Dos Attacken abwehren

[samy-delux]

Hey Leute,

Mir ist grad aufgefallen das man meinen Server mit ner einfach while Schleife töten kann.
Also geh ich zu Google und informier mich wie man sich dagegen schützen kann. Und les da das mod_security das kann aber nur mit einem Tool namens httpd-guardian. Dieses solles auf Apache Security - Apache httpd Tools geben. Doch in dem Packet dort ist es nicht enthalten.

Ich sehe es eh als schlechte Methode an, da bei jedem Request diese Binary aufgerufen wird. Was gibt es für bessere Methoden den Apache vor Dos oder DDos Atacken zu schützen?
Oder wo finde ich das entsprechende http-guardian ?

so long,
Samy

 

[Thorsten]

Hallo!
HTTP Guardian kenne ich nicht. mod_security kannst du ohne weiteres in Kombination mit Apache einsetzten. Siehe hierzu auch https://serversupportforum.de/threads/modsecurity-neue-fassung.11570/

Eventuell siehst du dir auch noch mod_evasive an.

mfG
Thorsten

 

[samy-delux]

mod_evasive bringt leider nichts. Selbst bei ner einfach PHP while Schleife, die per readfile eine URL öffnet ist es egal ob die Seite oder ein Error 403 zurück gegeben wird. Der Apache ist dann so oder so platt.
Mod_Security habe ich installiert. Aber mod_security selbst kann mich ja nicht vor Dos Attacken schützen oder? Ich probiere gerade "modsec2iptables" !

Gibt es noch bessere Möglichkeite mit mod_security um Dos auf Firewall Ebene abzuwehren?

 

[Sinepp]

Hallo samy,

DoS (Denial Of Service) != while Schleife in PHP.

Unter einem DoS wird verstanden: Es kommen requests, die einen externen Partner lahm legen. Er verneint weitere Anfragen.

Wenn einer Deiner User eine böse while-Schleife programmiert, hast Du zwar auch keinen Service mehr, aber die klassischen Methoden wie mod_evasive oder mod_security greifen intern nicht.

Grüße
Sinepp

 

[marneus]

Nun ja, Sachen wie

while (1==1) { rand(0,10); }

könnte man z.B. mit der MaxExecutionTime vom Ausmaß her ein wenig reduzieren.

 

[samy-delux]

Das meinte ich jetzt nicht...
Ich meinte dass ein böser Junge auf seinem eigenen Rechner folgendes ausführt:

<?php
while(true) {
     readfile("http://meinserver.de/");
}
?>

Das ist meiner Meinung nach eine Denial of Service Attacke.
Wie kan ich dies am besten verhindern. Mod_evasive greift da nicht, da es in dem Moment egal ist ob Error 403 Seiten oder wirkliche Seiten zurückgeliefert werden.
Hat jemand erfahrung ob das hier greifen würde?

Am besten wäre, wenn die Firewall einfach nur 5 Requests pro Sekunde von einer IP zulässt. Oder schieße ich mir da auch wieder selbst ins Knie ?

Wie kan ich so einen Skript Kiddie ****** wie da oben am besten blocken?

 

[marneus]

Die von dir genannte Methode wäre z.B. mit mod_evasive zu blocken. modsec2iptables ist durch das Zusammenspiel von mod_security und mod_evasive plus Aussperren via IPTABLES ganz bestimmt im Stande solche DoS-Attacken zu erkennen und abzuwehren.

 

[samy-delux]

Mod_security blockt das ab, da kein User Agent gesendet wird.
Problem gelöst!

 

[mgutt]

Ich suche gerade auch was und bin über Google wieder hier her gekommen

mod_security hilft bei Anfragen ohne User-Agent, aber was wenn jemand einfach mit fsockopen einen eigenen User-Agent fabriziert hat und damit eine Schleife durchläuft?

Aktuell finde ich nur Sache mit MySQL und timestamps, aber sowas wäre ja erst Recht der Tod für die Seite ^^

Gibt es noch andere performante Techniken, um DoS relativ automatisiert in den Griff zu kriegen?

Eine Idee, die mir kam, aber die ich mangels Rechten nicht umsetzen kann:
- man liest bei jedem Aufruf im Footer den Load
- übersteigt der Load den Faktor x liest man die aktuellen IPs aus, die auf den Apache zugreifen
- es wird die IP gekickt die mehr als x mal vorkommt und insgesamt auch am häufigsten in der Liste steht
- diese IP wird temporär für 24h gesperrt

So hätte man auch kein Problem mit Suchmaschinen-Crawlern.

 

[IP-Projects.de]

