RouterOS OpenVPN kaj NPS: agordu user-auth-method, ne auth

RouterOS povas atingi NPS per OpenVPN-ensaluto kaj tamen esti malakceptita, kaj la kutima kaŭzo estas du agordoj kies nomoj ambaŭ sonas kiel aŭtentikigo. Unu elektas kriptografian digeston por la tunelo; la alia decidas kiel la legitimiloj de la uzanto estas prezentataj al RADIUS. Ŝanĝo de la digesto neniam transformos PAP-peton en MS-CHAPv2, kiom ajn ofte la servo restartos. La suba kontrol-listo apartigas la du, poste sekvas unu malsukcesan ensaluton tra la NPS-politiko kiu juĝis ĝin.

Paŝo 1: legu ambaŭ agordojn antaŭ ol ŝanĝi iun ajn

Presu la efikan OpenVPN-servilan agordon sur la enkursigilo kiu finas la tunelon, ne el savkopio aŭ kopiita forumafiŝo. La du kampoj kiuj gravas kutime estas en la sama menuo kaj legiĝas kvazaŭ ili estus alternativoj. Ili ne estas: unu temas pri la datena kanalo, la alia pri la interŝanĝo de legitimiloj.

/interface ovpn-server server print
/interface ovpn-server server export

La kampo auth listigas digestojn kiel sha1 kaj sha256 kaj regas la HMAC kiu aŭtentikigas tunelajn pakaĵojn. La kampo user-auth-method elektas pap aŭ mschap2 kaj decidas kiel la enkursigilo prezentas la legitimilojn de la uzanto al RADIUS. Ŝanĝo de la digesto ne povas ŝanĝi la duan konduton, kaj tial la sama malakcepto postvivas ĉiun ĝustigon de la unua.

Haltu ĉi tie se via versio tute ne elmetas user-auth-method. Pli malnovaj RouterOS-konstruoj eble ne ofertas ĝin sur la OpenVPN-servilo, kaj la korekto apartenas al versio kiun vi povas subteni, ne al komando kopiita el pli nova.

Paŝo 2: trovu la politikon kiu efektive malakceptis la ensaluton

Ĉe la NPS-flanko, konekta peto estas taksata laŭ retaj politikoj, kaj la aŭtentika metodo nomata en la kongrua politiko devas esti unu kiun la kliento efektive proponis. Koreligu unu malsukcesan ensaluton laŭ tempo kaj uzanto anstataŭ legi suman nombron. La sekureca protokolo registras aprobitajn kaj rifuzitajn petojn kun kaŭza kodo, kio diras al vi multe pli ol la ĝenerala erarlinio de la enkursigilo.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Legu tri aferojn en la okazaĵo: la nomon de la kongrua politiko, la aŭtentikan metodon kaj la kaŭzan kodon. Politiko kiu postulas MS-CHAPv2 rifuzas PAP-peton eĉ kiam la pasvorto estas ĝusta, kaj politiko kiu postulas domajnan konton rifuzas lokan. La RADIUS-klienta enskribo ankaŭ devas kongrui kun la fonta adreso de la enkursigilo, alie la peto estas forĵetita antaŭ ol iu politiko estas konsultita. Nenio el tio aperas en la OpenVPN-protokolo.

Haltu ĉi tie se la peto neniam atingas NPS. Tio estas problemo pri la komuna sekreto, klienta adreso aŭ UDP 1812, kaj ŝanĝo de aŭtentikaj metodoj ne riparos ĝin.

Paŝo 3: ŝanĝu unu metodon, ambaŭflanke

Se la aprobita dezajno estas MS-CHAPv2, agordu ĝin sur la enkursigilo kaj konfirmu ke la kongrua politiko akceptas ĝin. Ŝanĝu unu flankon, retestu, poste ŝanĝu la alian; ŝanĝi ambaŭ samtempe lasas vin nekapabla diri kiu gravis.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Ne ŝaltu ĉiun pli malfortan metodon en NPS por ke la eraro malaperu. La dorsa sistemo devas teni materialon kiun la elektita metodo povas kontroli: MS-CHAPv2 bezonas aliron al la pasvorto aŭ al la domajno, kaj politiko ne povas elpensi tiun materialon. Larĝigi la politikon ankaŭ larĝigas tion kion atakanto povas provi kontraŭ la sama konto. Registru la metodon, la politikan nomon kaj la ŝanĝan referencon kune, por ke la sekva persono heredas decidon anstataŭ konjekton.

Konservu la atestilan validigon de la tunelo ĝuste tiel kiel ĝi estis. Legitimila metodo ne anstataŭas servilan identecon, kaj malaltigi TLS-kontrolojn por ke testo pasu interŝanĝas unu problemon kontraŭ pli malbona.

Paŝo 4: testu tri ensalutojn kaj unu permeson

Testu permesitan uzanton, malĝustan pasvorton kaj ekskluditan uzanton, ĉiun en freŝa seanco. La unua pruvas la vojon, la dua pruvas ke la legitimila kontrolo estas reala, kaj la tria pruvas ke la politiko ankoraŭ ekskludas tiun kiun ĝi devas. Kaŝmemorita seanco povas kaŝi ĉiujn tri, do malkonektu inter provoj.

/log print where topics~"ovpn"
/radius monitor 0

Sukcesa aŭtentikigo ne estas la fino de la kontrol-listo. Kontrolu la adreson kiun la kliento ricevis kaj la rimedojn kiujn tiu adreso povas atingi, ĉar uzanto povas aŭtentikiĝi ĝuste kaj tamen fini en la malĝusta baseno. Se la asignita adreso estas malĝusta, la problemo kuŝas en la profilo aŭ en la atributoj de la RADIUS-respondo, ne en la metodo. Konfirmu ambaŭ antaŭ ol fermi la bileton.

La kontrol-listo estas finita kiam la enkursigila agordo kaj la NPS-politiko nomas la saman metodon, unu permesita uzanto konektiĝas per freŝa seanco, unu malĝusta pasvorto estas rifuzita, unu ekskludita uzanto restas ekskludita, kaj la asignita adreso kongruas kun la celita baseno. Io ajn malpli lasas la sekvan ensaluton al hazardo.