Shtoni autentikim me emër përdoruesi në Dante

Kalojeni politikën SOCKS të Dante 1.4.4 nga qasja vetëm sipas burimit te një kontroll i qartë i llogarisë, duke ruajtur kufizimet e burimit dhe destinacionit.

Në Dante 1.4.4, rregullat e klientit pranojnë lidhjen përpara negocimit SOCKS, ndërsa rregullat SOCKS vendosin cilat kërkesa të autentikuara mund të vazhdojnë. Një lidhje nga një burim i lejuar mund të kërkojë përsëri emër përdoruesi në fazën e dytë.

Për autentikim me emra përdoruesish të sistemit operativ, shqyrtoni identitetet e shërbimit bashkë me metodën. Leximi i bazës së llogarive mund të kërkojë një identitet të privilegjuar:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Përdorni llogarinë reale të shërbimit me pak privilegje, të instaluar për Dante. Krijoni ose zgjidhni një llogari klienti të autorizuar, të pajtueshme me backend-in e emrave të përdoruesve; identiteti i shërbimit dhe hyrja e klientit kanë role të ndryshme.

Ruani kufijtë e kërkesave

Pas rregullit të ngushtë ekzistues të klientit, kërkoni llogarinë në itinerarin SOCKS të lejuar:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

Adresat dhe emri i llogarisë janë vlera shembull. Kjo lejon një burim, një destinacion, një komandë dhe përdoruesin e autentikuar të përcaktuar. Mos e zëvendësoni këtë kufi me burime të pakufizuara vetëm sepse është shtuar një fjalëkalim.

Cilësimet globale të metodës dhe ato të rregullit duhet të përputhen. Kontrolloni për një rregull të vjetër që lejon vetëm none, të mbetur nga konfigurimi vetëm sipas burimit. Ruani edhe kufizimet e synuara të dëgjuesit dhe murit mbrojtës.

Testoni negocimin dhe qasjen veçmas

Përpara nisjes, verifikoni skedarin me mënyrën e kontrollit të konfigurimit të serverit të instaluar. Pastaj përdorni një klient të autorizuar që mbështet vërtet negocimin SOCKS5 me emër përdoruesi dhe fjalëkalim. Kontrolloni mungesën e kredencialeve, kredencialet e pasakta dhe një llogari të lejuar që kërkon një objektiv të ndaluar.

Nënnegocimi me emër përdoruesi dhe fjalëkalim i përcaktuar nga RFC 1929 nuk e enkripton fjalëkalimin. Një sesion i mëvonshëm HTTPS me destinacionin nuk mbron atë shkëmbim të mëparshëm me proxy-n. Përdorni një rrugë të mbrojtur siç duhet nga klienti te serveri.

Një kontroll i suksesshëm i konfigurimit konfirmon sintaksën dhe identitetet, jo bazën e llogarive ose rrugën e rrjetit. Shqyrtoni regjistrat e serverit për fazën që refuzoi një test real.

Artikuj të ngjashëm