mm. Korrigiert mich wenn das nicht stimmt, aber ist es nicht so, dass Apache Anfragen von einer IP Limitiert, daher kann man doch einstellen, dass Apache z.B. maximal 5 Verbindungen von einer IP Adresse zulässt. Somit kann doch bei solch stupiden Vorgehen normal nichts passieren.

Kommt ein Angriff von einem Botnetz sieht das natürlich anders aus, das wird aber dann durch Security Module erkannt wie mod_evasive, hierbei wird dann die Anfrage an eine 403 Seite weitergeleitet. Wenn die Max Livetime der Anfrage in der apache2.conf dann auf 5 Sekunden gesetzt wird, muss der Angriff schon über ein sehr großes Botnetz erfolgen, bevor das Apache interessiert.

Eine richtige Deny of Service Attacke kann man aber immer noch effektiv nur extern abwehren. Ist die Paketflut bereits auf dem Server, ist es schon zu spät. Externe Firewalls wie Ciscos ASA bieten sich hier an, dass zumindest die Dienste bei einem Angriff nicht anfällig werden.

 

[mgutt]

Ich halte DDoS-Abwehrmaßnahmen für wenig sinnvoll, da man gegen diese eigentlich eh machtlos ist. Effektiv kann man nicht zwischen gehijackten und normalen Besucher unterscheiden. Falls eine solche Attacke eingeleitet wird, hilft eigentlich nur abschalten von bestimmten Länder-IPs, wenn man das Glück hat und diese aus dem Ausland kommen. Das ist weit aus performanter, als mit einem pauschalen Anfangsverdacht den allgemeinen Betrieb zu scannen.

Dann zu der genannten Limitierung. Wie heißt diese Option, wie performant ist diese und wie geht sie mit den guten um, wie z.B. Yahoo, Google oder Bing?

 

[IP-Projects.de]

Naja also nicht ganz. Man hängt so ein Firewall kästchen nicht nur davor um einen DDOS Angriff zu blockieren, sondern dafür sorge zu tragen, dass dadurch die Dienste auf dem Server selbst nicht beeinträchtigt werden. Für die Zeit eines DDOS Angriffs ist der Server nicht erreichbar das ist fakt. Wenn da ein Angriff mit 5 Gbit gefahren wird und der Server mit 100 Mbit an der Leitung hängt, ist das klar.

Hängt man aber so ein kleines Kästchen zwischen Switch und Server, landet die Paketmasse auf dem kleinen Kästchen. Ein Ausfall der Dienste auf dem Server ist daher nicht gegeben was auch gut so ist. Denn erfolgt so ein Angriff und der Server hängt, könnte eine Dateninkonsistenz entstehend z.B. wenn sehr viele Datenbankabfragen laufen könnten Tabellen der Datenbank beschädigt werden.

Kleine Paket flood geschichten wir in diesem Fall auf den Apache Server, werden durch die Firewall natürlich blockiert, hier geht es nur um richtige effektive Deny of Service Attacken.

 

[mgutt]

Diese Kiste wie Du sagst, produziert eine ständig vorhandene Latenz.

Da kannst Du auch zum Zeitpunkt des Angriffs den 80er Port schließen. Der Effekt ist der gleiche.

Die Datenbank schützt sich selbst, wenn man z.B. InnoDB einsetzt, was sowieso zu empfehlen ist, da es jederzeit zu einem Ausfall kommen kann.

Wie gesagt:
Hier geht es nur um DoS. Es geht um einen möglichst performanten Schutz vor Scriptkiddies. Und mod_security ist weder performant, noch performanceschonend, wie ich bereits ermittelt habe.

Bei einem Rootserver habe ich das ganze schon getestet. Man kann über uptime den aktuellen Load auslesen und dann bei Load 3 z.B. über netstat gezielt IPs rauskicken. Damit das ganze möglichst performant läuft, liest man den Load per Zufall aus mit einer Chance von 1:100 oder 1:1000 je nachdem wie viele Seitenaufrufe man generiert.

Die IPs sperrt man für 24h, damit die Guten automatisch wieder reinkommen und normalen Usern könnte man ein Captcha auswerfen, mit dem sie sich wieder freischalten können.

Zusätzlich könnte man zeitweise die gesperrten IPs sichten und eine Whitelist für die Guten bauen.

Leider erhalte ich bei meinen Managed Servern keinen Zugriff auf uptime oder netstat

 

[IP-Projects.de]

Diese Kiste wie Du sagst, produziert eine ständig vorhandene Latenz.

Da kannst Du auch zum Zeitpunkt des Angriffs den 80er Port schließen. Der Effekt ist der gleiche.

Die Latzenz ist wohl das geringste.

