Archivi tag: pix 501

Configurare un firewall Cisco PIX 501 come IDS

Sicurezza, , , , , ,

Premesso che i PIX 501 sono molto limitati come IDS, in quanto supportano soltanto circa 70 signature (piuttosto datate), può tornare comunque utile configurarli come Intrusion Detection System di prima linea, a cui associare dei sistemi più sofisticati, basati ad esempio su snort.

PIX-501.gif.jpg

Ovviamente, affinchè l’IDS possa svolgere il suo compito è necessario abilitare il logging dei pacchetti “sospetti”, reindirizzandoli su un’altra macchina (aka logserver), in modo da non causare eventuali memory leak al nostro piccolo firewall (soprattutto se la mole di traffico che deve esaminare è piuttosto elavata).

Ma veniamo alla configurazione del PIX. Per prima cosa digitiamo il comando (in modalità enable):

NightFirewall# sh run | i ip audit

il cui output sarà:

ip audit info action alarm
ip audit attack action alarm

Esso rappresenta le due tipologie di signature che possono essere gestite dal firewall, ovvero info ed attack, con le rispettive azioni di default (che in entrambi i casi è alarm).

Definiamo adesso delle nuove policy di audit digitando:

NightFirewall# conf t
NightFirewall(config)# ip audit name esterna info 
NightFirewall(config)# ip audit name interna attack action drop

La prima policy è di tipo info, la seconda è di tipo attack a cui è associata l’azione drop nel caso in cui vengano individuati dei pacchetti sospetti.

Associamo le policy di audit appena create alle interfacce del nostro PIX:

NightFirewall(config)# ip audit interface outside esterna
NightFirewall(config)# ip audit interface inside interna

ed infine lanciamo un write mem per salvare la nuova configurazione:

NightFirewall(config)# write mem

Ora il nostro PIX si comporterà come un IDS.

A presto.

PS: i log generati dal firewall avranno sa seguente struttura:

Oct 22 17:57:26 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 172.16.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 192.168.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400010: IDS:2000 ICMP echo reply from 192.168.*.* to 192.168.*.* on interface outside

In questo caso l’IDS ha generato dei falsi positivi, in quanto trattasi semplicemente di alcuni ping lanciati da nagios per i suoi check.

Ho quindi proceduto a disattivare le signature coinvolte utilizzando i seguenti comandi:

NightFirewall(config)# ip audit signature 2000 disable
NightFirewall(config)# ip audit signature 2004 disable

Cisco PIX 501 ed il fingerprint SSH (non visualizzabile da CLI)

Sicurezza, , , , , , , , ,

Qualche tempo fa, mentre provavo ad abilitare l’SSH sul mio PIX 501, ho cercato di visualizzare il fingerprint che viene generato dopo aver creato la coppia di chiavi RSA pubblica/privata.

pix 501,sshv1,sshv2,rsa1,rsa2,exploit,ssh 1.5,fingerprint,chiave pubblica,chiave privata

Con mio enorme stupore, dopo una breve ricerca su Internet e diversi tentativi da console, ho constatato che tale fingerprint non è visualizzabile direttamente dalla CLI del PIX.

L’unico comando presente da linea di comando è il seguente:

NightFirewall# sh ca mypubkey rsa

che consente di visualizzare la chiave pubblica usata dal firewall in questione, ma non il suo fingerprint.

Inoltre, dando un’occhiata al file .ssh/known_host presente nella mia home, ho notato che il fingerprint salvato è diverso da quelli associati agli host SSHv2. Questo a mio avviso è imputabile a due fattori:

1) L’uso di RSA1 anzichè RSA2 per la generazione del fingerprint stesso;

2) La versione del protocollo SSH utilizzata dal firewall (ovvero la 1.5).

Un modo per visualizzare il fingerprint del PIX 501 però esiste, e si basa su nmap:

nightfly@nightbox:~$ sudo nmap -sS -A <IP PIX 501>

Starting Nmap 5.00 ( http://nmap.org ) at 2011-09-05 20:30 CEST
Interesting ports on *.*.*.*:
Not shown: 998 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      Cisco SSH 1.25 (protocol 1.5)
|_ ssh-hostkey: 1024 **:**:**:**:6f:62:05:dd:a6:3b:43:1f:**:**:**:** (RSA1)

Mistero svelato.

PS: i lameri che volessero fare dei tentativi di exploit verso la mia macchina (poichè l’SSH 1.5 è palesemente vulnerabile), sappiano che tale servizio non è pubblicato all’esterno ed accetta connessioni solo da determinati host della rete interna. Ergo abbandonate qualunque idea bellicosa.

A presto.

Script per il backup automatico della configurazione di un firewall Cisco PIX 501

Networking, , , , , ,

In questo post ho riportato uno scrip da me creato il cui scopo è quello di eseguire un backup della configurazione di un router Cisco SOHO 77. Inoltre, sempre nell’ambito del post in questione, ho descritto la procedura per installare e configurare correttamente un server TFTP sulla nostra linux box. Dando per scontato che il server TFTP sia già attivo e che il file vuoto firewall.cfg sia già presente nella directory /tftpboot, vediamo come configurare il nostro firewall affinchè possa comunicare con il server in ascolto.

pix501

Una volta effettuato il login sul PIX 501 lanciamo un conf t e successivamente digitiamo il comando:

PIX501(config)# tftp-server inside <IP del server TFTP> /tftpboot/firewall.cfg

In questo modo stiamo dicendo al PIX qual è l’indirizzo del server ed il pathname del file su cui salvare la configurazione. Lanciamo un write mem per salvare le modifiche relative alla configurazione del firewall e successivamente accediamo alla nostra linux box. Fattò ciò creiamo il file backup_conf_pix501 il cui contenuto dovrà essere il seguente:

 #!/usr/bin/expect

 set password1 "<pass1>"
 set password2 "<pass2>

 spawn telnet <IP del firewall>
 expect "Password:"
 send "$password1\r"
 expect "Password:"
 send "$password2\r"
 expect ">"
 send "ena\r"
 expect "Password:"
 send "$password\r"
 expect "#"
 send "write net\r"
 expect "#"
 send "exit\r"
 expect eof

Rendiamo il file eseguibile digitando:

nightfly@nightbox:~$ sudo chmod +x backup_conf_pix501

spostiamolo in /usr/bin e successivamente editiamo il file /etc/crontab aggiungendo la entry:

00 00   * * * root backup_conf_pix501

Riavviamo cron:

nightfly@nightbox:~$ sudo /etc/init.d/cron restart

ed il gioco è fatto. See ya.

Reply dei root nameserver: mistero svelato

Sicurezza, , , ,

In riferimento a questo post, il fatto che il mio PIX 501 inizi a strillare per la dimensione “eccessiva” dei pacchetti provenienti da alcuni root nameserver (nella fattispecie K e J), è dovuto principalmente ad una questione di standard. Infatti, lo standard originario del DNS (risalente ormai al lontano 1980) prevedeva una dimensione massima di 512 byte per i pacchetti instradati mendiante il protocollo UDP.

servers.png

Successivamente, l’introduzione dell’IPv6, l’uso opzionale del protocollo TCP per il trasporto e la presenza di alcune flag aggiuntive, specificate all’interno dello standard EDNS0 (acronimo che sta per Extension Mechanism for DNS), ha fatto si che le reply potessero raggiungere delle dimensioni superiori ai 512 byte.

C’è da dire però che proprio tale “aggiornamento” ha reso possibili alcuni tipi di attacco DDoS diretti ai nameserver, tra cui il DNS amplification.

Spero di essere stato esaustivo.

Bye.

Root nameserver e pacchetti dalle dimensioni eccessive

Sicurezza, , ,

E’ lunedì mattina e come al solito do un’occhiata ai log collezionati dal mio server. Apro in lettura quelli del PIX e mi ritrovo queste entry:

Mar 14 06:56:44 ***%PIX-4-410001: Dropped UDP DNS reply from outside:192.58.128.30/53 to inside:*.*.*.*/23803; packet length 685 bytes exceeds configured limit of 680 bytes
 Mar 14 06:56:45 ***%PIX-4-410001: Dropped UDP DNS reply from outside:193.0.14.129/53 to inside:*.*.*.*/27872; packet length 703 bytes exceeds configured limit of 680 bytes
dns.jpg

Lancio un host sugli IP sorgenti, il cui risultato è il seguente:

 nightfly@nightbox:/var/log$ host 193.0.14.129
 129.14.0.193.in-addr.arpa domain name pointer k.root-servers.net.
 nightfly@nightbox:/var/log$ host 192.58.128.30
 30.128.58.192.in-addr.arpa domain name pointer j.root-servers.net.

Dunque mi chiedo: come mai i root nameserver mandano dei pacchetti dalle dimensioni così elevate?

Non mi rimane che modificare le impostazioni del PIX per evitare ulteriori notifiche di questo tipo.

A presto.

Sincronizzare data ed ora dei dispositivi di rete mediante un server NTP

Networking, , , , ,

L’uso di un buon timeserver rappresenta la prima regola per ottenere dei log affidabili e soprattutto privi di eventuali inconsistenze. Inoltre, grazie ad esso, è possibile sincronizzare la data e l’ora sui vari dispositivi di rete, in modo da non dover necessariamente ricorrere ad un settaggio manuale di tali parametri.

synchronize-internet-time-server.jpg

Vediamo adesso come definire un timeserver su di un router Cisco SOHO 77, su di un firewall Cisco PIX 501 e su una macchina linux.

NTP su Cisco SOHO 77

Entriamo nella modalità di configurazione del nostro router:

SOHO77# conf t

e successivamente digitiamo il comando:

SOHO77(config)# sntp server <IP del server NTP>

In questo caso ho utilizzato come server NTP ntp.ubuntu.com, il cui indirizzo IP è 91.189.94.4

Adesso definiamo la timezone:

SOHO77(config)# clock timezone UTC +1

Come potete notare dal comando precedente, ho utilizzato la timezone UTC+1 poichè attualmente in Italia è in vigore l’ora legale.

Controlliamo che tutto sia andato a buon fine digitando il comando:

SOHO77(config)# sh clock

ed infine salviamo la configurazione:

SOHO77(config)# copy run start

NTP su Linux

Passiamo adesso all’installazione di un timeserver sulla nostra macchina linux.

Per fare ciò è sufficiente digitare:

nightfly@nightbox:~$ sudo apt-get install ntp

Ad installazione completata editiamo il file di configurazione relativo ad ntpd, ovvero il demone che funge da timeserver:

nightfly@nightbox:~$ sudo nano /etc/ntp.conf

Inseriamo i seguenti hostname:

# You do need to talk to an NTP server or two (or three).
 server ntp.ubuntu.com
 server ntp1.inrim.it
 server ntp2.inrim.it

Salviamo il file e riavviamo ntpd:

nightfly@nightbox:~$ sudo service ntp restart

NTP su Cisco PIX 501

Bene, ora non ci resta che configurare un server NTP sul nostro firewall. Per fare ciò occorre seguire questi step:

PIX501# conf t

PIX501(config)# ntp server <IP della nostra macchina linux su cui gira ntpd> source inside

PIX501(config)# clock timezone UTC +1

Inoltre, è necessario definire un’ACL apposita sul firewall in questione in modo da consentire il traffico udp sulla porta 123. Ciò si rende necessario poichè il server NTP interno (presente sulla macchina linux) deve poter ricevere gli aggiornamenti da quello esterno.

PIX501(config)# access-list inbound permit udp host 91.189.94.4 host <IP del server NTP interno> eq 123

Controlliamo che tutto sia andato a buon fine digitando:

PIX501# sh clock

ed anche:

PIX501# sh ntp status

il cui output dovrebbe essere simile al seguente:

Clock is synchronized, stratum 4, reference is <IP del server NTP interno>
 nominal freq is 99.9967 Hz, actual freq is 99.9966 Hz, precision is 2**6
 reference time is d1161f31.f0ef3448 (14:18:41.941 UTC Mon Feb 28 2011)
 clock offset is 3.5382 msec, root delay is 78.16 msec
 root dispersion is 1386.23 msec, peer dispersion is 880.07 msec

ed infine salviamo la configurazione con un write mem.

Adesso i nostri dispositivi dovrebbero essere sincronizzati alla perfezione con i server NTP di riferimento.

A presto.

PIX 501: Dropped UDP DNS reply from outside to inside

Sicurezza, , ,

Recentemente, spulciando i log del mio PIX ho notato una sfilza di entry del tipo:

%PIX-4-410001: Dropped UDP DNS reply from outside:151.99.125.2/53 to inside:****/24077; packet length 636 bytes exceeds configured limit of 512 bytes

Ora, non so perchè i DNS che sono solito utilizzare inviino delle reply da 636 bytes, fatto sta che dando un’occhiata alla configurazione del mio PIX ho trovato la seguente direttiva:

fixup protocol dns maximum-length 512

Ecco l’inghippo. Entro in modalità di configurazione e digito:

fixup protocol dns maximum-length 680

Lancio un write mem per salvare la configurazione ed il problema è stato risolto… in men che non si dica.

See ya.

ROM Monitor su PIX 501

Sicurezza, , , ,

Recentemente ho notato un’anomalia durante la fase di boot del mio PIX 501. In particolare, questo aggeggino non riusciva a caricare correttamente Finesse (ovvero il sistema operativo integrato) dalla memoria flash, in quanto il file *.bin risultava corrotto.

L’errore riscontrato era il seguente:

Checksum verification on uncompressed PIX image failed.

Poichè i vari tentativi di ping da e verso le interfacce del firewall in questione sono sistematicamente falliti, ho pensato bene di caricare nuovamente l’immagine del PIX OS. Per fare ciò ho dovuto sfruttare il cosiddetto ROM Monitor, il qualche rappresenta una sorta di “modalità provvisoria” per i dispositivi Cisco.

Per accedervi è bastato riavviare il PIX e premere ESC. A questo punto ho provveduto a lanciare i seguenti comandi:

rommon> int 1

per attivare l’interfaccia “inside” del firewall;

rommon> address <indirizzo IP dell'interfaccia interna del PIX>

per assegnare un indirizzo all’interfaccia “inside” del firewall;

rommon> server <indirizzo IP del server TFTP>

in modo da istruire il PIX su quale indirizzo IP utilizzare per contattare il server TFTP;

rommon> file <nomefile.bin>

per specificare il nome dell’immagine relativa al PIX OS;

rommon> tftp

per avviare il trasferimento ed il salvataggio dell’immagine all’interno della memoria flash del PIX.

Una volta completato il salvataggio occorre riavviare il PIX ed il gioco è fatto.

A presto.

PS: tale guida non ha effetto nel caso in cui il checksum errato sia imputabile ad un guasto fisico della memoria flash.

Aggiornare IOS e PDM su Cisco PIX 501

Sicurezza, , , , ,

Data la scarsa documentazione presente in rete, ho pensato di pubblicare una piccola guida su come aggiornare la IOS (che in realtà si chiama Finesse) ed il PDM (PIX Device Manager) del Cisco PIX 501.

Tale modifica si rende necessaria in quanto non è possibile utilizzare il PDM con sistemi operativi abbastanza recenti, quali Windows XP e Windows Vista. Inoltre, il file associato alla IOS e quello relativo al PDM devono sempre essere allineati, dunque è fortemente sconsigliato effettuare l’upgrade del PDM lasciando invariata la versione di IOS.

Fatte queste premesse, veniamo a noi. Per prima cosa occorre utilizzare un programmino che permetta di lanciare un servizio di server TFTP sulla nostra macchina. Personalmente vi consiglio di usare tftp32, programmino semplice, veloce ed affidabile. Potete scaricarlo da qui, è gratuito.

Ora scarichiamo l’ultima versione di IOS disponibile per il nostro firewall, ovvero la 6.3(5), e la relativa versione di PDM (la 3.0(4)). Entrambi i file li potete scaricare direttamente da qui (è necessario un account CCO).

Avviamo il server TFTP sulla nostra macchina, facendo attenzione che sia la IOS che il PDM si trovino nella stessa directory dell’eseguibile. Colleghiamo il nostro PC al firewall con il classico cavo di rete (straight), allacciato ad una delle interfacce “inside”. Fatto ciò, utilizziamo un cavo rollover per connettere la porta COM del nostro PC con la porta console del firewall, apriamo Hyperterminal (oppure Putty) e settiamo i seguenti parametri di configurazione:

1) Bit per secondo: 9600

2) Bit di dati: 8

3) Parità: nessuno

4) Bit di stop: 1

5) Controllo del flusso: Hardware

Premiamo invio e dovremmo visualizzare il prompt del nostro firewall.

Digitiamo adesso i seguenti comandi:

pixfirewall# copy tftp flash:image

Address or name of remote host [0.0.0.0]? 192.168.2.2

Source file name [cdisk]? pix635.bin

copying tftp://192.168.2.2/pix635.bin to flash:image

[yes|no|again]? yes

Dove 192.168.2.2 è l’indirizzo IP del nostro PC, sul quale è in esecuzione il server TFTP.

Se tutto è andato a buon fine dovremmo vedere in output il seguente risultato:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!
Received 2101248 bytes
Erasing current image
Writing 1978424 bytes of image
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Image installed

Passiamo adesso al PDM. Digitiamo i comandi:

pixfirewall# copy tftp flash:pdm

Address or name of remote host [0.0.0.0]? 192.168.2.2

Source file name [cdisk]? pdm-304.bin

copying tftp://172.16.3.2/pdm-304.bin to flash:pdm

[yes|no|again]? yes

e successivamente verrà stampato a video il seguente risultato:

Erasing current PDM file
Writing new PDM file
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
PDM file installed.

Bene, il gioco è fatto. Non ci resta che installare sul PC che useremo per gestire il nostro PIX una versione di JVM (Java Virtual Machine) <= 1.4.3, poichè con le versioni successive il corretto funzionamento del PDM non è garantito. Potete scaricare la JVM versione 1.4.2 da qui.

Personalmente, prima di installare tale versione di JVM ho disinstallato tutte le altre versioni (più recenti) che si trovavano sul mio sistema, in modo da prevenire eventuali problemi di funzionamento futuri associati al PDM.

Una volta completata l’installazione della JVM apriamo il nostro browser e digitiamo:

https://192.168.2.1

dove 192.168.2.1 è l’indirizzo IP dell’interfaccia “inside” a cui è connessa la nostra LAN.

Appena vi comprarirà la finestra per l’inserimento di username e password, lasciate vuoto il campo username mentre nel campo password inserite la stessa parola chiave scelta per accedere alla modalità enable dal prompt del firewall.

Sicuramente il browser segnalerà che il certificato di autenticità è scaduto. Non preoccupatevi e accettatelo in modo permanente.

Dopo un ulteriore inserimento delle opportune credenziali di accesso e dopo che il PDM avrà caricato in locale tutte le impostazioni relative al nostro firewall, sarà finalmente possibile utilizzare questa GUI per customizzare completamente il nostro piccolo, ma utilissimo, dispositivo.

La guida termina qui, a presto.