[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Dicembre 2001 ml@sikurezza.org
Soggetto: Re: info firewall
Mittente: Fabio Panigatti \(Minerva spa\)
Data: 17 Dec 2001 17:07:45 -0000
>12/12/2001 13:59:52.032 - Probable TCP FIN scan - Source:212.216.176.140,
>80, WAN - Destination: xxx.xxx.xxx.xxx, 21484 LAN - -

>xxx è l'indirizzo del firewaal

Escluderei a priori un FYN Scan da parte di tin (anche se ho avuto
esperienze contrarie che mi portano a dubitare anche di server
apparentemente al di sopra di ogni sospetto). E poi con tutti i pacchetti
sulla stessa porta non è certo un FIN scan.
Sarebbe stato utile sapere quale rate/timeout usa il tuo firewall per
considerare un portscan una sequenza di pacchetti e se il firewall è
statefull (non lo conosco).

Se hai un IP dinamico può essere che fossero FIN destinati al precedente
leaser il cui router ha terminato la connessione senza aspettare il FIN di
risposta dal server (un po' troppo velocissssimo il cambio di lease :)).

Non so come si comporti il firewall della 3Com ma se è statefull e quel
trafico non fosse stato correlato ad una sessione in corso forse avrebbe
dovuto bloccarlo anche con un altro alert (fai il log di queste anomalie?
non hai altre righe significative nel log?). Quindi è possibile che ci fosse
effettivamente una connessione in atto e che il client avesse inviato il suo
FIN e ricevuto l'ACK del server. Bisognerebbe ricercare il motivo per cui il
server di tin abbia inviato più di un FIN (quanti?) e con un rate (quale?)
forse eccessivo. Evidentemente:
- non ha ricevuto l'ACK di risposta dal client; motivo: computer spento
fisicamente prima dell'invio, rete giù, crash, altro a scelta.
- non ha ricevuto gli RST successivi da parte del firewall; motivo: forse il
tuo firewall non risponde con RST/ICMP Dest Unreach.

A me succede spesso che arrivino 8-10 FIN a distanza di 2-10 secondi su
porte relative a connessioni già chiuse da diversi minuti (a volte da ore);
la causa dell'invio multiplo, nel mio caso, sta nel fatto che se non c'è una
connessione in corso il server non riceve l'RST/ICMP di risposta e quindi ci
riprova. Il perchè l'invio inizi, invece, non l'ho ancora scoperto.

Tanto per completezza potresti vedere se qualcuno della tua rete ha fatto
accessi a quel server web a quell'ora.

Se ho scritto qualche fesseria correggetemi.


Fabio


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005