Sobald die Paketflut den Server erreicht, sperrst du keinen Port 80 mehr Und was machst du gegen eventuell auftretende Sicherheitslücken im Zuge der Deny of Service Attacke? Wenn sich aufgrund der Last, Verzögerungen in der Anwendung auftun, welche es erlauben Datenstreams mit Userdaten herauszufiltern?

Solche Firewall Kästchen gibt es nicht zum Spaß, das hat schon alles einen tieferen Sinn.

 

[Huschi]

dass Apache Anfragen von einer IP Limitiert, daher kann man doch einstellen

Lieferst Du uns auch noch die exakten Direktiven dazu?
Ich kenne die bisher nicht und denke es ist lediglich als Modul (z.B. mod_limitipconn) nach installierbar.

Kommt ein Angriff von einem Botnetz sieht das natürlich anders aus, das wird aber dann durch Security Module erkannt wie mod_evasive

Gerade gegen Botnetze kann mod_evasive fast nichts mehr ausrichten.

Wenn die Max Livetime der Anfrage in der apache2.conf dann auf 5 Sekunden gesetzt wird

Nochmal: wie lautet die exakte Direktive dazu?

Externe Firewalls wie Ciscos ASA bieten sich hier an, dass zumindest die Dienste bei einem Angriff nicht anfällig werden.

Dem kann ich allerdings zustimmen.

Ich halte DDoS-Abwehrmaßnahmen für wenig sinnvoll

Gegen die ursprüngliche Fragestellung hier im Thread reicht ein mod_evasive.

Effektiv kann man nicht zwischen gehijackten und normalen Besucher unterscheiden.

Effektiv nicht, aber heuristisch gesehen klickt kein echte User 20mal in der Sekunde auf den selben Link. Und genau diese sperrt mod_evasive aus.

Das größte Problem sind aktuell die Botnetze. Und wenn die einen Server auf den Kiker haben, macht meistens der Provider die Schleusen bereits auf einem Router dicht um seine Infrastruktur zu schützen.
Hier hat also jede Maßnahme am Server selbst keine Chance mehr.

huschi.

 

[IP-Projects.de]

Zitat:
Zitat von IP-Projects.de Beitrag anzeigen
dass Apache Anfragen von einer IP Limitiert, daher kann man doch einstellen
Lieferst Du uns auch noch die exakten Direktiven dazu?
Ich kenne die bisher nicht und denke es ist lediglich als Modul (z.B. mod_limitipconn) nach installierbar.

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 5

ok keine IP Zugriffsbegrenzung sondern Requests von einer Verbindung. Habe ich mich vertan.

Zitat:
Kommt ein Angriff von einem Botnetz sieht das natürlich anders aus, das wird aber dann durch Security Module erkannt wie mod_evasive
Gerade gegen Botnetze kann mod_evasive fast nichts mehr ausrichten.

Da habe ich andere Erfahrungen gemacht. Wir hatten den Fall, dass ein Forum eines Kunden regelmäßig über verschiedene Botnetze geflutet wurde. Dank Spamhouse und Mod Evasive ist alles wieder im grünen Bereich.

Zitat:
Wenn die Max Livetime der Anfrage in der apache2.conf dann auf 5 Sekunden gesetzt wird
Nochmal: wie lautet die exakte Direktive dazu?

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 2

 

[Huschi]

Also Deine Apache-Kenntnisse sind weit unter den Erwartungen die man an einen Webhoster/Server-Provider hat.
MaxKeepAliveRequests als auch KeepAliveTimeout haben nichts (oder genauer: absolut gar nichts!!!) mit einer Limitierung von IP oder sonstigen Zugriffsbegrenzungen zu tun. Beide Direktiven behandeln lediglich das KeepAlive-Verhalten von HTTP/1.1.

Da habe ich andere Erfahrungen gemacht.

Man kann sich jetzt über "Erfahrungen" streiten. Auch ich erkenne mod_evasive mit einer absoluten Daseinsberechtigung an. Allein schon um kleinere DoS-Angriffe abzuwehren.
Aber es kommt auch auf die Art der Angriffe an und auf die Größe des Botnet. Z.B. ein Synflood-Angriff kommt erst gar nicht bis zu einem Apache-Modul. Aber setzt ihn dennoch außer Gefecht.

huschi.

 

[IP-Projects.de]

Also Deine Apache-Kenntnisse sind weit unter den Erwartungen die man an einen Webhoster/Server-Provider hat.
MaxKeepAliveRequests als auch KeepAliveTimeout haben nichts (oder genauer: absolut gar nichts!!!) mit einer Limitierung von IP oder sonstigen Zugriffsbegrenzungen zu tun. Beide Direktiven behandeln lediglich das KeepAlive-Verhalten von HTTP/1.1.

Was ich so auch in der Aussage korrigiert habe.

 

[Huschi]

*Augenzwinker*

huschi.