Was kann man tun gegen massive Angriffe

[ballaballa321]

Hallo und erstmal viele liebe Grüße an alle Mitglieder dieser Community!

Ich bin neu hier und hoffe, dass mein erster Post hier im richtigen Forum erfolgt. Wenn nicht, bitte entsprechend verschieben.

Ich habe folgendes Problem: Mein ehemaliger Geschäftspartner macht andauernd meine Server platt, indem er sog. d-dos-Angriff auf meine Server verübt - respektive verüben lässt. Mehrfach hat er bereits ganze Server bei mir wirklich zum Zusammenbruch gebracht. Und er hört einfach nicht auf. Auch wenn manche Server davon nicht in sich zusammenfallen, wird durch die Angriffe die Performance natürlich extrem beeinträchtigt.

Nun meine Frage: Was kann ich tun, um mich gegen diese Angriffe zu wehren? Gibt es Programme oder etwas, die wirklich gut sind, damit ich da nichts mehr zu befürchten habe?

Ich bin etwas ein Laie auf dem Gebiet. Mir wurde das so erklärt, dass er über Leute in Rußland und der Ukraine solche d-dos-Angriffe verübt. Jetzt haben wir zwar die IPs für Rußland und die Ukraine sperren lassen, aber in der Statistik tauchen immer wieder Rußland und Ukraine mit unglaublich hohen Werten auf. Auch wenn russische und ukrainische IPs gesperrt sind, dann machen die das über philipinische oder taiwanesische oder thailändische.

Kann mir jemand weiterhelfen?

Beste Grüße


BallaBalla321

[Six]

Hallo und willkommen im df.de!

Hallo und erstmal viele liebe Grüße an alle Mitglieder dieser Community!

Ich bin neu hier und hoffe, dass mein erster Post hier im richtigen Forum erfolgt. Wenn nicht, bitte entsprechend verschieben.

Ich habe folgendes Problem: Mein ehemaliger Geschäftspartner macht andauernd meine Server platt, indem er sog. d-dos-Angriff auf meine Server verübt - respektive verüben lässt. Mehrfach hat er bereits ganze Server bei mir wirklich zum Zusammenbruch gebracht. Und er hört einfach nicht auf. Auch wenn manche Server davon nicht in sich zusammenfallen, wird durch die Angriffe die Performance natürlich extrem beeinträchtigt.

Nun meine Frage: Was kann ich tun, um mich gegen diese Angriffe zu wehren?

Ich gehe davon aus, dass du bereits Anzeige erstattest hast? DDOS-Angriffe fallen unter den Tatbestand der Computersabotage nach § 303b Abs. 1 Nr. 2, Abs. 2 StGB.

Gibt es Programme oder etwas, die wirklich gut sind, damit ich da nichts mehr zu befürchten habe?

Nein. Die Abwehr einer DDOS Attacke ist aufwändig und nicht trivial. Viel Aufwand wird betrieben und ist nötig, um sich dagegen zu verteidigen.

[rendegast]

aber in der Statistik tauchen immer wieder Rußland und Ukraine mit unglaublich hohen Werten auf. Auch wenn russische und ukrainische IPs gesperrt sind, dann machen die das über philipinische oder taiwanesische oder thailändische.

Wenn Deine Geschäfte nicht in diesen Staaten ablaufen,
ist das Sperren der Länder-Ip schon mal nicht schlecht.
-> xtables-addons -> geoip.

Zudem ist das Mieten solcher bot-Netze auf die Dauer auch nicht billig, wird demnach bald aufhören.


Einrichten eines http-Proxy, zBsp. nginx,
dem die gespooften Anfragen aufgehalst werden.

[yeti]

Mein ehemaliger Geschäftspartner macht andauernd meine Server platt, indem er sog. d-dos-Angriff auf meine Server verübt - respektive verüben lässt.

Bis Du beweisen kannst, daß er dahinter steckt, ist es besser, Dieses auch nicht zu behaupten. Das kann nach Hinten losgeh'n!

[Lohengrin]

Ich gehe davon aus, dass du bereits Anzeige erstattest hast? DDOS-Angriffe fallen unter den Tatbestand der Computersabotage nach § 303b Abs. 1 Nr. 2, Abs. 2 StGB.

Wenn es technisch gelöst werden kann, dann ist das zu bevorzugen.

Gibt es Programme oder etwas, die wirklich gut sind, damit ich da nichts mehr zu befürchten habe?

Nein. Die Abwehr einer DDOS Attacke ist aufwändig und nicht trivial. Viel Aufwand wird betrieben und ist nötig, um sich dagegen zu verteidigen.

Ich habe mich mal vor längerer Zeit mit so etwas beschäftigt, allerdings von einem sehr abgehobenen Standpunkt aus. Ich habe nichts selbst dazu programmiert.
Das größte Problem ist es, den Angreifer zu ignorieren, bevor er Ressourcen belegt. Elegant ist es, den Angreifer verrecken zu lassen, also eine Teergrube. Nur wie macht man das, ohne dass eigene Ressourcen belegt werden? Da muss man ganz tief im IP-Stack hacken. Außerdem erscheint man dann selbst als Störer, und riskiert abgewehrt zu werden. Und das ist auf lange Sicht auch nicht erfolgreich, weil man mit den gleichen Mitteln die Angreifer effizienter machen kann.
Es muss etwas her, das die Pakete schon lange vor dir, also mindestens einen Router weiter verschwinden lässt, oder, noch besser, in eine Teergrube lockt. Und das muss authentifiziert geschehen, damit nicht irgendwer einem anderen eine Teergrube gräbt.
Gäbe es keine Flatrate für die Angreifer, wäre das Problem auch vom Tisch. Und hier sehe ich den größten Schaden, den DDOS anrichtet. Es liefert ein Arguement gegen Flatrate.
Das ganze Ding ist sehr interessant.

[Gunman1982]

Ich gehe davon aus, dass du bereits Anzeige erstattest hast? DDOS-Angriffe fallen unter den Tatbestand der Computersabotage nach § 303b Abs. 1 Nr. 2, Abs. 2 StGB.

