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

[Fabio Panigatti]

> Non conosco metalog, ma penso che passero un po' per google :-)

Io personalmente uso syslog-ng, ma metalog ha un sistema di bufferizzazione
in ram molto performante ed e' facile da configurare.

> mi interessa... come mai sarebbe una "scelta azardata", forse perchè è
> molto probabile che un firewall faccia logging del traffico, e quindi si
> risale velocemente al colpevole? Quali possono essere gli altri motivi?

Si, soprattutto perche' e' abbastanza scontato che un firewall logghi
il traffico sospetto e che abbia strumenti di rilevazione dei portscan.
Inoltre il funzionamento degli idlescan e' basato sul fatto che l'host
che viene sfruttato abbia scarso traffico, mentre e' facile che da un
firewall passi sempre qualcosa.

> si, ma la regola di log sta prima di quella di ESTABLISHED, l'ho fatto
> apposta perchè visto che si tratta di un server, loggo tutto il traffico
> non lecito che proviene dal server 2k in direzione del firewall o di
> internet.

Ok, allora non vuol dire.

> 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.

> non mi è molto chiaro, perchè con l'id è sempre 0? è per merito dello
> stack tcp o per altri motivi?

Prova a cercare documenti sull'idlescan o dumb host scan. Vedrai che e'
una tecnica inventata da un ricercatore italiano (antirez) basata sul
conteggio dell'incremento dell'IP ID di un host che riceve traffico di
"rimbalzo" dal vero host di cui si esegue la scansione. In pratica tu
spoofi l'indirizzo del dumb host (caronte) per eseguire la scansione
del server. Il server risponde un RST verso caronte per ogni porta
chiusa e un SYN+ACK per ogni porta aperta. Il RST viene droppato da
caronte mentre al SYN+ACK viene risposto un RST verso il server. Questa
uscita di un pacchetto tcp/ip causa l'incremento dell'IP ID di caronte.
Se caronte e' una macchina che aumenta progressivamente gli IP ID tu
puoi fare una cosa: sollecitare l'emissione di un pacchetto da caronte
nella tua direzione per ognuno dei pacchetti di scansione che invii al
server. Ogni risposta di caronte nella tua direzione avra' un IP ID
maggiore se ha gia' dovuto emettere un RST verso il server. In pratica
se l'ID e' uguale a ID_predicibile+1 vuol dire che il server ha risposto
un SYN+ACK e quindi quella porta del server e' aperta. Spero di essermi
spiegato, ma nel caso trovi un po' di doc anche in rete.

Ora, questa cosa funziona se l'incremento dell'ID e' predicibile, e non
random, come avviene con OpenBSD o altri sistemi operativi, e se l'host
che usi per contare gli ID non genera' altro traffico per i fatti suoi,
perche' altrimenti il conteggio sale per altri motivi (per questo si
chiama dumb host = host "silente"). Ma con i kernel linux c'e' un altro
problema: l'ID e' predicibile, in genere, ma i RST e i SYN+ACK hanno
sempre ID=0, senza nessun incremento, e bisogna usare le risposte icmp.
Visto che l'implementazione di idlescan di nmap usa solo TCP e quindi
un RST o un SYN+ACK sollecitato dal dumb host, e non icmp, non funziona
usando come dumb host un linux 2.4.

> E perchè se fa il probe degli IP ID su una porta aperta si ritorna al
> caso dell'idiota?
> In toria anche se la porta è aperta dovrebbe cmq ritornare un RST dallo
> zombie alla vittima?!?!, facendo il secondo ID probe sulla porta aperta,
> ci si dovrebbe trovare ID+2 o sbaglio?
> Mentre se la porta è chiusa ritorna un ID+1? giusto?

Opss... mi sa che sapevi gia' come funziona l'idlescan... vabbe, la
pappardella sopra la lascio lo stesso, ormai che l'ho scritta.

E' una scelta che funziona bene se le macchina non e' linux 2.4, perche
se la porta e' aperta e' facile ritenere che il traffico li diretto non
venga loggato. Ma se la macchina e' un linux si torna al problema dell'ID
che e' sempre zero, e il gioco non funziona.

> no, gli echo request che ci sono si possono contare su una mano

E tutti vengono dal server? Non c'e' niente di correlabile con la
scansione (per tempi, ad esempio) che venga da altre macchine?

> ho controllato, non sembra un idlescan.
>
> ok, la porta è chiusa e non ci sono log, quindi niente idle con nmap.
> cmq continuo a non capire il discorso della porta 61474 aperta o chiusa

Perche' avevo dato per scontato che le righe loggate fossero relative
solo al traffico droppato, mentre invece tu hai il LOG su tutto. Se
le righe di log sono solo sul traffico dropptao non potresti vedere
log relativi a traffico verso porte aperte, perche' sarebbe accettato.
Se la tua porta 61474 fosse stata aperta si potrebebro fare i probe
sulla 61474 con la ragionevole certezza che non verrebbero registrati.
Fatto salvo il fatto che con linux 2.4 non funzionerebbe.

> > 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.
>
>questi ci sono! quindi è più probabile sia un decoy proveniente da nmap!

Bene, forse ci siamo.

> qui c'ero arrivato da solo :-)))

Si si, l'avevo capito dal resto del post, ma avevi fatto un cenno al
fatto che poteva essere un comportamento degli scanner tipo nmap e per
un attimo pensavo che ti riferissi alla possiiblita' che quel pacchetto
venisse _direttamente_ da nmap.

> Per questa volta l'ha fatta franca, ma la prossima arriva la cazziata!

Magari puoi mettere un IDS o un firewallino sul server windows, in modo
da avere qualche info in piu' alla prossima marachella.

Ciao


Fabio