DDoS aanval: helpt rapporteren?

[Olaf van der Spek]

Een van mijn servers heeft momenteel last van een Distributed Denial of Service aanval van 3 mbyte/s. De server is een lobby server voor Red Alert 2 en andere games. Het lijkt erop dat de aanvaller een TCP verbinding opent, wat troep stuurt en dan weer afsluit. De aanval lijkt echter niet te slagen, want de server is nog goed bereikbaar. Het OS is Debian.
Nu vroeg ik mij af, heeft het zin uit te zoeken vanaf welke IP adressen de aanval komt (het zijn er volgens mij heel wat) en de aanval dan aan die ISPs te rapporteren?

En kent iemand toevallig handige tools hiervoor om een rapport te maken van de verkeersgegevens zodat ik niet handmatig alles bij elkaar hoef te zoeken?

[MrDummy]

Zoals je weet wordt Ddos aanval gedaan met behulp van tientallen gekaapte computers, die als slaves worden gebruikt.

Op server moet je script hebben die automatisch TCP/IP dump file maakt bij verdachte bandbreedte begint te draaien. Dan kan je zien welke ip adressen het is.
Probleem is dat attacker niet dom bezig is om ook zelf ddos te gooien naar je server, en doet dus op remote via gekaapte computers. De ip van de dader zelf krijg je dus niet meteen te zien in logs. Je moet dus in de gekaapte computers (de ip's in de tcp-ip log) kijken naar de logs. Via-via zeg maar. Vervolgens moet je al die ipadressen vergelijken van gekaapte computers logs en dan kun je match vinden: 1 ip die in alle computers voorkomt, misschien wel meerdere keren (voorbereiden op ddos dus).
Met gevonden aantal ips en logs als bewijs kun je misschien naar provider sturen van die persoon. Die kan de politie inschakelen vanwege strafbare DDos aanval.
Je hebt dus alle logs nodig, vooral van gekaapte computers om dader te kunnen vinden.
Alleen de log van je server kom je dus nog niet uit. Het zijn ip's van onschuldige gekaapte computers die je alleen maar eigenaar kunt waarschuwen dat hun computer open staat.....

Een goede attacker maakt echter liefst met dynamische ip's, om sporen weg te houden, of via tunnel, of via proxy. Zo min mogelijk sporen. Desnoods gewoon met de computer in de bibliotheek. Dus niet thuis achter de pc.

[Verwijderd]

Rapporteren heeft doorgaans (ik spreek uit ervaring) niet tot nauwelijks effect. De meeste providers kijken amper naar hun abuse@ aliasje, ten eerste vanwege het feit dat 90% van de mails komt van mensen die niet weten waar ze het over hebben (cq. een "personal firewall" ziet een ICMP pakketje komen van een router, markeert dit als "bad traffic" en de eigenaar gaat helemaal over de rooie), spam en andere troep, en ten tweede is het vaak onmogelijk (of te laat) om iets te kunnen doen mocht het wél een legitiem rapport zijn. Tiscali is verschrikkelijk slecht met abuse, alsmede T-Online (Duitsland) en RimaTDE (Spanje)... bij Rima kreeg ik zelfs een bounce. Lekker abuse-department dus

Lekker laten gaan dus (of je moet écht willen) en die IP's blokkeren is mijn advies.

Oja, antwoord op je tweede vraag: Snort i.c.m. ACID.

[ Voor 11% gewijzigd door Verwijderd op 09-10-2005 19:43 ]

[Olaf van der Spek]

De aanval is nu al 32 uur bezig en als die nog (veel) langer door gaat heeft het misschien wel zin wat ISPs te benaderen.
Gastheren van trojans moeten zich toch ook eens afvragen waarom hun internetverbinding zo langzaam is.

[ Voor 36% gewijzigd door Olaf van der Spek op 09-10-2005 21:02 ]

[Tys]

OlafvdSpek schreef op zondag 09 oktober 2005 @ 21:01:
De aanval is nu al 32 uur bezig en als die nog (veel) langer door gaat heeft het misschien wel zin wat ISPs te benaderen.
Gastheren van trojans moeten zich toch ook eens afvragen waarom hun internetverbinding zo langzaam is.

Tegenwoordig zijn verbindingen zo snel, die mbit extra per connectie voor een trojan merkt geen hond meer op ...

Overigens helpen mailtjes (telefoon anyone?) met logs naar een abuse@ adres wel degelijk.

[ Voor 3% gewijzigd door Tys op 09-10-2005 21:06 ]

[Stewie!]

Waarom filter je niet het traffic dat verzonden wordt door de aanvaller, desnoods zijn hele range. Op welke poorten krijg je het verkeer?

Kan jouw netwerkprovider niks betekenen dmv filtering?

[ Voor 47% gewijzigd door Stewie! op 09-10-2005 21:12 ]

[Olaf van der Spek]

Thiaz schreef op zondag 09 oktober 2005 @ 21:04:
Tegenwoordig zijn verbindingen zo snel, die mbit extra per connectie voor een trojan merkt geen hond meer op ...

Menig consument heeft geen upstream > 1 mbit/s.

[Stewie!]

OlafvdSpek schreef op zondag 09 oktober 2005 @ 21:16:
[...]

Menig consument heeft geen upstream > 1 mbit/s.

En om detectie zoveel mogelijk te voorkomen gebruiken deze programma's ook nooit het maximale aan bandbreedte

[Olaf van der Spek]

DaMorpheus schreef op zondag 09 oktober 2005 @ 21:11:
Waarom filter je niet het traffic dat verzonden wordt door de aanvaller, desnoods zijn hele range. Op welke poorten krijg je het verkeer?

Kan jouw netwerkprovider niks betekenen dmv filtering?

Het is een distributed attack, dus er zijn meerdere aanvallers/bots. Ik kan wel proberen het verkeer te filteren, maar dan moet ik eerst de bron adressen hebben en die heb ik nog niet. De port is van de lobby server (400x).

[Erkens]

DaMorpheus schreef op zondag 09 oktober 2005 @ 21:11:
Waarom filter je niet het traffic dat verzonden wordt door de aanvaller, desnoods zijn hele range. Op welke poorten krijg je het verkeer?

zelf filteren is lastig, want het verkeer komt toch nog jouw kant op waarvoor je dus nog steeds mag betalen

Kan jouw netwerkprovider niks betekenen dmv filtering?

Die zou (tijdelijk) de routes naar je server kunnen weghalen zodat de packets niet meer weten waar ze naar toe moeten. Dit is dus de enige partij die het kan filteren. Een beetje provider doet dit wel voor je

[Olaf van der Spek]

Erkens schreef op zondag 09 oktober 2005 @ 21:20:
Die zou (tijdelijk) de routes naar je server kunnen weghalen zodat de packets niet meer weten waar ze naar toe moeten. Dit is dus de enige partij die het kan filteren. Een beetje provider doet dit wel voor je

Maar die router kent het verschil niet tussen goede en 'foute' packets.

[H!GHGuY]

Wij hebben een tijd geleden ook een MSSQL aanval gehad (poort 1433).
Ik heb toen de poort geblockt en de IP's (die in de log kwamen) genoteerd.

Daarna heb ik reverse-DNS toegepast en emails gezonden naar de desbetreffende abuse@ adressen.
1 van de 2 was behulpzaam en heeft de server van een klant van hem laten resetten waardoor deze stopte. De andere (van een Amerikaanse universiteit) heb ik nooit iets van gehoord, zelfs niet nadat ik wat dreigende taal naar hen gooide.

persoonlijk kan ik dus zeggen: 50% kans

[Stewie!]

Erkens schreef op zondag 09 oktober 2005 @ 21:20:
[...]

zelf filteren is lastig, want het verkeer komt toch nog jouw kant op waarvoor je dus nog steeds mag betalen

Veel partijen bieden al het inkomend verkeer kosteloos

[...]

Die zou (tijdelijk) de routes naar je server kunnen weghalen zodat de packets niet meer weten waar ze naar toe moeten. Dit is dus de enige partij die het kan filteren. Een beetje provider doet dit wel voor je

Niet de routes filteren, dan ben je de lul omdat de rest die over die routes ging je niet meer kan bereiken. Goede oplossing is gewoon de ddos zelf filteren op de eigen routers danwel op die van de uplink providers van de provider

[mvdejong]

Soms helpt het echt goed, zeker als de "schuldige" in de States zit.
Een paar jaar geleden werd ik elke dag om dezelfde tijd (wat overeenkwam met het begin van de werkdag in een tijdzone in de States) getracteerd op wat virussen van dezelfde PC binnen een vrij fors bedrijf.

Ik kon zelf het e-mail adres van de gebruikster achterhalen, en ik heb haar een paar keer een mailtje gestuurd met het verzoek haar PC door de systeembeheer-afdeling te laten opkuisen. Geen reactie, geen effect.

Toen naar postmaster@ en webmaster@ van dat bedrijf gestuurd. Een paar dagen later een mailtje gekregen dat de betreffende dame een fors aantal interne regels had overtreden (zaken als rommelen met de virus-scanner, meer prive dan zakelijke e-mail doen), en dat de juiste maatregelen waren getroffen. Voor degenen die niet weten hoe ze in de States reageren op overtredingen van het veiligheidsbeleid binnen een bedrijf : de dame werd onmiddelijk door de bewaking het pand uitgebracht. Trouwens, dat werkt bij sommige bedrijven in Nederland ook zo, ik ken een paar incidenten van een eerdere detacherings-klus.

[Olaf van der Spek]

DaMorpheus schreef op zondag 09 oktober 2005 @ 21:28:
Niet de routes filteren, dan ben je de lul omdat de rest die over die routes ging je niet meer kan bereiken. Goede oplossing is gewoon de ddos zelf filteren op de eigen routers danwel op die van de uplink providers van de provider

Maar zijn routers daar tegenwoordig snel genoeg voor?
Ik weet dat Cistron ongeveer een jaar geleden een 100+ mbit/s attack moest filteren (naar een IP adres) en daar was de router (eigenlijk) niet snel genoeg voor.

[Erkens]

DaMorpheus schreef op zondag 09 oktober 2005 @ 21:28:
Veel partijen bieden al het inkomend verkeer kosteloos

Dataverkeer is dataverkeer, iemand moet het betalen

Niet de routes filteren, dan ben je de lul omdat de rest die over die routes ging je niet meer kan bereiken. Goede oplossing is gewoon de ddos zelf filteren op de eigen routers danwel op die van de uplink providers van de provider

natuurlijk ben je dan de lul omdat het goede verkeer er niet doorkan, maar soms heb je geen keus en is dat de snelste en goedkoopste manier om het probleem op te lossen. Al dat verkeer kost handen vol geld.

[Verwijderd]

Ik zou zorgen dat ik een redelijk compleet beeld kreeg van de gebruikte IP's (d.m.v. wat ik al zei [Snort+ACID] of een andere methode die je zelf prefereert) en vervolgens gaan filteren. Dit is even wat werk, maar je kijkt in ieder geval niet machteloos toe. Afhangende van wat voor DDoS dit is kan het wel of geen effect hebben, maar afgaande op wat je zei gaat dit volgens mij wel werken.

Ik weet ook niet hoe moeilijk je machine het heeft op dit moment, maar als 'ie door z'n knieën dreigt te gaan (cq. wel héél erg traag wordt ) zou ik alles blokkeren behalve je verbinding thuis en eens rustig gaan uitzoeken wat er gebeurd is en door welke nodes. Vervolgens kan je abuse@ gaan mailen, niet geschoten is altijd mis. Overigens zou ik niet gaan bellen naar abuse afdelingen, ze willen toch logfiles van je hebben en 9 van de 10 keer kom je gewoon bij de reguliere eerstelijns helpdesk uit die je óf doorverwijst naar abuse@ of je escaleert. Een aantal escalaties verder krijg je dan eindelijk een techneut aan de lijn die je op zijn beurt toch weer lekker doorverwijst naar abuse@. Mailen lijkt me dus het slimst.

[ Voor 23% gewijzigd door Verwijderd op 09-10-2005 22:34 ]

[Olaf van der Spek]

Verwijderd schreef op zondag 09 oktober 2005 @ 22:26:
Ik weet ook niet hoe moeilijk je machine het heeft op dit moment, maar als 'ie door z'n knieën dreigt te gaan (cq. wel héél erg traag wordt ) zou ik alles blokkeren behalve je verbinding thuis en eens rustig gaan uitzoeken wat er gebeurd is en door welke nodes.

100% CPU, maar aangezien de lobby server zelf weinig CPU en netwerk nodig heeft lijkt de service er zelf nauwelijks onder te leiden.
Ik wijzig de lobby server zelf morgen waarschijnlijk zodat een IP adres dat meer dan 60 connects/minuut doet automatisch direct weer gedropped wordt na de connect.

[Freee!!]

OlafvdSpek schreef op zondag 09 oktober 2005 @ 22:44:
[...]
100% CPU, maar aangezien de lobby server zelf weinig CPU en netwerk nodig heeft lijkt de service er zelf nauwelijks onder te leiden.
Ik wijzig de lobby server zelf morgen waarschijnlijk zodat een IP adres dat meer dan 60 connects/minuut doet automatisch direct weer gedropped wordt na de connect.

Hoezo droppen na de connect Als je het voor elkaar kan krijgen om geen "ACK" te versturen na ontvangst van de "SYN", komt de connect al helemaal niet tot stand en komen aan de andere kant allerlei leuke foutmeldingen als "Connection to ... timed out".

[Victor]

OlafvdSpek schreef op zondag 09 oktober 2005 @ 21:35:
[...]

Maar zijn routers daar tegenwoordig snel genoeg voor?
Ik weet dat Cistron ongeveer een jaar geleden een 100+ mbit/s attack moest filteren (naar een IP adres) en daar was de router (eigenlijk) niet snel genoeg voor.

Een beetje serieuze router (denk bijv. M160 van Juniper) maakt gehakt die van paar megabytes. Zodra duidelijk is waar de aanval vandaan komt is dat redelijk snel te filteren. Ik zou in het geval van de TS gewoon eens contact opnemen met de netwerkbeheerder van zijn hostprovider.

[Olaf van der Spek]

Mr. Liu schreef op zondag 09 oktober 2005 @ 22:53:
Hoezo droppen na de connect Als je het voor elkaar kan krijgen om geen "ACK" te versturen na ontvangst van de "SYN", komt de connect al helemaal niet tot stand en komen aan de andere kant allerlei leuke foutmeldingen als "Connection to ... timed out".

Dat is inderdaad veel slimmer, alleen niet op applicatie niveau te doen.
Maar ik ga dat zeker implementeren.

[Olaf van der Spek]

Erkens schreef op zondag 09 oktober 2005 @ 22:15:
Dataverkeer is dataverkeer, iemand moet het betalen

Maar dataverkeer (gebruikt) is in principe gratis. Capaciteit (beschikbare bandbreedte) kost geld.
En normaal gebruiken servers veel meer up dan down terwijl een DoS juist (vaak) veel down gebruikt, dus zo onlogisch is het niet.

[Erkens]

OlafvdSpek schreef op maandag 10 oktober 2005 @ 11:21:
[...]

Maar dataverkeer (gebruikt) is in principe gratis. Capaciteit (beschikbare bandbreedte) kost geld.
En normaal gebruiken servers veel meer up dan down terwijl een DoS juist (vaak) veel down gebruikt, dus zo onlogisch is het niet.

Dus voor jou maakt het niks uit een DDoS meer of minder, dat dataverkeer wat het genereerd is toch "gratis"
Mag ik bij jou mijn server parkeren

Jij snapt blijkbaar niet dat dat dataverkeer juist bandbreedte in beslag neemt (goh hoe komen anders al die bitjes bij je server) waardoor het dus _niet_ gratis is.

[Stewie!]

Erkens schreef op maandag 10 oktober 2005 @ 11:29:
[...]

Dus voor jou maakt het niks uit een DDoS meer of minder, dat dataverkeer wat het genereerd is toch "gratis"
Mag ik bij jou mijn server parkeren

Jij snapt blijkbaar niet dat dat dataverkeer juist bandbreedte in beslag neemt (goh hoe komen anders al die bitjes bij je server) waardoor het dus _niet_ gratis is.

Jep, maar doordat het wegvalt tussen het uitgaande verkeer heb je dus binnenkomend verkeer eigenlijk zonder extra kosten.
Maar toch zou ik een ddos altijd rapporteren, ik heb echter het idee dat dit niet echt een ddos is ("Het lijkt erop dat de aanvaller een TCP verbinding opent, wat troep stuurt en dan weer afsluit."). En waarom grijpt jou provider niet zelf in?

[Erkens]

Natuurlijk valt het niet weg tussen het uitgaande verkeer, immers op het moment dat er een DDoS bezig is kan er nauwelijks "goed" verkeer langs, dus heb je enkel dat inkomende verkeer van de DDoS.

Overigens nemen veel mensen/bedrijven dataverkeer af en geen bandbreedte, zeker als ze maar 1 of 2 servers hebben.

[moto-moi]

Tikje richting Beveiliging & Virussen

Inhoudelijk: Als je niets doet gaat het sowieso niet helpen, dus zelfs als maar 10% van je abuse meldingen resultaat opleveren zou ik het altijd doen Het is alleen meestal een rotkarwei om te doen.

[Stewie!]

Erkens schreef op maandag 10 oktober 2005 @ 11:54:
Natuurlijk valt het niet weg tussen het uitgaande verkeer, immers op het moment dat er een DDoS bezig is kan er nauwelijks "goed" verkeer langs, dus heb je enkel dat inkomende verkeer van de DDoS.

3 megabyte/seconde?

[Verwijderd]

beste is om een kernel te gebruiken met syn-cookie ondersteuning. dan verliezen dat soort ddos aanvallen al gauw hun effect.

[Erkens]

DaMorpheus schreef op maandag 10 oktober 2005 @ 12:01:
[...]

3 megabyte/seconde?

Alsof elke DDoS 3 mb/s is

[leuk_he]

3 mbyte per seconde van hoeveel clients? Is het wel wekrelijk een attack, niet gewoon 2 rotte clients?

[Stewie!]

Erkens schreef op maandag 10 oktober 2005 @ 12:06:
[...]

Alsof elke DDoS 3 mb/s is

Ik heb het over de situatie uit de topicstart, waar heb jij het dan over?
Over andere attacks? Vrijwel niemand zal daar ooit een rekening van krijgen.
1) Een goede provider treedt pro-actief op tegen ddos aanvallen
2) Of die provider treedt direct op na melding van de klant en filter de ddos, al dan niet met behulp van de uplink providers

