(D)DoS Angriffe einigermaßen kontrollieren

S

stefanMM

Homer isder Größte
ID: 332499
L
24 November 2009
132
15
Nabend zusammen,

habe im Forum gelesen, dass einige Lose-Seiten Betreiber offensichtlich Probleme mit (D)DoS Attacken haben, und das schon über längere Zeit.

Ich möchte hier einfach mal über die Möglichkeiten und Chancen solche Angriffe abzuwehren, bzw. einfach nur abzulehnen, und dem "gewünschten" regulären User dennoch auf die Seite zu lassen, diskutieren. Eventuell auch eine Kleine "Linksammlung" zu nützlichen Hinweisen, Tutorials und Neuigkeiten (s.u.)

Oftmals nutzen solche Bot-Netze relativ ähnliche (um nicht zu sagen gleiche) GET/POST Anfragen an den Server. Diese sind mit normalen Useranfragen oftmals sehr ähnlich. Meistens machen sich die Angreifer jedoch nicht die Mühe, Varianz in die gestellten Anfragen zu bringen. Und ein gewisses System sollte man (zumindest als Mensch mit Hilfe von Maschinen) eigentlich immer erkennen können. Ist ja schließlich berechnet, also kann man in der Regel auch Muster erkennen.

Ich habe für ein privates Projekt vor ein paar Tagen einen Server etwas nach einem gefundenen Tutorial angepasst. Hier der Link dazu. Ich find das wirklich gut erklärt und hatte keine größeren Probleme das einzubauen. Der Server hatte zwar noch keine (richtige) Attacke, aber einige Tests sind sehr gut gelaufen.

Nachteil ist natürlich, dass man den Anfang der Attacke möglichst früh mitbekommen muss. Da wird sich ja aber vielleicht über die Zeit ne "Sammlung" an sogenannten "SecRules" zusammenstellen lassen, ganz nach dem Motto gemeinsam seid ihr stark. Vielleicht können ja einige User Ihre Einstellungen nach Attacken hier posten, dann spricht sich das schnell rum und man ist für den Fall einer Attacke direkt gerüstet.

Ich denke nur über dieses Thema, und Server-Sicherheit im Allgemeinen, ist recht viel Gesprächsbedarf vorhanden und jeder Webmaster/Admin sollte sich heutzutage mehr denn je damit auseinandersetzen.

Auf der oben verlinkten Seite finden sich auch noch weitere Tuts in welchen erklärt wird, wie man seinen Server generell "etwas" sicherer bekommt. Ich kann eigentlich nur empfehlen, darüber nachzudenken vielleicht lieber zu einem kleineren und unbekannteren Hoster zu gehen. Diese sind zwar meist etwas teuer, gehen aber individuell viel besser auf die Kundenwünsche ein (so meine Erfahrung). Da lässt sich dann eventuell auch über eine extern geschaltete Hardware-Firewall reden. Diese ist dann nur zum ablehnen da und kann sich voll und ganz auf das konzentrieren was sie machen soll. Den Apachen freuts dann ebenso ;)

Bei Fragen versuche ich auch gerne zu helfen, kein Problem. Wobei auf der Seite auch zu vielen Dokumentationen und Erklärungen verlinkt wird - und hier unten auch! ;) Ich finds eigentlich nicht sooo schwer, wenn mans erstmal verstanden hat. Viel Spaß beim antworten!

In diesem Sinne: Kämpft! ;)

Gute Nacht!
Stefan


Links:
Installation/Grundkonfiguration von mod_security2
mod_security2 actions (Aktionen - vor allem deny sollte interessant sein)
mod_security Variablen (hier sind die wichtigsten QUERY_STRING, REMOTE_ADDR, REQUEST_BODY & vor allem REQUEST_HEADERS)

Infos:
:arrow: Es können mehrere "SecRules" angelegt werden, einfach in mehreren Zeilen untereinander schreiben. Sollte dann min. Eine der Regeln zutreffen wird die Anfrage einfach gedroppt, und bei Bedarf mitgeloggt, etc. pp. Dabei werden die Regeln von oben nach unten durchgegangen.
HTML: 
SecRule REQUEST_LINE  "get\s*\d+\s*http/1\.0$"  "phase:1,t:lowercase,msg:'DDos match',drop,auditlog,exec:'/etc/apache2/wrapper'"
SecRule REQUEST_HEADERS:User-Agent  "blablabla"  "phase:1,t:lowercase,msg:'DDos match',drop,auditlog,exec:'/etc/apache2/wrapper'"
 
