Sei sulla pagina 1di 85

Cisco Academy

Il Succo di CCNA Security

per lesame di Certificazione IINS #640-553


Powered by: MP Versione 1.0 Dicembre 2009

Il Succo di CCNA Security

Powered by: MP eForHum

Indice
Cap. 0 Cap. 1 1.1 1.2 1.3 Cap. 2 2.1 2.2 2.3 2.4 Cap. 3 3.1 3.2 3.3 3.4 3.5 Cap. 4 4.1 4.2 4.3 4.4 Cap. 5 5.1 5.2 5.3 5.4 Cap. 6 6.1 6.2 6.3 6.4 Cap. 7 7.1 7.2 7.3 7.4 Cap. 8 8.1 8.2 8.3 Introduzione................................................................................................................... 3 Le minacce alla sicurezza delle reti moderne ............................................................... 4 Principi fondamentali di una rete sicura ........................................................................... 4 Virus, Worms e Cavalli di Troia (Trojan Horses)............................................................. 6 Metodologie di attacco..................................................................................................... 7 Mettere in sicurezza gli apparati di rete ....................................................................... 8 Mettere in sicurezza gli accessi........................................................................................ 8 Assegnare i ruoli amministrativi .................................................................................... 12 Monitoraggio e gestione degli apparati .......................................................................... 14 Luso delle funzionalit di sicurezza automatiche .......................................................... 18 Autenticazione, Autorizzazione e Accounting ............................................................ 21 Scopo dellAAA ............................................................................................................ 21 LAutenticazione AAA locale........................................................................................ 22 LAAA basata su Server ................................................................................................ 24 LAutenticazione AAA basata su Server........................................................................ 28 LAutorizzazione e lAccounting AAA basati su Server ................................................ 30 Limplementazione delle tecnologie Firewall ............................................................. 31 Le Access Control List .................................................................................................. 31 Le tecnologie dei Firewall.............................................................................................. 40 Il CBAC Context-Based Access Control..................................................................... 43 Lo ZPF Zone-based Policy Firewall............................................................................ 47 Gli IPS-Intrusion Prevention Systems ........................................................................ 55 Le tecnologie IPS .......................................................................................................... 55 Le firme (signatures) degli IPS ...................................................................................... 57 Limplementazione degli IPS......................................................................................... 61 La verifica e il monitoraggio degli IPS........................................................................... 67 Mettere in sicurezza la LAN........................................................................................ 69 La sicurezza dei terminali (endpoint) ............................................................................. 69 Considerazioni sulla sicurezza a Livello 2...................................................................... 70 La configurazione della sicurezza a Livello 2................................................................. 70 La sicurezza nel wireless, nel VoIP e nelle SAN ............................................................ 71 Sistemi di crittografia .................................................................................................. 73 I servizi di crittografia.................................................................................................... 73 Lintegrit e lautenticit di base (dei messaggi) ............................................................ 73 La confidenzialit dei messaggi ..................................................................................... 74 La crittografia a chiave pubblica .................................................................................... 75 VPN-Virtual Private Networks ................................................................................... 77 Le VPN-Virtual Private Networks ................................................................................. 77 Le VPN di tipo GRE-Generic Route Encapsulation ....................................................... 77 Le componenti e il funzionamento delle VPN di tipo IPsec............................................ 78 1

Il Succo di CCNA Security


8.4 8.5 8.6 Cap. 9 9.1 9.2 9.3 9.4 9.5 9.6 9.7

Powered by: MP eForHum

Limplementazione di una VPN IPsec site-to-site con CLI ......................................... 78 Limplementazione di una VPN IPsec site-to-site con SDM ....................................... 79 Limplementazione delle VPN per accesso remoto ........................................................ 80 Gestire una rete sicura................................................................................................. 81 I principi del progetto di reti sicure ................................................................................ 81 La rete Cisco che si difende da sola (Self-Defending Network)...................................... 81 La sicurezza del funzionamento (Operations)................................................................. 82 Il test della sicurezza di rete........................................................................................... 82 Il piano per la Business Continuity e il Disaster Recovery....................................... 82 Il ciclo di vita dello sviluppo dei sistemi (SDLC)........................................................... 83 Lo sviluppo di una Security Policy completa (comprehensive) ................................... 83

Dimensioni in pagine dei singoli Capitoli e Totali Cap. 1: Le minacce alla sicurezza delle reti moderne Cap. 2: Mettere in sicurezza gli apparati di rete Cap. 3: Autenticazione, Autorizzazione e Accounting Cap. 4: Le tecnologie dei Firewall Cap. 5: IPS-Intrusion Prevention System Cap. 6: Mettere in sicurezza la LAN Cap. 7: Sistemi di crittografia Cap. 8: VPN-Virtual Private Networks Cap. 9: Gestire una rete sicura Totali: I Labs Packet Tracer 5.2 (Cap. 1: no PT5) Cap. 2: 27 punti Cap. 3: 21 punti Cap. 4: Act. A: 23 p.; Act. B: 9 p.; Act. C: 15 p. Cap. 5: 13 punti Cap. 6: Act. A: 55 punti; Act. B: 20 punti (Cap. 7: no PT5) Cap. 8: 19 punti

on-line; 49 pp; 60 pp; 44 pp; 83 pp; 55 pp; 85 pp; 70 pp; 83 pp; 66 pp; 595 pp;

nel Succo xx pp 13 pp 10 pp 23 pp 14 pp xx pp xx pp xx pp xx pp xxx pp

Cap. 9: 215 punti!

Labs reali (file Word) A (4 pp. Student, 5 pp. Instructor) A (42 pp. Student, 56 pp. Instructor) A (25 pp. Student, 31 pp. Instructor) A (31 pp. Student, 42 pp. Instructor) A (36 pp. Student, 47 pp. Instructor) A (29 pp. Student, 41 pp. Instructor) A (9 pp. Student, 9 pp. Instructor) A (28 pp. Student, 41 pp. Instructor) B (26 pp. Student, 36 pp. Instructor) C (23 pp. Student, 30 pp. Instructor) A (29 pp. Student, 61 pp. Instructor)

Il Succo di CCNA Security Cap. 0 Introduzione

Powered by: MP eForHum

Il presente Succo riassume tutto il Curriculum on-line del Corso CCNA Security v1.0 (2009), ad uso dei docenti e degli studenti che devono ripassare dopo lo studio, per fissare i concetti principali. La numerazione dei capitoli e dei paragrafi, nonch la traduzione dei loro titoli, segue rigorosamente loriginale inglese, per facilitare luso del Succo nei Corsi delle Cisco Academies. Anche le figure pi significative sono importate direttamente (in bitmap) dalloriginale. Come nello stile dellAutore, il testo comprende anche alcune parti in corsivo che costituiscono piccole integrazioni o correzioni al materiale originale (vedere caso per caso). Quando segnalato un errore del curriculum, compare anche il termine on-line come flag di riconoscimento. I termini in grassetto evidenziano invece i concetti principali di ogni frase. I comandi IOS, normalmente con il loro prompt, e le relative keywords fisse, sono riportati in courier bold, per emergere dal testo e risultare pi leggibili. Eventuali parametri variabili sono sempre in italiano e in courier, ma senza bold: talvolta col loro nome, talaltra sotto forma di esempio: R(config)#login delay secondi oppure: R(config)#login delay 10 Come usuale, i parametri indicati tra [ ] sono opzionali, mentre quelli tra { } indicano una scelta obbligatoria tra pi parametri, separati da |. In blu abbiamo riportato questioni dubbie, che la discussione in classe, o ulteriori ricerche, o un approccio sperimentale non sono ancora riuscite a dirimere, e vanno pertanto approfondite.

Il Succo di CCNA Security Cap. 1

Powered by: MP eForHum

Le minacce alla sicurezza delle reti moderne

1.1 Principi fondamentali di una rete sicura


1.1.1 Evoluzione della sicurezza di rete
P1 Il worm Code Red (luglio 2001) ha infettato 350.000 server nel mondo. C necessit di professionisti della sicurezza, sempre aggiornati sulle minacce (threats), tempestivi nellapplicare le patches necessarie ai sistemi, e capaci di formare sul tema della sicurezza gli utenti finali. P2 Allinizio di Internet (anni 60-70) la sicurezza non era un problema molto sentito. Con la comparsa dei primi virus negli anni 80 e del primo attacco DoS-Denial of Service negli anni 90, gli utenti delle reti hanno cominciato a cercare professionisti, versati (versed) nel settore, con la salutare mania (healthy paranoia) di metterle in sicurezza. P3 Le prime difese sono state gli IDS-Instrusion Detection System (SRI International, 1984), seguiti dopo pochi anni dagli IPS-Intrusion Prevention System, capaci di bloccare da soli gli attacchi. I firewall sono stati la generazione successiva, dapprima sotto forma di semplice filtraggio di Pacchetti IP scorrelati tra loro (DEC, 1988), e poi come filtraggio stateful che verifica anche se i Pacchetti fanno parte di connessioni L4 esistenti (established) di cui si tiene traccia (AT&T Bell Labs, 1989). I primi firewall erano implementati nei Router, poi sono comparsi apparati dedicati (standalone). I Cisco ISR-Integrated Services Router implementano un firewall stateful. P4 Quasi 20 anni dopo i rimedi per proteggere le reti da attacchi esterni, sono stati sviluppati anche quelli per contrastare gli attacchi provenienti dallinterno, ossia dalle LAN, ad opera di impiegati scontenti (disgruntled). Questi sono principalmente di 2 tipi: falsificazione della propria identit (spoofing) e DoS, per rendere inutilizzabili alcune risorse di rete. Alcuni esempi possono essere lattacco di MAC spoofing, quello per mandare in overflow le tabelle MAC degli Switch, i LAN storm, il Root Bridge spoofing del protocollo STP, i salti di VLAN e gli ARP spoofing. P5 La crittografia pu aiutare a proteggere da occhi indiscreti i dati e le comunicazioni, su cavo e via radio (nelle reti mobili e nelle WLAN-Wireless LAN). La confidenzialit o segretezza solo uno dei tre aspetti della sicurezza dellinformazione. Gli altri due sono: lintegrit rispetto alloriginale, che viene garantita allegando ai documenti una loro firma cifrata ottenuta tramite hashing, e la disponibilit (availability) dei dati, che non devono venire corrotti o cancellati e sono quindi protetti, ad es., da adeguati backup. Alcune tecnologie in merito sono: il protocollo Cisco GRE, vari tipi di VPN (ad es. quelle basate su IPsec o SSL) ed SSH-Secure SHell. 4

Il Succo di CCNA Security

Powered by: MP eForHum

1.1.2 Le motivazioni (drivers) per la sicurezza di rete


P1 Gli hackers sono gli esperti di reti e di informatica, e possono avere intenti positivi o negativi. Per contrastare questi ultimi, i professionisti della sicurezza devono restare costantemente al passo con le nuove minacce, le tecnologie per combatterle, ecc. Possono anche essere molto ricercati e pagati, ma hanno una grande responsabilit di autoaggiornamento. P2 I primi attacchi degli hackers si sono rivolti alle reti telefoniche, col mostro telefonico (Phone freak o Phreak) che simulava i toni audio necessari per fare chiamate internazionali a basso costo, su centrali AT&T. In seguito nato il wardialing, che faceva automaticamente migliaia di chiamate alla ricerca di computer, bulletin boards o FAX da attaccare. Infine si giunti allodierno wardriving, in cui si cerca di accedere alle reti wireless tramite password cracking, girando la citt in auto. Figura: il primo Internet Worm del 1988; le prime condanne per hacking sono del 1994; SATAN del 1995 e Nmap (che fa network scanning) del 1997. Esiste anche il tool Back Orifice (data?) per violare laccesso remoto ai sistemi. P3 Il primo virus inviato via mail stato Melissa (1999) ed ha portato ad una condanna dellautore, David Smith. Robert Morris, autore del primo worm (1988) che ha bloccato il 10% di Internet, pure stato condannato. Anche Kevin Mitnick finito in carcere per aver rubato gli account di numerose carte di credito nei primi anni 90. Infine vanno citati gli attacchi di spam (il primo, su ARPAnet, gi nel 1978), e lattacco DoS del canadese Mafiaboy, condannato nel 2000. P4 Le crescenti esigenze di sicurezza ICT hanno creato lesigenza di nuove professionalit. Il lavoro degli esperti di sicurezza comporta (entails) mantenersi aggiornati (keep abreast) sulle minacce pi recenti, sui rimedi, e sulle CVE-Common Vulnerability Exposure pubblicate dagli Enti che si occupano di sicurezza (es. cve.mitre.org). Devono anche saper registrare i LOG per riprendere o perseguire (reprimanding or prosecuting) chi viola le Policy di sicurezza.

1.1.3 Le organizzazioni della sicurezza


P1 Alcune delle organizzazioni pi note del settore sono: SANS-SysAdmin, Audit, Network, Security; CERT-Computer Emergency Response Team; (ISC)2-International Information System Security Certification Consortium; InfoSysSec; Mitre, FIRST, CIS. P2 In particolare, SANS un Ente fondamentale che pubblica risorse gratuite come: il portale di allarme Storm Center, i settimanali NewsBites e @RISK, le flash security alerts, ecc. Promuove corsi per ottenere la GIAC-Global Information Assurance Certification. P3 CERT parte del SEI-Software Engineering Institute, Ente federale della Carnegie Mellon University; stato inizialmente coordinato dallAgenzia DARPA. CERT/CC-Coordination Center gestisce le emergenze, cerca di prevenire incidenti futuri e d la caccia agli hackers. CERT diffonde la cultura della sicurezza in molti modi, ed consulente (advises) di vari Enti governativi. P4 (ISC)2 promuove la formazione sulla sicurezza in 135 Paesi e ha 60.000 soci in tutto il mondo. Sviluppa e mantiene un CBK-Common Body of Knowledge, e offre 4 Certificazioni, tra cui la CISSP-Certified Information System Security Professional P5 Un tool molto ustile ed usato per mantenersi aggiornati sui rischi di sicurezza sono le News ottenibili tramite i feed RSS-Really Simple Syndication (=Agenzia di stampa) che riassumono in formato standard notizie provenienti da varie fonti, leggibili poi su un normale Browser. Un feed RSS in solo testo disponibile a: http://www.us-cert.gov/current/index.rdf .

Il Succo di CCNA Security


1.1.4 I Domini della sicurezza

Powered by: MP eForHum

P1 La tematiche di sicurezza sono suddivise, dallo standard ISO/IEC 27002, in 12 Domini di interesse, analoghi a quelli definiti nella Certificazione CISSP (on-line con descrizioni):

P2 Particolarmente importante il secondo Dominio, quello della Security Policy, che definisce le regole a cui gli utenti di un sistema ICT si devono adeguare (must abide) per mantenerlo sicuro.

1.1.5 Le politiche (policies) della sicurezza


P1 P2 P3 P4

1.2 Virus, Worms e Cavalli di Troia (Trojan Horses)


1.2.1 I Virus
P1 P2

1.2.2 Gli Worms


P1 P2 P3

1.2.3 I Cavalli di Troia


P1 P2 6

Il Succo di CCNA Security


P1 P2 P3 P4 P5

Powered by: MP eForHum

1.2.4 Il contrasto (mitigating) a Virus, Worms e Cavalli di Troia

1.3 Metodologie di attacco


1.3.1 Attacchi di indagine (reconnaissance)
P1 P2 P3 P4 P5

1.3.2 Attacchi di accesso


P1 P2 P3

1.3.3 Attacchi di DoS-Denial of Service


P1 P2 P3 P4

1.3.4 Il contrasto a questi attacchi


P1 P2 P3 P4 P5

Il Succo di CCNA Security Cap. 2

Powered by: MP eForHum

Mettere in sicurezza gli apparati di rete

2.1 Mettere in sicurezza gli accessi


2.1.1 Mettere in sicurezza i Router di confine (edge)
P1 La sicurezza dei Router particolarmente importante, dato che essi agiscono come i vigili del traffico IP. Ancora maggior attenzione va prestata ai Router di confine (edge) tra le LAN e le WAN, in quanto sono il primo o lultimo presidio contro gli attacchi dallesterno o dallinterno. Spiare la password digitata da un collega, stando dietro di lui, viene detto shoulder surfing. P2 Larchitettura dei Router di confine pu variare a seconda della complessit delle reti: Approccio con singolo Router: adatto a piccole LAN o uffici SOHO, e affida tutta la sicurezza ad un solo apparato, spesso coincidente con un ISR-Integrated Services Router (NB: il focus del Corso su questi apparati, mentre sui Firewall ASA si vedono solo cenni)

Approccio di difesa rinforzata (defense-in-depth): prevede laggiunta di un Firewall tra la LAN e ledge Router, per svolgere ulteriori controlli sul traffico entrante ed uscente. Il Firewall vieta tipicamente il traffico generato dallesterno (dalla rete untrusted a quella trusted), ma consente il traffico di ritorno delle sessioni aperte dallinterno; pu svolgere anche funzioni di autenticazione degli utenti che accedono lecitamente dallesterno (clienti o teleworkers)

Approccio DMZ-Demilitarized Zone: una variante dellapproccio precedente, e prevede la creazione di unarea intermedia, la DMZ, ottenuta nella rete situata tra due Router, o su uninterfaccia dedicata del Firewall; alla DMZ si collegano i Server accessibili dallesterno

P3 La messa in sicurezza di un apparato (Router o Switch) prevede le seguenti aree ed azioni: Sicurezza fisica: installarlo in un locale sotto chiave, senza scariche elettrostatiche o altre interferenze, con sistemi antincendio, temperatura e umidit controllate, e un adeguato UPS 8

Il Succo di CCNA Security

Powered by: MP eForHum

Sicurezza del S.O.: mettere molta RAM, per contrastare meglio gli attacchi DoS e poter usare tutte le funzionalit di sicurezza necessarie; usare S.O. aggiornati ma stabili; tenerne un backup Sicurezza degli accessi: definire bene e controllare chi pu accedere agli apparati, e a quale livello; disabilitare le interfacce non usate; disabilitare i servizi innecessari. P4 La sicurezza degli accessi, in particolare, prevede: di restringere i modi di accedere (su quali porte, da quali utenti o IP, con quali protocolli) di registrare (log) chi ha avuto accesso, quando lha avuto, e che cosa ha fatto di autenticare chi accede (singoli, gruppi, servizi offerti); limitare il numero di tentativi di login e imporre una pausa tra tentativi successivi di autorizzare le azioni (singole funzioni o views) che ogni utente pu svolgere di visualizzare una nota legale (scritta con un consulente) prima delle sessioni interattive di proteggere i dati archiviati localmente, o in transito sulle linee dati, da copia e alterazione. P5 Laccesso amministrativo pu avvenire in locale, con cavo console (preferibile) o da remoto, con vari protocolli: preferire quelli che cifrano il traffico a quelli in chiaro. Ad es. meglio usare SSH-Secure SHell invece di Telnet sulla CLI; HTTPS invece di HTTP sulla GUI; SNMP v3 invece di SNMP v1-2. Inoltre bene definire lHost o la rete da cui si accetta laccesso remoto, le interfacce su cui esso accettato, e i protocolli ammissibili.