[ Voor 38% gewijzigd door Stewie! op 10-10-2005 12:18 ]

[Olaf van der Spek]

Verwijderd schreef op maandag 10 oktober 2005 @ 12:03:
beste is om een kernel te gebruiken met syn-cookie ondersteuning. dan verliezen dat soort ddos aanvallen al gauw hun effect.

Het is een TCP connect flood, geen TCP syn flood, dus cookies helpen niet (staan wel al aan).

[Olaf van der Spek]

moto-moi schreef op maandag 10 oktober 2005 @ 12:00:
Inhoudelijk: Als je niets doet gaat het sowieso niet helpen,

Gewoon wachten tot het stopt kan ook en zo te zien is die nu gestopt.

leuk_he schreef op maandag 10 oktober 2005 @ 12:11:
3 mbyte per seconde van hoeveel clients? Is het wel wekrelijk een attack, niet gewoon 2 rotte clients?

Ja, het is echt een attack. De lobby server heeft 10000 - 16000 connecties open terwijl er maar 1000 users online zijn.

[ Voor 41% gewijzigd door Olaf van der Spek op 10-10-2005 12:42 ]

[Olaf van der Spek]

Erkens schreef op maandag 10 oktober 2005 @ 11:29:
Dus voor jou maakt het niks uit een DDoS meer of minder, dat dataverkeer wat het genereerd is toch "gratis"
Mag ik bij jou mijn server parkeren

