Adaugă autentificare cu nume de utilizator în Dante

Treci politica SOCKS din Dante 1.4.4 de la acces doar după sursă la o verificare explicită a contului, păstrând restricțiile de sursă și destinație.

În Dante 1.4.4, regulile client acceptă conexiunea înaintea negocierii SOCKS, iar regulile SOCKS decid ce cereri autentificate pot continua. O conexiune dintr-o sursă permisă poate necesita în continuare un nume de utilizator în a doua etapă.

Pentru autentificarea cu nume de utilizator ale sistemului de operare, verifică identitățile serviciului, nu doar metoda. Citirea bazei de conturi poate necesita o identitate privilegiată:

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

Folosește contul real de serviciu cu privilegii reduse instalat pentru Dante. Creează sau alege un cont client autorizat, compatibil cu backendul pentru nume de utilizator; identitatea serviciului și autentificarea clientului au roluri diferite.

Păstrează limitele cererilor

După regula client restrictivă existentă, solicită contul pe ruta SOCKS permisă:

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
}

Adresele și numele contului sunt valori de exemplu. Acest lucru permite o sursă, o destinație, o comandă și utilizatorul autentificat indicat. Nu înlocui această limită cu surse nerestricționate doar pentru că ai adăugat o parolă.

Setările globale ale metodei și cele specifice regulii trebuie să fie în acord. Caută o regulă veche care permite doar none, rămasă din configurația bazată exclusiv pe sursă. Păstrează și restricțiile prevăzute pentru listener și firewall.

Testează negocierea și accesul separat

Înainte de pornire, verifică fișierul cu modul de verificare a configurației al serverului instalat. Apoi folosește un client autorizat care chiar acceptă negocierea SOCKS5 cu nume de utilizator și parolă. Verifică lipsa datelor de autentificare, date incorecte și un cont permis care cere o țintă interzisă.

Subnegocierea cu nume de utilizator și parolă definită de RFC 1929 nu criptează parola. O sesiune HTTPS ulterioară cu destinația nu protejează acel schimb anterior cu proxy-ul. Folosește o cale protejată corespunzător între client și server.

O verificare reușită a configurației confirmă sintaxa și identitățile, nu baza de conturi sau calea de rețea. Consultă jurnalele serverului pentru etapa care a respins un test real.

Articole similare