Две провере пријаве нису два фактора: 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 сервер и директоријум међусобно да се оптужују.

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