DDoS aufs SSF?

Ein HTTP 503 ist immerhin gemäss HTTP-Specs, Dein DROP hingegen nicht.

Wie bereits mitgeteilt, nennt sich DDoS Mitigation und tut seinen Dienst bei einigen Instanzen seit Aufnahme des Produktivbetriebs (Anfang 2014) sehr gut. Desweiteren ist der DROP bei illegitimen Clients durchaus legitim. Der einzige, der sich bis jetzt beschwert und wohl aufgrund fehlender Fachkenntnis im Umgang mit DDoS falsche Tatsachen aufstellt, bist hauptsächlich du.

Wir verarbeiten damit ein paar mehr Requests als dein 50€ Rootserver, der mit den 2,5Gbit Clean Traffic während Peakzeiten vermutlich überhaupt nicht klar kommt :)
 
Deine Beispielseite für aktiven DDoS-Mitigation ala Cloudflare wirft einen ordnungsgemässen 503, während Deine Frickellösung schlicht DROPed und damit dem Nutzer jegliche Möglichkeit zum Debugging nimmt.

Hast Dich mit Deinem Beispiel wohl vergallopiert...

BTW: Mein Lynx ist ein legitimer Client und wird von Dir gedropped, da darf ich mich wohl zu Recht beschweren.

BTW2: Ich bin nicht allein mit meinen Beschwerden, vielleicht solltest Du den Thread nochmal lesen. Per Mail bekomme ich darüberhinaus mehrere Nachfragen von Screenreader und Braile Nutzern, warum das SSF sie aussperrt. Da weder Thorsten noch Joseph eine akzeptable Antwort darauf liefern, verteile ich diese teils langjährigen (Ex-)SSF-Nutzer nun auf andere Foren mit fähigerer Administration.
 
Da weder Thorsten noch Joseph eine akzeptable Antwort darauf liefern, verteile ich diese teils langjährigen (Ex-)SSF-Nutzer nun auf andere Foren mit fähigerer Administration.
Definier "nicht akzeptabel" und warum einer der beiden, wovon mind. einer unterwegs ist und der andere von der Zeit her Theoretisch noch an seinem Hauptarbeitsplatz sitzen könnte, das bis jetzt hätte Debuggen müssen? Seit wann gibt es denn die Beschwerden?
Funktionieren die Reader denn mit der "I'm under attack" Einstellung in Cloudflare?

Edit: Nicht falsch verstehen. Ich will keinen Streit mit irgendjemandem hier oder SSF in den Hintern kriechen. Mir geht es nur um das Verständnis bzw. sachliche Begründung. SSF hat, zum vergleich, ja nie eine Lesbarkeits/Behindertenfreundlich (ich mag das Wort nicht aber so nennt man es nun mal) Garantie gegeben.
 
Last edited by a moderator:
Trolle soll man nicht füttern, mehr fällt mir dazu nicht mehr ein. Insofern jemand ein Problem hat, kann er sich gerne per PN melden, ich werde die Diskussion mit Markus aka Joe User nicht weiter fortführen - es führt eh zu nichts außer dummen Kommentaren und Unsachlichkeit :)
 
Cloudflare erlaubt zwar das Dumpen von Head, der Request wird ohne Cookies und Javascript jedoch noch immer geblockt. Damit ist deine These, es würde woanders reibungslos funktionieren, hinfällig.
Ich glaube, er meint damit eher das Basic-Filtering von CloudFlare wie z.B. die Header genauestens überprüfen ob diese verdächtig aussehen, das Verhalten einer einzigen IP-Adresse genau analysieren, etc.

Natürlich filtert das nicht *alles*, daher gibt es ja bei CloudFlare auch verschiedene Mitigations-Stufen, aber diese Basis-Dinge wie XMLRPC filtert man bereits ohne irgendeine JavaScript-Check Seite aufzubauen.

