Re: Log-Firewall

Grazie per queste prime info, ed ora vediamo di fornirti le ulteriori per
completare la risposta.
Questa macchina è una RH7.2, kernel 2.4.18-10brnf0.0.7 per poter far
interoperare le funzionalità di bridge con iptables 1.2.5
La macchina linux ha tre interfacce di rete
E' un bridge firewall e non fà routing
Gli indirizzi x.x.x.x sono quelli della mia classe C
La macchina che tu presumi essere un nt4 è effettivamente un nt4 e non è
possibile (ho controllato) che possa aver originato un pacchetto verso un
indirizzo di rete 192.168.50.156.

Le regole inerenti quelle righe del log sono queste:

#---------------------------------------------------------------------------
-----------------------------------#
# USO IL CONNECTION STATE PER BY-PASSARE IL RULE CHECKING
#
# E FACCIO IL LOG DEI PACCHETTI "INVALID"
#
#---------------------------------------------------------------------------
-----------------------------------#
iptables -A INPUT  -i br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A KEEP_STATE -m state --state INVALID -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "INVALID STATE: "
iptables -A KEEP_STATE -m state --state INVALID -j DROP


#---------------------------------------------------------------------------
-----------------------------------#
# REGOLE PER LA PROTEZIONE DA STEALTH SCAN E COMBINAZIONI
#
# ILLEGALI DEI FLAGS NEGLI HEADERS DEI PACCHETTI TCP
#
#---------------------------------------------------------------------------
-----------------------------------#
iptables -A CHECK_FLAGS -p tcp --tcp-flags ALL NONE -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "ALL NONE : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags ALL NONE -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "NMAP-XMAS: "
iptables -A CHECK_FLAGS -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "SYN,FIN SYN,FIN : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "SYN,RST SYN,RST : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags FIN,RST FIN,RST -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "FIN,RST FIN,RST : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,FIN FIN -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "ACK,FIN FIN : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,FIN FIN -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,PSH PSH -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "ACK,PSH PSH : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,PSH PSH -j DROP
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,URG URG -m limit --limit
$LOG_FLOOD -j LOG --log-prefix "ACK,URG URG : "
iptables -A CHECK_FLAGS -p tcp --tcp-flags ACK,URG URG -j DROP

Inoltre cosa significa TCP INCOMPLETE [8byte]

Grazie per la collaborazione e buona giornata
P.S.
Non capisco quando dici "hai fatto biricchinate"
non ho utilizzato nessun tipo di scan se è questo che intendevi.

----- Original Message -----
From: "Fabio Panigatti" <ml-panigatti@xxxxxxxxxxxxx>
To: <ml@xxxxxxxxxxxxx>
Sent: Friday, September 19, 2003 7:17 PM
Subject: Re: Log-Firewall


> Senza informazioni sulla tua rete, sulla configurazione delle macchine
> e con gli ip offuscati si possono fare solo vaghe congetture.
>
> > Sep 19 11:07:36 Br-Fwll kernel: INVALID STATE: IN=br0 PHYSIN=eth0
OUT=br0
> > PHYSOUT=eth1 SRC=213.45.10.146 DST=x.x.x.x LEN=40 TOS=0x00 PREC=0x00
TTL=118
> > ID=40234 DF PROTO=TCP SPT=1451 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
> >
> > Da cosa capisco che è un INVALID STATE?
>
> Dalla label :-)
>
> A parte le spiritosaggini, che non sono poi tanto tali, la label come
> saprai viene assegnata da chi scrive la regola: cerca nello script,
> guarda la regola e scoprirai su cosa fa match. E' probabile che si stia
> riferendo allo stato... INVALID, ma potrebbe anche essere altro. In
> assoluto non c'e' nulla negli header di quel pacchetto che puo' farlo
> definire INVALID a prescindere dalle regole.
>
> E' probabilmente una SYN scan fatto da 213.45.10.146 e tu registri (e,
> verosimilmente, droppi) i pacchetti INVALID in ingresso.
>
> > Sep 19 11:23:29 Br-Fwll kernel: INVALID STATE: IN=br0 PHYSIN=eth0
OUT=br0
> > PHYSOUT=eth1 SRC=212.131.63.58 DST=x.x.x.x LEN=56 TOS=0x00 PREC=0x00
TTL=246
> > ID=57206 PROTO=ICMP TYPE=3 CODE=1 [SRC=x.x.x.x DST=192.168.50.156 LEN=44
> > TOS=0x00 PREC=0x00 TTL=118 ID=61478 DF PROTO=TCP INCOMPLETE [8 bytes] ]
> >
> > Questo è particolare perchè è un ICMP: cosa significa la stringa fra
> > parentesi quadra? e perchè arriva da una rete privata (192.168.59.156)?
>
> E' un host unreachable: apparentemente, uno degli host nella tua rete
> (probabilmente un winnt 4) ha inviato un pacchetto TCP (probabilmente
> un SYN) all'ip 192.168.59.156, che non appartenendo alla tua rete e'
> stato instradato su internet. A nove hop di distanza c'era un router
> (tale 212.131.63.58) che non sapeva che farsene di quel coso e lo ha
> scartato mandandoti un'adeguata segnalazione (tipo 3 code 1, host
> unreachable) in cui ha allegato l'header ip del pacchetto che ha
> causato il problema (quello che vedi tra le parentesi quadre).
>
> Il problema e' che questo ICMP sarebbe dovuto essere traffico RELATED
> se il pacchetto TCP che l'ha originato fosse passato dal tuo netfilter.
> Qui sembra che sia stato interpretato come INVALID ma, come dicevo sopra,
> la label potrebbe non riferirsi necessariamente allo stato INVALID. Se e'
> veramente INVALID dovrebbe essere stato spoofato (il pacchetto TCP) al di
> fuori della tua rete (ma ci sarebbe una strana coincidenza sui TTL) oppure
> potrebbe essere stato generato molto tempo prima che arrivasse l'ICMP
> (ma molto, molto tempo prima) cosi' che nel frattempo lo stato era
scaduto.
> Troppe poche info. Se hai snort o un altro IDS con attivato il log delle
> sessioni TCP puoi vedere cosa e' successo in quel periodo di tempo.
>
> > Sep 19 11:47:32 Br-Fwll kernel: INVALID STATE: IN=br0 PHYSIN=eth0
OUT=br0
> > PHYSOUT=eth1 SRC=217.59.239.82 DST=x.x.x.x LEN=56 TOS=0x00 PREC=0x00
TTL=247
> > ID=45281 PROTO=ICMP TYPE=3 CODE=13 [SRC=x.x.x.x DST=217.58.188.109
LEN=40
> > TOS=0x00 PREC=0x00 TTL=119 ID=10296 PROTO=TCP INCOMPLETE [8 bytes] ]
> >
> > Uguale al precedente ma nella stringa fra parentesi quadra figura un
> > indirizzo di rete pubblica.
>
> Qui ci si ripete, a parte che il pacchetto TCP originale sembra quasi
> generato da uno scanner (hai fatto biricchinate?).
>
> Il tipo 3 code 13 e' un communication administratively prohibited, non
> molto dissimile da quello precedente tranne che per il fatto che e' stato
> inviato perche' chi ha configurato il router saprebbe anche dove inviare
> il tuo pacchetto, ma per qualche motivo non vuole farlo e te lo filtra.
>
> Non capisco bene il tuo commento: vuoi dire che nel primo caso l'ip e'
> privato? Forse sarebbe meglio se tu chiarissi se questa macchina fa da
> bridge o da router, se fa nat e dove e' stata inserita nella tua rete.
>
>
> Fabio che magari s'e' perso qualcosa per strada
>
>
> ________________________________________________________
> http://www.sikurezza.org - Italian Security Mailing List
>


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