Cisco Applied Mitigation Bulletin-
Questo bollettino sulla mitigazione applicata è un documento complementare all'advisory della sicurezza PSIRT relativo alle vulnerabilità della convalida dell'input delle chiamate di sistema del kernel locale di Cisco Unified IP Phone e fornisce tecniche di identificazione e mitigazione che gli amministratori possono distribuire sui dispositivi di rete Cisco.
-
I Cisco Unified IP Phone serie 7900, noti anche come telefoni TCP Cisco, contengono una vulnerabilità di convalida dell'input. Questa vulnerabilità è dovuta a un errore di convalida dell'input passato correttamente alle chiamate di sistema del kernel da applicazioni in esecuzione nello spazio utente. Un attacco di questo tipo avrebbe avuto origine in un contesto non privilegiato. L'utente non autorizzato potrebbe risolvere il problema ottenendo l'accesso locale tramite la porta AUX situata sulla parte posteriore del dispositivo oppure eseguendo l'autenticazione al dispositivo tramite SSH ed eseguendo un file binario controllato dall'utente non autorizzato progettato per risolvere il problema. Per impostazione predefinita, il metodo SSH viene disabilitato sul dispositivo dopo il provisioning eseguito da Cisco Unified Call Manager.
I vettori di attacco per l'utilizzo sono attraverso la console locale e i pacchetti che utilizzano i seguenti protocolli e porte:
- SSH con porta TCP 2
- TFTP che utilizza porte UDP casuali superiori a 1023
A questa vulnerabilità è stato assegnato l'identificatore CVE (Common Vulnerabilities and Exposures) CVE-2012-5445.
-
Le informazioni sul software vulnerabile, non interessato e fisso sono disponibili in Cisco Security Advisory, al seguente collegamento: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130109-uipphone.
-
I dispositivi Cisco forniscono diverse contromisure per questa vulnerabilità. Si consiglia agli amministratori di considerare questi metodi di protezione come best practice generali per la sicurezza dei dispositivi dell'infrastruttura e del traffico che attraversa la rete. In questa sezione del documento viene fornita una panoramica di queste tecniche.
Il processo di valutazione e riduzione dei rischi di un'organizzazione può considerare i seguenti aspetti della vulnerabilità descritti nel presente documento:- Per completare l'autenticazione SSH, occorre usare la rete o la porta AUX sul pannello posteriore del dispositivo.
- SSH viene disabilitato dopo il provisioning di Cisco Unified IP Phone.
- Dopo l'autenticazione al telefono, l'autore dell'attacco deve tentare di forzare il telefono a scaricare un file binario non firmato dannoso effettuando lo spoofing dell'indirizzo IP del server TFTP legittimo.
- Cisco Unified Communications Manager 8.0.1 e versioni successive firmano i file di configurazione inviati ai telefoni tramite TFTP per impostazione predefinita e supporta la sicurezza della crittografia dei file di configurazione telefonica. La firma e la crittografia dei file di configurazione del dispositivo impediscono la manomissione o la sostituzione dei file mediante lo spoofing di un server TFTP o di una risposta del server, in quanto la firma crittografica viene verificata prima che i file vengano utilizzati da un dispositivo.
Cisco Unified Communications Manager può fornire un'efficace prevenzione degli attacchi tramite i seguenti metodi:
- Disabilitare il server Cisco Unified IP Phone SSH
- Configurare i file di configurazione del telefono crittografato
Questi meccanismi di protezione impediscono l'accesso alla console e verificano l'integrità e la validità dei file di configurazione che si stanno tentando di eseguire sui telefoni.
Il software Cisco IOS può fornire mezzi efficaci di prevenzione degli attacchi utilizzando i seguenti metodi:
- iACL (Infrastructure Access List)
- VLAN Access List (vACL)
- uRPF (Unicast Reverse Path Forwarding)
- Snooping DHCP
- DAI (Dynamic ARP Inspection)
- Protezione origine IP
- 802.1x
Questi meccanismi di protezione filtrano e rilasciano, oltre a verificare gli indirizzi MAC e IP di origine dei pacchetti che stanno tentando di sfruttare questa vulnerabilità.
L'installazione e la configurazione corrette di uRPF forniscono un mezzo efficace di protezione dagli attacchi che utilizzano pacchetti con indirizzi IP di origine oggetto di spoofing. uRPF deve essere distribuito il più vicino possibile a tutte le origini di traffico.
La corretta installazione e configurazione di DAI fornisce un mezzo efficace di protezione dagli attacchi di spoofing al layer 2. La distribuzione di DAI richiede l'implementazione dello snooping DHCP. DAI eliminerà tutti i pacchetti ARP con binding di indirizzi IP-MAC non validi.
La corretta installazione e configurazione di IPSG fornisce un mezzo efficace di protezione dagli attacchi di spoofing a livello di accesso
Mezzi efficaci per prevenire gli attacchi possono essere forniti anche da Cisco ASA serie 5500 Adaptive Security Appliance, Cisco Catalyst serie 6500 ASA Services Module (ASASM) e Firewall Services Module (FWSM) per gli switch Cisco Catalyst serie 6500 e i router Cisco serie 7600, usando quanto segue:
- Access Control List (tACL) transit
- uRPF (Unicast Reverse Path Forwarding)
Questi meccanismi di protezione filtrano e rilasciano, oltre a verificare l'indirizzo IP di origine dei pacchetti che stanno tentando di sfruttare questa vulnerabilità.
-
Le organizzazioni sono invitate a seguire i processi standard di valutazione e mitigazione dei rischi per determinare l'impatto potenziale di questa vulnerabilità. Triage si riferisce all'ordinamento dei progetti e all'assegnazione delle priorità agli sforzi che hanno maggiori probabilità di avere successo. Cisco ha fornito documenti che possono aiutare le organizzazioni a sviluppare una funzionalità di triage basata sui rischi per i team addetti alla sicurezza delle informazioni. Valutazione dei rischi per la vulnerabilità della sicurezza Gli annunci e la valutazione dei rischi e la creazione di prototipi possono aiutare le organizzazioni a sviluppare processi ripetibili di valutazione della sicurezza e di risposta.
-
Attenzione: l'efficacia di qualsiasi tecnica di mitigazione dipende dalle situazioni specifiche del cliente, come il mix di prodotti, la topologia di rete, il comportamento del traffico e la missione organizzativa. Come per qualsiasi modifica apportata alla configurazione, valutare l'impatto della configurazione prima di applicare la modifica.
Per questi dispositivi sono disponibili informazioni specifiche sulla mitigazione e l'identificazione:
- Cisco Unified Communications Manager
- Router e switch Cisco IOS
- Cisco IOS NetFlow e Cisco IOS Flexible NetFlow
- Cisco ASA, Cisco ASASM e Cisco FWSM Firewall
- Cisco Security Manager
Cisco Unified Communications Manager
La protezione dei componenti in un sistema di comunicazione unificato Cisco è necessaria per proteggere l'integrità e la riservatezza delle chiamate vocali. Per aiutare gli amministratori a proteggere meglio i sistemi Cisco Unified Communications, sono disponibili linee guida relative alla sicurezza specifiche della tecnologia Unified Communications e della rete vocale. Queste risorse delle linee guida sulla sicurezza includono:
- Cisco Unified Communications System 9.x SRND - Sicurezza delle comunicazioni unificate
- Guida alla sicurezza di Cisco Unified Communications Manager, versione 8.6(1)
- Certificati per telefoni IP e comunicazioni sicure Cisco
Impostazioni specifiche sono disponibili in Cisco Unified Communications Manager per ridurre la vulnerabilità descritta in questo documento. Le impostazioni sono descritte di seguito.
Attenuazione: disabilitare la porta PC per Cisco Unified IP Phone
Per impedire l'accesso non autorizzato alla rete dell'organizzazione, si consiglia agli amministratori di disabilitare la porta PC nella hall, nella sala conferenze e in altri telefoni Cisco Unified IP fisicamente non protetti. Per disabilitare la porta del PC, gli amministratori possono effettuare le seguenti operazioni:
Passaggio 1: Nell'interfaccia di amministrazione di Cisco Unified Communications Manager, scegliere Dispositivo > Telefono
Passaggio 2: Elencare i telefoni con la porta PC disabilitata usando i criteri di ricerca appropriati e selezionare Find
Passaggio 3: Selezionare il nome del dispositivo per aprire la finestra Configurazione telefono
Passaggio 4: Individuare il parametro specifico del prodotto relativo alla porta PC
Passaggio 5: selezionare Disabilitato dall'elenco a discesa per il parametro Porta PC
Passaggio 6: Selezionare Salva
Passaggio 7: Selezionare Reset
Per ulteriori informazioni sulla disabilitazione della porta PC sui Cisco Unified IP Phone, consultare la sezione Disabilitazione delle impostazioni della porta PC nel documento Cisco Unified Communications Manager Security Guide.
Attenuazione: disabilitare il server SSH Cisco Unified IP Phone
Per impostazione predefinita, il server Cisco Unified IP Phone SSH è disabilitato. Questa impostazione deve essere verificata per evitare tentativi di accesso remoto per sfruttare la vulnerabilità descritta in questo documento. Per verificare l'impostazione, gli amministratori possono effettuare le seguenti operazioni:
Passaggio 1: Nell'interfaccia di amministrazione di Cisco Unified Communications Manager, scegliere Dispositivo > Telefono
Passaggio 2: Elencare i telefoni da verificare utilizzando i criteri di ricerca appropriati e selezionare Trova
Passaggio 3: Selezionare il nome del dispositivo per aprire la finestra Configurazione telefono
Fase 4: Individuare il parametro specifico del prodotto di Access SSH
Passaggio 5: Verificare che Disabled sia selezionato nell'elenco a discesa del parametro SSH Access
Per ulteriori informazioni sulla disabilitazione del server SSH sui Cisco Unified IP Phone, consultare la sezione Abilitazione e disabilitazione del protocollo SSH nel documento Cisco Unified IP Phone 8961, 9951 e 9971 Administration Guide for Cisco Unified Communications Manager.
Attenuazione: configurazione dei file di configurazione dei telefoni crittografati
Per garantire la privacy, gli amministratori devono configurare la crittografia del file di configurazione di Cisco Unified IP Phone. I file di configurazione vengono scaricati dal server TFTP Unified Communications Manager. La configurazione della crittografia consente inoltre di ridurre la vulnerabilità descritta in questo documento, in quanto eventuali file di configurazione non crittografati, con firma digitale e ricevuti da una fonte autenticata verranno ignorati e eliminati.
Per impostazione predefinita, il software Cisco Unified Communications Manager versione 8.0(1) e successive consente di firmare i file di configurazione del telefono e supporta la crittografia dei file di configurazione del telefono. Per ulteriori informazioni sulle funzionalità di sicurezza predefinite, vedere la sezione Security by Default del documento Cisco Unified Communications Manager Security Guide.
La procedura per configurare i file di configurazione del telefono crittografato è illustrata in dettaglio nell'elenco di controllo per la configurazione dei file di configurazione della crittografia. Per ulteriori informazioni sui file di configurazione telefonica crittografati, vedere le sezioni Configurazione di file di configurazione telefonica crittografati e Configurazione di un profilo di sicurezza telefonica nel documento Cisco Unified Communications Manager Security Guide.
Per verificare i file di configurazione dei telefoni crittografati, gli amministratori possono eseguire le operazioni seguenti:
Passaggio 1: nell'interfaccia di amministrazione di Cisco Unified Communications Manager, selezionare Sistema > Profilo sicurezza > Profilo sicurezza telefono
Passaggio 2: immettere i criteri di ricerca per individuare il record appropriato nel database e selezionare Trova
Passaggio 3: Selezionare il record da esaminare
Passaggio 4: Individuare il parametro del profilo di sicurezza della configurazione crittografata TFTP
Passaggio 5: verificare che la casella di controllo per il parametro TFTP Encrypted Config sia selezionata
Router e switch Cisco IOS
Mitigazione: Access Control List Dell'Infrastruttura
Per proteggere i dispositivi dell'infrastruttura e ridurre al minimo i rischi, l'impatto e l'efficacia degli attacchi diretti all'infrastruttura, gli amministratori devono implementare gli iACL (Access Control List) dell'infrastruttura per applicare le policy relative al traffico inviato ai dispositivi dell'infrastruttura. Gli amministratori possono costruire un iACL autorizzando esplicitamente solo il traffico autorizzato inviato ai dispositivi dell'infrastruttura in base alle configurazioni e ai criteri di sicurezza esistenti. Per garantire la massima protezione dei dispositivi dell'infrastruttura, gli iACL installati devono essere applicati in entrata su tutte le interfacce su cui è stato configurato un indirizzo IP. Una soluzione iACL non può fornire una protezione completa da questa vulnerabilità quando l'attacco proviene da un indirizzo di origine attendibile.
La tecnologia VLAN Cisco separa la rete fisica in più reti logiche. Si consigliano VLAN voce e dati separate per i seguenti motivi:
- Risparmio dello spazio e protezione dei dispositivi vocali dalle reti esterne L'indirizzamento privato dei telefoni sulla voce o sulla VLAN ausiliaria assicura la conservazione degli indirizzi e che i telefoni non siano accessibili direttamente tramite reti pubbliche. I PC e i server vengono in genere indirizzati con indirizzi di subnet instradati pubblicamente. Tuttavia, gli endpoint vocali possono essere indirizzati utilizzando gli indirizzi di subnet privata RFC 1918.
- Estensione dei limiti di attendibilità QoS (Quality of Service) ai dispositivi voce Gli switch Cisco possono rilevare i telefoni IP utilizzando il protocollo Cisco Discovery ed estendere automaticamente il trust QoS alla porta telefonica in modo dinamico.
- Protezione da attacchi di rete dannosi Il controllo degli accessi VLAN, il tagging 802.1Q e 802.1p può fornire protezione ai dispositivi voce da attacchi dannosi alla rete interna ed esterna, come worm, attacchi DoS (Denial of Service) e tentativi dei dispositivi dati di accedere alle code prioritarie tramite il tagging dei pacchetti.
- Facilità di gestione e configurazione Le VLAN separate per i dispositivi voce e dati a livello di accesso semplificano la gestione e la configurazione QoS.
Negli esempi di ACL seguenti, gli elenchi degli accessi Infrastructure-ACLdata-Policy e IPv6-Infrastructure-ACLdata-Policy negano i pacchetti SSH IPv4 e IPv6 non autorizzati sulla porta TCP 22 e i pacchetti TFTP IPv4 e IPv6 sulle porte UDP superiori a 1023 inviati dalla rete di dati ai dispositivi interessati sulla rete vocale. Gli elenchi degli accessi Infrastructure-ACLvoice-Policy e IPv6-Infrastructure-ACLvoice-Policy negano i pacchetti IPv4 e IPv6 RTP non autorizzati sulle porte UDP superiori a 1023 che possono essere inviati dai dispositivi interessati sulla rete voce alla rete dati nel tentativo di esfiltrare le comunicazioni vocali. Nell'esempio seguente, 192.168.60.0/24 e 2001:DB8:1:60::/64 rappresentano lo spazio di indirizzi IP utilizzato dai dispositivi interessati sulla rete voce e l'interfaccia Gigabit Ethernet0/0 è l'interfaccia rivolta verso il lato della rete dati di un router distribuito tra le reti dati e voce. L'interfaccia Gigabit Ethernet0/1 è l'interfaccia rivolta verso il lato della rete voce del router implementata tra le reti dati e voce. È necessario prestare attenzione a consentire il traffico richiesto per il routing e l'accesso amministrativo prima di rifiutare tutto il traffico non autorizzato. Ove possibile, lo spazio di indirizzi dell'infrastruttura deve essere distinto dallo spazio di indirizzi utilizzato per i segmenti di utenti e servizi. L'uso di questa metodologia di indirizzamento semplificherà la costruzione e l'implementazione degli iACL.
Per ulteriori informazioni sugli iACL, consultare il documento sulla protezione del core: Access Control List di protezione dell'infrastruttura.
ip access-list extended Infrastructure-ACLdata-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 22 permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny tcp any 192.168.60.0 0.0.0.255 eq 22 deny udp any 192.168.60.0 0.0.0.255 gt 1023 ! !-- Explicit deny ACE for traffic sent to addresses configured within !-- the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! ! !-- Create the corresponding IPv6 iACL ! ipv6 access-list IPv6-Infrastructure-ACLdata-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks to global and !-- link-local addresses ! deny tcp any 2001:DB8:1:60::/64 eq 22 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 ! !-- Permit other required traffic to the infrastructure address !-- range and allow IPv6 neighbor discovery packets, which !-- include neighbor solicitation packets and neighbor !-- advertisement packets ! permit icmp any any nd-ns permit icmp any any nd-na !
!-- Explicit deny for all other IPv6 traffic to the global !-- infrastructure address range !
deny ipv6 any 2001:DB8:1:60::/64 !
!-- Permit or deny all other Layer 3 and Layer 4 traffic !-- in accordance with existing security policies and configurations ! ! !-- Apply iACLs to interfaces in the ingress direction ! interface GigabitEthernet0/0 ip access-group Infrastructure-ACLdata-Policy in ipv6 traffic-filter IPv6-Infrastructure-ACLdata-Policy inip access-list extended Infrastructure-ACLvoice-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit udp 192.168.60.0 0 0.0.0.255 gt 1023 host 192.168.100.1 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny udp 192.168.60.0 0.0.0.255 gt 1023 any gt 1023 ! ! !-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! ! !-- Create the corresponding IPv6 iACL ! ipv6 access-list IPv6-Infrastructure-ACLvoice-Policy ! !-- Include explicit permit statements for trusted sources !-- that require access on the vulnerable protocols and ports !-- This includes softphones, web access to the phone (if allowed), !-- the Attendant Console or other applications communication end-points !-- that need access to the voice VLAN subnets ! permit udp 2001:DB8:60::/64 gt 1023 2001:DB8::100::1 gt 1023 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks to global and !-- link-local addresses ! deny udp 2001:DB8::60::/64 gt 1023 any gt 1023 ! !-- Permit other required traffic to the infrastructure address !-- range and allow IPv6 neighbor discovery packets, which !-- include neighbor solicitation packets and neighbor !-- advertisement packets ! permit icmp any any nd-ns permit icmp any any nd-na ! !-- Permit or deny all other Layer 3 and Layer 4 traffic !-- in accordance with existing security policies and configurations ! ! !-- Apply iACLs to interfaces in the ingress direction ! interface GigabitEthernet0/1 ip access-group Infrastructure-ACLvoice-Policy in ipv6 traffic-filter IPv6-Infrastructure-ACLvoice-Policy in
Identificazione: Access Control List dell'infrastruttura
Dopo che l'amministratore ha applicato l'iACL a un'interfaccia, il comando show ip access-lists restituisce il numero di pacchetti SSH sulla porta TCP 22 e di pacchetti TFTP sulle porte UDP superiori a 1023 che sono stati filtrati sulle interfacce a cui è applicato l'iACL. Gli amministratori devono esaminare i pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Di seguito è riportato un esempio di output per show ip access-lists Infrastructure-ACLdata-Policy:
router#show ip access-lists Infrastructure-ACLdata-Policy Extended IP access list Infrastructure-ACLdata-Policy 10 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 22 20 permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 30 deny tcp any 192.168.60.0 0.0.0.255 eq 22 (11 matches) 40 deny udp any gt 1023 192.168.60.0 0.0.0.255 gt 1023 (43 matches) 50 deny ip any 192.168.60.0 0.0.0.255
router#Nell'esempio precedente, l'elenco degli accessi Infrastructure-ACLdata-Policy ha scartato 11 pacchetti SSH sulla porta TCP 22 per la riga 30 della voce dell'elenco di controllo degli accessi (ACE) e 43 pacchetti TFTP sulle porte UDP superiori a 1023 per la riga 40 della voce dell'elenco di controllo degli accessi (ACE).
Dopo che l'amministratore ha applicato l'iACL a un'interfaccia, il comando show ipv6 access-list IPv6-Infrastructure-ACLdata-Policy identificherà il numero di pacchetti SSH sulla porta TCP 22 e di pacchetti TFTP sulle porte UDP superiori a 1023 filtrati sulle interfacce a cui è applicato l'iACL. Gli amministratori devono esaminare i pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Di seguito è riportato un output di esempio per show ip access-lists IPv6-Infrastructure-ACLdata-Policy:
router#show ipv6 access-list IPv6-Infrastructure-ACLdata-Policy IPv6 access list IPv6-Infrastructure-ACLdata-Policy permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 sequence 10 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 sequence 20 deny tcp any 2001:DB8:1:60::/64 eq 22 (1240 matches) sequence 30 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 (740 matches) sequence 40 permit icmp any any nd-ns sequence 50 permit icmp any any nd-na sequence 60 deny ipv6 any 2001:DB8:1:60::/64 sequence 70 router#Nell'esempio precedente, l'elenco degli accessi IPv6-Infrastructure-ACL-Policy ha eliminato i seguenti pacchetti ricevuti da un host o una rete non attendibile:
- 1240 pacchetti IPv6 SSH sulla porta TCP 22 per la linea ACE 30
- 740 pacchetti IPv6 TFTP su porte UDP superiori a 1023 per la linea ACE 40
Dopo che l'amministratore ha applicato l'iACL a un'interfaccia, il comando show ip access-lists restituisce il numero di pacchetti RTP sulle porte UDP superiori a 1023 che sono stati filtrati sulle interfacce a cui è applicato l'iACL. Gli amministratori devono esaminare i pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Di seguito è riportato un esempio di output per show ip access-lists Infrastructure-ACLvoice-Policy:
router#show ip access-lists Infrastructure-ACLvoice-Policy Extended IP access list Infrastructure-ACL-Policy 10 permit udp 192.168.60.0 0 0.0.0.255 gt 1023 host 192.168.100.1 gt 1023 20 deny udp 192.168.60.0 0.0.0.255 gt 1023 any gt 1023 (87 matches)
30 deny ip any 192.168.60.0 0.0.0.255
router#Nell'esempio precedente, l'elenco degli accessi Infrastructure-ACLvoice-Policy ha scartato 87 pacchetti RTP sulle porte UDP superiori a 1023 per la riga 20 della voce dell'elenco di controllo di accesso (ACE).
Dopo che l'amministratore ha applicato l'iACL a un'interfaccia, il comando show ipv6 access-lists identificherà il numero di pacchetti RTP sulle porte UDP superiori a 1023 filtrati sulle interfacce a cui è applicato l'iACL. Gli amministratori devono esaminare i pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Output di esempio per show ipv6 access-list IPv6-Infrastructure-ACLvoice-Policy:
router#show ipv6 access-list IPv6-Infrastructure-ACLvoice-Policy IPv6 access list IPv6-Infrastructure-ACLvoice-Policy permit udp 2001:DB8:60::/64 gt 1023 2001:DB8::100::1 gt 1023 sequence 10 deny udp 2001:DB8::60::/64 gt 1023 any gt 1023 (52 matches) sequence 20 permit icmp any any nd-ns sequence 30 permit icmp any any nd-na sequence 40 deny ipv6 any 2001:DB8:1:60::/64 sequence 50 router#Nell'esempio precedente, l'elenco degli accessi IPv6-Infrastructure-ACLvoice-Policy ha scartato 52 pacchetti RTP sulle porte UDP superiori a 1023 per la riga 20 della voce dell'elenco di controllo di accesso (ACE).
Per ulteriori informazioni sull'analisi degli incidenti tramite contatori ACE ed eventi syslog, consultare il white paper Identificazione degli incidenti tramite firewall e eventi syslog del router IOS Cisco Security.
Gli amministratori possono utilizzare Embedded Event Manager per fornire strumentazione quando vengono soddisfatte condizioni specifiche, ad esempio accessi al contatore ACE. Il white paper sulla sicurezza di Cisco Embedded Event Manager in a Security Context fornisce ulteriori dettagli su come utilizzare questa funzione.
Attenuazione: VACL (VLAN Access Control Lists)
Per proteggere la rete da tutti i pacchetti di bridging all'interno di una VLAN o instradati verso o da una VLAN, si consiglia di distribuire gli elenchi di controllo di accesso (VACL) VLAN per applicare le policy. Se si intende distribuire un VACL, è necessario verificare le porte necessarie per consentire il funzionamento dei telefoni con ogni applicazione utilizzata nella rete di telefonia IP. In genere, un VACL viene applicato alla VLAN usata dal telefono, in modo da consentire il controllo sulla porta di accesso. Gli amministratori possono costruire un VACL autorizzando esplicitamente solo il traffico autorizzato ad essere inserito in una VLAN o instradato verso o da una VLAN in conformità alle configurazioni e alle policy di sicurezza esistenti. Una soluzione VACL non può fornire una protezione completa contro le vulnerabilità che hanno un vettore di attacco di rete IPv4 quando l'attacco proviene da un indirizzo di origine attendibile.
Nota: i VACL sono diversi dagli ACL Cisco IOS tradizionali in quanto si applicano a tutti i pacchetti anziché solo ai pacchetti indirizzati. Oltre al traffico unicast, i VACL si applicano anche al traffico multicast e broadcast; questi tipi di pacchetti devono essere considerati nella configurazione VACL.
Il criterio VACL nega i pacchetti SSH non autorizzati sulla porta TCP 22 che vengono inviati ai dispositivi interessati all'interno della vlan vocale (come nel caso di un dispositivo compromesso che tenta di connettersi a un telefono SSH). Nell'esempio seguente, 192.168.60.0/24 è lo spazio di indirizzi IP utilizzato dai dispositivi interessati nella VLAN 60. È necessario prestare attenzione a consentire il traffico richiesto per il routing e l'accesso amministrativo prima di rifiutare tutto il traffico non autorizzato.
Per ulteriori informazioni sui VACL, consultare il capitolo Configurazione degli ACL delle porte e degli ACL delle VLAN nel documento della Guida alla configurazione software di Catalyst 6500 versione 12.2SXH e successive.
! !-- Create an access list policy that will be applied in a !-- VLAN access map that includes vulnerability-specific !-- access control entries (ACEs) that can aid in !-- identification of attacks ! ip access-list extended VACL-deny permit TCP any 192.168.60.0 0.0.0.255 eq 22 ! !-- Create an access list policy that will be applied !-- in a VLAN access map that permits all other !-- Layer 2 and Layer 3 traffic in accordance with !-- existing security polices and configurations. ! !-- Broadcast and multicast traffic must be accounted !-- for as well !-- !-- This access list policy could be implemented as an !-- explicit permit statement allowing all other IP traffic !-- as shown here ! ip access-list extended Permit-All permit ip any any ! !-- Define the VLAN access map that will be used to !-- perform policy enforcement (either permit or deny) !-- on the traffic matched by the previously defined !-- access control lists ! ! vlan access-map VACL 10 match ip address VACL-deny action drop ! vlan access-map VACL 20 match ip address Permit-All action forward ! !-- Apply the VACL policy to the VLAN or list of VLANs !-- to filter traffic (Note: The 'vlan-list' operator !-- is a single VLAN or comma separated list of VLANs) ! vlan filter VACL vlan-list 60 !
Nota: nell'esempio del VACL precedente, le voci dell'elenco di controllo di accesso (ACE) che corrispondono ai pacchetti di exploit potenziale con l'istruzione allow fanno sì che questi pacchetti vengano scartati dall'istruzione drop della mappa di accesso alla VLAN.
Identificazione: Access Control Lists VLAN
Dopo che l'amministratore ha applicato il VACL a una VLAN o a un elenco di VLAN, il comando show tcam interface vlan numero-interfaccia acl in ip identificherà il numero di pacchetti filtrati. Gli amministratori sono invitati a indagare sui pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Di seguito è riportato un esempio di output per show tcam interface vlan 60 acl in ip:
Nota: un amministratore può visualizzare altre statistiche di controllo dell'accesso usando il comando show tcam interface vlan vlan-interface-number acl in ip detail.
switch#show tcam interface vlan 60 acl in ip * Global Defaults shared Entries from Bank 0 Entries from Bank 1 deny tcp any 192.168.60.0 0.0.0.255 eq 22 (35 matches) permit ip any any (379 matches) switch#Nell'esempio precedente, le regole per i criteri VACL VACL hanno eliminato 35 pacchetti SSH sulla porta TCP 22.
Per ulteriori informazioni sull'analisi degli incidenti tramite i contatori ACE e gli eventi syslog, consultare il white paper Identificazione degli incidenti tramite firewall e eventi syslog del router IOS Operazioni Cisco Security Intelligence.
Gli amministratori possono utilizzare Embedded Event Manager per fornire strumentazione quando vengono soddisfatte condizioni specifiche, ad esempio accessi al contatore ACE. Il white paper sulla sicurezza di Cisco Embedded Event Manager in a Security Context fornisce ulteriori dettagli su come utilizzare questa funzione.
Attenuazione: protezione da spoofing
Gli amministratori possono utilizzare le seguenti protezioni contro lo spoofing per proteggere i dispositivi compromessi che tentano di eseguire lo spoofing del traffico del server TFTP.
Inoltro percorso inverso unicast
La vulnerabilità descritta in questo documento può essere sfruttata da pacchetti IP oggetto di spoofing. Gli amministratori possono distribuire e configurare Unicast Reverse Path Forwarding (uRPF) come meccanismo di protezione contro lo spoofing.
uRPF è configurato a livello di interfaccia ed è in grado di rilevare ed eliminare pacchetti che non dispongono di un indirizzo IP di origine verificabile. Gli amministratori non devono affidarsi a uRPF per fornire una protezione completa dallo spoofing, in quanto i pacchetti oggetto di spoofing possono entrare nella rete tramite un'interfaccia abilitata a uRPF se esiste una route di ritorno appropriata all'indirizzo IP di origine. Si consiglia agli amministratori di assicurarsi che durante la distribuzione di questa funzionalità sia configurata la modalità uRPF appropriata (libera o rigida), in quanto può bloccare il traffico legittimo che attraversa la rete. In un ambiente aziendale, è possibile abilitare uRPF sul perimetro Internet e sul livello di accesso interno sulle interfacce di layer 3 supportate dall'utente.
Identificazione: protezione da spoofing con inoltro percorso inverso unicast
Se l'uRPF è installato e configurato correttamente nell'infrastruttura di rete, gli amministratori possono utilizzare i comandi show cef type slot/port internal, show ip interface, show cef drop, show ip cef switching feature, e show ip traffic per identificare il numero di pacchetti scartati dall'uRPF.
Nota: a partire dal software Cisco IOS versione 12.4(20)T, il comando show ip cef switching è stato sostituito da show ip cef switching statistics feature.
Nota: il comando show | inizio comando regex e show | include i modificatori del comando regex vengono utilizzati negli esempi seguenti per ridurre al minimo la quantità di output che gli amministratori dovranno analizzare per visualizzare le informazioni desiderate. Per ulteriori informazioni sui modificatori di comandi, consultare le sezioni show command della guida di riferimento dei comandi di Cisco IOS Configuration Fundamentals.
router#show cef interface GigabitEthernet 0/0 internal | include drop ip verify: via=rx (allow default), acl=0, drop=18, sdrop=0 router#
Nota: show cef interface type slot/port internal è un comando nascosto che deve essere immesso completamente nell'interfaccia della riga di comando. Il completamento del comando non è disponibile.
router#show ip interface GigabitEthernet 0/0 | begin verify IP verify source reachable-via RX, allow default, allow self-ping 18 verification drops 0 suppressed verification drops router# router#show cef drop CEF Drop Statistics Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err RP 27 0 0 18 0 0 router#
router#show ip cef switching statistics feature IPv4 CEF input features:
Path Feature Drop Consume Punt Punt2Host Gave route
RP PAS uRPF 18 0 0 0 0
Total 18 0 0 0 0 -- CLI Output Truncated -- router# router#show ip traffic | include RPF 18 no route, 18 unicast RPF, 0 forced drop router#Nelle versioni precedenti, show cef interface Gigabit Ethernet 0/0 internal, show ip interface Gigabit Ethernet 0/0, show cef drop, show ip cef switching statistics feature, e show ip traffic example, uRPF ha scartato 18 pacchetti IP ricevuti a livello globale su tutte le interfacce con uRPF configurate a causa dell'impossibilità di verificare l'indirizzo di origine dei pacchetti IP all'interno della base di informazioni di inoltro di Cisco Express Forwarding.
Per ulteriori informazioni, consultare la guida alla funzionalità di inoltro percorso inverso unicast in modalità alloose.
Per ulteriori informazioni sulla configurazione e l'utilizzo di uRPF, consultare il white paper Understanding Unicast Reverse Path Forwarding (Informazioni sull'inoltro del percorso inverso Unicast) in Cisco Security.
Le funzionalità di mitigazione descritte in questo documento e usate contro un attacco di layer 2 sono lo snooping DHCP e la funzione DAI (Dynamic ARP Inspection). Si noti che la configurazione dello snooping DHCP è un prerequisito per configurare DAI.
Snooping DHCP
Lo snooping DHCP è una funzione di sicurezza che intercetta i messaggi DHCP che attraversano uno switch e blocca le offerte DHCP non attendibili. Lo snooping DHCP utilizza il concetto di porte attendibili e non attendibili. Le porte attendibili vengono in genere utilizzate per raggiungere i server DHCP o gli agenti di inoltro, mentre le porte non attendibili vengono utilizzate per la connessione ai client. Tutti i messaggi DHCP sono consentiti sulle porte attendibili, mentre solo i messaggi dei client DHCP sono accettati sulle porte non attendibili. Poiché né i server né gli agenti di inoltro devono connettersi a porte non attendibili, i messaggi server come DHCPOFFER, DHCPACK e DHCPNAK vengono eliminati dalle porte non attendibili. Inoltre, lo snooping DHCP crea e gestisce una tabella di binding da MAC a IP utilizzata per convalidare i pacchetti DHCP ricevuti da porte non attendibili. La tabella di binding dello snooping DHCP contiene l'indirizzo MAC, l'indirizzo IP, la durata del lease in secondi e le informazioni sulla porta VLAN per i client DHCP sulle porte non attendibili di uno switch. Le informazioni contenute in una tabella di binding dello snooping DHCP vengono rimosse dalla tabella di binding alla scadenza del lease o lo snooping DHCP viene disabilitato nella VLAN.
Usare il comando show ip dhcp snooping per visualizzare le impostazioni dello snooping DHCP e il comando show ip dhcp snooping binding per visualizzare le voci di binding corrispondenti alle porte non attendibili.
Per ulteriori informazioni sulla distribuzione e la configurazione dello snooping DHCP, consultare il documento sulla configurazione delle funzionalità DHCP e della protezione dell'origine IP.
DAI (Dynamic ARP Inspection)
La corretta installazione e configurazione di DAI fornisce un mezzo efficace di protezione dagli attacchi di spoofing al layer 2. La distribuzione di DAI richiede l'implementazione dello snooping DHCP. DAI eliminerà tutti i pacchetti ARP con binding IP-MAC non validi che non superano l'ispezione.
DAI si basa sulle voci nel database di binding dello snooping DHCP per verificare i binding degli indirizzi IP-MAC. Configurare ciascuna interfaccia protetta come attendibile utilizzando il comando di configurazione dell'interfaccia di trust dell'ispezione ip arp. Le interfacce attendibili ignorano i controlli di convalida dell'ispezione ARP e tutti gli altri pacchetti sono soggetti a ispezione quando arrivano su interfacce non attendibili. Nell'esempio seguente viene mostrato come configurare un'interfaccia come attendibile e come abilitare DAI per le VLAN da 5 a 10.
Esempio di configurazione DAI:
Switch(config)#interface GigabitEthernet 1/0/1 Switch(config-if)#ip arp inspection trust Switch(config)#ip arp inspection vlan 5-10
Protezione origine IP
IPSG (IP Source Guard) è una funzione di sicurezza che limita il traffico IP su interfacce di livello 2 non instradate filtrando i pacchetti in base al database di binding dello snooping DHCP e ai binding di origine IP configurati manualmente. Gli amministratori possono utilizzare il protocollo IPSG per prevenire gli attacchi degli utenti non autorizzati che tentano di falsificare i pacchetti falsificando l'indirizzo IP di origine e/o l'indirizzo MAC. Se correttamente implementato e configurato, IPSG, insieme a uRPF in modalità rigorosa, fornisce i mezzi più efficaci per la protezione da spoofing per la vulnerabilità descritta in questo documento.
La funzione IP Source Guard è abilitata in combinazione con la funzione snooping DHCP sulle interfacce di layer 2, incluse le porte di accesso e le porte trunk.
Esempio di configurazione di IP Source GuardSwitch(config)#interface GigabitEthernet 1/0/1 Switch(config-if)#ip verify source port-security
L'esempio precedente mostra come abilitare il protocollo IPSG con il filtro degli indirizzi IP e MAC di origine dinamica.
Usare il comando show ip verify source per visualizzare la configurazione IPSG e il comando show ip source binding per visualizzare i binding di origine IP sullo switch.
Per ulteriori informazioni sulla distribuzione e la configurazione di IPSG, consultare il documento sulla configurazione delle funzionalità DHCP e di IP Source Guard.
Identity-Based Networking con reti abilitate IEEE 802.1X
IEEE 802.1x è un framework standard di protocollo per reti LAN cablate e wireless che autentica utenti o dispositivi di rete e fornisce funzionalità di applicazione delle policy a livello di porta per garantire un controllo sicuro degli accessi alla rete. Lo standard IEEE 802.1x, combinato con la capacità dei dispositivi di rete di comunicare utilizzando i protocolli esistenti come EAP e RADIUS, fornisce una maggiore sicurezza e controllo dell'accesso ai segmenti e alle risorse di rete associando l'identità di un'entità connessa alla rete a un insieme corrispondente di criteri di controllo.
Ulteriori informazioni sulla distribuzione e la configurazione di 802.1x sono disponibili nella Guida alla distribuzione e configurazione delle reti abilitate per IEEE 802.1X di Identity-Based Networking Services: IP Telephony In IEEE 802.1X.
Cisco IOS NetFlow e Cisco IOS Flexible NetFlow
Identificazione: Identificazione del flusso di traffico IPv4 con Cisco IOS NetFlow
Gli amministratori possono configurare Cisco IOS NetFlow sui router e gli switch Cisco IOS che inoltrano il traffico tra le reti dati e voce per facilitare l'identificazione dei flussi di traffico IPv4 che potrebbero essere tentativi di sfruttare questa vulnerabilità da parte di un dispositivo sulla rete dati o flussi originati da un telefono della rete voce compromesso. Si consiglia agli amministratori di analizzare questi flussi per determinare se sono tentativi di sfruttare queste vulnerabilità o se si tratta di flussi di traffico legittimi.
router#show ip cache flow IP packet size distribution (90784136 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .698 .011 .001 .004 .005 .000 .004 .000 .000 .003 .000 .000 .000 .000 512 544 576 1023 1536 2048 2560 3072 3584 4096 4608 .000 .001 .256 .000 .010 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 1885 active, 63651 inactive, 59960004 added 129803821 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 402056 bytes 0 active, 16384 inactive, 0 added, 0 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 11393421 2.8 1 48 3.1 0.0 1.4 TCP-FTP 236 0.0 12 66 0.0 1.8 4.8 TCP-FTPD 21 0.0 13726 1294 0.0 18.4 4.1 TCP-WWW 22282 0.0 21 1020 0.1 4.1 7.3 TCP-X 719 0.0 1 40 0.0 0.0 1.3 TCP-BGP 1 0.0 1 40 0.0 0.0 15.0 TCP-Frag 70399 0.0 1 688 0.0 0.0 22.7 TCP-other 47861004 11.8 1 211 18.9 0.0 1.3 UDP-DNS 582 0.0 4 73 0.0 3.4 15.4 UDP-NTP 287252 0.0 1 76 0.0 0.0 15.5 UDP-other 310347 0.0 2 230 0.1 0.6 15.9 ICMP 11674 0.0 3 61 0.0 19.8 15.5 IPv6INIP 15 0.0 1 1132 0.0 0.0 15.4 GRE 4 0.0 1 48 0.0 0.0 15.3 Total: 59957957 14.8 1 196 22.5 0.0 1.5 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.60.10 Gi0/1 192.168.60.102 11 1785 1941 12 Gi0/1 192.168.60.28 Gi0/0 192.168.13.97 11 1B3E 2A53 5391 Gi0/1 192.168.150.60 Gi0/0 10.89.16.226 06 0016 12CA 1 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 Gi0/1 192.168.60.158 Gi0/0 192.168.11.54 06 0911 3628 1612 Gi0/0 10.88.226.1 Gi0/1 192.168.202.22 11 007B 007B 1 router#Nell'esempio precedente, è possibile visualizzare i flussi con
- 12 pacchetti su porte UDP alte (valori esadecimali 1785 e 1941) da 192.168.60.10 destinati a 192.168.60.102. Se si tratta di due endpoint telefonici che devono comunicare su porte UDP alte (ad esempio flussi voce RTP), potrebbero trattarsi di transazioni legittime.
- 5391 pacchetti su porte UDP alte (valori esadecimali 1B3E e 2A53) da 192.168.60.28 destinati a 192.168.13.97. Se la versione 192.168.13.97 non è un server TFTP, un endpoint voce o un gateway che deve comunicare con il telefono 192.168.60.28, potrebbe trattarsi di un tentativo di sfruttare questa vulnerabilità effettuando lo spoofing di una transazione TFTP per esfiltrare i dati da un telefono compromesso (192.168.60.28). Saranno necessarie ulteriori indagini.
- 45 pacchetti SSH sulla porta TCP 22 (valore esadecimale 0016) tra 192.168.10.17 e telefono 192.168.60.97. Se non si prevede che 192.168.10.17 gestisca il telefono 192.168.60.97 tramite SSH, potrebbe essere un tentativo di sfruttare questa vulnerabilità. Saranno necessarie ulteriori indagini.
- Porta TCP elevata pacchetti 1612 (valori esadecimali 0911 e 3628) tra 192.168.60.158 e 192.168.11.54. Se la versione 192.168.11.54 non è un endpoint voce o un gateway che deve comunicare con il numero di telefono 192.168.60.158 tramite queste porte TCP elevate, il telefono potrebbe essere compromesso e provare a filtrare i dati. Saranno necessarie ulteriori indagini.
Il traffico di dati TFTP legittimo inviato dai dati alla rete voce proviene dall'indirizzo IP del server TFTP voce attendibile e viene inviato agli indirizzi all'interno del blocco di indirizzi 192.168.60.0/24, utilizzato dai dispositivi interessati. I pacchetti in questi flussi possono essere oggetto di spoofing e possono indicare un tentativo di sfruttare questa vulnerabilità. Si consiglia agli amministratori di confrontare questi flussi con l'utilizzo di base per il traffico di rete inviato dai dati alle reti voce e di analizzare i flussi per determinare se provengono da host o reti non attendibili.
Come mostrato nell'esempio che segue, per visualizzare solo i pacchetti SSH sulla porta TCP 2 (valore esadecimale 16), usare il flusso della cache show ip | includere il comando SrcIf|_06_.*0016 per visualizzare i record Cisco NetFlow correlati:
router#show ip cache flow | include SrcIf|_06_.*0016 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 router#
Come mostrato nell'esempio che segue, per visualizzare solo le transazioni dei pacchetti che interessano gli indirizzi telefonici, usare show ip cache flow | include il comando Src_If|192.168.60 per visualizzare i record Cisco NetFlow correlati:
router#show ip cache flow | include Src_If|192.168.60 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0 192.168.60.10 Gi0/1 192.168.60.102 11 1785 1941 12 Gi0/1 192.168.60.28 Gi0/0 192.168.13.97 11 1B3E 2A53 5391 Gi0/0 192.168.10.17 Gi0/1 192.168.60.97 06 2B89 0016 45 Gi0/1 192.168.60.158 Gi0/0 192.168.11.54 06 0911 3628 1612 router#
Identificazione: identificazione del flusso di traffico IPv6 tramite Cisco IOS NetFlow
Gli amministratori possono configurare Cisco IOS NetFlow sui router e gli switch Cisco IOS per facilitare l'identificazione dei flussi di traffico IPv6 che potrebbero essere tentativi di sfruttare le vulnerabilità descritte in questo documento. Si consiglia agli amministratori di analizzare i flussi per determinare se si tratta di tentativi di sfruttare questa vulnerabilità o se si tratta di flussi di traffico legittimi.
L'output seguente viene generato da un dispositivo Cisco IOS con software Cisco IOS versione 12.4 e treno principale. La sintassi del comando può variare a seconda del software Cisco IOS in uso.
router#show ipv6 flow cache IP packet size distribution (50078919 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .990 .001 .008 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1023 1536 2048 2560 3072 3584 4096 4608 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 475168 bytes 8 active, 4088 inactive, 6160 added 1092984 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 33928 bytes 16 active, 1008 inactive, 12320 added, 6160 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added
SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...128::201 Gi0/0 2001:DB..128::20 Gi0/1 0x11 0x16C4 0x13C4 12 2001:DB...6A:5BA6 Gi0/0 2001:DB...28::21 Gi0/1 0x3A 0x0000 0x8000 841 2001:DB...128::10 Gi0/1 1445:DB...17::121 Gi0/0 0x11 0x4281 0x4510 5101 2001:DB...6A:5BA6 Gi0/0 2001:DB...134::3 Gi0/1 0x3A 0x0000 0x8000 1191 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 2001:DB...6A::15B Gi0/0 2001:DB...128::2 Gi0/1 0x06 0x160A 0x134A 1597 2001:DB...6A:5BA6 Gi0/0 2001:DB...146::3 Gi0/1 0x3A 0x0000 0x8000 1092
Per consentire la visualizzazione dell'indirizzo IPv6 completo a 128 bit, utilizzare il comando terminal width 132 in modalità di esecuzione.
Nell'esempio precedente, è possibile visualizzare i flussi con
- 12 pacchetti su porte UDP alte (valori esadecimali 16C4 e 13C4) da 2001:DB8:1:60:128:2001 destinati a 2001:DB8:1:60:128:20. Se si tratta di due endpoint telefonici che devono comunicare su porte UDP elevate (ad esempio flussi voce RTP), potrebbe trattarsi di transazioni legittime.
- 5101 pacchetti su porte UDP alte (valori esadecimali 1B3E e 2A53) da 2001:DB8:1:60:128:10 destinati a 2001:DB8:17:121. Se 2001:DB8:17:121 non è un server TFTP o un endpoint voce o un gateway previsto per la comunicazione con il telefono 2001:DB8:1:60:128:10, potrebbe trattarsi di un tentativo di sfruttare questa vulnerabilità effettuando lo spoofing di una transazione TFTP per esfiltrare i dati da un telefono compromesso (2001:DB8:1:60:128:10). Saranno necessarie ulteriori indagini.
- 6814 pacchetti SSH sulla porta TCP 22 (valore esadecimale 0016) tra 2001:DB8:1:128:15 e il numero di telefono 2001:DB8:1:60:22:44. Se non si prevede che 2001:DB8:1:128:15 gestisca il telefono 2001:DB8:1:60:22:44 tramite SSH, potrebbe trattarsi di un tentativo di sfruttare questa vulnerabilità. Saranno necessarie ulteriori indagini.
- Pacchetti 1597 su porta TCP alta (valori esadecimali 160A e 134A) tra il 2001:DB8:1:60:6A::15B e il 2001:DB8:3:128::2. Se 2001:DB8:3:128::2 non è un endpoint voce o un gateway che dovrebbe comunicare con il telefono 2001:DB8:1:60:6A::15B su queste alte porte TCP, allora il telefono potrebbe essere compromesso e provare a espellere i dati. Saranno necessarie ulteriori indagini.
Il lettore deve notare che il traffico di dati TFTP legittimo inviato dai dati alla rete voce proviene dall'indirizzo IP del server TFTP voce attendibile e viene inviato agli indirizzi all'interno del blocco di indirizzi 2001:DB8:1:60::/64, che viene utilizzato dai dispositivi interessati. I pacchetti in questi flussi possono essere oggetto di spoofing e possono indicare un tentativo di sfruttare questa vulnerabilità. Si consiglia agli amministratori di confrontare questi flussi con l'utilizzo di base per il traffico di rete inviato dai dati alle reti voce e di analizzare i flussi per determinare se provengono da host o reti non attendibili.
Come mostrato nell'esempio che segue, per visualizzare solo i pacchetti SSH sulla porta TCP 2 (valore esadecimale 16), usare il flusso della cache show ip | includere il comando SrcIf|_06_.*0016 per visualizzare i record Cisco NetFlow correlati:
router#show ip cache flow | include SrcIf|_06_.*0016 SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 router#
Come mostrato nell'esempio che segue, per visualizzare solo le transazioni dei pacchetti che interessano gli indirizzi telefonici, usare show ip cache flow | include Src_If|2001:DB8:1:60 per visualizzare i record Cisco NetFlow correlati:
router#show ip cache flow | include Src_If|2001:DB8:1:60 SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2001:DB...128::201 Gi0/0 2001:DB..128::20 Gi0/1 0x11 0x16C4 0x13C4 12 2001:DB...128::10 Gi0/1 1445:DB...17::121 Gi0/0 0x11 0x4281 0x4510 5101 2001:DB...128::15 Gi0/1 3411:DB...22::44 Gi0/0 0x10 0x4281 0x0016 6814 2001:DB...6A::15B Gi0/0 2001:DB...128::2 Gi0/1 0x06 0x160A 0x134A 1597
Identificazione: Identificazione del flusso di traffico IPv4 con Cisco Flexible NetFlow
Introdotta nel software Cisco IOS versione 12.2(31)SB2 e 12.4(9)T, Cisco IOS Flexible NetFlow migliora l'originale Cisco NetFlow aggiungendo la capacità di personalizzare i parametri di analisi del traffico per i requisiti specifici dell'amministratore. Cisco NetFlow originale utilizza sette tuple fisse di informazioni IP per identificare un flusso, mentre Cisco IOS Flexible NetFlow consente di definire il flusso dall'utente. Facilita la creazione di configurazioni più complesse per l'analisi del traffico e l'esportazione dei dati utilizzando componenti di configurazione riutilizzabili.
L'output di esempio seguente viene generato da un dispositivo Cisco IOS con una versione del software Cisco IOS nel treno 15.1T. Sebbene la sintassi sia quasi identica per i treni 12.4T e 15.0, può variare leggermente a seconda della versione Cisco IOS in uso. Nella configurazione seguente, Cisco IOS Flexible NetFlow raccoglie le informazioni sull'interfaccia Gigabit Ethernet0/0 per i flussi IPv4 in arrivo in base all'indirizzo IPv4 di origine, come definito dall'istruzione field match ipv4 source address key. Cisco IOS Flexible NetFlow includerà anche informazioni non chiave sui campi di indirizzi IPv4 di origine e di destinazione, sul protocollo, sulle porte (se presenti), sulle interfacce in entrata e in uscita e sui pacchetti per flusso.
! !-- Configure key and nonkey fields !-- in the user-defined flow record ! flow record FLOW-RECORD-ipv4 match ipv4 source address collect ipv4 protocol collect ipv4 destination address collect transport source-port collect transport destination-port collect interface input collect interface output collect counter packets ! !-- Configure the flow monitor to !-- reference the user-defined flow !-- record ! flow monitor FLOW-MONITOR-ipv4 record FLOW-RECORD-ipv4 ! !-- Apply the flow monitor to the interface !-- in the ingress direction ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR-ipv4 input
L'output del flusso NetFlow flessibile di Cisco IOS è il seguente:
router#show flow monitor FLOW-MONITOR-ipv4 cache format table Cache type: Normal Cache size: 4096 Current entries: 6 High Watermark: 1 Flows added: 9181 Flows aged: 9175 - Active timeout ( 1800 secs) 9000 - Inactive timeout ( 15 secs) 175 - Event aged 0 - Watermark aged 0 - Emergency aged 0 IPV4 SRC ADDR ipv4 dst addr trns src port trns dst port intf input intf output pkts ip prot ============== ============= ============= ============= ========== =========== ==== ======= 192.168.60.10 192.168.60.201 1456 7631 Gi0/0 Gi0/1 1128 17 192.168.60.28 192.168.13.97 8123 33112 Gi0/0 Gi0/1 5391 17 192.168.150.60 10.89.16.226 2567 443 Gi0/0 Gi0/1 13 6 192.168.10.17 192.168.60.97 1289 22 Gi0/0 Gi0/1 45 6 192.168.60.158 192.168.11.54 32211 3628 Gi0/0 Gi0/1 1612 6Per visualizzare solo i flussi SSH su Porta TCP 22, utilizzare la tabella show flow monitor FLOW-MONITOR-ipv4 cache format | includere l'indirizzo DST IPV4 |_22_.*_6_ per visualizzare i record NetFlow correlati.
Per visualizzare solo le transazioni pacchetto che interessano indirizzi telefonici, utilizzare il flusso della cache show ip | include il comando Src_If|192.168.60 per visualizzare i record Cisco NetFlow correlati.
Per ulteriori informazioni su Cisco IOS Flexible NetFlow, consultare la guida alla configurazione di Cisco IOS versione 15.1M&T e la guida alla configurazione di Cisco IOS Flexible NetFlow, versione 12.4T.
Identificazione: identificazione del flusso di traffico IPv6 tramite Cisco IOS Flexible NetFlow
L'output di esempio seguente viene generato da un dispositivo Cisco IOS con una versione del software Cisco IOS nel treno 15.1T. Sebbene la sintassi sia quasi identica per i treni 12.4T e 15.0, può variare leggermente a seconda della versione Cisco IOS in uso. Nella configurazione seguente, Cisco IOS Flexible NetFlow raccoglie informazioni sull'interfaccia Gigabit Ethernet0/0 per i flussi IPv6 in ingresso in base all'indirizzo IPv6 di origine, come definito dall'istruzione field match ipv6 source address key. Cisco IOS Flexible NetFlow includerà anche informazioni non chiave sui campi di indirizzi IPv6 di origine e di destinazione, sul protocollo, sulle porte (se presenti), sulle interfacce in entrata e in uscita e sui pacchetti per flusso.! !-- Configure key and nonkey fields !-- in the user-defined flow record ! flow record FLOW-RECORD-ipv6 match ipv6 source address collect ipv6 protocol collect ipv6 destination address collect transport source-port collect transport destination-port collect interface input collect interface output collect counter packets ! !-- Configure the flow monitor to !-- reference the user-defined flow !-- record ! flow monitor FLOW-MONITOR-ipv6 record FLOW-RECORD-ipv6 ! !-- Apply the flow monitor to the interface !-- in the ingress direction ! interface GigabitEthernet0/0 ipv6 flow monitor FLOW-MONITOR-ipv6 input
L'output del flusso NetFlow flessibile di Cisco IOS è il seguente:
router#show flow monitor FLOW-MONITOR-ipv6 cache format table Cache type: Normal Cache size: 4096 Current entries: 6 High Watermark: 2 Flows added: 539 Flows aged: 532 - Active timeout ( 1800 secs) 350 - Inactive timeout ( 15 secs) 182 - Event aged 0 - Watermark aged 0 - Emergency aged 0 ipv6 src addr ipv6 dst addr trns src prt trns dst prt intf inpt intf outpt pkts ip prot ================ =============== ============ ============ ========= ========== ==== ======= 2001:DB...128::201 2001:DB..128::20 Gi0/0 Gi0/1 21345 12134 222 17 2001:DB...6A:5BA6 2001:DB...28::21 Gi0/0 Gi0/1 12134 23 841 6 2001:DB...128::10 20015:DB...17::121 Gi0/1 Gi0/0 23254 45234 56 17 2001:DB...6A:5BA6 2001:DB...134::3 Gi0/0 Gi0/1 1231 53 135 17 2001:DB...128::15 2001:DB...22::44 Gi0/1 Gi0/0 4234 22 234 6 2001:DB...6A::15B 2001:DB...128::2 Gi0/0 Gi0/1 21431 12134 843 6 2001:DB...6A:5BA6 2001:DB...146::3 Gi0/0 Gi0/1 48212 121 1092 17 To permit display of the full 128-bit IPv6 address, use the terminal width 132 exec mode command.Per visualizzare solo i flussi SSH sulla porta TCP 22, utilizzare la tabella di formato della cache show flow monitor-MONITOR-ipv6 | includere il comando IPV6 DST ADDR|_22_.*_6_ per visualizzare i record Cisco IOS Flexible NetFlow correlati.
Per visualizzare solo le transazioni pacchetto che interessano gli indirizzi telefonici, utilizzare il comando show ip cache flow | includeSrc_If|2001:DB8:1:60 per visualizzare i record Cisco NetFlow correlati.
Cisco ASA e Cisco FWSM Firewall
Attenuazione: Access Control List transit
Per proteggere la rete dal traffico che entra nei punti di accesso in entrata, che possono includere punti di connessione Internet, punti di connessione fornitori e partner o punti di connessione VPN, si consiglia agli amministratori di distribuire elenchi di controllo di accesso in transito (tACL) per applicare le policy. Gli amministratori possono costruire un ACL autorizzando esplicitamente solo il traffico autorizzato ad accedere alla rete dai punti di accesso in entrata o autorizzando il traffico autorizzato a transitare sulla rete in base alle configurazioni e ai criteri di sicurezza esistenti. La soluzione tACL non è in grado di fornire una protezione completa da questa vulnerabilità quando l'attacco proviene da un indirizzo di origine attendibile.
Nel primo accesso vengono elencati tACL-Policy-Data e IPv6-tACL-Policy-Data per negare i pacchetti IPv4 e IPv6 SSH non autorizzati sulle porte TCP 22 e i pacchetti IPv4 e IPv6 TFTP sulle porte UDP superiori a 1023 inviati dalla rete di dati ai dispositivi interessati sulla rete vocale. Il secondo accesso elenca tACL-Policy-Voice e IPv6-tACL-Policy-Voice per negare i pacchetti IPv4 e IPv6 RTP non autorizzati sulle porte UDP superiori a 1023 inviati dai dispositivi interessati sulla rete voce alla rete dati e questo potrebbe essere un tentativo di esfiltrare le comunicazioni vocali. Nell'esempio seguente, 192.168.60.0/24 e 2001:DB8:1:60::/64 rappresentano lo spazio di indirizzi IP utilizzato dai dispositivi interessati sulla rete voce, mentre gli host 192.168.100.1 e 2001:DB8:100:1 sono considerati fonti attendibili che richiedono l'accesso ai dispositivi interessati. È necessario prestare attenzione a consentire il traffico richiesto per il routing e l'accesso amministrativo prima di rifiutare tutto il traffico non autorizzato.Per ulteriori informazioni sugli ACL, consultare il documento Access Control Lists: Filtering at Your Edge (Liste di controllo dell'accesso in transito: filtraggio sul perimetro della rete).
!
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
!
access-list tACL-Policy-Data extended permit tcp host 192.168.100.1 192.168.60.0 255.255.255.0 eq 22 access-list tACL-Policy-Data extended permit udp host 192.168.100.1 gt 1023 192.168.60.0 255.255.255.0 gt 1023 !
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of attacks
!
access-list tACL-Policy-Data extended deny tcp any 192.168.60.0 255.255.255.0 eq 22 access-list tACL-Policy-Data extended deny udp any gt 1023 192.168.60.0 255.255.255.0 gt 1023 !
!-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance
!-- with existing security policies and configurations
!
!-- Explicit deny for all other IP traffic
!
access-list tACL-Policy-Data extended deny ip any any !
!-- Create the corresponding IPv6 tACL
! !
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
! ipv6 access-list IPv6-tACL-Policy-Data permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 ipv6 access-list IPv6-tACL-Policy-Data permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023
!
!-- The following vulnerability-specific ACEs can
!-- aid in identification of attacks to global and
!-- link-local addresses
! ipv6 access-list IPv6-tACL-Policy-Data deny tcp any 2001:DB8:1:60::/64 eq 22 ipv6 access-list IPv6-tACL-Policy-Data deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023
!
!-- Permit or deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and configurations
!
!-- Explicit deny for all other IPv6 traffic
!
ipv6 access-list IPv6-tACL-Policy-Data deny ip any any !
!
!-- Apply tACLs to interfaces in the ingress direction
! access-group tACL-Policy-Data in interface outside access-group IPv6-tACL-Policy-Data in interface outside
!
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports
!-- This includes softphones and other communication end-points !-- deployed on the data network.
! access-list tACL-Policy-Voice permit udp 192.168.60.0 255.255.255.0 gt 1023 host 192.168.100.1 gt 1023 !
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of attacks
! access-list tACL-Policy-Voice deny udp 192.168.60.0 255.255.255.0 gt 1023 any gt 1023 !
!-- Permit or deny all other Layer 3 and Layer 4 traffic in accordance
!-- with existing security policies and configurations
!
!-- Explicit deny for all other IP traffic
!
access-list tACL-Policy-Voice deny ip any any !
!-- Create the corresponding IPv6 tACL
!
!-- Include explicit permit statements for trusted sources
!-- that require access on the vulnerable TCP and UDP ports !-- This includes softphones and other communication end-points !-- deployed on the data network
! ipv6 access-list IPv6-tACL-Policy-Voice permit udp 2001:DB8:60::/64 gt 1023 host 2001:DB8:1:100::1 gt 1023
!
!-- The following vulnerability-specific ACEs can
!-- aid in identification of attacks to global and
!-- link-local addresses
! ipv6 access-list IPv6-tACL-Policy-Voice deny udp 2001:DB8:60::/64 gt 1023 any gt 1023
!
!-- Permit or deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and configurations
!
!-- Explicit deny for all other IPv6 traffic
!
ipv6 access-list IPv6-tACL-Policy-Voice deny ip any any !
!-- Apply tACLs to interfaces in the ingress direction! access-group tACL-Policy-Voice in interface inside access-group IPv6-tACL-Policy-Voice in interface inside
Identificazione: Registrazione elenco accessi
Dopo aver applicato gli ACL a un'interfaccia, gli amministratori possono usare gli elenchi degli accessi ip show per identificare il numero di pacchetti IPv4 e IPv6 SSH filtrati sulle porte TCP 22 e sui pacchetti IPv4 e IPv6 TFTP sulle porte UDP superiori a 1023. Gli amministratori sono invitati a indagare sui pacchetti filtrati per determinare se sono tentativi di sfruttare questa vulnerabilità. Di seguito è riportato un output di esempio per show ip access-lists tACL-Policy-Data e show access-list IPv6-tACL-Policy-Data:
Firewall#show ip access-lists tACL-Policy-Data access-list tACL-Policy-Data; 5 elements; name hash: 0x47502853 access-list tACL-Policy-Data line 1 extended permit tcp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 eq 22 access-list tACL-Policy-Data line 2 extended permit udp host 192.168.100.1 gt 1023 192.168.60.0 0.0.0.255 gt 1023 access-list tACL-Policy-Data line 3 extended deny tcp any 192.168.60.0 0.0.0.255 eq 22 (hitcnt=57) access-list tACL-Policy-Data line 4 extended deny udp any gt 1023 192.168.60.0 0.0.0.255 gt 1023 (hitcnt=40) access-list tACL-Policy-Data line 5 extended deny ip any any Firewall#Nell'esempio precedente, l'elenco degli accessi tACL-Policy-Data ha eliminato i seguenti pacchetti ricevuti da un host o una rete non attendibile:
- 57 pacchetti SSH sulla porta TCP 22 per la linea ACE 3
- 40 pacchetti TFTP sulle porte UDP superiori a 1023 per la linea ACE 4
Firewall#show ipv6 access-list IPv6-tACL-Policy-Data ipv6 access-list IPv6-tACL-Policy-Data; 5 elements; name hash: 0x342aba4c Ipv6 access-list IPv6-tACL-Policy-Data line 1 permit tcp host 2001:DB8::100:1 2001:DB8:1:60::/64 eq 22 (hitcnt=55) Ipv6 access-list IPv6-tACL-Policy-Data line 2 permit udp host 2001:DB8::100:1 gt 1023 2001:DB8:1:60::/64 gt 1023 (hitcnt=38) Ipv6 access-list IPv6-tACL-Policy-Data line 3 deny tcp any 2001:DB8:1:60::/64 eq 22 (hitcnt=18) Ipv6 access-list IPv6-tACL-Policy-Data line 4 deny udp any gt 1023 2001:DB8:1:60::/64 gt 1023 (hitcnt=21) Ipv6 access-list IPv6-tACL-Policy-Data line 5 deny ip any any (hitcnt=21)Nell'esempio precedente, nell'elenco degli accessi IPv6-tACL-Policy-Data sono stati eliminati i seguenti pacchetti ricevuti da un host o una rete non attendibile:
- 18 pacchetti SSH sulla porta TCP 22 per la linea ACE 3
- 21 pacchetti TFTP sulle porte TCP superiori a 1023 per la linea ACE 4
Firewall#show access-list tACL-Policy-Voice access-list tACL-Policy-Voice; 3 elements; name hash: 0xef0bf5e access-list tACL-Policy-Voice line 1 extended permit udp 192.168.60.0 255.255.255.0 gt 1023 host 192.168.100.1 gt 1023 (hitcnt=0) access-list tACL-Policy-Voice line 2 extended deny udp 192.168.60.0 255.255.255.0 gt 1023 any gt 1023 (hitcnt=29) access-list tACL-Policy-Voice line 3 extended deny ip any any (hitcnt=0) Firewall#Nell'esempio precedente, l'elenco degli accessi IPv6-tACL-Policy-Voice ha eliminato i seguenti pacchetti ricevuti da un host o una rete non attendibile:
- 29 pacchetti RTP sulle porte UDP superiori a 1023 per la linea ACE 2
Firewall#router#show ipv6 access-list IPv6-tACL-Policy-Voice ipv6 access-list IPv6-tACL-Policy-Voice line 1 permit udp 2001:db8:60::/64 gt 1023 host 2001:db8:1:100::1 gt 1023 (hitcnt=0) ipv6 access-list IPv6-tACL-Policy-Voice line 2 deny udp 2001:db8:60::/64 gt 1023 any gt 1023 (hitcnt=44) ipv6 access-list IPv6-tACL-Policy-Voice line 3 deny ip any any (hitcnt=0)Nell'esempio precedente, l'elenco degli accessi IPv6-tACL-Policy-Voice ha eliminato i seguenti pacchetti ricevuti da un host o una rete non attendibile:
- 44 pacchetti RTP sulle porte UDP superiori a 1023 per la linea ACE 2
Identificazione: Messaggi syslog elenco accessi firewall
Il messaggio syslog del firewall 106023 verrà generato per i pacchetti negati da una voce di controllo di accesso (ACE) che non dispone della parola chiave log. Per ulteriori informazioni sul messaggio syslog, consultare il messaggio Cisco ASA serie 5500 System Log, 8.2 - 106023.
Le informazioni sulla configurazione del syslog per Cisco ASA serie 5500 Adaptive Security Appliance sono disponibili in Monitoraggio - configurazione della registrazione. Per informazioni sulla configurazione del syslog sul Cisco Catalyst serie 6500 ASA Services Module, consultare il documento sulla configurazione della registrazione. Per informazioni sulla configurazione del syslog sul modulo FWSM per gli switch Cisco Catalyst serie 6500 e i router Cisco serie 7600, consultare il documento sul monitoraggio del modulo Firewall Services.
Nell'esempio seguente, il comando show logging | il comando grep regex estrae i messaggi syslog dal buffer di registrazione sul firewall. Questi messaggi forniscono informazioni aggiuntive sui pacchetti rifiutati che potrebbero indicare potenziali tentativi di sfruttare le vulnerabilità descritte in questo documento. È possibile utilizzare diverse espressioni regolari con la parola chiave grep per cercare dati specifici nei messaggi registrati.
Per ulteriori informazioni sulla sintassi delle espressioni regolari, vedere Creazione di un'espressione regolare.
firewall#show logging | grep 106023 Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src outside:192.0.2.18/2944 dst inside:192.168.60.191/6281 by access-group "tACL-Policy-Data" Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src inside:192.168.60.33/5298 dst outside:192.0.2.200/2834 by access-group "tACL-Policy-Voice" Jan 09 2013 00:15:13: %ASA-4-106023: Deny tcp src outside:2001:db8:2::2:172/2951 dst inside:2001:db8:1:60::23/22 by access-group "IPv6-tACL-Policy-Data" Jan 09 2013 00:15:13: %ASA-4-106023: Deny udp src inside:2001:db8:1:60::134/7528 dst outside:2001:db8:d::a85e:172/4752 by access-group "IPv6-tACL-Policy-Voice" firewall#Per ulteriori informazioni sui messaggi syslog per le appliance Cisco ASA Series Adaptive Security, consultare la documentazione Cisco ASA serie 5500 System Log Messages, 8.2. Per ulteriori informazioni sui messaggi syslog per Cisco Catalyst serie 6500 ASA Services Module, consultare la sezione Analyzing Syslog Messages in Cisco ASASM CLI Configuration Guide. Per ulteriori informazioni sui messaggi syslog per Cisco FWSM, consultare i messaggi log del sistema di registrazione dello switch Catalyst serie 6500 e del router Cisco serie 7600 Firewall Services Module.
Per ulteriori informazioni sull'analisi degli incidenti tramite eventi syslog, consultare il white paper Identificazione degli incidenti tramite firewall e eventi syslog del router IOS Operazioni Cisco Security Intelligence.
Attenuazione: protezione da spoofing con inoltro percorso inverso unicast
Le vulnerabilità descritte in questo documento possono essere sfruttate da pacchetti IP oggetto di spoofing. Gli amministratori possono installare e configurare uRPF come meccanismo di protezione contro lo spoofing.
uRPF è configurato a livello di interfaccia ed è in grado di rilevare ed eliminare pacchetti che non dispongono di un indirizzo IP di origine verificabile. Gli amministratori non devono affidarsi a uRPF per fornire una protezione completa dallo spoofing, in quanto i pacchetti oggetto di spoofing possono entrare nella rete tramite un'interfaccia abilitata a uRPF se esiste una route di ritorno appropriata all'indirizzo IP di origine. In un ambiente aziendale, è possibile abilitare uRPF sul perimetro Internet e sul livello di accesso interno sulle interfacce di layer 3 supportate dall'utente.
Per ulteriori informazioni sulla configurazione e l'utilizzo di uRPF, consultare la guida di riferimento dei comandi di Cisco Security Appliance per ip verify reverse-path e il white paper Understanding Unicast Reverse Path Forwarding Cisco Security.
Identificazione: protezione da spoofing con inoltro percorso inverso unicast
Il messaggio syslog del firewall 106021 verrà generato per i pacchetti negati da uRPF. Per ulteriori informazioni sul messaggio syslog, consultare il messaggio Cisco ASA serie 5500 System Log, 8.2 - 106021.
Le informazioni sulla configurazione del syslog per Cisco ASA serie 5500 Adaptive Security Appliance sono disponibili in Monitoraggio - configurazione della registrazione. Per informazioni sulla configurazione del syslog per Cisco Catalyst serie 6500 ASA Services Module, consultare il documento sulla configurazione della registrazione. Per informazioni sulla configurazione del syslog sul modulo FWSM per gli switch Cisco Catalyst serie 6500 e i router Cisco serie 7600, consultare il documento sul monitoraggio del modulo Firewall Services.
Nell'esempio seguente, il comando show logging | il comando grep regex estrae i messaggi syslog dal buffer di registrazione sul firewall. Questi messaggi forniscono informazioni aggiuntive sui pacchetti rifiutati che potrebbero indicare potenziali tentativi di sfruttare le vulnerabilità descritte in questo documento. È possibile utilizzare diverse espressioni regolari con la parola chiave grep per cercare dati specifici nei messaggi registrati.
Per ulteriori informazioni sulla sintassi delle espressioni regolari, vedere Creazione di un'espressione regolare.
firewall#show logging | grep 106021 Jan 09 2013 00:15:13: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outside Jan 09 2013 00:15:13: %ASA-1-106021: Deny UDP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outside Jan 09 2013 00:15:13: %ASA-1-106021: Deny TCP reverse path check from 192.168.60.1 to 192.168.60.99 on interface outsideIl comando show asp drop può identificare anche il numero di pacchetti scartati dalla funzione uRPF, come mostrato nell'esempio che segue:
firewall#show asp drop frame rpf-violated Reverse-path verify failed 11 firewall#
Nell'esempio precedente, uRPF ha scartato 11 pacchetti IP ricevuti su interfacce con uRPF configurato. La mancanza di output indica che la funzionalità uRPF sul firewall non ha scartato pacchetti.
Per ulteriori informazioni sul debug di pacchetti o connessioni ignorati dai percorsi di sicurezza accelerati, vedere la guida di riferimento dei comandi di Cisco Security Appliance per show asp drop.
Cisco Security Manager
Identificazione: Cisco Security Manager
Cisco Security Manager, Visualizzatore eventi
A partire dalla versione software 4.0, Cisco Security Manager può raccogliere syslog da firewall Cisco e dispositivi IPS Cisco e fornisce il Visualizzatore eventi, che può eseguire query per individuare gli eventi correlati alle vulnerabilità descritte in questo documento.
L'uso dei seguenti filtri nella visualizzazione predefinita Eventi non consentiti del firewall nel Visualizzatore eventi fornisce tutti i messaggi deny syslog dell'elenco accessi al firewall Cisco acquisiti che potrebbero indicare potenziali tentativi di sfruttare le vulnerabilità descritte in questo documento.
- Utilizzare il filtro eventi di destinazione per filtrare gli oggetti di rete contenenti lo spazio di indirizzi IP utilizzato dai dispositivi interessati (ad esempio, l'intervallo di indirizzi IPv4 192.168.60.0/24 e l'intervallo di indirizzi IPv6 2001:DB8:1:60::/64)
- Utilizzare il filtro eventi del servizio di destinazione per filtrare gli oggetti che contengono la porta TCP 22 e le porte UDP 1023 - 65535
È possibile utilizzare un filtro ID tipo di evento con la visualizzazione predefinita Eventi negati firewall nel Visualizzatore eventi per filtrare gli ID syslog mostrati nell'elenco seguente in modo da fornire tutti i messaggi syslog di negazione firewall Cisco acquisiti che potrebbero indicare potenziali tentativi di sfruttare le vulnerabilità descritte in questo documento:
- ASA-4-106021 (spoofing uRPF)
- ASA-4-106023 (rifiuto ACL)
Per ulteriori informazioni sugli eventi di Cisco Security Manager, fare riferimento alla sezione Filtering and Querying Events (Filtro ed esecuzione di query sugli eventi) della Guida dell'utente di Cisco Security Manager.
Identificazione: Eventi dei partner del sistema di gestione degli eventi
Cisco collabora con le principali società SIEM (Security Information and Event Management) del settore tramite Cisco Developer Network. Questa partnership aiuta Cisco a fornire sistemi SIEM convalidati e testati che risolvono problemi aziendali quali l'archiviazione dei log a lungo termine e la diagnostica, la correlazione di eventi eterogenei e la creazione di report avanzati sulla conformità. I prodotti partner Security Information e Event Management possono essere utilizzati per raccogliere eventi dai dispositivi Cisco e quindi eseguire query sugli eventi raccolti per individuare gli incidenti creati da una firma Cisco IPS o rifiutare messaggi syslog da firewall che potrebbero indicare potenziali tentativi di sfruttare le vulnerabilità descritte in questo documento. Le query possono essere effettuate per Signature ID e Syslog ID, come mostrato nell'elenco seguente:
- ASA-4-106021 (spoofing uRPF)
- ASA-4-106023 (rifiuto ACL)
Per ulteriori informazioni sui partner SIEM, visitare il sito Web Security Management System.
-
IL PRESENTE DOCUMENTO VIENE FORNITO "COSÌ COM'È" E NON IMPLICA ALCUNA GARANZIA O CONCESSIONE, INCLUSE LE GARANZIA DI COMMERCIABILITÀ O IDONEITÀ PER UNO SCOPO SPECIFICO. L'UTILIZZO DA PARTE DELL'UTENTE DELLE INFORMAZIONI CONTENUTE NEL DOCUMENTO O NEI MATERIALI ACCESSIBILI DAL DOCUMENTO AVVIENE A PROPRIO RISCHIO. CISCO SI RISERVA IL DIRITTO DI MODIFICARE O AGGIORNARE IL PRESENTE DOCUMENTO IN QUALSIASI MOMENTO.
-
Mostra menoVersion Descrizione Sezione Data 1 Release iniziale 2013-Gennaio-09 16:01 GMT
-
Le informazioni complete sulla segnalazione delle vulnerabilità della sicurezza nei prodotti Cisco, su come ottenere assistenza in caso di incidenti relativi alla sicurezza e su come registrarsi per ricevere informazioni sulla sicurezza da Cisco, sono disponibili sul sito Web di Cisco all'indirizzo https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html. Ciò include istruzioni per le richieste della stampa relative agli avvisi di sicurezza Cisco. Tutti gli avvisi sulla sicurezza Cisco sono disponibili all'indirizzo http://www.cisco.com/go/psirt.
-
La vulnerabilità della sicurezza si applica alle seguenti combinazioni di prodotti.
Prodotti principali Cisco Cisco Unified 7906G IP Phone 7.2 (3) | 8.0 (3), (4), (4)SR1, (4)SR2, (4)SR3A) | 8.2 ((1), (2), (2) SR1, (2) SR2, (2) SR4, (2) SR3) | 8.3 ((1), (2), (2) SR1, (2) SR2, (2) SR3, (2) SR4, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7911G IP Phone 7.2 ((1), (2)SR2, (3)) | 8.0 [(1), (2)SR2, (3), (4)SR1, (4)SR2, (4)SR3A] | 8.2 [(1), (2) SR1, (2) SR2, (2) SR3, (2) SR4] | 8.3 (1, 2, 2) SR1, (3, 3) SR2 | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7931G IP Phone 8.3 ((1), (2), (2)SR1, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7941G IP Phone 7.0 ((2), (2)SR1, (3)) | 8.0 (1), (2)SR1, (3), (4), (4)SR1, (4)SR2, (4)SR3A) | 8.2 [(1), (2) SR1, (2) SR2, (2) SR3, (2) SR4] | 8.3 (1, 2, 2) SR1, (3, 3) SR2 | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7942G IP Phone 8.3 ((2), (2) SR1, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7945G IP Phone 8.3 ((2), (2) SR1, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7961G IP Phone 7.0 ((2), (2) SR1, (3)) | 8.0 [(1), (2)SR1, (3), (4)SR1, (4)SR2, (4)SR3A] | 8.2 [(1), (2) SR1, (2) SR2, (2) SR3, (2) SR4] | 8.3 (1, 2, 2) SR1, (3, 3) SR2 | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7962G IP Phone 8.3 ((2), (2) SR1, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7965G IP Phone 8.3 ((2), (2) SR1, (3), (3) SR2) | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7970G IP Phone 5.0 (1), (3) | 6.0 (1), (1)SR1, (2), (2)SR1, (3)SR1) | 7.0 (1), (2), (2)SR1, (3) | 8.0 [(1), (2)SR1, (3), (4)SR1, (4)SR2, (4)SR3A] | 8.3 (1, 2, 2) SR1, (3, 3) SR2 | 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7971G-GE IP Phone 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7961G-GE IP Phone 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7941G-GE IP Phone 9.0 (9.0(2)SR1, 9.0(2)SR2, 9.0(3), 9.1(1)SR1, 9.2(1)) Cisco Unified 7975G IP Phone 8.3(2) (Base, SR1) | 8.3(3) (Base, SR2) | 8.3(4) (Base, SR1) | 8.3(5) (Base) | 8.4(1) (Base, SR1, SR2) | 8.4(2) (Base) | 8.4(3) (Base) | 8.4(4) (Base) | 8.5(2) (Base, SR1) | 8.5(3) (Base, SR1) | 8.5(4) (Base) | 9.0(2) (Base, SR1, SR2) | 9.0(3) (Base) | 9.1(1) (Base, SR1) | 9.2(1) (Base, SR2) | 9.2(3) (Base) | 9.3(1) (Base, SR1)
Prodotti associati
-
IL PRESENTE DOCUMENTO VIENE FORNITO "COSÌ COM'È" E NON IMPLICA ALCUNA GARANZIA O CONCESSIONE, INCLUSE LE GARANZIA DI COMMERCIABILITÀ O IDONEITÀ PER UNO SCOPO SPECIFICO. L'UTILIZZO DA PARTE DELL'UTENTE DELLE INFORMAZIONI CONTENUTE NEL DOCUMENTO O NEI MATERIALI ACCESSIBILI DAL DOCUMENTO AVVIENE A PROPRIO RISCHIO. CISCO SI RISERVA IL DIRITTO DI MODIFICARE O AGGIORNARE GLI AVVISI IN QUALSIASI MOMENTO.
Una copia standalone o una parafrasi del testo di questo documento che omette l'URL di distribuzione è una copia non controllata e può non contenere informazioni importanti o contenere errori materiali. Le informazioni di questo documento sono destinate agli utenti finali dei prodotti Cisco