Re: Raptor fw synflood protection

> ma che si verificano spessissimo, questo fw quando riceve un syn per
> iniziare una connessione, a questo risponde con un ack (*solo* ack,
> non syn/ack) sommando 1000000 al sequence number del syn che ha
> ricevuto. In alcuni casi ho verificato che un client (nel mio caso

In un syn flood la macchina che appare come sorgente del traffico non
deve essere raggiungibile, altrimenti risponderebbe con un rst al syn
ack e non si avrebbe l'effetto voluto. Se invio un ack fuori sequenza
al mittente e ricevo l'rst ho la conferma che il syn proveniva da una
macchina esistente e che non si tratta di un syn flood, altrimenti mi
dimentico di aver ricevuto il syn e la cosa finisce li.

> linux) invia il syn, riceve l'ack, questo ack non gli quadra quindi
> invia una rst rimanendo in attesa del syn/ack relativo al syn
> precedentemente inviato. (questa e' la prima cosa che non mi quadra,
> perche' si comporta cosi?) 

rfc793

> correttamente. In altre condizioni se in mezzo alla strada c'e' un
> qualche aggeggio che fa stateful inspection possono sorgere dei
> problemi, ad esempio se c'e' un firewall netscreen, che di default ha
> abilitato il check dei sequence number nello stateful inspection, la
> cosa non funziona perche' probabilmente non lascia passare l'ack che
> torna indietro 

Dipende da come viene fatta la stateful inspection ma al 99% il motivo
e' proprio che l'ack viene bloccato e il raptor, non vedendo l'rst del
client, ritiene che il three way handshake non debba essere completato
(vedi sopra).

> e se anche lo facesse passare non farebbe passare la
> rst che il client invia. 

Se lasciasse passare l'ack e' perche' ha creato un nuovo stato per una
connessione, quindi l'rst di ritorno passerebbe ed il tuo problema non
esisterebbe (vedi oltre: fw-1).

> Un'altra cosa strana che ho verificato e'
> che se a inviare il syn e' una macchina OpenBSD (non ho provato altro
> oltre a linux e obsd) quando riceve l'ack semplicemente lo ignora e
> rimane in attesa del syn/ack corretto. 

Non ho mai provato ma non e' un comportamento corretto. Non e' che c'e
un [i]pf che filtra su qull'host openbsd? Quando ho un attimo di tempo
faccio una prova.

> Questa storia
> di rispondere ad un syn con un ack incrementando di 1000000 il
> sequence number e' rfc-compliant? 

Se intendi dire che e' prevista da una rfc la risposta (AFAIK) e' no,
come non lo sono gli altri sistemi di protezione dai syn flood.

> Quali dispositivi oltre ai netscreen hanno problemi a gestire questa 
> cosa? Io ho verificato che firewall-1 non fa una piega.

Perche FW-1 AFAIK crea un nuovo stato anche quando passa un ack. Anche
netfilter ha questo comportamento ma e' possible rimediare con un paio
di regole.


Fabio



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