Wenn es technisch gelöst werden kann, dann ist das zu bevorzugen.

Würde trotzdem Anzeige erstatten, warscheinlich aber nur gegen Unbekannt da man ja schlecht beweisen kann wer es ist.

Gibt es Programme oder etwas, die wirklich gut sind, damit ich da nichts mehr zu befürchten habe?

Nein. Die Abwehr einer DDOS Attacke ist aufwändig und nicht trivial. Viel Aufwand wird betrieben und ist nötig, um sich dagegen zu verteidigen.

Ich habe mich mal vor längerer Zeit mit so etwas beschäftigt, allerdings von einem sehr abgehobenen Standpunkt aus. Ich habe nichts selbst dazu programmiert.
Das größte Problem ist es, den Angreifer zu ignorieren, bevor er Ressourcen belegt. Elegant ist es, den Angreifer verrecken zu lassen, also eine Teergrube. Nur wie macht man das, ohne dass eigene Ressourcen belegt werden? Da muss man ganz tief im IP-Stack hacken. Außerdem erscheint man dann selbst als Störer, und riskiert abgewehrt zu werden. Und das ist auf lange Sicht auch nicht erfolgreich, weil man mit den gleichen Mitteln die Angreifer effizienter machen kann.
Es muss etwas her, das die Pakete schon lange vor dir, also mindestens einen Router weiter verschwinden lässt, oder, noch besser, in eine Teergrube lockt. Und das muss authentifiziert geschehen, damit nicht irgendwer einem anderen eine Teergrube gräbt.

Ich vermute du meinst honeypots. Die Frage dabei ist wie wird der D-Dos ausgeführt, erwartet der Angreifer überhaupt sowas wie ein Ack vom Server oder feuert er einfach nur Syn-Pakete. Im letzteren Fall würd ein Honepot nix bringen, da der Angreifer eh keine Antwort erwartet.
Ich würde mal vermuten das der D-Dos auf den Webserver mindestens bis zum HTTP Get durchgeführt wird. Also einen dedizierten Rechner hinsetzen mit nem Honeypot drauf und an dem Router davor anhand von zum Beispiel IP-Bereichen regeln ob der Traffic an den echten Content geht oder in den Honeypot. Problem hierbei is dann natürlich der Router der unter Umständen mit der Last des D-Dos auch nicht fertig wird.

Gäbe es keine Flatrate für die Angreifer, wäre das Problem auch vom Tisch. Und hier sehe ich den größten Schaden, den DDOS anrichtet. Es liefert ein Arguement gegen Flatrate.
Das ganze Ding ist sehr interessant.

Wüsste nicht was Flatrate da jetz direkt mit zu tun hat. Auch wenn du Volumenbasiert abrechnest die meisten Bots sind doch eh übernommene Zombierechner, was interessiert es da den Botnetz Betreiber ob der Zombie-Nutzer für den Traffic bezahlt.

[Cae]

An den TE: Werde mal bitte konkret. DDoS? Auf was? Welche, wieviele Server bei dir, welche, wieviele Serverdienste? Geht der DDoS auf IP, TCP/UDP oder Anwendung (OSI-Layer)?

Eine Anzeige ist grundsätzlich angebracht, allerdings bezweifle ich, dass du die Angriffe zweifelsfrei auf eine Person zurückführen kannst. Also gegen Unbekannt.

Gruß Cae

[Lohengrin]

Würde trotzdem Anzeige erstatten, warscheinlich aber nur gegen Unbekannt da man ja schlecht beweisen kann wer es ist.

Wer die Musik bestellt, muss zahlen. Selbst wenn die den Angreifer erwischen, dann zeigt er seinen Offenbarungseid und das wars. Und wer zahlt dann? Ich, und die Trottel, die ich in Mitleidenschaft gezogen habe.

Ich vermute du meinst honeypots.

Nein. Ich will nicht jemanden anlocken. Der Angreifer will schon zu mir.

Die Frage dabei ist wie wird der D-Dos ausgeführt, erwartet der Angreifer überhaupt sowas wie ein Ack vom Server oder feuert er einfach nur Syn-Pakete.

Ich habe mal gehört, dass ein gängiger IP-Stack schon beim Syn Ressourcen reserviert. Und das muss verhindert werden.

Ich würde mal vermuten das der D-Dos auf den Webserver mindestens bis zum HTTP Get durchgeführt wird. Also einen dedizierten Rechner hinsetzen mit nem Honeypot drauf und an dem Router davor anhand von zum Beispiel IP-Bereichen regeln ob der Traffic an den echten Content geht oder in den Honeypot.

Ok. In diesem Sinne doch Honeypot. Aber das braucht kein dezidierter Rechner zu sein. Er muss ja nur sehr wenig Speicher für das TCP reservieren. Mehr als ein HTTP GET braucht er sich ja nicht zu merken. Außerdem soll das TCP nur den Empfang von "HT" bestätigen, sich dann taub stellen, irgendwann mal das "TP" bestätigen, usw.

Gäbe es keine Flatrate für die Angreifer, wäre das Problem auch vom Tisch. Und hier sehe ich den größten Schaden, den DDOS anrichtet. Es liefert ein Arguement gegen Flatrate.
Das ganze Ding ist sehr interessant.

Wüsste nicht was Flatrate da jetz direkt mit zu tun hat. Auch wenn du Volumenbasiert abrechnest die meisten Bots sind doch eh übernommene Zombierechner, was interessiert es da den Botnetz Betreiber ob der Zombie-Nutzer für den Traffic bezahlt.

Es wäre ein starker Anreiz für die vom Bot Gekaperten, den Bot loszuwerden.

[Cae]

Ich habe mal gehört, dass ein gängiger IP-Stack schon beim Syn Ressourcen reserviert. Und das muss verhindert werden.

Richtig. Das sind zwar nur einige dutzend Bytes, aber es sind viele Angreifer und viele Verbindungen. Lösung: TCP-syn-Cookies [1].

Gruß Cae

[1] https://de.wikipedia.org/wiki/SYN-Cookies

[Gunman1982]