Hallo,

zunächst einmal Danke dafür. Dem ein oder anderen wird es sicher helfen. Bei DoS-Attacken allerdings nur sehr beschränkt!

Mit den SecRules kannst Du den Apachen absichern, ihn aber nicht vor DoS-Attacken schützen. Sobald eine Anfrage am Server ankommt, ist dieser mit der Verarbeitung der Anfrage beschäftigt. Und genau dort hin zielen die DoS-(Denial of Service)-Attacken - den Server so sehr mit Arbeit zuschütten, dass dieser seinen Dienst einstellt, bzw. so sehr damit beschäftigt ist, dass kein normales Arbeiten mehr möglich ist.

Es macht aus Angreifersicht keinen Unterschied ob die Anfragen regulär verarbeitet werden, oder ob der Server/ModSecurity ne Runde mit Fehlercodes um sich wirft.

DoS-Attacken müssen schon beim Server-Provider (Quelle und/oder Ziel) abgefangen werden, sobald soetwas ersichtlich wird. Nur wenn soetwas gar nicht erst zum Server vordringt, ist man vor Ausfällen dieser Kategorie relativ gewappnet...

Gruß
 
Ich frage mich woher du die Information beziehst, dass DDoS-Angriffe meist GET/POST-Anfragen sind :roll:
Denn diese sind eigentlich ungeeignet, ist der Get/Post fertig, könnte der Webserver den Socket schließen und fertig, man erreicht nur, dass PHP (sofern es genutzt wird) einiges zu tun hat.
Die meisten Angriffe finden direkt auf TCP-Schicht (OSI-Schicht 4) mittels SYN-Anfragen oder einfachen Established-Connections statt.

Und da kann mod_security relativ wenig machen, da muss man dann mit Software direkt auf die TCP-Schicht aufsetzen, also direkt mit einen Intrusion Prevention System.
 
ice-breaker schrieb:
Und da kann mod_security relativ wenig machen, da muss man dann mit Software direkt auf die TCP-Schicht aufsetzen, also direkt mit einen Intrusion Prevention System.
Zum Vergrößern anklicken....

Genau richtig und auf der Basis sind wir derzeit am Arbeiten. Täglich werden weitere Server Angriffen, aber nicht nur noch uns, auch nicht gezielt, sondern wahllos. In Branchenforen sind schon heftige Diskussionen unter den Anbietern wer da wohl hintersteckt. Auf jedenflal Böse derzeit.

mfg X Future Media
 
XFuture-Media.de schrieb:
Genau richtig und auf der Basis sind wir derzeit am Arbeiten. Täglich werden weitere Server Angriffen, aber nicht nur noch uns, auch nicht gezielt, sondern wahllos. In Branchenforen sind schon heftige Diskussionen unter den Anbietern wer da wohl hintersteckt. Auf jedenflal Böse derzeit.

mfg X Future Media
Zum Vergrößern anklicken....

Aber auch ein Intrusion Prevention System wird den Server beschäftigen. Wie ich schon geschrieben habe, der Schutz dafür muss schon im Backbone-Bereich vorhanden sein, um die Kunden/Server zu schützen.
Hetzner tut es auch, allerdings mit dem unschönen Nebeneffekt, dass diese den Server vom Netz nehmen. Ich glaube aber, dass es da auch andere Lösungen gibt.

Beispielsweise kann man den Source-IP-Range sperren. Länder aus denen solche Angriffe kommen, sind meist bekannt (China, Rumänien, usw.). Wieviele Chinesen greifen regulär auf deutsche Seiten zu? Das sind wenns hoch kommt <1%...
Ich hab's auf meinen Servern mit Postfix so gemacht, und seither kommen wesentlich weniger dieser "undelivered"-Mails rein.

Irgendeine Lösung muss es jedenfalls geben, und das Problem besteht nicht erst seit einer Woche...

Gruß
 
TerraTux schrieb:
Beispielsweise kann man den Source-IP-Range sperren. Länder aus denen solche Angriffe kommen, sind meist bekannt (China, Rumänien, usw.). Wieviele Chinesen greifen regulär auf deutsche Seiten zu? Das sind wenns hoch kommt <1%...
Ich hab's auf meinen Servern mit Postfix so gemacht, und seither kommen wesentlich weniger dieser "undelivered"-Mails rein.
Zum Vergrößern anklicken....

