Bronies.de Technische Probleme Hilfe-Thread

[mrx1983]

(13.01.2014)Conqi schrieb:  Ich hab ein Problem mit dem Erreichen der Seite seit Cloudflare wieder aktiv ist, wenn ich übers Smartphone rein will. Hab ein Lumia 925 mit Windows Phone 8 und nutze den Browser UCBrowser. Die Seite wird fast sofort als nicht erreichbar angezeigt und das wars. Mit dem standardmäßigen Internetexplorer geht es, was mich noch mehr verwundert, denn afaik müssen alle Browser auf WP8 den IE als Unterbau benutzen (wie bei iOS mit Safari).

Ich tippe mal drauf, das gerade mobile Browser irgendwie durch den Check fallen, weil halt irgendwas fehlt was die normalen Browser haben.
Od. zu langsam reagieren.
Oder vielleicht der Useragent String für Cloudflare suspekt ist.
Aber hab das jetzt schon von mehreren gehört, Mobil scheint bei vielen nicht mehr zu gehen.

[Saij]

Normal lässt sich eig. der Cloudflare Browser Check durch Cookies und JS parsing auch maschinell umgehen. Daher finde ich ihn nicht wirklich sinnvoll (vorallem weil er schonmal nichts gebracht hat)

[mrx1983]

(13.01.2014)Saij schrieb:  Normal lässt sich eig. der Cloudflare Browser Check durch Cookies und JS parsing auch maschinell umgehen. Daher finde ich ihn nicht wirklich sinnvoll (vorallem weil er schonmal nichts gebracht hat)

Ist wohl eine Notlösung, kann mir aber auch gut vorstellen, wenn man genug Aufwand reinsteckt, das man auch das wieder umgehen kann.

[Piet.Lu]

zumal es ohne diesen "nicht wirklich sinnvollen" Schutz derzeit doch auch das Licht hier aus wäre....
jeder Mechanismus lässt sich umgehen, das ist klar, aber solange es doch läuft, läufts ^^

