AAA
Il controllo degli accessi è uno degli elementi fondamentali per un’infrastruttura di rete, in questo modo noi controlliamo chi può avere accesso alla rete e cosa può fare, quali servizi può effettivamente utilizzare, dopo avere eseguito l’accesso. AAA è un framework attraverso il quale noi possiamo configurare il controllo degli accessi sui nostri apparati di rete, siano essi access-server, terminali mobili WiFi, etc.
Ma perchè AAA? AAA è l’acronimo di Authentication, Authorization e Accounting. Il framework AAA si propone di fornire una via modulare all’esecuzione dei seguenti servizi:
Authentication: fornisce il servizio di identificazione degli utenti (chi è ?) attraverso molteplici modalità: login/password, challenge/response, encryption (a seconda del protocollo scelto).
L’autenticazione ci consente di identificare l’utente prima che sia autorizzato all’accesso di rete o ai servizi di rete.
Authorization: fornisce il servizio per il controllo remoto degli accessi, autorizzazione per utente, autorizzazione per gruppo, autorizzazione per servizio, supporta IP, IPX, Telnet.
Si basa sulla creazione di un insieme di attributi che descrivono le policy associate all’utente.
Un database locale o remoto contenente le informazioni per singolo utente servirà per comparare tale set di informazioni con quelle presenti al suo interno, il risultato sarà ritornato ad AAA che determinerà le azioni che l’utente può o non può compiere.
I server remoti, anche detti remote security server, autorizzano l’utente associandogli una coppia AV, attributo-valore, che definisce queste azioni.
Accounting: fornisce il servizio di invio di dati utilizzati per il billing, l’auditing, il reporting, come identità, tempi di start-stop, comandi seguiti, numero di pacchetti e numero di bytes.
In questo modo possiamo tracciare le attività dell’utente, come i servizi utilizzati e le risorse di rete consumate.
Quando l’accounting è attivato l’access server invia dei report sull’attività utente al nostro security server, TACAS+ o RADIUS sotto forma di accounting records, composto da una coppia AV di accounting che verrà salvata sul nostro server remoto, o access control server. Questo consente la possibilità di un’analisi a posteriori dei dati collezionati con scopi di auditing, billing e network management.
Nella maggioranza dei casi AAA utilizza protocolli come RADIUS, TACACS+, o Kerberos per amministrare le sue funzioni di sicurezza. Se il nostro router o access server ha funzionalità di NAS (Network Access Server) AAA rappresenta la modalità attraverso la quale stabiliamo la comunizazione tra il nostro NAS e il RADIUS, TACACS+ o Kerberos security server.
AAA rappresenta il principale metodo per effettuare il controllo di accesso, in ogni caso l’IOS fornisce altre funzionalità per tale scopo come le autenticazioni basate su local username, la line password e la enable password.
Chiaramente tali funzionalità non garantiscono gli stessi livelli di granularità che si possono ottenere utilizzando AAA. In questo documento tralascerò la parte relativa all’accounting e all’authorization, trattando solo l’authentication.
RADIUS e TACACS+
Radius è l’acronimo di Remote Authentication Dial-In User Service, un protocollo client/server che consente ai server di accesso remoto di comunicare con un’unità centrale che ha funzionalità di autenticare gli utenti ed autorizzarli, garantire l’accesso alla sistema o al servizio richiesto. Il server centrale consente di mantenere i profili utente in un database che viene reso disponibile ai server remoti. Creato da Livingston ora parte di Lucent, RADIUS è uno standard de facto utilizzato da un grosso numero di produttori. Un pacchetto radius:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TACAS+ è un acronimo di Terminal Access Controller Access Control System, evoluzione di TACACS ormai datato e usato sporadicamente, e di XTACACS (Extended). TACACS+ è u protocollo completamente nuovo e perciò non retrocompatibile. Vediamo una rete di esempio come quella riportata in figura, dove un utente remoto vuole autenticarsi sulla nostra rete.
aaascheme.jpg
Il nostro NAS è configurato per autenticarsi sui server R1-R2-T1-T2, l’utente invia la richiesta di accesso, il NAS la processa e inizia a comunicare con R1. In caso di autenticazione positiva R1 risponde con un messaggio di PASS e l’utente è autenticato altrimenti invia indietro un messaggio di FAIL, all’utente viene negato l’accesso e la sessione viene chiusa. Se R1 non risponde il nas la processa come un ERROR e contatta R2, questo procedimento prosegue per tutti i metodi di autenticazione configurati finchè l’utente non è autenticato o respinto.
Nella figura sottoriportata ho cercato di sintetizzare i passi compiuti dall’AAA authentication.
radius.jpg
Radius Server
Nel catalogo prodotti di Cisco c’è una soluzione software, ACS, che implementa un server RADIUS/TACACS+ per piattaforma Unix o Windows Server. In quest’ultimo caso si può allineare il db di ActiveDirectory con il db di RADIUS. Questa soluzione supporta anche le cosiddette estensioni radius alla base di soluzioni complesse come la Self Defending Network.
Pur essendo una soluzione completa e sicuramente ottima, risulta costosa ed a volte esagerata per le esigenze comuni ma fortunatamente il mondo OSS ci aiuta con due ottimi prodotti come freeradius o openradius utilizzabili su piattaforma Linux.
Per windows possiamo utilizzare il prodotto commerciale WinRadius, disponibile anche in versione freeware ma limitatamenete a 5 utenti, o IAS di Microsoft basandoci sugli utenti del dominio AD.
Freeradius e Openradius possono basare la loro lista utenti su semplici file di testo o si possono appogiare ad un database MySQL che offre prestazioni decisamente superiori in ambienti con molti utenti.
Una semplice ricerca con google fornisce una miriade di risultati con tutorial e how-to per l’installazione e configurazione di un server radius. Giusto a titolo esemplificativo riporto le risposte di ottenute da un server radius, nello specifico è un server freeradius installato su piattaforma Linux, precisamente Fedora Core 4, che gira sotto WindowsXP per mezzo di un’emulazione attraverso VmWare Player, configurato per autenticare gli utenti con MySQL. Ecco la risposta ottenuta in caso di mismatch della shared secret tra nas e radius server:
[root@www ~]# radtest test test localhost 0 pippo
Sending Access-Request of id 35 to 127.0.0.1:1812
User-Name = "test"
User-Password = "test"
NAS-IP-Address = www.gllabs.tk
NAS-Port = 0
Re-sending Access-Request of id 35 to 127.0.0.1:1812
User-Name = "test"
User-Password = "\237[$\251\005\316\0147\241\352.X\356%\t\343"
NAS-IP-Address = www.gllabs.tk
NAS-Port = 0
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=35, length=20
rad_decode: Received Access-Reject packet from 127.0.0.1:1812 with invalid
signature (err=2)! (Shared secret is incorrect.)
Ecco, invece, la risposta in caso di login correttamente eseguito:
[root@www hjan]# radtest test test localhost 0 testing123
Sending Access-Request of id 139 to 127.0.0.1:1812
User-Name = "test"
User-Password = "test"
NAS-IP-Address = www.gllabs.tk
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=139, length=20
[root@www hjan]#
Local AAA
Analizziamo innanzitutto il processo di login base ad un router. Solitamente ci colleghiamo in console o via telnet al router e questi ci presenta il prompt dei comandi router>, siamo quindi in modalità non provilegiata percui possiamo eseguire un limitato numero di comandi e questi non hanno impatto sulle funzionalità del router. Ma la modalità privilegiata è ad un passo, con il comando ena viene richiesto l’inserimento di una password e quindi in caso match positivo viene mostrato il prompt router#, siamo quindi in modalità privilegiata e possiamo procedere anche con i comandi di configurazione. E’ chiaro che la debolezza del sistema è relativa alla password stessa, alla sua sicurezza intrinseca, ed al fatto che vi sia un’unica barriera. Chiaramente in sistemi di rete reali la soluzione consiste nell’utilizzo di access-list, permetteremo ad esempio il login telnet solo da una rete di management, in combinazione ad un ulteriore livello di autenticazione, una coppia login/password. Abilitando l’autorizzazione sui comandi, quali comandi posso eseguire e quali no e magari anche il supporto EAP/TLS per l’autenticazione con certificati digitali. Supponiamo di non avere ancora un radius server, ma di usare una specie di database utenti interno al router, vediamo il comando utile a crearlo:
username pippo password 7 105E00091518
In questo caso ho creato un utente locale al router, chiamato pippo e con password pippo. Adesso abilitiamo la parte di autenticazione ed applichiamola al login via telnet:
! aaa new-model aaa authentication login TEST-AAA-TELNET local ! line vty 0 4 login authentication TEST-AAA-TELNET !
La riga chiave è aaa authentication login TEST-AAA-TELNET local, con questa abilitiamo il servizio aaa per l’autenticazione del login, assegnamo un nome alla regola, nel nostro caso TEST-AAA-TELNET e diciamo di andare ad autenticare sul database interno, local. In questo modo abbiamo creato una regola per autenticare il login, non ci resta che applicarla, ed è quello che facciamo con il login authentication posto sotto line vty. Il risultato è che se noi proviamo a fare un telnet al nostro router, ci viene fornito un promt di questo tipo:
Username: Inserendo pippo Username:pippo Login: inserendo la pasword corretta Username:pippo Login: router>
Et voilà. Abbiamo autenticato il login via telnet. Ovviamente possiamo abbellire il tutto con un bel banner pre login , che so uno di quelli tipo:
************************** * Restricted Area * * Authorized Access Only * **************************
o simili, con il comando :
aaa authentication banner delimiter string delimiter
e impostare un messaggio per il fallimento del login con il comando:
aaa authentication fail-message delimiter string delimiter
Radius AAA
Vediamo ora come abilitare il radius:
aaa authentication login TEST-AAA-TELNET group radius local radius-server host 172.22.53.201 auth-port 1812 acct-port 1813 key cisco
La prima cosa che salta all’occhio è che c’è ancora il local, questo per garantire comunque un accesso alla macchina in caso di completo fallimento dei radius per problemi legati ai radius stessi o per problemi di raggiungibilità ad essi. Inutile dire che l’utenza locale dovrebbe essere il più sicuro possibile o quantomento un’utenza non standard, per capirci utilizzare “cisco cisco” come utenza locale potrebbe non essere una buona idea. Ma prima del local viene specificato di fare riferimento ad un radius server, che viene impostato con il comando successivo ( si intuisce come l’ordine sia importate! ). Nel comando successivo impostiamo l’ip del server radius, le porte su sui il server radius ascolta per l’autenticazione e per l’accounting, e la chiave.
La chiave spesso definita anche shared secret, stabilsce una stringa condivisa tra nas e radius server, utilizzata per autenticare la comunicazione nas – radius server.
Ecco fatto abbiamo finito, ora il nostro telnet è protetto con l’autenticazione su un radius remoto. Volendo possiamo impostare un timeout diverso da quello di default, 30 secondi, per il login con il comando:
timeout login response seconds | ex. timeout login response 5
In questo modo indichiamo al sistema di aspettare al massimo 5 secondi per l’input del login. Si può definire un gruppo di server radius:
aaa authentication login default group group1 aaa group server radius group1 server 1.1.1.1 auth-port 1645 acct-port 1646 server 2.2.2.2 auth-port 2000 acct-port 2001 radius-server host 1.1.1.1 auth-port 1645 acct-port 1646 radius-server host 2.2.2.2 auth-port 2000 acct-port 2001
Conlcusioni
Questo articolo voleva offrire una semplice panoramica su un argomento vasto e complesso quale è il controllo degli accessi e più in generale l’IOS Security. Ho saltato le parti riguardanti l’autorizzazione e l’accounting che verranno trattate in successive evoluzioni dell’articolo, del resto ho saltato pure la parte di configurazione di un radius server per non appesantire troppo questo documento.
Quindi ora non vi resta che installare un vostro radius server ed iniziare a giocare con un router ed un client di test. Cosa potete fare? Un sacco di cose ma se volete un’idea vi dico 802.1X…….e ora via dateci sotto, studiate un po’ anche voi! ;)
RFC e Links
RFC 2548
RFC 2809
RFC 2865
RFC 2866
RFC 2867
RFC 2868
RFC 2869
RFC 2882
RFC 3162
Attributi Radius http://www.freeradius.org/rfc/attributes.html
Cisco IOS Security Configuration http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html