Hm, jetzt sprichst Du aber von einer ganz anderen Art des "Angriffs", (massig) Spam per E-Mail. Da mag das mit dem IP-Range ja sogar was bringen. Gegen SYN-floods bringt das aber Null, weil die IP-Adressen ja gar nicht echt sein müssen.

Dafür gibt's natürlich auch (halb)automatische Schutzmaßnahmen. Selbst im Artikel den der TE anführte war ein Blog-Eintrag zum Thema SYN-flood verlinkt, aber da findet man sicher noch mehr im Netz. Bin ich jetzt auch nicht grad der Experte dafür.

Ich meine nur, hier geht's ja um (D)DoS eigentlich...
 
Dass das eine andere Art von Angriffen ist, ist mir bewusst. Ging mir auch nicht darum diese Angriffe per IP-Ausschluss zu vermeiden, oder dass dies die ultimative Lösung wäre. Das Beispiel mit den Mails bezog sich eher auf das in meinem Falle ausgeschlossene Land.

Interessanter Artikel übrigens. Mit diesen Aufführungen würden viele der "Opfer" schon mal besser da stehen und müssten den Dienst nicht alle 5min neu starten. Auf der anderen Seite, soweit ich mich erinnere sind die SYN-Cookies doch per default aktiviert!? Warum dann trotzdem so viele gestreßte Betreiber?
 
prinzipiell hast du Recht, was die Klamm-Seiten momentan erleben ist jedoch kein vollwertiger DDoS.
Bei einem vollwertigen DDoS ist schon die ganze Bandbreite des Servers durch die Bots zu, da kann der Serverbetreiber nichts mehr machen, da muss dann das RZ eingreifen.
Momentan sieht es aber bei einigen so aus, dass die Bandbreite nichtmal annähernd voll ausgelastet ist, sondern es sich auf Angriffe auf den Webserver reduziert.
Apache hat ein miserables Verhalten bei vielen gleichzeitigen Anfragen (architekturbedingt), einen Reverse-Proxy wie nginx vor den Apache zu hängen und ein kleines Intrusion Prevention System zu installieren, sollte vielen Seiten schonmal einiges helfen.
 
Ich danke euch für diesen Thread.

Momentan sieht es aber bei einigen so aus, dass die Bandbreite nichtmal annähernd voll ausgelastet ist, sondern es sich auf Angriffe auf den Webserver reduziert.
Zum Vergrößern anklicken....

Meine Seiten inkl. Investmentseite sind auch wieder seit heute betroffen (und waren es Freitag bis Samstag). Als ärgerlich empfinde ich, dass mein Hoster (host-europe) am Freitag meint, das läge an der Apachekonfiguarion und es deutet nichts in Richtung Angriff hin und ich musste ihn drei Tage lang überzeugen dass es wohl wirklich ein DDoS-Angriff ist. Allerdings könnten die ihrer Aussage nach grundsätzlich nichts machen.
Deshalb interessiert mich insbesondere die Stärken der Angriffe bei euch.
Ich hab mal mit netstat die Anzahl der Verbindungen zählen lassen und komme immer, auch kurz nach Neustart des Apaches, auf 900 bis 1050. Hab jetzt das Tool scr bekommen, um zu sehen wie viele zugriffe welche ip macht und versuche die auszusperren. Ansonsten wüssten die nichts mehr. Vorher hatten die noch geworben dass ich da beim Dedicated Server Unterstützung in solchen Fällen bekomme.
Das ist doch nicht normal, wenn ich hier lese dass andere Hoster auch was getan haben und das jetzt im Griff haben, wieso kann das host-europe nicht? Würde ja was bezahlen, aber die bieten nichts an. Bei welchem Hoster habt ihr gute Erfahrungen gemacht, wer installiert z.B. gute Firewalls oder hat so geholfen, dass es wirklich geholfen hat?
Würde es gerne mit mod_security2 & co versuchen, scheiter aber dann manchmal an irgendwelchen Stellen weil meine Linuxkenntnisse auf das Installieren von Paketen begrenzt sind und habe im Grunde auch keine Zeit mich da zwei Tage einzulesen. Das ist doch Aufgabe des Hosters?!
 
