Newsgroup: it.comp.sicurezza.varie
Titolo: SYN flooding: domanda facile

Saluti a tutti.
Mi sfugge una cosa sul syn flooding:
1)l'attaccante spedisce dei pacchetti spoofati di tipo syn alla vittima
->
2) la vittima risponde con un ack+syn alla macchina vera il cui
indirizzo e' stato spoofato che ovviamente che non ne sa nulla e che
quindi non risponde con l'ultimo ack->
3)la connessione resta in half-open e quindi se l'attaccante spedisce
dei syn piu' velocemente dei tempi di timeout delle connesssioni TCP
della machina vittima tosto o tardi la macchina vittima si trovera' con
la memoria dedicata alle connessioni pendenti piena.
Vabbe'.
La domanda banale e': ma il protocollo tcp non prevede alcuna azione da
parte della macchina spoofata? Ovvero al punto 2) se una macchina si
vede arrivare un ack+syn relativo ad un syn che non ha mai spedito non
dovrebbe rispondere con un rst? E questo non dovrebbe risolvere il
problema senza bisogno dei syn-cookies?
Grazie per l'attenzione,
t.

 problema senza bisogno dei syn-cookies?
syn-cookies?, la mia ignoranza dice: 'che cavolo intendi per syn-cookies?'
mahh...
Spero di esserti stato utile.
Marco
--
Marco Spiga
www.networkingitalia.it
-----------------------------


E' un modo, attualmente gia' implementato di default (MI PARE) nel kernel della
redhat per prevenire questo tipo d'attacchi. Io ho trovato informazioni
interessanti qui:
http://www.bronzesoft.org/projects/scfw/
Il punto cruciale, secondo me sta nella spiegazione :
<<In the SYN cookies implementation of TCP, when the server received a SYN
packet, it reponds a SYN-ACK packet with the ACK sequence number calculated from
source address, source port, source sequence, destination address, destination
port and a secret seed. Then the server releases all state. If an ACK comes from
the client, the server can recalculate it to determine if it's an reponse to the
former SYN-ACK. If it is, the server can directly enter the TCP_ESTABLISHED
state and open the connection.
In this way, the server avoid to keep watch half-open connections. >>
Il concetto, piu' o meno, m'e' chiaro, ma non capisco cosa intenda "in pratica"
con la frase:
"Then the server releases all state", che vuol dire? Che si scrive qualcosa
nell'hard disk e poi che va a rivederselo quando riceve l'ultimo ack? Perche',
detto grezzamente, se invece lui comunque si scrive qualcosa in ram allora
l'attacco puo' in ogni caso avere una sua efficacia, magari in tempi piu'
lunghi.
Mi sei stato utilissimo,
stammi bene,
t.

 proprio per evitare che partano i reset in risposta ai syn-ack.
Grazie mille, m'era sfuggito questo dettagliuccio.
t.

 lunghi.
Lui non si scrive niente da nessuna parte: rilascia completamente qualsiasi
stato relativo alla sessione in modo da non occupare risorse. L'ISN del S+A
viene calcolato partendo da alcuni dati noti (che hai gia' citato). L'ISN e'
il cookie.
Quando riceve un ACK (qualsiasi) verifica se appartiene ad una sessione gia'
stabilita o no e, nel secondo caso, ricalcola il cocokie: se corrisponde al
ACK num + 1 dell'ACK allora vuol che quell'ACK e' in risposta ad un suo SYN
+ACK e, a quel punto, costruisce una sessione usando i dati dell'ACK appena
arrivato e comincia la comunicazione. Se il cookie non corrisponde, invece,
viene emesso un rst.
Fabio

 ACK num + 1 dell'ACK allora vuol che quell'ACK e' in risposta ad un suo
SYN
s/ACK num + 1/ACK num - 1/
Fabio

 arrivato 
perfetto, era proprio questo che mi sfuggiva.
Grazie mille,
t.


Grazie a te!, e grazie per il link, se non ci si aiuta nell'ng :), dove ci
si potrebbe aiutare :P ...saluti.
<out>
p.s. grazie anche a Fabio Panigatti...ho letto dopo il suo post
sull'argomento.
</out>
--
Marco Spiga
www.networkingItalia.it
-------------------------------------

Ciao,
scusa dimenticava la rfc2267!, il num dovrebbe essere giusto :), prova un
po' a leggerla :))))
ciao
