|
Made in |
DESCRIPTION | Pix: la famiglia di firewall Cisco | Live Discussion - Skill: 2- JUNIOR |
Cisco, il maggiore produttore al mondo di router, da anni produce delle network appliance dedicate alla sicurezza: la famiglia di firewall Pix. Tutti i modelli più recenti appartengono alla serie 500, dal più piccolo, il 501, dedicato a piccole reti o telelavoratori, al 535, per grandi e affollati network. Sui Pix, che hanno varie parti hardware comuni a normali computer (processore Intel, schede di rete fast ethernet o gigabit ecc), gira un sistema operativo dedicato, giunto al momento alla versione 6.3, ma con ancora largo utilizzo delle versioni 5.x e 6.x. |
||||||
Le feature offerte dai Pix variano a seconda del modello e della versione del sistema operativo installata, in genere quanto segue si applica almeno a Pix 505 o superiori con OS versione 6.x - Stateful inspection firewall, con logica basata su access-list a catena e moduli per gestire protocolli quali Ftp, RTSP, H.323, SIP - Gestione NATttin PATting (il masquerading del mondo Linux) - Gestione tramite command line o via web tramite Pix Device Manager (integrato) e software di gestione come Cisco Works - Supporto di VPN IpSec, PPTP, L2TP. Supporto di IKE, NAT/PAT traversing e autenticazione IpSec con shared-keys e certificati x509, criptazione DES, 3DES, AES (256 bit) - Supporto VLAN, SNMP, e OSPF (sebbene sia improprio usare un Pix come un router) - DHCP, telnet, NTP client e server - Meccanismi di intrusion detection con logging remoto - Authentication, Authorization, Accounting (AAA) con supporto TACACS+ e RADIUS Le caratteristiche e i costi dei Pix variano parecchio. Si riportano i dati ufficiali Cisco sulle performance (considerare che in condizioni reali il throughput effettivo è quasi sempre inferiore a quello indicato come Cleartext throughput, su questo influiscono il numero di access-list, VPN, translazioni di NAT ecc.) e sulla architettura dei sistemi (sostanzialmente basati su architettura Intel I386, con slot PC a 33 e 66 Mhz, memoria SDRAM e cache di secondo livello). PIX 501 - Appliance con HUB di 4 porte RJ45 per piccoli uffici o telelavoratori. Ha due porte fast-ethernet (outside e inside) per una rete pubblica ed una LAN privata. Cleartext throughput: 60 Mbps Concurrent connections: 7500 56-bit DES IPsec VPN throughput: 6 Mbps 168-bit 3DES IPsec VPN throughput: 3 Mbps 128-bit AES IPsec VPN throughput: 4.5 Mbps Simultaneous VPN peers: 10 (numero massimo di SA supportate) Processor: 133-MHz AMD SC520 Processor Random access memory: 16 MB of SDRAM Flash memory: 8 MB System bus: Single 32-bit, 33-MHz PCI PIX 506E - Maggiore throughput, senza HUB. Per piccoli uffici. Ha due porte fast-ethernet (outside e inside) per una rete pubblica ed una LAN privata. Cleartext throughput: 100 Mbps Concurrent connections: 25,000 56-bit DES IPsec VPN throughput: 20 Mbps 168-bit 3DES IPsec VPN throughput: 17 Mbps 128-bit AES IPsec VPN throughput: 30 Mbps Simultaneous VPN peers: 25 Processor: 300-MHz Intel Celeron Processor Random access memory: 32 MB of SDRAM Flash memory: 8 MB Cache: 128 KB level 2 at 300 MHz System bus: Single 32-bit, 33-MHz PCI PIX 515E - Occupa 1 Rack Unit, ha uno slot PCI per un modulo (scheda) espandibile e supporta il failover. Ha 2 interfacce fast-ethernet che possono arrivare a 6 tramite moduli aggiuntivi. Cleartext throughput: 188 Mbps Concurrent connections: 130,000 168-bit 3DES IPsec VPN throughput: Up to 140 Mbps with VAC+ or 63 Mbps with VAC 128-bit AES IPsec VPN throughput: Up to 135 Mbps with VAC+ 256-bit AES IPsec VPN throughput: Up to 140 Mbps with VAC+ Simultaneous VPN tunnels: 2000 Processor: 433-MHz Intel Celeron Processor Random access memory: 32 MB or 64 MB of SDRAM Flash memory: 16 MB Cache: 128 KB level 2 at 433 MHz System bus: Single 32-bit, 33-MHz PCI PIX 525 - Occupa 2 Rack Unit, ha 3 slot PCI espandibili e supporta il failover. Ha 2 interfacce fast-ethernet che possono arrivare a 10, oppure avere 3 gigabit ethernet, tramite schede aggiuntive. Cleartext throughput: 330 Mbps Concurrent connections: 280,000 168-bit 3DES IPsec VPN throughput: Up to 155 Mbps with VAC+ or 72 Mbps with VAC 128-bit AES IPsec VPN throughput: Up to 165 Mbps with VAC+ 256-bit AES IPsec VPN throughput: Up to 170 Mbps with VAC+ Simultaneous VPN tunnels: 2000 Processor: 600-MHz Intel Pentium III Processor Random access memory: 128 MB or 256 MB of SDRAM Flash memory: 16 MB Cache: 256 KB level 2 at 600 MHz System bus: Single 32-bit, 33-MHz PCI PIX 535 - Occupa 3 Rack Unit, ha 4+5 slot PCI espandibili e supporta il failover. Ha 2 interfacce fast-ethernet a cui si possono aggiungere quelle (fast-ethernet e gigabit ethernet) dei moduli PCI aggiuntivi. Cleartext throughput: 1.7 Gbps Concurrent connections: 500,000 168-bit 3DES IPsec VPN throughput: Up to 440 Mbps with VAC+ or 100 Mbps with VAC 128-bit AES IPsec VPN throughput: Up to 535 Mbps with VAC+ 256-bit AES IPsec VPN throughput: Up to 440 Mbps with VAC+ Simultaneous VPN tunnels: 2000 Processor: 1-GHz Intel Pentium III Processor Random access memory: 512 MB or 1 GB of SDRAM Flash memory: 16 MB Cache: 256 KB level 2 at 1-GHz System buses: Two 64-bit, 66 MHz PCI, one 32-bit, 33-MHz PCI I moduli aggiuntivi sono sostanzialmente schede PCI, per Pix 515 e superiori con le seguenti feature: - Scheda fast-ethernet con 1 porta RJ45 (fuori produzione?); - Scheda fast-ethernet con 4 porte RJ45; - Scheda gigabit-ethernet con 1 porta in fibra SX multimodale; - VPN Accellerator Card (VAC) per accellerazione hardware di DES e 3DES per tunnel IPSec; - VPN Accellerator Card + (VAC+) con maggiore potenza e supporto DES, 3DES, AES. Dalla versione 6 del Pix Firewall Operating System (PixOs, per comodità) è incluso Cisco Device Manager (PDM), uno strumento per configurare e gestire il PIX con relativa semplicità. E' sostanzialmente una applet Java, che viene eseguita sul browser ma visualizzata e scaricata via https direttamente dal Pix. Interviene sulle stesse configurazioni che si possono gestire "a mano" via CLI. Le versioni attualmente supportate sono la 2.0 (presente nel PixOS 6.2) e la 3.0 (PixOS 6.3). La 1.0 è presente in PixOS 6.0, 6.1. Con le nuove versioni la sintassi dei comandi del PixOS tende sempre più ad essere simile a quella del normale IOS dei router Cisco (anche se rimangono due sistemi totalmente diversi). La versioni 5.x (da 5.0 a 5.3) e in misura minore 4.x (da 4.0 a 4.5) sono ancora utilizzate, hanno tendenzialmente meno features delle versioni recenti, possono non supportare i nuovi hardware e avere bug, poi corretti, di varia natura. Nuove versioni del PixOs vengono rilasciate in numero relativamente limitato, non esiste l'intricata ragnatela di versioni diverso come per lo IOS e una ogni versione resa pubblica va considerata una "General Deployment" (pronta per ambienti di produzione). Le più recente prevedono meccanismi di autoaggiornamento. Il costo del PixOS è incluso nel prezzo dell'hardware, ma alcune funzionalità richiedono l'acquisto di licenze software aggiuntive (attivabili con adeguate activation keys che di fatto agiscono su una immagine del PixOs comune). Alla versione base, restricted (R), con supporto DES di un limitato numero di utenti contemporanei, si aggiungono versioni unrestricted (UR) senza limiti software sul numero massimo di connessioni, failover (FO), con supporto del failover automatico (è necessaria una coppia di Pix uguali). Per il supporto di 3DES e AES è inoltre richesta una licenza aggiuntiva, a parte. Cisco offre anche i Firewall Services Modules che implementano, come moduli aggiuntivi le funzionalità di firewalling del PixOs su switch Catalyst 6500 e router Cisco 7600. A parte i Pix più antichi, le versioni recentemente dismesse, ma che è ancora comune trovare in produzioni, sono: Pix 520 (sostituito dal 525, smesso di essere venduto dal 23 Giugno 2001, è stato l'ultimo ad avere il tradizionale ed inconfondibile floppy disk); Pix 515 (sostituito dal 515E, End Of Sale (EOS): 24 Maggio 2002); Pix 506 (sostituito dal 506E, End Of Sale (EOS): 24 Maggio 2002).
|
DESCRIPTION | Cisco Pix: Comandi base | Live Discussion - Skill: 2- JUNIOR |
Le attività di configurazione e gestione di un Cisco Pix hanno una logica simile a quella dello IOS sui router e gli stessi comandi tendono, con le nuove release, a assomigliarsi. In particolare con la release 6.x, sono stati introdotti comandi comuni allo IOS ma è stata mantenuta la compatibilità con i vecchi equivalenti. |
||||||
Come in qualsiasi OS multiutente, esistono utenti normali e privilegiati (enabled). Si diventa i root di un Pix con: Pix> enable Pix# Il prompt cambia da > a # Da qui si entra in modalità configurazione con: configure terminal Si salva la configurazione in memoria residente (NVRAM, FLASH..) con: write memory Si visualizza la configurazione corrente: write terminal oppure show running-config Si visualizzano i messaggi di log (da attivare in configurazione, possono restare in un buffer locale (che occupa memoria) o loggati su un syslog server remoto) con: show logging Si può usare il ? o help per avere gli elenchi dei comandi e delle opzioni di un comando disponibili. Si esce dalla modalità di configurazione con exit o quit .I comandi possono essere abbreviati (es: conf term ).Se si devono impostare grosse modifiche alla configurazione, è preferibile fare un paste completo di un testo precedentemente scritto (con la sintassi verificata). Le impostazioni date in configurazione sono immediatamente attive, ma fino a quando non si salva la configurazione con un write mem vengono perse al reboot.Dopo aver configurato comandi che modificano lo stato dell'engine del Pix come alias, access-list, conduit, global, nat, outbound, static è necessario dare il comando (in enable mode, non in configurazione): clear xlate Notare che questo resetta tutte le translazioni (NAT e PAT) correntemente gestite dal Pix e può interrompere connessioni che il Pix sta gestendo. Come tutti i comandi clear può avere dei risultati radicali, per cui va usato con attenzione. Comandi di diagnostica show cpusage Informazioni minime sul CPU time utilizzato |
DESCRIPTION | Cisco Pix: Configurazione di base | Live Discussion - Skill: 3- INTERMEDIATE |
Una configurazione di base di un PIX comprende la definizione delle interfacce, delle regole minime e delle impostazioni di default. | ||||||
Per definire gli indirizzi delle interfacce si usa un comando tipo:ip address interfaccia indirizzoIP maschera .I nomi delle interfacce sono di default outside, inf1, inf2 ... inside e hanno associato un livello di sicurezza da 0 (interfaccia esterna) a 100 (l'interfaccia inside). I nomi e i livelli di sicurezza delle interfacce si definiscono con nameif, i parametri di rete con ip address. Si impostano route statiche con route: route interfaccia destinazione maschera gateway Il default gateway si può impostare con: route outside 0 0 IP_Gateway 1 (Si può usare 0 per abbreviare 0.0.0.0)La logica del Pix è a strati e applica la logica del natting per ogni passaggio fra interfacce con livello di sicurezza diverso. Le intefaccie interne, con maggiore livello di sicurezza, "emergono" e possono subire NAT e PAT con i comandi nat e global. Per accedere ad IP di interfacce interne, dall'esterno si usano i comandi static (fa natting e port forwarding) e il relativo uso di access list (ip access-list). Vediamo una configurazione di esempio minima, con la definizione di due interfacce e un PAT (masquerading) di tutti gli ip dell'interfaccia interna su un unico ip esterno. Alcuni parametri sono impostati di default. Imposta i nomi e i livelli di sicurezza delle interfacce
|
DESCRIPTION | Configurare VPN IPSec sul Pix | Live Discussion - Skill: 4- ADVANCED |
La configurazione di VPN IpSec sul Pix è simile a quella su Cisco IOS e prevede parametri e una logica simile a qualsiasi altra implementazione IpSec. In genere, in fase di configurazione di una VPN basata su IpSec, si devono definire i seguenti parametri per i due peer (i dispositivi agli estermi del tunnel): - Algoritmi di criptazione (3des/des/aes) e hash (md5/sha) utilizzati - Scelta dell'opzione Perfect Forward Secrecy (PFS) e gruppo Diffie-Hellman (1 o 2) - Metodo di autenticazione (Pre-shared keys o certificati X509) - Indirizzi IP pubblici dei due peer (uno può essere arbitrario, per client road warrior, che si collegano da IP diversi) e delle relative reti locali. - Durata in secondi delle Security Associations IpSec (SA). |
||||||
Il Pix può stabilire VPN con altri PIX, router Cisco, Firewall Checkpoint e qualsiasi altro dispositivo che supporti IpSec, sia per tunnel lan to lan che per la gestione di roadwarrior. I comandi fondamentali sono isakmp con cui si gestiscono i parametri del protocollo IKE per la negoziazione di SA fra i peer nella prima fase del setup di un tunnel IpSec e crypto con vari sottocomandi per gestire i diversi aspetti della vpn. Vediamo gli elementi base di una configurazione di un pix con indirizzo pubblico 222.222.222.1/24 sulla interfaccia outside (esterna), e IP 10.0.0.1/24 sulla inside (interna, con un livello di sicurezza maggiore). Questo Pix viene configurato per assegnare a degli arbitrari client su Internet che si collegano utilizzando una pre-shared key un indirizzo preso dal pool 222.222.222.100-110. Ecco gli elementi di configurazione necessari: Si definiscono i nomi e i livelli di sicurezza delle interfacce nameif ethernet0 outside security0 Si definisce una acl che identifica i pacchetti del tunnel da escludere dal natting fra rete interna ed esterno access-list 101 permit ip 10.0.0.0 255.255.255.0 222.222.222.100 255.255.255.255 Indirizzo IP pubblico del Pix e relativa netmask ip address outside 222.222.222.1 255.255.255.0 Indirizzo IP sulla rete interna ip address inside 10.0.0.1 255.255.255.0 Definizione degli indirizzi assegnati ai client VPN. Il nome pool-indirizzi è deciso dall'utente. ip local pool pool-indirizzi 222.222.222.100-222.222.222.110 Si escludono dal natting della rete interna (definito sotto) gli IP che matchano la acl 101 e sono destinati al tunnel. nat (inside) 0 access-list 101 Anche se non strettamente necessario per una VPN, è logico prevedere che il PIX debba fate PAT (masquerading) della rete interna. Si definiscono gli indirizzi (sull'interfaccia inside) da nattare e, con il comando global, l'indirizzo IP, di solito pubblico, con cui devono apparire. Il numero 111 (NatID) deve corrispondere nei due comandi, usando altri numeri si possono definire diversi IP e relativi pool di indirizzi interni. Di default il NatID è 1. Se si usa lo 0, come nella riga sopra, seguito da una acl, si definisce quali pacchetti escludere dal processo di natting: nat (inside) 111 0 0 Definizione del default gateway (si ipotizza un 222.222.222.254). Si deve definire l'interfaccia da cui è raggiungibile. route outside 0.0.0.0 0.0.0.0 222.222.222.254 Indica al Pix di non considerare access-list e nat per permettere al traffico ipsec di arrivare alle interfacce (comodo, pratico e quasi indispensabile, in assegna di laboriose acl specifiche) sysopt connection permit-ipsec Si definisce il set di trasformazione (criptazione + hash) che devono subire i pacchetti nel tunnel. Possono coesistere più set su tunnel diversi, che usano diversi algoritmi. E' indispensabile che client e server della VPN utilizzino esattamente gli stessi algoritmi. crypto ipsec transform-set il_mio_set esp-des esp-md5-hmac Le mappe dinamiche, hanno sintassi simili alle normali mappe, ma possono essere utilizzate per matching con client dalle caratteristiche non predefinite. Per tutti i parametri non esplicitamente definiti (indirizzo IP remoto, transform set, range definito da acl ecc) accettano qualsiasi valore (come se ci fosse una wildcard). La seguente riga associa una mappa dinamica definita dall'utente al trasform set indicato. La definizione di un trasform set è obbligatoria in una dynamic map. crypto dynamic-map la_mia_mappa_dinamica 10 set transform-set il_mio_set A titolo d'esempio si segnalano altre entry che possono essere definite (ma non servono nel nostro caso) per questa dynamic map: crypto dynamic-map la_mia_mappa_dinamica 10 match address 155 # La mappa si applica ai pacchetti definiti nella acl 155 crypto dynamic-map la_mia_mappa_dinamica 10 set pfs # Forza e richiede l'uso di PFS Un Pix può avere più mappe, per gestire diversi tunnel. Queste hanno un nome (la_mia_mappa) e un sequence number che ne identifica l'ordine di preferenza. Devono restare gli stessi quando si definiscono le caratteristiche della stessa mappa. La riga che segue associa ad una mappa dell'utente la mappa dinamica sopra definita (l'uso di mappe dinamiche è necessario quando alcuni parametri sono flessibili e non possono essere definiti a priori): crypto map la_mia_mappa 10 ipsec-isakmp dynamic la_mia_mappa_dinamica Per assegnare dinamicamente gli indirizzi si deve attivare la IKE Mode Config. Con questa riga il PIX prova ad assegnare un IP al client che si collega (preso nel range pool-indirizzi precedentemente definito): crypto map la_mia_mappa client configuration address initiate Con questa riga il Pix accetta eventuali indirizzi proposti dal client (non dovrebbe essere indispensabile, nel nostro caso) crypto map la_mia_mappa client configuration address respond Si applica la crypto map alla interfaccia esterna. Questo comando è fondamentale e di fatto è quello da inserire a fine configurazione per rendere attiva la crypto map. Va specificata l'interfaccia su cui passano i pacchetti da sottoporre alla mappa di criptazione. Notare che può essere specificato solo un set di mappe per singola interfaccia. Un set di mappe deve avere mappe con lo stesso nome, ed eventuale sequence number diverso. Se ci sono mappe con nomi diversi, queste non appartengono allo stesso set e non possono essere contemporaneamente applicate alla stessa interfaccia. Quindi, se per esempio sull'interfaccia esterna di un Pix terminano, oltre ai client road warrior, del nostro caso, anche altri tunnel lan-to-lan, questi devono essere definiti nella mappa la_mia_mappa con sequence number diversi. crypto map la_mia_mappa interface outside Qui si definiscono i parametri con cui gestire IKE, un protocollo che facilita la creazione automatica di SA nella fase 1 della negoziazione IpSec. Si abilita la possibilità di negoziare IKE sull'interfaccia esterna: isakmp enable outside Se si utilizza IKE con un metodo di autenticazione basato su una chiave precedentemente scambiata, questa si definisce nel modo seguente (qui il peer remoto è un qualsiasi indirizzo, ma può essere un IP specifico per tunnel lan to lan): isakmp key chiave_pre_shared address 0.0.0.0 netmask 0.0.0.0 Oltre che con questo comando (è possibile inserirlo più volte per diversi peer), è possibile definire la chiave con i vpngroup sotto definiti. Definisce secondo quale criterio (indirizzo IP o nome) i due peer creano la SA IKE. La stessa scelta va fatta su entrambi i lati, se non si usano chiavi RSA per le quali è meglio usare hostname, il valore di default è: isakmp identity address Si definisce quale è il pool di indirizzi da assegnare ai client: isakmp client configuration address-pool local pool-indirizzi outside Si impostano le policy con cui gestire la negoziazione IKE specificando un numero di priorità (da 1 a 65534, qui è 20). In particolare, nell'ordine: tipo di autenticazione, tipo di criptazione, algoritmo di hash, gruppo Diffie-Hellman, durata in secondi della SA: isakmp policy 20 authentication pre-share Cisco permette una configurazione del tunnel estremamente semplice nei suoi VPN Client (versione 3.x) e nei prodotti che supportano la modalità Easy VPN Remote. Questo è possibile passando vari parametri di rete al client tramite il comando vpngroup (da usare solo con client Cisco). Qui viene definitivo il nome del gruppo (paragonabile ad una login) e la relativa password, oltre agli indirizzi IP di server dns, wins e dominio di default: vpngroup nome_gruppo dns-server 10.0.0.25 Altri parametri sono configurabili, come un pool di indirizzi da assegnare allo specifico gruppo, utile per assegnare diversi pool di indirizzi a diversi gruppi, e in alternativa al pool definito con isakmp client configuration address-pool: vpngroup nome_gruppo address-pool pool_indirizzi Oppure una access-list (in questo caso la 89) con cui si definiscono quali pacchetti criptare nel tunnel e quali lasciare al di fuori del canale criptato: vpngroup nome_gruppo split-tunnel 89
|
TIPS | Monitorare le performance di un Pix | Live Discussion - Skill: 3- INTERMEDIATE |
Quando il network è lento, il firewall ha funzionamenti erranti e tutto sembra complicarsi è utile avere gli strumenti di base per diagnosticare eventuali problemi o condizioni di stress di un Pix. Oltre ad accorgimenti minimi, in fase di configurazione, sono disponibili alcuni comandi validi per capire cosa succede al proprio Pix. Le informazioni qui riassunte derivano da un interessante nota tecnica presa dal sito Cisco e linkata come fonte, in questo caso sostanzialmente unica, di questo testo. |
||||||
Interfacce di rete Per un Pix è fondamentale avere interfacce di rete che non perdono pacchetti per problemi fisici o di configurazione a livello di data link. Come per ogni server o dispositivo di rete, destinato ad essere collegato stabilmente ad una porta di uno switch, è opportuno settare manualmente velocità e duplex del link, sia sull'interfaccia del Pix, che sulla relativa porta dello switch. Il settaggio automatico di default, può ritardare la negoziazione del link (problema solo iniziale) e, se è unilaterale, può dare problemi di duplex mismatch. Nel dubbio impostare un full duplex a 10 o 100, verificando la bontà dei cavi utilizzati e la mancanza di interferenze. A livello della porta dello switch, inoltre, è opportuno rimuovere la negoziazione automatica di etherchannel e trunking (su un Pix, di solito, non si usano: l'etherchanneling non è supportato, mentre il trunking VLAN lo è solo dalla release 6.x). Può essere inoltre utile attivare il PortFast (o Fast Start) Forwarding a livello della porta di uno switch (Cisco) a cui è collegato il Pix. In genere problemi fisici di rete si rivelano con percentuali relativamente alte nei counter dei runts, input errors, CRC, frame sulle interfacce di rete. Logging e troubleshooting Il Pix supporta il logging su un syslog server remoto, che può essere molto comodo per tenere sotto controllo messaggi di errore e attività di debugging. Le attività di logging possono essere piuttosto pesanti e degradare le prestazioni del sistema. In genere vale la pena impostare il livello di log a debugging solo in caso di attività di troubleshooting diretto, altrimenti attivare il logging su un syslog server remoto (qui 10.0.2.150) con minore verbosità: logging on Rallentamenti per timeout di identd e reverse DNS lookup Spesso delle prestazioni di rete deludenti dipendono dalla implementazione di determinati protocolli più che da veri problemi di networking. In particolare accade che alcuni server (ftp, telnet, smtp...) a seconda di come sono implementati e configurati eseguano delle query identd (un protocollo di identificazione dell'utente che si collega al servizio, di fatto totalmente inutile) o DNS (reverse lookup per ottenere il nome di un host di cui si sa l'indirizzo IP) relative ai client che si collegano. Se a queste query non vengono fornite risposte rapide (perchè sul client gira un server identd, o è stato configurato il reverse del suo IP sul server DNS utilizzato), l'utente deve attendere che le stesse vadano in timeout prima di accedere al servizio remoto. Per risolvere questo tipo di problemi (si manifestano tipicamente in alti tempi di attesa al momento di un collegamento ad un server e poi a successive normali velocità di interazione) si può intervenire in vari modi: - Disattivare a livello del server in questione l'uso di query identd o reverse DNS. - Configurare sui propri server DNS (quelli che vengono usati dalle macchine su cui girano i servizi interessati) le zone di reverse (in-addr.arpa) per tutti gli IP dei client che si collegano (se possibile). - Mettere a mano negli /etc/hosts dei server il mapping IP del client remoto e relativo nome (soluzione sporca ma rapida). - Configurare il Pix per rispondere con un esplicito e definitivo RST alle richieste Identd che gli arrivano sulle interfacce. Il comando da usare è: service reset inbound associato ad access-list che bloccano i pacchetti identd (tcp/113). In questo modo il Pix non droppa silenziosamente i pacchetti filtrati ma risponde con un RST al client. Notare che questo comando vale per ogni connessione e causa un maggiore carico dovuto ai pacchetti TCP RST di risposta.Comandi Utili per valutare l'utilizzo delle risorse La command line del PIX presenta vari comandi utili per valutare lo stato delle risorse disponibili. Quelle più importanti sono la memoria, la CPU time, la disponibilità di buffer per i pacchetti in coda, il numero di translazioni e connessioni gestite. show cpu usage - Visualizza l'utilizzo di CPU negli ultimi 5 secondi, 1 minuto, 5 minuti.Le attività che consumano più CPU sono la criptazione di dati per le VPN e in parte il logging in locale (meglio loggare su remoto, senza esagera in verbosità). Per vedere il dettaglio della CPU utilizzata dai singoli processi utilizzare show processes e tenere d'occhio in particolare la colonna runtime, e come questa varia dopo alcuni minuti. Di fatto indica quanto CPU time in millisecondi è stata utilizzata da un processo dall'avvio. Il processo 557poll dovrebbe essere quello più oneroso, in quando controlla il traffico sulle interfacce fastethernet. Se il processo Logger occupa troppe risorse su un sistema sotto stress vale la pena disattivare o ridurre ogni forma di logging.show memory - Visualizza la memoria RAM totale e quella disponibile.Il Pix carica in RAM rispettivamente l'immagine del sistema operativo, la configurazione, alloca spazio per i buffer (blocks) e tiene in memoria le tabelle di natting (xlate) e le connessioni che sta gestendo. Generalmente una volta terminato il boot, la RAM occupata reta stabile, e tende ad aumentare solo sotto grossi carichi di traffico. Se la RAM finisce il Pix, probabilmente, si inchioda. show blocks - Visualizza i blocchi di buffer liberi per i pacchetti che il Pix sta gestendo. L'output si divide secondo le dimensioni dei pacchetti (in genere il normale traffico è messo in blocchi da 1550 byte, mentre i pacchetti per il logging remoto o la sincronizzazione delle informazioni di failover stateful sono in blocchi da 256 byte) e alcuni counter che rappresentano rispettivamente il Massimo numero di blocchi disponibili (MAX), il numero minimo di blocchi liberi raggiunti (LOW) e il numero corrente di blocchi disponibili (CNT). Quando il CNT arriva a zero, il Pix alloca menoria per ulteriori blocchi (fino ad un massimo di 8192), se questo non basta, inizia a droppare pacchetti. E' normale aver il LOW a 0 per blocchi da 256 e 1550, ma se il CNT è costantemente a 0 il Pix potrebbe non bastare a gestire adeguatamente il traffico che gli viene sottoposto.show traffic - Visualizza informazioni sul traffico passato per interfaccia. Utilizzare clear traffic per azzerare i relativi contatori.show interface - Visualizza altri dati sulle interfacce, gli errori e i pacchetti trasferiti. Il contatore no buffers indica quanti pacchetti sono stati droppati per esaurimento dei blocks, le collisions non dovrebbero esistere su interfacce in full duplex e su quelle in half duplex non dovrebbero superare il 10% di tutti i pacchetti in entrata e in uscita. Se uno dei counter degli errori aumenta costantemente esiste un problema che va risolto in quanto intacca sicuramente le performance.show perfmon - Comodo per vedere il numero di connessioni, xlates e altri operazioni che il router sta gestendo. Da valori in numero al secondo correnti e medi.show xlate - Visualizza le traslazioni che il Pix sta gestendo (NAT, PAT). Se si vogliono visualizzare soltanto i totali, senza il dettaglio delle singole xlate, digitare show xlate count Analogamente show conn mostra le connessioni TCP e UDP correnti e show conn count dei valori riassuntivi. Sempre in termini di traffico gestito, show local-host fornire ulteriori informazioni interessanti.Un numero esagerato di connections può essere sintomo di un DOS attack, un numero esagerato di xlate può indicare attività di spoofing da parte di un host interno (sintomo di una potenziale violazione dello stesso). E' possibile, in configurazione, definire i tempi di timeout per connessioni e translazioni, vanno generalmente abbassati, rispetto ai valori di default, se si è sotto attacco DOS. Pix Device Manager (PDM) Il PDM è stato introdotto dalla release 6.0 del Pix Operative System. Permette la configurazione e il monitoring di un Pix via browser, fra le sue caratteristiche permette di visualizzare dati storici su vari parametri. Questi dati possono essere visualizzati anche via command line con comandi tipo show pdm history 10m snapshot . Per attivare questo meccanismo di raccolta informazioni si deve interventire in conf mode con pdm history enable .
|
TIPS | Pix: Utilizzare Certification Authority (CA) per VPN IpSec | Live Discussion - Skill: 5- SENIOR |
Sul Pix l'alternativa all'uso di pre-shared keys per autenticare i due peer di un tunnel IpSec è usare i certificati X.509 gestiti da una CA (Certification Authority come Verisign o una propria gestita internamente). La configurazione del tunnel è sostanzialmente la stessa, nei due metodi, cambia il comando per assegnare isakmp policy 10 authentication pre-share - Per usare chiavi (password) prestabiliteisakmp policy 10 auth rsa-sig - Per usare firme digitali certificate da una CA Cambiano ovviamente i comandi specifici per definire la chiave prestabilita o la gestione di una CA. |
||||
E' fondamentale configurare un nome di host e di dominio per il proprio Pix e mantenerlo coerente con quello registrato presso la CA:hostname superpix A questo punto, sempre in conf mode, vanno digitati dei comandi che servono per stabilire un contatto con la CA, non tutti vengono salvati nella configurazione. Assicurarsi di avere l'ora del Pix settata sul fuso orario di Greenwitch GMT, in quanto molte CA si basano sul GMT per le date di assegnazione e revoca dei certificati. Si generano le chiavi RSA del Pix (una volta dato il comando viene visualizzata a video): ca generate rsa key 512 Le chiavi vengono salvate su un file autonomo sulla flash. Per visualizzarlo: show ca my rsa key .512 è la lunghezza in bit del modulo. Più è grande più le chiavi sono sicure ma lungo il processo di criptazione. Un valore ragionevole è 768. Ci si registra presso la CA (anche questi comandi non vengono salvati e vanno dati una volta sola). Usare un nome univoco per la CA, che verrà usato nel resto della configurazione, qui è un FDQN (può essere imposto dalla CA) ma può essere anche una singola parola come mia_ca. Specificare poi l'IP con cui raggiungerlo, eventualmente seguito dall'URL completo con vi si accede via HTTP al server CA (cgi-bin/pkiclient.exe è il valore di default): ca identity ca-server.esempio.it 10.0.100.20:cgi-bin/pkiclient.exe Si imposta un tentativo ogni 2 minuti per 20 volte per contattare la CA. L'invio di CRL (Certificate Revocation List) da parte della CA è opzionale. ca configure ca-server.esempio.it ra 2 20 crloptional I due suddetti comandi restano salvati nella configurazione. Ci si autentica presso la CA configurata. Assicurarsi che il certificato per il proprio Pix sia stato creato sul server della Certification Authority (proprio o esterno) e di avere la password per registrare (enrollment) il proprio Pix sul server (questi comandi NON vengono salvati in configurazione): ca authenticate ca-server.esempio.it L'opzione serial invia alla CA un numero seriale del Pix. La password va ricordata (non viene salvata) in quanto necessaria se si vuole revocare o rinnovare l'enrollment.A questo punto si può verificare se ci si è registrati correttamente con la ca con il comando show ca certificate Se è tutto a posto e il certificato è stato ottenuto, salvare le impostazioni con ca save all .Questo comando, che non viene salvato in configurazione, va reimpostato ogni volta che si modifica, cancella o alterna qualche impostazione con il comando ca .Il resto della configurazione è simile a quello di un normale tunnel IpSec, salvo dove si configura IKE per usare i certificati: isakmp policy 10 auth rsa-sig
|
Openskills LiveBook: Appunti tecnici su Cisco Pix | (C)oresis Srl | GNU FDL licence | Generated: 23/10/2003 |