Nenn mich Paranoid, aber ich musste mir den JavaScript Code herauskratzen und eben einen decoder schreiben, der diesen "DDoS Protection" dreck umgeht, weil ich auf sehr wenig seiten überhaupt JavaScript aktiviert habe. Und die Tatsache, dass ich den decoder innerhalb von 2 Minuten zusammengeschrieben hatte lässt diese "DDoS Protection" sehr klein aussehen wenn der Attacker auch weiß wie das funktioniert, denn dann gibts eben kein XMLRPC Angriff sondern eben irgendwas anderes.

Link11 kann, genauso wie CloudFlare, auch sehr gut Layer-7 Attacken filtern und braucht nicht so eine JavaScript Check Seite. Selbiges z.B. auch mit Prolexic.
 
Last edited by a moderator:
Natürlich filtert das nicht *alles*, daher gibt es ja bei CloudFlare auch verschiedene Mitigations-Stufen, aber diese Basis-Dinge wie XMLRPC filtert man bereits ohne irgendeine JavaScript-Check Seite aufzubauen.

Das ist mir bewusst, es folgen jedoch in der Regel auf eine Attacke ganz andere Angriffsmuster, welche sich wesentlich unterscheiden.

Verschiedene Mitigationsstufen gibt es auch bei uns, angefangen mit Cookie Verification bis hin zu Captcha's. Letzteres ist für Härtefälle am besten geeignet.


Nenn mich Paranoid, aber ich musste mir den JavaScript Code herauskratzen und eben einen decoder schreiben, der diesen "DDoS Protection" dreck umgeht, weil ich auf sehr wenig seiten überhaupt JavaScript aktiviert habe. Und die Tatsache, dass ich den decoder innerhalb von 2 Minuten zusammengeschrieben hatte lässt diese "DDoS Protection" sehr klein aussehen wenn der Attacker auch weiß wie das funktioniert, denn dann gibts eben kein XMLRPC Angriff sondern eben irgendwas anderes.

Insofern, kann ich mir das Script mal ansehen? Dann gucken wir mal, was sich unsererseits optimieren lässt und ob es überhaupt erforderlich ist, großartige Optimierungen vorzunehmen.

Link11 kann, genauso wie CloudFlare, auch sehr gut Layer-7 Attacken filtern und braucht nicht so eine JavaScript Check Seite. Selbiges z.B. auch mit Prolexic.

Das ist mir bei beiden neu, hast du es getestet oder selbst verifiziert? Gerade Link11 ist in der Vergangenheit nur bedingt mit Layer7 klar gekommen. Cloudflare kommt ohne UAT Mode jedoch auch nur bedingt mit GET/POST Flood klar :rolleyes:
 
Wie viel mag dein Server ertragen ? Würde mich interessieren ob ich bezüglich meinen Kosten besser drannen bin mit meiner Config als du oder nicht ;)

Ich bin die letzten Tage nur wenig online gewesen und deshalb habe ich vieles hier nur überflogen...aber interpretiere ich das richtig, daß der Angriff auf deinem Mist gewachsen ist?
Wenn ich jetzt daneben liegen sollte, sorry...aber wenn ich richtig liege: Was bringt dir das Ganze?
 
Guten Abend zusammen,

auch auf die Gefahr hin, mich unbeliebt zu machen: Ich bin einigermaßen schockiert über diverse eurer Kommentare. (Wohlgemerkt nicht über alle!) Feedback ist ohne Frage wichtig und sicher gibt es an der momentanen DDoS-Protection Dinge, die optimiert werden können und ggf. sollten. Was hier aber einige vergessen zu scheinen:

- Joseph (virtual2) hat freiwillig und unentgeltlich das Forum, an welchem wir offensichtlich alle gerne teilnehmen, binnen kürzester Zeit wieder online gebracht. Die Alternative wäre gewesen, es schlichtweg erstmal offline zu lassen. Eher wenige Administratoren (egal mit welcher Spezialisierung) bewegen sich, ohne die Arbeitszeit in Rechnung zu stellen. Das kann man ruhig einfach mal so wie es ist anerkennen; was nun nicht heißt, dass man nicht auch Kritik äußern darf.