2.1.2 La configurazione di una accesso amministrativo sicuro


P1 Le password sicure, contro gli attacchi dei tools basati su dizionario o a forza bruta, sono fatte di almeno 10 caratteri, con caratteri maiuscoli e minuscoli, numeri, simboli e spazi (validi per Cisco allinterno delle password, non allinizio; ci permette di creare delle pass-phrase). Evitare termini facili (es. nomi di persone, auto, animali...) o storpiarli (misspell): Smith Smyth o 5mYth; Security 5ecur1ty... Cambiarle di frequente; non scriverle vicino agli apparati protetti! Usare gli stessi tools degli hackers (es. L0phtCrack o Cain&Abel) per testarne la robustezza. P2 In grandi aziende, le password possono essere archiviate in Server di autenticazione (AAA) di tipo TACACS+ o RADIUS, come il Cisco Secure ACS-Access Control Server; buona norma prevedere anche password di back-up locali sugli apparati per laccesso in caso di Server off-line. Le password da definire sono: quelle di accesso (login) da console, AUX e dalle 5 linee virtuali VTY (n. da 0 a 4); per default, le linee CON e AUX non richiedono password, a differenza delle VTY (se manca, non si accede). Queste password sono memorizzate in chiaro nella configurazione. Per assegnare queste password usare i comandi di linea: password valore e: login quella di abilitazione (enable) del modo privilegiato (privileged EXEC mode). Questa password, se assegnata col comando: enable secret valore, (e non: enable password valore) viene cifrata in configurazione col metodo di hashing (forte) MD5. P3 Le password possono essere rinforzate imponendone (enforcing) una lunghezza minima, evitando di lasciare connessioni non presidiate (unattended) e cifrando le password in chiaro. Il primo obiettivo si ottiene col comando di configurazione globale: security password min-length valore (suggerito: almeno 10) e non agisce sulle password gi configurate. Il time-out delle connessioni per default di 10: si suggerisce di ridurlo a 2-3 col comando di linea: exec-timeout minuti [secondi] (NB: usando minuti=0, va allinfinito) e/o di disabilitare linterprete CLI sulla linea AUX con: no exec. 9

Il Succo di CCNA Security

Powered by: MP eForHum

Le password memorizzate in chiaro possono essere cifrate con lalgoritmo (debole) MD7, tramite il comando: service password-encryption , decifrabile per con tools reperibili in rete. P4 Laccesso agli apparati pu anche essere protetto dalla coppia username-password basata su DB locale, col comando globale (errato on-line): username utente secret [tipo-MD] password; il tipo pu essere 0, 5 o 7, quello di default il solito MD5. Assegnare poi alle linee interessate il comando: login local per indicare che le credenziali di accesso vanno cercate sullapparato.

2.1.3 La configurazione di sicurezza avanzata per i login virtuali


P1 Protezione dei login da remoto (VTY) dagli attacchi a forza bruta e DoS, con: ritardo tra tentativi successivi, shutdown del login sotto attacco DoS e/o generazione di Syslog degli accessi. P2 Questi i comandi di configurazione globale previsti: R(config)#login block-for secondi attempts volte within secondi R(config)#login quiet-mode access-class {num-acl | nome-acl} R(config)#login delay secondi R(config)#login on-failure log [every num-di-login] R(config)#login on-success log [every num-di-login]

P3 La gestione dei login col comando: login block-for detta Normal (o watch) mode e verifica solo quanti tentativi sono stati fatti. Quella del comando: login quiet-mode invece blocca anche gli accessi se il modo normale fallisce. Con il comando: login delay secondi si impone un intervallo tra un tentativo e laltro, contro gli attacchi a forza bruta. P4 I log dei tentativi di login, non attivi per default, vengono richiesti con i due comandi pi sopra, o col macro-comando: auto secure. Con: show login [failures] si vede quanto si configurato, e i valori dei contatori di fallimento:

10

Il Succo di CCNA Security

Powered by: MP eForHum

P5 Laggiunta di opportuni messaggi di banner pu informare gli utenti della sicurezza attiva sullapparato. Il comando : banner {exec | incoming | login | motd | slipppp} d messaggio d (d = delimiter), e si possono aggiungere, senza eccedere, dei token come: $(hostname), $(domain), $(line), $(line-desc).

2.1.4 La configurazione di SSH-Secure SHell


P1 Le password possono essere catturate con strumenti come Wireshark (ex Ethereal); se sono in chiaro, il sistema violato. SSH attivo dallIOS 12.1(1), e usa la cifratura di IPsec DES o 3DES (sigla k8 o k9 nel filename .bin). Luso di SSH prevede che i nomi degli apparati siano tutti diversi, e che sia invece uguale il loro nome di dominio; lautenticazione username-password pu essere in locale o su Server AAA. P2 Per attivare laccesso tramite SSH, seguire i seguenti step: configurare il nome di dominio col comando globale: ip domain-name dominio generare una coppia di chiavi asimmetriche basate sullhostname e sul dominio, col comando: crypto key generate rsa general-keys modulus size (size = tipico 1024, range 380 2048) verificare che le chiavi siano state generate, con: show crypto key mypubkey rsa; se ci sono gi chiavi presenti, azzerarle con: crypto key zeroize rsa verificare lesistenza di credenziali username-password valide, o configurarle abilitare SSH coi comandi di linea: login local e: transport input ssh P3 opzionalmente, SSH supporta altri parametri: la versione (ip ssh version {1 | 2}; la versione 2 usa lalgoritmo DH-Diffie Hellman per lo scambio sicuro delle chiavi IKE, quelle di cifratura dei parametri di negoziazione e il MAC-Message Authentication Code per il controllo di integrit. Il default modo compatibile); il time-out per la negoziazione dei parametri col partner (ip ssh time-out secondi; default = 120); infine il numero massimo di retries (ip ssh authentication-retries num; default = 3). Verificare il tutto con: show ip ssh . P4 Laccesso a un apparato con SSH pu avvenire da un altro apparato Client, o da un PC con gli emulatori: TeraTerm, PuTTY o OpenSSH. Nel primo caso, lanciare il comando privilegiato: ssh -l username ip-address (-opz = ad es. l, -v); con: show ssh si vedono le sessioni aperte. Da PC, invece, le credenziali (IP, username e password) vengono richieste in apposite finestre. Ricordare che SSH usa come Telnet la Porta TCP well-known n. 22. 11

Il Succo di CCNA Security

Powered by: MP eForHum

P5 SSH pu essere abilitato sugli apparati anche con SDM-Security Device Manager. Anche SDM permette di verificare lesistenza di chiavi rsa e di generarle se necessario:

2.2 Assegnare i ruoli amministrativi