[C#*~5]

(13.01.2014)Piet.Lu schrieb:  

(13.01.2014)Corus schrieb:  Dieser ständige IP-Check nervt schon ziemlich

hmm, die 5 Sekunden sind jetzt nicht der Weltuntergang
Und solange das Forum dadurch am leben bleibt, hab ich da nichts gegen

Bla. Wie gesagt, mobil teilweise deutlich länger. Hab auch schon mal ne Minute gewartet. Und nur um mal kurz die Seite aufzurufen, ist mir das deutlich zu lang.

[mrx1983]

Jo ist momentan besser wie nichts, das stimmt ^^

[Evenprime]

(13.01.2014)Saij schrieb:  Normal lässt sich eig. der Cloudflare Browser Check durch Cookies und JS parsing auch maschinell umgehen. Daher finde ich ihn nicht wirklich sinnvoll (vorallem weil er schonmal nichts gebracht hat)

Ich bin für Alternativen gern zu haben. Wir sind allerdings schon bei Ovh und deren System fängt diese Angriffe halt nicht ab.

Serverseitige Erkennung der nicht menschlichen Requests haben wir schon probiert, dafür sind diese aber pro IP zu wenige und insgesamt zu viele, sprich entweder tonnenweise false positives oder drr Server ist dicht.

[Conqi]

(13.01.2014)mrx1983 schrieb:  Aber hab das jetzt schon von mehreren gehört, Mobil scheint bei vielen nicht mehr zu gehen.

Mit dem IE geht´s wie gesagt, also kann ich damit aktuell noch relativ gut leben. Nervig ist es trotzdem. Vor allem meine ich, dass es zwischendurch sogar einmal ging, aber was soll´s.

[LightningGear]

(13.01.2014)Conqi schrieb:  

(13.01.2014)mrx1983 schrieb:  Aber hab das jetzt schon von mehreren gehört, Mobil scheint bei vielen nicht mehr zu gehen.

Mit dem IE geht´s wie gesagt, also kann ich damit aktuell noch relativ gut leben. Nervig ist es trotzdem. Vor allem meine ich, dass es zwischendurch sogar einmal ging, aber was soll´s.

Also auf meinem iPhone geht es über den Safari-Browser. Aber erst, nachdem ich zweimal den Check neugestartet hab und drei Minuten vergangen sind. Nervig, aber wohl nicht so einfach zu ändern.

[Atra Demonica]

Naja schon wenn die Angreifer es ebeb einfach lassen.

@saij: Deswegen, weil es umgänglich ist, ist das ja nicht mehr nur der Einzige Schutz. Ist halt aber alles recht nervig.

[Saij]

(13.01.2014)Evenprime schrieb:  

(13.01.2014)Saij schrieb:  Normal lässt sich eig. der Cloudflare Browser Check durch Cookies und JS parsing auch maschinell umgehen. Daher finde ich ihn nicht wirklich sinnvoll (vorallem weil er schonmal nichts gebracht hat)

Ich bin für Alternativen gern zu haben. Wir sind allerdings schon bei Ovh und deren System fängt diese Angriffe halt nicht ab.

Serverseitige Erkennung der nicht menschlichen Requests haben wir schon probiert, dafür sind diese aber pro IP zu wenige und insgesamt zu viele, sprich entweder tonnenweise false positives oder drr Server ist dicht.

Serverseitige Erkennung bringt nichts auf Layer 4. Höchstens auf Layer 7 - aber auch da wird es schwer wenn das Netzwerk davor einfach überlastet ist.
Und soviel weiss ich: Layer 4 und Layer 7 scheinen die bevorzugten Angriffspunkte zu sein. Ist aber nur eine Einschätzung von mir durch meine Kenntnisse.

Eine Möglichkeit wäre noch ein Heartbeat DNS LoadBalancing. Benötigt halt ziemlich viele Server (einen für die Datenbank und für den Master DNS der halt immer geshared sein muss (wobei man über Replikation auch versuchen kann mit 2+ DB Servern zu arbeiten was aber die Sache sehr sehr wackelig macht gerade bei vielen Schreibzugriffen) und Nodes in unterschiedlichen Netzen welche die eigentliche Seite sharen). Außerdem hebelt es das DNS Caching System aus und erzeugt durch die DNS Anfragen wieder Last (was sich aber durch mehrere Secondary DNS gut aufteilen/lösen lässt).

Man stellt hierbei den TTL der Zone auf ein sehr geringen Wert ein (müsste man forschen was so der niedrigste Wert ist der bei den großen Providern als TTL durchgeht) und wechselt dann jedesmal die IP hinter http://www.bronies.de bzw. bronies.de auf einen Server, der aktuell nicht unter Beschuss steht. In Zusammenarbeit mit Cloudflare sollte sich das sogar recht gut ohne große Änderungen am DNS System machen lassen sofern Cloudflare eine entsprechende API hat um die IPs bei denen intern umzubiegen.
Bringt aber nur was wenn die Nodes in unterschiedlichen Netzen (am besten sogar komplett Weltweit) verteilt sind. So gibt es immer wieder einen Node, der nicht angegriffen wird und daher erreichbar ist und das Forum ausliefern kann.

Mit OVH wird ja schon Layer 4 recht gut abgesichert. Das Problem dürften die Layer 7 Angriffe sein. Die kann OVH nicht einfach filtern, weil es eben korrekte Requests sind, welche halt nur zuhauf kommen. Da gibt es kein direkten Unterscheidungsmerkmal. Wenn ihr die Möglichkeit habt die Firewalls bei OVH einzustellen (was afaik bei DDoS Schutz Pro geht) könntet ihr die Anzahl der aufzubauenden Verbindung pro IP auf einen recht kleinen Wert setzen (alles andere wird dann gedroppt). Braucht halt wieder ein Netz mit genug Bandbreite. Und das wird immer das Problem sein wenn man die Requests nicht auf mehrere Netze aufteilen kann.

Selbst ein eigenes Rack mit Hardware LoadBalancer wird da schnell angreifbar sein.

Was man auch mal "erforschen" könnte, wäre die Tatsache wie das z.B. Google und einige IRC machen: multiple A Records mit Wertigkeiten. Da bin ich bis jetzt nur mal oberflächig drauf gestoßen und hab keine weiteren Informationen inwiefern Browser/Betriebssysteme dann auf eine andere IP umschwenken. (Hier mal eine Antwort/Frage auf stackexchange.com die sagt das es möglich sein soll: http://webmasters.stackexchange.com/ques...e-than-one)

Das sind so ein paar Dinge über die ich mir mal Gedanken gemacht hab. Ich weiss halt nicht was ihr schon alles probiert habt und wie euer Setup atm aussieht und vorallem wie viel Geld in Abwehrmaßnahmen gesteckt werden soll.

Aber ich denke mit 4-5 vServern in den mittleren Preissegmenten (so ca. 20€) kann man da schon die Heartbeat Variante einigermaßen gut fahren. Vorallem weil sich da die Last auch aufteilen lässt.

Und selbst wenn man versucht mit 2 oder 3 Root Servern die Multiple A Record oder Cloudflare API Variante zu fahren sollte sich das schon gut lohnen (und auch hier wieder eine gute Lastverteilung möglich machen was auch kleinere Maschinen bedeutet). Besonders die DB Maschine kann dann wirklich gut auf die DB angepasst werden (mehr RAM, weniger CPU) und die Webserver dann entsprechend auch (weniger RAM, mehr CPU).
Das Forum müsste dann halt auch vom Code her an die Multiserver Variante angepasst werden bzgl. Avatare und andere Uploads (was auch wieder etwas Konzept benötigt).

(13.01.2014)Atra Demonica schrieb:  Naja schon wenn die Angreifer es ebeb einfach lassen.

@saij: Deswegen, weil es umgänglich ist, ist das ja nicht mehr nur der Einzige Schutz. Ist halt aber alles recht nervig.

Und eben weil er eigentlich ohne Aufwand umgänglich bringt es nichts diesen "Schutz" aktiv zu lassen und die User zu "ärgern". Ein Perl Script was diesen Browser Check aushebelt sehe ich nicht als schwer an. Da JS in dem Check macht nichts anderes als einen zufälligen Wert zu berechnen und ein Formular per GET abzuschicken. Seh ich kein Problem darin. Cookie Handling und UserAgent Handling ist in LWP eh schon so gut integriert das ich mich einfach als Firefox oder Chrome ausgeben kann und die Cookies über mehrere Requests behalte.

Daneben bringt Cloudflare auch nichts wenn die Software auf dem Server sich selber verrät. Inwieweit das aber abgestellt wurde weiss ich nicht (ich weiss nur dass es da mal eine Lücke gab die genutzt wurde um die IP der Maschine hinter Cloudflare zu finden).

Was mir aufgefallen ist, dass ihr anscheinend schon mit NGINX als LoadBalancer arbeitet. Aber ich vermute mal das es nur auf einen einzigen Apache dahinter geht und nicht auf multiple Server. Bringt eigentlich so keinen Vorteil außer das es entsprechend Latenz und Resourcen verbraucht.
Was ihr vlt. auch mal überlegen solltet ist der Einsatz von einem Varnish Proxy in verbindung mit ESI. Setzen wir hier bei den großen Webseiten auch ein um einfach bestimmte Teile der Webseite unterschiedlich lang zu cachen. Könnte hier garantiert auch Sinn machen um Last zu nehmen und auch die Last zu verteilen (wir arbeiten mit 2 nginx und 2 Varnish vor 6 oder 7 Apache2).

Clustering in so einer Umgebung mit dem Hintergrund der Angriffe ist nicht ganz einfach und braucht definitiv ein gescheites Konzept. Rumprobieren und hoffen bringt kaum was weil die Angreifer immer wieder was zerreisen können und man sich irgendwann total verstrickt und Dinge einrichtet die nicht helfen sondern alles nur schlimmer machen.


Nebenbei:
E-Mail ist langsam... Hab die Benachrichtung für diesen Thread erst viel Später bekommen wo schon 6 neue Antworten da waren. Ist n bissel blöd (und nein: mein E-Mail System tut und läuft auch schnell - ist keine Last drauf und andere E-Mails kamen auch an. Greylisting ist auch deaktiviert)

[Vaalyn]

(13.01.2014)Evenprime schrieb:  Ich bin für Alternativen gern zu haben. Wir sind allerdings schon bei Ovh und deren System fängt diese Angriffe halt nicht ab.

Serverseitige Erkennung der nicht menschlichen Requests haben wir schon probiert, dafür sind diese aber pro IP zu wenige und insgesamt zu viele, sprich entweder tonnenweise false positives oder drr Server ist dicht.

Habt ihr eventuell mal über Geo Load Balancing nachgedacht mit 1 DB Server und 2 Foren Servern?

[Saij]

Nachtrag:
Layer 7 Angriffe dürften sich auch mit mehreren Servern in einem Netzwerk durchführen.
Die häufigen 502 Bad Gateway deuten darauf hin, dass der nginx noch in der Lage war den Request zu verarbeiten, aber den dahinter liegenden Apache nimmer erreicht hat. Durch den Einsatz mehrerer Server und 2 nginx LoadBalancern sollte sich das Problem recht gut aufteilen lassen. Wenn Geld da ist wäre es sogar eine Möglichkeit das ganze in 2 Netze aufzusplitten und dann weiterhin mit der Heartbeat bzw. Multiple A Record bzw. Cloudflare Variante zu verbinden und dann entsprechend eine Last- und Bandbreitenverteilende Balancing Strategy aufzubauen. Das dürfte dann für die Angreifer auch schwer werden mit dem DDoS, einfach weil der Aufwand, die IP von den Servern dahinter (die eigentlichen Server sollten nur interne IPs bekommen und nicht von extern erreichbar sein) zu bekommen bzw. der Aufwand die LoadBalancer (vorallem wenn man von 2 LB pro Netz ausgeht) unereichbar zu groß wird (man braucht entsprechend mehr Bots weil man mehr Angriffspunkte hätte).
Ganz ausschließen lässt sich ein DDoS aber nie. Dafür ist das Netz einfach nicht ausgelegt.
Was man auch versuchen könnte wäre noch ein 3. Netz, welches nur über IPv6 erreichbar ist einzurichten. In D geht IPv6 mittlerweile einigermaßen und könnte dadurch auch die Angreifer stören (man braucht erstmal einen IPv6 fähigen Bot).

Ziel ist es auf alle Fälle bei einem Angriff einfach auf ein anderes System zu switchen, so dass sich die Downtime (welche es geben könnte - aber nicht muss) für die User so gering wie möglich zu halten, für die Angreifer aber jedesmal arbeit verursacht um die Bots umzustellen.

Schutz über Layer 7 sollte dabei mit einer Firewall wie iptables (oder besser einer Hardware Firewall) gut machbar sein, wenn man die Rules sehr gut definiert. Auch wenn iptables dabei besser auf einem System läuft, was über genug Resourcen verfügt, einfach weil der Kernel auch Resourcen benötigt bevor die Pakete überhaupt bei iptables ankommen (daher ist auch eine Hardware Firewall am besten).

* Saij kramt mal weiter in seiner Netzwerk-Wissens-Kiste aus der Berufsschule

---

Nochmal ich (ich schreib einfach mal frei meine Gedanken runter in der Hoffnung das sie vlt. helfen )

Angriff auf Layer 4:
Hier wird von den Angreifern darauf abgezielt, dass Netzwerk an sich zu überlasten. Es werden recht schnell kleine Pakete verschickt die dann die Router und Bandbreite überlasten. Dabei ist es egal ob es sich um korrupte Pakete oder richtige Pakete handelt (wobei die Korrupten um längen kleiner sind). Das ganze kann einfach nur durch den Provider gefiltert werden (massiver Ausbau der Bandbreite im eigenen Netz und Filteranlagen). Macht OVH ja auch so. Dauert bei denen nur etwas wenn man nicht den DDoS Schutz Pro hat (im Normalfall bis zu 2 Minuten bis die Filterhardware anspringt). Aber auch hier gibt es die Möglichkeit durch gute Steuerung die Last auf Layer 4 so gering zu halten, dass die Filteranlagen nicht anspringen und dennoch das Netzwerk kurz vor dem Server ausgehebelt wird. Aber da arbeitet OVH afaik noch dran um die Einstellung zu perfektionieren.

Angriff auf Layer 7:
Hier werden korrekte Pakete an den Server geschickt. Deshalb ist auch das Netz hier meistens nicht ausgelastet und es wird kein Angriff erkannt.
Aber da die Server die Pakete dann verarbeiten (besonders wenn dahinter eine Applikation hängt) werden die Ressourcen auf den Servern komplett verbraucht (deswegen ist kein Ping möglich und SSH auch nicht - keine Ressourcen mehr verfügbar).
Hier lässt sich über ein einfaches Clustering mit LoadBalancing abhilfe schaffen.
Mal ein kleines Strukturbeispiel (mal als Text - im Büro kann ich schlecht ne Netzwerkstruktur zeichnen )

Es gibt einen LoadBalancer (meist eine spezielle Hardware um Ressourcen zu schonen). Dieser nimmt die Requests an und verteilt sie nach einem bestimmten Verfahren (bspw. RoundRobin oder direkte Aktivierung) auf 2 weitere Server. Auf diesen weiteren Servern läuft je ein nginx. Dieser Webserver ist sehr sehr sehr Ressourcen schonend wenn er nur als eine Art Proxy LoadBalancer läuft.
Hier können nebenbei auch Firewall Regeln aufgestellt werden oder andere, ressourcensparende Techniken verfügbar gemacht werden (bspw. Auslieferung statischer Dateien wie Grafiken oder JS oder CSS - Dinge die nicht vom Server interpretiert werden müssen). Durch E-Tags und Caching wird es hier nochmal ressourcenfreundlicher.
Diese beiden nginx Server leiten die Anfragen dann an eine Reihe von Apache Servern weiter. Die Apache Server sind von außen direkt nicht wirklich zu erreichen (bzw. nur wenn man wirklich mal was auf EINEM Server machen muss um Fehler zu finden). Selbst wenn jetzt eine Reihe von attackierenden Anfragen ankommen, so wird die Last auf alle Apache Server verteilt. Zuviel Last kann auch nicht erzeugt werden, weil sonst die Bandbreite wieder ausgereizt wird was zum Einsatz der Filterhardware führt.

Man kann das ganze auch einen Schritt kleiner machen und ohne die LB Hardware arbeiten (sollte aber 2 nginx haben die entsprechend per Heartbeat oder andere Überwachungssoftware die Domain auf den anderen Server schalten können).
Für die nginx reicht es wenn 2 recht starke Maschinen (oder 2 virtuelle, aber starke Maschinen) vorhanden sind (geht ja nur um die Ressourcen - und die sind auch bei einer Aufteilung von reellen Ressourcen vorhanden). Für die Apache und DB Server kann man dann ohne Probs komplett auf virtuelle Maschinen zurück greifen. Dort sollten dann die Ressourcen aber komplett abgeschottet sein zwischen den vServern. Damit lässt sich zwar eine Maschine abschießen, aber die anderen juckt das nicht weil ihre Ressourcen nicht betroffen sind. Vorallem kommt man immer noch auf die Hostmaschine drauf wenn die auch noch ein paar Ressourcen über hat

Soviel erstmal zu meinen Gedanken aus einer Raucherpause
Wenn mir noch was einfällt melde ich mich wieder

---

(Ich biete übrigens an, das ganze gerne mit dem Techteam in einer Skype Runde oder whereever zu diskutieren und auch weiter zu helfen - Angebot steht - wenn es angenommen wird einfach melden )

[Piet.Lu]

klingt schon logisch,
aber nicht jeder hat IPv6-fähige Hardware - müsste sich dann erstmal jeder anschaffen gehen und nicht jeder hat das Geld dafür.
und dann sperrt man dadurch auch einige unschuldige aus, was nicht sein sollte

[Saij]

Halt Stopp!
IPv6 kann heute eigentlich jeder Router und jeder Rechner. Nur der Provider ist es meistens.
Aber selbst wenn: ich hab ja nicht gesagt man sollte NUR auf IPv6 setzen. Sondern es ZUSÄTZLICH nutzen.

[Piet.Lu]

Mein Router zu Hause ist 10 Jahre alt, ich denke mal nicht, dass der IPv6-fähig ist, aber ist ja auch wurscht ^^
aber ok, zusätzlich wär eine gute Alternative ^^

[Saij]

So genau weiss ich jetzt nicht wann der IPv6 Standard geschaffen wurde, aber 10 Jahre könnten hart an der Grenze liegen (wird mal Zeit zum aufrüsten )

[Vaalyn]

(13.01.2014)Saij schrieb:  So genau weiss ich jetzt nicht wann der IPv6 Standard geschaffen wurde, aber 10 Jahre könnten hart an der Grenze liegen (wird mal Zeit zum aufrüsten )

Ich meine IPv6 ist schon vor der Jahrtausendwende zum Standard und Nachfolger von IPv4 erklärt worden.

[Saij]

Meine ich auch - daher müsste 10 Jahre alte HW auch schon IPv6 unterstützen Bin mir da aber nicht sicher

[Vaalyn]

Kommt wohl auf den Hersteller an, manche sind bei sowas ja recht faul bzw langsam, wenn's darum geht neue Sachen einzubauen^^