Comments for post Attacco al server web di antirez.com

mordha writes: ip inserito lista aggiornamento server ramaloopster o simili.
Navigatore Anonimo writes: Mi correggo : http://ipp2p.org/ non è una patch ma un modulo per iptables ;-) ... non c'è da patchare il kernel ;-) ... bastano i sorgenti di iptables ... in effetti la soluzione B potrebbe difendere anche da altri attacchi di questo tipo indipendentemente dal sistema o dal programma usato ... il tutto deve comunque entrare a regime , ci sarà un picco sul server che andrà scemando man mano che il filtro aggiunge gli IP ad iptables ... tuttavia una soluzione che "banni" il traffico p2p in anticipo , cioè prima che raggiunga il server sarebbe la soluzione ottimale
boverix writes: stesso problema... 4-8 connessioni da 200mila ip differenti... installato kernel patchato L7 (l7-filter.sourceforge.net) e intercettato tutti i "$MyNick". Riduce quello che passa, ma almeno riconosce che sono pacchetti DC++. Adesso provo a configurare fail2ban per droppare gli ip qualche ora (di notte si riducono notevolmente, probabile che tanti client DC++ spengono il pc). non è la soluzione, ma almeno apache resta su... (PS kernel patchato non da me che sono una pippa con il .config del kernel...)
antirez writes: @Navigatore Anonimo: spiegazione perfetta, solo che IMHO mod_security non aiuta, una volta che sei arrivato al web server e' troppo tardi. Alla fine cio' che mi ha salvato e' stato il firewalling, perche' come traffico 380 pacchetti al secondo (il picco a cui siamo arrivati) anche se e' tanto e' sostenibile se si tratta solo di SYN TCP e non permetti di completare la three way handshake. Dunque penso che monitorare le richieste e segnare gli IP sorgente di ognuna e bloccare tramite iptables gli IP che effettuano troppe richieste sia una soluzione. Anche se ha funzionato molto meglio nella mia esperienza la soluzione "B", ovvero guardare quali client andavano in timeout (perche' non sanno parlare davvero il protocollo HTTP!) per filtrarli. Grazie del commento :)
Navigatore Anonimo writes: in sostanza (IMHO) l'attacco può essere portato se si ha già il controllo di uno o più hub : in quel caso lo status di operatore dovrebbe garantire la possibilità di aggiungere altri hubs ; ciò che ha fatto questo "operatore" è inserire antirez.com nella lista degli hubs di dc++ con la conseguenza che i client collegati al suo/ ai suoi hub(s) hanno iniziato a inoltrare richieste verso antirez.com : le versioni precedenti del client non è che siano buggati nel senso stretto della parola ; semplicemente "credono" che ogni hub nella lista sia valido e quindi continuano a inoltrare le richieste. Ciò che la nuova versione del client ha introdotto è un limite ai tentativi di connessione verso un hub che risponde "picche" : in sostanza dopo un tot di tentativi non andati a buon fine (rifiuto di connessione da parte dell'hub) , il client lo esclude dagli hubs validi e non tenta più di connettersi. Su emule ad esempio questo limite è di tre tentativi. Tuttavia finchè tutti i client della rete dc++ non sono aggiornati , il problema potrebbe ripresentarsi per via delle stesso o di un altro "mattacchione" di turno. C'è una patch per iptables specifica per questo tipo di problemi : http://ipp2p.org/ ... oppure potresti vagliare la possibilità di usare mod_security http://www.modsecurity.org/ che è un modulo per apache capace di filtrare il traffico a livello HTTP , capace cioè di risolvere questo e ben altri problemi ;-) Ciao e buon lavoro ;-)
antirez writes: @Navigatore Anonimo: si... e' esattamente l'attacco che ho ricevuto io. Dunque e' relativo ad un bug dei client, e basta avere il controllo di uno o piu' hub per eseguire l'attacco. A quanto pare le ultime versioni del client DC++ sono state corrette.
Navigatore Anonimo writes: sembra che antirez.com sia in buona compagnia : http://news.netcraft.com/archives/2007/05/23/p2p_networks_hijacked_for_ddos_attacks.html
michele writes: Questo ti piacera' di sicuro noi lo usiamo per blacklistare chi fa troppe query contemporanee sui DNS, ma va bene per qualsiasi protocollo/porta: http://www.digitalgenesis.com/software/phrel/
Mdx writes: Una curiosità, come mai hai deciso di fare gli script in tcl piuttosto che perl o altro? Il tcl è un linguaggio più "leggero"?
al0ha writes: Antir, io ho avuto a che fare molto da vicino con la rete direct connect un paio di anni fa. L'attacco che hai ricevuto sembra un attacco di IP Spoofing e veniva utilizzato per impedire l'accesso agli hub (una specie di canali irc per chi non li conoscesse). In particolare si utilizzavano dei software nei quali si indicavano solitamente IP server vittima e numero di porta, dopo aver deciso questo si collegavano a diversi hub su direct connect e una volta collegati a questi ricevevano la lista degli utenti (migliaia) utilizzandoli per fare richieste contemporanee al server vittima come se ogni utente dell'hub avesse effettuato la richiesta inondando proprio il server vittima e provocando un denial of service. Spero di esserti stato d'aiuto antir.
Navigatore Anonimo writes: mi chiederei se sei convinto che sia stato UN attacker : la rete dc++ , a differenza di emule, mi pare non si appoggi ad un server : funziona come la rete kad in emule o come skype , appoggiandosi ai nodi con più risorse e che sono da più tempo online (hubs) ... se si ipotizzasse invece che "qualcuno" su cui passa molto di quel traffico abbia un filtro a livello applicazione che sia in grado di individuare il traffico dc++ e che abbia impostato una regola che redirige questo traffico che passa su quel tratto di rete direttamente sul tuo IP ???
dat writes: a me è successa la stessa cosa ma col pc di casa, insomma, ho un cessoso 56k, mi collego e vedo il traffico a palla, colpa di bittorrent e di chi usava l'ip prima di me. col consiglio di qualche amico mi è bastato sconnettermi e riconnettermi per sistemare la questione ma non credo funzioni su un server ;)
antirez writes: @riffraff: dimenticavo, malvaggi non era un refuso, sbaglio totalmente le doppie quando scrivo di fretta ;) Grazie per la segnalazione.
antirez writes: @riffraff: grazie per la dritta, infatti dopo avevo visto sul manuale ma non potevo usare tale feature :( Ecco cosa accade: poiche' il server e' carico i client arrivano giusto a fare la three way handshake TCP, solo pochissimi di loro riescono davvero a spedire pezzi del protocollo, la maggior parte vanno in timeout prima. Filtrando queste connessioni tramite il firewall avrei eliminato una percentuale insignificante di client. Alla fine la soluzione vera e' venuta dall'error.log che mi permette di vedere la lista degli IP di connessioni che vanno in timeout. Filtrando quelle che superano un tot di tentativi di connessione che hanno come effetto un timeout sembra funzionare bene. Anche se stanno continuando :-\ Grazie per il commento.
riffraff writes: afair iptables supporta il filtering stateful e il matching di stringhe, una cosa tipo -m string --string "EXTENDEDPROTOCOL". Immagino dovrai combinarlo con una regola che matchi altro altrimenti uno che ha cercato questo problema su google non può accedere :) Cmq fico :D (ah, refuso in "malvagi")
antirez writes: Ho trovato un nuovo modo per filtrare gli IP cattivi, infatti in access.log di apache globale, che non e' collegato ad alcun virtual domain configurato sulla macchina si legge: 87.10.17.252 - - [21/May/2007:14:53:02 +0200] "-" 408 - "-" "-" 87.10.17.252 - - [21/May/2007:14:53:03 +0200] "-" 408 - "-" "-" 87.10.17.252 - - [21/May/2007:14:53:03 +0200] "-" 408 - "-" "-" 62.195.165.78 - - [21/May/2007:14:53:11 +0200] "-" 408 - "-" "-" 62.195.165.78 - - [21/May/2007:14:53:12 +0200] "-" 408 - "-" "-" 62.195.165.78 - - [21/May/2007:14:53:13 +0200] "-" 408 - "-" "-" E cosi' via... in pratica si vedono gli IP delle richieste che vanno in timeout per un dominio che non esiste. Questi sono esattamente tutti i client che io vorrei filtrare. Modifichero' dunque lo script in Tcl per leggere gli IP da quel file e aggiungere le regole per filtrare tali IP se vedo che la macchina ricomincia a soffrire. Se funziona tutto mi piace molto di piu' riuscire a resistere all'attacco grazie al bilanciamento dei parametri. Mi sembra piu' una soluzione "di sistema" :)
antirez writes: @davidonzo: buona idea, la macchina e' in housing da Aruba, potremmo chiedere a quest'ultima se altri loro clienti hanno avuto simili problemi. Sarebbe abbastanza allucinante se ci avessero attaccati in prima persona. Comunque maxclients 500 + timeout 5 + filtering degli IP nuovi di tanto in tanto sembra abbia recuperato la situazione per ora. Spero che la smettano presto.
davidonzo writes: Avevo notato il down stamane. La prima cosa sarebbe chiedere all'intestatario dell'IP cui fa capo la tua macchina, se ha subito (o sta subendo) altri attacchi simili.
home