- 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?

- 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.

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.

- 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.

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?

Nichts für ungut :)


Viele Grüße
Tim
 
Last edited by a moderator:
Ich bin die letzten Tage nur wenig online gewesen und deshalb habe ich vieles hier nur überflogen...aber interpretiere ich das richtig, daß der Angriff auf deinem Mist gewachsen ist?
Wenn ich jetzt daneben liegen sollte, sorry...aber wenn ich richtig liege: Was bringt dir das Ganze?

Nein, kommt nicht von mir.
Kein ding, bist nicht der erste welcher mich bechuldig
 
Definier "nicht akzeptabel"
Von Thorsten h�tte ich erwartet, dass er sich an den ersten Grundsatz der System-Administration h�lt: Don't panic!
Auch das hier permanent gepredigte "Du brauchst einen Ersatzadmin wenn Du nicht selbst eingreifen kannst" h�tte er meiner Meinung nach beherzigen k�nnen.
Stattdessen schiebt er Panik und greift blind zum ersten sich ihm anbietenden Billigangebot und erh�ht damit den Schaden, da ihm dadurch mehrere regelm�ssige Nutzer abgesprungen und etliche weitere ver�rgert sind.
Mit k�hlem Kopf und gegebenenfalls etwas Downtime w�re der Schaden erheblich kleiner bis kaum bemerkbar gewesen.
Ja, die Kritik ist sowohl gerechtfertigt, als auch etwas zu hart, aber Thorsten wird Ersteres nachvollziehen k�nnen und Letzteres wird er mir zumindest eine Zeit lang �bel nehmen. Ich kann damit leben und Thorsten vermutlich auch (irgendwann).

Von Joseph aka virtual2 h�tte ich erwartet, dass er die Kritik ernst nimmt und seinen Dienst entsprechend anpasst. Letzteres ist problemlos m�glich, schliesslich k�nnen seri�se Anbieter ala Akamai es auch.

Seit wann gibt es denn die Beschwerden?
Seitdem das SSF diesem MitM ausgesetzt ist.

Funktionieren die Reader denn mit der "I'm under attack" Einstellung in Cloudflare?
Sie liefern entweder eine passende Fehlermeldung dank des 503 von Cloudflare oder sie funktionieren dort.

Edit: Nicht falsch verstehen.
Keine Sorge, Du bleibst ja sachlich.

SSF hat, zum vergleich, ja nie eine Lesbarkeits/Behindertenfreundlich (ich mag das Wort nicht aber so nennt man es nun mal) Garantie gegeben.
Richtig.
Aber ein Dienstleister, der vors�tzlich unschuldige legitime Nutzer und insbesondere Behinderte aussperrt, der geh�rt offen angeprangert und im Zweifel auch wegen Diskrimminierung und/oder N�tigung angezeigt. Und genau das macht Joseph mit seinem "DDoS-Mitigation"-Service.
 
Nein, kommt nicht von mir

Wie schon eben gesagt, Sry

Kein ding, bist nicht der erste welcher mich bechuldig

War jetzt auch nicht als Beschuldigung gedacht, sondern lediglich eine (scheinbar falsche) Schlußfolgerung aufgrund des von Milchbroetchen zitierten Threads.

Unabhängig davon frage ich mich trotzdem, welchen Sinn sowas machen soll...?
Ich würde es ja noch verstehen, wenn ein Online-Shop oder andere gewinnbringende Seiten attackiert werden, um dem Seitenbetreiber auf diese Weise materiellen Schaden zuzufügen...aber hier beim SSF sind doch nur die User die Leidtragenden...:confused:
 
Ich werde die durch den "DDoS-Mitigation"-Service verursachten kaputten Umlaute in meinen Beiträgen absichtlich nicht korrigieren.
 