Würde trotzdem Anzeige erstatten, warscheinlich aber nur gegen Unbekannt da man ja schlecht beweisen kann wer es ist.

Wer die Musik bestellt, muss zahlen. Selbst wenn die den Angreifer erwischen, dann zeigt er seinen Offenbarungseid und das wars. Und wer zahlt dann? Ich, und die Trottel, die ich in Mitleidenschaft gezogen habe.

Dein Argument also das man lieber nicht strafrechtlich verfolgt weil Risiko das nix zu holen ist und es dann auf Staatskosten geht? Belassen wir es dabei das wir da getrennte Meinungen haben ok?

Ich vermute du meinst honeypots.

Nein. Ich will nicht jemanden anlocken. Der Angreifer will schon zu mir.

Die Frage dabei ist wie wird der D-Dos ausgeführt, erwartet der Angreifer überhaupt sowas wie ein Ack vom Server oder feuert er einfach nur Syn-Pakete.

Ich habe mal gehört, dass ein gängiger IP-Stack schon beim Syn Ressourcen reserviert. Und das muss verhindert werden.

Das Maximale was du machen kannst ist in der Firwall das Paket zu droppen (kein Reject). Resourcen hast du aber auch dann schon eingesetzt weil du das Paket im Empfangsbuffer hast, sonst könnte die Firewall ja nicht drauf reagieren. Mein Punkt war allerdings das dies kein Fall für Honeypot/Tarpit Lösungen wäre, also diese nur für einen sehr bestimmten Bereich von DDoS Angriffen in Frage kommen. Nämlich TCP/IP mit mehr als nur einem SYN.

Ich würde mal vermuten das der D-Dos auf den Webserver mindestens bis zum HTTP Get durchgeführt wird. Also einen dedizierten Rechner hinsetzen mit nem Honeypot drauf und an dem Router davor anhand von zum Beispiel IP-Bereichen regeln ob der Traffic an den echten Content geht oder in den Honeypot.

Ok. In diesem Sinne doch Honeypot. Aber das braucht kein dezidierter Rechner zu sein. Er muss ja nur sehr wenig Speicher für das TCP reservieren. Mehr als ein HTTP GET braucht er sich ja nicht zu merken. Außerdem soll das TCP nur den Empfang von "HT" bestätigen, sich dann taub stellen, irgendwann mal das "TP" bestätigen, usw.

Naja aber auch hier sinds wieder Resourcen die du auf dem Produktivsystem ja besser anderweitig einsetzen kannst. Kommt halt auf den Ausmass des DDoS an. Lass dann doch lieber den dedizierten Rechner in die Knie gehen mit dem Tarpit/Honeypot, bis dahin hat er auf jeden Fall schon ne ganze Menge mehr an Angreifern gefressen als ein Life-System was nebenher noch die legitimen Anfragen beantworten muss.

Gäbe es keine Flatrate für die Angreifer, wäre das Problem auch vom Tisch. Und hier sehe ich den größten Schaden, den DDOS anrichtet. Es liefert ein Arguement gegen Flatrate.
Das ganze Ding ist sehr interessant.

Wüsste nicht was Flatrate da jetz direkt mit zu tun hat. Auch wenn du Volumenbasiert abrechnest die meisten Bots sind doch eh übernommene Zombierechner, was interessiert es da den Botnetz Betreiber ob der Zombie-Nutzer für den Traffic bezahlt.

Es wäre ein starker Anreiz für die vom Bot Gekaperten, den Bot loszuwerden.

Ein Bot-Netz Betreiber muss immer abwägen wie groß das Risiko bei einer Aktion ist, dass die Maschiene als Zombie identifiziert wird. Und je nach DDoS angriffsart sind das ja nicht grosse Datenklumpen die da über die Leitung laufen sondern nur tierisch viele Anfragen. 5 Std DDoS attacke, was macht das an Traffic?! Volle Upstream Nutzung bei 16Mbit Leitung zum Beispiel ~80KByte/s * 3600 * 5 = ~848000KByte also ~850MB ... da aber warscheinlich der Nutzer vorm Zombie nicht merken soll das grad der komplette Upstream genutzt wird um nen Server zu killen isses wohl eher sowas wie 20Kbyte oder so, also ~210MB. Weiss nicht ob das so auffällt.

Allerdings gibs ja auch bei den meisten Anbietern ne Abuse Email Adresse die man anschreiben kann. Weiss allerdings nicht was die dann machen, wünschen würde ich mir das sie den User informaieren das er da was auf dem Rechner laufen haben könnte das ihn unwissentlich zu einem Hirn-Verkoster degradiert.

[wanne]

Lösung: TCP-syn-Cookies [1].

Ja, wird mittlerweile glaube ich überall standardmtäßig implementiert.
Zu Thema: Es währe schon sehr Interessant, wie der DOST/Was da eigentlich zur Verfügung steht.
Wenn da nur ne Website ohne große Dateiein ist, kannst du recht einfach kleine Limits für einzelne Verbindungen setzen.
Wie sich das anhört ist das kein Botnetz sondern eine "Firma" mit eigenen Rechnern, die das durchführt.
Für ne einfache Website (Das heißt ohne andere Dienste und ohne Größere Files wie Videos/hochauflösende Bilder.), die nicht so häufig besucht wird könnte eine Filterregel dann so aussehen:

Code: Alles auswählen

iptables -A INPUT -m hashlimit --hashlimit-name dos1 --hashlimit-mode srcip --hashlimit-srcmask 23 --hashlimit-burst 20000 --hashlimit-above 1000/minute -j REJECT
iptables -A INPUT -p tcp -m tcp --syn -m hashlimit --hashlimit-name synflood --hashlimit-mode srcip --hashlimit-srcmask 23 --hashlimit-burst 4000 --hashlimit-above 750/minute -j REJECT

