[PLUTO-security] Log preoccupanti

[Andrea Dinale]

Piviul said:
> Andrea Dinale wrote:

> ...dunque, credo se mi puoi assistere ci possa provare ma sono cose   
> moolto al di sopra delle mie conoscenze. Anzitutto da dove mi consigli 
> di agire: da una box all'interno della LAN può andar bene o credi sia 
> meglio dalla DMZ? Tanto dovrebbe essere soltanto una questione di 
> controllare le differenza di TTL... giusto?

bhe se vuoi ricreare la situazione uguale a quella registrata nei log,
dovresti farlo dal firewall dove hai avuto i log.

> Poi mi scrivi: /invialo all'host remoto in porta 80/ intendi ad un host
>  specifico (ad esempio proprio il 207.68.178.238? tieni conto che se lo
>  pingo non risponde!)?

yes, intendo proprio quello.
Cmq se non si pinga non e' un problema, puoi telnettarti nella porta 80,
quindi l'host remoto 207.68.178.238 risponde almeno con un SYN/ACK.

Cmq non e' una cosa indispensabile da fare quel test, e' solo una
curiosita' perche` mi sembra anomalo avere due pacchetti spediti
apparentemete dallo stesso host, ma con due ttl diversi, addirittura di 11
unita'.

giusto per completezza di informazione (anche per chi sta leggendo in
silenzio) il ttl e' un valore che puo' essere max 255. Quando un host
invia un pacchetto scrive un valore di ttl nel header del pacchetto
stesso. Ad ogni router che il pacchetto attraversa il ttl viene
decrementato di una unita'. Se durante il suo tragitto il ttl si azzera
viene mandato un messaggio icmp all'host che ha originto il pacchetto
dicendogli che non lo puo' consegnare perche` e' stato superato il limite
massimo di router oltrepassati.

E' ragionevole pensare che tutti i pacchetti che vengono scambiati tra due
host siano allo stesso livello di ttl. Non e' una verita' assoluta,
perche` il ttl e' modificabile, ma e' molto strano che due pacchetti che
con buona probabilita' appartengono alla stessa connessione abbiano una
diferenza di ttl cosi elevata.

Di solito quando si pensa di essere vittima di un attacco da sorgente
spoofata, e' utile verificare il ttl, perche` puo' fornire un indicazione
in piu' rispetto alla autenticita' della sorgente.

nel tuo caso dubito altamente si tratti di un ip spoofato, non avrebbe
molto senso spoofare un ip con i flag ACK/FIN.

Avevo due minuti ed ho fatto un paio di test:

I risultati sono simili ai tuoi log (quindi non preoccuparti, sembra
"normale")

Ho spedito dei pacchetti con flag ACK settato, cosi l'host remoto puo'
solo rispondere con un RST, ed infatti.

Dec 16 16:47:27 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=30337 PROTO=TCP
SPT=0 DPT=2418 WINDOW=8201 RES=0x00 RST URGP=0

Dec 16 16:47:28 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=28121 PROTO=TCP
SPT=0 DPT=2419 WINDOW=8201 RES=0x00 RST URGP=0

come si puo' vedere il ttl qui e' a 240.
Pero' a differenza dei log tuoi l'id e' diverso da zero


Mentre questi sono dei log di una sessione HTTP (quindi sulla porta 80)


Dec 16 16:48:49 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=19105 PROTO=TCP
SPT=80 DPT=38514 WINDOW=8190 RES=0x00 ACK SYN URGP=0

Dec 16 16:48:50 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=57737 PROTO=TCP
SPT=80 DPT=38514 WINDOW=17191 RES=0x00 ACK URGP=0

Dec 16 16:48:50 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=576 TOS=0x00 PREC=0x00 TTL=49 ID=57741 PROTO=TCP
SPT=80 DPT=38514 WINDOW=17191 RES=0x00 ACK URGP=0

Dec 16 16:48:50 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=387 TOS=0x00 PREC=0x00 TTL=49 ID=63159 PROTO=TCP
SPT=80 DPT=38514 WINDOW=17191 RES=0x00 ACK PSH FIN URGP=0

Dec 16 16:48:50 caronte kernel: TTL-TEST IN=eth1 OUT=
MAC=00:08:a1:18:10:f7:00:04:ed:0b:c5:52:08:00 SRC=207.68.178.238
DST=62.123.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=42261 PROTO=TCP
SPT=80 DPT=38514 WINDOW=17191 RES=0x00 ACK URGP=0

qui succedono delle cose strane (almeno per me), il ttl del primo e
dell'ultimo pacchetto e' a 240 come quello prima, ma per i pacchetti
intermedi il ttl e' a 49

Ho dei dubbi...
Mi aiutate?
Allora se pingo (anzi hpingo) mi risponde semrpe con ttl 240, faccio una
connessione http, mi risponde con un ttl diverso, tranne per il primo e
per l'ultimo pacchetto.Cosa puo' essere?? tipo un proxy? che si smandruppa i pacchetti "sporchi"
(tipo quelle dell'hping) e di inizializzare la connessione e poi passa la
palla al server vero e proprio??

> infine non ho mai sentito parlare di hping; ora lo cerco e spero di 
> essere in grado di creare un pacchetto ACK con hping.

hping e' un software che ti permette di pingare forgindo il pacchetto piu'
o meno come vuoi, non puoi fare proprio tutto (mi sembra), ma molte volte
e' utile.

>> Sul fatto che il bridge sia stato permissivo nei confronti di quei
>> pacchetti potrebbe essere perche` il bridge non si e' accorto che la
>> connessione tra il tuo host e quello remoto e' caduta, ma se ne e'
>> accorto il firewall.> e come mai?


Bhe' alle volte capita, anche frequentemente. Sopratutto se ci sono due
nat in mezzo.

>> Se non ricordo male che setta ID=0 per tutti i RST e' linux > 2.4.20,
>> pero' NON ne sono ASSULUTAMTE sicuro, [Maestro Fabio se ci sei batti un
>> colpo:)].> ma quanto ne sai??!! in effetti è un 2.4.23


ehmm... sto parlando dell'host remoto cioe' di 207.68.178.238 :-))
Cmq ti consiglio di aggiornare il 2.4.23, perche` (se non sbaglio) e'
affetto da una vulnerabilita` abbastanza grave.Questo vale se e' un "vanilla" se e' un kernel distribuito con la distro,
potrebbe essere che sia stata applicata la patch correttiva.

> Vi terrò informati


ok ;)


ciao
A


P.S. scusate la lunghezza del post, ma tanto qui non c'e' poco traffico,
quindi mi permetto un po' di bit in piu' :-))