Afegiu autenticació amb nom d’usuari a Dante

Passeu d’una política SOCKS basada només en l’origen a una comprovació explícita del compte a Dante 1.4.4, mantenint les restriccions d’origen i destinació.

A Dante 1.4.4, les regles de client admeten la connexió abans de la negociació SOCKS, mentre que les regles SOCKS decideixen quines peticions autenticades poden continuar. Una connexió des d’un origen permès encara pot requerir un nom d’usuari a la segona fase.

Per autenticar amb usuaris del sistema operatiu, reviseu les identitats del servei i el mètode. Llegir la base de comptes pot requerir una identitat privilegiada:

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

Feu servir el compte de servei real amb pocs privilegis instal·lat per a Dante. Creeu o seleccioneu un compte de client autoritzat compatible amb el backend de noms d’usuari; la identitat del servei i l’inici de sessió del client tenen funcions diferents.

Manteniu els límits de les peticions

Després de la regla de client restrictiva existent, exigiu el compte a la ruta SOCKS permesa:

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
}

Les adreces i el nom del compte són valors d’exemple. Això permet un origen, una destinació, una ordre i l’usuari autenticat indicat. No substituïu aquest límit per orígens sense restriccions només perquè s’hi ha afegit una contrasenya.

Els ajustos globals del mètode i els específics de la regla han de concordar. Comproveu si queda una regla antiga que només admet none d’una configuració basada únicament en l’origen. Manteniu també les restriccions previstes del punt d’escolta i del tallafoc.

Proveu la negociació i l’accés per separat

Abans d’engegar el servidor, verifiqueu el fitxer amb el mode de comprovació de configuració de la versió instal·lada. Després feu servir un client autoritzat que realment admeti la negociació SOCKS5 amb usuari i contrasenya. Proveu credencials absents, credencials incorrectes i un compte permès que demana una destinació prohibida.

La subnegociació d’usuari i contrasenya definida a l’RFC 1929 no xifra la contrasenya. Una sessió HTTPS posterior amb la destinació no protegeix aquell intercanvi anterior amb el proxy. Feu servir un camí adequadament protegit entre client i servidor.

Una comprovació de configuració correcta confirma la sintaxi i les identitats, no la base de comptes ni el camí de xarxa. Consulteu els registres del servidor per veure en quina fase s’ha rebutjat una prova real.

Articles relacionats