Solicitați autentificarea la ambele servicii HTTP și SOCKS ale 3proxy

Configurați utilizatori 3proxy, autentificare puternică și reguli de acces la servicii pentru clienții HTTP și SOCKS5.

Definirea unui utilizator nu este întreaga configurare de autentificare a 3proxy. Serviciul are nevoie și de o metodă de autentificare și de o regulă de acces care o folosește. Ordinea contează deoarece setările serviciului se aplică în timpul procesării configurației.

Un exemplu doar local pentru două servicii:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Referința de configurare explică users, auth strong și comenzile serviciului. CL stochează această parolă de exemplu ca text simplu. Protejați fișierul și alegeți o formă acceptată de stocare a credențialelor potrivită pentru implementare.

Clientul are nevoie de schimbul de autentificare corect

Serviciul HTTP așteaptă autentificare proxy HTTP. Serviciul SOCKS are nevoie de un client care acceptă autentificarea SOCKS5 cu nume de utilizator și parolă. Un client SOCKS4 nu poate oferi acel schimb doar pentru că ajunge la același port de ascultare.

Cuvântul strong este numele unui mod de autentificare, nu o garanție a transportului criptat. Protejați segmentul de la client la proxy atunci când este necesar. HTTPS către destinație și criptarea către proxy rămân decizii separate.

Legăturile loopback limitează acest exemplu la accesul local. Pentru clienții la distanță, alegeți explicit un ascultător și o politică de rețea dorite. Un ascultător public cu wildcard nu înlocuiește verificarea comportamentului de autentificare.

Dacă un serviciu cere credențiale și altul nu, examinați setările dinaintea fiecărei comenzi de serviciu, regulile de după orice flush și memoria cache de autentificare. Schimbarea unei parole nu poate repara un serviciu pornit sub o politică greșită. La fel, schimbarea contului de sistem de operare al demonului nu creează un utilizator proxy.

Articole similare