[PLUTO-security] Log iptables, non mi tornano i conti!

[Fabio Panigatti]

> gli altri non me ne vogliano, ma "il Panigatti" è proprio un maestro!

Piantala! :-)

> > Hai gente potenzialmente ackera/lamera in rete?
> forse uno, ma non credo

...mmmh...

Che sistemi operativi hai in rete, se si escludono le macchine *nix
a cui puoi accedere solo tu?

> > Il server offre servizi a una DMZ?
> in che senso, se intendi che è in dmz e offre servizi verso
> internet no. Anzi, li una dmz no c'è

Ok, niente dmz. Quello che intendevo era se c'erano server in DMZ che
si connettevano al server interno per fare qualcosa, come autenticare
gli utenti di posta o cose simili.

> > C'e' qualche SNAT che coinvolge l'ip che il firewall ha su eth2 come
> > sorgente? (y.y.y.y)
> no, c'è uno SNAT (MASQUERADE) ma è sulla eth1

Ok.

Qui m'ero espresso in modo un po' criptico. Volevo escludere un'eventuale
dmz che accedeva alla rete interna con SNAT sull'ip di y.y.y.y.

> > 00:02:55:22:aa:5c e' il MAC del server windows?
>
> yes

Ok

> > Dovresti loggare anche i numeri di sequenza e le tcp options IMHO.
> > L'impatto sulle prestazioni e' nullo e hai altri dati d'analizzare
> > in caso di bisogno.
>
> si, hai ragione, è meglio, anzi è meglio se comincio a googlare un po'
> per capiere quello che stai decendo :-))

Be', intanto appendi --log-tcp-sequence --log-tcp-options --log-ip-options
alle tue regole -j LOG :-)

> A dire il vero è meglio se mi studio un po' di regole di log più
> efficaci di quelle che uso adesso, (hai qualche esempio da mandare, non
> chiedo pappa pronta, ma qualcosa che mi faccia capire "in pratica", come
> si fa)

A parte le aggiunte sopra, potrei dirti di mettere una regola -j LOG per
ogni -j DROP/REJECT con una etichetta --log-prefix significativa. Se la
macchina non e' molto performante e/o non ha molto spazio per i log potresti
pensare di mettere delle regole di limitazione del rate di logging, ma
a me non piace tanto: prima proverei a usare un syslogd piu' performante,
tipo metalog, e ad aumentare lo spazio per /var.

> Sarà una patch, ora ho messo in download il kernel source di red hat e
> vediamo.

Mah, magari e' proprio una patch di redhat . I sorgenti dovrebebro chiarire
i dubbi.

> cmq, a me sa tanto di port scan.

Si, sembra uno scan di tipo decoy o idle ai danni del server windows.
Nel caso dell'idlescan sarebbe stato usato il firewall come dumb host,
scelta quanto mai azzardata per un sacco di motivi. Nel caso del decoy
l'ip del firewall sarebbe stato inserito tra quelli per mascherare il
vero scanner.

> Ma dovrebbe essere stato fatto dal firewall verso il server.

No, questo e' da escludere in partenza: se hai regole per cui accetti
traffico ESTABLISHED in ingresso non avresti avuto nessun log, in
quanto i RST provenienti dal server windows sarebbero stati riconosciuti
come risposte ai tuoi SYN e lasciati passare.

> Ho i miei buoni motivi per dubitare che si sia introdotto qualcuno
> dall'esterno ed abbia fatto un port-scan del server, piuttosto che
> qualcuno da dentro lo abbia fatto, usando l'indirizzo del firewall
> come decoy.

O anche come dumb host per un idlescan. Con il kernel 2.4 l'autore del
portscan dovrebbe aver "sondato" il firewall con traffico icmp o udp,
perche' con tcp non funzionerebbe (l'ID sarebbe sempre 0). Considerato
che nmap usa solo TCP per i probe del dumb host vuol dire che chi l'ha
fatto lo ha fatto a mano usando udp o icmp ed e' bravo, o lo ha fatto
con nmap ed e' stupidino, visto che non puo' funzionare. Nel primo caso
dovresti trovare una marea di icmp (echo request, per esempio) o udp
(su una porta chiusa) tutti uguali nei log di netfilter, se blocchi e
logghi questo traffico. Se non ci sono vuol dire che ha usato un tool
che fa i probe degli IP ID su una porta tcp aperta (perche' non c'e'
nei log) e si ritorna al caso dell'idiota oppure che non e' stato un
idlescan. In pratica dovresti cercare altrettante righe di log relative
a traffico udp o icmp provenienti da un MAC address che non e' quello
del server, ma quello del vero scanner.

In caso sia stato un idlescan potresti anche trovare un echo request
proveniente dal vero host che ha fatto lo scan, in quanto molti si
dimenticano di specificare l'opzione -P0 quando usano nmap per gli
idlescan.

Se c'e' qualcosa che non e' chiaro provo a entrare piu' nel dettaglio.

> che dici maestro, è possibile?

Piantala2 :-P

> Tempo fa ho notato che con alcuni tipi di portscan, fatti verso il
> server 2k, nei log mi trovavo nei log degli errori attribuiti al server
> wins. Quindi se lunedì trovo quegli errori e l'ora coincide sono a
> cavallo!

Bene, ottima idea. Ma questo, penso, funziona solo se e' stato eseguito
anche uno scan UDP sul server. Che tipo di scansioni erano quelle che
hanno ti avevano causato gli errori?

