La Configurazione del Firewall con il Protocollo di Autenticazione Kerberos

Chiamato come il cane a tre teste che custodiva le porte dell’Ade nei miti greci antichi, il protocollo Kerberos fornisce un servizio di autenticazione sicuro per le reti informatiche. Esegue un’autenticazione mutua tra l’utente e il server con l’aiuto di un terzo fidato, il Key Distribution Center (KDC), che fornisce servizio di autenticazione e rilascio dei ticket. Tutti i principali sistemi operativi, tra cui Microsoft Windows, Linux, Apple OS X e FreeBSD, supportano il protocollo Kerberos.

I messaggi del protocollo Kerberos sono protetti contro attacchi di replay e intercettazioni tramite crittografia a chiave segreta condivisa. Lo scopo principale di Kerberos è evitare la trasmissione di password crittografate sulla rete. Elimina la minaccia dei packet sniffer e migliora la sicurezza complessiva della rete.

Sebbene il provider di supporto alla sicurezza di Kerberos gestisca efficacemente gravi minacce alla sicurezza, può essere difficile da implementare a causa di varie limitazioni:

• Se il server Kerberos è inattivo, gli utenti non possono accedere. Il problema può essere risolto utilizzando meccanismi di autenticazione di fallback e più server Kerberos.
• Gli orologi degli host coinvolti devono essere sincronizzati. Altrimenti, l’autenticazione fallirà, poiché i ticket Kerberos hanno un determinato periodo di validità.
• Kerberos non può essere utilizzato quando gli utenti desiderano connettersi a servizi da sistemi non affidabili.
• In caso di utilizzo della crittografia simmetrica, la compromissione dell’infrastruttura di autenticazione consentirà a un attaccante di impersonare qualsiasi utente.
• Ogni servizio di rete che richiede un hostname diverso avrà bisogno del proprio set di chiavi Kerberos.

Come Funziona l’Autenticazione Kerberos

Il Key Distribution Center è composto da un Authentication Server (AS) e da un Ticket Granting Server (TGS). Il TGT è un Ticket Granting Ticket.

1. L’utente inserisce login e password. L’ID utente in chiaro viene inviato all’Authentication Server (AS) con richiesta di servizi per conto dell’utente.
2. AS controlla se il login dell’utente è nel database. Se vi sono informazioni su quell’utente, allora AS può generare la chiave segreta del client secondo l’ID e la password dell’utente. AS invia all’utente:
   • Chiave di sessione Client/TSG (crittografata con la chiave segreta del client);
   • TGT, comprensivo di ID utente, indirizzo di rete e periodo di validità del ticket + chiave di sessione Client/TGS (crittografata con la chiave segreta del TGS).
3. L’utente decodifica il primo messaggio ma non può decodificare il secondo, poiché non possiede la chiave segreta di TSG. Il client invia un messaggio al TGS:
   • TGT ricevuto da AS + ID server + chiave segreta TGS/Client (crittografata con la chiave segreta TGS);
   • Autenticatore, comprensivo di ID client e timestamp (crittografato con la chiave di sessione Client/TSG).
4. TGS decodifica il primo messaggio, ottiene TGT + chiave di sessione TGS/Client, con cui decodifica il secondo messaggio. TGS verifica se l’ID utente del primo messaggio corrisponde all’ID del secondo messaggio e se il timestamp non supera il periodo di validità del ticket. Se tutto è corretto, TSG invia all’utente:
   • ID usato, indirizzo di rete, periodo di validità del ticket + chiave di sessione Client/Server (crittografata con la chiave segreta del server);
   • Chiave di sessione Client/Server (crittografata con la chiave segreta Client/TGS).
5. Il client invia al server a cui tenta di accedere:
   • ID usato, indirizzo di rete, periodo di validità del ticket + chiave di sessione Client/Server (crittografata con la chiave segreta del server);
   • Autenticatore, comprensivo di ID e timestamp (crittografato con la chiave di sessione Client/Server).
6. Il server di destinazione decodifica i messaggi dell’utente, verifica se gli ID utente di entrambi i messaggi hanno lo stesso valore e se il periodo di validità non è scaduto, quindi invia al client il seguente parametro per confermare la sua identità:
   • Timestamp + 1 (crittografato con la chiave di sessione Client/Server)

Il client verifica se il valore del timestamp è timestamp + 1, il che indica la vera identità di un server. Se è così, il client può fidarsi del server e iniziare a lavorare con esso.

Configurazione del Firewall per funzionare con il Protocollo di Autenticazione Kerberos

Il firewall del database DataSunrise supporta il protocollo di autenticazione Kerberos. È necessario implementare alcune modifiche alle impostazioni per consentire le operazioni di Kerberos, variabili a seconda del prodotto RDBMS utilizzato. In questo articolo mostreremo come personalizzare Kerberos su MS SQL Server.

Durante il lavoro in Active Directory, l’autorizzazione degli utenti avviene tramite l’interfaccia di supporto alla sicurezza (SSPI). Esistono due protocolli che possono essere utilizzati: NTLM e Kerberos. NTLM è un protocollo più lento e meno sicuro, pertanto ci concentreremo solo sulla personalizzazione di Kerberos. Per abilitare Kerberos, devono essere soddisfatte diverse condizioni:

1. La delega per Active Directory Users and Computers deve essere abilitata.
   • Accedere a Active Directory Users and Computers.
   • Trovare l’account del computer in cui è installato DataSunrise.
   • Andare alla scheda Delega e passare allo stato “Trust this computer for delegation to any service”.
2. L’indirizzo del proxy deve corrispondere all’SPN registrato del servizio MSSQLSvc. Utilizzare lo strumento SetSPN per registrare i due SPN richiesti per l’account del computer per il quale è stata consentita la delega: setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

   L’elenco di tutti gli SPN registrati può essere ottenuto con il seguente comando:

   setspn -L proxy-host

   Per eliminare il proxy SPN, eseguire il seguente comando:

   setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

   Per testare lo schema di autorizzazione, eseguire il seguente comando dopo essersi connessi al server:

   select auth_scheme from sys.dm_exec_connections where session_id=@@spid

   Il risultato sarà corrispondente allo schema di autenticazione utilizzato dal server: SQL, NTLM o KERBEROS.

3. In caso di errore “Cannot generate SSPI context”, fare riferimento alle istruzioni di supporto Microsoft su come risolvere il problema con l’interfaccia di supporto alla sicurezza.