Unabhängig davon frage ich mich trotzdem, welchen Sinn sowas machen soll...?
Ich würde es ja noch verstehen, wenn ein Online-Shop oder andere gewinnbringende Seiten attackiert werden, um dem Seitenbetreiber auf diese Weise materiellen Schaden zuzufügen...aber hier beim SSF sind doch nur die User die Leidtragenden...:confused:
Seitdem ich hier offen gegen den "DDoS-Mitigation"-Service von Joseph argumentiere, steht mein Serverchen ebenfalls "unter Beschuss" ;)
 
Insofern, kann ich mir das Script mal ansehen? Dann gucken wir mal, was sich unsererseits optimieren lässt und ob es überhaupt erforderlich ist, großartige Optimierungen vorzunehmen.
Ablauf:
Code:
› curl http://serversupportforum.de/
<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|6bd88cd66f7f1398bdda9b65dad1a952e3f63c35|challenge|age|3600|path|window|location|reload'.split('|'),0,{}))
</script>
</body>
<meta http-equiv="refresh" content="3">
</html>

› curl -s http://serversupportforum.de/ | fgrep 'eval('
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|6bd88cd66f7f1398bdda9b65dad1a952e3f63c35|challenge|age|3600|path|window|location|reload'.split('|'),0,{}))

› jsc
> var evilscript = 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|6bd88cd66f7f1398bdda9b65dad1a952e3f63c35|challenge|age|3600|path|window|location|reload'.split('|'),0,{})
undefined
> console.log(evilscript);
function challenge(){document.cookie='layer7-ddos-protection=6bd88cd66f7f1398bdda9b65dad1a952e3f63c35; max-age=3600; path=/';window.location.reload()}
undefined
>

Ich hab bei evilscript eben den Javascript Code hier genommen, "eval(" am Anfang und ")" am Ende entfernt, in eine Variable gepackt und mir die Funktion als String ausgeben lassen.

Da ich also nun weiß, was das Script wirklich macht und wie das Cookie zusammengesetzt wird, eben Fix das Script zusammengeschrieben (in dem Fall lass ich mir dann aber nicht die Function parsen und dann ausgeben sondern hol mir die Werte lieber direkt mit Regex aus dem HTML Code heraus):

Code:
#!/usr/bin/env node

var request = require('request');

request('http://serversupportforum.de/', function (err, res, body) {
        var asdf = body.replace(/\r\n|\r|\n/gm, '').match(/.*max\|function\|document\|cookie\|layer7-ddos-protection\|(.*)\|challenge\|age\|(.*)\|path\|window\|location\|reload.*/);
        var cookie = 'layer7-ddos-protection=' + asdf[1] + '; max-age=' + asdf[2] + '; path=/';
        console.log(cookie);
        console.log('Run this in your browsers developer console:');
        console.log('document.cookie=\'' + cookie + '\';');
});

Das Script ausgeführt resultiert also in:

Code:
› node Projects/h3Bs/index.js
layer7-ddos-protection=6bd88cd66f7f1398bdda9b65dad1a952e3f63c35; max-age=3600; path=/
Run this in your browsers developer console:
document.cookie='layer7-ddos-protection=6bd88cd66f7f1398bdda9b65dad1a952e3f63c35; max-age=3600; path=/';


Das ist mir bei beiden neu, hast du es getestet oder selbst verifiziert? Gerade Link11 ist in der Vergangenheit nur bedingt mit Layer7 klar gekommen. Cloudflare kommt ohne UAT Mode jedoch auch nur bedingt mit GET/POST Flood klar :rolleyes:
Link11 filterte bisher Attacken auf technobase.fm sehr gut, sind aber nun auf einen anderen Provider umgestiegen. Gründe sind mir unbekannt, da ich nichts mehr damit zu tun habe.
 
Das Script ausgeführt resultiert also in:

