Aggiungere l’autenticazione con nome utente a Dante

Passa da una politica SOCKS basata solo sull’origine a un controllo esplicito dell’account in Dante 1.4.4, mantenendo i vincoli su origine e destinazione.

In Dante 1.4.4, le regole client ammettono la connessione prima della negoziazione SOCKS, mentre le regole SOCKS decidono quali richieste autenticate possono proseguire. Una connessione da un’origine consentita può quindi richiedere comunque un nome utente nella seconda fase.

Per l’autenticazione con gli utenti del sistema operativo, esamina le identità del servizio oltre al metodo. La lettura del database degli account può richiedere un’identità privilegiata:

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

Usa l’effettivo account di servizio con pochi privilegi installato per Dante. Crea o scegli un account client autorizzato compatibile con il backend dei nomi utente; l’identità del servizio e l’accesso del client hanno ruoli diversi.

Mantieni i limiti delle richieste

Dopo la regola client restrittiva esistente, richiedi l’account sul percorso SOCKS consentito:

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
}

Gli indirizzi e il nome dell’account sono valori di esempio. Questo consente un’origine, una destinazione, un comando e l’utente autenticato indicato. Non sostituire tale limite con origini senza restrizioni solo perché hai aggiunto una password.

Le impostazioni globali del metodo e quelle della regola devono coincidere. Cerca una vecchia regola che ammette solo none, rimasta dalla configurazione basata esclusivamente sull’origine. Conserva anche i vincoli previsti per il listener e il firewall.

Verifica separatamente negoziazione e accesso

Prima dell’avvio, verifica il file con la modalità di controllo della configurazione del server installato. Poi usa un client autorizzato che supporti davvero la negoziazione SOCKS5 con nome utente e password. Prova credenziali mancanti, credenziali errate e un account consentito che richiede una destinazione vietata.

La subnegoziazione con nome utente e password definita da RFC 1929 non cifra la password. Una successiva sessione HTTPS con la destinazione non protegge quello scambio precedente con il proxy. Usa un percorso adeguatamente protetto tra client e server.

Un controllo di configurazione riuscito conferma sintassi e identità, non il database degli account o il percorso di rete. Consulta i log del server per individuare la fase che ha respinto una prova reale.

Articoli correlati