Aber wie gesagt es währe wirklich wichtig zu wissen, was du für dienste anbitest. (Damit du nichts filterst, was du eigentlich anbieten willst.)
Und auch eine Etwas genauere Beschreibung der Angriffe währe interessant.
Das ganze funktioniert im übrigen auch herforragend, auf nem Router vor dem Server. Die REJECTs würde ich im Übrigen drin lassen. Bei ner DOS ist es gar nicht so schlecht, wenn der Angreifer erfährt dass sine Angriffe in's leere laufen.
Wenn dir die ICMP-Meldungen zu viel werden kannst du drüber eine DROP Meldung mit einem leicht größeren Limit setzen. (Oder einfach hinten dran die ICMP-Meldungen filtern.)
Ist aber nicht resistent gegen source-IP spoofing. Wie gesagt: Es währe sehr sinnvol zu erfahren, was das für ein Server ist und was für Angriffe sind, die er da fährt.
Aber den Aufwand für das Filtern (wie ich es vorgeschlagen habe) kann man glaube ich echt vergessen bei Leitungen, die unter einem GiB/s leiten.

[Lohengrin]

Dein Argument also das man lieber nicht strafrechtlich verfolgt weil Risiko das nix zu holen ist und es dann auf Staatskosten geht?

Ich habe schon viele beobachtet, die damit schlechte Erfahrung gemacht haben. In einem Fall hat ein im ARGE-Sprech Hilfsbedürftiger einen Freund von mir beschissen. Ich habe dem Beschissenen geraten, gar nichts zu tun. Ein anderer im Hilfsbedürftiger empfahl ihm, zu klagen. Schließlich habe er ja eine Rechtsschutzversicherung. Das endete mit dem Feststellung, dass der Bescheißer eine Eidesstattliche Versicherung hat. Das war sowas von klar. Aber der, der das empfohlen hat, hat kein Problem damit. "Es ist ja sein gutes Recht, und dafür hat er schließlich die Rechtschutzversicherung", sagte er.
Ich habe keine Rechtschutzversicherung. Aus Überzeugung. Ich wurde auch schon aufs Übelste beschissen - von jemandem, der damit prahlt, rechtschutzversichert zu sein. Nochmal ist mir das nicht passiert. Auch ich werde aus Schaden klug. Und ich ärger mich sehr darüber, dass ich so dumm war.

Belassen wir es dabei das wir da getrennte Meinungen haben ok?

Meinetwegen. Aber das, was ich eben schrieb, wollte ich noch loswerden.

Die Frage dabei ist wie wird der D-Dos ausgeführt, erwartet der Angreifer überhaupt sowas wie ein Ack vom Server oder feuert er einfach nur Syn-Pakete.

Ich habe mal gehört, dass ein gängiger IP-Stack schon beim Syn Ressourcen reserviert. Und das muss verhindert werden.

Das Maximale was du machen kannst ist in der Firwall das Paket zu droppen (kein Reject). Resourcen hast du aber auch dann schon eingesetzt weil du das Paket im Empfangsbuffer hast, sonst könnte die Firewall ja nicht drauf reagieren.

Beim derzeitigen TCP-Stack ja. Aber wenn man daran herumhackt, könnte es was werden. Schon beim Empfang kann klar werden, dass das mal wieder von einer bekannten IP-Adresse kommt. Und wenn das dann noch ein TCP mit SYN ist, dann ist schluss, und der Speicher ist wieder frei.

Ok. In diesem Sinne doch Honeypot. Aber das braucht kein dezidierter Rechner zu sein. Er muss ja nur sehr wenig Speicher für das TCP reservieren. Mehr als ein HTTP GET braucht er sich ja nicht zu merken. Außerdem soll das TCP nur den Empfang von "HT" bestätigen, sich dann taub stellen, irgendwann mal das "TP" bestätigen, usw.

Naja aber auch hier sinds wieder Resourcen die du auf dem Produktivsystem ja besser anderweitig einsetzen kannst. Kommt halt auf den Ausmass des DDoS an. Lass dann doch lieber den dedizierten Rechner in die Knie gehen mit dem Tarpit/Honeypot, bis dahin hat er auf jeden Fall schon ne ganze Menge mehr an Angreifern gefressen als ein Life-System was nebenher noch die legitimen Anfragen beantworten muss.

Kommt drauf an, wieviel Ressourcen für die TCP-Verbindung reserviert werden. Wenn man gleich großzügig ein paar Kilobyte nimmt, hat man ein Problem. Wenn man erst einmal mit einem DDoS rechnet, und 64 Byte nimmt, wird es erträglich. Aber dafür müsste man am TCP-Stack basteln. Beim derzeitigen TCP-Stack hat der HTTP-Server keine Chance.

Wüsste nicht was Flatrate da jetz direkt mit zu tun hat. Auch wenn du Volumenbasiert abrechnest die meisten Bots sind doch eh übernommene Zombierechner, was interessiert es da den Botnetz Betreiber ob der Zombie-Nutzer für den Traffic bezahlt.

Es wäre ein starker Anreiz für die vom Bot Gekaperten, den Bot loszuwerden.

Ein Bot-Netz Betreiber muss immer abwägen wie groß das Risiko bei einer Aktion ist, dass die Maschiene als Zombie identifiziert wird. Und je nach DDoS angriffsart sind das ja nicht grosse Datenklumpen die da über die Leitung laufen sondern nur tierisch viele Anfragen. 5 Std DDoS attacke, was macht das an Traffic?! Volle Upstream Nutzung bei 16Mbit Leitung zum Beispiel ~80KByte/s * 3600 * 5 = ~848000KByte also ~850MB ... da aber warscheinlich der Nutzer vorm Zombie nicht merken soll das grad der komplette Upstream genutzt wird um nen Server zu killen isses wohl eher sowas wie 20Kbyte oder so, also ~210MB. Weiss nicht ob das so auffällt.

Soweit richtig. Nur was für einen Schaden kann das anrichten? Damit kann man doch nur Server belästigen, die bei SYN-Paketen erst einmal großzügig Ressourcen reservieren.
Man könnte aber auch als ISP so etwas erkennen. Wenn da jemand zu viele TCP/SYN an dieselbe IP-Nummer raushaut, wird ignoriert. Das ist jetzt aber verdammt heikel. Netzneutralität und so.