Code:
› node Projects/h3Bs/index.js
layer7-ddos-protection=6bd88cd66f7f1398bdda9b65dad1a952e3f63c35; max-age=3600; path=/
Run this in your browsers developer console:
document.cookie='layer7-ddos-protection=6bd88cd66f7f1398bdda9b65dad1a952e3f63c35; max-age=3600; path=/';

Ein Zugriff war damit möglich? Kann ich mir ehrlich gesagt nicht vorstellen, da der Cookie alle paar Sekunden durch einen random hash getauscht wird.
 
Ein Zugriff war damit möglich? Kann ich mir ehrlich gesagt nicht vorstellen, da der Cookie alle paar Sekunden durch einen random hash getauscht wird.
Es funktioniert für ca. eine Stunde, dann muss ein neuer Cookie gesetzt werden.

Funktioniert so übrigens auch mit cURL:

Code:
› curl -v -b "$(node x.js)" http://serversupportforum.de/
*   Trying 5.1.74.67...
* Connected to serversupportforum.de (5.1.74.67) port 80 (#0)
> GET / HTTP/1.1
> Host: serversupportforum.de
> User-Agent: curl/7.42.1
> Accept: */*
> Cookie: layer7-ddos-protection=af200caf2a3ef6ecae66e9d635ff8cd299cac7a9; max-age=3600; path=/
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 24 Sep 2015 20:01:54 GMT
< Content-Type: text/html; charset=ISO-8859-1
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.11
< Set-Cookie: bblastvisit=1443124891; expires=Fri, 23-Sep-2016 20:01:31 GMT; Max-Age=31535999; path=/
< Set-Cookie: bblastactivity=0; expires=Fri, 23-Sep-2016 20:01:31 GMT; Max-Age=31535999; path=/
< Cache-Control: private
< Pragma: private
< X-UA-Compatible: IE=7
< Vary: Accept-Encoding
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html dir="ltr" lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<!--

        <meta http-equiv="Cache-Control" content="no-cache" />
        <meta http-equiv="Pragma" content="no-cache" />
        <meta http-equiv="Expires" content="0" />

-->

<title>Server Support Forum </title>

----- CUT -----

<!-- End Piwik Code --><!-- vBadvanced 2-2-3-6 -->

</body>
* Connection #0 to host serversupportforum.de left intact
 
Es funktioniert für ca. eine Stunde, dann muss ein neuer Cookie gesetzt werden.

Funktioniert so übrigens auch mit cURL:

Code:
› curl -v -b "$(node x.js)" http://serversupportforum.de/
*   Trying 5.1.74.67...
* Connected to serversupportforum.de (5.1.74.67) port 80 (#0)
> GET / HTTP/1.1
> Host: serversupportforum.de
> User-Agent: curl/7.42.1
> Accept: */*
> Cookie: layer7-ddos-protection=af200caf2a3ef6ecae66e9d635ff8cd299cac7a9; max-age=3600; path=/
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 24 Sep 2015 20:01:54 GMT
< Content-Type: text/html; charset=ISO-8859-1
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Powered-By: PHP/5.5.9-1ubuntu4.11
< Set-Cookie: bblastvisit=1443124891; expires=Fri, 23-Sep-2016 20:01:31 GMT; Max-Age=31535999; path=/
< Set-Cookie: bblastactivity=0; expires=Fri, 23-Sep-2016 20:01:31 GMT; Max-Age=31535999; path=/
< Cache-Control: private
< Pragma: private
< X-UA-Compatible: IE=7
< Vary: Accept-Encoding
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html dir="ltr" lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<!--

        <meta http-equiv="Cache-Control" content="no-cache" />
        <meta http-equiv="Pragma" content="no-cache" />
        <meta http-equiv="Expires" content="0" />

-->

<title>Server Support Forum </title>

----- CUT -----

<!-- End Piwik Code --><!-- vBadvanced 2-2-3-6 -->

</body>
* Connection #0 to host serversupportforum.de left intact

Dann ist der Fix für uns recht einfach, danke dir für den Hinweis ;)
 
Back
Top