2.2.1 La configurazione dei livelli di privilegio
P1 Per default, i livelli di accesso amministrativo sugli apparati sono 2: quello non privilegiato (User EXEC: livello 1; prompt R>) e quello privilegiato (Privileged EXEC: livello 15; prompt R#). P2 Il livello 0, predefinito, consente solo di vedere un Help (!?). possibile definire i comandi disponibile per gli altri livelli intermedi col comando: R(config)#privilege modo {level liv | reset | all} comando dove modo pu essere (da PT5.2): {configure | exec | interface | line | router}, level va da 0 a 15, e comando il nome del comando da attribuire a quel livello. Se questo indicato con parametri (es. show ip route) il livello abilitato anche per tutti i comandi show e per tutti i sottocomandi di show ip route. P3 Anche lautenticazione pu essere adeguata ai livelli cos definiti. Su pu definire una password per laccesso ad un certo livello, con: enable secret level liv password, oppure si possono definire credenziali individuali con: username nome privilege liv secret password (NB: non scambiare le ultime due keyword!). P4 I livelli superiori ereditano (inherit) tutti i privilegi dei livelli inferiori. Per accedere ad un certo livello, dare il comando: R>enable [liv] e rispondere al prompt con la password corrispondente; se liv manca, si accede al livello massimo = 15. P5 Nonostante il metodo di definizione dei livelli sia abbastanza flessibile, ha alcune limitazioni: non permette di specificare singole porte o interfacce, assegna sempre ai livelli superiori i comandi di quelli inferiori, non permette di fare il contario, e include tutti i comandi di una certa famiglia quando se ne indica uno in particolare (es. show ip route). Inoltre richiede un noioso lavoro di configurazione dei singoli comandi EXEC. 12

Il Succo di CCNA Security

Powered by: MP eForHum

2.2.2 La configurazione degli accessi alla CLI basati sul ruolo


P1 Per risolvere questi problemi, Cisco ha introdotto dallIOS 12.3(11)T la Role-based CLI per la definizione delle Viste (Views) sugli apparati, a favore della sicurezza e disponibilit della rete, e per una maggior efficienza operativa degli amministratori. P2 Per poter definire le Views si deve appartenere alla Root View, che ha i livelli di privilegio 15. Le singole Viste, o CLI Views, vengono associate ai vari comandi che possono eseguire, senza alcuna gerarchia n eredit dai livelli inferiori. Infine, le Superviews sono collezioni di CLI Views, anche ripetute in varie Superviews; cancellare una Superview non cancella le sue CLI Views. P3 Per configurare una CLI View, occorre: creare un nuovo modello AAA con: R(config)#aaa new-model; uscire con: exit entrare nella Root View con: R#enable view [root] rientrare in configurazione e creare una View con: R(config)#parser view nome; il Router si porta in view config mode (si possono definire fino a 15 Views oltre la Root) assegnare (subito!) una password alla View con: R(config-view)#secret password assegnare i comandi o le interfacce alla View con: R(config-view)#command modo {include | include-exclusive | exclude} [all] [command | interface tipo-num]; quindi uscire con: exit. Esempio (vedi anche: show run):

P4 Per creare una Superview, il procedimento analogo: basta aggiungere la keyword: superview dopo il comando: parser view nome e, entrati in modo R(config-view)#, assegnare la password e aggiungere le CLI-Views alla Superview col comando: view nome. Per entrare nelle varie Viste, usare il comando: R>/#enable view nome e dare la password. P5 Per verificare le Viste, entrarvi e verificare che i comandi attesi siano disponibili. Usare il comando: R#show parser view per vedere la propria View o, da Root View: R#show parser view all per vedere un sommario di tutte le Viste:

13

Il Succo di CCNA Security

Powered by: MP eForHum

2.3 Monitoraggio e gestione degli apparati


2.3.1 Mettere in sicurezza le immagini Cisco IOS e i files di configurazione
P1 Gli apparati dotati di Memoria Flash su scheda PCMCIA possono avere la funzionalit Cisco IOS Resilient Configuration, che salva una copia di sicurezza dellIOS e della configurazione (detti globalmente bootset) su tale supporto, in modo non visibile col comando: dir. I comandi per salvare i due file sono: R(config)#secure boot-image e: secure boot-config. P2 Le immagini di cui sopra possono essere aggiornate, e ogni aggiornamento genera un LOG. La funzione di Resilienza pu essere disabilitata solo via console, coi due comandi negati. Il sistema si accorge se le versioni running in RAM sono successive a quelle salvate, ed emette un messaggio; la Flash pu essere aggiornata ripetendo i messaggi: secure. P3 Per vedere i files archiviati, usare: show secure bootset, o il: dir di ROMmon. Per ricaricare lapparato con tali backup, svolgere i seguenti passi: riavviare il Router con: reload e portarsi in ROMmon (con Ctrl-Break entro 60) emettere il comando: dir e prendere nota dei nomi dei files col comando: boot di ROMmon, caricare limmagine protetta di IOS salvata in Flash entrare in modo global config con: conf t recuperare la configurazione protetta con: secure boot-config restore. P4 Descrizione della procedura per la normale Password recovery di un Router, gi nota dal CCNA: accesso da console, Ctrl-Break entro 60, cambio del confreg in ROMmon a 0x2142, reset o: continue per caricare lIOS senza configurazione, lettura o modifica delle password... NB: la Password recovery sugli Switch si fa in modo diverso. P5 Se attivo anche il comando globale nascosto: no service password-recovery, il Router indica al boot: Password recovery functionality is disabled e sente il Ctrl-Break solo per 5 durante la decompressione dellIOS, prima che compaia la scritta Image text-base. In tal caso il Router, dopo una conferma, cancella la configurazione corrente e si riporta ai factory default. Con la password recovery disabilitata non funziona il comando: xmodem del ROMmon per caricare nuove immagini IOS attraverso la porta console, e si deve ricorrere a Cisco per ottenere un nuovo IOS su flash SIMM o su scheda PCMCIA.

2.3.2 Le gestione e il reporting sicuri


P1 Pu essere importante, per una buona gestione della rete, archiviare i LOG degli eventi pi significativi, secondo quanto previsto in una Change Management Policy. I LOG possono essere mantenuti su un Server Syslog o in unapplicazione SNMP-Simple Network Management Protocol. 14

Il Succo di CCNA Security

Powered by: MP eForHum

P2 La gestione degli apparati e dei LOG pu essere fatta fuori banda (OOB-Out Of Band) su linee e reti dedicate, o in banda (In Band) sulle normali linee dati del traffico utente. In entrambi i casi, occorrono adeguate precauzioni per evitare che un hacker acceda alla rete di gestione, che ha di solito privilegi elevati: Firewall intermedi, VPN, autenticazione forte, VLAN separate, ecc. P3 La gestione OOB pi adatta a grandi reti, ma pu accorgersi tardi di problemi alla rete di produzione; la gestione In-Band, invece, pi semplice, ma va adeguatamente protetta, come detto, ad es. usando SSH invece di Telnet o tramite tunnel sicuri, ed aprendo gli accessi nei Firewall solo per il tempo necessario alla gestione.

2.3.3 Luso di Syslog per la sicurezza di rete


P1 I Server Syslog prevedono 8 livelli standard di severit degli eventi registrati:

I messaggi possono essere inviati, oltre che sulla linea CON (default), anche sulle linee VTY (se richiesto col comando: terminal monitor), in un buffer del Router per essere esaminati in differita, come TRAP a una stazione SNMP indicata con opportuno indirizzo IP, e a un Server di Syslog, come quelli presenti nei sistemi Microsoft o Linux, o negli apparati Cisco MARS. I messaggi di LOG possono contenere un timestamp, e indicano sempre un nome standard, il livello di severit e un messaggio in chiaro: P2 I messaggi inviati dai Syslog Client ai Syslog Server possono essere migliaia, ed difficile analizzarli. La soluzione Cisco MARS-Monitoring, Analysis and Response System permette di correlare i vari LOG e di segnalare in tempo reale, tramite regole, se essi indicano un potenziale problema in rete. MARS un tassello delliniziativa Cisco sulla Self-Defending Network. P3 I passi per configurare il Syslog su un Router o uno Switch Client sono, da R(config)#: indicare il nome o lIP del Syslog Server, con: logging host [nome | ip-addr] indicare il livello massimo di LOG da registrare, con: logging trap [liv | nome] indicare linterfaccia di cui fornire lIP nei messaggi, con: logging source-interface tipo num abilitare il servizio, con: logging on. Il servizio pu poi essere abilitato singolarmente verso le varie destinazioni con: logging buffered, logging monitor, ecc. P4 Il Syslog pu essere anche abilitato da SDM con la seguente schermata:

15

Il Succo di CCNA Security

Powered by: MP eForHum

P5 Sempre con SDM si possono vedere in tempo reale i LOG registrati dal sistema, come segue:

16

Il Succo di CCNA Security

Powered by: MP eForHum

2.3.4 Luso di SNMP per la sicurezza di rete


P1 Un altro diffuso metodo per archiviare gli eventi dei sistemi SNMP. Esso prevede lesistenza di oggetti gestiti (Managed Nodes) su cui gira un SNMP Agent, e di una o pi stazioni di gestione (NMS-Network Management Station), i messaggi generati dal protocollo SNMP girano sulla rete di produzione (OOB) e sono di tre tipi fondamentali: get e set, generati dalle NMS per leggere dati dagli Agent o assegnare dei set-point; e trap, generati come spontanee dagli Agent in casi urgenti. I messaggi get e set sono particolarmente vulnerabili. I dati scambiati hanno formati standardizzati detti MIB-Management Information Base, dipendenti dal tipo di oggetto controllato. P2 SNMP v1 e v2 usano delle Community string che permettono di scambiare i messaggi get (string read-only = public per default) e di set (string read-write = private per default). Queste stringhe fungono di fatto da password, e devono essere quindi cambiate. Inoltre SNMP v1 e v2 scambiano i messaggi in chiaro. P3 SNMP v3 ha affrontato questi problemi, introducendo una firma sui messaggi che ne garantisce lintegrit, lautenticazione degli interlocutori, e la cifratura del traffico. La configurazione di SNMP v3 esula per dagli scopi del Corso. P4 La combinazione di Security model (AAA) e Security level (tra i tipi indicati nel seguito) determina quale tipo di sicurezza viene usata sui messaggi SNMP v3. I livelli sono: noAuth: usa solo la Community string come le versioni precedenti di SNMP auth: autentica i messaggi coi metodi HMAC (basato su MD5 o SHA) priv: come sopra, e inoltre cifra i messaggi con DES, 3DES o AES (che vedremo). SDM non supporta la configurazione di SNMP v3. Per configurare SNMP v1 o v2, si deve selezionare SNMP dagli Additional Task Router Properties, e poi digitare il tasto Edit. Vanno quindi assegnate le Community string. SDM genera in configurazione i seguenti comandi: smnp-server community stringa ro (read-only) o: rw (read-write). P5 Sempre dalla stessa finestra di SDM, si pu assegnare il nome o lIP del Trap Receiver a cui il Router, come oggetto gestito, invier i suoi messaggi spontanei: premere il tasto Add.... Ovviamente le stringhe e i Trap receivers possono essere anche modificati o cancellati.

2.3.5 Luso di NTP-Network Time Protocol


P1 Luso dei LOG con timestamp pi facile se gli orari degli apparati sono sincronizzati. Gli apparati possono ricevere data e ora manualmente o tramite un Server NTP-Network Time Protocol che usa la Porta UDP 123 ed standardizzato nella RFC 1305. Per la configurazione manuale, da CLI si usa il comando privilegiato: clock set..., mentre da SDM si deve entrare nella voce Date/Time delle Router Properties gi viste. P2 Per la sincronizzazione automatica, occorre scegliere innanzitutto se farla da un Server interno (che va tenuto allineato con una sorgente esterna) o far accedere tutti direttamente ad Internet. Un Cliente e un Server NTP si scambiano lora se risultano associati. Configurare NTP richiede: la scelta di un Server NTP Master, con: ntp master [stratum] dove il n. finale indica la distanza in hops da un orologio atomico autoritativo di riferimento di attivare il servizio sui Client con: ntp server {ip-addr | nome} [version num] [key id] [source interfaccia] [prefer]

17

Il Succo di CCNA Security

Powered by: MP eForHum

in alternativa sui Client, di usare il comando: R(config-if)#ntp broadcast client, per accettare messaggi NTP in broadcast da un Server, abbastanza precisi anche se ricevuti senza dialogo. I comandi: show clock e: show ntp status mostrano i dati temporali. P3 Un attacco ai Time Server pu confondere gli amministratori, e va evitato tramite schemi restrittivi basati su ACL, e tramite lautenticazione cifrata prevista da NTP v3 e successive. Usare: R(config)#ntp authenticate per abilitare il servizio; R(config)#ntp authentication-key numero md5 password R(config)#ntp trusted-key numero Per vedere se tutto OK, usare: show ntp associations detail. P4 Per configurare NTP da SDM, accedere dalle Router Properties alla voce: NTP/SNTP-Simple Network Man. Prot., aggiungere un Server tramite il tasto Add... e configurarlo opportunamente:

2.4 Luso delle funzionalit di sicurezza automatiche


2.4.1 Effettuare una Security Audit
P1 Alcuni servizi e protocolli, abilitati per default sugli apparati Cisco, o attivati per necessit dalloperatore, possono aprire brecce nella sicurezza. Un esempio il protocollo CDP. Un attaccante pu usare un software free come Cisco CDP monitor (vedi schermata on-line) per capire quali apparati sono in rete. Conviene spegnere CDP, specie sui Router di frontiera (edge). P2 Vari servizi, che una volta aveva senso fossero abilitati per default, oggi vanno tenuti inattivi: SNMP, che pu non servire affatto ICMP, che deve essere almeno limitato Telnet, a cui va preferito SSH GARP-Gratuitous ARP e Proxy ARP linoltro degli IP-directed broadcast

18

Il Succo di CCNA Security

Powered by: MP eForHum

altri in figura: CDP, FTP/TFTP, NTP, PAD, servizi minori di TCP /UDP, MOP, DNS, HTTP, Finger, IP source routing, IP identification services... P3 Tre strumenti Cisco consentono di effettuare in automatico un controllo sulle vulnerabilit degli apparati: Cisco AutoSecure un audit tool che si lancia da CLI con comando: R#auto secure, e che pu poi attuare i rimedi proposti, in automatico o su conferma delloperatore Security Audit Wizard lo stesso audit tool, lanciato per dalla GUI di SDM One-Step Lockdown la seconda parte dello stesso tool lanciato da SDM, che implementa le protezioni necessarie; entrambi sono basati sulla funzione Cisco IOS AutoSecure.

P4 Il Security Audit Wizard, in particolare, presenta la seguente schermata sulle vulnerabilit:

19

Il Succo di CCNA Security

Powered by: MP eForHum

2.4.2 Il blocco (locking down) di un Router con AutoSecure


P1 La funzione auto secure (con spazio!), lanciata da IOS, opera sia sul piano di gestione (management plane) dellapparato, mettendo in sicurezza i servizi gi indicati, sia sul piano dellinstradamento (forwarding plane), agendo sui servizi: CEF-Cisco Express Forwarding, filtraggio traffico con le ACL, e il filtraggio stateful con lIOS firewall sui protocolli pi comuni (CBAC-Content Based Access Control). P2 Il comando in oggetto ha i seguenti parametri: R#auto secure [no-interact | full] [management | forwarding] [ntp | login | ssh | firewall | tcp-intercept] dove: no-interact chiede di fare direttamente lattuazione dei rimedi (default = full = interattivo) gli altri parametri chiedono di agire selettivamente sui vari piani e servizi. P3 Il comando segue i seguenti passi: mostra una schermata informativa di ingresso, identifica le interfacce coinvolte, propone i servizi di gestione da disabilitare, un banner e chiede le password; infine mette in sicurezza le interfacce e il forwarding plane.

2.4.3 Il blocco di un Router con SDM-Security Device Module


P1 Con la funzione One-step Lockdown vengono disabilitati (circa) gli stessi servizi pericolosi che si bloccano con la funzione CLI auto secure, dopo la Security Audit. Dopo un warning del programma, vengono elencate le funzioni che il programma intende mettere in sicurezza; premendo il tasto Deliver viene mostrata una finestra che mostra lavanzamento e la conclusione delloperazione:

P2 Cisco SDM svolge 5 funzioni in meno di auto secure, mentre ne svolge 3 in modo diverso:

20

Il Succo di CCNA Security Cap. 3

Powered by: MP eForHum

Autenticazione, Autorizzazione e Accounting

3.1 Scopo dellAAA


3.1.1 Una panoramica sullAAA
P1 Per controllare laccesso agli apparati di rete, il metodo pi semplice si basa sulle password (comando: R(config-line)#password valore) che per, in assenza del servizio di password encryption, restano in chiaro nella configurazione, sono soggette ad attacchi a forza bruta e non identificano chi fa il login (no accountability). Meglio perci richiedere la coppia username-password, configurabile coi comandi: R(config)#username nome-utente {password | secret} valore R(config)#line vty 0 4 R(config-line)#login local Le credenziali di Authentication possono essere registrate localmente sui singoli apparati come da esempio, con un notevole aggravio per lamministratore, o essere centralizzate sui Server AAA. P2 Le funzioni dei Server AAA permettono un controllo pi fine sugli accessi: Authentication: verifica che lutente sia chi dice di essere, tramite password, challengeresponse, token card, metodi biometrici, ecc Authorization: stabilisce che cosa tale utente abbia diritto di fare: quali Server vede, ecc Accounting: registra che cosa lutente ha fatto, a livello di login-logout o sulle singole azioni. I controlli sono quindi simili a quelli che vengono fatti per luso di una carta di credito.

3.1.2 Le caratteristiche dellAAA


P1 Laccesso alle risorse di rete pu essere fatto per scopi amministrativi usando un traffico a caratteri (Character mode Telnet/SSH sulle linee CON, AUX o VTY), o per fare traffico dati verso qualche Server della rete (Packet mode, ad es. su una linea dial-up con PPP, o su VPN). Le prime due A dellAAA si applicano a entrambi i tipi di accesso, mentre lAccounting riguarda solo il traffico dati. LAutenticazione AAA pu avvenire, come detto, in locale o basata su Server di tipo RADIUS o TACACS+ (come Cisco Secure ACS-Access Control Server, anche in versione Solution Engine o Express):

21

Il Succo di CCNA Security

Powered by: MP eForHum

P2 LAutorizzazione consiste nel determinare che cosa lutente pu o non pu fare, come i livelli di privilegio o quelli role-based dicono quali comandi CLI ha a disposizione un operatore. Le Autorizzazioni sono un set di attributi del profilo utente che vengono scaricati dal Server al Router in automatico, e consentono o bloccano determinate operazioni. P3 LAccounting sempre svolto inviando i LOG ad un Server. Pu registrare veri tipi di eventi: di rete: cattura il traffico PPP e simili (SLIP, ARAP), inclusi il n. di Pacchetti e di bytes di connessione: cattura le connessioni uscenti, Telnet e simili (LAT, TN3270, PAD, rlogin) di EXEC: cattura le connessioni di console entranti: utente, start-stop, IP o num. tel. mittente di sistema: cattura gli eventi di sistema, come reboot, Accounting on-off, ecc. di comando: cattura i singoli comandi IOS di livello privilegiato, con data e ora di esecuzione di risorsa: cattura i record di start e stop degli utenti che si autenticano o non ci riescono.

3.2 LAutenticazione AAA locale


3.2.1 La configurazione dellAutenticazione AAA locale con CLI
P1 Questa autenticazione, detta anche self-contained Authentication o self-contained AAA adatta solo per reti piccole. simile allautenticazione login local gi vista, ma offre anche un metodo di login di backup (ad es. per password di utente dimenticata). Richiede, oltre a definire le coppie username-password degli utenti da autenticare, di svolgere i passi seguenti. P2 Innanzitutto va abilitato globalmente lAAA col comando: R(config)#aaa new-model. Quindi devono essere definite le liste dei metodi di autenticazione ammessi (da 1 a 4), da applicare poi alle interfacce daccesso (VTY, TTY, COM e/o AUX). Il comando per definire una lista : R(config)#aaa authentication login {default | nome-lista} metodo1 [... metodo4] (metodi separati da spazi) dove: default il nome della lista base, mentre possono essere definite liste con nomi diversi i metodi possono essere vari: enable dice che possibile autenticarsi con la password di enable; krb5 e krb5-telnet dicono che lautenticazione la fa un Server Kerberos; line dice che basta la password di login sulla linea; local e local-case fanno autenticazione locale (col secondo: case sensitive); cache nome dice che ci si autentica su un cache Server; group nome dice che il Server nel gruppo indicato (si possono creare gruppi RADIUS, TACACS+, ecc); none dice che non serve autenticazione (usare in fondo alla lista, solo in reti di test) I metodi dopo il primo sono tentati solo se il metodo precedente non da risposta o va in errore, mentre se lautenticazione espressamente negata, il processo termina. Altri comandi simili sono: R(config)#aaa authentication enable che abilita lAAA per laccesso al solo modo EXEC privilegiato, e: R(config)#aaa authentication ppp che abilita lAAA per laccesso da linee seriali Point to Point Protocol. P3 Le varie liste possono essere applicate alle diverse interfacce coi comandi: R(config)#line linea numero R(config-line)#login authentication nome-lista Tutte le linee hanno applicata la lista base default, se questa risulta definita. In caso contrario, lautenticazione si fa solo a fronte del DB di username-password definito localmente. 22

Il Succo di CCNA Security

Powered by: MP eForHum

P4 Il comando: R(config)#aaa local authen attempts max-fail num-errori (non in PT5) permette di bloccare un utente se sbaglia pi di num-errori volte laccesso; lutente pu essere sbloccato solo da un amministratore (vedi sotto). Il comando: login delay, gi visto, invece impone solo una pausa tra i tentativi successivi. Col comando: R#show aaa local user lockout si vede lelenco degli utenti bloccati, che possono venire riammessi (uno o tutti) col comando: R#clear aaa local user lockout {username nome | all}. Con: R#show aaa user {sess-id | all} si vedono i dati raccolti sulle sessioni attive (IP dellutente, protocollo usato, velocit del link, n. di Pacchetti e bytes scambiati...), mentre con: R#show aaa sessions si vedono le sessioni attive.

3.2.2 La configurazione dellAutenticazione AAA locale con SDM


P1 AAA abilitato per default in SDM, ma ci pu essere verificato nella pagina AAA del men: Configure Additional Tasks. Se AAA viene disabilitato col tasto in alto a destra, il Router informa che modificher la configurazione per assicurarsi un accesso anche dopo loperazione.

P2 La prima cosa da fare creare gli utenti locali, da Configure Additional Tasks Router Access User Accounts/Views. Cliccare il tasto Add..., immettere il nome, la password (due volte), il livello di privilegio (lasciare 15 se non si sono creati livelli minori) o la View associata. Il Router crea ad es. il comando: username nome priv 15 secret 5 pswd view root. P3 Vanno poi create le liste di metodi per lAutenticazione, da applicare quindi alle varie linee. Configure Additional Tasks AAA Authentication Policies Login. Cliccare Add..., scegliere il nome della lista o lasciare default, aggiungere da 1 a 4 metodi (=local!), cliccare OK. Il tasto Save nella toolbar alta salva il lavoro, come il: copy run sta. Cisco dimentica di illustrare come si applicano le liste di metodi alle varie linee. 23

Il Succo di CCNA Security

Powered by: MP eForHum

3.2.3 Il troubleshooting dellAutenticazione AAA locale


P1 Il comando: R#debug aaa permette di verificare molte cose sui servizi AAA, in particolare sullAutenticazione. Lanciarlo quando va tutto bene per vedere gli output normali, e capire poi cosa non funziona se ci sono problemi.

P2 Con la keyword: authentication si ottiene il seguente output. Verificare soprattutto i messaggi di stato GETUSER e GETPASS, e la lista su cui si tenta lautenticazione.

3.3 LAAA basata su Server


3.3.1 Le caratteristiche dellAAA basata su Server
P1 Quando la rete cresce, meglio affidare lautenticazione ad un Server, come Cisco Secure ACS. Questo Server RADIUS e TACACS+ pu recuperare le credenziali degli utenti da DB esterni, come le Active Directory o i Server LDAP-Lightweight Directory Access Protocol. P2 TACACS+ Terminal Access Control Access Control Server + considerato pi sicuro di RADIUS Remote Access Dial-In User Services in quanto cifra tutto il traffico dal Router al Server; RADIUS invece cifra solo le password, lasciando in chiaro gli username e altre info. 24

Il Succo di CCNA Security

Powered by: MP eForHum

3.3.2 I protocolli di comunicazione dellAAA basata su Server


P1 Differenze tra TACACS+ e RADIUS: TACACS+ RADIUS Funzionalit Permette di separare le tre A Mantiene le prime due A insieme Standard Supportato soprattutto da Cisco Standard aperto (RFC 2138, 2865...) Prot. di Trasporto TCP (Porta 49) UDP (Porta 1812, old=1645) Autenticaz. CHAP S, bidirezionale o mutua S, ma solo verso il Client (supplicant) Supporto multiprot. S Parziale (no ARA n NETBEUI) Confidenzialit Cifra lintero traffico Cifra solo le password Customizzazione Profili singoli o di gruppo Non permette la scelta (solo singoli?) Accesso remoto Non definito Supporta 802.1X e SIP P2 TACACS+ incompatibile con le versioni precedenti TACACS e XTACACS. disponibile dallIOS 10.3; supporta vari protocolli, come IP ed Appletalk. Bella animazione. P3 RADIUS usato in locale e in remoto, e supporta bene lAccounting (sulle Porte 1813 e 1646); le sue RFC sono le 2865 2868. Cifra anche le password PAP con MD5, ma non il resto. molto usato dai VoIP Service Providers tramite il protocollo SIP-Session Initiation Protocol. Il Server destinato a succedere a RADIUS DIAMETER, che usa a livello 4 TCP e il nuovo protocollo SCTP-Stream Control Transmission Protocol del 2000. Bella animazione.

3.3.3 Il Cisco Secure ACS-Access Control Server


P1 Esistono sul mercato i Server RADIUS di Funks Steel-Belted, Livingston Enterprises e Merit Networks, ma solo il Cisco Secure ACS combina in un unico Server i protocolli RADIUS e TACACS+, offrendo diversi vantaggi. P2 Cisco Secure ACS usa un DB centralizzato per il controllo dei privilegi concessi agli utenti, e raccoglie report dettagliati sulle attivit da loro svolte. Supporta accessi su reti wired e wireless, in dial-up, a larga banda, per il VoIP, tramite Firewall e VPN. Gestisce anche lautenticazione LDAP, e permette di definire restrizioni sui giorni e gli orari di accesso, e i profili dei gruppi. P3 Cisco Secure ACS un elemento dellarchitettura Cisco IBNS-Identity Based Networking Services, basata sullo Standard di sicurezza IEEE 802.1X e su EAP, per la protezione della rete ad ogni livello a partire dal suo perimetro, dove si trovano Switch e AP RADIUS-enabled. anche parte delliniziativa NAC-Network Admission Control, che permette di mettere in quarantena ogni Client che cerca di accedere alla rete senza sufficienti garanzie di protezione da virus, worm, ecc. Il NAC a sua volta rientra nelliniziativa della Cisco Self-Defending Network. P4 Cisco Secure ACS vanta elevate caratteristiche di funzionalit e scalabilit.

facile da usare, grazie alla sua interfaccia GUI; scalabile, supportando Server ridondati e remoti; estendibile, grazie al supporto allo standard LDAP; gestibile in ambiente Windows, essendo compatibile con Active Directory e con Windows Performance Monitor; facile da amministrare, dato che permette di gestire gli utenti e gli apparati in gruppi; flessibile ed 25

Il Succo di CCNA Security

Powered by: MP eForHum

integrabile, perch compatibile con tutte le versioni recenti di IOS, con le VPN e con PPP multichassis e multilink; compatibile con i token di tutti i sistemi OTP-One Time Password RADIUS-compliant, come RSA, PassGo, Secure Computing, ActiveCard, Vasco e CryptoCard; controllabile, perch consente accessi in base allora e al giorno del login, al grado di occupazione della rete e al numero di sessioni gi aperte. P5 Le tre soluzioni commerciali di Cisco Secure ACS sono: Cisco Secure ACS for Windows: soluzione software da installare su Server Windows 2000 o 2003 del cliente o sulle due soluzioni hardware seguenti, che accede ad un DB di autenticazione esterno Cisco Secure ACS Solution Engine: soluzione hardware su Server da rack 19 1U (= 1,75 inches = 44,5 mm di spessore), preinstallata e dimensionata per aziende sopra i 350 utenti

Cisco Secure ACS Express 5.0: soluzione hardware su Server da rack 19 1U, preinstallata e dimensionata per aziende sotto i 350 utenti (max 50 contemporanei). Interfaccia GUI facilitata, prezzo minore.

3.3.4 La configurazione del Cisco Secure ACS


P1 Cisco dichiara sul suo sito quali sono i software interoperabili con Cisco Secure ACS, quando interagisce con Client quali Router, Switch, Firewall, VPN Concentrator e Access Point. Gli IOS compatibili sono da 11.2 in poi; i Client non Cisco possono accedere con RADIUS e/o TACACS+; deve essere verificata la connettivit da e verso i Client, anche su linee dial-in, VPN e wireless; i Gateway intermedi devono permettere il traffico sulle Porte TCP/UDP richieste; il Client deve disporre di un Web browser supportato; tutte le NIC del Server devono essere attive, per non rallentare il Server con le CryptoAPI Microsoft. A Cisco Secure ACS si accede solo tramite interfaccia HTML, lanciata dallicona ACS Admin o digitando lURL http://127.0.0.1:2002, o lIP del Server remoto seguito da: :2002. P2 Le funzioni disponibili, attivate con i relativi tasti (in figura un esempio) sono: User Setup, Group Setup, Shared Profile Component, Network Configuration, System Configuration, Interface Configuration, Administration Control, External User Databases, Posture Validation, Network Access Profile, Report and Activity, Online Documentation. Le opzioni RADIUS possono essere abilitate separatamente da quelle di default TACACS+.

P3 Prima di configurare un Client per laccesso al Server ACS, il Client AAA (il Router!) deve essere dichiarato sul Server, configurandone vari parametri. Procedere come segue: selezionare la funzione Network Configuration e Add Entry digitare il nome e lIP del Client, e la secret key per la cifratura del traffico AAA scegliere il protocollo AAA richiesto (TACACS+ e/o RADIUS, in varie versioni) completare le altre opzioni e cliccare su Submit & Apply. 26

Il Succo di CCNA Security

Powered by: MP eForHum

Dalla funzione di Interface Configuration possibile controllare i Servizi ivi offerti dal Server:

P4 La configurazione dellaccesso ai DB di autenticazione esterni si fa tramite il tasto External User Databases. unoperazione complessa, con ulteriori opzioni in caso di accesso a DB Windows; solitamente richiede che ogni utente sia presente in una sola istanza dei DB configurati, dato che viene presa per buona la sua prima comparsa. Le opzioni fondamentali sono: la Unknown User Policy, che permette di definire il profilo degli utenti non compresi nel DB di ACS locale, ma solo nei DB esterni; la Database Group Mappings, che dice quali privilegi locali ereditano (inherit) gli utenti rilevati nei DB esterni; la Database Configuration, che indica quali sono i DB esterni (di vari tipi: RSA SecurID, RADIUS Token Server, External ODBC DB, Windows DB, LEAP Proxy RADIUS Server e Generic LDAP). Per un Windows DB, cliccare il tasto Configure; tra le opzioni aggiuntive compare la sezione Dialin Permission, che permette di abilitare in pi laccesso da remoto (Grant dialin p.) se ci previsto anche nel profilo del Windows Users Manager. Un Windows DB pu anche essere visto da diversi Domini, con lo stesso username, ma con password diverse.

3.3.5 La configurazione di Utenti e Gruppi su Cisco Secure ACS


P1 Gli utenti possono ricevere i privilegi di accesso singolarmente o per gruppi. Il secondo caso si applica anche al gruppo degli Unknown User autenticati dai DB esterni. La funzione deve essere abilitata con un check in apposita casella. Ogni DB esterno predefinito che deve essere esaminato alla ricerca di tali utenti, deve essere spostato nella Selected Database List con lapposita freccia. I DB selezionati possono essere messi in ordine di preferenza con Up/Down. Premere poi Submit. P2 Gli utenti autenticati da un Windows DB potrebbero richiedere autorizzazioni diverse da quelle concesse agli utenti LDAP: per questo torna comoda lautorizzazione per gruppi diversi. Alcuni DB consentono lappartenenza degli utenti a un solo gruppo, altri a pi gruppi. Ogni gruppo pu ad es. specificare quali comandi IOS un suo utente pu o non pu eseguire. Da SDM: lanciare il Wizard Group Setup; cliccare il tasto Edit Settings; selezionare il Permit o il Deny sui singoli comandi e parametri; concludere con Submit. P3 Per aggiungere un utente, lanciare il Wizard User Setup; indicare uno Username e cliccare il tasto Add/Edit; fornire altri dati (password; abilitazione, password e comandi TACACS+); Submit. 27

Il Succo di CCNA Security

Powered by: MP eForHum

3.4 LAutenticazione AAA basata su Server


3.4.1 La configurazione dellAutenticazione AAA basata su Server con CLI
P1 Per utilizzare i Servizi AAA con CLI, i passi richiesti sono i seguenti: abilitare globalmente il Servizio AAA, col comando: R(config)#aaa new-model specificare il/i Server AAA di tipo TACACS+ o RADIUS da usare (es. Cisco Secure ACS) indicare la chiave di cifratura (encryption key) per proteggere il traffico verso tali Server configurare la lista dei metodi di autenticazione per avere accesso ai Servizi di tali Server. P2 I Server TACACS+, ad esempio, si indicano col comando: R(config)#tacacs-server host {ip-address | nome-Server} [single-connection] dove il parametro finale indica a TCP di tenere aperta ununica connessione per tutta la sessione. R(config)#tacacs-server key valore indica invece la chiave di cifratura comune tra il Server e il Router AAA (terzo passo sopra). R(config)#radius-server host {ip-address | nome-Server} R(config)#radius-server key valore sono invece i comandi per indicare un Server RADIUS (che usa UDP, quindi non crea connessioni) e la relativa chiave di cifratura del traffico. Infine, per autenticarsi presso i Server indicati, occorre includerli tra i metodi di login del comando: R(config)#aaa authentication login {default | nome-lista} metodo1 [... metodo4] (metodi separati da spazi) gi visto in 3.2.1.2. In particolare, usare i metodi: group tacacs+ e/o: group radius e concludere con un: local-case per le emergenze.

3.4.2 La configurazione dellAutenticazione AAA basata su Server con SDM


P1 Analoghe configurazioni possono essere svolte con SDM, come in parte gi visto: Configure Additional Tasks AAA AAA Servers and Groups AAA Servers tasto Add scegliere il tipo (TACACS+ / RADIUS), darne lIP o il Nome (se presente un DNS/Wins) cliccare il controllo sulla Single connection modificare eventuali Timeout di default (5) e assegnare la chiave di cifratura (due volte per conferma); se non indicata per lo specifico Server, usa quella comune configurata nella finestra AAA Servers Global Settings. Cliccare OK. P2 Per fare il login su un Router AAA con autenticazione su Server esterno, occorre definire tale Server in un metodo; se tale metodo quello di default, verr applicato a tutte le interfacce reali e virtuali del Router, che non abbiano applicata un'altra lista di metodi specifici. Con SDM: Configure Additional Tasks AAA Authentication Policies Login Add la lista di Default, o una nuova User defined di metodi indicare il Nome della lista aggiungere con Add i singoli metodi che la lista usa, scegliendoli dallelenco drop-down (ad es. group tacacs+, seguito da enable come metodo di emergenza = usare per il login la password di enable). OK; OK. Il comando CLI creato : R(config)#aaa authentication login Nome group tacacs+ enable. Segue limmagine delle principali pagine SDM coinvolte nella configurazione:

28

Il Succo di CCNA Security

Powered by: MP eForHum

P3 La lista di metodi creata deve essere applicata alle linee interessate (es. VTY) tramite: Configure Additional Tasks Router Access VTY cliccare Edit scegliere (solo in figura): il range delle VTY (es. 0 4), il Timeout dopo cui si fa logout automatico (default 10); il protocollo abilitato in input e output (Telnet e/o SSH); lAuthentication Policy (=lista metodi) definita nel passo precedente premere OK.

3.4.3 Il Troubleshooting dellAutenticazione AAA basata su Server


P1 Nel Troubleshooting utile il comando: R#debug aaa authentication che mostra ad alto livello lattivit di login. Se finisce con PASS, tutto ok; con FAIL, verificare la chiave segreta.

P2 Utili sono anche i comandi: R#debug tacacs e: R#debug radius che permettono di vedere in modo pi dettagliato i relativi messaggi (TACACS in particolare con la keyword events):

29

Il Succo di CCNA Security

Powered by: MP eForHum

3.5 LAutorizzazione e lAccounting AAA basati su Server


3.5.1 La configurazione dellAutorizzazione AAA basata su Server
P1 LAutorizzazione stabilisce che cosa un utente autenticato possa fare o non fare, in termini di risorse di rete, di Servizi, di programmi (network authorization) o di comandi IOS (exec author.). TACACS+ pu separare i Servizi di Autenticazione e Autorizzazione su Server diversi, mentre RADIUS tiene le due funzioni sempre unite. Lutente JR-Admin pu ad esempio essere autorizzato (ACCEPT) dal Server ACS ad eseguire il comando: show version, ma non (REJECT) il comando: config terminal. ACS, quando opera come Server TACACS+, pu mantenere aperta una sola sessione TCP persistente per tutte le richieste di autorizzazione. P2 La funzione di Autorizzazione si configura col comando: R(config)#aaa authorization {network | exec | commands level} {default | nome-lista} metodo1 [... metodo4] Mentre, quando la funzione non abilitata, tutti gli utenti hanno pieno accesso alle risorse, appena essa viene attivata il default diventa lopposto, e lamministratore si pu trovare escluso dal sistema e deve riavviare il Router, cosa che in produzione pu essere molto negativa. Si deve creare quindi un utente con pieni diritti di accesso prima di attivare la funzione di autorizzazione (come? Sembra un serpente che si morde la coda! Forse basta non uscire). Esempio:

P3 Come per lAutenticazione, anche per lAutorizzazione la configurazione pu essere fatta con SDM, creando una Authorization Policy con una lista di metodi, fino a 4. La lista di default si applica a tutte le interfacce che non abbiano applicata una lista specifica User defined. Esempio: Configure Additional Tasks AAA Authorization Policy Exec cliccare Add scegliere il Nome default per la lista cliccare Add aggiungere il metodo group tacacs+ doppio OK. Comando creato: aaa autorization exec default group tacacs+ P4 Analogamente, si possono stabilire le Authorization Policy per i Servizi in Packet mode (Network), che producono un comando come sopra, con: network al posto di: exec.

3.5.2 La configurazione dellAccounting AAA basato su Server


P1 I metodi di Accounting (raccolti nella lista di default o in liste specifiche per interfaccia) permettono di tenere traccia delle azioni svolte dagli utenti autenticati sulle risorse autorizzate. Ci permette di addebitare eventuali costi, di rilevare quando gli utenti hanno fatto login, per quanto tempo ed eventualmente svolgendo quali azioni o comandi. Anche la lista dei cambiamenti di configurazione effettuati pu aiutare successive fasi di troubleshooting. P2 Il comando per attivare lAccounting dello stesso tipo dei precedenti: R(config)#aaa accounting {network | exec | connect} {default | n} {start-stop | stop-only | none} [broadcast] metodo1 [... metodo4]. 30

Il Succo di CCNA Security Cap. 4

Powered by: MP eForHum

Limplementazione delle tecnologie Firewall

4.1 Le Access Control List


4.1.1 La configurazione delle ACL Standard ed Estese con CLI
P1 Le ACL possono essere usate per controllare il traffico ai livelli 2, 3, 4 e 7. In passato venivano usate le ACL numeriche nel range 200-299 per filtrare il traffico in base al campo Ethernet Type delle Trame (es. 0x8035 = messaggio RARP), o le ACL 700-799 per farlo in base agli indirizzi MAC. Oggi le ACL sono pi spesso basate sugli indirizzi L3 IPv4 o IPv6 e sulle Porte TCP e/o UDP, e quindi ai protocolli e servizi richiesti. P2 Le ACL Standard numeriche per IPv4 e IPv6 hanno numero da 1 a 99 e da 1300 a 1999; esse controllano solo lIP sorgente dei Pacchetti, e non possono indicare alcun protocollo L4-L7: R(config)#access-list numero {permit | deny} IP-sorgente [w.m.] Le ACL Estese numeriche per IPv4 e IPv6 hanno numero da 100 a 199 e da 2000 a 2699; esse controllano i Pacchetti in base sia allIP sorgente sia alla destinazione, e possono anche indicare un protocollo L4 (TCP o UDP) ed L7 (Porte Well-known). La sintassi (semplificata) del comando : R(config)#access-list numero {permit | deny} protocollo IP-sorgente w.m. [operator Port [Port]] IP-destinaz w.m. [operator Port [Port]] [established] NB: protocollo = ip | tcp | udp | icmp; le due w.m.-wildcard mask sono in questo caso obbligatorie [errore on-line]; gli operator sono: eq | lt | gt | neq | range con Porta-iniziale e Porta-finale, validi solo per tcp e udp. La keyword established possibile solo con tcp. Le ACL, sia standard sia estese, hanno un deny finale implicito; se devono consentire il traffico diverso da quello specificato, inserire un permit finale esplicito. Possono essere applicate alle interfacce e alle linee VTY, in ingresso o in uscita dal Router, con i comandi: R(config-if)#ip access-group numero {in | out} R(config-line)#access-class numero {in | out} P3 Le ACL possono anche avere un nome invece di un numero; vengono create col comando: R(config)#ip access-list {standard | extended} nome-ACL Nel sottomodo specifico di configurazione vengono poi usati i comandi permit e deny, con sintassi analoga a quella delle ACL numeriche: 31

Il Succo di CCNA Security

Powered by: MP eForHum

R(config-std-nacl)#{permit | deny} {IP-sorgente [w.m.] | any} R(config-ext-nacl)#{permit | deny} protocol IP-sorg. IP-dest. ... Le entry di una ACL con nome possono essere cancellate, aggiunte anche in posizione intermedia o modificate singolarmente, a differenza delle ACL numeriche che si possono solo riscrivere tutte. Anche le ACL con nome si devono poi applicare alle interfacce o alle linee VTY; in questo caso possibile specificare se il protocollo ammesso Telnet (Porta 23) o SSH (22); destinatario = any.

P4 Usando il parametro finale: log in una ACL entry si ottiene che il Router invii alla console e ad ogni altro sistema di log attivo (buffer interno, Syslog Server, ecc.) un record come il seguente:

I log sono generati al primo evento e poi ad intervalli di 5, ma possono appesantire il Router. P5 Alcune attenzioni (several caveats) devono essere poste nello scrivere le ACL: la presenza del deny finale, che c anche se non si vede, e blocca tutto il traffico residuo le ACL standard controllano solo il mittente; usare ACL estese per un miglior controllo lordine delle entry importante: usare prima quelle pi specifiche, poi le pi generali il filtraggio direzionale: capire se lACL va applicata a quel che entra o esce dal Router nuove entry sono aggiunte nelle ACL numeriche solo alla fine; usare quelle con nome per poter aggiungere statement intermedi, assegnando loro un numero di posizione i Pacchetti generati dal Router (es. routing update) non sono filtrati dalle ACL outbound consentita solo unACL per interfaccia, per direzione e per protocollo (IP, IPX, ecc.).

4.1.2 Luso delle ACL IP Standard ed Estese


P1 La scelta tra ACL standard ed estese dipende dal contesto di sicurezza che si deve proteggere. Nella rete seguente, se la subnet 172.16.4.0 non deve accedere solo alla subnet 172.16.3.0, basta creare unACL standard per linterfaccia di uscita, come segue: R1(config)#access-list 1 deny 172.16.4.0 0.0.0.255 R1(config)#access-list 1 permit any R1(config)#interface fa0/0 R1(config-if)#ip access-group 1 out

32

Il Succo di CCNA Security

Powered by: MP eForHum

P2 Nello stesso scenario, per vietare solo il traffico FTP tra le due subnet, usare unACL estesa: R1(config)#access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21 ;21 = Porta comandi dellFTP R1(config)#access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20 ;20 = Porta dati dellFTP R1(config)#access-list 101 permit ip any any R1(config)#interface fa0/1 R1(config-if)#ip access-group 101 in ;evita traffico nel Router

4.1.3 La topologia e il flusso per le Access Control List


P1 Il traffico entrante viene controllato dalle ACL, prima di verificare in Routing Table come instradarlo. Quello in uscita viene filtrato dopo il routing, prima dellaccodamento sullinterfaccia. P2 Le ACL estese meglio applicarle (place) ad interfacce vicine al mittente, per evitare traffico inutile in rete. Quelle standard invece vanno applicate vicine alla destinazione, per evitare di bloccare anche traffico non vietato o per cautelarsi contro possibili giri alternativi di quello vietato. P3 Le ACL estese possono bloccare certi tipi di traffico da una sorgente, ma non da unaltra: ad es. il download di posta su un PC con POP3 (Porta TCP 110) pu essere vietato da Internet, ma non da un Server di posta interno. Uno scan fatto con Nmap (per vedere le porte aperte sul un Host) dal PC in questione mostra che la Porta 110 aperta sul Server, ma non sul Default Gateway (figura e testo on-line piuttosto dubbi):

P4 Per vedere se unACL attiva, meglio evitare di usare stabilmente il parametro finale: log. Meglio verificare con: R#show [ip] access-list, che indica anche quanti match le singole entry (o ACE-Access Control Entry) hanno fatto: R1#show [ip] access-list Extended IP access list 100 10 deny tcp any host 192.168.1.3 eq telnet (12 matches) 20 permit ip any any (1355 matches) Verificare anche con: R#show running-config :

33

Il Succo di CCNA Security

Powered by: MP eForHum

4.1.4 La configurazione delle ACL Standard ed Estese con SDM


P1 SDM permette di creare ad applicare le ACL tramite la sua interfaccia grafica. Cliccare il tasto Configure in alto e il tasto del Wizard Additional Tasks a sinistra. P2 SDM chiama Regole (Rules) le ACL e altri filtraggi; vedi Additional Tasks ACL Editor:

Le Rules che SDM riconosce sono, come si vede: le Access Rules, che sono le normali ACL IP le NAT Rules, che regolano la traduzione tra indirizzi privati e pubblici le IPsec Rules, che individuano il traffico da cifrare le NAC Rules, che specificano gli IP ammessi o meno alla rete (Network Admission Control) le Firewall Rules, che sono analoghe alle Access Rules, ma pi sofisticate le QoS Rules, che specificano il traffico voce o video che richiede una certa classe di servizio le Unsupported Rules, che sono state create in CLI e possono solo essere viste in SDM le Externally-defined Rules, che sono state create in CLI, ma gestibili in SDM, non su una IF le SDM default Rules, che sono regole predeterminate usate dal Wizard SDM. P3 I passi per definire una ACL (Access Rule) con SDM sono: ACL Editor Access Rules Add assegnare un nome o un numero alla Rule, indicare se Standard o Extended e una eventuale descrizione; Add... delle singole Entry (Permit/Deny e tutti i parametri necessari, tra cui una descrizione della Entry e leventuale log finale) OK. Le Entry introdotte possono essere clonate, modificate, cancellate o spostate in su o in gi. P4 Le Access Rules create devono quindi essere associate ad uninterfaccia attiva (up-up), tramite il tasto Associate... che permette di indicare anche la direzione Inbound/Outbound. P5 I comandi IOS generati da SDM possono essere esaminati dal tasto View Running Config disponibile nella Home Page del programma, o dalla voce View del Men in alto (vedi): 34

Il Succo di CCNA Security

Powered by: MP eForHum

4.1.5 La configurazione delle ACL TCP Established e Riflessive


P1 Esempi di ACL pi complesse di quelle viste finora, sono quelle che lasciano passare da Internet alla LAN il traffico delle sole sessioni TCP gi aperte dallinterno (tramite la keyword established, 1995), e le ACL reflexive (1996) che analogamente ammettono solo traffico di ritorno, tramite entry temporanee che vengono rimosse alla fine di ogni connessione TCP.

P2 Le ACL Estese con la keyword established verificano solo che i Segmenti TCP entranti verso la LAN abbiano i flag ACK o RST attivi (tipico delle risposte a richieste di connessione inviate dallinterno). Non si applicano ai Segmenti UDP n ai Pacchetti ICMP. Non tengono alcuna traccia delle connessioni realmente aperte, e sono quindi dei buchi (hole) che possono essere superati dagli hacker che creano messaggi artefatti con Nmap o altri generatori di traffico:

35

Il Succo di CCNA Security

Powered by: MP eForHum

P3 I seguenti comandi permettono il traffico entrante verso la LAN sono se si tratta di risposte provenienti da un Server HTTPS (Porta 443) o se traffico SSH (Porta 22) verso un dato Host: R(config)#access-list 101 permit tcp any eq 443 192.168.1.0 0.0.0.255 established R(config)#access-list 101 permit tcp any host 192.168.1.3 eq 22 R(config)#access-list 101 deny ip any any R(config)#interface s0/0 R(config-if)#ip access-group 101 in P4 Le Reflexive ACL permettono un filtraggio pi stretto delle ACL established, in quanto il traffico di ritorno deve avere anche gli IP e le Porte giuste, e pu avvenire solo allinterno delle connessioni gi aperte, essendo permesso da una entry temporanea inserita nellACL entrante, che limita il tempo di un attacco DoS o simili. Il meccanismo prevede la scrittura di unACL uscente (inbound sullinterfaccia LAN, o outbound su quella WAN) con la keyword: reflect. Ogni Segmento uscente che fa match con tale ACL genera una entry temporanea nella ACL con nome entrante che permette il solo traffico di ritorno per quel Segmento, con gli indirizzi IP e le Porte scambiati rispetto al Segmento uscente. P5 Ad esempio, per permettere la sola navigazione web dalla LAN, usare i seguenti comandi: R(config)#ip access-list extended uscente R(config-ext-nacl)#permit tcp any any eq 80 reflect risposte-web R(config-ext-nacl)#permit udp any any eq 53 reflect risposte-dns timeout 10 R(config-ext-nacl)#exit R(config)#ip access-list extended entrante-rifl R(config-ext-nacl)#evaluate risposte-web R(config-ext-nacl)#evaluate risposte-dns R(config-ext-nacl)#deny ip any any ;inutile, gi implicito! R(config-ext-nacl)#exit R(config)#interface s0/0 R(config-if)#ip access-group uscente out R(config-if)#ip access-group entrante-rifl in. Esempio di entry temporanea generata nella ACL entrante-rifl: R(config-ext-nacl)#permit host IP-web eq 80 host IP-mio eq 1044

4.1.6 La configurazione delle ACL Dinamiche


P1 Le ACL dinamiche o lock and key, sono anchesse del 1996, e permettono il traffico dati IP attraverso il Router solo se il mittente si autentica per una sessione Telnet civetta sul Router stesso. Il traffico bloccato dallACL dinamica finch lautenticazione non ha avuto successo; poi la connessione Telnet viene chiusa e unACE temporanea permette il traffico inviato dal mittente. P2 Ripete in termini diversi quanto detto nella pagina precedente, aggiungendo solo che la Policy sulle risorse autorizzate per tutti gli utenti delle ACL dinamiche, e non per-user. P3 Per creare lACE dinamica che consente il traffico desiderato, usare il comando: 36

Il Succo di CCNA Security

Powered by: MP eForHum

R(config)#access-list 100-199 dynamic nome-ACL [timeout minuti] {permit | deny} protocollo IP-sorgente w.m. [operator Port [Port]] IP-destinaz w.m. [operator Port [Port]] [established] Il timeout eventuale della entry temporanea che viene creata di tipo assoluto, della durata massima da 1 a 9999 minuti. Lutente dovr poi autenticarsi per il Telnet, su richiesta del Router, con la line password (sconsigliato), o come utente di un DB AAA locale o basato su Server. P4 I comandi completi per istanziare unACL dinamica sono quindi (esempio): R(config)#username Studente password 0 cisco R(config)#access-list 101 permit tcp any host IP-Router eq telnet R(config)#access-list 101 dynamic apri timeout 15 permit ip IP-sorgente w.m. IP-destinaz w.m. ;le reti mittente e destin. R(config)#interface s0/1 ;per il traffico dati R(config-if)#ip access-group 101 in R(config)#line vty 0 4 ;per il Telnet civetta R(config-line)#login local ;autent. con DB AAA locale R(config-line)#autocommand access-enable [host] timeout 5 Il commando: autocommand abilita la funzione di lock and key della ACL, e sostituisce any con lIP dellhost mittente; indica inoltre il timeout di idle sulle VTY, dopo cui lACL chiusa. Interessante la keyword opzionale host: se presente, solo lHost autenticato (il suo IP) avr accesso alla rete di destinazione indicata nella ACL dinamica; in sua assenza, tutti gli IP della sua rete sorgente potranno accedere alla rete target, insieme al loro apripista.

4.1.7 La configurazione delle ACL Time-based


P1 Le ACL Time-based sono del 1998, e consentono il traffico e la registrazione dei LOG solo in determinati momenti. Queste ACL sono di tipo extended numeriche o con nome, con il comando e il parametro: time-range che indicano un periodo di tempo univoco o ricorrente. P2 Questi i comandi per configurarle: R(config)#time-range Nome-periodo R(config-time-range)#absolute start h-ini d-ini end h-fin d-fin o: R(config-time-range)#periodic gg-sett h-ini to [gg-sett] h-fin R(config-time-range)#exit R(config)#access-list 101 permit tcp IP-sorgente w.m. any eq Port [log | log-input] [established] time-range Nome-periodo R(config)#interface s0/1 R(config-if)#ip access-group 101 out NB: Il curriculum on-line dice che linizio e la fine del periodo absolute possono mancare, e che in tal caso linizio adesso e la fine il 31/12/2035. Nel caso periodic, invece, i giorni della settimana predefiniti sono: Monday, Tuesday, Wednsday, Thursday, Friday, Saturday, Sunday, daily (tutti 7 i giorni), weekdays (da luned a venerd) e weekend (sabato e domenica); per indicare pi giorni, premetterli tutti allora di inizio. Ricordarsi, se la ACL intende negare certo traffico, di aggiungere alla fine il permit per il resto! 37

Il Succo di CCNA Security

Powered by: MP eForHum

P3 Per permettere la navigazione web solo in certi orari, usare appositi time-range (on-line).

4.1.8 Il troubleshooting delle implementazioni di ACL complesse


P1 Per verificare il comportamento delle ACL, usare i comandi: R#show [ip] access-list [numero-ACL | nome-ACL] che mostra anche quanti match hanno fatto i singoli statement/entry/ACE della ACL indicata, e/o: R#debug ip packet [numero-ACL | nome-ACL] [detail]. P2 Questo un output di esempio del primo commando:

P3 Questo un output di esempio del secondo commando (attenzione al carico di CPU!):

4.1.9 La mitigazione degli attacchi tramite ACL


P1 Molti attacchi ricadono nelle categorie: falsificazione (spoofing) di indirizzi IP; DoS con TCP SYN (o SYN Flood); DoS di tipo smurf (=puffo!) che invia un ping-broadcast con spoofed source ad una grande rete, ottenendo di sommergere il target con londata delle echo reply; altri messaggi ICMP o traceroute. Spesso questi elementi vengono opportunamente combinati. Per difendersi da questi devastanti attacchi DoS, si possono bloccare tutti i Pacchetti inviati da ben noti gruppi di indirizzi IP, spesso usati per lo spoofing, e anche certi tipi di Pacchetti ICMP.

P2 Ad esempio, delle ACL dovrebbero sempre bloccare il traffico proveniente da IP privati (secondo la RFC 1918: 10.x.y.z, 172.16-32.x.y; 192.168.x.y) o altri casi speciali e permettere, in uscita da una LAN, sono gli IP sorgente della LAN stessa:

38

Il Succo di CCNA Security

Powered by: MP eForHum

P3 invece frequente che debbano essere consentiti in ingresso verso una rete i protocolli DNS, SMTP, FTP, e il traffico di gestione Telnet, SSH, Syslog e SNMP:

P4 Infine vanno opportunamente gestiti i messaggi ICMP entranti e uscenti dalle reti, per evitarne luso dannoso fatto dagli hackers: permettere in ingresso solo i tipi echo-reply, source-quench e unreachable, e in uscita echo-request, parameter-problem, packet-too-big e source-quench.

39

Il Succo di CCNA Security


4.2 Le tecnologie dei Firewall

Powered by: MP eForHum

4.2.1 Mettere in sicurezza le reti con i Firewall


P1 Il termine firewall indica un rigido filtro che separa distinti comparti. Il primo firewall per le reti stato prodotto nel 1988 da DEC-Digital Equipment Corporation ed era un software che filtrava i Pacchetti in base a certe regole, ma in modo stateless (...implicito?), ossia senza sapere se un Pacchetto fa o meno parte di una connessione o flusso gi esistente (come fanno le ACL):

Nel 1989 gli AT&T Bell Labs hanno realizzato il primo firewall stateful (...esplicito?) che filtra i Pacchetti anche in base alla loro appartenenza a flussi di dati autorizzati o meno, tramite regole temporanee create ad-hoc. Ci consente di mitigare attacchi DoS che sfruttano (exploit) connessioni gi attive negli apparati di rete, in modo MITM-Man In The Middle. Col tempo, alcuni hanno realizzato firewall di tipo standalone, per sgravare i Router dai filtraggi. P2 I firewall consentono di proteggere gli Host delle reti, di sanare (sanitize) eventuali debolezze dei protocolli, di bloccare traffico dannoso, di implementare policy di sicurezza semplici e robuste, e di concentrare i controlli in punti perimetrali ben definiti, semplificandoli nel resto della rete. Alcuni loro limiti sono per quelli di creare dei punti critici nella rete (single point of failure), di creare problemi a certe applicazioni, di stimolare negli utenti la ricerca (proactively search) di strade per by-passarli, di rallentare il traffico e di non scoprire contenuti dannosi se nascosti in tunnel o altri tipi di copertura.

4.2.2 Tipi di Firewall


P1 Un firewall un apparato complesso che pu operare a diversi livelli e con varie funzioni: un Packet-filtering Firewall un Router con delle ACL operanti a livello 3 e 4 uno Stateful Firewall un apparato che controlla anche le connessioni attive ai livelli 4 e 5 un Application Gateway Firewall, o Proxy Firewall, un apparato in grado di filtrare il traffico (con opportuni software) fino al livello 7 un Address-translation Firewall un apparato che espande il numero di IP disponibili (?) e nasconde lindirizzamento interno di una rete... cio fa pi o meno da NAT un Host-based Firewall un computer (PC o Server) con a bordo un software di filtraggio un Transparent Firewall un apparato che fisicamente si mette lungo il traffico e lo filtra tra due interfacce, risultando del tutto invisibile alla rete (non fa NAT, un bozzo sul filo!) un Hybrid Firewall una combinazione dei tipi precedenti: ad esempio, un Application Inspection Firewall ha funzioni di Stateful Firewall e di Application Gateway. P2 Le soluzioni Packet-filtering sono le pi semplici, in quanto bloccano staticamente il traffico in base agli IP (L3) e alle Porte (L4) sorgente e destinazione, al protocollo (ip/tcp/udp/icmp...) e allo stato di alcuni flag TCP (SYN, RST...) con la keyword: established. Bloccare in uscita la Porta 25 evita, ad esempio, di lasciar propagare via mail messaggi virati. P3 Gli Stateful Firewall tengono invece traccia, in una stateful session flow table, delle connessioni aperte, esaminando i flag TCP di SYN, RST, ACK e FIN. Quando si apre una connessione dallinterno della rete verso lesterno, viene messa in tabella una nuova entry, e i 40

Il Succo di CCNA Security

Powered by: MP eForHum

Pacchetti entranti vengono esaminati e permessi solo se sono risposte alle richieste uscenti (match con un connection object esistente). Analoghe entry vengono prodotte per connessioni autorizzate aperte dallesterno, onde consentire il traffico di risposta uscente.

Soluzioni pi avanzate consentono di inseguire la negoziazione dinamica delle Porte di certi protocolli come passive FTP, di verificare i numeri di sequenza dei Segmenti TCP, o di validare il traffico di query & response DNS per evitare attacchi di DNS cache poisoning (?). Purtroppo i Pacchetti in uscita possono rivelare allesterno informazioni sullo schema di indirizzamento interno, se non sono affiancati da soluzioni di NAT o da Proxy Server. P4 Le soluzioni Cisco per il firewalling sono 3: un Router con IOS Firewall, adatto per SMB-Small to Medium Business e ROBO-Remote Office Branch Office un firewall dedicato della serie PIX, ormai fuori produzione, con vari modelli e prestazioni un firewall ASA-Adaptive Security Appliance, che integra anche la Unified Communication ed il mattone fondamentale della Cisco Self-Defending Network, anchesso in vari modelli, con prezzi da 500 a 40.000 euro circa.

4.2.3 I Firewall nel progetto delle reti


P1 Le reti delimitate dai Firewall sono di solito due o tre. Il caso pi semplice quello di un Firewall che separa una LAN interna (trusted) da una rete esterna (untrusted, ad es. Internet). Il traffico dallinterno viene abilitato liberamente, mentre quello entrante bloccato, a meno che risulti essere la risposta a sessioni avviate dallinterno. In altri casi il Firewall ha una terza interfaccia, detta DMZ-DeMilitarized Zone, con livello di fiducia (trust) intermedio. Il traffico uscente dalla LAN e dalla DMZ sono consentiti, quello entrante verso la DMZ consentito solo verso i Server previsti: HTTP/HTTPS, mail, DNS, ecc. 41

Il Succo di CCNA Security

Powered by: MP eForHum

P2 Una buona architettura di sicurezza pu essere concepita a strati (layered defense), per difendere a diversi livelli i Client (endpoint security), la comunicazione in s, il perimetro (boundary) delle varie reti, la LAN interna (network core) e il sito distinto di Disaster Recovery. Un Pacchetto entrante pu dover attraversare prima un Router esterno che fa un filtraggio statico; poi pu passare da un Firewall o un bastion Host della DMZ, che applicano ulteriori controlli. Quindi viene instradato verso lHost destinazione attraverso il filtro di un ulteriore Router interno. Il mito (myth) che ci renda la rete sempre sicura per ingiustificato: occorre cautelarsi anche dagli attacchi interni e dai virus contenuti nelle mail, evitare gli accessi aperti da modem e AP installati dagli utenti (rogue) e dotarsi di ridondanze e di un sistema sicuro di Disaster Recovery. P3 LAmministratore di rete deve anche redigere e gestire una Firewall Security Policy (parte della Security Policy pi generale) che chieda di: bloccare tutto il traffico e i Servizi imprevisti, di controllare gli accessi, i LOG e i cambiamenti di configurazione dei Firewall, di gestire linterno... P4 Esempio di una architettura con due Router/Firewall con DMZ intermedia, che offrono anche ridondanza per gli accessi dallesterno alla DMZ stessa:

42

Il Succo di CCNA Security

Powered by: MP eForHum

4.3 Il CBAC Context-Based Access Control


4.3.1 Le caratteristiche del CBAC
P1 Il CBAC un tipo di filtraggio stateful operante ai livelli 3, 4 e 7, in grado di inseguire anche i protocolli e le Porte, anche multiple, negoziate dinamicamente dalle varie applicazioni, come FTP, H.323, RPC e SQLnet. Supporta lanalisi delle traduzioni NAT e PAT ed in grado di bloccare i programmi P2P come Gnutella e KaZaa, o lInstant Messaging di Yahoo!, AOL e MSN. Le sue funzioni principali sono quattro: filtraggio del traffico: pu analizzare i Pacchetti in ingresso e/o in uscita da ogni rete, secondo una Tabella delle sessioni gestita a livello applicativo, anche su Porte dinamiche, come detto ispezione del traffico: consente di rilevare ed evitare attacchi di SYN-flood (connessioni semiaperte o hembryonic) che sovraccaricano (overwhelm) i Server e i Firewall stessi, e altri attacchi DoS basati sullinvio di Segmenti TCP con numeri di sequenza errati Intrusion Detection: rileva alcuni tipi di attacchi fatti con SMTP, in base alle loro firme lasciate nei messaggi di syslog; li ferma, resettando le loro connessioni e generando un LOG generazione di allarmi e sequenze di verifica (audit trails): se rileva attivit sospette, CBAC genera opportuni allarmi e messaggi di syslog con: un timestamp, gli indirizzi IP e le Porte sorgente e destinazione, il numero di bytes scambiati in rete. P2 La prima versione di CBAC risale al 1997. Le migliorie rispetto alle ACL established e reflexive sono di seguito riassunte: controlla la creazione e la chiusura delle connessioni TCP, e la correttezza dei n. di sequenza ispeziona le query e le reply DNS, che usano UDP (chiuse se non si concludono in 5-30) ispeziona i 6 tipi pi comuni di messaggi ICMP (da IOS 12.2); risposte attese entro 10 max supporta applicazioni che usano canali multipli (di controllo e/o di dato) negoziando le Porte analizza il traffico in base agli indirizzi nascosti (embedded) perch tradotti dal NAT/PAT pu limitare i comandi disponibili a livello applicativo tra due Server (ad esempio SMTP). CBAC verifica solo i protocolli specificati in configurazione; gli altri per default sono bloccati.

4.3.2 Come opera il CBAC


P1 Le ACL che implementano il CBAC permettono solitamente il traffico in uscita dalla rete trusted a quella untrusted, e popolano la Tabella delle sessioni attive (Stateful flow table). Inseriscono inoltre, nelle ACL inverse che bloccano il traffico entrante, delle entry temporanee (temporary holes) che permettono solo il traffico di ritorno strettamente previsto e necessario, in base allo stato della Tabella. P2 Esempio di quanto sopra, nel caso di una sessione Telnet; precisa in pi soltanto che, per i messaggi successivi al primo di ogni sessione, la entry della Tabella viene solo aggiornata resettando il timer di idle, e non viene aggiunta alcuna entry dinamica nella ACL di ritorno, essendo questa gi stata creata. Siccome Telnet non negozia le Porte dinamicamente, il comportamento molto simile a quello di una ACL reflexive. P3 La gestione dei Segmenti TCP prevede di verificare innanzitutto che il tipo di traffico uscente sia permesso. Poi, nel Three way handshake, verifica che gli indirizzi IP, le Porte, i numeri di Sequenza e di Acknowledgement, e i flag di SYN e ACK, siano coerenti ed inviati entro certi tempi massimi. I messaggi seguenti della sessione devono infine avere il flag ACK attivo. 43

Il Succo di CCNA Security

Powered by: MP eForHum

Per gli scambi UDP, non essendoci numeri n di sessione n flag, il dialogo viene verificato solo, se consentito, tramite gli indirizzi IP e le Porte. Dopo un certo timeout, il dialogo viene chiuso. Anche altri protocolli possono essere gestiti come UDP in modo stateful a tempo, in base agli IP e alle Porte, mentre GRE e IPsec sono gestiti in modo stateless, Pacchetto per Pacchetto. Altre applicazioni dinamiche, come FTP, SQLnet e vari protocolli di streaming, possono essere ispezionate inseguendo (snooping) le Porte negoziate dai partner, e permettendone il dialogo solo se lintera applicazione consentita. P4 I comandi per configurare il CBAC sono i seguenti:

viene abilitato un certo protocollo (Telnet=23) in uscita dalla LAN, chiedendone lispezione secondo una certa regola che vedremo poi come configurare quando si apre la sessione, il Firewall inserisce, nella ACL blocca-tutto di ritorno, una ACE dinamica che consente il traffico di risposta tra i due IP e le due Porte ispezionate vengono anche verificati certi comandi specifici dellapplicazione, come gli SMTP illegali a seguito di violazioni delle regole di ispezione o delle soglie (threshold) di allarme DoS (massimo numero di sessioni TCP semi-aperte o embrionali, numero di tali sessioni in un certo intervallo e numero di tali sessioni per Host sorgente) il Firewall pu generare un allarme, proteggere le risorse di sistema attaccate, ad es. rifiutando per un certo tempo nuove connessioni, e/o bloccare i Pacchetti indesiderati in arrivo, resettando la connessione quando il traffico si conclude su comando o per time-out, le ACE dinamiche vengono rimosse.

4.3.3 La configurazione del CBAC


P1 Sono 4 passi: scegliere le interfacce, configurarvi le ACL, definire le regole di ispezione e applicare tali regole alle interfacce. P2 Per CBAC, si definisce interfaccia interna quella da cui il traffico da filtrare pu essere richiesto o iniziato: il traffico di quel tipo proveniente spontaneamente dallesterno sar bloccato. In uno scenario a tre interfacce con la DMZ, un certo tipo di traffico (DNS, Web...) pu essere consentito dallesterno verso la DMZ stessa. Infine, lo scenario pu prevedere che il traffico possa essere iniziato nelle due direzioni: in tal caso, configurare un doppio flusso indipendente, scambiando le interfacce interna ed esterna.

44

Il Succo di CCNA Security

Powered by: MP eForHum

P3 Le ACL devono consentire, in ingresso sullinterfaccia interna, tutto il traffico lecito, e possono essere standard o estese (N.B.: non serve metterla anche in out sullinterfaccia esterna, come fatto nella figura on-line!). In ingresso sullinterfaccia esterna, invece, necessaria una ACL estesa che vieta tutto il traffico spontaneo; in essa verranno dinamicamente inserire le ACE per consentire il traffico di risposta (N.B.: non serve metterla anche in out sullinterfaccia interna, come fatto nella figura on-line!). Aggiungere alle ACL i filtri antispoofing che vietano il traffico esterno con IP sorgenti appartenenti alla rete interna (lattaccante cerca di farsi passare come un utente interno), o da 255.255.255.255 (tipico di un attacco di broadcast). Esplicitare lo statement finale di deny pu essere utile per aggiungervi la keyword: log. P4 Le regole da definire sono una per ogni direzione del traffico da controllare (di solito... una) e indicano i protocolli applicativi da ispezionare, oltre a TCP, UDP e ICMP se richiesto. Una regola si configura con una serie di comandi globali: ip inspect name nome-regola, ciascuno dei quali indica il protocollo da ispezionare, e pu richiedere lattivazione di un allarme (alert) e/o la generazione di un LOG (audit-trail) e/o luso di un timeout di idle sul protocollo: . Es.: ip inspect name FWRULE smtp alert on audit-trail on timeout 300 ip inspect name FWRULE ftp alert on audit-trail on timeout 300 Al protocollo HTTP possono seguire altri parametri, come nellesempio seguente: ip inspect name PERMIT_JAVA http java-list 10 access-list 10 permit 10.2.2.0 0.0.0.255 che permette ai PC della subnet 10.2.2.0/24 di scaricare applet Java. P5 Esempio significativo e piuttosto completo di un filtraggio CBAC su un Router a tre vie:

45

Il Succo di CCNA Security


4.3.4 Il troubleshooting del CBAC

Powered by: MP eForHum

P1 Gli allarmi (Alerts) di CBAC sono abilitati per default sulla console, ma si possono disabilitare col comando: R(config)#ip inspect alert-off (riabilitarli con: no...) o, per la singola regola, con: R(config)#ip inspect name nome-regola alert-off. molto utile lasciare gli allarmi abilitati, per ottenere messaggi del tipo: %FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator (133.22.35.3:49776) indicante il tentativo di raggiungere un e-mail Server con un commando SMTP vietato, ad es.: per la presenza di un carattere pipe ( | ) nei campi From o To della mail per linvio di :decode@ nella testata della mail per luso di vecchi comandi Wiz o Debug sulla Porta SMTP per lesecuzione di codice arbitario grazie ad un bug del Client Majordomo. P2 Gli Audit-trails sono messaggi indicanti ogni tentativo, riuscito o meno, di accedere attraverso una connessione filtrata da CBAC. Sono disabilitati per default, e vengono abilitati con: R(config)#ip inspect audit-trail Ad esempio, una sessione Telnet iniziata dal Client 192.168.1.1 viene registrata come: %FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.1:32805) sent 22 bytes responder (133.22.35.3:23) sent 204 bytes Gli Audit-trails sono inviati per default sulla console, ma possono essere diretti anche verso un buffer interno del Router (con: R(config)#logging buffered, per essere esaminati poi con: R#show logging) e/o su un Syslog Server (con: R(config)#logging on e: R(config)#logging host 10.0.0.240). Ricordarsi anche (Tip) che per ricevere i messaggi di log sulla VTY di una sessione Telnet occorre dare: R#terminal monitor. P3 I comandi: show per esaminare il CBAC hanno la sintassi: R#show ip inspect {name nome-regola | config | interfaces tipo numero | sessions [detail] | all}. Esempi: name nome-regola: mostra le configurazioni assegnate ai vari protocolli da esaminare: Inspection name: FWRULE cuseeme alert is on audit-trail is on timeout 3600 ftp alert is on audit-trail is on timeout 3600
smtp max-data 20000000 alert is on audit-trail is on timeout 3600

sessions: mostra le sessioni uscenti ed entranti aperte, nella Stateful Flow Table. Esempio di una sessione FTP aperta dallIP interno 192.168.1.1 verso il Server FTP esterno 144.3.4.5: Established Sessions:
Session 25AB18C (192.168.1.1:32805)=>(144.3.4.5:21) ftp SIS_OPEN Session 3D44BA2 (144.3.4.5:20)=>(192.168.1.1:32806) ftp-data SIS_OPEN

Il Server ha aperto una connessione FTP dati di ritorno, e nellACL inbound 100 si possono vedere le due entry temporanee che consentono il passaggio del traffico FTP di ritorno: R#show ip access-list Extended IP access list 100
permit tcp host 144.3.4.5 eq 21 host 192.168.1.1 eq 32805 (4 matches) permit tcp host 144.3.4.5 eq 20 host 192.168.1.1 eq 32806 (9 matches)

46

Il Succo di CCNA Security

Powered by: MP eForHum

P4 I comandi: debug sul CBAC hanno la seguente sintassi: R#debug ip inspect {tcp | udp | icmp | application | events | object-creation | object-deletion | function-trace | timers [detailed]}. Da IOS 12.4(20)T il comando sostituito da: R#debug policy-firewall. Le application gestite sono (perch dirlo nel debug e non in testa al capitolo sul CBAC?!): cuseeme, dns, ftp-cmd, ftp-token, h323, http, netshow, rcmd, realaudio, rcp, rtsp, sip, skinny (VoIP proprietario Cisco), smtp, SQLnet, streamworks, tftp e vdolive. Ad esempio: R#debug ip inspect timers permette di vedere i timer TCP ed UDP eventualmente in corso o scaduti. N.B.: non sembrano adeguati, in proposito, gli esempi di debug nel testo on-line, del tipo:
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22) (10.0.0.1:46409) => (10.1.0.1:21)...

4.4 Lo ZPF Zone-based Policy Firewall


4.4.1 Le caratteristiche dello ZPF
P1 DallIOS 12.4(6)T del 2006, Cisco ha introdotto il firewall per zone e non per singole interfacce, detto anche ZBPF, ZBF o ZFW; include i filtraggi CBAC, quelli sullURL e anti-DoS. Per la configurazione si usa un apposito linguaggio, detto C3PL-Cisco Common Classification Policy Language, per definire la gerarchia delle zone e per raggruppare gli Host in ogni zona. P2 Il maggior vantaggio della ZPF rispetto al CBAC la semplicit duso. CBAC infatti non usa una struttura gerarchica della Policy, ma ogni interfaccia si relaziona ad unaltra in modo indipendente, e le relazioni tra interfacce multiple si fanno complesse. Inoltre gli Host di ogni interfaccia subiscono tutti la stessa Policy, e il tutto pesantemente basato sulle ACL. La Policy di default tra le zone, a differenza del CBAC, un deny all. Inoltre lo ZPF non usa le ACL, ma il C3PL che pi leggibile: una Policy regola completamente un certo tipo di traffico. CBAC e ZPF possono essere usati insieme sullo stesso Router, ma non sulla stessa interfaccia.

P3 I passi per configurare uno Zone-based Policy Firewall sono 4: suddividere logicamente la rete in zone a sicurezza diversa; ad es. esterno, interno e perimetro (cio la DMZ con i Server pubblici) decidere quale tipo di traffico consentito tra ogni coppia di zone logiche; ad es. TCP, UDP, ICMP, IPsec EPS-Encapsulating Security Payload, ecc.

47

Il Succo di CCNA Security

Powered by: MP eForHum

progettare linfrastruttura fisica, decidendo quanti apparati di sicurezza avere tra le varie zone e se questi sono collegati in serie, o in parallelo per offrire ridondanza in base alla struttura fisica, su ogni interfaccia dei firewall occorre aggregare le policy del traffico consentito di tutte le zone collegate a valle di tale interfaccia. Tipiche architetture ZPF sono: quella a due zone LAN-Internet, quella a tre zone con DMZ (in linea o su interfaccia dedicata), quella con Firewall ridondanti e quella complessa a pi zone.

4.4.2 Come opera lo ZPF


P1 Le azioni che lo ZPF consente sono: inspect: equivale al comando: ip inspect del CBAC, abilitando il traffico di ritorno dei protocolli permessi in uscita, inclusi eventuali messaggi ICMP + le sessioni dati FTP, H.323... drop: equivale allazione di deny delle ACL; pu essere associata ad un LOG pass: equivale allazione di permit delle ACL; abilita il traffico in una sola direzione. Il traffico consentito da inspect o pass pu avere una banda limitata tramite il comando: police. P2 Alcune regole governano lassegnazione delle interfacce alle varie zone di sicurezza: ogni interfaccia pu appartenere ad una sola zona il traffico libero tra interfacce della stessa zona il traffico pu invece transitare verso altre zone (non verso singole interfacce non assegnate a zone) solo se esiste una policy interzonale che lo ispeziona e/o permette le interfacce non assegnate alle zone possono usare un filtraggio CBAC a parte se uninterfaccia deve consentire tutto il traffico, va assegnata ad una zona legata con la policy dummy o pass-all verso le altre zone.

48

Il Succo di CCNA Security

Powered by: MP eForHum

Linterfaccia Linterfaccia Esiste un Esiste una Policy? Azione sorgente membro di destinazione abbinamento tra le una zona? membro di una zona? due zone? NO NO n/a n/a Non gestita da ZPF NO SI n/a n/a Drop SI NO n/a n/a Drop SI SI stessa zona n/a Pass SI SI NO n/a Drop SI SI SI * NO Drop SI SI SI SI Decide la Policy * Errore on-line: dice stessa zona (1), ma non ha senso, perch in tal caso il traffico sempre libero.

P3 Il traffico generato dal Router o a lui destinato fa eccezione rispetto alle regole precedenti. Tutte le interfacce del Router (i loro IP) fanno automaticamente parte della cosiddetta self zone, dalla quale o verso la quale il traffico consentito per default. Solo unesplicita policy interzonale che riguardi la self zone come sorgente o destinazione pu ispezionare o bloccare tale traffico.

4.4.3 La configurazione dello ZPF con CLI


P1 Occorrono 5 passi per configurare lo ZPF con CLI (da eseguire nellordine): creare le zone col comando: zone security definire le classi (o tipi) di traffico col comando: class-map type inspect definire le policy sulle classi col comando: policy-map type inspect abbinare le coppie di zone alle policy con: zone-pair security e: service-policy associare le interfacce alle zone col comando: zone-member security Per creare ununione tra pi zone, creare una nuova zona senza interfacce e definire le policy di tipo pass che la legano alle zone da unire. Uninterfaccia non pu fare parte di una zona ZPF ed essere anche gestita da CBAC; il CBAC pu per regolare il traffico tra interfacce non ZPF: tra i due mondi non pu per fluire alcun traffico, e assegnare uninterfaccia a una zona produce sempre una temporanea interruzione del traffico. P2 Le zone si definiscono in base ai criteri di sicurezza omogenei che si intendono applicare:

R(config)#zone security nome-zona-1 es. Inside R(config-sec-zone)#description Rete interna R(config-sec-zone)#zone security nome-zona-2 es. Outside R(config-sec-zone)#description Rete esterna Con Nmap si vede che, senza Host attivi, dallesterno visibile solo lIP nattato dellinterfaccia del Router (172.16.10.33) mentre, con Host attivi, escono anche i loro IP nattati (172.16.10.34). 49

Il Succo di CCNA Security

Powered by: MP eForHum

P3 La definizione delle classi (o tipi) di traffico si effettua con i comandi: R(config)#class-map [type inspect] [match-any | match-all] nome-classe Con match-any la classe soddisfatta da un qualunque criterio indicato; con match-all soddisfatta se lo sono tutti i criteri (da 4.4.4.3). R(config-cmap)#match {access-group num-ACL | access-group name nome-ACL | protocol protoc | class-map nome-classe} dove si vede che il traffico pu essere dato da unACL, essere un intero protocollo (vari, da L3 a L7), o richiamare una gerarchia di classi pi semplici, anche annidate (nested). P4 Le policy sulle classi si definiscono tramite i comandi: R(config)#policy-map [type inspect] nome-policy R(config-pmap)#class [type inspect] {nome-classe | class-default} dove la class-default la classe che raggruppa tutto il traffico non definito in altre classi; segue il comando che definisce cosa fare con la classe di traffico indicata, nella policy in questione, (cosa possibile solo se i comandi Policy-map e Class-map sono stati dati con type inspect): R(config-pmap-c)#{pass | drop | inspect [log] | police(?)} P5 Per abbinare le coppie di zone tra loro e alle policy si usano i comandi: R(config)#zone-pair security nome-pair source {nome-zona-s | self} destination {nome-zona-d | self} R(config-sec-zone-pair)#description da-qui(s)a-l(d) R(config-sec-zone-pair)#service-policy {type inspect nome-policy | protoc nome-policy} dove protoc pu essere: h323, http, im, imap, p2p, pop3, sip, smtp, sunrpc o urlfilter. Infine, le interfacce vanno associate alle zone coi comandi: R(config)#interface tipo numero R(config-if)#zone-member security nome-zona-x. Si vedano on-line gli alerts generati dalla keyword: inspect sul traffico in transito.

4.4.4 La configurazione manuale dello ZPF con SDM


P1 Con SDM-Security Device Manager, la configurazione della ZPF risulta semplificata. I passi sono solo 4, dato che le interfacce sono associate alle zone nel primo passo. Con IOS 12.4(9)T disponibile una nuova GUI, detta CCP-Cisco Configuration Professional, che aggiunge la funzione di configurazione di una community di apparati (ma non va ad es. per SIP nella self zone). P2 La definizione delle zone reperibile in SDM, nel Wizard degli Additional Tasks (vedi); con Add possibile aggiungere una zona, darle un nome e associarvi le interfacce fisiche o logiche. Le interfacce virtuali (Dialer, ecc.) a differenza delle precedenti possono appartenere a pi zone. Alla fine premere OK per creare la zona e OK per confermare il Command Delivery Status. Il nome di una zona non pu essere modificato, n la zona pu essere cancellata se in una pair.

50

Il Succo di CCNA Security

Powered by: MP eForHum

P3 La definizione di una class map avviene sempre dal Wizard Additional Tasks, ma sotto il C3PL. Analogamente al CLI, permette di dare un nome alla classe di traffico, di associare una eventuale descrizione e un certo tipo di Inspection, in cui possibile definire una ACL, un protocollo (vedi) o una class map subordinata. La classe pu essere modificata con Edit.

P4 Anche le policy map si creano col C3PL: come si vede in figura, equivalgono alla creazione con CLI: nome, descrizione, class map associata/e (anche pi di una, nellordine desiderato) ed azione tra: pass | drop (con eventuale log) | inspect (e... police? Non c! Il CLI pi accurato).

51

Il Succo di CCNA Security

Powered by: MP eForHum

P5 Infine, vanno definite le coppie di zone e la loro associazione ad una policy map, tramite la voce Zone Pairs degli Additional Tasks:

4.4.5 La configurazione dello ZPF con il Wizard SDM


P1 Un modo ancora pi semplice per configurare un firewall usare il Wizard Firewall and ACL di SMD, usando la modalit Basic, come in figura (ma, come si vede, esiste anche una Advanced). Il Wizard chiede se occorre una DMZ, e opera solo sulle interfacce non configurate con CBAC.

52

Il Succo di CCNA Security

Powered by: MP eForHum

P2 Il Wizard permette di associare le interfacce del Router alle reti Outside(untrusted) o Inside(trusted) e di scegliere se Allow Secure Cisco SDM Access From Outside Interfaces, cio se consentire laccesso di gestione via SDM da remoto al Router. In tal caso, dopo un altro Next> il Wizard chiede da quale IP si accetta tale accesso: scegliere un solo IP, una rete o ANY. P3 Le Policy predefinite scelte dal Wizard sono tre: sicurezza bassa, media e alta (vedi): ne vengono mostrate le descrizioni e, premendo il tasto Preview Commands, i comandi CLI corrispondenti. richiesto almeno lIP di un DNS per far funzionare lapplicazione.

P4 Alla fine, la finestra di Firewall Configuration Summary mostra le policy applicate (tra SDM_LOW, SDM_MEDIUM o SDM_HIGH) con tutti i singoli comandi configurati. Il tasto FINISH completa la configurazione, rendendola operativa.

4.4.6 Il troubleshooting dello ZPF


P1 Per rivedere il Firewall creato dal Wizard, sceglierne la scheda Edit Firewall Policy (vedi); da tale scheda, basata sulle interfacce (o sulle zone?) possibile modificare direttamente il Firewall. Nel caso di un Firewall a due interfacce, i controlli introdotti riguardano solo HTTP, SMTP e FTP. 53

Il Succo di CCNA Security

Powered by: MP eForHum

P2 La funzione Monitor (men principale) e Firewall Status mostra un grafico sul numero di Pacchetti scartati o inoltrati, a scelta in Real-time ogni 10, ogni 1 (per 1 h) o ogni 12 (per 12 h):

P3 Il comando: R#show policy-map type inspect zone-pair session mostra le statistiche relative alle connessioni attive nella ZPF State Table. Vedere il lungo esempio nel testo on-line.

54

Il Succo di CCNA Security Cap. 5

Powered by: MP eForHum

Gli IPS-Intrusion Prevention Systems

5.1 Le tecnologie IPS


5.1.1 Le caratteristiche degli IDS e degli IPS
P1 Gli attacchi zero-day threats sono quelli che sfruttano (exploit) il tempo tra la scoperta di una vulnerabilit e il rilascio della patch da parte del Vendor. Si propagano rapidamente e spesso non prevedibile da quale parte possano entrare in reti complesse con utenti remoti, VPN, ecc. P2 Il continuo controllo manuale dei LOG registrati dai sistemi antivirus ovviamente una soluzione poco praticabile, e comunque permetterebbe solo interventi tardivi. I primi sistemi IDS-Intrusion Detection System analizzavano fuori linea una copia del traffico in transito da e verso la rete, per non rallentare il traffico stesso; richiedevano per la collaborazione degli apparati di rete (Switch con porte mirror, Router e Firewall) per generare tale copia (promiscuous mode), e non erano in grado di bloccare attacchi sferrati da un singolo Pacchetto. Oggi esistono soluzioni che bloccano immediatamente gli attacchi. P3 Gli IPS-Intrusion Prevention System, a differenza degli IDS, operano in linea, e non fanno passare il traffico se prima non lhanno analizzato, con varie tecniche (ricerca firme, analisi dei profili e dei protocolli, ecc.) operanti ai livelli da 2 a 7: possono bloccare malware che passerebbe attraverso un normale Firewall e fermare anche attacchi contenuti in un singolo Pacchetto. Ovviamente, se mal configurati, possono rallentare tutto il traffico scambiato dalla rete.

P4 I sensori IDS e IPS possono essere implementati nellIOS di un Router, in una appliance o in un modulo o scheda da inserire in un apparato di rete. La tecnica di analisi pi usata quella delle firme (signatures) rilevate su singoli Pacchetti (atomic) o in traffico multipacket. 55

Il Succo di CCNA Security


Soluzione IDS promiscuous mode

Powered by: MP eForHum


Svantaggi Non blocca il traffico pericoloso Richiede una Policy e un tuning precisi pi vulnerabile a tecniche di evasion (??) Pu bloccare la rete se si guasta Pu rallentare la rete se troppo carico Pu introdurre latenza e jitter

P5 Vantaggi e svantaggi degli IDS e degli IPS sono sintetizzati nella seguente tabella:
Vantaggi Non genera latenza e jitter Non blocca la rete se si guasta Non rallenta la rete se troppo carico Pu bloccare i singoli Pacchetti di innesco (trigger) del malware Pu usare tecniche di stream normalization contro le evasions (??)

IPS inline mode

Talvolta si pu usare un IPS per rilevare pochi tipi di minacce critiche inline, ed installare un IDS che, offline, verifica pi a fondo tutto il traffico transitato e pu validare loperato dellIPS.

5.1.2 Le implementazioni IPS basate su Host


P1 IDS e IPS possono essere a livello Network (NIDS-NIPS) o sul singolo Host (HIDS-HIPS). Le soluzioni NIPS, implementate su Router ISR, su ASA o su moduli per Switch L3 Catalyst 6500 possono rilevare le firme o profili (pattern) di traffico anomali. Le soluzioni HIPS come CSA-Cisco Security Agent permettono, sul singolo PC, di verificare (audit) i file di LOG, quelli di sistema e varie altre risorse, tra cui file specifici di quellHost. Opera sulle firme e sullanalisi comportamentale (behavioural), e come anti-virus e firewall locale. P2 Il CSA ha due componenti: un Management Center da installare su un Server della LAN, e il Security Agent da installare sugli Host (Server e Client); mostra una red flag nel system tray. LAgent analizza in continuazione le risorse di sistema decise dallAmministratore, compreso il Registry, e invia report al Management Center su eventuali attivit sospette acted upon, in modo del tutto trasparente allutente dellHost. P3 CSA capace di bloccare gli attacchi in base alle risorse di sistema utilizzate, e non necessita di aggiornamenti tempestivi di firme, ecc. In caso di sospetto attacco, la red flag diviene lampeggiante e chiede lazione da svolgere: Ok (esegui), No (nega) o No, termina lapplicazione.

P4 Gli HIPS non sempre sono in grado di accertare (ascertain) se lattacco stato bloccato in tempo, hanno una visione del problema legato alla singola macchina e non alla rete, e devono essere installati su ogni Host, dovendo quindi essere compatibili coi vari S.O.

5.1.3 Le implementazioni IPS basate su apparati di rete


P1 Gli IPS possono essere implementati con apparati dedicati (IPS 4200 con O.S. 5.1, da pag. 2), o essere aggiunti come schede AIM-Advanced Integration Module o NME-Network Module Enhanced a Router ISR, essere inseriti negli ASA come schede AIP-SSM Advanced Inspection & Prevention Security Service Module (con 1, 2 o 4 GB di RAM), o infine essere inseriti negli Switch Catalyst 6500 come IDSM-2 Intrusion Detection Services Module, v.2. Il sistema operativo sottostante viene rinforzato (hardened) disabilitando i servizi non necessari, mentre lhardware fornisce le interfacce Ethernet/Fast/Giga, la potenza di CPU e la RAM richieste. P2 Gli IPS in piccoli uffici possono anche essere implementati a software, tramite lIOS IPS degli ISR 1841, 2800 e 3800. Lapparato deve avere abbastanza RAM per le firme da ispezionare. In figura, le caratteristiche delle 4 soluzioni hardware sopra indicate, alternative allIOS IPS. 56

Il Succo di CCNA Security

Powered by: MP eForHum

P3 Le prestazioni delle varie soluzioni variano dal minimo dellIOS IPS, alle schede AIM o NME per ISR, alle estensioni AIP-SSM degli ASA, fino ai moduli IDSM-2 degli Switch 6500 o agli IPS 4200, adatti a soluzioni enterprise o ai Provider. P4 I NIPS-Network IPS hanno il vantaggio di esaminare tutto il traffico in rete, e non devono essere supportati dai vari S.O. dei singoli Client. Possono per essere accecati (blind) dal traffico cifrato, hanno difficolt a ricostruire traffico frammentato, e possono creare problemi di banda. I NIPS, uniti agli HIPS-Host IPS, offrono migliore sicurezza contro gli attacchi.

5.2 Le firme (signatures) degli IPS


5.2.1 Le caratteristiche delle firme degli IPS
P1 Gli attacchi presentano spesso caratteristiche tipiche, dette firme del loro comportamento o dei messaggi che producono, simili a quelle contenute nei file virus.dat degli antivirus. Quando viene riconosciuta una firma, lIPS reagisce con una specifica azione, come quella di generare un LOG. Le firme hanno attributi come: il tipo, che cosa scatena lallarme (trigger), lazione da fare. P2 Le firme possono essere di due tipi: atomiche: risiedono in un singolo Pacchetto o evento, e non richiedono pertanto di mantenere uno stato del tentativo di attacco in corso, richiedendo quindi risorse (es. RAM) limitate. Un esempio il LAND, un attacco di spoofed TCP SYN con IP sorgente e destinazione uguali (p. 5.2.1.3), che riesce di solito a passare un IDS (off-line!), mentre viene bloccato dagli IPS composite: dette anche stateful signature, sono invece date da una sequenza di Pacchetti o di eventi, di cui occorre tenere traccia mentre si presentano, in un periodo massimo detto event horizon. Ogni firma ha il suo periodo tipico, e la taratura del massimo periodo in cui lIPS pu rilevare un attacco composito condiziona da un lato le risorse di cui esso ha bisogno e, per contro, la sua capacit di rilevare attacchi di lunga durata. P3 Le firme vengono tenute aggiornate scaricando ad intervalli regolari dei file di update; ad esempio, lattacco LAND individuato dalla firma Impossible IP Packet n. 1102.0.

P4 Per aumentare lefficienza della scansione, le firme vengono raggruppate per caratteristiche comuni, che rendono ogni gruppo analizzabile da un particolare SME-Signature Micro-Engine, un software di scansione che utilizza le espressioni regolari per analizzare varie firme alla volta, di tipo sia atomico sia composito, sulla base di determinati valori e protocolli contenuti nei Pacchetti. La versione 5.x degli SME, contenuta nellIOS 12.4(11)T e successivi, definisce 5 tipi di engine: 57

Il Succo di CCNA Security

Powered by: MP eForHum

atomic, service, string, multi-string e other/normalizer che riconoscono anche le firme cifrate e il loro livello di rischio (risk rating). Gi dallIOS 12.4(6)T per si usava la versione 4.x. Luso delle SME e la compilazione delle espressioni regolari richiedono alte quantit di RAM. P5 I file delle firme hanno formato del tipo: IOS-S361-CLI.pkg, e contengono tutte le firme della versione S360, pi gli aggiornamenti rilevati nel frattempo. Le firme meno prioritarie vengono aggiornate da Cisco ogni due settimane, mentre quelle pi urgenti sono pubblicate in poche ore. Per scaricare le firme dal sito Cisco.com serve un valido account CCO-Cisco Connection Online.

5.2.2 Gli allarmi riconosciuti dalle firme degli IPS


P1 Questi allarmi, detti anche signature trigger, sono come i sensori di movimento che rilevano uno scassinatore (burglar) in una casa; sono di 4 tipi base, con vantaggi e svantaggi: pattern-based: rileva una certa stringa, d pochi falsi positivi, ma devessere aggiornato spesso anomaly-based: rileva un comportamento sospetto, pu rilevare attacchi ignoti, ma generico policy-based: rileva un comportamento predeterminato, difficile da definire in grandi reti honey pot-based: mette in rete Server fasulli per attrarre lattacco e poterlo analizzare meglio. Si possono applicare ad attacchi atomici o compositi, ed integrare tra loro. Un altro meccanismo di allarme si basa sulla decodifica dei protocolli (protocol decodes) che analizza il traffico distinguendo i singoli campi di presunti protocolli pericolosi in transito. P2 I pattern-based trigger possono rilevare singoli campi (con firme atomiche, che non richiedono di mantenere uno stato del traffico sotto analisi) o certe stringhe (con firme composite). Il traffico sospetto quello indirizzato a determinate Porte, per cui non rileva attacchi di tipo Trojan Horse che si spostano su Porte qualsiasi. Tarare le firme per evitare i falsi positivi. P3 Gli anomaly-based trigger segnalano invece quando il traffico si discosta da un profilo normale che pu essere definito in base allosservazione della rete o dellHost per un certo tempo, o in base a una certa RFC (??). Il vantaggio che questi trigger scattano anche per attacchi sconosciuti, ma per contro possono indicare attacco anche per nuovi comportamenti leciti, perci richiedono che il traffico normale sia ogni tanto ridefinito. Inoltre leventuale osservazione deve avvenire durante un periodo... veramente normale. Infine, la segnalazione di anomalia non indica la causa dellattacco, che deve essere ulteriormente indagata. P4 I policy-based trigger sono simili a quelli pattern-based, ma non cercano specifiche firme, bens azioni vietate o pericolose svolte dalle applicazioni, come il lancio del cmd.exe da parte di un Client di posta, qualunque esso sia. Le azioni vietate sono rilevate in base ad unanalisi storica. Un esempio di trigger atomico quello di rilevare un Pacchetto frammentato in base solo allultimo frammento; un trigger composito invece quello di una richiesta RPC di un Host SUN Unix non preceduta da una richiesta al programma SUN PortMapper. Gli honey pot-based trigger, infine, sono basati su dummy Server che distraggono lattaccante dal fare danni ai Server veri, mentre ne analizzano la modalit di attacco; sono pi usati per ricerca. P5 LIOS IPS derivato dai sensori dedicati IPS 4200 e dalle schede IDSM per Catalyst 6500.

58

Il Succo di CCNA Security

Powered by: MP eForHum

Offre i seguenti benefici: usa anche le funzioni di routing per aumentare la sicurezza; si installa in linea, e pu quindi controllare tutto il traffico; pu collaborare con gli IDS, i Firewall, le VPN e il NAC-Network Admission Control per proteggere tutti gli accessi; supportato dai software di gestione SDM, Cisco Security Monitor / Manager e MARS; supporta, se dotato di sufficiente RAM, fino a 2000 firme di attacco tratte dallo stesso DB delle appliance IPS dedicate.

5.2.3 La taratura (tuning) di tali allarmi


P1 Un sistema di allarme non deve generare n falsi positivi (allarmi su traffico normale), n falsi negativi (non-allarmi su traffico pericoloso): in entrambi i casi occorre tarare il sistema per ottenere che i primi diventino veri negativi (nessun allarme) e i secondi, veri positivi (allarme). P2 Se non ci sono mai allarmi, possibile che la rete non intercetti tutto il traffico pericoloso, ma veloce; se ci sono troppi falsi positivi, invece, la rete pi lenta e si perde tempo ad esaminarli. La severit dellallarme (vedi figura) deve essere come quella del rischio del tipo di attacco rilevato; lamministratore deve basarsi, per la taratura delle anomalie, sul traffico normale in rete.

5.2.4 Le azioni associate alle firme degli IPS


P1 A parte il caso in cui il traffico sia permesso (vedi il perch alla fine di Pag. 5), ci sono 5 tipi di reazioni possibili agli attacchi rilevati: generazione di un allarme, con un alert compatto o verboso registrazione di un LOG dellattivit, con i Pacchetti dellattaccante, della vittima o dei due bloccare (drop) o prevenire lattivit, agendo sullattaccante, sulla connessione o sui Pacchetti resettare una connessione TCP, dirottandone (hijacking) e terminandone il flusso bloccare lattivit futura, agendo sulla connessione o sullIP dellattaccante, e generando eventualmente una trap SNMP. P2 Il primo tipo di azione pu generare alert atomici (singoli) o di summary (li conta in una certa finestra di tempo, ed meno esposto ad attacchi DoS che esauriscono le risorse dellHost). Vari sistemi IPS possono passare automaticamente dal primo al secondo modo, o per gli alert successivi al primo, o se il numero degli alert nel tempo supera una certa soglia. Altri disabilitano per un certo tempo anche il summary di un certo alert avvenuto, per evitare troppi allarmi. 59

Il Succo di CCNA Security

Powered by: MP eForHum

P3 Il secondo tipo di azione il LOG dellattivit sospetta rilevata, che viene registrato su un apposito supporto per unanalisi a posteriori (esempio di firma: la stringa /etc/password). Il LOG pu comprendere un certo numero di Pacchetti da e verso lIP attaccante. P4 Il terzo tipo di azione il drop dellattivit sospetta, ottenuto tramite leliminazione del singolo Pacchetto sospetto o della connessione TCP associata, o bannando lIP mittente per un certo periodo. Negli ultimi due casi, lIPS evita di verificare tutti i Pacchetti seguenti al primo. P5 Le azioni di tipo 4 e 5 sono il reset delle connessioni TCP e il blocco dellattivit futura. Lazione 4 si ottiene inviando al mittente un Segmento con il flag RST a 1, cosa che non avviene soltanto se si nega (deny) il passaggio al traffico generato dalla connessione. Lazione 5 si ottiene quando lIPS modifica unACL dinamica su uno o pi apparati perimetrali, per bloccare per un certo tempo il traffico di quel tipo inviato dal mittente. Infine, come detto, unazione possibile anche quella di permettere il traffico. Ci pu servire per usare una logica iniziale restrittiva che blocca tutto, e poi aprire selettivamente alcune finestre.

5.2.5 La gestione e il monitoraggio degli IPS


P1 Monitorare gli allarmi consente di valutare gli attacchi e la robustezza del sistema di difesa. Ci sono 4 fattori che compongono una strategia di sicurezza: il metodo di gestione, la correlazione degli eventi, il gruppo security staff e il piano di risposta agli incidenti: vediamoli meglio. P2 Il metodo di gestione dei sistemi di sicurezza pu essere distribuito (es. via SDM) per pochi sensori, o centralizzato per linstallazione (deployment) di numerosi apparati IPS. La correlazione degli eventi pu avvenire se i sensori hanno i LOG sincronizzati tramite Server NTP-Network Time Protocol, e raccolti su un unico archivio centrale (monitoring facility). Meglio se, oltre ai LOG di allarme, si correlano anche i messaggi Syslog e NetFlow (developed by Cisco Systems to run on Cisco equipments for collecting IP traffic information), come fa MARS. Il gruppo security staff deve essere adeguato alle dimensioni dellazienda, per poter analizzare gli eventi registrati e tarare gli IPS sulle sue specifiche necessit. Il piano di risposta agli incidenti, infine, deve prevedere il modo di ripristinare i sistemi compromessi, verificare se c stato furto di informazioni e quali sistemi sono stati coinvolti. P3 I sistemi GUI di gestione locale dei sensori IPS sono: SDM-Security Device Manager e IDM-IPS Device Manager ( un Server web gratuito, interno ai sensori e allIOS IPS). Quelli per la gestione centralizzata o remota sono: IEV-IPS Event Viewer (con funzioni di filtro e di Import/Export), CSM-Cisco Security Manager (molto potente e versatile, per sensori e IOS IPS) e MARS-Monitor, Analysis and Response System, il pi potente, che opera col CSM (ha un apposito esame!); vedi schermata:

60

Il Succo di CCNA Security

Powered by: MP eForHum

P4 Gli allarmi possono essere generati in formato LOG o SDEE-Secure Device Event Exchange, protocollo extensible specifico di sicurezza; esempio di allarme in formato SDEE: %IPS-4-SIGNATURE: Sig. 1107 Subsig: 0 Sev: 2, RFC1918 address [192.168.121.1:137 -> 192.168.121.255:137] P5 Le 7 best practice suggerite per una efficiente gestione degli allarmi sono: bilanciare laggiornamento delle firme con il downtime che esso richiede far aggiornare automaticamente le firme dei sensori IPS in grandi installazioni proteggere con un IPS il Server di gestione dove sono scaricati i nuovi pack di firme esso pu essere un Server FTP; in assenza di aggiornamenti, si possono creare firme ad hoc il direttorio dove viene conservato il signature pack deve essere accessibile in read only sfasare (stagger) i sensori IPS per la ricerca periodica di nuove firme sul Server FTP mantenere allineati i livelli delle firme supportate dalla console di gestione e quelli dei sensori.

5.3 Limplementazione degli IPS


5.3.1 La configurazione degli IPS Cisco IOS con CLI
P1 I 5 passi per attivare lIOS IPS 4.x dalla CLI dellIOS 12.3(8)T4, o il 5.x da 12.4(10) sono: scaricare i files IOS IPS; creare un direttorio di configurazione in flash; creare una IOS ISP crypto key; abilitare lIOS IPS su uninterfaccia; caricare un signature pack sul Router. P2 NellIOS fino alla versione 12.4(11)T esclusa limmagine conteneva delle firme IPS built-in o hard-coded, a cui si aggiungevano le firme contenute nel file XML detto SDF-Signature Definition File; dallIOS citato in poi, le firme sono contenute solo nel file SDF, in formato 5.x. Come primo passo per attivare lIPS comunque sempre richiesto il download delle firme e della relativa crypto key che ne garantisce lautenticit, tramite accesso con account registrato al sito CCO di Cisco. I file sono rispettivamente: IOS-Sxxx-CLI.pkg e realm-cisco-pub.key.txt. Occorre inoltre la creazione di una directory in flash (anche eventualmente su supporto USB o PCMCIA) per ospitare tali file, col comando: R#mkdir nome (es. R#mkdir ipsfolder). Con R#rename vecchio nuovo possibile cambiare il nome della directory; con R#dir flash: possibile esaminare che la directory esista ed abbia i corretti diritti di accesso in r/w:

P3 Il passo 3 della configurazione di IOS IPS lattivazione della crypto key scaricata. Trattandosi di una lunga stringa alfanumerica, il file .TXT gi contiene anche i comandi IOS per poter essere inviato direttamente da HyperTerminal al Router:

61

Il Succo di CCNA Security

Powered by: MP eForHum

Se la crypto key errata o assente, quando la compila, il Router emette una diagnostica tipo: %IPS-3-INVALID_DIGITAL_SIGNATURE: Invalid Digital Signature found (key not found) P4 Poi (passo 4), occorre abilitare lIOS IPS, in 4 sottopassi: istanziare una nuova IPS rule con un nome, e uneventuale ACL che determina quale traffico vada analizzato (in sua assenza, si analizza tutto il traffico); inoltre si deve fornire la posizione del direttorio in flash dove si trovano i file delle firme, con i comandi: R(config)#ip ips name previeni [list num/nome_acl] R(config)#ip ips config location flash:ipsfolder Nelle versioni di IOS previe alla 12.4(11)T, lultimo comando era: R(config)#ip ips sdf location flash:ipsfolder abilitare i servizi di gestione SDEE e LOG con i comandi: R(config)#ip http server R(config)#ip ips notify sdee R(config)#ip ips notify log (attivo per default) configurare la categoria delle firme, tra quelle pi comuni: all, basic e advanced, che determinano quante firme verranno installate sul Router, a seconda della sua RAM. Le varie firme possono essere abbandonate (retired) o in uso (unretired); per ridurre il numero delle firme in uso, si possono mettere retired quelle della categoria all, e poi unretired quelle di una categoria pi piccola, es. basic, con i comandi: R(config)#ip ips signature-category R(config-ips-category)#category all R(config-ips-category-action)#retired true R(config-ips-category-action)#exit R(config-ips-category)#category poche_firme basic R(config-ips-category-action)#retired false R(config-ips-category-action)#exit R(config-ips-category)#exit Do you want to accept these changes? [confirm] y R(config)# Se una firma compare in pi categorie, IOS IPS la considera retired o meno a seconda dellultima categoria richiamata in configurazione che la riguarda. applicare lIPS a uninterfaccia, in una certa direzione o entrambe, con il comando: R(config-if)#ip ips previeni {in | out} ripetere il comando per in+out 62

Il Succo di CCNA Security

Powered by: MP eForHum

P5 Infine, il passo 5 quello di caricare finalmente laggiornamento pi recente del signature pack sul Router da un Server FTP o TFTP, e di verificarlo con i comandi: R#copy ftp://ftp_user:password@Server-IP/IOS-Snnn-CLI.pkg idconf R#show ip ips signature count esempi:

5.3.2 La configurazione degli IPS Cisco IOS con SDM


P1 Per configurare lIPS pu essere usato, al posto del CLI, il Security Device Manager, da apposito Wizard (il settimo dallalto, a sinistra). necessario che il PC su cui si installa lSDM abbia almeno 256 MB di Java memory heap, assegnabili dal Pannello di controllo Java Scheda Java tasto Visualizza del Java Runtime Environment: digitare -Xmx256m e Ok:

Il Wizard IPS di SDM presente 4 schede che sono descritte nel seguito: Create IPS, Edit IPS, Security Dashboard (cruscotto) e IPS Migration (utile per portare sotto IOS 12.4(11)T firme create in versione 4.x, trasformandole in 5.x). Si crea una nuova regola IPS premendo il tasto Launch IPS Rule Wizard... (consigliato, al posto del metodo manuale Edit IPS) come da figura: 63

Il Succo di CCNA Security

Powered by: MP eForHum

P2 Entrati nel Wizard, leggere le istruzioni preliminari e premere Next. Il primo passo quello di scegliere le interfacce su cui operare con lIPS (NB nel CLI era lultimo): farlo, indicando la direzione del controllo, e premere Next.

P3 Occorre quindi indicare una o pi posizioni dove trovare il file delle firme (per aggiungere posizioni, es Server FTP / TFTP, premere il tasto ...), o se scaricarlo da Cisco.com (premere il tasto Download); le eventuali aggiunte o modifiche alle firme vanno in un delta file in Flash, che deve a sua volta essere firmato con una Chiave pubblica fornita anchessa da Cisco.com. P4 Per scaricare la chiave, accedere a: http://www.cisco.com/pcgi-bin/tablebuild/ios-5signup. Copiarne con un text editor il nome (es. realm-cisco.pub signature) e il valore esadecimale (vedi in figura) nei campi previsti in SDM, e premere Next. La seguente figura mostra la finestra che implementa i passi indicati in P3 e P4.

64

Il Succo di CCNA Security

Powered by: MP eForHum

P5 Occorre infine specificare la/e locazione/i per le firme e il delta, e scegliere la Categoria basic (adatta a Router fino a 128 MB di RAM) o advanced (per Router pi dotati). Premere il tasto Finish e confermare anche la schermata di Summary presentata dal Wizard. R#show run mostra i comandi in CLI, compreso un eventuale ip virtual-reassembly sulle interfacce.

65

Il Succo di CCNA Security


5.3.3 La modifica delle firme nellIOS IPS

Powered by: MP eForHum

P1 Le firme possono essere retired o unretired singolarmente o in gruppo, usando il CLI:

P2 Con CLI anche possibile cambiare lazione associata a una o pi firma, col comando: event-action (seconda schermata: signature-category e non -definition):

P3 Con SDM si possono modificare le firme, dalla scheda Edit IPS Signatures All Categories, e se ne pu modificare la severit.

66

Il Succo di CCNA Security

Powered by: MP eForHum

P4 Con un click destro su una firma, se ne pu modificare lazione associata, tra 5 non esclusive: Deny Attacker Inline: bloccalIP del mittente con unapposita ACL Deny Connection Inline: scarta i Pacchetti presenti e futuri di una certa connessione TCP Deny Packet Inlina: blocca il singolo Pacchetto Produce Alert: genera un messaggio di allarme Reset TCP Connection: invia un Segmento di reset per terminare il flusso TCP.

P5 Selezionando una firma e premendo il tasto Edit si possono modificare vari altri parametri della stessa; il testo ne spiega 10: Signature ID, SubSignature ID, Alert Severity, Sig Fidelity Rating (fiducia che i suoi allarmi siano Veri Positivi), Promiscuous Delta, Sig Description, Engine, Event Counter, Alert Frequency e Status (ritired o unretired).

5.4 La verifica e il monitoraggio degli IPS


5.4.1 La verifica degli IPS Cisco IOS
P1 5 varianti del comando: R#show ip ips xxx permettono di verificare il funzionamento dellIPS: xxx = [all | configuration | interfaces | signatures | statistics]: vedi schermate on-line. 2 comandi: R#clear ip ips [configuration | statistics] resettano lIPS. P2 Con SDM, dai tasti Edit IPS IPS Policies si vedono le interfacce su cui applicato lIPS, in direzione in o out, e se su di esse attiva la funzione di VFR-Virtual Fragment Reassembly, come si vede nella seguente figura. Vari altri tasti consentono di configurare e gestire i messaggi di sicurezza e le firme.

67

Il Succo di CCNA Security

Powered by: MP eForHum

5.4.2 Il monitoraggio degli IPS Cisco IOS


P1 I comandi per abilitare la registrazione eventi nelle due forme possibili sono: R(config)#logging Log_server_IPaddress indica a quale Server inviarlo R(config)#ip ips notify {log | sdee} dice in che forma lo si vuole R(config)#logging on abilita globalmente il logging P2 Si dettaglia in caso SDEE, basato su HTTP(S) e XML; usa il meccanismo di pull con cui unapplicazione di Network Management richiede i LOG archiviati, e il Router IPS risponde.

Il buffer SDEE archivia per default 200 eventi; se viene ridotto, gli eventi sono tutti persi, se viene ampliato (fino a 1000 eventi massimi) gli eventi sono conservati. Con: R#clear ip ips sdee {events | subscriptions} si cancella quanto richiesto. Il comando: R#ip ips notify ha sostituito il vecchio comando: R#ip audit notify, che per ancora riconosciuto e gestito. P3 Le applicazioni per raccogliere e mostrare gli eventi SYSLOG o SDEE sono gi state citate: MARS, IEV, CSM o SDM. Da SDM, gli eventi SDEE si vedono da: Monitor Logging SDEE Message Log, mentre quelli Syslog da: Monitor Logging Syslog. Esempi:

68

Il Succo di CCNA Security Cap. 6

Powered by: MP eForHum

Mettere in sicurezza la LAN

6.1 La sicurezza dei terminali (endpoint)


6.1.1 Introduzione alla sicurezza dei terminali
P1 xx P2 P3 P4 P5

6.1.2 La sicurezza dei terminali con IronPort


P1 P2 P3

6.1.3 La sicurezza dei terminali con il NAC-Network Admission Control


P1 P2 P3 P4 P5

6.1.4 La sicurezza dei terminali con il CSA-Cisco Security Agent


P1 P2 P3 P4 P5

69

Il Succo di CCNA Security

Powered by: MP eForHum

6.2 Considerazioni sulla sicurezza a Livello 2


6.2.1 Introduzione alla sicurezza a Livello 2
P1 P2

6.2.2 Gli attacchi di falsificazione dei MAC (MAC Address Spoofing)


P1 P2

6.2.3 Gli attacchi di overflow della MAC Address Table


P1 P2

6.2.4 Gli attacchi di manipolazione dellSTP


P1 P2

6.2.5 Gli attacchi di tempesta nella LAN (LAN Storm)


P1 P2

6.2.6 Gli attacchi alle VLAN


P1 P2 P3

6.3 La configurazione della sicurezza a Livello 2


6.3.1 La configurazione della Port security
P1 P2 P3 P4 P5

6.3.2 La verifica della Port security


P1 P2 P3

70

Il Succo di CCNA Security


P1 P2 P3 P4 P5

Powered by: MP eForHum

6.3.3 La configurazione della BPDU Guard e della Root Guard

6.3.4 La configurazione del controllo sulle tempeste (Storm Control)


P1 P2 P3

6.3.5 La configurazione della sicurezza sui VLAN trunk


P1 P2

6.3.6 La configurazione dellanalizzatore delle Cisco Switched Port


P1 P2 P3

6.3.7 La configurazione dellanalizzatore delle Cisco Remote Switched Port


P1 P2 P3

6.3.8 Le buone prassi (Recommended Practices) per il Livello 2


P1 P2

6.4 La sicurezza nel wireless, nel VoIP e nelle SAN


6.4.1 Considerazioni sulle tecnologie avanzate di sicurezza aziendale
P1 P2 P3 P4

6.4.2 Considerazioni sulla sicurezza wireless


P1 P2 71

Il Succo di CCNA Security


P3

Powered by: MP eForHum

6.4.3 Le soluzioni per la sicurezza wireless


P1 P2

6.4.4 Considerazioni per la sicurezza VoIP


P1 P2 P3 P4 P5

6.4.5 Le soluzioni per la sicurezza VoIP


P1 P2 P3 P4

6.4.6 Considerazioni per la sicurezza delle SAN-Storage Area Networks


P1 P2 P3 P4 P5

6.4.7 Le soluzioni per la sicurezza delle SAN


P1 P2 P3 P4 P5

72

Il Succo di CCNA Security Cap. 7 Sistemi di crittografia

Powered by: MP eForHum

7.1 I servizi di crittografia


7.1.1 Mettere in sicurezza le comunicazioni
P1 P2 P3 P4

7.1.2 La crittografia (o cifratura)


P1 P2 P3 P4

7.1.3 La crittoanalisi
P1 P2 P3 P4

7.1.4 La crittologia
P1 P2 P3

7.2 Lintegrit e lautenticit di base (dei messaggi)


7.2.1 Le polpette (hash) crittografiche
P1 73

Il Succo di CCNA Security


P2 P3

Powered by: MP eForHum

7.2.2 Lintegrit con MD5 e SHA-1


P1 P2 P3

7.2.3 Lautenticit con HMAC


P1 P2 P3

7.2.4 La gestione delle chiavi (key) crittografiche


P1 P2 P3 P4

7.3 La confidenzialit dei messaggi


7.3.1 La crittazione o cifratura
P1 P2 P3 P4 P5

7.3.2 Il DES-Data Encryption Standard


P1 P2 P3

7.3.3 Il 3DES-Triple DES


P1 P2

7.3.4 LAES-Advanced Encryption Standard


P1 P2

74

Il Succo di CCNA Security


7.3.5 Gli algoritmi di cifratura alternativi
P1 P2

Powered by: MP eForHum

7.3.6 Lo sbambio chiavi con Diffie-Hellman


P1 P2

7.4 La crittografia a chiave pubblica


7.4.1 Confronto tra cifratura simmetrica e asimmetrica
P1 P2 P3 P4

7.4.2 La firma digitale (digital signature)


P1 P2 P3 P4 P5

7.4.3 Rivest, Shamir e Adleman


P1 P2

7.4.4 La PKI-Public Key Infrastructure


P1 P2 P3 P4

7.4.5 Gli standard PKI


P1 P2 P3 P4

7.4.6 Le CA-Certificate Authorities


P1 75

Il Succo di CCNA Security


P2 P3

Powered by: MP eForHum

7.4.7 I Certificati digitali e la CA


P1 P2 P3 P4

76

Il Succo di CCNA Security Cap. 8

Powered by: MP eForHum

VPN-Virtual Private Networks

8.1 Le VPN-Virtual Private Networks


8.1.1 Una panoramica sulle VPN
P1 P2

8.1.2 Le topologie delle VPN


P1 P2 P3 P4 P5

8.1.3 Le soluzioni (Cisco) per le VPN


P1 P2 P3 P4 P5

8.2 Le VPN di tipo GRE-Generic Route Encapsulation


8.2.1 La configurazione di un Tunnel GRE site-to-site
P1 P2 P3 P4

77

Il Succo di CCNA Security

Powered by: MP eForHum

8.3 Le componenti e il funzionamento delle VPN di tipo IPsec


8.3.1 Introduzione a IPsec
P1 P2 P3 P4 P5

8.3.2 I protocolli di sicurezza di IPsec


P1 P2 P3 P4 P5

8.3.3 LIKE-Internet Key Exchamge


P1 P2 P3 P4 P5

8.4 Limplementazione di una VPN IPsec site-to-site con CLI


8.4.1 La configurazione di una VPN IPsec site-to-site
P1 P2

8.4.2 Task 1 La configurazione delle ACL compatibili (sui due lati)


P1 P2

8.4.3 Task 2 La configurazione dellIKE


P1 P2 P3

8.4.4 Task 3 La configurazione dei Transform Set


P1 P2 78

Il Succo di CCNA Security


P1 P2 P3

Powered by: MP eForHum

8.4.5 Task 4 La configurazione delle Crypto ACL

8.4.6 Task 5 Lapplicazione della Crypto Map


P1 P2 P3

8.4.7 La verifica e il troubleshooting della configurazione IPsec


P1 P2 P3 P4

8.5 Limplementazione di una VPN IPsec site-to-site con SDM


8.5.1 La configurazione di IPsec con SDM
P1 P2 P3 P4

8.5.2 Il VPN Wizard Setup veloce


P1 P2

8.5.3 Il VPN Wizard Setup step-by-step


P1 P2 P3 P4 P5

8.5.4 La verifica, il monitoraggio e il troubleshooting delle VPN


P1 P2

79

Il Succo di CCNA Security

Powered by: MP eForHum

8.6 Limplementazione delle VPN per accesso remoto


8.6.1 Il profilo delle aziende cambia
P1 P2 P3

8.6.2 Introduzione alle VPN per accesso remoto


P1 P2

8.6.3 Le VPN di tipo SSL-Secure Socket Layer


P1 P2 P3 P4 P5

8.6.4 La soluzione Cisco Easy VPN


P1 P2 P3

8.6.5 La configurazione di un Server VPN con SDM


P1 P2 P3 P4 P5

8.6.6 La connessione verso un Client VPN


P1 P2

80

Il Succo di CCNA Security Cap. 9 Gestire una rete sicura

Powered by: MP eForHum

9.1 I principi del progetto di reti sicure


9.1.1 Come assicurarsi che una rete sia sicura
P1 P2

9.1.2 Lidentificazione delle minacce (threats) e lanalisi dei rischi


P1 P2 P3 P4 P5

9.1.3 La gestione del rischio e le tecniche per evitarlo


P1 P2 P3

9.2 La rete Cisco che si difende da sola (Self-Defending Network)


9.2.1 Introduzione alla Cisco SDN-Self-Defending Network
P1 P2 P3 P4

9.2.2 Le soluzioni per la Cisco SDN


P1 P2 81

Il Succo di CCNA Security


P3 P4 P5

Powered by: MP eForHum

9.2.3 Il portfolio Cisco per la sicurezza integrata


P1 P2

9.3 La sicurezza del funzionamento (Operations)


9.3.1 Introduzione alla Operations Security
P1 P2

9.3.2 I principi della Operations Security


P1 P2 P3 P4

9.4 Il test della sicurezza di rete


9.4.1 Introduzione al test della sicurezza di rete
P1 P2 P3

9.4.2 Gli strumenti per il test della sicurezza di rete


P1 P2 P3 P4

9.5 Il piano per la Business Continuity e il Disaster Recovery


9.5.1 Il piano per la continuit
P1 P2

9.5.2 Incidenti (disruptions) e backup


P1 P2 82

Il Succo di CCNA Security

Powered by: MP eForHum

9.6 Il ciclo di vita dello sviluppo dei sistemi (SDLC)


9.6.1 Introduzione allSDLC-System Development Life Cycle
P1 P2

9.6.2 Le fasi dellSDLC


P1 P2 P3 P4 P5

9.7 Lo sviluppo di una Security Policy completa (comprehensive)


9.7.1 Una panoramica sulla Politica di Sicurezza
P1 P2 P3

9.7.2 La struttura di una Politica di Sicurezza


P1 P2 P3 P4

9.7.3 Gli Standard, le Linee Guida e le Procedure


P1 P2 P3 P4

9.7.4 I ruoli e le responsabilit


P1 P2

9.7.5 La consapevolezza (awareness) della sicurezza e il training


P1 P2 P3 P4 83

Il Succo di CCNA Security


9.7.6 Le Leggi e lEtica
P1 P2

Powered by: MP eForHum

9.7.7 La risposta a una breccia (breach) nella sicurezza


P1 P2

84