CNTLM: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Riga 94: Riga 94:
{{ Warningbox | ''PassNT'' e ''PassLM'' cifrano la password senza tenere conto di nome utente e dominio, mentre come già scritto ''PassNTLMv2'' sfrutta anche i suddetti parametri. Ne consegue che gli hash ''PassNT'' e ''PassLM'' di una certa password sono sempre i medesimi a prescindere dal nome utente e dal dominio specificato, mentre nel caso di ''PassNTLMv2'' cambia in funzione del loro valore.}}
{{ Warningbox | ''PassNT'' e ''PassLM'' cifrano la password senza tenere conto di nome utente e dominio, mentre come già scritto ''PassNTLMv2'' sfrutta anche i suddetti parametri. Ne consegue che gli hash ''PassNT'' e ''PassLM'' di una certa password sono sempre i medesimi a prescindere dal nome utente e dal dominio specificato, mentre nel caso di ''PassNTLMv2'' cambia in funzione del loro valore.}}


=== Controllo del funzionamente di cntlm ===
=== Controllo del funzionamento di cntlm ===


Se il test effettuato al punto precedente è risultato positivo è il momento di provare ad eseguire cntlm in modalità normale (ma avviandolo sempre da terminale, non come demone).
Se il test effettuato al punto precedente è risultato positivo è il momento di provare ad eseguire cntlm in modalità normale (ma avviandolo sempre da terminale, non come demone).

Versione delle 15:53, 17 feb 2015

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione

CNTLM è un proxy di autenticazione molto utile quando il proprio computer si trova dietro un firewall windows che richiede all'utente di autenticarsi per poter "accedere ad internet". Sebbene alcuni programmi, come i browser più noti, implementino nativamente un sistema per dialogare con proxy di qualsiasi natura, molti altri o non hanno proprio alcun modo per interfacciarsi con un proxy, oppure semplicemente inviano degli hedears che vengono rifiutati dal proxy windows. Un altro motivo per usare cntlm consiste nella possibilità di specificare la password in forma cifrata e non in chiaro, come di solito avviene per esempio in APT, dove l'unico modo di specificare username e password è insieme all'indirizzo del proxy nella forma http://username:password@indirizzo_proxy:porta/.

Installazione

CNTLM è disponibile direttamente da repository ufficiali, quindi è per esempio sufficiente digitare:

# aptitude install cntlm

Configurazione

Configurare CNTLM non è di per se difficile una volta capita la logica di fondo, purtroppo la documentazione esistente è (al momento in cui questa guida viene scritta) piuttosto lacunosa nello spiegare alcune opzioni e aspetti.

Modifica iniziale di cntlm.conf

Per prima cosa si consiglia di terminare l'esecuzione del demone cntlm, poiché è preferibile eseguire inizialmente cntlm direttamente da riga di comando in modo da poter registrare log specifici e aumentare il numero di informazioni fornite dal proxy. Per terminare cntlm digitare:

# /etc/init.d/cntlm stop

Fare una copia del file di configurazione orginale, ad esempio:

# cp /etc/cntlm.conf /etc/cntlm_conf.bak

Quindi editarlo avendo cura di commentare tutte le righe AD ESCLUSIONE di quelle relative alla porta da usare e agli indirizzi da non passare a cntlm:

# List addresses you do not want to pass to parent proxies
# * and ? wildcards can be used
#
NoProxy		localhost, 127.0.0.*, 10.*, 192.168.*

...

# Specify the port cntlm will listen on
# You can bind cntlm to specific interface by specifying
# the appropriate IP address also in format <local_ip>:<local_port>
# Cntlm listens on 127.0.0.1:3128 by default
#
Listen		3128

Test di cntlm e calcolo hash password

A questo punto avviare il proxy in modalità test digitando quanto segue:

# cntlm -I -u ''mia_utenza'' -d ''AZIENDA'' -M http://www.google.it ''IP_proxy:porta''

Dove:

  • I è un opzione che abilita l'immissione della password utente direttamente da terminale, senza cioè doverla specificare in chiaro nella riga di comando (tramite l'opzione -p).
  • mia_utenza è l'utenza abilitata ad accedere al server proxy di windows;
  • AZIENDA è il dominio cui appartiene la sopracitata utenza;
  • IP_proxy:porta è l'indirizzo del server proxy windows;
  • -M è l'opzione da usare per specificare un indirizzo http valido contro cui testare il funzionamento di cntlm.

Una volta specificata la password si dovrebbe ottenere una risposta simile alla seguente:

Config profile  1/4... OK (HTTP code: 200)
----------------------------[ Profile  0 ]------
Auth            NTLMv2
PassNTLMv2      FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE
------------------------------------------------

Dove FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE è un hash generato in funzione di:

  • nome utente
  • dominio
  • password

Si noti che server vecchi potrebbero utilizzare protocolli di autenticazione più vecchi (e meno sicuri) di NTLMv2, in tal caso l'output del precedente comando potrebbe essere significativamente diverso da quello indicato. Del precedente output è la prima riga ad indicare se il test ha avuto successo o meno. Se si riceve Config profile 1/4... OK (HTTP code: 200) allora il test ha avuto esito positivo, viceversa se si dovesse ottenere un credentials rejected significherebbe che il test è fallito a causa di un errata indicazione di utente, password o dominio (uno solo o anche tutte e tre i parametri contemporaneamente).

Info.png Note
  • Nell'esperienza personale di chi scrive è risultato indifferente specificare come dominio AZIENDA oppure fqdn_azienda, a patto di indicare correttamente l'hash della password (si veda più sotto).
  • L'hash (o gli hash) restituiti serviranno solo più avanti, al momento di definire in maniera finali il file cntlm.conf.


Note sugli altri metodi di cifratura e di autenticazione

È possibile ottenere manualmente un elenco di tutti e tre i possibili hash digitando:

# cntlm -H -u ''mia_utenza'' -d ''AZIENDA''

Che resituirà qualcosa di simile a:

PassLM          FAK3FAK3FAK3FAK3FAK3FAK3FAK3FAK3
PassNT          F@KEF@KEF@KEF@KEF@KEF@KEF@KEF@KE
PassNTLMv2      FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE    # Only for user 'mia_utenza', domain 'AZIENDA'
Info.png Importante
Il precedente comando calcola solo gli hash della password, NON testa in alcun modo il funzionamento di cntlm. Per testarne il funzionamento è necessario usare l'opzione -M seguita da un indirizzo internet valido.

Come specificato nel manuale di cntlm esistono diversi protocolli di autenticazione ciascuno dei quali sfrutta da uno a due sistemi di cifratura:

Auth         |  Requires
-------------+-----------------
NTLMv2       |  PassNTLMv2
NTLM2SR      |  PassNT
NT           |  PassNT
NTLM         |  PassNT + PassLM
LM           |  PassLM

Nella colonna Auth viene indicata la sigla del protocollo di autenticazione, mentre nella colonna requires la sigla dei metodi di cifratura usati per cifrare la password utente (i protocolli sono ordinati in funzione del grado di sicurezza offerto, dove NTLMv2 è il più recente e il più sicuro). Come si vede tutti i protocolli di autenticazione, ad eccezione di NTLM, richiedono un solo sistema di cifratura.

Warning.png ATTENZIONE
PassNT e PassLM cifrano la password senza tenere conto di nome utente e dominio, mentre come già scritto PassNTLMv2 sfrutta anche i suddetti parametri. Ne consegue che gli hash PassNT e PassLM di una certa password sono sempre i medesimi a prescindere dal nome utente e dal dominio specificato, mentre nel caso di PassNTLMv2 cambia in funzione del loro valore.


Controllo del funzionamento di cntlm