Jij snapt blijkbaar niet dat dat dataverkeer juist bandbreedte in beslag neemt (goh hoe komen anders al die bitjes bij je server) waardoor het dus _niet_ gratis is.

Voor dataverkeer heb je wel capaciteit nodig en dat kost inderdaad geld.
Maar als je die capaciteit wel hebt maar niet gebruikt (en dus ook geen dataverkeer hebt) kost het *ook* geld.
Als een ISP ervoor kiest dataverkeer te verkopen in plaats van capaciteit kan dat natuurlijk ook, maar daarom zei ik er 'in principe' bij.

[ Voor 14% gewijzigd door Olaf van der Spek op 10-10-2005 12:45 ]

[leuk_he]

OlafvdSpek schreef op maandag 10 oktober 2005 @ 12:41:
[...]
Gewoon wachten tot het stopt kan ook en zo te zien is die nu gestopt.
[...]

Ja, het is echt een attack. De lobby server heeft 10000 - 16000 connecties open terwijl er maar 1000 users online zijn.

DDos staat voor een distributed Dineial of Service

-Distributed: Je hebt niet echt aangegeven dat het meer (ip's) clietns betreft. 10.000 connecties kunnen best van 1 rotte client komen met meer bandtbreedte heeft dan goed voor hem is. (of niet goed, een gewoon een proggie dat het hele weekdn op een school staat te draaien en een beetje rotte verbinding heeft)
-Denial. of service Dat stukje hebben ze dus niet voor elkaar gekregen. Wat ze dan wel doen met die connects is de vraag. Maar wellicht is het gewoon een op hol geslagen spider. Ook niet leuk, maar wellicht te overzien.

Voordat je moeilijk gaat rapporteren zul je echt wat meer info willen verzamelen, anders gaat hij in de abuse@isp toch in de bittebak.

[Olaf van der Spek]

leuk_he schreef op maandag 10 oktober 2005 @ 13:11:
-Distributed: Je hebt niet echt aangegeven dat het meer (ip's) clietns betreft. 10.000 connecties kunnen best van 1 rotte client komen met meer bandtbreedte heeft dan goed voor hem is. (of niet goed, een gewoon een proggie dat het hele weekdn op een school staat te draaien en een beetje rotte verbinding heeft)

Ik gaf aan dat het inderdaad om een aanval ging. Niet of die distributed was of niet.

-Denial. of service Dat stukje hebben ze dus niet voor elkaar gekregen. Wat ze dan wel doen met die connects is de vraag. Maar wellicht is het gewoon een op hol geslagen spider. Ook niet leuk, maar wellicht te overzien.

Voordat je moeilijk gaat rapporteren zul je echt wat meer info willen verzamelen, anders gaat hij in de abuse@isp toch in de bittebak.

Ik neem aan dat een tcpdump wel genoeg informatie bevat en dat daaruit wel een rapport is te genereren dat richting een ISP kan, of niet?

[leuk_he]

OlafvdSpek schreef op maandag 10 oktober 2005 @ 13:17:
[...]

Ik gaf aan dat het inderdaad om een aanval ging. Niet of die distributed was of niet.

Title is "DDoS"... is een redelijke hint.

Ik neem aan dat een tcpdump wel genoeg informatie bevat en dat daaruit wel een rapport is te genereren dat richting een ISP kan, of niet?

Overschat ze niet bij een ISP. In eerste instantie krijg je waarschijnlijk toch een robot mailtje terug. Een dump interpreteren is niet zo simpel hoor. Als je geen FBI in je e-mail hebt staan kom je niet zo makkelijk bij de mensen die een dump kunnen interpreteren.

Maar baat het niet dan schaad het niet.

[ Voor 14% gewijzigd door leuk_he op 10-10-2005 13:23 ]

[Erkens]

leuk_he schreef op maandag 10 oktober 2005 @ 13:22:
Title is "DDoS"... is een redelijke hint.

niet alleen die titel

OlafvdSpek schreef op zaterdag 08 oktober 2005 @ 21:22:
Een van mijn servers heeft momenteel last van een Distributed Denial of Service aanval van 3 mbyte/s.

[Olaf van der Spek]

leuk_he schreef op maandag 10 oktober 2005 @ 13:22:
Overschat ze niet bij een ISP. In eerste instantie krijg je waarschijnlijk toch een robot mailtje terug. Een dump interpreteren is niet zo simpel hoor. Als je geen FBI in je e-mail hebt staan kom je niet zo makkelijk bij de mensen die een dump kunnen interpreteren.

Maar baat het niet dan schaad het niet.

Ik heb er nog geen ervaring mee, maar wat willen ze wel hebben dan?

[Stewie!]

OlafvdSpek schreef op maandag 10 oktober 2005 @ 14:22:
[...]

Ik heb er nog geen ervaring mee, maar wat willen ze wel hebben dan?

Mijn ervaring: 10 regels uit de logs is al voldoende.
Maar er zijn ook partijen die gewoon niet reageren. We hadden een tijd terug last van scriptkiddies, even chello gemailed (hun provider) en de problemen waren direct over. Uiterst behulpzaam daar

[ Voor 30% gewijzigd door Stewie! op 10-10-2005 14:33 ]

[DataGhost]

DaMorpheus schreef op maandag 10 oktober 2005 @ 14:28:
[...]

Mijn ervaring: 10 regels uit de logs is al voldoende.
Maar er zijn ook partijen die gewoon niet reageren. We hadden een tijd terug last van scriptkiddies, even chello gemailed (hun provider) en de problemen waren direct over. Uiterst behulpzaam daar

geinig, mijn ervaring met chello is dat er juist niks aan gedaan werd, geeneens een mailtje
k had zelf wel een net mailtje opgestuurd met alle details mja

[serkoon]

Ik zou gewoon even een tijdje een tcpdump laten draaien die een log wegschrijft naar disk. Dan wat grep/perl-foo erop loslaten om te achterhalen welke ip's/ranges voor de flood verantwoordelijk zijn. Dan sorteren op de grootste flooders eerst en die filteren op de host zelf.

Filteren kan dmv een firewall of door gewoon een null-route te zetten. Routing code is doorgaans behoorlijk geoptimaliseerd, zodat zelfs duizenden routes nog snel afgehandeld kunnen worden. Als je die weg bewandeld, controleer dan wel of de ontvangen SYNs nu niet voor duizenden tcp-'connects' in de SYN_RECV-state zorgen. Een null-route zou ervoor kunnen zorgen dat het zenden van een SYN/ACK een error oplevert, waardoor de connectie gewoon direct weggegooid wordt, maar het kan ook gewoon genegeerd worden, waardoor je dus SYN timeouts krijgt. Mgoed, daar werken syncookies wel weer tegen

Als je wil firewallen, zorg er dan voor dat je een geoptimaliseerde manier gebruikt voor het toepassen van 1 rule op meerdere adressen. Maak niet voor elk adres een aparte rule, dan moet de firewall software door een lange lijst rules lineair wandelen, wat enorm veel tijd kost. De manual weet vast of/hoe je zoiets moet aanpakken..