Две најавни проверки не се два фактора: VPN и RADIUS

Додавањето втор backend за автентикација на VPN порта изгледа како додавање втор фактор. Обично додава втора проверка, која е различен објект со различни режими на откажување. Дали двете мора да успеат, што докажува секоја и што се случува кога едната е недостапна се три одделни одлуки. Ако згрешите, портата завршува построга во демонстрацијата и послаба за време на прекин.

Што всушност докажува вториот backend

Пребарувањето во локална сметка докажува дека име постои во база на податоци и дека лозинка му одговарала. RADIUS размената докажува дека RADIUS сервер вратил Access-Accept за примените атрибути. Ниту едно од тврдењата не спомнува тип на фактор, бидејќи двете проверуваат знаење. А упатството на NIST за дигитален идентитет брои различни типови фактори и нивните автентикатори, а не сервери или потсетници.

Постои легитимен дизајн во кој учествуваат двата системи. Централна услуга може да го автентицира човекот, додека портата независно проверува дали таа сметка има право на овој тунел. Тоа е авторизација покрај автентикацијата, и нарекувањето тоа двофакторно меша проверка на политика со доказ за поседување.

RADIUS може да носи вистински втор фактор кога стои пред нешто што проверува еден, како push одобрување или хардверски токен. Ковертот не кажува кои автентикатори ги покажал корисникот, затоа читајте ја политиката на backend-от, а не етикетата на портата.

AND, OR и резервната се различни производи

Пред да ги споредувате имплементациите, одлучете што значи двете во вашето барање. AND политиката бара секоја именувана проверка да помине, OR политиката прифаќа онаа што успева, а резервната ја пробува втората само под наведени услови на откажување. Тие три се однесуваат спротивно за време на прекин, и обично само една од нив е тоа што прегледот го имал на ум.

Додавањето два записи за backend на екран за конфигурација не открива која политика ја спроведува производот. Некои порти ги врзуваат додатоците по ред и запираат на првото одбивање, што е AND само кога секој додаток е задолжителен. Други локалната сметка ја третираат како премостување, што централен прекин го претвора во заобиколување. Сигурниот одговор е документиран негативен тест за секој пат, изведен врз build-от што го распоредувате.

Резервната заслужува најмногу сомнеж, бидејќи постои за да продолжи да работи кога нешто е расипано. Резервна што прифаќа локална лозинка секогаш кога RADIUS е недостапен ја претворила централната политика во втора, послаба врата.

Двојната проверка на OpenVPN е конкретен случај

Заедничкиот OpenVPN 2.6 бара и клиентски сертификат и конфигурираната auth-user-pass-verify скрипта кога двете се овозможени. Тоа е документиран AND помеѓу проверка на сертификат и скрипта за акредитиви, и тоа се навистина две проверки. Сепак не е автоматски два типа фактори, бидејќи скриптата може да проверува само лозинка.

Комбинацијата исто така го остава отворено прашањето за поврзување. Сертификатот обично идентификува уред, додека акредитивите идентификуваат лице, и ништо во стандардниот тек не бара двете да се однесуваат на исти субјект. Одлучете кои парови се дозволени, потоа спроведете ја таа карта во скриптата за проверка или во подоцнежен чекор за авторизација.

Режимот само со сертификат е една проверка, поткрепена со клуч што може, но не мора да биде заштитен со PIN. PIN ги претвора истите акредитиви во знаење плус поседување само ако клучот не може да се користи без него. Оставањето на клучот нешифриран на диск го сведува вториот дел на дозвола за датотека.

Производителите на уреди градат сопствена инсталација, често PAM модул или RADIUS додаток зад веб-конзола. Однесувањето на заедницата е референца за тоа како изгледаат двојните проверки, а не опис како уредот ги комбинира.

Проверете ја комбинацијата на вашата порта

Прочитајте ја конфигурацијата пред да ѝ верувате на конзолната резиме. Редовите што ја одредуваат политиката се режимот на сертификат, скриптата за акредитиви и редоследот на додатоците.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep покажува дали е потребен сертификат и која скрипта се извршува по него, а редоследот е поважен отколку што сугерираат имињата. Исписот на сертификатот ја дава идентитетот што портата ќе го види, вклучувајќи го CN и серискиот број потребни за картата за поврзување. RADIUS тестот е негативниот случај: погрешна лозинка мора да даде Access-Reject, а точна Access-Accept. Ако одбиени акредитиви сѐ уште даваат сесија, скриптата воопшто не е на патот за автентикација.

Потоа изведете го случајот со прекин на лабораториска инстанца: запрете го задолжителниот backend и поврзете се со важечки акредитиви. Очекуваниот резултат е одбивање, а сѐ друго е резервната политика што никој не ја документирал.

Напишете го барањето како негативни случаи

Употребливо барање ги именува доказите, сметките на кои им е дозволено да ги презентираат и резултатот кога недостасува проверувач. Тоа го наведува и дозволеното спарување помеѓу идентитетот на уредот и идентитетот на лицето. Тоа е попрецизно од имињата на производите на нарачката, и може да се тестира.

Прифаќањето треба да вклучи четири одбивања: несоодветна локална сметка, недостасувачки задолжителен доказ, неважечки втор фактор и недостапен задолжителен backend. Секое одбивање бара линија во дневникот што го разликува од другите, инаку следниот инцидент започнува со претпоставки. Забележете која компонента ја донела секоја одлука, бидејќи портата, RADIUS серверот и директориумот ќе се обвинуваат меѓусебно.

Повторете ги четирите одбивања по секоја промена на додаток или фирмвер. Тие се евтини, а политиката што ја штитат е делот што напаѓачот прв го проверува.