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

[Andrea Dinale]

Il lun, 2003-07-14 alle 18:14, Fabio Panigatti ha scritto:
 
> Che sistemi operativi hai in rete, se si escludono le macchine *nix
> a cui puoi accedere solo tu?

3 linux ed un po' di uindovs di qualsiasi versione dal 95 all'xp

> > > 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 :-)

ok, domani quando sono in ufficio modifico lo script (lo potrei fare in
ssh anche da qua, ma non mi sembra giusto lavorare troppo per la gloria)

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

Bene, ho già un bel punto di partenza, ora come ora le mie regole di log
sono settate da schifo!
Non conosco metalog, ma penso che passero un po' per google :-)

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

come ho già detto nell'altra mail, i dubbi sono stati alimentati e non
tolti, proverò a cercare meglio, ma google dice poco, e nel kernel
source RH, non c'è nulla, proverò a scaricare i sorgenti di iptables +
patch-o-matic e vedo se dentro li c'è la risposta o no!

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

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?

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

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.
Probabilmente non è una scelta felice, ma ripeto che non sono ancora in
grado di loggare bene il traffico, devo entrare nella giusta mentalità.

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

frena frena, stai 1000 passi davanti a me e continui a correre :-)
non mi è molto chiaro, perchè con l'id è sempre 0? è per merito dello
stack tcp o per altri motivi?
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?

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

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

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

colpito ed affondato!, anche qui hai ragione, ho fatto delle prove e
questo succede solo con scansioni udp, quindi nisba!
cmq sono sicuro si tratti di port-scan.
 
> > 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

ho controllato, non sembra un idlescan.

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

'nchia che difficile... sto slerando :-)
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

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

[CUT]
> 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.

ci sono sempre più indizi, ormai sono sicuro si tratta di un decoy scan!

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

anche a me non sembra sensato forgiare un pacchetto con queste
caratteristiche, soprattutto per il fatto che è un RST.
Non è da escludere uno scanner autocostruito, ma viste le considerazioni
precedenti, è probabile si tratti di nmap

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

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

> > 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).
 
direi che il cerchio si chiude!
 
> 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...

Purtoppo sempre per il discorso dei log fatti alla ca**o di cane questa
informazione non posso ricavarla...
Per questa volta l'ha fatta franca, ma la prossima arriva la cazziata!

Grazie
Andrea