La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Identity Services Engine (ISE) versione 1.3 supporta una nuova API chiamata pxGrid. Questo protocollo moderno e flessibile che supporta l'autenticazione, la crittografia e i privilegi (gruppi) consente una facile integrazione con altre soluzioni di sicurezza. Questo documento descrive l'uso dell'applicazione pxLog scritta come prova del concetto. pxLog è in grado di ricevere messaggi syslog da Intrusion Prevention System (IPS) e inviare messaggi pxGrid all'ISE per mettere in quarantena l'aggressore. Di conseguenza, ISE utilizza RADIUS Change of Authorization (CoA) per modificare lo stato di autorizzazione dell'endpoint che limita l'accesso alla rete. Tutto questo avviene in modo trasparente per l'utente finale.
Per questo esempio, come IPS è stato utilizzato Snort, ma è possibile utilizzare qualsiasi altra soluzione. In realtà non deve essere un IPS. è sufficiente inviare il messaggio syslog a pxLog con l'indirizzo IP dell'autore dell'attacco. Questo crea la possibilità di integrare un gran numero di soluzioni.
Questo documento illustra anche come risolvere i problemi e testare le soluzioni pxGrid, con i problemi e le limitazioni tipici.
Avvertenza: l'applicazione pxLog non è supportata da Cisco. Questo articolo è stato scritto come prova di concetto. Lo scopo principale era quello di usarlo durante il test migliore dell'implementazione di pxGrid sull'ISE.
Cisco raccomanda la conoscenza della configurazione di Cisco ISE e delle conoscenze base su questi argomenti:
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Di seguito è riportato il flusso del traffico, come mostrato nello schema della rete:
La soluzione consiste nell'installare un set di applicazioni su un computer Linux:
L'applicazione pxLog utilizza le seguenti librerie:
Tutte queste librerie si trovano già nella directory lib del progetto, quindi non è necessario scaricare altri file Java ARchive (JAR).
Per installare l'applicazione:
Questo articolo non si concentra su alcun IPS specifico, e per questo motivo viene fornita solo una breve spiegazione.
Lo snort è configurato come inline con il supporto DAQ. Il traffico viene reindirizzato con iptables:
iptables -I FORWARD -j ACCEPT
iptables -I FORWARD -j NFQUEUE --queue-num 1
Quindi, dopo l'ispezione, viene iniettato e inoltrato secondo le regole di fattibilità predefinite.
Sono state configurate alcune regole di snort personalizzate (il file /etc/snort/rules/test.rules è incluso nella configurazione globale).
alert icmp any any -> any any (itype:8; dsize:666<>686; sid:100122)
alert icmp any any -> any any (itype:8; ttl: 6; sid:100124)
Snort invia un messaggio syslog quando il valore TTL (Time To Live) del pacchetto è uguale a 6 o le dimensioni del payload sono comprese tra 666 e 686. Il traffico non è bloccato da Snort.
È inoltre necessario impostare delle soglie per garantire che gli allarmi non siano attivati troppo spesso (/etc/snort/threshold.conf):
event_filter gen_id 1, sig_id 100122, type limit, track by_src, count 1, seconds 60
event_filter gen_id 1, sig_id 100124, type limit, track by_src, count 1, seconds 60
Il server syslog punta quindi al computer pxLog (/etc/snort/snort.conf):
output alert_syslog: host=10.222.0.61:514, LOG_AUTH LOG_ALER
Per alcune versioni di Snort, ci sono bug relativi alla configurazione syslog, quindi è possibile usare le impostazioni predefinite che puntano a localhost e syslog-ng può essere configurato per inoltrare messaggi specifici all'host pxLog.
EPS deve essere abilitato (disabilitato per impostazione predefinita) da Amministrazione > Impostazioni:
In questo modo è possibile utilizzare la funzionalità di quarantena/rimozione della quarantena.
La prima regola viene rilevata solo quando l'endpoint viene messo in quarantena. L'accesso limitato viene quindi applicato in modo dinamico dalla CoA RADIUS. Inoltre, lo switch deve essere aggiunto ai dispositivi di rete con il segreto condiviso corretto.
Lo stato di pxGrid può essere verificato dalla CLI:
lise/admin# show application status ise
ISE PROCESS NAME STATE PROCESS ID
--------------------------------------------------------------------
Database Listener running 6717
Database Server running 51 PROCESSES
Application Server running 9486
Profiler Database running 7804
AD Connector running 10058
M&T Session Database running 7718
M&T Log Collector running 9752
M&T Log Processor running 9712
Certificate Authority Service running 9663
pxGrid Infrastructure Service running 14979
pxGrid Publisher Subscriber Service running 15281
pxGrid Connection Manager running 15248
pxGrid Controller running 15089
Identity Mapping Service running 9962
Sono inoltre disponibili debug separati per pxGrid (Amministrazione > Registrazione > Configurazione registro di debug > pxGrid). I file di debug sono memorizzati nella directory pxGrid. I dati più importanti si trovano nei siti pxgrid/pxgrid-jabberd.log e pxgrid/pxgrid-controller.log.
L'applicazione pxLog viene distribuita automaticamente all'avvio di Tomcat.
pxLog deve elaborare i messaggi syslog ed eseguire le azioni in base ad essi. Per aggiungere una nuova regola, selezionare Gestisci regole:
Ora il modulo enforcer cerca questa espressione regolare (RegExp) nel messaggio syslog: "snort[". Se individuato, esegue la ricerca in tutti gli indirizzi IP e seleziona quello precedente all'ultimo. Questa funzionalità è in grado di soddisfare la maggior parte delle soluzioni di sicurezza. Per ulteriori informazioni, consultare la sezione Syslog. L'indirizzo IP (utente non autorizzato) è in quarantena tramite pxGrid. È inoltre possibile utilizzare una regola più granulare, ad esempio il numero della firma.
La stazione di Microsoft Windows 7 avvia una sessione dot1x cablata. Cisco Anyconnect NAM è stato usato come supplicant. Il metodo EAP (Extensible Authentication Protocol-Protected EAP) è configurato.
Viene selezionato il profilo di autorizzazione ISE Dot1x Full Access. Lo switch scarica l'elenco degli accessi per concedere l'accesso completo:
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ALL-53fc9dbe
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E6BAB267CF
Acct Session ID: 0x00003A70
Handle: 0xA100080E
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit ip any any
Questo comando mostra ciò che accade se si invia da un pacchetto Microsoft Windows con TTL = 7:
c:\> ping 10.222.0.61 -i 7 -n 1
Tale valore viene diminuito su Snort nella catena di inoltro e viene generato un allarme. Di conseguenza, viene inviato un messaggio syslog verso pxLog:
Sep 6 22:10:31 snort snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 ->
10.222.0.61
Il pxLog riceve il messaggio syslog, lo elabora e richiede di mettere in quarantena l'indirizzo IP. È possibile verificare questa condizione controllando i registri:
L'ISE riporta che l'indirizzo IP è stato messo in quarantena:
Di conseguenza, rivede il criterio di autorizzazione, sceglie la quarantena e invia RADIUS CoA per aggiornare lo stato di autorizzazione sullo switch per l'endpoint specifico.
Questo è il messaggio di terminazione CoA che forza il supplicant ad avviare una nuova sessione e ottenere un accesso limitato (Permit_ICMP):
Il risultato può essere confermato sullo switch (accesso limitato per l'endpoint):
3750#show authentication sessions interface g0/17
Interface: GigabitEthernet0/17
MAC Address: 0050.b611.ed31
IP Address: 10.221.0.240
User-Name: cisco
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
ACS ACL: xACSACLx-IP-PERMIT_ICMP-53fc9dc5
Session timeout: N/A
Idle timeout: N/A
Common Session ID: 0A01000C000037E7BAB7D68C
Acct Session ID: 0x00003A71
Handle: 0xE000080F
Runnable methods list:
Method State
dot1x Authc Success
3750#show ip access-lists interface g0/17
permit icmp any any
In questa fase, l'amministratore decide di riattivare la quarantena per l'endpoint:
La stessa operazione può essere eseguita direttamente dall'ISE:
L'ISE riesamina le regole e aggiorna lo stato di autorizzazione sullo switch (viene concesso l'accesso completo alla rete):
La relazione conferma che:
L'applicazione pxLog è stata scritta per dimostrare la funzionalità dell'API pxGrid. Consente di:
Nuove funzionalità sono previste per il futuro.
Ecco alcuni screenshot di esempio da pxLog:
Il client (utente) può essere membro di un gruppo alla volta. I due gruppi più utilizzati sono:
Come accennato in precedenza, entrambe le applicazioni client, pxLog e pxGrid Controller (ISE), devono avere certificati configurati per comunicare. L'applicazione pxLog conserva quelle nei file Java KeyStore:
I file sono protetti da password (impostazione predefinita: cisco123). La posizione e le password dei file possono essere modificate in WEB-INF/web.xml.
Ecco i passaggi per generare un nuovo Java KeyStore:
pxgrid store # keytool -import -alias ca -keystore root.jks -file cert-ca.der
pxgrid store # keytool -import -alias mnt -keystore root.jks -file cert-mnt.der
pxgrid store # keytool -import -alias ca -keystore client.jks -file cert-ca.der
pxgrid store # keytool -genkey -alias clientcert -keyalg RSA -keystore client.jks -
keysize 2048
pxgrid store # keytool -certreq -alias clientcert -keystore client.jks -
file cert-client.csr
pxgrid store # keytool -import -alias clientcert -keystore client.jks -file cert-
client.der
pxgrid store # keytool -list -v -keystore client.jks
pxgrid store # keytool -list -v -keystore root.jks
Attenzione: quando il nodo ISE 1.3 viene aggiornato, è possibile mantenere il certificato di identità, ma la firma dell'autorità di certificazione viene rimossa. Di conseguenza, l'ISE aggiornato utilizza un nuovo certificato ma non allega mai il certificato CA nel messaggio SSL/ServerHello. In questo modo viene attivato il guasto sul client che si aspetta (in base alla RFC) di vedere una catena completa.
L'API pxGrid per diverse funzioni (come il download della sessione) esegue una convalida aggiuntiva. Il client contatta l'ISE e riceve il nome host ISE, definito dal comando hostname nella CLI. Il client tenta quindi di eseguire la risoluzione DNS per il nome host e di contattare e recuperare i dati da tale indirizzo IP. Se la risoluzione DNS per il nome host ISE ha esito negativo, il client non tenterà di ottenere alcun dato.
Attenzione: si noti che per questa risoluzione viene utilizzato solo il nome host, indicato in questo scenario, e non il nome di dominio completo (FQDN), ovvero lise.example.com in questo scenario.
Cisco pubblica e supporta l'API pxGrid. Esiste un pacchetto con il nome seguente:
pxgrid-sdk-1.0.0-167
All'interno ci sono:
Di seguito è riportato l'elenco delle soluzioni di sicurezza che inviano messaggi syslog con l'indirizzo IP dell'autore dell'attacco. Questi possono essere facilmente integrati con pxLog a condizione che si utilizzi la regola RegExp corretta nella configurazione.
Snort invia gli allarmi syslog nel seguente formato:
host[id] [sig_gen, sig_id, sig_sub] [action] [msg] [proto] [src] [dst]
Di seguito è riportato un esempio:
snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 -> 10.222.0.61
L'indirizzo IP dell'autore dell'attacco è sempre il secondo prima dell'ultimo (destinazione). È semplice creare un RegExp granulare per una firma specifica ed estrarre l'indirizzo IP dell'autore dell'attacco. Di seguito è riportato un esempio di RegExp per la firma 100124 e il messaggio ICMP (Internet Control Message Protocol):
snort[\.*:100124:.*ICMP.*
Quando l'ASA è configurata per l'ispezione HTTP (esempio), il messaggio syslog corrispondente ha il seguente aspetto:
Mar 12 2014 14:36:20: %ASA-5-415006: HTTP - matched Class 23:
MS13-025_class in policy-map MS_Mar_2013_policy, URI matched -
Dropping connection from inside:192.168.60.88/2135 to
outside:192.0.2.63/80
Anche in questo caso si potrebbe usare un RegExp granulare per filtrare questi messaggi ed estrarre l'indirizzo IP dell'utente malintenzionato, il secondo prima dell'ultimo.
Di seguito è riportato un esempio di messaggio inviato dal sensore Sourcefire:
Jan 28 19:46:19 IDS01 SFIMS: [CA IDS][Policy1][119:15:1] http_inspect: OVERSIZE
REQUEST-URI DIRECTORY [Classification: Potentially Bad Traffic] [Priority: 2]
{TCP} 10.12.253.47:55504 -> 10.15.224.60:80
Di nuovo, è semplice estrarre l'indirizzo IP dell'utente malintenzionato perché vale la stessa logica. Vengono inoltre forniti il nome del criterio e la firma, in modo che la regola pxLog possa essere granulare.
Di seguito è riportato un messaggio di esempio inviato dal precedente Juniper Intrusion Detection & Prevention (IDP):
dayId="20061012" recordId="0" timeRecv="2006/10/12
21:52:21" timeGen="2006/10/12 21:52:21" domain="" devDomVer2="0"
device_ip="10.209.83.4" cat="Predefined" attack="TROJAN:SUBSEVEN:SCAN"
srcZn="NULL" srcIntf="NULL" srcAddr="192.168.170.20" srcPort="63396"
natSrcAddr="NULL" natSrcPort="0" dstZn="NULL" dstIntf="NULL"
dstAddr="192.168.170.10" dstPort="27374" natDstAddr="NULL" natDstPort="0"
protocol="TCP" ruleDomain="" ruleVer="5" policy="Policy2" rulebase="IDS"
ruleNo="4" action="NONE" severity="LOW" alert="no" elaspedTime="0" inbytes="0"
outbytes="0" totBytes="0" inPak="0" outPak="0" totPak="0" repCount="0"
packetData="no" varEnum="31" misc="<017>'interface=eth2" user="NULL"
app="NULL" uri="NULL"
L'indirizzo IP dell'autore dell'attacco può essere estratto allo stesso modo.
JunOS è simile:
Jul 16 10:09:39 JuniperJunOS: asp[8265]:
ASP_IDS_TCP_SYN_ATTACK: asp 3: proto 6 (TCP),
ge-0/0/1.0 10.60.0.123:2280 -> 192.168.1.12:80, TCP
SYN flood attack
Di seguito sono riportati alcuni esempi di iptable Linux.
Jun 15 23:37:33 netfilter kernel: Inbound IN=lo OUT=
MAC=00:13:d3:38:b6:e4:00:01:5c:22:9b:c2:08:00 src=10.0.0.1 DST=10.0.0.100 LEN=60
TOS=0x10 PREC=0x00 TTL=64 ID=47312 DF PROTO=TCP SPT=40945 DPT=3003 WINDOW=32767
RES=0x00 SYN URGP=0
È possibile inviare informazioni syslog per qualsiasi tipo di pacchetto con le funzionalità avanzate fornite dai moduli iptable, quali il rilevamento delle connessioni, xtables, rpfilters, il pattern matching e così via.
Di seguito è riportato un messaggio di esempio per bloccare i frammenti IPFW:
Sep 7 15:03:14 delta ipfw: 11400 Deny UDP 10.61.216.50 10.81.199.2 in via fxp0
(frag 52639:519@1480)
L'ISE è in grado di riconoscere il tipo di sessioni in termini di gestione del CoA.
Il modulo EPS è semplice. Quando esegue una quarantena, invia sempre un pacchetto di terminazione CoA. Per le sessioni cablate/wireless, non è un problema (tutti i supplicant 802.1x sono in grado di avviare in modo trasparente una seconda sessione EAP). Tuttavia, quando l'ASA riceve il messaggio di terminazione del CoA, interrompe la sessione VPN e l'utente finale riceve questa notifica:
Per forzare la riconnessione automatica della VPN AnyConnect (configurata nel profilo XML), è possibile procedere in due modi:
Anche quando la nuova sessione è stabilita, l'ASA sceglie il nuovo ID della sessione di revisione. Dal punto di vista di ISE, questa è una nuova sessione e non c'è alcuna possibilità di rilevare la regola di quarantena. Anche per le VPN, non è possibile usare l'indirizzo MAC dell'endpoint come identità, a differenza del punto1x cablato/wireless.
La soluzione è costringere l'EPS a comportarsi come l'ISE e inviare il corretto tipo di CoA in base alla sessione. Questa funzionalità sarà introdotta in ISE versione 1.3.1.
Di seguito è riportato un elenco di partner e soluzioni pxGrid:
Ecco altri partner e soluzioni:
Per l'elenco completo delle soluzioni di sicurezza, consultare il Catalogo delle soluzioni Marketplace.
Su ISE versione 1.3 sono disponibili tre tipi di API.
Di seguito è riportato un confronto:
RIPOSO | RESTful esterno | pxGrid | |
---|---|---|---|
Autenticazione client | username + password (autenticazione HTTP di base) |
username + password (autenticazione HTTP di base) |
certificato |
Separazione dei privilegi | no |
limitato (Amministratore ERS) |
yes (Gruppi) |
Accesso | Mnt | Mnt | Mnt |
Trasporto | tcp/443 (HTTPS) | tcp/9060 (HTTPS) | tcp/5222 (XMPP) |
Metodo HTTP | OTTIENI | GET/POST/PUT | OTTIENI/POST |
Attivato per impostazione predefinita | sì | no | no |
Numero di operazioni | pochi | molti | pochi |
Terminazione CoA | supportato | no | supportato |
Riautenticazione CoA | supportato | no | supportato * |
Operazioni utente | no | sì | no |
Operazioni sugli endpoint | no | sì | no |
Operazioni del gruppo di identità degli endpoint | no | sì | no |
Quarantena (IP, MAC) | no | no | sì |
Rimuovi quarantena (IP, MAC) | no | no | sì |
PortBounce/Shutdown | no | no | sì |
Operazioni utente guest | no | sì | no |
Operazioni del portale guest | no | sì | no |
Operazioni con i dispositivi di rete | no | sì | no |
Operazioni per gruppi di dispositivi di rete | no | sì | no |
* Quarantine utilizza il supporto CoA unificato di ISE versione 1.3.1.
pxLog può essere scaricato da Sourceforge.
Software Development Kit (SDK) già incluso. Per la documentazione più recente su SDK e API per pxGrid, contattare il partner o il team Cisco che gestisce gli account.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
23-Dec-2014 |
Versione iniziale |