> Jul 10 10:43:46 caronte kernel: IN=eth2 OUT=
> MAC=00:08:a1:18:10:f7:00:02:55:22:aa:5c:08:00 SRC=x.x.x.x DST=y.y.y.y
> LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3125 PROTO=TCP SPT=124 DPT=61474
> WINDOW=0 RES=0x00 ACK RST URGP=0

Sembrerebbe proprio il risultato di una scansione idle o decoy. nmap non
e' molto configurabile nelle scansioni idlescan e, in particolare, esegue
due probe per ogni porta. Quindi dovresti vedere almeno due RST o SYN+ACK
per ogni porta sorgente, e mi sembra che non sia cosi', pero' verifica tu
che hai sotto mano tutti i log con un grep SPT=124. Anche la porta di
destinazione dei RST deve essere tenuta d'occhio: e' sempre fissa negli
idlescan e uguale a quella indicata sulla linea di comando su cui eseguire
i probe per verificare gli IP ID. In pratica nmap dovrebbe essere stato
lanciato con una linea di comando del tipo:

nmap -sI y.y.y.y:61474 x.x.x.x

La tua porta 61474 e' aperta? Se non lo e' e non trovi altre righe di log
provenienti da un altro host e dirette verso quella porta allora non siamo
in presenza di un idlescan eseguito con nmap (ma potrebbe essere stato
eseguito a mano con hping, anche se i tempi non sono molto compatibili con
uno idlescan fatto a mano).

Se fosse un decoy eseguito con nmap dovresti trovare all'inizio un icmp
echo reply e, sopratttutto, _due_ RST o SYN+ACK provenienti dalla porta
80/tcp, uno dei quali proprio all'inizio della scansione e uno piu' in
la, quando e' venuto il turno di scansionare effettivamente la porta
80/tcp.

> Jul 10 10:43:46 caronte kernel: IN=eth2 OUT=
> MAC=00:08:a1:18:10:f7:00:02:55:22:aa:5c:08:00 SRC=x.x.x.x DST=y.y.y.y
> LEN=44 TOS=0x00 PREC=0x00 TTL=128 ID=3143 DF PROTO=TCP SPT=445 DPT=61474
> WINDOW=16616 RES=0x00 ACK SYN URGP=0
>
> questa sopra e' diversa non è RST ma SYN ACK, ed infatti quella porta è
> aperta.

Questa puo' essere di qualche utilita': come vedi, ha una LEN=44, che vuol
dire al 99% che il SYN che ha generato questo SYN+ACK non aveva tcp options,
come nel caso dei SYN emessi da nmap e hping2, due strumenti con cui puo'
essere stato condotto un idlescan. Con nmap potrebbe essere stato condotto
anche un decoy scan, ovviamente.

> Jul 10 10:43:47 caronte kernel: IN=eth2 OUT=
> MAC=00:08:a1:18:10:f7:00:02:55:22:aa:5c:08:00 SRC=x.x.x.x DST=y.y.y.y
> LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=4661 PROTO=TCP SPT=1464 DPT=61474
> WINDOW=0 RES=0x00 ACK RST URGP=22770
>
> Questa ha dei valori di URGP diversi, come mai, è un compartamento
> normale dei port-scanner tipo nmap?

Non lo so, non e' una riga molto coerente. Il flag URG non e' settato ma
l'urgent pointer e' maggiore di zero. Tra l'altro in un RST non ha nessun
significato l'indicazione urgent. Penso che sia un baco dello stack di
windows 2000, ma provo a cercare altre info. Un altra possibilita' e' che
sia stato forgiato appositamente, ma non sono molti i tool che consentono
di impostare un valore diverso da zero per l'urgent pointer, tra l'altro
con il flag URG spento, se si esclude uno scanner autocostruito. E poi
perche' prendersi la briga di costruire un pacchetto come questo? Non
ne vedo il motivo, cosi' su due piedi.

Giusto per chiarire: questo traffico non e' generato direttamente dallo
scanner, nmap o chi per lui, ma sono le risposte del server windows alla
scansione dello scanner.

> Jul 10 10:44:15 caronte kernel: IN=eth2 OUT=
> MAC=00:08:a1:18:10:f7:00:02:55:22:aa:5c:08:00 SRC=x.x.x.x DST=y.y.y.y
> LEN=28 TOS=0x00 PREC=0x00 TTL=128 ID=4750 PROTO=ICMP TYPE=0 CODE=0
> ID=32887 SEQ=0

Anche questa e' abbastanza interessante, perche' ancor di piu' di quella
che contiene il SYN+ACK dalla 445/tcp, conferma che e' stato usato uno
scanner, in quanto solo uno scanner emette icmp echo request "vuoti" e,
di conseguenza, windows risponde con echo reply altrettanto vuoti (lo
stack tp/ip di windows, come da rfc, copia il payload dell'echo request
e lo mette nell'echo reply).


In sostanza, sembra che l'ip dell'interfaccia interna del firewall sia
stato usato come dumb host in una scansione idlescan o come indirizzo
spoofato in una scansione decoy, eseguita con un tool automatico che
emette traffico tcp syn senza options e icmp echo request vuoti. A
seconda dell'esito delle ulteriori verifiche sul numero di RST per ogni
porta, sul numero di RST o SYN+ACK provenienti dlla porta 80/tcp del
server e le altre citate, si puo' avere qualche altro elemento per
escludere uno o l'altro dei possibili tool e metodi di scansione che
possono essere stati usati. Se poi si riesce a risalire anche a qualche
riga di log generata diettamente dallo scanner siamo a cavallo, perche'
basta prendere il mac address e...


Fabio