La Configurazione del Firewall per il Protocollo di Autenticazione Kerberos

Chiamato come il cane a tre teste che guarda i cancelli dell’Ade nei miti greci antichi, il protocollo Kerberos fornisce un servizio di autenticazione sicura per le reti informatiche. Esso esegue l’autenticazione reciproca tra l’utente e il server con l’aiuto del Key Distribution Center (KDC) di terze parti affidabile che fornisce il servizio di autenticazione e concessione di ticket. Tutti i principali sistemi operativi, inclusi Microsoft Windows, Linux, Apple OS X e FreeBSD, supportano il protocollo Kerberos.

I messaggi del protocollo Kerberos sono protetti contro gli attacchi di replay e l’ascolto clandestino tramite crittografia a chiave condivisa. Lo scopo principale di Kerberos è evitare la trasmissione di password crittografate attraverso la rete. Elimina la minaccia degli sniffers di pacchetti e migliora la sicurezza generale della rete.

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

• Se il server Kerberos è inattivo, gli utenti non possono accedere. Il problema può essere risolto utilizzando meccanismi di autenticazione di riserva e server Kerberos multipli.
• 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.
• Nel caso venga utilizzata la crittografia simmetrica, la compromissione dell’infrastruttura di autenticazione permetterà a un attaccante di impersonare qualsiasi utente.
• Ogni servizio di rete che richiede un nome host diverso avrà bisogno del proprio set di chiavi Kerberos.

Come Funziona l’Autenticazione Kerberos

Il Key Distribution Center è costituito dal Server di Autenticazione (AS) e dal Ticket Granting Server (TGS). TGT è un Ticket Granting Ticket.

1. L’utente inserisce login e password. L’ID utente in chiaro viene inviato al Server di Autenticazione (AS) con una richiesta di servizi a nome dell’utente.
2. AS verifica se il login dell’utente è nel database. Se ci 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 che include 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, perché non ha la chiave segreta del TGS. Il client invia un messaggio al TGS:
   • TGT ricevuto dall’AS + ID del server + chiave segreta TGS/Client (crittografata con la chiave segreta del TGS);
   • Autenticatore che include ID client e timestamp (crittografato con la chiave di sessione Client/TSG).
4. TGS decritta il primo messaggio, riceve TGT + chiave di sessione TGS/Client, con la quale decritta il secondo messaggio. TGS verifica se l’ID dell’utente dal primo messaggio corrisponde all’ID del secondo messaggio e se il timestamp non supera il periodo di validità del ticket. Se tutto è corretto, TGS 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 cerca di accedere i seguenti messaggi:
   • ID usato, indirizzo di rete, periodo di validità del ticket + chiave di sessione Client/Server (crittografata con la chiave segreta del server);
   • Autenticatore che include ID e timestamp (crittografato con la chiave di sessione Client/Server).
6. Il server di destinazione decritta i messaggi dell’utente, verifica se gli ID utente dei due messaggi hanno lo stesso valore e se il periodo di validità non è stato superato, 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 conferma la vera identità del server. Se è così, il client può fidarsi del server e iniziare a lavorare con esso.

Configurare il Firewall per Lavorare con il Protocollo di Autenticazione Kerberos

Il firewall del database DataSunrise supporta il protocollo di autenticazione Kerberos. Devono essere implementate alcune modifiche alle impostazioni per consentire le operazioni Kerberos, che possono variare 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 dell’utente viene eseguita tramite Security Support Provider Interface (SSPI). Ci sono due protocolli che possono essere utilizzati: NTLM e Kerberos. NTLM è un protocollo più lento e meno sicuro, quindi contempleremo solo la personalizzazione di Kerberos. Per abilitare Kerberos, devono essere soddisfatte diverse condizioni:

1. Deve essere abilitata la delega per Active Directory Users e Computers.
   • Vai su Active Directory Users e Computers.
   • Trova l’account del computer su cui è installato DataSunrise.
   • Vai alla scheda Delega e passa allo stato “Fiducia questo computer per la delega a qualsiasi servizio”.
2. L’indirizzo proxy deve corrispondere all’SPN registrato del servizio MSSQLSvc. Utilizzare lo strumento SetSPN per registrare due SPN necessari 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

   È possibile ottenere l’elenco di tutti gli SPN registrati con il seguente comando:

   setspn -L proxy-host

   Per eliminare l’SPN proxy, eseguire il seguente comando:

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

   Per testare lo schema di autorizzazione, eseguire il comando seguente 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. Nel caso in cui venga visualizzato l’errore “Impossibile generare il contesto SSPI”, fare riferimento alle istruzioni di supporto Microsoft su come risolvere il problema con l’interfaccia provider di supporto alla sicurezza.