Re: Attacco agli stati TCP

> FuSyS ha fatto una considerazione molto importante a riguardo,
> dicendo che molte tecniche in certi ambienti sono gi?
> pi? o meno conosciute. Gli diamo ragionissima, anche se forse
> si riferiva ad ambienti privati. 
mh non proprio privati, discussioni simili sono state fatte cercando di vedere
dal lato tecnico i netstrike, senza contare che il concetto di "portfucking"?
lo leggo dalla prima volta che ho scaricato un file da internet ...

> Con Igor Falcomata abbiamo avuto uno scambio di 2/3 email piene
> di considerazioni e talune volte di idee. L'utilizzo dei
> RST da parte di firewall che forniscono una sorta di
> protezione ad attacchi di tipo Syn Flood ? una implementazione
> di cui gi? eravamo a conoscenza e che
> comunque Igor ha tenuto a puntualizzare.
c'e` da dire che... l'invio di RST al client da parte di un programma
che gira sul client e` l'esempio dell'ennesima volta che si cerca di 
superare con un escamotage una protezione "clinet side". avevo detto in un
messaggio sul thread avvenuto su devel@ riguardo la saturazione dei backlog
della listen() (mh cioe`, spero d'averlo detto :) che un test molto simile
l'avevo fatto con un programma che apriva connessioni e quando riceveva
l'errore "Too many file descriptor" (1024 di default) forkava se stesso
in modo da aprire un altro processo (con ancora 1024 possibili file
descriptor da occupare)

la differenza sta appunto nel modo in cui la mia macchina veniva stressata,
prezzo che pago volentieri visto che faceva tutto in una pagina di codice :)
(che purtroppo non trovo + cmq si capisce che e` semplice scrivelo)

> C'? stato chi ha paragonato ci? che definiamo SAOR
> Attack con un Naptha DoS; nei naptha DoS non ci pare si
> utilizzino dei RST, gli stessi si basano pi? che altro
> sulla creazione di connessioni fantasma sfruttando l'ARP
> poisoning in ambienti switchati. L'attacco che proponevamo
> era un tantino diverso...pi? rintracciabile sicuramente ma
> differente dai naptha DoS. 
si il naptha porta attacchi differenti (il piu` interessante e` quello
sul LAST_ACK imho)

> scut dice che se qualcuno ha la possibilit? di spoofare un indirizzo
> IP e di forgiare pacchetti a piacimento significa che ha
> i privilegi di superuser sulla macchina, quindi
> "you should also have control over the kernel tables and could
> take out the entry." 
su questo non c'e` dubbio, l'utilizzo dei RST e` solo un pagliativo per 
superare un problema "client side" come l'uso della fork() e come si
potrebbe fare con iptables... pensa a fare un sw che invii un SYN, legga
in SYN ACK, risponda con l'ACK. il tuo kernel si metterebbe di mezzo 
appena ricevuto il SYN ACK rispondendo con un RST, tu metti una rules di
iptables che droppi tutti i pacchetti con RST in uscita ed otterrai lo
stesso risultato.

(andare a toccare la file descriptor table in kernel space, secondo me,
e` uno spreco)

> Cosa ne pensate? Se qualcuno avesse idee, codice, parolacce
> cortesemente (o meno) notificatacele. Grazie 
l'idea suggerita da antirez, quella di monitorare gli stati delle connessioni
a layer 5 per decidere quale uccidere puo' essere una soluzione cmq.

senza contare che attacchi di questo genere possono funzionare perche`
nessun sistema ha una limitazione sul "numero di connessioni possibili
provenienti da un ip".
paradossalmente, grazie a fastweb e ad altre reti che fan uscire in NAT,
attacchi come questi e come i nestrike possono ancora funzionare :)

ciao,
vecna

P.S. scusate x la mancata risposta alla vostra email, pensavo ne aveste avute
gia` abbastanza :)

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