Zuletzt bearbeitet:
Jipii schrieb:
Das ist doch nicht normal, wenn ich hier lese dass andere Hoster auch was getan haben und das jetzt im Griff haben, wieso kann das host-europe nicht? Würde ja was bezahlen, aber die bieten nichts an. Bei welchem Hoster habt ihr gute Erfahrungen gemacht, wer installiert z.B. gute Firewalls oder hat so geholfen, dass es wirklich geholfen hat?
Zum Vergrößern anklicken....

Hmm.. glaube, das im Grunde kein Hoster irgendwas dafür getan hat.. das waren alles die Serverbesitzer selbst...
besonders hart hats scheinbar sogar die Besitzer eines Managed Servers getroffen... diese können sich ja nichtmal selbst helfen (wenn ihnen jemand hilfe anbietet), da sie ja im regelfall gar keinen Zugriff auf ihr System haben (zumindest nicht so starken)...

LG
 
Also der Tipp mit dem reverse proxy is eigentlich super, wenn man einen server mit syn-cookies einstellt und dann einen HAproxy oder Pound sollte zumindest die Ressourcen des Webservers der das heavy lifting macht schuetzen (ausserdem kann man mit HAproxy auch die Datenbanken load-balancen, was bei replicated DBs sehr geil is). Danach is der Bottleneck einfach nur noch die Leitung, und ein SYN-Flood wird dann schwer (SYN-Packete haben 12 Byte groesse, alles andere wird von Routern gedroppt, und damit muessen schon > 1MiBit / 12 Bit ~= 87381 SYN-Packete pro MiBit/Sekunde eintreffen um das zu stopfen) und was jetzt noch fehlt sind roque UDP Packete (danke Raven und ice-breaker fuer den Tipp) die bei einem Webhoster sowieso keine Existenzberechtigung haben und man kann als Hosting-Provider oft upstream anfordern dass UDP gedroppt wird.
Fehlt noch etwas?
 
Ich sag nur 4,8 Mio pps. Alles was bei dem Ausmaß hilft ist Geld. Geld für die (gefilterte) Bandbreite oder Zeit. Bei den "Massenhostern" wird idR bei ~>25k pps blackholed weil "Traffic unlimited".
 
Zuletzt bearbeitet:
Snyke schrieb:
Also der Tipp mit dem reverse proxy is eigentlich super, wenn man einen server mit syn-cookies einstellt und dann einen HAproxy oder Pound sollte zumindest die Ressourcen des Webservers der das heavy lifting macht schuetzen
Zum Vergrößern anklicken....
wurde bereits probiert, die Bandbreite der Angreifer ist zu hoch, sie haben ne ganze Menge an Proxys lahmgelegt.

Snyke schrieb:
Danach is der Bottleneck einfach nur noch die Leitung
Zum Vergrößern anklicken....
wunderbar, dass es nur noch nie Bandbreite ist :ugly:
das ist auch überhaupt nicht am schwersten zu lösende Problemstellung.


Snyke schrieb:
und ein SYN-Flood wird dann schwer (SYN-Packete haben 12 Byte groesse, alles andere wird von Routern gedroppt, und damit muessen schon > 1MiBit / 12 Bit ~= 87381 SYN-Packete pro MiBit/Sekunde eintreffen um das zu stopfen)
Zum Vergrößern anklicken....
es ist kein Syn-Flood.

Snyke schrieb:
und was jetzt noch fehlt sind roque UDP Packete (danke Raven und ice-breaker fuer den Tipp) die bei einem Webhoster sowieso keine Existenzberechtigung haben und man kann als Hosting-Provider oft upstream anfordern dass UDP gedroppt wird.
Fehlt noch etwas?
Zum Vergrößern anklicken....
Möglicherweise das Geld für solche Maßnahmen?
Nicht ohne Grund verkaufen Firmen wie Verisign eine DDoS-Protection für einen riesen Batzen Geld, denn so einfach wie es klingt, ist es nicht.
So etwas ist eine richtig teure Sache und nicht mal eben nebenbei finanziert.
Das RZ wird dir die größere BAndbreite berechnen (denn 100Mbit/s schaffen die Angreifen leider locker), den Hardware-Proxy, der auch ne Menge Schotter kostet wenn er soviele Mbit/s filtern können muss achja und Traffic wird dir auch noch berechnet.
 
syn-flood
reverse proxys
lisnmüff...

bahnhof.gif
:ugly:

aber klingt furchtbar unheimlich...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben