Il blog sull'informatica

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.

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

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.

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.

In questo post ho riportato uno script 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.

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 "$password1r"
expect "Password:"
send "$password2r"
expect ">"
send "enar"
expect "Password:"
send "$passwordr"
expect "#"
send "write netr"
expect "#"
send "exitr"
expect eof

NB: ricordatevi di mettere un backslash prima di "r".

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.