Allerdings gibs ja auch bei den meisten Anbietern ne Abuse Email Adresse die man anschreiben kann. Weiss allerdings nicht was die dann machen, wünschen würde ich mir das sie den User informaieren das er da was auf dem Rechner laufen haben könnte das ihn unwissentlich zu einem Hirn-Verkoster degradiert.

Was wiegt schwerer? Das Recht irgend etwas ins Netz zu ballern, oder das Recht nicht mit TCP/SYN beballert zu werden.

[wanne]

Die Frage dabei ist wie wird der D-Dos ausgeführt, erwartet der Angreifer überhaupt sowas wie ein Ack vom Server oder feuert er einfach nur Syn-Pakete.

Ich habe mal gehört, dass ein gängiger IP-Stack schon beim Syn Ressourcen reserviert. Und das muss verhindert werden.

Das Maximale was du machen kannst ist in der Firwall das Paket zu droppen (kein Reject). Resourcen hast du aber auch dann schon eingesetzt weil du das Paket im Empfangsbuffer hast, sonst könnte die Firewall ja nicht drauf reagieren.

Beim derzeitigen TCP-Stack ja. Aber wenn man daran herumhackt, könnte es was werden. Schon beim Empfang kann klar werden, dass das mal wieder von einer bekannten IP-Adresse kommt. Und wenn das dann noch ein TCP mit SYN ist, dann ist schluss, und der Speicher ist wieder frei.[/quote]Mit TCP Hat das gar nichts zu tun. Wenn die Firewall dropt Bekommt TCP davon nichts mehr mit.
Es ging nur darum, das die Firewall das Paket durchlesen muss. (Und dagegen kann man nichts machen Außer die FIrewall eben auszulagern.) Aber das ist Und reine TCP-floods sind sein 1997 kein Problem mehr.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies (Ist aber sowieso standard.)
Im übrigen sind mehrere syns sinnvoll. Mein Konqueror "flooded" auch erst mal 10 syns. Wenn er ebay.de aufruft. (Um verschiedenen Elemente zu laden)

Soweit richtig. Nur was für einen Schaden kann das anrichten? Damit kann man doch nur Server belästigen, die bei SYN-Paketen erst einmal großzügig Ressourcen reservieren.
Man könnte aber auch als ISP so etwas erkennen. Wenn da jemand zu viele TCP/SYN an dieselbe IP-Nummer raushaut, wird ignoriert. Das ist jetzt aber verdammt heikel. Netzneutralität und so.

IDIOT!!!!!!!!!!!!!!!!!!!
Das problem an DOS-Angriffen ist im Normalfall nicht, dass sie nicht unterbunden werden können, sondern sie zu blocken während andere legitime Anfragen möglich bleiben. ifconfig eh0 down schützt dich hervorragend vor DOS Angriffen aus dem Netz.
Wenn das der Betreiber des Servers nicht schafft, der weiß was für Dienste er anbietet und den vollständigen Angriff sieht, wie soll es dann der ISP, der nur einen der vielen Bots sieht und noch nicht mal weiß was der denn eigentlich machen sollte.
Die einzige Stelle an der das sinnvoll gemacht werden kann währe der Zugang direkt vor dem Server. Und da bekommst du das (für den Aufpreis, den sowas kostet) garantier auch (wenn man lieb nachfragt).
Das einzige wofür das sorgt ist, dass jede Menge legitime Anwendungen nicht mehr funktionieren während es fast keinen DOS Angriff verhindert. Wie gesagt reine SYN angriffe sind seit 1997 sowieso nutzlos. Und für andere Angriffe auf irgend Protokoll jeden Router im Internet zu updaten ich weiß nicht ob das der sinnvolle Ansatz ist...

[Lohengrin]

Beim derzeitigen TCP-Stack ja. Aber wenn man daran herumhackt, könnte es was werden. Schon beim Empfang kann klar werden, dass das mal wieder von einer bekannten IP-Adresse kommt. Und wenn das dann noch ein TCP mit SYN ist, dann ist schluss, und der Speicher ist wieder frei.

Mit TCP Hat das gar nichts zu tun. Wenn die Firewall dropt Bekommt TCP davon nichts mehr mit.

Bei Iptables werden Ports berücksichtigt. Man kann ganz am Anfang des ankommenden Pakets erkennen, ob es mal wieder ein TCP/SYN ist von der Adresse, die schon viele Verbindungen hat. Ab da ist klar, dass die gesamten mehr als 1400 Bytes (oder so ähnlich), nicht mehr gebraucht werden. Man kann das gleich fürs nächste Paket nehmen.

Es ging nur darum, das die Firewall das Paket durchlesen muss. (Und dagegen kann man nichts machen Außer die FIrewall eben auszulagern.) Aber das ist Und reine TCP-floods sind sein 1997 kein Problem mehr.

Es geht mir nicht um ein einfaches SYN, wo dann nichts mehr hinterher kommt. Es geht mir um die Späße, wo jemand mehrfach ein HTTP GET senden will.

Im übrigen sind mehrere syns sinnvoll. Mein Konqueror "flooded" auch erst mal 10 syns. Wenn er ebay.de aufruft. (Um verschiedenen Elemente zu laden)

Ich dachte nicht an 10, sondern eher an 100 Verbindungen.

Soweit richtig. Nur was für einen Schaden kann das anrichten? Damit kann man doch nur Server belästigen, die bei SYN-Paketen erst einmal großzügig Ressourcen reservieren.
Man könnte aber auch als ISP so etwas erkennen. Wenn da jemand zu viele TCP/SYN an dieselbe IP-Nummer raushaut, wird ignoriert. Das ist jetzt aber verdammt heikel. Netzneutralität und so.

IDIOT!!!!!!!!!!!!!!!!!!!
Das problem an DOS-Angriffen ist im Normalfall nicht, dass sie nicht unterbunden werden können, sondern sie zu blocken während andere legitime Anfragen möglich bleiben. ifconfig eh0 down schützt dich hervorragend vor DOS Angriffen aus dem Netz.

Was soll denn mit derselben Absender-IP, Empfänger-IP und Empfänger TCP-Port noch für eine legitime Anfragen kommen, wenn innerhalb einer Sekunde 100 TCP/SYN kommen? Zehn Rechner hinter einem NAT, die alle gleichzeitig Ebay aufrufen?

