Applica protezione ai dispositivi IOS

Introduzione

Questo documento descrive come proteggere i dispositivi di sistema Cisco IOS^® e aumentare la sicurezza complessiva della rete.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Introduzione

Quando si proteggono i dispositivi di sistema Cisco IOS, la sicurezza complessiva della rete aumenta.

La sicurezza complessiva della rete è strutturata attorno ai tre piani in cui è possibile classificare le funzioni di un dispositivo di rete. I tre piani funzionali di una rete sono: il piano di gestione, il piano di controllo e il piano dati. Ogni piano fornisce funzionalità diverse che devono essere protette. In questo documento viene fornita una panoramica di tutte le funzionalità incluse e i riferimenti alla documentazione correlata.

• Management Plane: il management plane gestisce il traffico inviato al dispositivo Cisco IOS ed è composto da applicazioni e protocolli, ad esempio Secure Shell (SSH) e Simple Network Management Protocol (SNMP).
  
  
• Control Plane: il control plane di un dispositivo di rete elabora il traffico che è fondamentale per mantenere la funzionalità dell'infrastruttura di rete. Il control plane è costituito da applicazioni e protocolli tra dispositivi di rete, ad esempio il Border Gateway Protocol (BGP), e i protocolli IGP (Interior Gateway Protocol). Sono inoltre inclusi Enhanced Interior Gateway Routing Protocol (EIGRP) e Open Shortest Path First (OSPF).
  
  
• Piano dati - Il piano dati inoltra i dati attraverso un dispositivo di rete. Il data plane non include il traffico inviato al dispositivo Cisco IOS locale.

Le funzionalità di sicurezza descritte in questo documento spesso forniscono dettagli sufficienti per configurare la funzionalità descritta. Tuttavia, se i dettagli non sono disponibili, la feature viene spiegata in modo che sia possibile valutare se è necessaria una maggiore attenzione alla feature. Ove possibile e opportuno, questo documento contiene raccomandazioni che, se implementate, contribuiscono a proteggere una rete.

Operazioni sicure

La sicurezza delle operazioni di rete è un argomento fondamentale. Anche se la maggior parte di questo documento è dedicata alla configurazione sicura di un dispositivo Cisco IOS, le sole configurazioni non proteggono completamente una rete. Le procedure operative in uso sulla rete contribuiscono alla sicurezza tanto quanto la configurazione dei dispositivi sottostanti.

Questi argomenti contengono suggerimenti operativi che è consigliabile implementare. Questi argomenti evidenziano aree critiche specifiche delle operazioni di rete e non sono completi.

Monitoraggio dei consigli e delle risposte sulla sicurezza Cisco

Il Cisco Product Security Incident Response Team (PSIRT) crea e gestisce pubblicazioni, comunemente note come consigli PSIRT, per problemi relativi alla sicurezza dei prodotti Cisco. Il metodo utilizzato per la comunicazione di problemi meno gravi è Cisco Security Response. Gli avvisi e le risposte sulla sicurezza sono disponibili all'indirizzo Cisco Security Advisories.

Ulteriori informazioni su questi veicoli di comunicazione sono disponibili in Cisco Security Vulnerability Policy.

Per mantenere una rete sicura, tenere presente i consigli e le risposte sulla sicurezza di Cisco che sono stati rilasciati. È necessario essere a conoscenza di una vulnerabilità prima di poter valutare la minaccia che può rappresentare per una rete. Per assistenza nel processo di valutazione, fare riferimento a Valutazione dei rischi per la vulnerabilità della sicurezza.

Utilizzo di autenticazione, autorizzazione e accounting

Il framework AAA (Authentication, Authorization, and Accounting) è essenziale per proteggere i dispositivi di rete. La struttura AAA fornisce l'autenticazione delle sessioni di gestione e può inoltre limitare gli utenti a comandi specifici definiti dall'amministratore e registrare tutti i comandi immessi da tutti gli utenti. Per ulteriori informazioni su come usare il protocollo AAA, vedere la sezione Autenticazione, autorizzazione e accounting di questo documento.

Processo di raccolta e monitoraggio dei registri centralizzato

Per acquisire informazioni su eventi presenti, emergenti e cronologici relativi a problemi di sicurezza, è necessario che l'organizzazione disponga di una strategia unificata per i registri eventi e la correlazione. Questa strategia unificata deve sfruttare i registri di tutti i dispositivi di rete e utilizzare funzionalità di correlazione preconfigurate e personalizzabili.

Dopo l'implementazione dei registri centralizzati, è necessario sviluppare un approccio strutturato per l'analisi dei registri e la registrazione degli incidenti. In base alle esigenze dell'organizzazione, questo approccio può variare da una semplice analisi diligente dei dati di registro ad un'analisi avanzata basata su regole.

Per ulteriori informazioni su come implementare i log sui dispositivi di rete Cisco IOS, vedere la sezione Best Practice di registrazione di questo documento.

Usa protocolli sicuri quando possibile

I protocolli multipli vengono utilizzati per trasportare dati sensibili di gestione della rete. Se possibile, utilizzare protocolli sicuri. Tra i protocolli a scelta sicura è incluso l'uso del protocollo SSH, anziché Telnet, in modo che i dati di autenticazione e le informazioni di gestione vengano crittografati. Inoltre, utilizzare protocolli di trasferimento file sicuri quando si copiano i dati di configurazione. Un esempio è l'uso del protocollo SCP (Secure Copy Protocol) al posto del protocollo FTP o TFTP. 

Per ulteriori informazioni sulla gestione sicura dei dispositivi Cisco IOS, vedere la sezione Sessioni di gestione interattiva sicure di questo documento.

Maggiore visibilità del traffico con NetFlow

NetFlow consente di monitorare i flussi di traffico sulla rete. Originariamente progettato per esportare informazioni sul traffico in applicazioni di gestione di rete, NetFlow può essere utilizzato anche per visualizzare informazioni sul flusso su un router. Questa funzionalità consente di visualizzare in tempo reale il traffico che attraversa la rete. Indipendentemente dal fatto che le informazioni di flusso vengano esportate o meno in un raccoglitore remoto, è consigliabile configurare i dispositivi di rete per NetFlow in modo che possano essere utilizzati in modo reattivo, se necessario.

Per ulteriori informazioni su questa funzione, consultare la sezione Identificazione e tracciamento del traffico in questo documento e in Cisco IOS NetFlow.

Nota: solo gli utenti Cisco registrati possono accedere a informazioni e strumenti interni.

Gestione della configurazione

La gestione della configurazione è un processo mediante il quale vengono proposte, esaminate, approvate e distribuite le modifiche alla configurazione. Nel contesto di una configurazione di dispositivo Cisco IOS, due aspetti aggiuntivi della gestione della configurazione sono critici: archiviazione della configurazione e sicurezza.

Usare gli archivi di configurazione per eseguire il rollback delle modifiche apportate ai dispositivi di rete. In un contesto di protezione, gli archivi di configurazione possono essere utilizzati anche per determinare quali modifiche alla protezione sono state apportate e quando sono state apportate. Insieme ai dati di registro AAA, queste informazioni possono essere utili per il controllo della sicurezza dei dispositivi di rete.

La configurazione di un dispositivo Cisco IOS contiene molti dettagli riservati. Nomi utente, password e contenuto degli elenchi di controllo di accesso sono esempi di queste informazioni riservate. Il repository utilizzato per archiviare le configurazioni dei dispositivi Cisco IOS deve essere protetto. Un accesso non sicuro a queste informazioni può compromettere la sicurezza dell'intera rete.

Piano di gestione

Il piano di gestione è costituito da funzioni che consentono di raggiungere gli obiettivi di gestione della rete. Ciò include sessioni di gestione interattive che usano SSH, nonché la raccolta di statistiche con SNMP o NetFlow. Se si considera la sicurezza di un dispositivo di rete, è fondamentale che il piano di gestione sia protetto. Se un problema di sicurezza può compromettere le funzioni del piano di gestione, potrebbe essere impossibile ripristinare o stabilizzare la rete.

Nelle sezioni seguenti di questo documento vengono descritte in dettaglio le funzionalità e le configurazioni di sicurezza disponibili nel software Cisco IOS per fortificare il piano di gestione.

Protezione avanzata piano di gestione generale

Il piano di gestione viene utilizzato per accedere, configurare e gestire un dispositivo, nonché per monitorarne le operazioni e la rete in cui viene distribuito. Il piano di gestione riceve e invia traffico per le operazioni di queste funzioni. Proteggere sia il piano di gestione che il piano di controllo di un dispositivo, in quanto le operazioni del piano di controllo influiscono direttamente sulle operazioni del piano di gestione. I protocolli utilizzati dal piano di gestione includono:

• Simple Network Management Protocol
• Telnet
• Protocollo Secure Shell
• Protocollo di trasferimento file
• Protocollo HyperText Transfer / Protocollo Secure HyperText Transfer

• Protocollo Trivial File Transfer
• Secure Copy Protocol
• TACACS+
• RAGGIO
• NetFlow
• Protocollo orario di rete
• Syslog

Devono essere prese misure per garantire la sopravvivenza dei piani di gestione e di controllo durante gli incidenti di sicurezza. Se uno di questi aerei viene sfruttato con successo, tutti gli aerei possono essere compromessi.

Gestione password

Le password controllano l'accesso alle risorse o ai dispositivi. A tale scopo, utilizzare la password utilizzata per autenticare le richieste. Quando si riceve una richiesta di accesso a una risorsa o a un dispositivo, la richiesta viene contestata per la verifica della password e dell'identità e l'accesso può essere concesso, negato o limitato in base al risultato. Come buona norma per la sicurezza, le password devono essere gestite con un server di autenticazione TACACS+ o RADIUS. Tuttavia, in caso di errore dei servizi TACACS+ o RADIUS, è ancora necessaria una password configurata localmente per l'accesso privilegiato. Un dispositivo può inoltre includere altre informazioni sulla password nella propria configurazione, ad esempio una chiave NTP, una stringa della community SNMP o una chiave del protocollo di routing.

Il comando enable secret viene usato per impostare la password che concede l'accesso amministrativo privilegiato al sistema Cisco IOS. È necessario utilizzare il comandoenable secretanziché il comando precedenteenable password. OSPF (Open Shortest Path First) enable passwordutilizza un algoritmo di crittografia debole.

Se non enable secret è impostato alcun accesso e viene configurata una password per la riga di tty della console, la password della console può essere utilizzata per ricevere l'accesso privilegiato, anche da una sessione remote virtual tty (vty). Questa azione è quasi certamente indesiderata ed è un altro motivo per garantire la configurazione di un segreto abilitante.

Il comando service password-encryption di configurazione globale indica al software Cisco IOS di crittografare le password, i segreti CHAP (Challenge Handshake Authentication Protocol) e dati simili salvati nel file di configurazione. Tale codifica è utile per impedire che osservatori occasionali osservino le password, ad esempio quando guardano lo schermo alle spalle di un amministratore. Tuttavia, l'algoritmo utilizzato dal service password-encryption comando è una semplice cifratura Vigen re. L'algoritmo non è progettato per proteggere i file di configurazione da analisi gravi da parte di utenti malintenzionati anche leggermente sofisticati e non deve essere utilizzato a questo scopo. I file di configurazione Cisco IOS che contengono password crittografate devono essere gestiti con la stessa attenzione usata per un elenco non crittografato delle stesse password.

Questo algoritmo di crittografia debole non viene utilizzato dal enable secret comando, ma viene utilizzato dal comando di configurazione globale e dal comando di configurazione enable password della password riga di comando. Questo tipo di password deve essere eliminato e occorre usare il enable secret comando o la funzione Sicurezza potenziata delle password.

Il comandoenable secrete la funzione Sicurezza avanzata password utilizzano Message Digest 5 (MD5) per l'hashing delle password. Questo algoritmo ha avuto una notevole revisione pubblica e non è noto per essere reversibile. Tuttavia, l'algoritmo è soggetto ad attacchi di dizionario. In un attacco di dizionario, un utente malintenzionato tenta di trovare una corrispondenza con ogni parola di un dizionario o con un'altra lista di password candidate. Pertanto, i file di configurazione devono essere archiviati in modo sicuro e condivisi solo con utenti attendibili.

Sicurezza potenziata delle password

La funzione di sicurezza potenziata delle password, introdotta nel software Cisco IOS versione 12.2(8)T, consente agli amministratori di configurare l'hashing MD5 delle password per il comandousername. Prima di questa funzione esistevano due tipi di password: Type 0, che è una password in testo non crittografato, e Type 7, che utilizza l'algoritmo della cifratura Vigen re. La funzione Sicurezza avanzata password non può essere utilizzata con protocolli che richiedono il recupero della password non crittografata, ad esempio CHAP.

Per crittografare una password utente con hashing MD5, eseguire il comando di configurazione username secret globale.

!

username <name> secret <password>

!

Blocco nuovo tentativo password di accesso

La funzione Login Password Retry Lockout, aggiunta nel software Cisco IOS versione 12.3(14)T, consente di bloccare un account utente locale dopo un numero configurato di tentativi di accesso non riusciti. Dopo che un utente è stato bloccato, il suo account viene bloccato fino a quando non viene sbloccato. Impossibile bloccare con questa funzionalità un utente autorizzato configurato con il livello di privilegio 15. Ridurre al minimo il numero di utenti con livello di privilegio 15.

Si noti che gli utenti autorizzati possono bloccarsi da un dispositivo se viene raggiunto il numero di tentativi di accesso non riusciti. Un utente malintenzionato può inoltre creare una condizione DoS (Denial of Service) con ripetuti tentativi di autenticazione tramite un nome utente valido.

Nell'esempio viene mostrato come abilitare la funzione di blocco dei tentativi di accesso con password:

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

Questa funzionalità si applica anche ai metodi di autenticazione, ad esempio CHAP e PAP (Password Authentication Protocol).

Nessun recupero della password del servizio

Nel software Cisco IOS versione 12.3(14)T e successive, la funzione No Service Password-Recovery non consente a nessuno con accesso alla console di accedere in modo sicuro alla configurazione del dispositivo e di cancellare la password. Inoltre, non consente a utenti malintenzionati di modificare il valore del registro di configurazione e accedere alla NVRAM.

!

no service password-recovery

!

Il software Cisco IOS fornisce una procedura di recupero della password che si basa sull'accesso a ROM Monitor Mode (ROMMON), in cui viene utilizzato il tasto Break durante l'avvio del sistema. In ROMMON, il software del dispositivo può essere ricaricato per richiedere una nuova configurazione del sistema che includa una nuova password.

La procedura di recupero della password corrente consente a chiunque disponga dell'accesso alla console di accedere al dispositivo e alla relativa rete. La funzione No Service Password-Recovery impedisce il completamento della sequenza di tasti di interruzione e l'immissione di ROMMON durante l'avvio del sistema.

Se no service password-recovery è attivato su un dispositivo, è consigliabile salvare una copia offline della configurazione del dispositivo e implementare una soluzione di archiviazione della configurazione. Se è necessario recuperare la password di un dispositivo Cisco IOS dopo aver abilitato questa funzione, l'intera configurazione viene eliminata.

Per ulteriori informazioni su questa funzione, fare riferimento all'esempio di configurazione di Secure ROMMON.

Disabilita servizi inutilizzati

Per una sicurezza ottimale, disabilitare tutti i servizi non necessari. I servizi non necessari, in particolare quelli che utilizzano il protocollo UDP (User Datagram Protocol), vengono raramente utilizzati per scopi legittimi, ma possono essere utilizzati per avviare DoS e altri attacchi che vengono altrimenti impediti dal filtraggio dei pacchetti.

Disabilitare i servizi TCP e UDP di piccole dimensioni. Questi servizi includono:

• echo (numero porta 7)
  
  
• scarta (numero porta 9)
  
  
• diurno (numero porta 13)
  
  
• chargen (numero porta 19)

Anche se l'abuso dei piccoli servizi può essere evitato o reso meno pericoloso da elenchi di accesso anti-spoofing, disabilitare i servizi su qualsiasi dispositivo accessibile all'interno della rete. Per impostazione predefinita, i servizi di piccole dimensioni sono disabilitati nel software Cisco IOS versione 12.0 e successive. Nel software precedente, è possibile emettere i comandi di configurazione globale no service tcp-small-servers e no service udp-small-servers per disabilitarli.

Se non vengono utilizzati, i servizi aggiuntivi da disabilitare includono:

• Eseguire il comando di configurazioneno ip fingerglobale per disabilitare il servizio Finger. Per impostazione predefinita, il software Cisco IOS versioni successive alla 12.1(5) e alla 12.1(5)T disabilita questo servizio.
• Eseguire il comando di configurazioneno ip bootp serverglobale per disabilitare il protocollo BOOTP (Bootstrap Protocol).
• Nel software Cisco IOS versione 12.2(8)T e successive, usare il comando ip dhcp bootp ignore in modalità di configurazione globale per disabilitare il comando BOOTP. In questo modo i servizi DHCP (Dynamic Host Configuration Protocol) rimangono abilitati.
• Se i servizi di inoltro DHCP non sono necessari, è possibile disabilitare i servizi DHCP. Eseguire il comando no service dhcp in modalità di configurazione globale.
• Eseguire il comando no mop enabled in modalità di configurazione interfaccia per disabilitare il servizio MOP (Maintenance Operation Protocol).
• Eseguire il comando di configurazione globale no ip domain-lookup per disabilitare i servizi di risoluzione DNS (Domain Name System).
• Eseguire il comando no service pad in modalità di configurazione globale per disabilitare il servizio Packet Assembler/Disassembler (PAD), utilizzato per le reti X.25.
  Il server HTTP può essere disabilitato con il comando no ip http server in modalità di configurazione globale e il server HTTP protetto (HTTPS) può essere disabilitato con il comando di configurazione globale no ip http secure-server.
  A meno che i dispositivi Cisco IOS non recuperino le configurazioni dalla rete durante l'avvio, è necessario utilizzare il comando di configurazione globale no service config. In questo modo si impedisce al dispositivo Cisco IOS di tentare di individuare un file di configurazione sulla rete con TFTP.
  Cisco Discovery Protocol (CDP) è un protocollo di rete utilizzato per rilevare altri dispositivi CDP per le adiacenze e la topologia di rete. Il CDP può essere utilizzato dai sistemi di gestione della rete (NMS, Network Management Systems) o durante l'isolamento dei problemi. Il CDP deve essere disabilitato su tutte le interfacce connesse a reti non attendibili. a tal fine, usare il comando no cdp enable interface. In alternativa, il CDP può essere disabilitato globalmente con il comando di configurazione globale no cdp run. Notare che il CDP può essere utilizzato da un utente malintenzionato per la ricognizione e per mappare una rete.
• Il protocollo LLDP (Link Layer Discovery Protocol) è un protocollo IEEE definito in 802.1AB ed è simile al protocollo CDP. Tuttavia, questo protocollo consente l'interoperabilità tra altri dispositivi che non supportano CDP. LLDP deve essere trattato allo stesso modo di CDP e disabilitato su tutte le interfacce che si connettono a reti non attendibili. A tale scopo, usare i comandi di configurazione dell'interfaccia no lldp transmission e no lldp receive. Eseguire il comando di configurazione globale no lldp run per disabilitare LLDP a livello globale. LLDP può anche essere utilizzato da un utente malintenzionato per la ricognizione e per mappare una rete.

• Per gli switch che supportano l'avvio da sdflash, è possibile migliorare la sicurezza per l'avvio da flash e disabilitare sdflash con il comando di configurazione "no sdflash".

Timeout EXEC

Per impostare l'intervallo, l'interprete dei comandi EXEC attende l'input dell'utente prima di terminare una sessione, eseguire il comando di configurazione della riga exec-timeout. Utilizzare il comando exec-timeout per disconnettere le sessioni sulle righe vty o tty lasciate inattive. Per impostazione predefinita, le sessioni vengono disconnesse dopo dieci minuti di inattività.

!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]
!

Mantenimento attività per sessioni TCP

I comandi di configurazione globale service tcp-keepalives-in e service tcp-keepalives-out consentono a un dispositivo di inviare pacchetti TCP keepalive per le sessioni TCP. Utilizzare questa configurazione per abilitare i pacchetti TCP keepalive sulle connessioni in entrata al dispositivo e sulle connessioni in uscita dal dispositivo. In questo modo, il dispositivo sull'estremità remota della connessione è ancora accessibile e le connessioni half-open o orfane vengono rimosse dal dispositivo Cisco IOS locale.

!

service tcp-keepalives-in
service tcp-keepalives-out
!

Uso dell'interfaccia di gestione

È possibile accedere al piano di gestione di un dispositivo in banda o fuori banda tramite un'interfaccia di gestione fisica o logica. Idealmente, l'accesso alla gestione sia in banda che fuori banda è disponibile per ciascun dispositivo di rete, in modo che sia possibile accedere al piano di gestione durante le interruzioni della rete.

Una delle interfacce più comuni utilizzate per l'accesso in banda a un dispositivo è l'interfaccia di loopback logico. Le interfacce di loopback sono sempre attive, mentre le interfacce fisiche possono cambiare stato e l'interfaccia potrebbe non essere accessibile. Si consiglia di aggiungere un'interfaccia di loopback a ciascun dispositivo come interfaccia di gestione e di utilizzarla esclusivamente per il piano di gestione. In questo modo l'amministratore può applicare le regole a tutta la rete per il piano di gestione. Una volta configurata su un dispositivo, l'interfaccia di loopback può essere utilizzata dai protocolli del piano di gestione, ad esempio SSH, SNMP e syslog, per inviare e ricevere il traffico.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

Notifiche soglia memoria

La funzione di notifica della soglia della memoria, aggiunta nel software Cisco IOS versione 12.3(4)T, consente di ridurre le condizioni di memoria insufficiente su un dispositivo. A tale scopo, questa funzionalità utilizza due metodi: Notifica soglia memoria e Prenotazione memoria.

Notifica soglia memoria genera un messaggio di registro per indicare che la memoria disponibile su un dispositivo è scesa al di sotto della soglia configurata. Nell'esempio di configurazione viene mostrato come abilitare questa funzione con il comando di configurazione globale memory free low-watermark. In questo modo, un dispositivo può generare una notifica quando la memoria disponibile scende al di sotto della soglia specificata e di nuovo quando la memoria disponibile aumenta del 5% rispetto alla soglia specificata.

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

La prenotazione della memoria è utilizzata in modo da rendere disponibile una quantità di memoria sufficiente per le notifiche critiche. In questo esempio di configurazione viene illustrato come attivare questa funzionalità per garantire il funzionamento dei processi di gestione anche quando la memoria del dispositivo è esaurita.

!

memory reserve critical <value>
!

Per ulteriori informazioni su questa funzione, fare riferimento a Notifiche di soglia della memoria.

Notifica soglia CPU

Introdotta nel software Cisco IOS versione 12.3(4)T, la funzione di notifica dei valori di soglia della CPU consente di rilevare e ricevere notifiche quando il carico della CPU su un dispositivo supera una soglia configurata. Quando la soglia viene superata, il dispositivo genera e invia un messaggio trap SNMP. Sul software Cisco IOS sono supportati due metodi di soglia per l'utilizzo della CPU: Rising Threshold e Falling Threshold.

In questa configurazione di esempio viene mostrato come abilitare le soglie di aumento e di diminuzione per attivare un messaggio di notifica della soglia della CPU:

!

snmp-server enable traps cpu threshold
!

snmp-server host <host-address> <community-string> cpu 
!