Se il test effettuato al punto precedente è risultato positivo è il momento di provare ad eseguire cntlm in modalità normale (ma avviandolo sempre da terminale, non come demone). Da terminale digitare:

# cntlm -T log.txt -Isv -a ''auth'' -u mia_utenza -d AZIENDA IP_proxy:porta

A questo punto si dovrebbe vedere il cursore rimanere fermo (è possibile terminare l'esecuzione di cntlm in qualsiasi momento premento CTRL+C), segno che cntlm è avviato e in ascolto. Alcune note sulle nuove opzioni usate:

  • -T permette di indicare un file di log specifico in cui salvare tutte le informazioni prodotte da cntlm;
  • -a permette di specificare il protocollo di autenticazione, usare quello indicato dal programma stesso in modalità test (si veda sezione precedente). In teoria questo parametro può anche essere omesso visto che cntlm dovrebbe essere in grado si selezionare autonomamente il protocollo corretto;
  • -s e -v permettono di stampare molte più informazioni rispetto al normale.

Aprire una nuova finestra e testare il funzionamento di cntlm usando ad esempio aptitude (o apt-get o quello che più aggrada) e wget. Esempi di test:

# aptitude update
$ wget http://indirizzo_test/file.test

Se i sudetti comandi funzionano correttamente è allora possibile passare direttamente alla sezione successiva e definire in modo definitivo il file di configurazione cntlm.conf, viceversa sarà necessario esaminare il file di log per cercare di capire cosa sia andato storto (i codici degli headers HTTP possono dare utili indicazioni).

Modifica finale di cntlm.conf

Se i precedenti test hanno dato esito positivo è possibile arrestare l'istanza precedente avviata di cntlm (se ancora non lo si era fatto) e quindi editare in modo definitivo il file /etc/cntlm.conf. Al lettore la scelta se creare un file di configurazione minimale (cioè privo di tutti i commenti) oppure no. Di seguito un esempio di file minimale (sono inclusi tutti e tre gli hash della password utente, ma chiaramente solo uno o due sono realmente necessari come già detto):

Username        nome_utente
Domain          AZIENDA
PassLM          FAK3FAK3FAK3FAK3FAK3FAK3FAK3FAK3
PassNT          F@KEF@KEF@KEF@KEF@KEF@KEF@KEF@KE
PassNTLMv2      FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE 
Proxy           IP_proxy
NoProxy         localhost, 127.0.0.*, 10.*, 192.168.*
Listen          3128
Auth            NTLMv2

Si noti che il parametro Auth potrebbe essere volendo omesso poiché cntlm è in grado di determinarlo autonomamente al suo avvio (così come il parametro flag).

Possibili problemi

403 Forbidden

Se la risposta (header HTTP) che riceve cntlm dal proxy windows è 403 Forbidden è possibile che l'errore sia dovuto ad un rifiuto degli headers che normalmente i vari applicativi come APT e wget generano. Per esempio in un sistema su cui è installato anche apt-cacher il parametro User-Agent è nei due casi (rispettivamente):

apt-cacher/1.7.10 libcurl/7.38.0 GnuTLS/3.3.8 zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Wget/1.16 (linux-gnu)

Se questo fosse il caso è possibile istruire cntlm affiché sostituisca i predetti valori con uno "più comune". È quindi sufficiente editare il file /etc/cntlm.conf è decommentare (o aggiungere) quanto segue:

# Headers which should be replaced if present in the request
#
Header         User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Naturalmente è necessario riavviare il demone di cntlm perché carichi questo nuovo parametro.

Info.png Nota
A seguito di questa variazione TUTTE le richieste indirizzate a cntlm vedranno il parametro User-Agent modificato, pertanto può essere conveniente evitare di indicare cntlm come proxy per quelle applicazioni che permettono nativamente di indicare un proprio proxy, come molti dei browser più comuni.


Approfondimenti

Manpages

man cntlm

Sitografia




Guida scritta da: Wtf 14:21, 17 feb 2015 (CET) Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized