Newsgroup: it.comp.sicurezza.varie
Titolo: Nukkato? Come faccio [LUNGO]

sempre vulnerabile a questo genere di attacchi.
scusate ma sembra esserci un lato che sfugge a molti. Il concetto di flood e'
quanto di piu' lontano nella rete da quello di nuke. Ceto, un flood ci
puo' 'nukare' ma non nella stessa maniera. Ci impedisce di accedere ad altri
pacchetti/connessioni/dati. Ad esempio se io invio una stratosferica mole
di tentativi di connessione TCP o di echo_request con ICMP. MA ANCHE CON MOLTI
ALTRI TIPI: broadcast reply, pipe chargen/echo, flag U con puntatori ad altre
flag U ... etc etc.
Lo scopo e' INTASARE il mio canale di trasmissione per impedirgli di poterne
gestire altre.
Detto questo, se installo un firewall, questo risiede per forza di cose a valle
del mio modem :) e quindi lo stesso i pacchetti li ricevo, anche se decido di
non onorarli; questo xche' il mio firewall non interrompe a livello di gateway
tutti i pacchetti del flood. Questo puo' farlo solo il mio ISP.
Quindi se ne puo' dedurre che si possa intasare il firewall o semplicemente il
modem (meglio dire la sua banda) in modo da NON FARMI GESTIRE PIU' NIENT'ALTRO.
A questo puntano gli attacchi ICMP. Se sono su un 33.6 e vengo floodato da
varie T3 (come di solito accade) allora stiamo freschi .... e provare un
netstat -a (senza la n) ci fa solo piu' male :)))
A mio avviso una buona protezione consiste nel richiedere all'ISP un proxy
per IRC (ovviamente loggato) e che abbia un sistema di filtraggio/segmentazione
della banda per ovviare a simili attacchi (la soluzione adottata da molti ISP
di non onorare i msg ICMP di tipo echo a livello router e' solo un escamotage
e non un hack. Anche se funzionale :)))
invy

in...@fw.net
 wrote:
 >Quindi se ne puo' dedurre che si possa intasare il firewall o semplicemente il
 >modem (meglio dire la sua banda) in modo da NON FARMI GESTIRE PIU' NIENT'ALTRO.
Una soluzione interessante consiste nell'usare dai due lati linux 2.1.x
con ipchains e delle politiche di queuing che privilegino determinate
categorie di traffico. Ma se si ha il controllo del modem remoto allora
di solito ci si puo` risparmiare la fatica di fare questo e mandare
direttamente nel black hole tutto il traffico superfluo. Oppure usare
l'IP masquerading sul remoto e non farsi vedere per niente.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 l'IP masquerading sul remoto e non farsi vedere per niente.
Il cuore del problema infatti e' quello quando si tratta di attacchi
DoS a saturazione di banda, salvo casi particolari come lo Smurf alla
fine (supponendo che attaccante e attaccato conoscano "tutti i trucchi")
'vince' chi ha piu' banda disponibile, dove 'banda disponibile' e' quella
della macchina "piu' esterna" che controlli tu (sia essa il firewall,
il POP del tuo provider, il tuo modem o qualsiasi altra cosa...).
Se ricordi in passato avevo gia' affrontato il problema lanciando
un sassolino nello stagno con la proposta "perche' non mettiamo
giu' un protocollo di comunicazione firewall-firewall, lo 
istituzionalizziamo come standard e cerchiamo di tirarci dietro 
un po' di provider e soprattutto di backbone ?".
Se si riuscisse a fare qualcosa del genere potremmo avere una situazione
simile alla seguente:
- Io mi metto su il mio bel firewallino dietro al modem, ovviamente se
  qualcuno tenta di attaccarmi fa molto in fretta a saturarmi la banda 
  del modem, allora il mio firewallino passa una segnalazione in cascata
  al suo "papa'" che sta sul POP del provider "per favore fermami il traffico
  da X.Y.Z.N che non ne posso piu'".
- Il firewall che sta sul pop vedendo che sono un suo cliente e che
  ho tutto il diritto di non ricevere piu' il traffico per ME da X.Y.Z.N
  .... lo ferma lui fino a nuovo ordine, se anche la SUA banda di uplink 
  inizia ad avere problemi fa lo stesso con il border gateway del provider,
  il quale trovando la richiesta lecita ferma il traffico al di fuori
  della rete del mio provider.
- Se anche il border gateway non je la fa piu'... passa la richiesta ai
  router del provider attaccante.... se questi non collaborano... la passa
  ai router del backbone che li interconnette, evenualmente mettendo
  di fatto in blackhole temporaneo tutto il provider attaccante.
Se si riuscisse a mettere insiee un protocollo standard e abbastanza 
sicuro e flessibile, a tirarsi dietro i produttori di router e firewall,
a tirarsi dietro qualche backbone e di conseguenza la maggioranza dei
rpvoder allora sarebbe "la soluzione" per fermare gli attacchi a saturazione
di banda "all'origine".
Ok... sono un sognatore :P
Ciao,
-- 
Andrea

direttamente nel black hole tutto il traffico superfluo. Oppure usare
yeah, a qualcosa di simile pensavo. Tieni da conto pero' che questo non
esaurisce DA SOLO il problema della banda sotto attacco. Se l'attaccante e'
in grado di floodare il gateway dell'ISP allora siam fatti ...
Bisognerebbe portare a monte il blocco, filtraggio ... etc etc etc
invy

Ok... sono un sognatore :P
no no :) magari un idealista pero' si :)
invy

nu...@tin.it
 wrote:
 >Se ricordi in passato avevo gia' affrontato il problema lanciando
 >un sassolino nello stagno con la proposta "perche' non mettiamo
 >giu' un protocollo di comunicazione firewall-firewall, lo 
Perche` no? Ci sono altri interessati? Devo aprire una mailing list?
In teoria l'implementazione mi sembra facile, basta un demone che
riceve e verifica il mittente delle richieste e poi esegua ipchains o
l'equivalente dei *BSD.
Visto che e` improbabile che Cisco aggiunga le feature in IOS si
potrebbe comandare il router tramite rsh o simili.
Si potrebbe dividere il programma in un frontend che generi i filtri e
una serie di backend che le convertano nei comandi.
 >- Il firewall che sta sul pop vedendo che sono un suo cliente e che
 >  ho tutto il diritto di non ricevere piu' il traffico per ME da X.Y.Z.N
 >  .... lo ferma lui fino a nuovo ordine, se anche la SUA banda di uplink 
Problema: non e` scalabile. Se inizi a infilare access-list in un router
questo rallenta. Non so quanto il fast-blackole dei IOS piu` recenti
aiuti ma in fondo non sono un esperto di cisco.
Pero` mi sembra che questo sistema sia facilmente usabile per fare un
DoS contro una terza vittima: se A manda a B pacchetti che sembrano
provenire da C allora B ignorera` anche il traffico legittimo che arriva
dall'host C.


in...@nuke.it
 wrote:
 >nel nuovo protocollo: come posso comunicare al fw a monte che sono floodato, se
 >lo sono davvero ed in maniera efficace ?
UDP, evitando gli ACK.


 segmentare la numerica in modo da lasciare un canale SEMPRE libero da
traffico.
Dipende da come viene implementato il protocollo di firewall cooperation:
da un lato un flood (a meno che il tuo OS non sia cosi' cretino da rispondere)
puo' saturare la banda solo in UNA direzione (dall'attaccante verso di te),
dall'altro la "comunicazione di servizio" della serie "zittiscimi sto cretino"
deve avvenire nella direzione opposta.
Certo se si facesse con TCP non funzionerebbe perche' e' necessario un flusso
bidirezionale per istituire la comunicazione, ma con un UDP autenticato con RSA
(tanto per buttare giu' un'idea) o semplicemente un UDP secco visto che alla fin
fine il firewall "upstream" e' in grado di sapere da che parte viene il
pacchetto
(e quindi di sapere che non e' spoofed, salo casi molto particolari) il discorso
cambia.
Ad esempio se la cosa fosse supportata a livello di access server, nel caso
specifico del modem, il problema non si pone nemmeno (l'access server puo' ben
credere che cio' che arriva dal modem viene dal mio IP e non e' spoofed).
Al piu' si potrebbe gestire il tutto con le classiche priorita' di traffico
del routing, da esempio utilizzando un "IP protocol" specifico e dandogli una
priorita' superiore a qualsiasi altra cosa.
Ciao,
-- 
Andrea

 
Gia' risposi.. o ti sei risposto da solo ? o ho dato per scontata la
risposta ?
La premessa e':
1) Il nostro giocattolo esiste in una realta' "mediamente firewallata",
   in cui almeno i pacchetti devono venire dalla direzione giusta, per
   i casi piu' comuni questa e' una garanzia sufficiente (l'access server
   a cui sono connesso via modem accetta i comandi SOLO dal modem
   stesso che protegge, e se vengono di li i pacchetti non sono certo
   spoofed...), i border-gateway accettano comandi solo dagli access
   router dello stesso provider.. e si suppone che un indirizzo spoofed 
   come mittente venga fermato (dai border gateway o dagli access server).
La continuazione e':
2) Nei casi piu' complessi (in cui un pachetto router-router o 
   firewall-firewall potrebbe essere spoofed da qualcuno, ma qui abbiamo
   un range molto ristretto di macchine autorizzate da comunicare una "regola"
   a "questo" firewall, l'unico caso in cui il protocollo deve essere molto
   aperto e' per il caso dialup-modem-access-server, dove lo spoofing
   e' rigorosamente impossibile) si passa a una autenticazione RSA...
Salut,
[per il resto: fino a dopo natale sono nella deep shit per un insieme
 di cose, ho 46 patch da ritoccare e postare per ircu e poi da finire
 la documentazione dell'algoritmo di compressione che ho progettato e
 che sto pubblicando e dell'enchanched TCP di cui vorrei proporre una 
 RFC... dopo il 10 gennaio o giu' di li sono tutto tuo per sta cosa e 
 eventualmente per il robot-cerca-crosspost nei newsgroup....]
-- 
Andrea

nu...@tin.it
 wrote:
 >> Pero` mi sembra che questo sistema sia facilmente usabile per fare un
 >> DoS contro una terza vittima: se A manda a B pacchetti che sembrano
 >> provenire da C allora B ignorera` anche il traffico legittimo che arriva
 >> dall'host C.
 >1) Il nostro giocattolo esiste in una realta' "mediamente firewallata",
 >   in cui almeno i pacchetti devono venire dalla direzione giusta, per
 >   i casi piu' comuni questa e' una garanzia sufficiente (l'access server
 >   a cui sono connesso via modem accetta i comandi SOLO dal modem
 >   stesso che protegge, e se vengono di li i pacchetti non sono certo
No, mi riferisco a una cosa diversa. A fa un flooding a B usando come
mittente l'IP di C. A questo punto B blocchera` C senza poter sapere che
in realta` il colpevole e` A.