Wenn das der Betreiber des Servers nicht schafft, der weiß was für Dienste er anbietet und den vollständigen Angriff sieht, wie soll es dann der ISP, der nur einen der vielen Bots sieht und noch nicht mal weiß was der denn eigentlich machen sollte.
Die einzige Stelle an der das sinnvoll gemacht werden kann währe der Zugang direkt vor dem Server. Und da bekommst du das (für den Aufpreis, den sowas kostet) garantier auch (wenn man lieb nachfragt).

Das stimmt wohl. Aber der angegriffene Server kriegt bei einem DDoS von 1000 Seiten auch die 1000-fache Datenmenge ab.

Das einzige wofür das sorgt ist, dass jede Menge legitime Anwendungen nicht mehr funktionieren während es fast keinen DOS Angriff verhindert.

Welche legitime Anwendung macht 100 TCP-Verbindungen zum selben Ziel (IP Nummer und TCP-Port) gleichzeitig auf?

Und für andere Angriffe auf irgend Protokoll jeden Router im Internet zu updaten ich weiß nicht ob das der sinnvolle Ansatz ist...

Es geht nicht um jeden Router. Es reicht aus, wenn zwischen dem Angreifer und dem Angegriffenen einer das tut. Das wäre auch schon ein verdammt großer Aufwand. Aber es geht um DoS auf irgendwas mit TCP.

[hikaru]

Aus der Sicht eines nahezu Uninformierten:
Was passiert denn wenn die Teergrube unter dem DDOS zusammenbricht? Aus meinen nahezu nicht vorhandenen Netzwerkkenntnissen schließe ich, dass dann zwei Fälle eintreten könnten:
1. Entweder der Router wird dann durch die nicht auslieferbaren Anfragen in die Knie gezwungen oder der Produktivrechner kriegt wieder die Last aufgebrummt. In beiden Unterfällen müsste man also die Teergrube entsprechend dimensionieren um die DDOS-Last zu bewältigen.
2. Es passiert einfach gar nichts. Die DDOS-Anfragen können eben nicht bearbeitet werden, aber abgesehren davon funktioniert auf dem Produktivsystem alles. Wozu bräuchte man dann aber überhaupt eine Teergrube? Müsste es nicht reichen die DDOS-Pakete im Router zu verwerfen? Oder ist es für den Router mit mehr Aufwand verbunden die DDOS-Pakete zu verwerfen als an die Teergrube zu schicken?

[wanne]

Welche legitime Anwendung macht 100 TCP-Verbindungen zum selben Ziel (IP Nummer und TCP-Port) gleichzeitig auf?

Wenn man "bild.de" aufruft sind es genau exakt 50. Wenn das jetzt 2 In der gleichen Sekunde machen (Hinter einem ANschluss können sich ganze Netze verbergen.) Hast du deine 100 Voll. Aber es gibt außer Web noch viele andere Anwendungen. Ich wette ein restart eines Torrent Clients kanckt die 500. (Kann ich wegen Krüppelinternet nicht ausprobieren.)

Was die meisten hie aber absolut nicht verstehen wollen ist, ja das dropen von Paketen braucht resourcen. Aber damit man von den Resourcen gekillt wird muss es schon ein sehr ordentlicher DDOS-Angriff sein. Das macht der OTTO-normal Mensch nicht so einfach. Da braucht's schon wirklich gute neue Ideen, dass man was in der Größe hinbekommt. In unserem Fall absolut übertrieben. Und glecih 5 mal übertreiben wenn man das ganze I-Net umstellen will wegen 5 Angriffen im Jahr, die die Größe haben.

@hikaru: Du hast natürlich recht.

[hikaru]

@hikaru: Du hast natürlich recht.

Womit?
Mein letzter Beitrag basiert auf keinerlei Fachkenntnis sondern lediglich (wie ich hoffe) logischem Denkvermögen.

[Six]

IDIOT!!!!!!!!!!!!!!!!!!!

Während dein Beitrag in der Sache richtig ist, ist die Art und Weise der Ausführung völlig unangemessen. Betrachte dich als verwarnt.

[Six]

Was die meisten hie aber absolut nicht verstehen wollen ist, ja das dropen von Paketen braucht resourcen. Aber damit man von den Resourcen gekillt wird muss es schon ein sehr ordentlicher DDOS-Angriff sein. Das macht der OTTO-normal Mensch nicht so einfach. Da braucht's schon wirklich gute neue Ideen, dass man was in der Größe hinbekommt. In unserem Fall absolut übertrieben. Und glecih 5 mal übertreiben wenn man das ganze I-Net umstellen will wegen 5 Angriffen im Jahr, die die Größe haben.

Du musst ja noch nicht mal explizit droppen. Wenn eine DDoS anrollt, routest du gegen Null, das ist quasi kostenlos. Klar, die Seite ist zwar down, aber deine Infrastruktur lebt und andere Dienste auch.

[Gunman1982]

Was die meisten hie aber absolut nicht verstehen wollen ist, ja das dropen von Paketen braucht resourcen. Aber damit man von den Resourcen gekillt wird muss es schon ein sehr ordentlicher DDOS-Angriff sein. Das macht der OTTO-normal Mensch nicht so einfach. Da braucht's schon wirklich gute neue Ideen, dass man was in der Größe hinbekommt. In unserem Fall absolut übertrieben. Und glecih 5 mal übertreiben wenn man das ganze I-Net umstellen will wegen 5 Angriffen im Jahr, die die Größe haben.

Du musst ja noch nicht mal explizit droppen. Wenn eine DDoS anrollt, routest du gegen Null, das ist quasi kostenlos. Klar, die Seite ist zwar down, aber deine Infrastruktur lebt und andere Dienste auch.

Ohne jetzt den Code angeschaut zu haben sollte das das gleiche wie drop sein.