process cpu threshold type <type> rising <percentage> interval <seconds> 
     [falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!

Per ulteriori informazioni su questa funzione, fare riferimento a Notifica soglia CPU.

Riserva di memoria per l'accesso alla console

Nel software Cisco IOS versione 12.4(15)T e successive, la funzione Reserve Memory for Console Access (Riserva di memoria per l'accesso alla console) può essere utilizzata per riservare una quantità di memoria sufficiente a garantire l'accesso alla console a un dispositivo Cisco IOS a scopo amministrativo e di isolamento dei problemi. Questa funzione è particolarmente utile quando la memoria del dispositivo è quasi esaurita. Per abilitare questa funzione, è possibile usare il comando di configurazione globale della console di riserva di memoria. Nell'esempio, viene usato un dispositivo Cisco IOS con una configurazione che riserva 4096 kilobyte per questo scopo.

!
memory reserve console 4096
!

Rilevatore perdite di memoria

Introdotta nel software Cisco IOS versione 12.3(8)T1, la funzione di rilevamento delle perdite di memoria consente di rilevare le perdite di memoria su un dispositivo. Rilevamento perdite di memoria è in grado di rilevare perdite in tutti i pool di memoria, i buffer di pacchetti e i blocchi. Le perdite di memoria sono allocazioni statiche o dinamiche di memoria che non servono a nessuno scopo utile. Questa funzionalità è incentrata sulle allocazioni di memoria dinamiche. È possibile utilizzare il comando show memory debug leaks EXEC per rilevare eventuali perdite di memoria.

Overflow del buffer: rilevamento e correzione di danneggiamento della rizona

Nel software Cisco IOS versione 12.3(7)T e successive, la funzione Buffer Overflow: Detection and Correction of Redzone Corruption può essere abilitata su un dispositivo per rilevare e correggere un overflow di blocchi di memoria e continuare le operazioni.

Per abilitare questa funzione, è possibile utilizzare i comandi di configurazione globale. Una volta configurato, il comando show memory overflow può essere usato per visualizzare le statistiche di rilevamento e correzione dell'overflow del buffer.

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

Raccolta Avanzata Di File Crashinfo

La funzione avanzata Crashinfo File Collection elimina automaticamente i vecchi file crashinfo. Questa funzione, aggiunta nel software Cisco IOS versione 12.3(11)T, consente a un dispositivo di recuperare spazio per creare nuovi file crashinfo quando il dispositivo si blocca. Questa funzione consente anche di configurare il numero di file crashinfo da salvare.

!
exception crashinfo maximum files <number-of-files>
!

Protocollo orario di rete

Il protocollo NTP (Network Time Protocol) non è un servizio pericoloso, ma qualsiasi servizio non necessario può rappresentare un vettore di attacco. Se si utilizza NTP, è importante configurare in modo esplicito un'origine ora attendibile e utilizzare l'autenticazione corretta. Per gli scopi del syslog, ad esempio durante le indagini forensi su potenziali attacchi, nonché per il successo della connettività VPN quando si dipende dai certificati per l'autenticazione di fase 1, è necessario disporre di tempo accurato e affidabile.

• Fuso orario NTP - Quando si configura il protocollo NTP, è necessario configurare il fuso orario in modo che i timestamp possano essere accuratamente correlati. Esistono due metodi tipici per configurare il fuso orario per i dispositivi su una rete con una presenza globale. Un metodo consiste nel configurare tutti i dispositivi di rete con l'ora UTC (Coordinated Universal Time), in precedenza denominata GMT (Greenwich Mean Time). L'altro metodo consiste nel configurare i dispositivi di rete con il fuso orario locale. Per ulteriori informazioni su questa funzione, consultare la sezione "clock timezone" nella documentazione del prodotto Cisco.
  
  
• Autenticazione NTP - Se si configura l'autenticazione NTP, questa assicura che i messaggi NTP vengano scambiati tra peer NTP attendibili.

Questa è una configurazione di esempio che utilizza l'autenticazione NTP:

Client:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server 172.16.1.5 key 5

Server:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5

Disabilita Smart Install

Le best practice sulla sicurezza relative alla funzionalità Cisco Smart Install (SMI) dipendono dal modo in cui la funzionalità viene utilizzata in un ambiente utente specifico. Cisco distingue questi casi di utilizzo:

• Utenti che non utilizzano la funzionalità SMI.
• Utenti che utilizzano la funzionalità SMI solo per l'installazione zero-touch.
• Utenti che sfruttano la funzionalità Smart InstallSMI per un'installazione con più di zero-touch (configurazione e gestione delle immagini).

Le sezioni seguenti descrivono in dettaglio ogni scenario:

• Utenti che non utilizzano la funzionalità SMI.
• Gli utenti che non usano la funzione SMI e che eseguono una versione del software Cisco IOS e Cisco IOS XE in cui il comando è disponibile, possono disabilitare la funzione SMI con il comando no vstack.

Nota: il comando vstack è stato introdotto in Cisco IOS versione 12.2(55)SE03.

Di seguito viene riportato un esempio di output del comando show vstack su uno switch Cisco Catalyst con la funzionalità client SMI disabilitata:

switch# show vstack 
config Role: Client (SmartInstall disabled) 
Vstack Director IP address: 0.0.0.0

Clienti che utilizzano la funzionalità SMI solo per l'installazione zero-touch

Disabilitare la funzionalità del client SMI al termine dell'installazione zero-touch o usare il comando no vstack.

Per propagare il comando no vstack nella rete, utilizzare uno dei seguenti metodi:

• Immettere il comando no vstack su tutti gli switch client, manualmente o con uno script.
• Aggiungere il comando no vstack come parte della configurazione di Cisco IOS da inviare a ciascun client SMI come parte dell'installazione zero-touch.
• Nelle versioni che non supportano il comando vstack (Cisco IOS versione 12.2(55)SE02 e precedenti), applicare un ACL (Access Control List) sugli switch client per bloccare il traffico sulla porta TCP 4786.

Per abilitare la funzionalità del client SMI in un secondo momento, immettere il comando vstack su tutti gli switch client, manualmente o con uno script.

Clienti che utilizzano la funzionalità SMI per un'installazione senza interruzioni

Nella progettazione di un'architettura SMI, prestare attenzione affinché lo spazio di indirizzi IP dell'infrastruttura non sia accessibile a parti non attendibili. Nelle versioni che non supportano il comando vstack, verificare che solo il director SMI disponga della connettività TCP a tutti i client SMI sulla porta 4786.

Gli amministratori possono utilizzare le seguenti procedure ottimali di sicurezza per le distribuzioni SMI sui dispositivi interessati:

• ACL di interfaccia
• Control Plane Policing (CoPP). Questa funzione non è disponibile su tutte le versioni del software Cisco IOS.

Nell'esempio viene mostrato un ACL di interfaccia con l'indirizzo IP del director SMI come 10.10.10.1 e l'indirizzo IP del client SMI come 10.10.10.200:

ip access-list extended SMI_HARDENING_LIST
Permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any

Questo ACL deve essere distribuito su tutte le interfacce IP su tutti i client. Può inoltre essere premuto dal director alla prima installazione degli switch.

Per limitare ulteriormente l'accesso a tutti i client all'interno dell'infrastruttura, gli amministratori possono utilizzare queste procedure ottimali di sicurezza su altri dispositivi della rete:

• iACL (Access Control List) dell'infrastruttura
• VACL (VLAN Access Control List)

Limitazione dell'accesso alla rete con ACL di infrastruttura

Progettati per prevenire la comunicazione diretta non autorizzata ai dispositivi di rete, gli iACL sono uno dei controlli di sicurezza più critici implementati sulle reti. Un iACL sfrutta l'idea che quasi tutto il traffico di rete attraversa la rete e non è destinato alla rete stessa.

Un iACL viene costruito e applicato per specificare le connessioni dagli host o dalle reti che devono essere autorizzate ai dispositivi di rete. Esempi comuni di questi tipi di connessione sono eBGP, SSH e SNMP. Dopo aver autorizzato le connessioni richieste, tutto il resto del traffico verso l'infrastruttura viene esplicitamente rifiutato. Tutto il traffico di transito che attraversa la rete e non è destinato a dispositivi dell'infrastruttura è quindi esplicitamente autorizzato.

Le protezioni fornite dagli iACL sono significative sia per i piani di gestione che per quelli di controllo. L'implementazione degli iACL può essere agevolata dall'uso di indirizzi diversi per i dispositivi dell'infrastruttura di rete. Per ulteriori informazioni sulle implicazioni degli indirizzi IP per la sicurezza, fare riferimento a Un approccio orientato alla sicurezza degli indirizzi IP.

Nell'esempio, la configurazione degli ACL mostra la struttura da usare come punto iniziale quando si inizia il processo di implementazione degli ACL:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!

 permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
 permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
 permit tcp host <trusted-management-stations> any eq 22
 permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Dopo la creazione, l'iACL deve essere applicato a tutte le interfacce con dispositivi non di infrastruttura. Ciò include le interfacce che si connettono ad altre organizzazioni, segmenti di accesso remoto, segmenti di utenti e segmenti nei centri dati.

Per ulteriori informazioni sugli ACL dell'infrastruttura, consultare il documento sulla protezione del core: Access Control List di protezione dell'infrastruttura.

Filtro pacchetti ICMP

Il protocollo ICMP (Internet Control Message Protocol) è progettato come protocollo di controllo IP. Pertanto, i messaggi trasmessi possono interagire in modo significativo con i protocolli TCP e IP in generale. Mentre gli strumenti di rete, ping e traceroute, per risolvere i problemi relativi all'uso di ICMP, la connettività ICMP esterna è raramente richiesta per il corretto funzionamento della rete.

Il software Cisco IOS offre la funzionalità per filtrare specificamente i messaggi ICMP per nome o tipo e codice. Questo ACL di esempio, che deve essere usato con le voci di controllo di accesso (ACE) degli esempi precedenti, consente i ping da stazioni di gestione attendibili e server NMS e blocca tutti gli altri pacchetti ICMP:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!

 permit icmp host <trusted-management-stations> any echo
 permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Filtra frammenti IP

Il processo di filtro dei pacchetti IP frammentati può rappresentare una sfida per i dispositivi di sicurezza. Infatti, le informazioni di layer 4 utilizzate per filtrare i pacchetti TCP e UDP sono presenti solo nel frammento iniziale. Il software Cisco IOS utilizza un metodo specifico per controllare i frammenti non iniziali rispetto agli elenchi degli accessi configurati. Il software Cisco IOS valuta questi frammenti non iniziali rispetto all'ACL e ignora qualsiasi informazione filtrata di layer 4. In questo modo, i frammenti non iniziali verranno valutati solo sulla parte di layer 3 di qualsiasi ACE configurata. 

In questa configurazione di esempio, se un pacchetto TCP destinato a 192.168.1.1 sulla porta 22 viene frammentato in transito, il frammento iniziale viene scartato, come previsto, dalla seconda ACE, in base alle informazioni di layer 4 contenute nel pacchetto. Tuttavia, tutti i frammenti (non iniziali) che rimangono sono autorizzati dalla prima voce ACE, in base completamente alle informazioni di layer 3 contenute nel pacchetto e nella voce ACE. Questo scenario viene mostrato nella configurazione seguente:

!

ip access-list extended ACL-FRAGMENT-EXAMPLE
 permit tcp any host 192.168.1.1 eq 80
 deny tcp any host 192.168.1.1 eq 22
!

A causa della natura non intuitiva della gestione dei frammenti, i frammenti IP sono spesso autorizzati inavvertitamente dagli ACL. La frammentazione è spesso utilizzata nei tentativi di eludere il rilevamento da parte dei sistemi di rilevamento delle intrusioni. Per questi motivi, i frammenti IP sono spesso usati negli attacchi e il motivo per cui devono essere filtrati esplicitamente all'inizio di tutti gli ACL configurati. Questo esempio di ACL include la filtrazione completa dei frammenti IP. Le funzionalità di questo esempio devono essere utilizzate con le funzionalità degli esempi precedenti.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Per ulteriori informazioni sulla gestione dei pacchetti IP frammentati da parte degli ACL, consultare il documento Access Control Lists and IP Fragments.

Supporto ACL per filtrare le opzioni IP

Dal software Cisco IOS versione 12.3(4)T, è supportato l'uso degli ACL per filtrare i pacchetti IP, in base alle opzioni IP contenute nel pacchetto. Le opzioni IP rappresentano una sfida per la sicurezza dei dispositivi di rete in quanto devono essere elaborate come pacchetti di eccezione. Ciò richiede un livello di sforzo della CPU che non è richiesto dai pacchetti tipici che attraversano la rete. La presenza di opzioni IP all'interno di un pacchetto può anche indicare un tentativo di sovvertire i controlli di sicurezza sulla rete o di alterare in altro modo le caratteristiche di transito di un pacchetto. Per questi motivi, i pacchetti con opzioni IP devono essere filtrati al margine della rete.

Questo esempio deve essere usato con le voci ACE degli esempi precedenti per includere la filtrazione completa dei pacchetti IP che contengono le opzioni IP:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Supporto ACL per filtrare in base al valore TTL

Dal software Cisco IOS versione 12.4(2)T, è stato aggiunto un filtro di supporto ACL dei pacchetti IP, basato sul valore TTL (Time to Live). Il valore TTL di un datagramma IP viene ridotto da ciascun dispositivo di rete man mano che il pacchetto passa dall'origine alla destinazione. Anche se i valori iniziali variano a seconda del sistema operativo, quando il valore TTL di un pacchetto raggiunge zero, il pacchetto deve essere scartato. Il dispositivo che riduce il valore TTL a zero, e quindi scarta il pacchetto, deve generare e inviare un messaggio ICMP "Tempo scaduto" all'origine del pacchetto.

La generazione e la trasmissione di questi messaggi costituisce un processo di eccezione. I router possono eseguire questa funzione quando il numero di pacchetti IP in scadenza è basso, ma se il numero di pacchetti in scadenza è alto, la generazione e la trasmissione di questi messaggi possono utilizzare tutte le risorse CPU disponibili. Questo presenta un vettore di attacco DoS. Per questo motivo, i dispositivi devono essere protetti dagli attacchi DoS che usano un'alta velocità di pacchetti IP, che stanno per scadere.

Si consiglia alle organizzazioni di filtrare i pacchetti IP con valori TTL bassi al bordo della rete. Il filtraggio completo dei pacchetti con valori TTL insufficienti per attraversare la rete riduce la minaccia di attacchi basati su TTL.

In questo esempio, un ACL filtra i pacchetti con valori TTL inferiori a sei. Ciò fornisce la protezione dagli attacchi TTL in scadenza per le reti fino a cinque hop di larghezza.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets with TTL values insufficient to traverse the network
!

 deny ip any any ttl lt 6
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Nota: alcuni protocolli utilizzano in modo legittimo pacchetti con valori TTL bassi. eBGP è uno di questi protocolli. Per ulteriori informazioni su come mitigare gli attacchi TTL basati sulla scadenza, fare riferimento a TTL Expiry Attack Identification and Mitigation (Identificazione e mitigazione degli attacchi TTL in scadenza).

Sessioni di gestione interattiva protette

Le sessioni di gestione per i dispositivi consentono di visualizzare e raccogliere informazioni su un dispositivo e sulle relative operazioni. Se queste informazioni vengono divulgate a un utente malintenzionato, il dispositivo può diventare oggetto di un attacco, essere compromesso e utilizzato per eseguire ulteriori attacchi. Chiunque disponga di accesso privilegiato a un dispositivo ha la capacità di esercitare il controllo amministrativo completo su tale dispositivo. È fondamentale proteggere le sessioni di gestione per impedire la divulgazione delle informazioni e l'accesso non autorizzato.

Protezione del piano di gestione

Nel software Cisco IOS versione 12.4(6)T e successive, la funzione di protezione del piano di gestione (MPP) consente agli amministratori di imporre restrizioni sulle diverse interfacce del traffico di gestione ricevuto da un dispositivo. In questo modo l'amministratore può esercitare un ulteriore controllo su un dispositivo e sulla modalità di accesso al dispositivo.

Nell'esempio viene mostrato come abilitare il protocollo MPP per consentire solo SSH e HTTPS sull'interfaccia Gigabit Ethernet 0/1:

!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https
!

Per ulteriori informazioni sul protocollo MPP, fare riferimento a Management Plane Protection.

Nota: MPP non supporta IPv6 ed è limitato al percorso di input IPv4. Poiché IPv6 non è filtrato, utilizzare CoPP in ambienti misti IPv4/IPv6.

Control Plane Protection

La funzionalità Control Plane Protection (CPPr) si basa sulla funzionalità Control Plane Policing per limitare e controllare il traffico aereo destinato al processore di routing del dispositivo Cisco IOS. Aggiunto nel software Cisco IOS versione 12.4(4)T, il protocollo CPPr divide il control plane in categorie separate, note come sottointerfacce. Esistono tre sottointerfacce del control plane: Host, Transit e CEF-Exception. Inoltre, CPPr include le seguenti funzioni di protezione del control plane:

• Funzione di filtro delle porte: consente all'amministratore di controllare o rilasciare i pacchetti inviati alle porte TCP e UDP chiuse o non in ascolto.
  
  
• Caratteristica dei criteri di soglia della coda: limita il numero di pacchetti per un protocollo specificato consentiti nella coda di input IP del control plane.

CPPr consente agli amministratori di classificare, controllare e limitare il traffico inviato a un dispositivo a scopo di gestione tramite la sottointerfaccia host. Esempi di pacchetti classificati per la categoria della sottointerfaccia host includono il traffico di gestione, come SSH o Telnet e i protocolli di routing.

Nota: CPPr non supporta IPv6 ed è limitato al percorso di input IPv4.

Per ulteriori informazioni sulla funzione Cisco CPPr, consultare il documento Control Plane Protection Feature Guide - 12.4T and Understanding Control Plane Protection.

Sessioni di gestione della crittografia

Poiché le informazioni possono essere divulgate in una sessione di gestione interattiva, questo traffico deve essere crittografato in modo che un utente malintenzionato non possa accedere ai dati trasmessi. La crittografia del traffico consente una connessione di accesso remoto sicura al dispositivo. Se il traffico di una sessione di gestione viene inviato in rete in formato non crittografato, un utente non autorizzato può ottenere informazioni riservate sul dispositivo e sulla rete.

Un amministratore può stabilire una connessione crittografata e sicura per la gestione dell'accesso remoto a un dispositivo con le funzionalità SSH o HTTPS (Secure Hypertext Transfer Protocol). Il software Cisco IOS supporta SSH versione 1.0 (SSHv1), SSH versione 2.0 (SSHv2) e HTTPS che utilizza Secure Sockets Layer (SSL) e Transport Layer Security (TLS) per l'autenticazione e la crittografia dei dati. SSHv1 e SSHv2 non sono compatibili. SSHv1 non è sicuro e non è standardizzato, quindi si consiglia di non utilizzarlo se SSHv2 è un'opzione.

Il software Cisco IOS supporta anche il protocollo SCP (Secure Copy Protocol), che consente una connessione crittografata e sicura per copiare le configurazioni dei dispositivi o le immagini software. SCP si basa sul protocollo SSH. Nell'esempio, la configurazione abilita SSH su un dispositivo Cisco IOS:

!

ip domain-name example.com
!

crypto key generate rsa modulus 2048
!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!

line vty 0 4
 transport input ssh
!

Questo esempio di configurazione abilita i servizi SCP:

!

ip scp server enable
!

Questo esempio di configurazione è per i servizi HTTPS:

!

crypto key generate rsa modulus 2048
!

ip http secure-server
!

Per ulteriori informazioni sulla funzionalità SSH del software Cisco IOS, consultare le domande frequenti sulla configurazione di Secure Shell sui router e gli switch con Cisco IOS e Secure Shell (SSH).

SSHv2

La funzione di supporto SSHv2, introdotta nel software Cisco IOS versione 12.3(4)T, consente all'utente di configurare SSHv2. Il supporto SSHv1 è stato implementato in una versione precedente del software Cisco IOS. SSH viene eseguito su un livello di trasporto affidabile e fornisce solide funzionalità di autenticazione e crittografia. L'unico trasporto affidabile definito per SSH è TCP. SSH consente di accedere in modo sicuro ai comandi di un altro computer o dispositivo in rete e di eseguirli in modo sicuro. La funzionalità SCP (Secure Copy Protocol), memorizzata su tunnel SSH, consente il trasferimento sicuro dei file.

Se il comando ip ssh versione 2 non è configurato in modo esplicito, Cisco IOS abilita SSH versione 1.9. SSH v1 e SSH v2 sono compatibili con entrambe le connessioni. SSHv1 è considerato non sicuro e può avere effetti negativi sul sistema. Se il protocollo SSH è abilitato, si consiglia di disabilitare SSHv1 usando il comando ip ssh versione 2.

Questa configurazione di esempio abilita SSHv2 (con SSHv1 disabilitato) su un dispositivo Cisco IOS:

!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

ip ssh time-out 60  
ip ssh authentication-retries 3  
ip ssh source-interface GigabitEthernet 0/1    

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

per ulteriori informazioni sull'uso del protocollo SSHv2, fare riferimento al supporto Secure Shell versione 2.

Miglioramenti SSHv2 per le chiavi RSA

Cisco IOS SSHv2 supporta metodi di autenticazione interattivi da tastiera e basati su password. La funzione SSHv2 Enhancements for RSA Keys supporta anche l'autenticazione con chiave pubblica basata su RSA per il client e il server.

Per l'autenticazione degli utenti, l'autenticazione RSA utilizza una coppia di chiavi privata/pubblica associata a ciascun utente per l'autenticazione. Per completare l'autenticazione, l'utente deve generare una coppia di chiavi privata/pubblica sul client e configurare una chiave pubblica sul server SSH Cisco IOS.

Un utente SSH che tenta di stabilire le credenziali fornisce una firma crittografata con la chiave privata. La firma crittografata e la chiave pubblica dell'utente vengono inviate al server SSH per l'autenticazione. Il server SSH calcola un hash sulla chiave pubblica fornita dall'utente. L'hash viene utilizzato per determinare se nel server è presente una voce corrispondente. Se viene trovata una corrispondenza, la verifica del messaggio basata su RSA viene eseguita con la chiave pubblica. L'utente viene quindi autenticato o non autorizzato in base alla firma crittografata.

Per l'autenticazione del server, il client SSH Cisco IOS deve assegnare una chiave host per ciascun server. Quando il client tenta di stabilire una sessione SSH con un server, riceve la firma del server come parte del messaggio di scambio chiave. Se sul client è attivato il flag di controllo rigoroso della chiave host, il client verifica se dispone della voce della chiave host corrispondente al server preconfigurato. Se viene trovata una corrispondenza, il client tenta di convalidare la firma con la chiave host del server. Se l'autenticazione del server ha esito positivo, la sessione continua; in caso contrario viene terminata e viene visualizzato un messaggio di errore Autenticazione server.

Questa configurazione di esempio abilita l'uso delle chiavi RSA con SSHv2 su un dispositivo Cisco IOS:

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using 
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits 
!

 crypto key generate rsa usage-keys label sshkeys modulus 2048
!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120
!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5
!
! Configure SSH version 2
!

ip ssh version 2 
!

  

per ulteriori informazioni sull'uso delle chiavi RSA con SSHv2, fare riferimento a Secure Shell versione 2 Enhancements for RSA Keys.

Questa configurazione di esempio consente al server SSH Cisco IOS di eseguire l'autenticazione RSA. L'autenticazione dell'utente ha esito positivo se la chiave pubblica RSA memorizzata sul server viene verificata con la coppia di chiavi pubblica o privata memorizzata sul client.

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Configure the SSH username
!

        username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash command (followed by the SSH key type and version.)
!

Per ulteriori informazioni sull'uso delle chiavi RSA con SSHv2, consultare il documento sulla configurazione del server SSH Cisco IOS per eseguire l'autenticazione RSA.

Questa configurazione di esempio consente al client SSH Cisco IOS di eseguire l'autenticazione del server basata su RSA.

!
!

hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name
!
! Specify the RSA public-key of the remote peer 
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash <key-type> <key-name> command (followed by the SSH key 
! type and version.)
!
! Ensure that server authentication takes place - The connection will be 
! terminated on a failure
!

ip ssh stricthostkeycheck 
!

Per ulteriori informazioni sull'uso delle chiavi RSA con SSHv2, consultare il documento sulla configurazione del client SSH Cisco IOS per eseguire l'autenticazione server basata su RSA.

Porte console e AUX

Nei dispositivi Cisco IOS, le porte console e le porte ausiliarie (AUX) sono linee asincrone che possono essere utilizzate per l'accesso locale e remoto a un dispositivo. Tenere presente che le porte console sui dispositivi Cisco IOS dispongono di privilegi speciali. In particolare, questi privilegi consentono a un amministratore di eseguire la procedura di recupero della password. Per eseguire il recupero della password, un utente non autenticato dovrebbe avere accesso alla porta della console e la possibilità di interrompere l'alimentazione al dispositivo o di causarne l'arresto anomalo.

Tutti i metodi utilizzati per accedere alla porta console di un dispositivo devono essere protetti in modo equivalente alla protezione imposta per l'accesso privilegiato a un dispositivo. I metodi utilizzati per proteggere l'accesso devono includere l'uso di password AAA, exec-timeout e modem (se il modem è collegato alla console).

Se il recupero della password non è necessario, un amministratore può rimuovere la possibilità di eseguire la procedura di recupero della password tramite il comando di configurazione globale no service password-recovery; tuttavia, dopo aver abilitato il comando no service password-recovery, un amministratore non può eseguire il recupero della password su un dispositivo.

Nella maggior parte dei casi, la porta AUX del dispositivo deve essere disabilitata per impedire l'accesso non autorizzato. Una porta AUX può essere disabilitata con questi comandi:

!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password
!

Controllare le righe vty e tty

Le sessioni di gestione interattive nel software Cisco IOS utilizzano un tty o un tty virtuale (vty). Un tty è una linea asincrona locale alla quale un terminale può essere collegato per l'accesso locale al dispositivo o a un modem per l'accesso remoto a un dispositivo. Si noti che i tty possono essere utilizzati per le connessioni alle porte console di altri dispositivi. Questa funzione consente a un dispositivo con linee tty di fungere da console server dove è possibile stabilire connessioni attraverso la rete alle porte console dei dispositivi connessi alle linee tty. È necessario controllare anche le linee tty per queste connessioni inverse sulla rete.

Una linea vty viene utilizzata per tutte le altre connessioni di rete remote supportate dal dispositivo, indipendentemente dal protocollo (SSH, SCP o Telnet sono esempi). Per garantire che un dispositivo sia accessibile da una sessione di gestione locale o remota, è necessario applicare controlli appropriati sia sulla linea vty che su quella tty. I dispositivi Cisco IOS hanno un numero limitato di linee vty; il numero di linee disponibili può essere determinato con il comando show line EXEC. Quando tutte le linee vty sono in uso, non è possibile stabilire nuove sessioni di gestione, il che può creare una condizione DoS per l'accesso al dispositivo.

Il controllo di accesso più semplice a un vty o tty di un dispositivo consiste nell'utilizzare l'autenticazione su tutte le linee, indipendentemente dalla posizione del dispositivo sulla rete. Questa operazione è critica per le linee vty in quanto sono accessibili dalla rete. La rete può accedere anche a una linea tty collegata a un modem utilizzato per l'accesso remoto alla periferica o a una linea tty collegata alla porta console di altre periferiche. Altre forme di controllo degli accessi vty e tty possono essere applicate con i comandi di input transport o di configurazione access-class, con le funzionalità CoPP e CPPr o se si applicano elenchi degli accessi alle interfacce sul dispositivo.

L'autenticazione può essere imposta tramite l'uso del server AAA, il metodo consigliato per l'accesso autenticato a un dispositivo, con l'uso del database utenti locale, o tramite una semplice autenticazione tramite password configurata direttamente sulla riga vty o tty.

il comando exec-timeout deve essere usato per disconnettere le sessioni sulle righe vty o tty lasciate inattive. il comando service tcp-keepalives-in deve essere usato anche per abilitare i pacchetti TCP keepalive sulle connessioni in arrivo al dispositivo. In questo modo, il dispositivo sull'estremità remota della connessione è ancora accessibile e le connessioni half-open o orfane vengono rimosse dal dispositivo Cisco IOS locale.

Controllo del trasporto per le linee vty e tty

Configurare un vty e tty in modo che accetti solo connessioni di gestione dell'accesso remoto crittografate e sicure al dispositivo o attraverso il dispositivo, se utilizzato come console server. In questa sezione vengono illustrati i tipi di chiamata perché è possibile connettere tali linee alle porte console di altri dispositivi, in modo da rendere il tty accessibile in rete. Per impedire la divulgazione delle informazioni o l'accesso non autorizzato ai dati trasmessi tra l'amministratore e il dispositivo, utilizzare il protocollo transport input ssh anziché i protocolli non crittografati, ad esempio Telnet e rlogin. La configurazione transport input none può essere abilitata su un tty, disabilitando l'uso della riga tty per le connessioni alla console inversa.

Entrambe le linee vty e tty consentono a un amministratore di connettersi ad altre periferiche. Per limitare il tipo di trasporto che un amministratore può utilizzare per le connessioni in uscita, utilizzare il comando di configurazione della riga di output del trasporto. Se le connessioni in uscita non sono necessarie, utilizzare l'output di trasporto none. Tuttavia, se le connessioni in uscita sono consentite, applicare un metodo di accesso remoto crittografato e sicuro per la connessione tramite l'utilizzo dell'output di trasporto ssh.

Nota: se supportato, IPSec può essere utilizzato per connessioni di accesso remoto crittografate e sicure a un dispositivo. Se si utilizza IPSec, viene aggiunto un ulteriore sovraccarico della CPU al dispositivo. Tuttavia, il protocollo SSH deve essere ancora applicato come trasporto, anche quando si usa IPSec.

Banner di avviso

In alcune giurisdizioni legali, può essere impossibile perseguire e illegale monitorare utenti malintenzionati, a meno che non siano stati informati che non è loro consentito utilizzare il sistema. Un metodo per inviare questa notifica è inserire le informazioni in un messaggio banner configurato con il comando Cisco IOS software banner login.

I requisiti di notifica legale sono complessi, variano in base alla giurisdizione e alla situazione e richiedono una discussione con il consulente legale. Anche all'interno delle giurisdizioni, le opinioni legali possono differire. In collaborazione con il consulente legale, uno striscione può fornire alcune o tutte queste informazioni:

• Notare che il sistema deve essere connesso o utilizzato solo da personale specificamente autorizzato e forse anche informazioni su chi può autorizzare l'uso.
  
  
• Si noti che qualsiasi utilizzo non autorizzato del sistema è illegale e può essere soggetto a sanzioni civili e penali.
  
  
• Si noti che qualsiasi utilizzo del sistema può essere registrato o monitorato senza ulteriori avvisi e che i registri risultanti possono essere utilizzati come prova in tribunale.
  
  
• Avvisi specifici richiesti dalle leggi locali.

Da un punto di vista della sicurezza, piuttosto che da un punto di vista legale, un banner di accesso non deve contenere informazioni specifiche sul nome, il modello, il software o la proprietà del router. Tali informazioni possono essere utilizzate in modo non corretto da utenti malintenzionati.

Autenticazione, autorizzazione e accounting

Il framework AAA (Authentication, Authorization, and Accounting) è fondamentale per proteggere l'accesso interattivo ai dispositivi di rete. La struttura AAA fornisce un ambiente altamente configurabile che può essere personalizzato in base alle esigenze della rete.

Autenticazione TACACS+

TACACS+ è un protocollo di autenticazione che i dispositivi Cisco IOS possono utilizzare per autenticare gli utenti di gestione su un server AAA remoto. Questi utenti possono accedere al dispositivo Cisco IOS tramite SSH, HTTPS, telnet o HTTP.

L'autenticazione TACACS+, o più in generale l'autenticazione AAA, consente di usare i singoli account utente per ciascun amministratore di rete. Quando non si dipende da una singola password condivisa, la sicurezza della rete è migliorata e la responsabilità è rafforzata.

RADIUS è un protocollo simile a TACACS+; tuttavia, cripta solo la password inviata attraverso la rete. Al contrario, TACACS+ cripta l'intero payload TCP, che include sia il nome utente che la password. Per questo motivo, usare TACACS+ anziché RADIUS quando TACACS+ è supportato dal server AAA. Per un confronto più dettagliato dei due protocolli, fare riferimento a TACACS+ e RADIUS Comparison.

L'autenticazione TACACS+ può essere abilitata su un dispositivo Cisco IOS con una configurazione simile a quella dell'esempio seguente:

!

aaa new-model
aaa authentication login default group tacacs+
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

La configurazione precedente può essere utilizzata come punto di partenza per un modello di autenticazione AAA specifico dell'organizzazione. 

Un elenco di metodi è un elenco sequenziale che descrive i metodi di autenticazione da sottoporre a query per autenticare un utente. Gli elenchi di metodi consentono di designare uno o più protocolli di protezione da utilizzare per l'autenticazione e quindi di garantire un sistema di backup per l'autenticazione in caso di errore del metodo iniziale. Il software Cisco IOS utilizza il primo metodo elencato che accetta o rifiuta correttamente un utente. I metodi successivi vengono tentati solo se quelli precedenti hanno esito negativo a causa della mancata disponibilità del server o di una configurazione errata.

Fallback autenticazione

Se tutti i server TACACS+ configurati non sono più disponibili, un dispositivo Cisco IOS può fare affidamento sui protocolli di autenticazione secondari. Le configurazioni tipiche includono l'uso dell'autenticazione locale o l'abilitazione dell'autenticazione se tutti i server TACACS+ configurati non sono disponibili.

L'elenco completo delle opzioni per l'autenticazione su dispositivo include enable, local e line. Ogni opzione presenta dei vantaggi. L'utilizzo dell'enable secretalgoritmo è preferito in quanto il segreto viene sottoposto a hashing con un algoritmo unidirezionale che è intrinsecamente più sicuro dell'algoritmo di crittografia utilizzato con le password di tipo 7 per l'autenticazione di linea o locale.

Tuttavia, nelle versioni software Cisco IOS che supportano l'utilizzo di password segrete per gli utenti definiti localmente, può essere opportuno eseguire il fallback all'autenticazione locale. Ciò consente di creare un utente definito localmente per uno o più amministratori di rete. Se TACACS+ non è completamente disponibile, ciascun amministratore può utilizzare il nome utente e la password locali. Sebbene questa azione accresca la responsabilità degli amministratori di rete nelle interruzioni TACACS+, aumenta in modo significativo il carico amministrativo in quanto è necessario mantenere gli account utente locali su tutti i dispositivi di rete.

Questo esempio di configurazione si basa sull'esempio di autenticazione TACACS+ precedente per includere l'autenticazione di fallback alla password configurata localmente con il enable secret comando:

!

enable secret <password>
!

aaa new-model
aaa authentication login default group tacacs+ enable
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

Utilizzo di password di tipo 7

Originariamente concepite per consentire una rapida decrittografia delle password archiviate, le password Type 7 non rappresentano una forma sicura di memorizzazione delle password. Sono disponibili numerosi strumenti per decrittografare facilmente queste password. Evitare di usare password di tipo 7 a meno che non siano richieste da una funzionalità in uso sul dispositivo Cisco IOS.

Utilizzare il tipo 9 (scrypt) quando possibile:

username <username> privilege 15 algorithm-type scrypt secret <secret>

La rimozione di password di questo tipo può essere eseguita tramite l'autenticazione AAA e l'utilizzo della funzione Sicurezza potenziata delle password, che consente di utilizzare password segrete con utenti definiti localmente dal comando di configurazione username globale. Se non è possibile impedire completamente l'utilizzo di password di tipo 7, considerare queste password offuscate, non crittografate.

Per ulteriori informazioni sulla rimozione delle password di tipo 7, vedere la sezione Protezione avanzata di General Management Plane.

Autorizzazione comando TACACS+

L'autorizzazione dei comandi con TACACS+ e AAA fornisce un meccanismo che consente o nega ciascun comando immesso da un utente amministrativo. Quando l'utente immette i comandi EXEC, Cisco IOS invia ciascun comando al server AAA configurato. Il server AAA utilizza i criteri configurati per autorizzare o negare il comando per l'utente specifico.

È possibile aggiungere questa configurazione al precedente esempio di autenticazione AAA per implementare l'autorizzazione del comando:

!

aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none 
aaa authorization commands 15 default group tacacs none
!

Accounting comando TACACS+

Quando è stata configurata, l'accounting dei comandi AAA invia informazioni su ciascun comando EXEC immesso ai server TACACS+ configurati. Le informazioni inviate al server TACACS+ includono il comando eseguito, la data di esecuzione e il nome utente di chi lo ha immesso. L'accounting dei comandi non è supportato con RADIUS.

Questa configurazione di esempio abilita l'accounting dei comandi AAA per i comandi EXEC immessi ai livelli di privilegio zero, uno e 15. Questa configurazione si basa su esempi precedenti che includono la configurazione dei server TACACS.

!

aaa accounting exec default start-stop group tacacs 
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs
!

Server AAA ridondanti

I server AAA utilizzati in un ambiente possono essere ridondanti e installati in modo fault-tolerant. In questo modo, è possibile garantire l'accesso interattivo alla gestione, ad esempio SSH, nel caso in cui un server AAA non sia disponibile.

Quando si progetta o si implementa una soluzione server AAA ridondante, tenere presenti le seguenti considerazioni:

• Disponibilità dei server AAA al momento di potenziali errori di rete
  
  
• Posizionamento geograficamente distribuito dei server AAA
  
  
• Caricamento su singoli server AAA in condizioni di stato stazionario e di errore
  
  
• Latenza di rete tra server di accesso alla rete e server AAA
  
  
• Sincronizzazione database server AAA

Per ulteriori informazioni, fare riferimento a Distribuire i server di controllo di accesso.

Rafforzamento del protocollo SNMP (Simple Network Management Protocol)

In questa sezione vengono evidenziati diversi metodi che è possibile utilizzare per proteggere la distribuzione di SNMP nei dispositivi Cisco IOS. È di fondamentale importanza proteggere in modo appropriato il protocollo SNMP per proteggere la riservatezza, l'integrità e la disponibilità dei dati di rete e dei dispositivi di rete attraverso cui transitano. L'SNMP fornisce una vasta gamma di informazioni sullo stato dei dispositivi di rete. Proteggere queste informazioni da utenti malintenzionati che desiderano utilizzare questi dati per eseguire attacchi alla rete.

Stringhe della community SNMP

Le stringhe della community sono password applicate a un dispositivo Cisco IOS per limitare l'accesso, sia di sola lettura che di lettura/scrittura, ai dati SNMP sul dispositivo. Queste stringhe della community, come tutte le password, vengono scelte con cura per evitare che siano insignificanti. Modificare le stringhe della community a intervalli regolari e in conformità con i criteri di sicurezza della rete. Ad esempio, modificare le stringhe quando un amministratore di rete cambia ruolo o lascia la società.

Queste righe di configurazione configurano una stringa della community di sola lettura di READONLY e una stringa della community di lettura/scrittura di READWRITE:

!

snmp-server community READONLY RO
snmp-server community READWRITE RW  
!

Nota: gli esempi di stringhe della community precedenti sono stati scelti per spiegare chiaramente l'utilizzo di queste stringhe. Per gli ambienti di produzione, scegliere le stringhe della community con cautela e includere una serie di simboli alfabetici, numerici e non alfanumerici. 

Per ulteriori informazioni su questa funzione, consultare la guida di riferimento dei comandi SNMP di Cisco IOS.

Stringhe della community SNMP con ACL

Oltre alla stringa della community, applicare un ACL che limiti ulteriormente l'accesso SNMP a un gruppo selezionato di indirizzi IP di origine. Questa configurazione limita l'accesso SNMP in sola lettura ai dispositivi host terminali che risiedono nello spazio di indirizzi 192.168.100.0/24 e limita l'accesso SNMP in lettura/scrittura solo al dispositivo host terminale a 192.168.100.1.

Nota: i dispositivi autorizzati da questi ACL richiedono la stringa della community appropriata per accedere alle informazioni SNMP richieste.

!

access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1
!

snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99
!

Per ulteriori informazioni su questa funzione, consultare la community snmp-server nella guida di riferimento dei comandi di Cisco IOS Network Management.

ACL di infrastruttura

È possibile implementare gli ACL di infrastruttura (iACL) in modo che solo gli host finali con indirizzi IP attendibili possano inviare il traffico SNMP a un dispositivo Cisco IOS. In teoria, un iACL contiene una policy che nega i pacchetti SNMP non autorizzati sulla porta UDP 161.

Per ulteriori informazioni sull'uso degli ACL, vedere la sezione Limitazione dell'accesso alla rete con ACL di infrastruttura di questo documento.

Viste SNMP

Le viste SNMP sono una funzione di sicurezza che consente o nega l'accesso a determinati MIB SNMP. Una volta creata e applicata una vista a una stringa della community con i comandi di configurazione globale snmp-server community-string view, l'accesso ai dati MIB è limitato alle autorizzazioni definite dalla vista. Se appropriato, utilizzare le visualizzazioni per limitare gli utenti di SNMP ai dati necessari.

Questo esempio di configurazione limita l'accesso SNMP con la stringa della community LIMITATA ai dati MIB presenti nel gruppo di sistema:

!

snmp-server view VIEW-SYSTEM-ONLY system include
!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!

Per ulteriori informazioni, fare riferimento a Configurazione del supporto SNMP.

SNMP versione 3

Il protocollo SNMP versione 3 (SNMPv3) è definito dalle specifiche RFC3410, RFC3411, RFC3412, RFC3413, RFC3414 e RFC3415 ed è un protocollo interoperabile basato su standard per la gestione della rete. L'SNMPv3 fornisce un accesso sicuro ai dispositivi perché autentica e facoltativamente cripta i pacchetti sulla rete. Se supportato, SNMPv3 può essere utilizzato per aggiungere un altro livello di sicurezza quando si distribuisce SNMP. L'SNMPv3 è costituito da tre opzioni di configurazione principali:

• no auth - Questa modalità non richiede alcuna autenticazione o crittografia dei pacchetti SNMP
  
  
• auth - Questa modalità richiede l'autenticazione del pacchetto SNMP senza crittografia
  
  
• priv - Questa modalità richiede sia l'autenticazione che la crittografia (privacy) di ciascun pacchetto SNMP

È necessario che esista un ID motore autorevole per utilizzare i meccanismi di sicurezza SNMPv3 (autenticazione o autenticazione e crittografia) per gestire i pacchetti SNMP. Per impostazione predefinita, l'ID motore viene generato localmente. L'ID del motore può essere visualizzato con il show snmp engineID comando, come mostrato nell'esempio seguente:

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

Nota: se l'ID del motore viene modificato, tutti gli account utente SNMP devono essere riconfigurati.

Il passaggio successivo è quello di configurare un gruppo SNMPv3. Questo comando configura un dispositivo Cisco IOS per SNMPv3 con un gruppo di server SNMP AUTHGROUP e abilita solo l'autenticazione per questo gruppo con la parola chiave auth:

!
snmp-server group AUTHGROUP v3 auth
!

Questo comando configura un dispositivo Cisco IOS per SNMPv3 con un gruppo di server SNMP PRIVGROUP e abilita l'autenticazione e la crittografia per questo gruppo con la parola chiave priv:

!
snmp-server group PRIVGROUP v3 priv
!

Questo comando configura un utente SNMPv3 snmpv3user con una password di autenticazione MD5 di authpassword e una password di crittografia 3DES di privpassword:

!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword
!

Tenere presente che snmp-server user i comandi di configurazione non vengono visualizzati nell'output di configurazione del dispositivo come richiesto dalla RFC 3414. Pertanto, la password dell'utente non è visualizzabile dalla configurazione. Per visualizzare gli utenti configurati, immettere il show snmp user comando, come mostrato nell'esempio:

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Per ulteriori informazioni su questa funzione, fare riferimento a Configurazione del supporto SNMP.

Protezione del piano di gestione

La funzionalità Management Plane Protection (MPP) del software Cisco IOS può essere utilizzata per proteggere il protocollo SNMP perché limita le interfacce attraverso cui il traffico SNMP può terminare sul dispositivo. La funzione MPP consente agli amministratori di designare una o più interfacce come interfacce di gestione. Il traffico di gestione può entrare in un dispositivo solo attraverso queste interfacce di gestione. Dopo l'abilitazione del protocollo MPP, nessuna interfaccia, ad eccezione di quelle di gestione designate, accetta il traffico di gestione della rete destinato al dispositivo.

Il protocollo MPP è un sottoinsieme della funzionalità CPPr e richiede una versione di Cisco IOS che supporti tale funzionalità. Per ulteriori informazioni su CPPr, fare riferimento a Descrizione di Control Plane Protection.

Nell'esempio, il protocollo MPP viene usato per limitare l'accesso SNMP e SSH solo all'interfaccia Fast Ethernet 0/0:

!
control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 
!

per ulteriori informazioni, consultare la Management Plane Protection Feature Guide.

Registrazione delle procedure ottimali

I registri eventi forniscono visibilità sul funzionamento di un dispositivo Cisco IOS e sulla rete in cui è distribuito. Il software Cisco IOS offre diverse opzioni flessibili di configurazione dei registri che possono contribuire a raggiungere gli obiettivi di visibilità e gestione della rete di un'organizzazione.

In queste sezioni vengono illustrate alcune best practice sulle funzionalità di log di base che possono aiutare gli amministratori a utilizzare correttamente le funzionalità di log, con un impatto minimo sulla funzionalità di log di un dispositivo Cisco IOS.

Invia log a una posizione centrale

Si consiglia di inviare le informazioni di registro a un server syslog remoto. Ciò rende possibile correlare e controllare gli eventi di rete e di sicurezza tra i dispositivi di rete in modo più efficace. I messaggi syslog vengono trasmessi in modo non affidabile da UDP e in formato non crittografato. Pertanto, le protezioni offerte da una rete per la gestione del traffico (ad esempio, crittografia o accesso fuori banda) possono essere estese per includere il traffico syslog.

Nell'esempio seguente viene configurato un dispositivo Cisco IOS per inviare le informazioni di registro a un server syslog remoto:

!
logging host <ip-address>
!

Per ulteriori informazioni sulla correlazione dei log, fare riferimento a Identificazione degli incidenti tramite firewall e eventi syslog del router Cisco IOS.

Integrata in Cisco IOS versione 12.4(15)T e originariamente introdotta nella versione 12.0(26)S, la funzione Logging to Local Nonvolatile Storage (ATA Disk) consente di salvare i messaggi di log di sistema su un disco flash ATA (Advanced Technology Attachment). I messaggi salvati su un'unità ATA vengono mantenuti dopo il riavvio di un router.

Queste linee di configurazione configurano 134.217.728 byte (128 MB) di messaggi di log nella directory syslog della memoria flash ATA (disk0), con una dimensione file specificata di 16.384 byte:

logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384

Prima che i messaggi di log vengano scritti su un file sul disco ATA, il software Cisco IOS controlla se lo spazio su disco è sufficiente. In caso contrario, il messaggio del file registro meno recente (con l'indicatore orario) viene eliminato e il file corrente viene salvato. Il formato del nome file è log_month:day:year::time.

Nota: un'unità flash ATA ha uno spazio su disco limitato e deve quindi essere mantenuta per evitare la possibilità di sovrascrivere i dati archiviati.

Nell'esempio viene mostrato come copiare i messaggi di log dal disco flash ATA del router a un disco esterno sul server FTP 192.168.1.129 come parte delle procedure di manutenzione:

copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog

Per ulteriori informazioni su questa funzione, fare riferimento a Registrazione su disco ATA (Local Nonvolatile Storage).

Livello di registrazione

A ogni messaggio di log generato da un dispositivo Cisco IOS viene assegnata una delle otto priorità, dal livello 0, Emergenze, al livello 7, Debug. Se non espressamente richiesto, si consiglia di evitare i registri al livello 7. I registri al livello 7 producono un carico elevato della CPU sul dispositivo, che può causare instabilità del dispositivo e della rete.

Il logging trap livello di comando di configurazione globale viene utilizzato per specificare i messaggi di log da inviare ai server syslog remoti. Il livello specificato indica il messaggio con il livello di gravità più basso inviato. Per i log nel buffer, viene utilizzato il comando logging buffered level.

In questo esempio di configurazione i messaggi di log inviati ai server syslog remoti e al buffer di log locale vengono limitati ai livelli di gravità da 6 (Informativo) a 0 (Emergenze):

!

logging trap 6
logging buffered 6
!

per ulteriori informazioni, fare riferimento a Risoluzione dei problemi, Gestione degli errori e Registrazione.

Non accedere alle sessioni di console o di monitoraggio

Con il software Cisco IOS, è possibile inviare messaggi di log alle sessioni di monitoraggio, ossia sessioni di gestione interattive in cui è terminal monitor stato emesso il comando EXEC, e alla console. Tuttavia, questa operazione può aumentare il carico della CPU di un dispositivo Cisco IOS e pertanto non è consigliata. Inviare invece le informazioni di registro al buffer di registro locale che può essere visualizzato con il show logging comando.

Utilizzare i comandi di configurazione globale no logging console e no logging monitor per disabilitare i registri nella console e monitorare le sessioni. L'esempio di configurazione mostrato di seguito illustra l'utilizzo dei comandi:

!

no logging console
no logging monitor
!

Per ulteriori informazioni sui comandi di configurazione globale, consultare la guida di riferimento dei comandi di Cisco IOS Network Management.

Usa registri nel buffer

Il software Cisco IOS supporta l'uso di un buffer di registro locale in modo che un amministratore possa visualizzare i messaggi di registro generati localmente. Si consiglia vivamente di utilizzare i registri memorizzati nel buffer anziché quelli delle sessioni della console o del monitor.

Quando si configurano i log nel buffer, sono disponibili due opzioni di configurazione rilevanti: la dimensione del buffer del log e le severità dei messaggi memorizzate nel buffer. Le dimensioni del logging buffer file vengono configurate con il comando di configurazione globalelogging buffered size.. Il livello di gravità più basso incluso nel buffer viene configurato con il comando log buffered severity. Un amministratore può visualizzare il contenuto del buffer di registro tramite il comando show logging EXEC.

Questo esempio di configurazione include la configurazione di un buffer di registro di 16.384 byte e un livello di gravità pari a 6, Informativo, che indica che i messaggi di livello da 0 (Emergenze) a 6 (Informativo) sono archiviati:

!

logging buffered 16384 6
!

Per ulteriori informazioni sui log nel buffer, consultare la guida di riferimento dei comandi di Cisco IOS Network Management.

Configura interfaccia origine di registrazione

Per garantire un maggiore livello di coerenza durante la raccolta e l'analisi dei messaggi di log, è consigliabile configurare in modo statico un'interfaccia di origine di log. A tale scopo, usare il comando logging source-interface interface. Un'interfaccia di origine della registrazione configurata staticamente garantisce che lo stesso indirizzo IP venga visualizzato in tutti i messaggi di registro inviati da un singolo dispositivo Cisco IOS. Per una maggiore stabilità, utilizzare un'interfaccia di loopback come origine del log.

Questo esempio di configurazione illustra l'utilizzo del comando di configurazione globale dell'logging source-interfaceinterfaccia per specificare l'indirizzo IP dell'interfaccia 0 di loopback da utilizzare per tutti i messaggi di log:

!
logging source-interface Loopback 0
!

Per ulteriori informazioni, consultare la guida di riferimento dei comandi di Cisco IOS.

Configura timestamp registro

La configurazione dei timestamp del registro consente di correlare gli eventi tra i dispositivi di rete. È importante implementare una configurazione di timestamp di registro corretta e coerente per garantire la correlazione dei dati di registro. Configurare i timestamp del registro in modo da includere la data e l'ora, con una precisione di millisecondi, e il fuso orario in uso nel dispositivo.

Questo esempio include la configurazione dei timestamp di log, con precisione in millisecondi, all'interno della zona UTC (Coordinated Universal Time):

!
service timestamps log datetime msec show-timezone
!

Se si preferisce non registrare gli orari relativi all'ora UTC, è possibile configurare un fuso orario locale specifico e configurare le informazioni in modo che siano presenti nei messaggi di registro generati. Nell'esempio viene mostrata una configurazione del dispositivo per l'area PST (Pacific Standard Time):

!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!

Gestione configurazione software Cisco IOS

Il software Cisco IOS include diverse funzionalità per abilitare una forma di gestione della configurazione su un dispositivo Cisco IOS. Tali funzionalità includono la funzionalità per archiviare le configurazioni e per eseguire il rollback della configurazione a una versione precedente, nonché per creare un registro delle modifiche della configurazione dettagliato.

Sostituzione della configurazione e rollback della configurazione

Nel software Cisco IOS versione 12.3(7)T e successive, le funzionalità di sostituzione e ripristino della configurazione consentono di archiviare la configurazione del dispositivo Cisco IOS sul dispositivo. Memorizzate manualmente o automaticamente, le configurazioni in questo archivio possono essere utilizzate per sostituire la configurazione corrente in esecuzione con il comando configure replace filename. Ciò è in contrasto con il comando copy filename running-config . Il comando configure replace filename sostituisce la configurazione in esecuzione, a differenza dell'unione eseguita dal copy comando.

Si consiglia di abilitare questa funzione su tutti i dispositivi Cisco IOS della rete. Dopo aver abilitato la funzione, un amministratore può aggiungere all'archivio la configurazione corrente in esecuzione con il archive config EXEC comando. Le configurazioni archiviate possono essere visualizzate con il show archive EXEC comando.

In questo esempio viene illustrata la configurazione dell'archivio di configurazione automatica. In questo esempio viene indicato al dispositivo Cisco IOS di archiviare le configurazioni archiviate come file denominati archived-config-N sul disco0: file system, per mantenere un massimo di 14 backup e per archiviare una volta al giorno (1440 minuti) quando un amministratore esegue il write memory EXEC comando.

!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory
!

Sebbene la funzione di archiviazione della configurazione possa memorizzare fino a 14 configurazioni di backup, si consiglia di valutare i requisiti di spazio prima di utilizzare il maximum comando.

Accesso esclusivo alle modifiche alla configurazione

Aggiunta al software Cisco IOS versione 12.3(14)T, la funzione Accesso esclusivo alle modifiche alla configurazione assicura che solo un amministratore apporti modifiche alla configurazione di un dispositivo Cisco IOS alla volta. Questa funzione consente di eliminare l'impatto indesiderato delle modifiche simultanee apportate ai componenti di configurazione correlati. Questa funzione, configurata con la modalità di comando di configurazione globale, configuration mode exclusive funziona in una delle due modalità seguenti: automatica o manuale. In modalità automatica, la configurazione si blocca automaticamente quando un amministratore esegue il configure terminal EXEC comando. In modalità manuale, l'amministratore utilizza il configure terminal lock comando per bloccare la configurazione quando entra in modalità di configurazione.

L'esempio mostra la configurazione di questa funzione per il blocco automatico della configurazione:

!
configuration mode exclusive auto
!

Configurazione resiliente del software Cisco IOS

Aggiunta nel software Cisco IOS versione 12.3(8)T, la funzionalità di configurazione resiliente permette di archiviare in modo sicuro una copia dell'immagine software e della configurazione del dispositivo Cisco IOS attualmente utilizzati da un dispositivo Cisco IOS. Quando questa funzionalità è attivata, non è possibile modificare o rimuovere i file di backup. È consigliabile attivare questa funzionalità per impedire tentativi di eliminazione dei file sia involontari che dannosi.

!
secure boot-image
secure boot-config!

Dopo aver abilitato questa funzione, è possibile ripristinare una configurazione eliminata o un'immagine software Cisco IOS. Lo stato corrente di questa funzione può essere visualizzato con il show secure boot EXEC comando.

Software Cisco con firma digitale

Aggiunta nel software Cisco IOS versione 15.0(1)M per i router Cisco serie 1900, 2900 e 3900, la funzionalità software Cisco con firma digitale semplifica l'uso del software Cisco IOS con firma digitale e quindi sicuro, tramite la crittografia asimmetrica protetta (chiave pubblica).

Un'immagine con firma digitale trasporta un hash crittografato (con una chiave privata) di se stessa. Una volta effettuato il controllo, il dispositivo decrittografa l'hash con la chiave pubblica associata dalle chiavi che ha nel suo archivio chiavi e calcola anche il proprio hash dell'immagine. Se l'hash decrittografato corrisponde all'hash dell'immagine calcolata, l'immagine non è stata manomessa e può essere considerata attendibile.

Le chiavi software Cisco con firma digitale sono identificate dal tipo e dalla versione della chiave. Una chiave può essere di tipo speciale, di produzione o di rollover. Ai tipi di chiave di produzione e speciale è associata una versione di chiave che aumenta alfabeticamente quando la chiave viene revocata e sostituita. Quando si utilizza la funzionalità Software Cisco con firma digitale, le immagini ROMMON e Cisco IOS normali sono entrambe firmate con una chiave speciale o di produzione. L'immagine ROMMON è aggiornabile e deve essere firmata con la stessa chiave dell'immagine speciale o di produzione caricata.

Questo comando verifica l'integrità dell'immagine c3900-universalk9-mz.SSA nella memoria flash con le chiavi nell'archivio chiavi del dispositivo:

show software authenticity file flash0:c3900-universalk9-mz.SSA

La funzionalità software Cisco con firma digitale è stata integrata anche in Cisco IOS XE versione 3.1.0.SG per gli switch Cisco Catalyst serie 4500 E.

Per ulteriori informazioni su questa funzione, fare riferimento a Software Cisco con firma digitale.

Nel software Cisco IOS versione 15.1(1)T e successive, è stata introdotta la sostituzione della chiave per il software Cisco con firma digitale. La sostituzione e la revoca della chiave sostituiscono e rimuovono una chiave utilizzata per un controllo del software Cisco con firma digitale dall'archivio delle chiavi della piattaforma. In caso di compromissione di una chiave, è possibile revocare solo le chiavi speciali e di produzione.

Una nuova chiave (speciale o di produzione) per un'immagine (speciale o di produzione) viene fornita in un'immagine (di produzione o di revoca) utilizzata per revocare la chiave speciale o di produzione precedente. L'integrità dell'immagine di revoca viene verificata con una chiave di rollover prememorizzata nella piattaforma. La chiave di rollover non viene modificata. Quando si revoca una chiave di produzione, dopo il caricamento dell'immagine di revoca la nuova chiave viene aggiunta all'archivio chiavi e la vecchia chiave associata può essere revocata, a condizione che l'immagine ROMMON venga aggiornata e che la nuova immagine di produzione venga avviata. Quando si revoca una chiave speciale, viene caricata un'immagine di produzione. Questa immagine aggiunge la nuova chiave speciale e può revocare la vecchia chiave speciale. Dopo aver aggiornato ROMMON, è possibile avviare la nuova immagine speciale.

Nell'esempio seguente viene descritta la revoca di una chiave speciale. Con questi comandi viene aggiunta la nuova chiave speciale all'archivio chiavi dall'immagine di produzione corrente, viene copiata una nuova immagine ROMMON (C3900_rom-monitor.srec.SSB) nell'area di archiviazione (usbflash0:), viene aggiornato il file ROMMON e viene revocata la vecchia chiave speciale:

software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special

Una nuova immagine speciale (c3900-universalk9-mz.SSB) può quindi essere copiata sulla memoria flash per essere caricata e la firma dell'immagine viene verificata con la chiave speciale appena aggiunta (SSB):

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

La revoca e la sostituzione delle chiavi non sono supportate sugli switch Catalyst serie 4500 E con software Cisco IOS XE, anche se questi switch supportano la funzionalità software Cisco con firma digitale.

Per ulteriori informazioni su questa funzione, consultare la sezione Revoca e sostituzione della chiave del software Cisco con firma digitale nella guida al software Cisco con firma digitale.

Notifica e registrazione delle modifiche alla configurazione

La funzionalità di notifica e registrazione delle modifiche alla configurazione, aggiunta nel software Cisco IOS versione 12.3(4)T, consente di registrare le modifiche alla configurazione apportate a un dispositivo Cisco IOS. Il registro viene mantenuto sul dispositivo Cisco IOS e contiene le informazioni utente della persona che ha apportato la modifica, il comando di configurazione immesso e l'ora in cui è stata apportata la modifica. Questa funzionalità viene abilitata con il comando della modalità di configurazione del logger delle modifiche di logging enable configurazione. I comandi hidekeys logging size e le voci facoltative vengono utilizzati per migliorare la configurazione predefinita in quanto impediscono la registrazione dei dati della password e aumentano la lunghezza del log delle modifiche.

Si consiglia di abilitare questa funzionalità per poter comprendere più facilmente la cronologia delle modifiche alla configurazione di un dispositivo Cisco IOS. Inoltre, si consiglia di utilizzare il comando di notify syslog configurazione per abilitare la generazione di messaggi syslog quando viene apportata una modifica alla configurazione.

!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog
!

Dopo aver abilitato la funzionalità Notifica e registrazione delle modifiche alla configurazione, è show archive log config all possibile utilizzare il comando in modalità di esecuzione privilegiata per visualizzare il log di configurazione.

Piano di controllo

Le funzioni del Control Plane sono costituite dai protocolli e dai processi che comunicano tra i dispositivi di rete per lo spostamento dei dati dall'origine alla destinazione. Ciò include protocolli di routing, come Border Gateway Protocol, nonché protocolli come ICMP e Resource Reservation Protocol (RSVP).

È importante che gli eventi nei piani di gestione e di dati non influiscano negativamente sul piano di controllo. Se un evento del piano dati, ad esempio un attacco DoS, influisce sul piano di controllo, l'intera rete può diventare instabile. Queste informazioni sulle funzionalità e sulle configurazioni del software Cisco IOS possono aiutare a garantire la resilienza del control plane.

Protezione avanzata piano di controllo generale

La protezione del control plane di un dispositivo di rete è fondamentale in quanto il control plane garantisce la gestione e il funzionamento dei piani dati. Se il control plane diventa instabile durante un problema di sicurezza, può essere impossibile ripristinare la stabilità della rete.

In molti casi, è possibile disabilitare la ricezione e la trasmissione di determinati tipi di messaggi su un'interfaccia per ridurre al minimo la quantità di carico della CPU necessaria per elaborare i pacchetti non necessari.

Reindirizzamenti IP ICMP

Un router può generare un messaggio di reindirizzamento ICMP quando un pacchetto viene ricevuto e trasmesso sulla stessa interfaccia. In questa situazione, il router inoltra il pacchetto e invia un messaggio di reindirizzamento ICMP al mittente del pacchetto originale. Questo comportamento consente al mittente di ignorare il router e inoltrare i pacchetti futuri direttamente alla destinazione (o a un router più vicino alla destinazione). In una rete IP che funziona correttamente, un router invia i reindirizzamenti solo agli host delle proprie subnet locali. In altre parole, i reindirizzamenti ICMP non superano mai il limite del layer 3.

I messaggi di reindirizzamento ICMP sono di due tipi: reindirizzamento per un indirizzo host e reindirizzamento per un'intera subnet. Un utente malintenzionato può sfruttare la capacità del router di inviare reindirizzamenti ICMP tramite la trasmissione continua dei pacchetti al router, che costringe il router a rispondere con messaggi di reindirizzamento ICMP, con un conseguente impatto negativo sulla CPU e sulle prestazioni del router. Per impedire al router di trasmettere i reindirizzamenti ICMP, usare il comando di configurazione dellno ip redirects'interfaccia.

Impossibile raggiungere ICMP

La filtrazione con un elenco degli accessi all'interfaccia comporta la trasmissione di messaggi ICMP "destinazione irraggiungibile" alla sorgente del traffico filtrato. La generazione di questi messaggi può aumentare l'utilizzo della CPU nel dispositivo. Per impostazione predefinita, nel software Cisco IOS, la generazione di pacchetti ICMP "destinazione irraggiungibile" è limitata a un pacchetto ogni 500 millisecondi. La generazione di messaggi ICMP "destinazione irraggiungibile" può essere disabilitata con il comando di configurazione no ip unreachablesdell'interfaccia. Il limite di velocità ICMP non raggiungibile può essere modificato dal valore predefinito con il comando di configurazione globale ip icmp rate-limit unreachable interval-in-ms.

Proxy ARP

Il proxy ARP è la tecnica con cui un dispositivo, in genere un router, risponde alle richieste ARP destinate a un altro dispositivo. Falsificando la propria identità, il router si assume la responsabilità di indirizzare i pacchetti verso la destinazione reale. L'ARP proxy consente ai computer di una subnet di raggiungere subnet remote senza la configurazione del percorso o un gateway predefinito. Il proxy ARP è definito nella RFC 1027.

L'uso dell'ARP proxy presenta alcuni svantaggi. Ciò può causare un aumento della quantità di traffico ARP sul segmento di rete, l'esaurimento delle risorse e attacchi man-in-the-middle. ARP proxy presenta un vettore di attacco di esaurimento risorse in quanto ogni richiesta ARP proxy consuma una piccola quantità di memoria. Un utente non autorizzato può esaurire tutta la memoria disponibile se invia un numero elevato di richieste ARP.

Gli attacchi man-in-the-middle consentono a un host nella rete di eseguire lo spoofing dell'indirizzo MAC del router, con conseguente trasmissione inavvertitamente del traffico da parte degli host all'autore dell'attacco. Il proxy ARP può essere disabilitato con il comando di configurazione interfaccia no ip proxy-arp.

Limita impatto CPU del traffico del Control Plane

La protezione del control plane è fondamentale. Poiché le prestazioni delle applicazioni e l'esperienza dell'utente finale possono risentire della presenza di traffico di dati e di gestione, la sopravvivenza del control plane garantisce la manutenzione e l'operatività degli altri due piani.

Informazioni sul traffico del Control Plane

Per proteggere correttamente il control plane del dispositivo Cisco IOS, è essenziale comprendere i tipi di traffico a cui la CPU passa tra i processi. Il traffico di commutazione di processo è in genere costituito da due tipi di traffico diversi. Il primo tipo di traffico viene indirizzato al dispositivo Cisco IOS e deve essere gestito direttamente dalla CPU del dispositivo Cisco IOS. Il traffico è costituito dalla categoria Traffico adiacente alla ricezione. Questo traffico contiene una voce nella tabella Cisco Express Forwarding (CEF), in cui l'hop del router successivo è il dispositivo stesso, indicato dal termine receive nell'output della show ip cef CLI. Questa indicazione si riferisce a tutti gli indirizzi IP che richiedono la gestione diretta da parte della CPU del dispositivo Cisco IOS, compresi gli indirizzi IP dell'interfaccia, lo spazio degli indirizzi multicast e lo spazio degli indirizzi di broadcast.

Il secondo tipo di traffico gestito dalla CPU è il traffico del piano dati, ossia il traffico con una destinazione diversa dal dispositivo Cisco IOS stesso, che richiede un'elaborazione speciale da parte della CPU. Sebbene non sia un elenco esaustivo degli impatti sulla CPU del traffico del piano dati, questi tipi di traffico sono commutati in base al processo e possono pertanto influire sul funzionamento del piano di controllo:

• Registrazione Access Control List: il traffico di registro ACL è costituito da qualsiasi pacchetto generato a causa di una corrispondenza (autorizzazione o rifiuto) di una voce ACE su cui viene utilizzata la parola chiave log.
  
  
• Unicast Reverse Path Forwarding (Unicast RPF) - RPF unicast, utilizzato con un ACL, può causare la commutazione di determinati pacchetti.
  
  
• Opzioni IP - Tutti i pacchetti IP con opzioni incluse devono essere elaborati dalla CPU.
  
  
• Frammentazione: tutti i pacchetti IP che richiedono la frammentazione devono essere passati alla CPU per essere elaborati.
  
  
• Scadenza TTL (Time-to-Live): i pacchetti con valore TTL inferiore o uguale a uno richiedono l'invio di messaggi ICMP (Internet Control Message Protocol Time Exceeded) (ICMP Type 11, Code 0), che danno luogo all'elaborazione della CPU.
  
  
• ICMP Unreachables: i pacchetti che causano messaggi ICMP "destinazione irraggiungibile" a causa della loro route, MTU o filtrazione, vengono elaborati dalla CPU.
  
  
• Traffico che richiede una richiesta ARP - Le destinazioni per cui non esiste una voce ARP vengono elaborate dalla CPU.
  
  
• Traffico non IP: tutto il traffico non IP viene elaborato dalla CPU.

In questo elenco vengono illustrati in dettaglio diversi metodi per determinare quali tipi di traffico devono essere elaborati dalla CPU del dispositivo Cisco IOS:

• Il show ip cef comando fornisce le informazioni dell'hop successivo per ciascun prefisso IP contenuto nella tabella CEF. Come indicato in precedenza, le voci che contengono receive come "Hop successivo" sono considerate adiacenze di ricezione e indicano che il traffico deve essere inviato direttamente alla CPU.
  
  
• Il show interface switching comando fornisce informazioni sul numero di pacchetti commutati da un dispositivo.
  
  
• Il show ip traffic comando fornisce informazioni sul numero di pacchetti IP:
  
  
  • con una destinazione locale (ovvero, ricevi traffico adiacente)
  • con opzioni
  • che richiedono la frammentazione
  • che vengono inviati allo spazio degli indirizzi di broadcast
  • inviati allo spazio indirizzi multicast
    
    
• Il traffico di ricezione adiacente può essere identificato usando il comando show ip cache flow. Tutti i flussi destinati al dispositivo Cisco IOS hanno un'interfaccia di destinazione (DstIf) locale.
  
  
• Control Plane Policing può essere usato per identificare il tipo e la velocità del traffico che raggiunge il control plane del dispositivo Cisco IOS. Il control plane policing può essere eseguito tramite l'uso di ACL di classificazione granulare, registri e il show policy-map control-plane comando.

ACL di infrastruttura

Gli ACL di infrastruttura (iACL) limitano la comunicazione esterna ai dispositivi della rete. Gli iACL sono illustrati nella sezione Limitazione dell'accesso alla rete con ACL di infrastruttura di questo documento.

Si consiglia di implementare gli iACL per proteggere il control plane di tutti i dispositivi di rete.

Receive ACL

Per le piattaforme distribuite, l'opzione Receive ACL (ACL ricevuti) può essere usata nel software Cisco IOS versione 12.0(21)S2 per la versione 12000 (GSR), 12.0(24)S per la versione 7500 e 12.0(31)S per la versione 10720. L'rACL protegge il dispositivo dal traffico dannoso prima che questo influisca sul processore di routing. Gli rACL sono progettati per proteggere solo il dispositivo su cui sono configurati e il traffico di transito non è influenzato da un rACL. Di conseguenza, l'indirizzo IP di destinazione "any" (qualsiasi) utilizzato nelle voci ACL di esempio mostrate, fa riferimento solo agli indirizzi IP fisici o virtuali del router. Gli ACL sono anche considerati una best practice per la sicurezza della rete e possono essere considerati un'aggiunta a lungo termine alla buona sicurezza della rete.

Questo è l'ACL del percorso di ricezione che è stato scritto per autorizzare il traffico SSH (porta TCP 22) da host attendibili sulla rete 192.168.100.0/24:

!
!--- Permit SSH from trusted hosts allowed to the device.
!

access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22
!
!--- Deny SSH from all other sources to the RP.
!

access-list 151 deny tcp any any eq 22
!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!

access-list 151 permit ip any any
!
!--- Apply this access list to the receive path.
!

ip receive access-list 151
!

Per identificare e autorizzare il traffico legittimo su un dispositivo e rifiutare tutti i pacchetti indesiderati, consultare il documento GSR: Receive Access Control List.

CoPP

La funzione CoPP può essere utilizzata anche per limitare i pacchetti IP destinati al dispositivo dell'infrastruttura. Nell'esempio, solo il traffico SSH proveniente da host attendibili può raggiungere la CPU del dispositivo Cisco IOS. 

Nota: il traffico proveniente da indirizzi IP sconosciuti o non attendibili può impedire agli host con indirizzi IP assegnati in modo dinamico di stabilire una connessione con il dispositivo Cisco IOS.

!

access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any
!

class-map match-all COPP-KNOWN-UNDESIRABLE
 match access-group 152
!

policy-map COPP-INPUT-POLICY
 class COPP-KNOWN-UNDESIRABLE
  drop
!

control-plane
 service-policy input COPP-INPUT-POLICY
!

Nell'esempio precedente di CoPP, le voci ACL che corrispondono ai pacchetti non autorizzati con l'azione di autorizzazione determinano l'eliminazione di questi pacchetti da parte della funzione di eliminazione della mappa dei criteri, mentre i pacchetti che corrispondono all'azione di negazione non sono interessati dalla funzione di eliminazione della mappa dei criteri.

CoPP è disponibile nei software Cisco IOS versione 12.0S, 12.2SX, 12.2S, 12.3T, 12.4 e 12.4T.

Control Plane Protection

La funzionalità Control Plane Protection (CPPr), introdotta nel software Cisco IOS versione 12.4(4)T, può essere utilizzata per limitare o controllare il traffico aereo destinato alla CPU del dispositivo Cisco IOS. Analogamente al CoPP, il CPPr può limitare il traffico con una maggiore granularità. La CPPr suddivide il piano di controllo aggregato in tre categorie distinte di piani di controllo, note come sottointerfacce. Sono presenti sottointerfacce per le categorie di traffico Host, Transito e CEF-Exception. Inoltre, la CPPr comprende le seguenti funzioni di protezione del control plane:

• Funzione di filtro delle porte - Questa funzione consente di controllare e scartare i pacchetti inviati a porte TCP o UDP chiuse o non in ascolto.
  
  
• Funzione di soglia della coda - Questa funzione limita il numero di pacchetti per un protocollo specificato consentiti nella coda di input IP del control plane.

Per ulteriori informazioni sull'uso della funzione CPPr, fare riferimento a Descrizione di Control Plane Protection (CPPr).

Limitatori di velocità hardware

Cisco Catalyst serie 6500 Supervisor Engine 32 e Supervisor Engine 720 supportano limitatori di velocità basati su hardware (HWRL) specifici della piattaforma per scenari di rete speciali. Questi limitatori di velocità hardware vengono definiti come limitatori di velocità speciali in quanto coprono un insieme predefinito specifico di scenari IPv4, IPv6, unicast e multicast DoS. I moduli HWRL possono proteggere il dispositivo Cisco IOS da una serie di attacchi che richiedono l'elaborazione dei pacchetti da parte della CPU.

Per impostazione predefinita, sono disponibili diversi HWRL abilitati. Per ulteriori informazioni sugli HWRL, fare riferimento a Impostazioni predefinite del limitatore di velocità basato su hardware PFC3.

Per ulteriori informazioni sugli HWRL, fare riferimento a Limitatori di velocità basati su hardware sul PFC3.

Secure BGP

Il Border Gateway Protocol (BGP) è la base di routing di Internet. Di conseguenza, qualsiasi organizzazione con requisiti di connettività più che modesti utilizza spesso BGP. Il BGP è spesso preso di mira dagli aggressori a causa della sua ubiquità e della natura preconfigurata e dimenticata delle configurazioni BGP nelle organizzazioni più piccole. Tuttavia, esistono molte funzionalità di sicurezza specifiche di BGP che possono essere utilizzate per aumentare la sicurezza di una configurazione BGP.

Questo documento offre una panoramica delle principali funzionalità di sicurezza BGP e, ove appropriato, fornisce raccomandazioni per la configurazione.

Protezione basata su TTL

Ogni pacchetto IP contiene un campo da 1 byte noto come TTL (Time to Live). Ogni dispositivo attraversato da un pacchetto IP diminuisce di uno questo valore. Il valore TTL iniziale varia in base al sistema operativo e in genere varia da 64 a 255. Un pacchetto viene scartato quando il relativo valore TTL raggiunge zero.

Conosciuto come GTSM (Generalized TTL-based Security Mechanism) e BGP TTL Security Hack (BTSH), un sistema di sicurezza basato su TTL sfrutta il valore TTL dei pacchetti IP per garantire che i pacchetti BGP ricevuti provengano da un peer connesso direttamente. Questa funzionalità richiede spesso il coordinamento da parte dei router peer; tuttavia, una volta abilitata, può completamente sconfiggere molti attacchi basati su TCP contro BGP.

Il protocollo GTSM per BGP è abilitato con l'ttl-securityopzione per il comando di configurazione del router neighbor BGP. L'esempio mostra come configurare questa funzione:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>
!

Quando si ricevono i pacchetti BGP, il valore TTL viene controllato e deve essere maggiore o uguale a 255, meno il numero di hop specificato.

Autenticazione peer BGP con MD5

L'autenticazione peer con MD5 crea un digest MD5 di ciascun pacchetto inviato come parte di una sessione BGP. In particolare, per generare il digest vengono utilizzate parti delle intestazioni IP e TCP, il payload TCP e una chiave segreta.

Il digest creato viene quindi archiviato nell'opzione TCP Kind 19, creata appositamente a questo scopo dalla RFC 2385 . L'altoparlante BGP ricevente utilizza lo stesso algoritmo e la stessa chiave segreta per rigenerare il digest del messaggio. Se i digest ricevuti e quelli calcolati non sono identici, il pacchetto viene scartato.

L'autenticazione peer con MD5 è configurata con l'passwordopzione per il comando di configurazione del router neighbor BGP. Di seguito viene illustrato l'utilizzo di questo comando:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>
!

Per ulteriori informazioni sull'autenticazione peer BGP con MD5, fare riferimento a Autenticazione router adiacente.

Configura numero massimo prefissi

I prefissi BGP vengono memorizzati da un router. Maggiore è il numero di prefissi che un router deve contenere, maggiore è il consumo di memoria da parte del BGP. In alcune configurazioni è possibile memorizzare un sottoinsieme di tutti i prefissi Internet, ad esempio in configurazioni che utilizzano solo una route predefinita o route per le reti di utenti del provider.

Per evitare l'esaurimento della memoria, configurare il numero massimo di prefissi accettati per peer. È consigliabile configurare un limite per ogni peer BGP.

Quando si configura questa funzionalità con il comando di configurazione del router neighbor maximum-prefix BGP, è necessario un argomento: il numero massimo di prefissi accettati prima della chiusura di un peer. Facoltativamente, è possibile immettere anche un numero compreso tra 1 e 100. Questo numero rappresenta la percentuale del valore massimo dei prefissi rispetto all'invio di un messaggio di registro.

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!

Per ulteriori informazioni sui prefissi massimi per peer, fare riferimento a Configurazione della funzione BGP Maximum-Prefix.

Filtra prefissi BGP con elenchi di prefissi

Gli elenchi di prefissi consentono a un amministratore di rete di autorizzare o negare prefissi specifici inviati o ricevuti da BGP. Ove possibile, utilizzare gli elenchi di prefissi per garantire l'invio del traffico di rete sui percorsi desiderati. Applica gli elenchi di prefissi a ogni peer eBGP sia in entrata che in uscita.

Gli elenchi di prefissi configurati limitano i prefissi inviati o ricevuti a quelli specificamente consentiti dai criteri di route di una rete. Se ciò non è possibile a causa dell'elevato numero di prefissi ricevuti, configurare un elenco di prefissi in modo da bloccare specificamente i prefissi noti non validi. Questi prefissi noti non validi includono lo spazio di indirizzi IP non allocato e le reti riservate per scopi interni o di test dalla RFC 3330. Configurare gli elenchi di prefissi in uscita in modo da consentire specificamente solo i prefissi che un'organizzazione intende annunciare.

In questo esempio di configurazione vengono utilizzati elenchi di prefissi per limitare le route apprese e annunciate. In particolare, solo una route predefinita è consentita in entrata dall'elenco di prefissi BGP-PL-INBOUND e il prefisso 192.168.2.0/24 è l'unica route che può essere annunciata da BGP-PL-OUTBOUND.

!

ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24
!

router bgp <asn>
 neighbor <ip-address> prefix-list BGP-PL-INBOUND in
 neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out
!

Per informazioni complete sui filtri dei prefissi BGP, consultare il documento sulla connessione a un provider di servizi tramite BGP esterno.

Filtra prefissi BGP con elenchi degli accessi ai percorsi di sistema autonomi

Gli elenchi degli accessi al percorso del sistema autonomo BGP (AS) consentono all'utente di filtrare i prefissi ricevuti e annunciati in base all'attributo AS-path di un prefisso. Questa funzione può essere utilizzata con gli elenchi di prefissi per definire un insieme di filtri valido.

In questo esempio di configurazione vengono utilizzati gli elenchi di accesso ai percorsi AS per limitare i prefissi in ingresso a quelli originati dai prefissi in uscita e AS remoti a quelli originati dal sistema autonomo locale. I prefissi originati da tutti gli altri sistemi autonomi vengono filtrati e non installati nella tabella di routing.

!

ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$
!

router bgp <asn>
 neighbor <ip-address> remote-as 65501
 neighbor <ip-address> filter-list 1 in
 neighbor <ip-address> filter-list 2 out
!

Protocolli gateway interni sicuri

La capacità di una rete di inoltrare correttamente il traffico e di eseguire il ripristino in caso di modifiche o errori della topologia dipende da una vista accurata della topologia. Per ottenere questa vista, è spesso possibile eseguire un IGP (Interior Gateway Protocol). Per impostazione predefinita, gli IGP sono dinamici e rilevano router aggiuntivi che comunicano con il particolare IGP in uso. Gli IGP individuano anche le route che possono essere utilizzate quando un collegamento di rete non riesce.

Queste sottosezioni forniscono una panoramica delle principali funzioni di sicurezza IGP. Se necessario, vengono forniti suggerimenti ed esempi relativi a Routing Information Protocol versione 2 (RIPv2), Enhanced Interior Gateway Routing Protocol (EIGRP) e Open Shortest Path First (OSPF).

Autenticazione e verifica del protocollo di routing con Message Digest 5

La mancata protezione dello scambio di informazioni di routing consente all'utente malintenzionato di introdurre informazioni di routing false nella rete. Utilizzare l'autenticazione tramite password con i protocolli di routing tra router per migliorare la sicurezza della rete. Tuttavia, poiché l'autenticazione viene inviata come testo non crittografato, per un utente non autorizzato può essere semplice sovvertire questo controllo di sicurezza.

Quando si aggiungono funzionalità hash MD5 al processo di autenticazione, gli aggiornamenti di routing non contengono più password non crittografate e l'intero contenuto dell'aggiornamento di routing è più resistente alle manomissioni. Tuttavia, l'autenticazione MD5 è ancora soggetta ad attacchi di forza bruta e dizionario se vengono utilizzate password poco affidabili. Si consiglia di utilizzare password con una casualità sufficiente. Dal momento che l'autenticazione MD5 è molto più sicura rispetto all'autenticazione tramite password, questi esempi sono specifici dell'autenticazione MD5. IPSec può essere utilizzato anche per convalidare e proteggere i protocolli di routing, ma in questi esempi non viene descritto in dettaglio l'utilizzo di IPSec.

Sia EIGRP che RIPv2 utilizzano le catene di chiavi come parte della configurazione. Per ulteriori informazioni sulla configurazione e sull'uso delle catene di chiavi, consultare il documento key.

Questa è una configurazione di esempio per l'autenticazione del router EIGRP che utilizza MD5:

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip authentication mode eigrp <as-number> md5
 ip authentication key-chain eigrp <as-number> <key-name>
!

Questo è un esempio di configurazione dell'autenticazione router MD5 per RIPv2. RIPv1 non supporta l'autenticazione.

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>
!

Questa è una configurazione di esempio per l'autenticazione del router OSPF con MD5. OSPF non utilizza catene di chiavi.

!

interface <interface>
 ip ospf message-digest-key <key-id> md5 <password>
!

router ospf <process-id>
 network 10.0.0.0 0.255.255.255 area 0
 area 0 authentication message-digest
!

Per ulteriori informazioni, fare riferimento a Configurazione di OSPF.

Comandi dell'interfaccia passiva

Le perdite di informazioni, o l'introduzione di informazioni false in un IGP, possono essere mitigate attraverso l'uso del passive-interface comando che assiste nel controllo della pubblicità delle informazioni di routing. Si consiglia di non annunciare alcuna informazione alle reti che non rientrano sotto il controllo amministrativo.

Nell'esempio viene mostrato come usare questa funzione:

!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>
!

Filtro di indirizzamento

Per ridurre la possibilità di immettere informazioni di route false sulla rete, utilizzare il filtro di route. A differenza del comando di configurazione del passive-interface router, il routing viene eseguito sulle interfacce quando il filtro di routing è abilitato, ma le informazioni annunciate o elaborate sono limitate.

Per EIGRP e RIP, l'uso del distribute-list comando con la out parola chiave limita le informazioni annunciate, mentre l'uso della in parola chiave limita gli aggiornamenti elaborati. Il distribute-list comando è disponibile per OSPF, ma non impedisce a un router di propagarsi delle route filtrate. È possibile utilizzare il area filter-list comando.

Nell'esempio di EIGRP che segue vengono filtrati gli annunci in uscita con il distribute-list comando e un elenco di prefissi:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> out <interface>
!

Nell'esempio seguente il protocollo EIGRP filtra gli aggiornamenti in ingresso con un elenco di prefissi:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> in <interface>
!

Nell'esempio di OSPF che segue viene utilizzato un elenco di prefissi con il area filter-list command:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 
!

Consumo risorse processo ciclo

I prefissi del protocollo di routing vengono memorizzati da un router e il consumo delle risorse aumenta con l'aggiunta di prefissi che un router deve conservare. Per evitare l'esaurimento delle risorse, configurare il protocollo di routing in modo da limitare l'utilizzo delle risorse. Ciò è possibile con OSPF se si utilizza la funzione di protezione dall'overload del database dello stato del collegamento.

In questo esempio viene illustrata la configurazione della funzione di protezione dall'overload del database dello stato del collegamento OSPF:

!

router ospf <process-id>
 max-lsa <maximum-number> 
!

Protocolli di ridondanza Secure First Hop

I protocolli di ridondanza First Hop (FHRP) forniscono resilienza e ridondanza per i dispositivi che fungono da gateway predefiniti. Questa situazione e questi protocolli sono comuni in ambienti in cui una coppia di dispositivi di layer 3 fornisce la funzionalità gateway predefinita per un segmento di rete o un set di VLAN che contengono server o workstation.

Il protocollo GLBP (Gateway Load-Balancing Protocol), il protocollo HSRP (Hot Standby Router Protocol) e il protocollo VRRP (Virtual Router Redundancy Protocol) sono tutti protocolli FHRP. Per impostazione predefinita, questi protocolli comunicano con comunicazioni non autenticate. Questo tipo di comunicazione può consentire a un utente non autorizzato di presentarsi come dispositivo compatibile con FHRP per assumere il ruolo di gateway predefinito nella rete. Questa acquisizione permette all'aggressore di eseguire un attacco man-in-the-middle e di intercettare tutto il traffico utente che esce dalla rete.

Per prevenire questo tipo di attacchi, tutti gli FHRP supportati dal software Cisco IOS includono una funzionalità di autenticazione con MD5 o stringhe di testo. A causa della minaccia rappresentata da FHRP non autenticati, è consigliabile che le istanze di questi protocolli utilizzino l'autenticazione MD5. In questo esempio di configurazione viene illustrato l'utilizzo dell'autenticazione GLBP, HSRP e VRRP MD5:

!

interface FastEthernet 1
 description *** GLBP Authentication ***
 glbp 1 authentication md5 key-string <glbp-secret>
 glbp 1 ip 10.1.1.1
!

interface FastEthernet 2
 description *** HSRP Authentication ***
 standby 1 authentication md5 key-string <hsrp-secret>
 standby 1 ip 10.2.2.1
!

interface FastEthernet 3
 description *** VRRP Authentication ***
 vrrp 1 authentication md5 key-string <vrrp-secret> 
 vrrp 1 ip 10.3.3.1
!

Piano dati

Sebbene il piano dati sia responsabile dello spostamento dei dati dall'origine alla destinazione, nel contesto della sicurezza, il piano dati è il meno importante dei tre piani. Per questo motivo, quando si protegge un dispositivo di rete è importante proteggere di preferenza i piani di gestione e di controllo rispetto al piano dati.

Tuttavia, all'interno dello stesso piano dati, ci sono molte funzionalità e opzioni di configurazione che possono aiutare a proteggere il traffico. In queste sezioni vengono descritte in dettaglio le funzionalità e le opzioni che consentono di proteggere più facilmente la rete.

Protezione avanzata piano dati generale

La maggior parte del traffico dei piani dati attraversa la rete come determinato dalla configurazione del routing di rete. Tuttavia, la funzionalità di rete IP permette di modificare il percorso dei pacchetti sulla rete. Caratteristiche quali le opzioni IP e in particolare l'opzione di instradamento sorgente, rappresentano oggi una sfida a livello di sicurezza per le reti.

L'uso degli ACL transit è importante anche per fortificare il piano dati.

Per ulteriori informazioni, vedere la sezione Filtro del traffico di transito con ACL transit.

Caduta selettiva opzioni IP

Le opzioni IP pongono due problemi di sicurezza. Il traffico che contiene opzioni IP deve essere commutato in base al processo dai dispositivi Cisco IOS, il che può portare a un carico elevato della CPU. Le opzioni IP includono anche la funzionalità di modifica del percorso del traffico sulla rete, che potenzialmente consente di sovvertire i controlli di sicurezza.

Per questo motivo, il comando di configurazione globale ip options {drop | ignore} è stato aggiunto al software Cisco IOS versione 12.3(4)T, 12.0(22)S e 12.2(25)S. Nella prima forma di questo comando, ip options dropvengono scartati tutti i pacchetti IP che contengono le opzioni IP ricevute dal dispositivo Cisco IOS. In questo modo si evita sia il carico elevato della CPU che la possibile sovversione dei controlli di sicurezza che le opzioni IP possono attivare.

Nella seconda forma di questo comando, ip options ignoreil dispositivo Cisco IOS viene configurato in modo da ignorare le opzioni IP contenute nei pacchetti ricevuti. Anche se in questo modo si attenuano le minacce relative alle opzioni IP per il dispositivo locale, è possibile che la presenza di opzioni IP influisca sui dispositivi a valle. Per questo motivo, si consiglia drop di utilizzare questo comando. Come mostrato nell'esempio di configurazione:

!
ip options drop
!

Alcuni protocolli, ad esempio l'RSVP, fanno un uso legittimo delle opzioni IP. Questo comando influisce sulle funzionalità di questi protocolli.

Dopo aver abilitato il comando IP Options Selective Drop, è possibile usare il show ip traffic EXEC comando per determinare il numero di pacchetti ignorati a causa della presenza di opzioni IP. Queste informazioni sono presenti nel contatore di rilascio forzato.

Disabilita routing origine IP

Il routing dell'origine IP sfrutta le opzioni Loose Source Route e Record Route, in tandem, o Strict Source Route, insieme all'opzione Record Route per consentire all'origine del datagramma IP di specificare il percorso di rete di un pacchetto. Questa funzionalità può essere utilizzata nei tentativi di indirizzare il traffico attorno ai controlli di sicurezza sulla rete.

Se le opzioni IP non sono state completamente disabilitate dalla funzione di eliminazione selettiva delle opzioni IP, è importante che il routing dell'origine IP sia disabilitato. Il routing dell'origine IP, abilitato per impostazione predefinita in tutte le versioni del software Cisco IOS, è disabilitato dal comando di no ip source-route configurazione globale. L'esempio di configurazione riportato di seguito illustra l'utilizzo del comando:

!
no ip source-route
!

Disabilita reindirizzamenti ICMP

I reindirizzamenti ICMP vengono utilizzati per informare un dispositivo di rete di un percorso migliore verso una destinazione IP. Per impostazione predefinita, il software Cisco IOS invia un reindirizzamento se riceve un pacchetto che deve essere instradato tramite l'interfaccia che ha ricevuto.

In alcune situazioni, è possibile che un utente non autorizzato faccia in modo che il dispositivo Cisco IOS invii molti messaggi di reindirizzamento ICMP, con un conseguente carico della CPU elevato. Per questo motivo, si consiglia di disabilitare la trasmissione dei reindirizzamenti ICMP. I reindirizzamenti ICMP vengono disabilitati con il comando interface configuration no ip redirects , come mostrato nell'esempio di configurazione che segue:

!

interface FastEthernet 0
 no ip redirects
!

Disabilitare o limitare le trasmissioni dirette IP

Le trasmissioni dirette IP consentono di inviare un pacchetto di trasmissione IP a una subnet IP remota. Quando il pacchetto raggiunge la rete remota, il dispositivo IP di inoltro invia il pacchetto come trasmissione di layer 2 a tutte le stazioni della subnet. Questa funzionalità di trasmissione diretta è stata utilizzata come un aiuto per l'amplificazione e la riflessione in diversi attacchi, che includono l'attacco del mirino.

Per impostazione predefinita, le versioni correnti del software Cisco IOS hanno questa funzionalità disabilitata; tuttavia, può essere abilitata con il comando di configurazione dellip directed-broadcast'interfaccia. Per impostazione predefinita, le versioni del software Cisco IOS precedenti alla 12.0 dispongono di questa funzionalità.

Se una rete richiede assolutamente la funzionalità di trasmissione diretta, controllarne l'utilizzo. A tal fine, è possibile usare un ACL come opzione del ip directed-broadcast comando. Questo esempio di configurazione limita le trasmissioni dirette ai pacchetti UDP provenienti da una rete attendibile, 192.168.1.0/24:

!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!

interface FastEthernet 0
 ip directed-broadcast 100
!

Filtra il traffico di transito con ACL transit

È possibile controllare il traffico che attraversa la rete utilizzando gli ACL di transito (tACL). Ciò è in contrasto con gli iACL che cercano di filtrare il traffico destinato alla rete stessa. Il filtro fornito dagli elenchi ACL è utile quando l'obiettivo è filtrare il traffico diretto a un particolare gruppo di dispositivi o il traffico che attraversa la rete.

In genere, i firewall eseguono questo tipo di filtro. Tuttavia, in alcuni casi può essere utile eseguire questo filtro su un dispositivo Cisco IOS della rete. Ad esempio, dove deve essere eseguita la filtrazione ma non è presente alcun firewall.

I tACL rappresentano inoltre una posizione appropriata in cui implementare le protezioni anti-spoofing statiche.

Per ulteriori informazioni, vedere la sezione Protezione da spoofing.

Per ulteriori informazioni sugli ACL, fare riferimento a Access Control List transit: Filtering at Your Edge.

Filtro pacchetti ICMP

Il protocollo ICMP (Internet Control Message Protocol) è stato progettato come protocollo di controllo per IP. Pertanto, i messaggi trasmessi possono avere ramificazioni significative sui protocolli TCP e IP in generale. L'ICMP viene utilizzato dagli strumenti ping e traceroutedal router per risolvere i problemi relativi alla rete e per rilevare l'MTU del percorso. Tuttavia, la connettività ICMP esterna è raramente necessaria per il corretto funzionamento della rete.

Il software Cisco IOS offre la funzionalità per filtrare specificamente i messaggi ICMP per nome o tipo e codice. Nell'esempio, l'ACL permette l'ICMP da reti attendibili e blocca tutti i pacchetti ICMP da altre origini:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Permit ICMP packets from trusted networks only
!

 permit icmp host <trusted-networks> any 
!
!--- Deny all other IP traffic to any network device
!

 deny icmp any any
!

Filtra frammenti IP

Come spiegato in precedenza nella sezione Limitazione dell'accesso alla rete con ACL di infrastruttura in questo documento, il filtro dei pacchetti IP frammentati può rappresentare una sfida per i dispositivi di sicurezza.

A causa della natura non intuitiva del controllo dei frammenti, i frammenti IP sono spesso autorizzati inavvertitamente dagli ACL. La frammentazione è spesso utilizzata anche per tentare di eludere il rilevamento con sistemi di rilevamento delle intrusioni. Per questi motivi, i frammenti IP sono spesso utilizzati negli attacchi e possono essere filtrati esplicitamente nella parte superiore di qualsiasi ACL configurato. L'esempio di ACL elencato include un filtro completo dei frammenti IP. Le funzionalità illustrate in questo esempio devono essere utilizzate con le funzionalità degli esempi precedenti:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in 
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!

Per ulteriori informazioni sulla gestione dei pacchetti IP frammentati da parte degli ACL, consultare il documento Access Control Lists and IP Fragments.

Supporto ACL per filtrare le opzioni IP

Nel software Cisco IOS versione 12.3(4)T e successive, il software Cisco IOS supporta l'uso degli ACL per filtrare i pacchetti IP, in base alle opzioni IP contenute nel pacchetto. La presenza di opzioni IP all'interno di un pacchetto può indicare un tentativo di sovvertire i controlli di sicurezza sulla rete o di alterare in altro modo le caratteristiche di transito di un pacchetto. Per questi motivi, si consiglia di filtrare i pacchetti con opzioni IP al bordo della rete.

Utilizzare questo esempio, insieme al contenuto degli esempi precedenti, per includere un filtro completo per i pacchetti IP che contengono opzioni IP:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!

Protezioni anti-spoofing

Molti attacchi utilizzano lo spoofing degli indirizzi IP di origine per essere efficaci o per nascondere la vera origine di un attacco e ostacolare un traceback accurato. Il software Cisco IOS fornisce RPF unicast e IP Source Guard (IPSG) per scoraggiare gli attacchi che si basano sullo spoofing degli indirizzi IP di origine. Inoltre, gli ACL e il routing nullo sono spesso implementati come mezzo manuale per prevenire lo spoofing.

Il protocollo IPSG riduce al minimo lo spoofing delle reti sotto controllo amministrativo diretto tramite la verifica della porta dello switch, dell'indirizzo MAC e dell'indirizzo di origine. Unicast RPF fornisce la verifica della rete di origine e può ridurre gli attacchi di tipo spoofing da reti non sottoposte a controllo amministrativo diretto. La funzione di sicurezza delle porte può essere utilizzata per convalidare gli indirizzi MAC al livello di accesso. L'ispezione DAI (Dynamic Address Resolution Protocol) riduce i vettori di attacco che utilizzano l'avvelenamento ARP sui segmenti locali.

RPF unicast

Unicast RPF consente a un dispositivo di verificare l'indirizzo di origine di un pacchetto inoltrato raggiungibile tramite l'interfaccia che ha ricevuto il pacchetto. Non affidarsi a RPF unicast come unica protezione contro lo spoofing. I pacchetti oggetto di spoofing potrebbero entrare nella rete tramite un'interfaccia Unicast abilitata per RPF se esiste una route di ritorno appropriata all'indirizzo IP di origine. Unicast RPF si basa sull'utente per abilitare Cisco Express Forwarding su ciascun dispositivo ed è configurato per singola interfaccia.

Unicast RPF può essere configurato in una di due modalità: loose o strict. Nei casi in cui è presente il routing asimmetrico, si preferisce la modalità "libero" perché è noto che la modalità rigorosa causa il rifiuto dei pacchetti in queste situazioni. Durante la configurazione del comando di configurazione dell'ip verifyinterfaccia, la parola chiave any configura la modalità libera, mentre la parola chiave rx configura la modalità rigorosa.

L'esempio mostra come configurare questa funzione:

!

ip cef
!

interface <interface>
  ip verify unicast source reachable-via <mode>
!

Per ulteriori informazioni sulla configurazione e l'utilizzo di RPF unicast, fare riferimento a Descrizione di Unicast Reverse Path Forwarding.

Protezione origine IP

IP Source Guard è un mezzo efficace per prevenire lo spoofing che può essere utilizzato se si ha il controllo sulle interfacce di layer 2. IP Source Guard utilizza le informazioni dello snooping DHCP per configurare in modo dinamico un elenco di controllo di accesso (PACL) delle porte sull'interfaccia di layer 2, impedendo il traffico proveniente da indirizzi IP non associati nella tabella di binding dell'origine IP.

IP Source Guard può essere applicato alle interfacce di layer 2 che appartengono alle VLAN abilitate per lo snooping DHCP. Questi comandi abilitano lo snooping DHCP:

!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Dopo aver abilitato lo snooping DHCP, questi comandi abilitano IPSG:

!
interface <interface-id>
   ip verify source 
!

La sicurezza delle porte può essere abilitata con il comando di configurazione dellTip verify source port security'interfaccia. A tal fine, è necessario ip dhcp snooping information option; anche il comando di configurazione globale. Il server DHCP deve supportare l'opzione DHCP 82.

Per ulteriori informazioni su questa funzione, fare riferimento a Configurazione delle funzionalità DHCP e IP Source Guard.

Sicurezza porta

La funzione di sicurezza delle porte viene usata per ridurre lo spoofing degli indirizzi MAC nell'interfaccia di accesso. La funzione di sicurezza delle porte può utilizzare indirizzi MAC appresi in modo dinamico (permanenti) per semplificare la configurazione iniziale. Una volta che la sicurezza delle porte ha determinato una violazione MAC, può utilizzare una delle quattro modalità di violazione. Le modalità sono: proteggere, limitare, arrestare e chiudere la VLAN. Nei casi in cui una porta fornisce l'accesso a una sola workstation utilizzando protocolli standard, può essere sufficiente un numero massimo di una porta. I protocolli che utilizzano indirizzi MAC virtuali, ad esempio HSRP, non funzionano quando il numero massimo è impostato su uno.

!

interface <interface> 
  switchport
  switchport mode access 
  switchport port-security
  switchport port-security mac-address sticky
  switchport port-security maximum <number>
  switchport port-security violation <violation-mode>
!

Per ulteriori informazioni sulla configurazione della sicurezza delle porte, consultare il documento sulla configurazione della sicurezza delle porte.

Ispezione ARP dinamica

La DAI (Dynamic ARP Inspection) può essere utilizzata per mitigare gli attacchi di avvelenamento ARP sui segmenti locali. Un attacco avvelenamento ARP è un metodo in cui un attaccante invia informazioni ARP falsificate ad un segmento locale. Queste informazioni sono progettate per danneggiare la cache ARP di altri dispositivi. Spesso un aggressore usa l'avvelenamento ARP per eseguire un attacco man-in-the-middle.

DAI intercetta e convalida la relazione tra indirizzi IP e MAC di tutti i pacchetti ARP su porte non attendibili. Negli ambienti DHCP, DAI utilizza i dati generati dalla funzionalità di snooping DHCP. I pacchetti ARP ricevuti su interfacce attendibili non vengono convalidati e i pacchetti non validi su interfacce non attendibili vengono ignorati. In ambienti non DHCP, è necessario usare ACL ARP.

Questi comandi abilitano lo snooping DHCP:

!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Dopo aver abilitato lo snooping DHCP, questi comandi abilitano DAI:

!
ip arp inspection vlan <vlan-range> 
!

Negli ambienti non DHCP, per abilitare DAI sono necessari ACL ARP. Nell'esempio viene mostrata la configurazione di base di DAI con ACL ARP:

!

arp access-list <acl-name>
 permit ip host <sender-ip> mac host <sender-mac>
!

ip arp inspection filter <arp-acl-name> vlan <vlan-range>
!

La funzione DAI può essere abilitata anche per singola interfaccia, se supportata.

ip arp inspection limit rate <rate_value> burst interval <interval_value>

Per ulteriori informazioni su come configurare DAI, fare riferimento a Configurazione dell'ispezione ARP dinamica.

ACL anti-spoofing

Gli ACL configurati manualmente possono fornire una protezione anti-spoofing statica contro gli attacchi che usano spazio degli indirizzi noto, non usato o non attendibile. In genere, questi ACL anti-spoofing vengono applicati al traffico in entrata ai limiti della rete come componente di un ACL più grande. Gli ACL anti-spoofing richiedono intervalli di monitoraggio regolari perché possono variare frequentemente. È possibile ridurre al minimo lo spoofing nel traffico proveniente dalla rete locale se si applicano ACL in uscita che limitano il traffico a indirizzi locali validi.

Nell'esempio viene mostrato come usare gli ACL per limitare lo spoofing IP. Questo ACL viene applicato al traffico in entrata sull'interfaccia desiderata. Gli ACE che compongono questo ACL non sono completi. Se si configurano questi tipi di ACL, cercare un riferimento aggiornato che fornisca risultati definitivi.

!

ip access-list extended ACL-ANTISPOOF-IN
 deny	ip 10.0.0.0 0.255.255.255 any
 deny	ip 192.168.0.0 0.0.255.255 any
!

interface <interface>
 ip access-group ACL-ANTISPOOF-IN in
!

Per ulteriori informazioni su come configurare gli Access Control List, consultare il documento sulla configurazione degli ACL IP di uso comune.

L'elenco ufficiale degli indirizzi Internet non allocati è gestito dal Team Cymru. Per ulteriori informazioni su come filtrare gli indirizzi inutilizzati, vedere la pagina di riferimento di Bogon .

Limitazione dell'impatto della CPU sul traffico del piano dati

Lo scopo principale dei router e degli switch è inoltrare i pacchetti e i frame attraverso il dispositivo alle destinazioni finali. Questi pacchetti, che attraversano i dispositivi distribuiti in tutta la rete, possono avere un impatto sulle operazioni della CPU di un dispositivo. Proteggere il piano dati, costituito dal traffico che attraversa il dispositivo di rete, per garantire il funzionamento dei piani di gestione e di controllo. Se il traffico di transito può causare l'elaborazione del traffico di commutazione da parte di un dispositivo, è possibile che il piano di controllo di un dispositivo ne subisca le conseguenze, con conseguenti interruzioni operative.

Funzioni e tipi di traffico che influiscono sulla CPU

Sebbene non esaustivo, questo elenco include i tipi di traffico del piano dati che richiedono un'elaborazione CPU speciale e sono commutati dal processo da parte della CPU:

• Log ACL: il traffico di log ACL è costituito da qualsiasi pacchetto generato a causa di una corrispondenza (autorizzazione o negazione) di una voce ACE su cui viene utilizzata la parola chiave log.
  
  
• Unicast RPF - Unicast RPF utilizzato con un ACL può causare la commutazione di processo di alcuni pacchetti.
  
  
• Opzioni IP - Tutti i pacchetti IP con opzioni incluse devono essere elaborati dalla CPU.
  
  
• Frammentazione: tutti i pacchetti IP che richiedono la frammentazione devono essere passati alla CPU per essere elaborati.
  
  
• Time-to-Live (TTL) Expiry: i pacchetti il cui valore TTL è minore o uguale a 1 richiedono l'invio di messaggi ICMP (Internet Control Message Protocol Time Exceeded) (ICMP Type 11, Code 0), che danno luogo all'elaborazione della CPU.
  
  
• ICMP Unreachables: i pacchetti che causano messaggi ICMP "destinazione irraggiungibile" a causa della loro route, MTU o filtrazione, vengono elaborati dalla CPU.
  
  
• Traffico che richiede una richiesta ARP. Le destinazioni per cui non esiste una voce ARP vengono elaborate dalla CPU.
  
  
• Traffico non IP: tutto il traffico non IP viene elaborato dalla CPU.

Per ulteriori informazioni sulla protezione avanzata del piano dati, vedere la sezione Protezione avanzata del piano dati generale.

Filtra in base al valore TTL

È possibile usare la funzione di supporto ACL per il filtro sul valore TTL, introdotta nel software Cisco IOS versione 12.4(2)T, in un elenco di accessi IP esteso per filtrare i pacchetti in base al valore TTL. Questa funzione può proteggere un dispositivo che riceve il traffico di transito il cui valore TTL è zero o uno. Il filtro dei pacchetti basato sui valori TTL può essere usato anche per assicurare che il valore TTL non sia inferiore al diametro della rete, in modo da proteggere il control plane dei dispositivi dell'infrastruttura a valle dagli attacchi TTL in scadenza.

Alcune applicazioni e strumenti, ad esempio traceroute utilizzano i pacchetti TTL in scadenza per scopi di test e diagnostici. Alcuni protocolli, ad esempio IGMP, utilizzano legittimamente il valore TTL 1.

Nell'esempio, questo ACL crea un criterio che filtra i pacchetti IP quando il valore TTL è inferiore a 6.

!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any ttl lt 6
 permit ip any any
!
!--- Apply access-list to interface in the ingress direction
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Per ulteriori informazioni su come filtrare i pacchetti in base al valore TTL, fare riferimento a TTL Expiry Attack Identification and Mitigation (Identificazione e mitigazione degli attacchi TTL in scadenza).

Per ulteriori informazioni su questa funzione, fare riferimento al supporto ACL per il filtro sul valore TTL.

Nel software Cisco IOS versione 12.4(4)T e successive, il protocollo FPM (Flexible Packet Matching) consente agli amministratori di effettuare le corrispondenze sui bit arbitrari di un pacchetto. Questo criterio FPM elimina i pacchetti con un valore TTL inferiore a 6.

!

load protocol flash:ip.phdf
!

class-map type access-control match-all FPM-TTL-LT-6-CLASS
 match field IP ttl lt 6
!

policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
 class  FPM-TTL-LT-6-CLASS
  drop
!

interface FastEthernet0
 service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY
!

Filtra in base alla presenza di opzioni IP

Nel software Cisco IOS versione 12.3(4)T e successive, è possibile usare il supporto ACL per la funzionalità Filtering IP Options (Opzioni IP filtro) in un elenco di accessi IP estesi con nome per filtrare i pacchetti IP con opzioni IP presenti. Il filtro dei pacchetti IP basato sulla presenza di opzioni IP può essere usato anche per impedire al control plane dei dispositivi dell'infrastruttura di elaborare questi pacchetti a livello di CPU.

Il supporto ACL per il filtro delle opzioni IP può essere usato solo con ACL estesi con nome. RSVP, Multiprotocol Label Switching Traffic Engineering, IGMP versioni 2 e 3, e altri protocolli che utilizzano pacchetti di opzioni IP non possono funzionare correttamente se i pacchetti di questi protocolli vengono scartati. Se questi protocolli sono in uso sulla rete, è possibile usare il supporto ACL per il filtro delle opzioni IP. Tuttavia, la funzione ACL IP Options Selective Drop può bloccare questo traffico e questi protocolli non possono funzionare correttamente. Se non sono in uso protocolli che richiedono opzioni IP, il metodo preferibile per eliminare questi pacchetti è ACL IP Options Selective Drop.

Nell'esempio di ACL viene creato un criterio che filtra i pacchetti IP che contengono opzioni IP:

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option any-options
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

In questo esempio viene mostrato un ACL che filtra i pacchetti IP con cinque opzioni IP specifiche. I pacchetti contenenti queste opzioni vengono rifiutati:

• 0 Fine elenco opzioni (eool)
  
  
• 7 Record Route (record-route)
  
  
• Timestamp 68 (timestamp)
  
  
• 131 - Loose Source Route (lsr)
  
  
• 137 - SSR (Strict Source Route)

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option eool
 deny ip any any option record-route
 deny ip any any option timestamp
 deny ip any any option lsr
 deny ip any any option ssr
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Per ulteriori informazioni sulle opzioni IP degli ACL, consultare la sezione Protezione avanzata del piano dati generale di questo documento.

Per ulteriori informazioni su come filtrare il traffico di transito e ai bordi, consultare il documento Access Control List: Filtering at Your Edge (Liste di controllo dell'accesso transito: filtraggio sul perimetro della rete).

Un'altra funzionalità del software Cisco IOS che può essere utilizzata per filtrare i pacchetti con opzioni IP è CoPP. Nel software Cisco IOS versione 12.3(4)T e successive, il protocollo CoPP consente agli amministratori di filtrare il flusso del traffico dei pacchetti del control plane. Un dispositivo che supporta CoPP e ACL per il filtro delle opzioni IP, introdotto nel software Cisco IOS versione 12.3(4)T, può utilizzare un criterio dell'elenco degli accessi per filtrare i pacchetti contenenti opzioni IP.

Questo criterio CoPP ignora i pacchetti di transito ricevuti da un dispositivo quando sono presenti opzioni IP:

!

ip access-list extended ACL-IP-OPTIONS-ANY
 permit ip any any option any-options
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS-ANY
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

Il criterio CoPP ignora i pacchetti di transito ricevuti da un dispositivo quando sono presenti le seguenti opzioni IP:

• 0 Fine elenco opzioni (eool)
  
  
• 7 Record Route (record-route)
  
  
• Timestamp 68 (timestamp)
  
  
• 131 Loose Source Route (lsr)
  
  
• 137 Strict Source Route (ssr)

!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

Nei criteri CoPP precedenti, le voci dell'elenco di controllo di accesso (ACE, Access Control List) che corrispondono ai pacchetti con l'azione di autorizzazione determinano l'eliminazione di questi pacchetti da parte della funzione di eliminazione della mappa dei criteri, mentre i pacchetti che corrispondono all'azione di negazione (non visualizzata) non sono interessati dalla funzione di eliminazione della mappa dei criteri.

Control Plane Protection

Nel software Cisco IOS versione 12.4(4)T e successive, la protezione del piano di controllo (CPPr) può essere utilizzata per limitare o controllare il traffico del piano di controllo da parte della CPU di un dispositivo Cisco IOS. Anche se simile al CoPP, il CPPr può limitare il traffico della polizia con una maggiore granularità rispetto al CoPP. Il CPPr divide il control plane aggregato in tre categorie separate note come sottointerfacce: Esistono sottointerfacce Host, Transit e CEF-Exception.

Il criterio CPPr rifiuta i pacchetti in transito ricevuti da un dispositivo il cui valore TTL è inferiore a 6 e i pacchetti in transito o non in transito ricevuti da un dispositivo il cui valore TTL è zero o uno. Il criterio CPPr ignora anche i pacchetti con opzioni IP selezionate ricevuti dal dispositivo.

!

ip access-list extended ACL-IP-TTL-0/1
 permit ip any any ttl eq 0 1
!

class-map ACL-IP-TTL-0/1-CLASS
 match access-group name ACL-IP-TTL-0/1
!

ip access-list extended ACL-IP-TTL-LOW
 permit ip any any ttl lt 6
!

class-map ACL-IP-TTL-LOW-CLASS
 match access-group name ACL-IP-TTL-LOW
!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map CPPR-CEF-EXCEPTION-POLICY
 class ACL-IP-TTL-0/1-CLASS
  drop
 class ACL-IP-OPTIONS-CLASS
  drop
!

!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device

!

control-plane cef-exception
 service-policy input CPPR-CEF-EXCEPTION-POLICY
!

policy-map CPPR-TRANSIT-POLICY
 class ACL-IP-TTL-LOW-CLASS
  drop
!

control-plane transit
 service-policy input CPPR-TRANSIT-POLICY
!

Nel criterio CPPr precedente, le voci dell'elenco di controllo di accesso che corrispondono ai pacchetti con il risultato dell'azione di autorizzazione indicavano che tali pacchetti erano stati scartati dalla funzione di rilascio della mappa dei criteri, mentre i pacchetti che corrispondevano all'azione di rifiuto (non mostrata) non erano influenzati dalla funzione di rilascio della mappa dei criteri.

Per ulteriori informazioni sulla funzione CPPr, fare riferimento a Descrizione di Control Plane Protection e Control Plane Protection.

Identificazione e tracciamento del traffico

In alcuni casi, è necessario identificare rapidamente e rintracciare il traffico di rete, in particolare durante la risposta a un problema o durante prestazioni di rete insoddisfacenti. NetFlow e gli ACL di classificazione sono due metodi principali per raggiungere questo scopo con il software Cisco IOS. NetFlow può fornire visibilità su tutto il traffico della rete. Inoltre, NetFlow può essere implementato con collector in grado di fornire analisi automatizzata e di analisi dei trend a lungo termine. Gli ACL di classificazione sono un componente degli ACL e richiedono una pre-pianificazione per identificare il traffico specifico e gli interventi manuali durante l'analisi. In queste sezioni viene fornita una breve panoramica di ciascuna funzionalità.

NetFlow

NetFlow identifica le attività di rete anomale e correlate alla sicurezza in base ai flussi di rete. I dati di NetFlow possono essere visualizzati e analizzati dalla CLI, oppure possono essere esportati in un agente di raccolta NetFlow commerciale o freeware per l'aggregazione e l'analisi. I sistemi di raccolta NetFlow, attraverso tendenze a lungo termine, possono fornire il comportamento della rete e l'analisi dell'utilizzo. NetFlow esegue l'analisi di attributi specifici all'interno dei pacchetti IP e crea i flussi. La versione 5 è la più comunemente utilizzata di NetFlow; tuttavia, la versione 9 è più estendibile. I flussi NetFlow possono essere creati con i dati del traffico campionati in ambienti con grandi volumi di dati.

Il CEF, o CEF distribuito, è un prerequisito per abilitare NetFlow. NetFlow può essere configurato su router e switch.

Nell'esempio viene illustrata la configurazione di base di NetFlow. Nelle versioni precedenti del software Cisco IOS, il comando per abilitare NetFlow su un'interfaccia è ip route-cache flow anziché ip flow {ingress | egress}.

!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!

interface <interface> 
 ip flow <ingess|egress> 
!

Questo è un esempio di output di NetFlow dalla CLI. L'attributo SrcIf può essere utile nel traceback.

router#show ip cache flow
IP packet size distribution (26662860 total packets):
   1-32   64   96  128	160  192  224  256  288  320  352  384	416  448  480
   .741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  55 active, 65481 inactive, 1014683 added
  41000680 ager polls, 0 flow alloc failures
  Active flows timeout in 2 minutes
  Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
  110 active, 16274 inactive, 2029366 added, 1014683 added to flow
  0 alloc failures, 0 force free
  1 chunk, 15 chunks 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	 11512	    0.0        15    42      0.2      33.8      44.8
TCP-FTP 	  5606	    0.0 	3    45      0.0      59.5      47.1
TCP-FTPD	  1075	    0.0        13    52      0.0       1.2      61.1
TCP-WWW 	 77155	    0.0        11   530      1.0      13.9      31.5
TCP-SMTP	  8913	    0.0 	2    43      0.0      74.2      44.4
TCP-X		   351	    0.0 	2    40      0.0       0.0      60.8
TCP-BGP 	   114	    0.0 	1    40      0.0       0.0      62.4
TCP-NNTP	   120	    0.0 	1    42      0.0       0.7      61.4
TCP-other	556070	    0.6 	8   318      6.0       8.2      38.3
UDP-DNS 	130909	    0.1 	2    55      0.3      24.0      53.1
UDP-NTP 	116213	    0.1 	1    75      0.1       5.0      58.6
UDP-TFTP	   169	    0.0 	3    51      0.0      15.3      64.2
UDP-Frag	     1	    0.0 	1  1405      0.0       0.0      86.8
UDP-other	 86247	    0.1       226    29     24.0      31.4      54.3
ICMP		 19989	    0.0        37    33      0.9      26.0      53.9
IP-other	   193	    0.0 	1    22      0.0       3.0      78.2
Total:	       1014637	    1.2        26    99     32.8      13.8      43.9

SrcIf	      SrcIPaddress    DstIf	    DstIPaddress    Pr SrcP DstP Pkts
Gi0/1	      192.168.128.21  Local	    192.168.128.20  11 CB2B 07AF   3
Gi0/1	      192.168.150.60  Gi0/0	    10.89.17.146    06 0016 101F  55
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 101F 0016   9
Gi0/1	      192.168.150.60  Local	    192.168.206.20  01 0000 0303  11
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 07F1 0016   1

Per ulteriori informazioni sulle funzionalità di NetFlow, fare riferimento a Cisco IOS NetFlow.

Per una panoramica tecnica di NetFlow, consultare il documento Introduzione a Cisco IOS NetFlow.

ACL di classificazione

Gli ACL di classificazione forniscono visibilità sul traffico che attraversa un'interfaccia. Gli ACL di classificazione non alterano i criteri di sicurezza di una rete e sono in genere costruiti per classificare singoli protocolli, indirizzi di origine o destinazioni. Ad esempio, una voce ACE che consente tutto il traffico potrebbe essere suddivisa in protocolli o porte specifiche. Questa classificazione più granulare del traffico in ACE specifiche può aiutare a fornire visibilità del traffico di rete, in quanto ogni categoria di traffico ha un proprio contatore di visite. L'amministratore può anche separare il rifiuto implicito presente alla fine di un ACL in ACE granulari per identificare i tipi di traffico negati.

L'amministratore può accelerare la risposta all'incidente utilizzando gli ACL di classificazione con i comandi show access-list ping ed clear ip access-list counters EXEC.

Nell'esempio viene mostrata la configurazione di un ACL di classificazione per identificare il traffico SMB prima di un rifiuto predefinito:

!

ip access-list extended ACL-SMB-CLASSIFY
 remark Existing contents of ACL
 remark Classification of SMB specific TCP traffic 
 deny	tcp any any eq 139
 deny	tcp any any eq 445
 deny	ip any any 
!

Per identificare il traffico che usa un ACL di classificazione, usare il show access-list EXEC comando. I contatori ACL possono essere cancellati con il clear ip access-list counters EXEC comando.

router#show access-list ACL-SMB-CLASSIFY 
Extended IP access list ACL-SMB-CLASSIFY
    10 deny tcp any any eq 139 (10 matches)
    20 deny tcp any any eq 445 (9 matches)
    30 deny ip any any (184 matches) 

Per ulteriori informazioni su come abilitare le funzionalità di log negli ACL, consultare il documento sulla registrazione delle liste di controllo dell'accesso.

Controllo degli accessi con mappe VLAN e liste di controllo degli accessi alle porte

Gli Access Control Lists (VACL) delle VLAN, o mappe VLAN e ACL delle porte (PACL), offrono la possibilità di applicare il controllo dell'accesso al traffico non indirizzato più vicino ai dispositivi endpoint rispetto agli elenchi di controllo degli accessi applicati alle interfacce indirizzate.

In queste sezioni viene fornita una panoramica delle funzionalità, dei vantaggi e degli scenari di utilizzo potenziale di VACL e PACL.

Controllo degli accessi con mappe VLAN

I VACL o le mappe VLAN che si applicano a tutti i pacchetti che entrano nella VLAN, offrono la capacità di imporre il controllo dell'accesso sul traffico intra VLAN. Ciò non è possibile con gli ACL sulle interfacce di routing. Ad esempio, una mappa VLAN può essere usata per impedire agli host contenuti nella stessa VLAN di comunicare tra loro, riducendo in questo modo le opportunità per gli attacchi locali o i worm di sfruttare un host sullo stesso segmento di rete. Per impedire ai pacchetti di usare una mappa VLAN, creare un elenco di controllo di accesso (ACL) che corrisponda al traffico e, nella mappa VLAN, impostare l'azione su drop. Dopo aver configurato una mappa VLAN, tutti i pacchetti che entrano nella VLAN vengono valutati in sequenza rispetto alla mappa VLAN configurata. Le mappe di accesso VLAN supportano gli elenchi di accesso IPv4 e MAC, ma non supportano i log o gli ACL IPv6.

In questo esempio viene utilizzato un elenco degli accessi esteso con nome che illustra la configurazione di questa funzionalità:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address>
     <destination-port>
!

vlan access-map <name> <number>
 match ip address <acl-name>
 action <drop|forward>
!

Nell'esempio viene mostrato come usare una mappa VLAN per bloccare le porte TCP 139 e 445 e il protocollo vines-ip:

!

ip access-list extended VACL-MATCH-ANY
 permit ip any any
!

ip access-list extended VACL-MATCH-PORTS
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139
!

mac access-list extended VACL-MATCH-VINES
 permit any any vines-ip
!

vlan access-map VACL 10
 match ip address VACL-MATCH-VINES 
 action drop
!

vlan access-map VACL 20 
 match ip address VACL-MATCH-PORTS
 action drop
!

vlan access-map VACL 30
 match ip address VACL-MATCH-ANY
 action forward
!

vlan filter VACL vlan 100 
!

Per ulteriori informazioni sulla configurazione delle mappe VLAN, fare riferimento a Configurazione della sicurezza di rete con gli ACL.

Controllo dell'accesso con i PACL

I PACL possono essere applicati solo alla direzione in entrata sulle interfacce fisiche di layer 2 di uno switch. Analogamente alle mappe VLAN, i PACL offrono il controllo dell'accesso sul traffico non indirizzato o di livello 2. La sintassi per la creazione dei PACL, che ha la precedenza sulle mappe VLAN e sugli ACL del router, è la stessa degli ACL del router. Se un ACL viene applicato a un'interfaccia di layer 2, viene chiamato PACL. La configurazione implica la creazione di un ACL IPv4, IPv6 o MAC e la relativa applicazione all'interfaccia di layer 2.

In questo esempio viene utilizzato un elenco degli accessi con nome esteso per illustrare la configurazione di questa funzionalità:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address> 
     <destination-port>
!

interface <type> <slot/port>
 switchport mode access
 switchport access vlan <vlan_number>
 ip access-group <acl-name> in 
!

Per ulteriori informazioni sulla configurazione degli ACL, consultare la sezione Configurazione della sicurezza di rete con gli ACL sulle porte.

Controllo degli accessi con MAC

Gli elenchi di controllo di accesso MAC o gli elenchi estesi possono essere applicati su una rete IP con questo comando in modalità di configurazione interfaccia:

Cat6K-IOS(config-if)#mac packet-classify

Nota: gli Access Control List MAC classificano i pacchetti di layer 3 come pacchetti di layer 2. Il comando è supportato nel software Cisco IOS versione 12.2(18)SXD (per Sup 720) e nel software Cisco IOS versione 12.2(33)SRA o successive.

Questo comando di interfaccia deve essere applicato all'interfaccia in entrata e indica al motore di inoltro di non ispezionare l'intestazione IP. Di conseguenza, è possibile utilizzare un elenco degli accessi MAC nell'ambiente IP.

Uso di VLAN private

Le VLAN private (PVLAN) sono una funzione di sicurezza di layer 2 che limita la connettività tra workstation o server su una VLAN. Senza le PVLAN, tutti i dispositivi di una VLAN di layer 2 possono comunicare liberamente. Esistono situazioni di rete in cui la sicurezza può essere migliorata limitando la comunicazione tra i dispositivi su una singola VLAN. Ad esempio, le PVLAN vengono spesso utilizzate per impedire la comunicazione tra i server su una subnet accessibile pubblicamente. Se un singolo server viene compromesso, la mancanza di connettività ad altri server dovuta all'applicazione di PVLAN può contribuire a limitare il compromesso a un unico server.

Esistono tre tipi di VLAN private: VLAN isolate, VLAN di comunità e VLAN primarie. La configurazione delle PVLAN utilizza le VLAN primaria e secondaria. La VLAN primaria contiene tutte le porte promiscue, descritte più avanti, e include una o più VLAN secondarie, che possono essere VLAN isolate o di comunità.

VLAN isolate

La configurazione di una VLAN secondaria come VLAN isolata impedisce completamente la comunicazione tra i dispositivi della VLAN secondaria. Può esistere una sola VLAN isolata per VLAN primaria e solo le porte promiscue possono comunicare con le porte di una VLAN isolata. Le VLAN isolate possono essere utilizzate su reti non attendibili, ad esempio reti che supportano gli utenti guest.

Nell'esempio di configurazione, la VLAN 11 è configurata come VLAN isolata e associata alla VLAN 20 primaria. Nell'esempio, l'interfaccia Fast Ethernet 1/1 è configurata anche come porta isolata sulla VLAN 11:

!

vlan 11
 private-vlan isolated
!

vlan 20
 private-vlan primary
 private-vlan association 11
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

VLAN della community

Una VLAN secondaria configurata come VLAN di comunità consente la comunicazione tra i membri della VLAN e con le porte promiscue sulla VLAN primaria. Tuttavia, non è possibile comunicare tra due VLAN della community o da una VLAN della community a una VLAN isolata. Le VLAN di comunità devono essere utilizzate per raggruppare server che devono essere connessi tra loro, ma nei casi in cui non è richiesta la connettività a tutti gli altri dispositivi della VLAN. Questo scenario è comune in una rete accessibile pubblicamente o in qualsiasi punto in cui i server forniscono contenuto a client non attendibili.

Nell'esempio, viene configurata una singola VLAN della community e la porta dello switch Fast Ethernet 1/2 viene configurata come membro di tale VLAN. La VLAN della community, VLAN 12, è una VLAN secondaria rispetto alla VLAN 20 primaria.

!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 12
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

Porte promiscue

Le porte degli switch inserite nella VLAN principale sono note come porte promiscue. Le porte promiscue possono comunicare con tutte le altre porte sulle VLAN primaria e secondaria. Le interfacce router o firewall sono i dispositivi più comuni presenti sulle VLAN.

Questo esempio di configurazione combina i precedenti esempi di VLAN isolata e di comunità e aggiunge la configurazione dell'interfaccia Fast Ethernet 1/12 come porta promiscua:

!

vlan 11
 private-vlan isolated
!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 11-12
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

interface FastEthernet 1/12
 description *** Promiscuous Port ***
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 20 add 11-12
!

Quando si implementano le PVLAN, è importante verificare che la configurazione di layer 3 supporti le restrizioni imposte dalle PVLAN e non consenta di sovvertire la configurazione. Un filtro di layer 3 con un ACL del router o un firewall può impedire la sovversione della configurazione della PVLAN.

Per ulteriori informazioni sull'uso e la configurazione delle VLAN private, fare riferimento alla sezione PVLAN (VLAN private) - promiscue, isolate, condivise, disponibile nella home page Sicurezza LAN.

Conclusioni

Questo documento offre un'ampia panoramica dei metodi che possono essere utilizzati per proteggere un dispositivo di sistema Cisco IOS. Se si proteggono i dispositivi, si aumenta la sicurezza complessiva delle reti gestite. In questa panoramica, viene descritta la protezione dei piani di gestione, controllo e dati e vengono forniti suggerimenti per la configurazione. Se possibile, vengono forniti dettagli sufficienti per la configurazione di ciascuna feature associata. Tuttavia, in tutti i casi, vengono forniti riferimenti completi per fornire le informazioni necessarie per un'ulteriore valutazione.

Riconoscimenti

Alcune descrizioni delle caratteristiche riportate in questo documento sono state scritte dai team di sviluppo di informazioni Cisco.

Appendice: Elenco di controllo per la protezione avanzata dei dispositivi Cisco IOS

Questo elenco di controllo contiene tutti i passaggi per fortificare i dispositivi presentati in questa guida. Gli amministratori possono usarlo come promemoria di tutte le funzionalità di protezione avanzata usate e prese in considerazione per un dispositivo Cisco IOS, anche se una funzionalità non è stata implementata perché non era applicabile. Si consiglia agli amministratori di valutare ogni opzione in relazione ai potenziali rischi prima di implementarla.

Piano di gestione

• Password
  
  
  • Abilita hashing MD5 (opzione segreta) per abilitare le password degli utenti locali
  • Configurare il blocco dei tentativi di reimpostazione password
  • Disabilita recupero password (considerare i rischi)
    
    
• Disabilita servizi inutilizzati
  
  
• Configurare i pacchetti TCP keepalive per le sessioni di gestione
  
  
• Impostazione delle notifiche di soglia della memoria e della CPU
  
  
• Configurazione
  
  
  • Notifiche di soglia della memoria e della CPU
  • Riserva di memoria per l'accesso alla console
  • Rilevatore di perdita di memoria
  • Rilevamento overflow buffer
  • Raccolta avanzata crashinfo
    
    
• Uso degli iACL per limitare l'accesso alla gestione
  
  
• Filtro (considerare i rischi)
  
  
  • Pacchetti ICMP
  • Frammenti IP
  • Opzioni IP
  • Valore TTL nei pacchetti
    
    
• Control Plane Protection
  
  
  • Configura filtrazione porte
  • Configura soglie della coda
    
    
• Accesso alla gestione
  
  
  • Utilizzare Management Plane Protection per limitare le interfacce di gestione
  • Imposta timeout esecuzione
  • Uso di un protocollo di trasporto crittografato (ad esempio SSH) per l'accesso CLI
  • Controllo del trasporto per le linee vty e tty (opzione classe di accesso)
  • Avvisa con l'utilizzo di banner
    
    
• AAA
  
  
  • Usa AAA per autenticazione e fallback
  • Utilizzare AAA (TACACS+) per l'autorizzazione dei comandi
  • Utilizza AAA per l'account
  • Uso di server AAA ridondanti
    
    
• SNMP
  
  
  • Configurazione delle community SNMPv2 e applicazione degli ACL
  • Configurazione di SNMPv3
    
    
• Registrazione
  
  
  • Configura registri centralizzati
  • Impostare i livelli di log per tutti i componenti rilevanti
  • Imposta interfaccia origine log
  • Configura granularità timestamp registro
    
    
• Gestione della configurazione
  
  
  • Sostituzione e rollback
  • Accesso esclusivo alle modifiche alla configurazione
  • Configurazione resilienza software
  • Notifiche delle modifiche alla configurazione

Piano di controllo

• Disabilita (considera rischio)
  
  
  • Messaggi di reindirizzamento ICMP
  • ICMP non raggiungibili
  • Proxy ARP
    
    
• Configurare l'autenticazione NTP se si desidera utilizzare NTP
  
  
• Configura Control Plane Policing/Protection (filtri porte, soglie coda)
  
  
• Protocolli di routing sicuri
  
  
  • BGP (TTL, MD5, prefissi massimi, elenchi di prefissi, ACL di percorsi di sistema)
  • IGP (MD5, interfaccia passiva, filtri di routing, consumo di risorse)
    
    
• Configurare i limitatori di velocità hardware
  
  
• Protocolli di ridondanza Secure First Hop (GLBP, HSRP, VRRP)

Piano dati

• Configura eliminazione selettiva opzioni IP
  
  
• Disabilita (considera rischio)
  
  
  • Route di origine IP
  • Trasmissioni dirette IP
  • Messaggi di reindirizzamento ICMP
    
    
• Limita trasmissioni dirette IP
  
  
• Configurazione degli ACL (considerare i rischi)
  
  
  • Filtra ICMP
  • Filtra frammenti IP
  • Opzioni Filtro IP
  • Filtra valori TTL
    
    
• Configurare le protezioni anti-spoofing necessarie
  
  
  • ACL
  • Protezione origine IP
  • Ispezione ARP dinamica
  • RPF unicast
  • Sicurezza porta
    
    
• Control Plane Protection (control-plane cef-exception)
  
  
• Configurazione di NetFlow e degli ACL di classificazione per l'identificazione del traffico
  
  
• Configurazione degli ACL di controllo dell'accesso richiesti (mappe VLAN, PACL, MAC)
  
  
• Configurazione di VLAN private