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


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


Archivio: Marzo 2002 ml@sikurezza.org
Soggetto: Re: Syn/Ack Flood?
Mittente: Angelo Dell'Aera
Data: 28 Mar 2002 18:36:14 -0000
On Wed, 27 Mar 2002 14:10:50 +0100 Qlo <qlo@ipv6mania.net> wrote:

> Parlando  ieri  sera  con   un  conoscente  è  venuto  fuori  questo
> argomento: sei  da un host A  forgio un pacchetto  con indirizzo del
> mittente  quello della  vittima  e come  destinatario  quello di  un
> server (magari  che sappiamo avere molta banda  a disposizione).  Il
> pacchetto avrà  il flag SYN  ad 1.  La  porta ad esempio sia  la 80.
> Quindi il pacchetto giungerà al server che risponderà con un syn/ack
> all'indirizzo  mittente che  quando riceverà  tale pacchetto,  se la
> porta su  cui lo riceve è  aperta manderà un  RST, altrimenti nulla.
> Ma se  io mando un sacco di  syn al server, magari  da + postazioni,
> questo manderà  una marea di  syn/ack alla "vittima"?  E  filtrare i
> pacchetti  con questo  flag in  ingresso  senza che  ci sia  nessuna
> connessione in  stato SYN_SENT non  risolverebeb nulla no?  La banda
> sarebbe cmq occupata.

In  teoria sì  nella  pratica è  difficile  a meno  di non  mettercisi
d'impegno.   Ti  spiego.Nel  momento   in  cui  esegui  un  SYN  flood
normalmente quello che  fai è forgiare un pacchetto  SYN con indirizzo
sorgente  spoofed  (facendo  in  modo  che questo  indirizzo  non  sia
raggiungibile) e inviarlo all'host vittima.E' questo il meccanismo che
ti  consente di implementare  il DoS  perchè se  ci pensi  bene quando
l'host  vittima riceve il  SYN invia  il SYN/ACK  e allo  stesso tempo
alloca risorse  per la gestione della connessione  (che ovviamente nel
nostro caso non diventerà  mai ESTABILISHED).Inoltre considera che una
volta  che l'host vittima  invia il  SYN/ACK se  non riceve  l'ACK che
conclude il 3-way handshake ritrasmette il SYN/ACK per un certo numero
di volte.E  qui sta il nocciolo  del discorso perchè  nel frattempo il
kernel  deve  per forza  mantenere  in  quella  che potremmo  chiamare
`incomplete connection  queue' una  entry e non  può liberarla  se non
dopo la scadenza del timeout.Questa queue ha una dimensione limitata e
se la saturi hai ottenuto un DoS nel senso classico del termine perchè
da  quel  momento  tutto  ciò  che  giungerà  su  quella  porta  verrà
silenziosamente scartato.

Nel tuo caso lo scenario è  ben diverso perchè l'host vittima non deve
attendere  proprio nulla.Questo  si  vede arrivare  un  SYN/ACK ma  di
quella connessione non c'è  traccia.Di conseguenza l'RST è immediato e
quindi non  c'è esaurimento delle risorse per quell'host.

Certo qualcuno potrebbe  dire che è pur sempre un  flooding ma imho si
otterrebbe lo  stesso risultato inviando una qualunque  fetenzia e non
necessariamente un SYN/ACK.


Alla prossima,

Angelo Dell'Aera 'buffer' 
<buffer@users.sourceforge.net>


________________________________________________________
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