Paket kommt auf physischen Kabel an, Landet im RX-Buffer der Netzwerkkarte (Resource gebunden), würde jetzt vermuten das der entsprechende daemon firewall/routing das aus dem RX-Buffer zieht (resourcen immernoch gebunden), nun wird geprüft und anhand dessen entschieden was gemacht wird (Drop oder Routing), bei drop: Speicher freigeben, bei Routing -> /dev/null ... Same difference

Aus der Sicht eines nahezu Uninformierten:
Was passiert denn wenn die Teergrube unter dem DDOS zusammenbricht? Aus meinen nahezu nicht vorhandenen Netzwerkkenntnissen schließe ich, dass dann zwei Fälle eintreten könnten:
1. Entweder der Router wird dann durch die nicht auslieferbaren Anfragen in die Knie gezwungen oder der Produktivrechner kriegt wieder die Last aufgebrummt. In beiden Unterfällen müsste man also die Teergrube entsprechend dimensionieren um die DDOS-Last zu bewältigen.

Warum sollte der Produktivrechner behelligt werden? Ausser du sagst dem Router das er beim Ausfall des Honeypots wieder aufs Produktiv-System routen soll, wovon ich abraten würde. Kann natürlich sein das der Router in die Knie geht da er ab jetzt warscheinlich ziemlich viele icmp-destination-unreachable Pakete rausschicken muss.

2. Es passiert einfach gar nichts. Die DDOS-Anfragen können eben nicht bearbeitet werden, aber abgesehren davon funktioniert auf dem Produktivsystem alles. Wozu bräuchte man dann aber überhaupt eine Teergrube? Müsste es nicht reichen die DDOS-Pakete im Router zu verwerfen? Oder ist es für den Router mit mehr Aufwand verbunden die DDOS-Pakete zu verwerfen als an die Teergrube zu schicken?

Ziel einer Teergrube/Honigglases ist es den Angreifer zu beschäftigen, wenn der Angreifer meint er blockiert mit seiner Anfrage erfolgreich deinen Webserver dann schickt er keine neue Anfrage. Ansonsten bombardiert er dich unter Umständen mit Anfragen. Also Ziel: Resourcen auf Angreifer Seite binden.

*SNIP*
Beim derzeitigen TCP-Stack ja. Aber wenn man daran herumhackt, könnte es was werden. Schon beim Empfang kann klar werden, dass das mal wieder von einer bekannten IP-Adresse kommt. Und wenn das dann noch ein TCP mit SYN ist, dann ist schluss, und der Speicher ist wieder frei.

Mit TCP Hat das gar nichts zu tun. Wenn die Firewall dropt Bekommt TCP davon nichts mehr mit.
Es ging nur darum, das die Firewall das Paket durchlesen muss. (Und dagegen kann man nichts machen Außer die FIrewall eben auszulagern.) Aber das ist Und reine TCP-floods sind sein 1997 kein Problem mehr.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies (Ist aber sowieso standard.)
Im übrigen sind mehrere syns sinnvoll. Mein Konqueror "flooded" auch erst mal 10 syns. Wenn er ebay.de aufruft. (Um verschiedenen Elemente zu laden)

Naja ich halte syn-floods immernoch für durchaus einsetzbare Attacken. Je nachdem wie das Opfer reagiert. Wenn es bei überforderung anfängt die "Angreifer" zu ignorieren dann nen Angriff mit ip-paket-spoofing (Absenderadresse geändert) durchführen. Entweder man umgeht damit die Limitierung oder man sorgt dafür das das Opfer von sich aus alle Anfragen von den gespooften IP-Adressen ignoriert.
Zudem ... ich weiss ja nicht ob ich zu abgehoben denke aber ich habe jetzt nicht Angriffe mit 100 SYN/s im Kopf sondern so eher im 5 Stelligen Bereich.

Soweit richtig. Nur was für einen Schaden kann das anrichten? Damit kann man doch nur Server belästigen, die bei SYN-Paketen erst einmal großzügig Ressourcen reservieren.
Man könnte aber auch als ISP so etwas erkennen. Wenn da jemand zu viele TCP/SYN an dieselbe IP-Nummer raushaut, wird ignoriert. Das ist jetzt aber verdammt heikel. Netzneutralität und so.

Das problem an DOS-Angriffen ist im Normalfall nicht, dass sie nicht unterbunden werden können, sondern sie zu blocken während andere legitime Anfragen möglich bleiben. ifconfig eh0 down schützt dich hervorragend vor DOS Angriffen aus dem Netz.
Wenn das der Betreiber des Servers nicht schafft, der weiß was für Dienste er anbietet und den vollständigen Angriff sieht, wie soll es dann der ISP, der nur einen der vielen Bots sieht und noch nicht mal weiß was der denn eigentlich machen sollte.
Die einzige Stelle an der das sinnvoll gemacht werden kann währe der Zugang direkt vor dem Server. Und da bekommst du das (für den Aufpreis, den sowas kostet) garantier auch (wenn man lieb nachfragt).
Das einzige wofür das sorgt ist, dass jede Menge legitime Anwendungen nicht mehr funktionieren während es fast keinen DOS Angriff verhindert. Wie gesagt reine SYN angriffe sind seit 1997 sowieso nutzlos. Und für andere Angriffe auf irgend Protokoll jeden Router im Internet zu updaten ich weiß nicht ob das der sinnvolle Ansatz ist...

Was natürlich auch eine Möglichkeit wäre ist garkeine syn Pakete zu schicken sondern Pakete die die vollen 1500Byte Nutzlast drin haben und so tun als wären sie legitime Pakete. Ziel: Leitung verstopfen.

[hikaru]

Ziel einer Teergrube/Honigglases ist es den Angreifer zu beschäftigen, wenn der Angreifer meint er blockiert mit seiner Anfrage erfolgreich deinen Webserver dann schickt er keine neue Anfrage. Ansonsten bombardiert er dich unter Umständen mit Anfragen. Also Ziel: Resourcen auf Angreifer Seite binden.

Schon klar, aber warum muss man denn dafür wirklich ein System vorhalten? Lässt sich ein blockierter Server nicht direkt im Router simulieren?

[Gunman1982]

Ziel einer Teergrube/Honigglases ist es den Angreifer zu beschäftigen, wenn der Angreifer meint er blockiert mit seiner Anfrage erfolgreich deinen Webserver dann schickt er keine neue Anfrage. Ansonsten bombardiert er dich unter Umständen mit Anfragen. Also Ziel: Resourcen auf Angreifer Seite binden.

Schon klar, aber warum muss man denn dafür wirklich ein System vorhalten? Lässt sich ein blockierter Server nicht direkt im Router simulieren?

Das Problem hierbei wäre das dein Router wieder mehr machen muss als nur stupide Routen. Je mehr Aufgaben/Logik desto fehleranfälliger und resourcen-intensiv. Also falls du auf dem den Honeypots/Tarpits willst. Ein firewall drop (auf router oder sonstwo) bindet Angreifer resourcen nur minimal, nämlich bis beim Angreifer das Programm in den tcp timeout läuft für die Verbindung.

EDIT:
Oh ahja, alt aber Klassiker: (Vorsicht werbung -.- )
http://www.networkworld.com/news/2001/0125mshacked.html

[Six]

Ohne jetzt den Code angeschaut zu haben sollte das das gleiche wie drop sein.

Paket kommt auf physischen Kabel an, Landet im RX-Buffer der Netzwerkkarte (Resource gebunden), würde jetzt vermuten das der entsprechende daemon firewall/routing das aus dem RX-Buffer zieht (resourcen immernoch gebunden), nun wird geprüft und anhand dessen entschieden was gemacht wird (Drop oder Routing), bei drop: Speicher freigeben, bei Routing -> /dev/null ... Same difference

So läuft das nicht, die Entscheidung ist nicht routen oder droppen, sondern da wird eine strikte Reihenfolge eingehalten:
1) Wo solls hin?
2) Darf es das?

Schritt 2) ist noch nicht mal zwingend erforderlich und entsprechend reicht

Code: Alles auswählen

ip route add <subnetz> via <gw-im-anderen-subnetz> dev <device-im-anderen-subnetz>

vollkommen aus, um routing in ein anderes Netz zu aktivieren. Deswegen reicht

Code: Alles auswählen

ip route add blackhole <böse-IP-oder-böses-Subnetz>

um einen Angreifer ohne Umweg über die Firewall ins Klo zu spülen. Dass das ein Performancevorteil gegenüber der iptables-DROP Methode hat, liegt auf der Hand, oder?

[Gunman1982]

Ohne jetzt den Code angeschaut zu haben sollte das das gleiche wie drop sein.

Paket kommt auf physischen Kabel an, Landet im RX-Buffer der Netzwerkkarte (Resource gebunden), würde jetzt vermuten das der entsprechende daemon firewall/routing das aus dem RX-Buffer zieht (resourcen immernoch gebunden), nun wird geprüft und anhand dessen entschieden was gemacht wird (Drop oder Routing), bei drop: Speicher freigeben, bei Routing -> /dev/null ... Same difference

So läuft das nicht, die Entscheidung ist nicht routen oder droppen, sondern da wird eine strikte Reihenfolge eingehalten:
1) Wo solls hin?
2) Darf es das?

Schritt 2) ist noch nicht mal zwingend erforderlich und entsprechend reicht

Code: Alles auswählen

ip route add <subnetz> via <gw-im-anderen-subnetz> dev <device-im-anderen-subnetz>

vollkommen aus, um routing in ein anderes Netz zu aktivieren. Deswegen reicht

Code: Alles auswählen

ip route add blackhole <böse-IP-oder-böses-Subnetz>

um einen Angreifer ohne Umweg über die Firewall ins Klo zu spülen. Dass das ein Performancevorteil gegenüber der iptables-DROP Methode hat, liegt auf der Hand, oder?

Jup, mein Gedankengang war eher von der Speicherauslastung her, von den Rechenzyklen her hast du vollkommen Recht.

[Lohengrin]

Welche legitime Anwendung macht 100 TCP-Verbindungen zum selben Ziel (IP Nummer und TCP-Port) gleichzeitig auf?

Wenn man "bild.de" aufruft sind es genau exakt 50. Wenn das jetzt 2 In der gleichen Sekunde machen (Hinter einem ANschluss können sich ganze Netze verbergen.) Hast du deine 100 Voll. Aber es gibt außer Web noch viele andere Anwendungen. Ich wette ein restart eines Torrent Clients kanckt die 500. (Kann ich wegen Krüppelinternet nicht ausprobieren.)

Gibt es für SMTP nicht extra den Batch-Mode, damit man nicht für jede Email an dasselbe Ziel (nächster SMTP-Server als Router) eine neue TCP-Verbindung braucht? War das nicht der Grund für HTTP/1.1? Wenn ein Torrent Client mehrere Sachen von demselbsen Torrent-Server holt, dann sollte der das doch auch in einer TCP-Verbindung machen.

Mehrere TCP-Verbindung zwischen demselben Client und demselben Server ist Ressourcenverschwendung. Ein Client, der sowas macht, ist böse.

Nochmal zu bild.de. Sind das wirklich 50 TCP-Verbindungen, oder sind das 50 "HTTP GET" in einer TCP-Vernbindung?

Was die meisten hie aber absolut nicht verstehen wollen ist, ja das dropen von Paketen braucht resourcen.

Das ist das Problem. Deswegen muss der Router die Annahme des IP-Pakets abbrechen, also nach /dev/null umleiten, sobald klar ist, dass das gedropt werden wird.

So läuft das nicht, die Entscheidung ist nicht routen oder droppen, sondern da wird eine strikte Reihenfolge eingehalten:
1) Wo solls hin?
2) Darf es das?

Genau diese Reihenfolge ist das Problem. Und um das zu lösen, muss man ganz tief im IP/TCP herumhacken, möglicherweise das Ding komplett neu machen.

Zudem ... ich weiss ja nicht ob ich zu abgehoben denke aber ich habe jetzt nicht Angriffe mit 100 SYN/s im Kopf sondern so eher im 5 Stelligen Bereich.

Wenn 1000 Angreifer mit jeweils 100 SYN pro Sekunde kommen, passt das.