Was tun bei DoS/DDoS-Angriffen ?

Ich beobachte nebenbei gerne die neuesten Entwicklungen im Bereich DDoS (DistributedDenialofService).

NEIN, nicht weil ich es selbst nutzen möchte, sondern schlicht um Kunden besser schützen zu können.

In den letzten Tagen hatte schon Akamai die Segel gestrichen, als ein illustrer Traffic von 620GBit/s das Blog von Brian Krebs lahmlegte (übrigens eine mehr als imposante Zugriffsrate für ein Blog 🙂 ).
Heute lese ich nun auf Heise, daß der französische Hoster OVH von einem DDoS mit 1,1TB/s minimal überrascht wurde.

Das sind mal UpStream-Raten 🙂

Und nu ?

Da nun nicht jeder Webseitenbetreiber von einem DDoS in diesen Außmaßen getroffen wird, empfiehlt es sich zum Beispiel beim Apache httpd etwas wie mod_evasive einzusetzen.
Es wird ganz sicher nicht dem Anfangs genannten Traffic von 620GB/1,1TB standhalten – da ist der Speicher schneller voll, als man Papp sagen kann – aber es hilft doch gegen Script-Kids und wirklich einfach gestrickte DoS/DDoS-Versuche.

Zusätzlich könnte man natürlich auch noch eine Strategie wählen die ich in diesem Beitrag beschrieben hatte und diese Methode auf Port 80 ausdehnen.

 

Toll 🙁

Ich werde mal am Wochenende versuchen einen etwas detaillierten Beitrag zu mod_evasive zu schreiben 🙂

Welche Gegenmaßnahmen man sonst noch treffen kann, darf ich, nach gründlicher rechtlicher Recherche, hier leider nicht posten 🙁

Jenkins Slave-Nutzung

Sofern man sich beim Jenkins für die Skalierung mittels Build-Slaves entschieden hat, läuft man zwangsläufig in eines der Jenkins Grundprobleme:
Man hat zwar nun mehere Build-Slaves, die Jobs werden aber nach wie vor nach dem Jenkins Prinzip auf dem entsprechenden Node gestartet.

Was meine ich nun mit Jenkins-Prinzip ?
Jenkins startet grundsätzlich den auszuführenden Job IMMER dort, wo er zuletzt ausgeführt wurde.

Wenn also alle meine Jobs bisher auf dem Master ausgeführt wurden, werden sie auch weiterhin dort ausgeführt, was dann den Aufbau von Build-Slaves ad Absurdum führt 🙁

Die Lösung

Es gibt ein sehr zu empfehlendes Plugin für Jenkins: Scoring Load Balancer

Das Plugin überschreibt das Standardverhalten vom Jenkins und entscheidet anhand von Konfigurationen, wie die Last auf die Knoten verteilt werden soll.

Es gibt bei diesem Plugin diverse Möglichkeiten die Last gewichtet zu verteilen, allerdings ist meine präferierte Einstellung bei diesem Plugin das „Scoring by Node Loads“.

Hier wird im Endeffekt für jeden Build-Knoten zunächst ein Wert „Scale for Scores“ definiert.
Jeder „Freie Build-Executor“ erhält nun noch einen inkrementellen Wert und jeder „Belegte Build-Executor“ einen dekrementellen Wert.

Um zu verdeutlichen, wie das Ganze nun funktioniert, nehmen wir einfach mal folgende Jenkins-Knoten-Konfiguration an:

Knoten Anzahl Build-Prozessoren Knoten Score
Master 30 300 (30*(1*10))
Slave 1 30 300 (30*(1*10))

Wird jetzt auf dem Master ein Job ausgeführt, sinkt der Knoten Score auf 290, da ja ein Build-Prozessor belegt ist.
Wird nun während des laufenden Builds auf dem Master ein weiterer Build angestoßen, sucht das Plugin nun nach dem Knoten, der den höchsten verfügbaren Knoten-Score hat. In diesem Fall wäre das dann der theoretische Knoten Slave 1.

Das Plugin bietet des Weiteren diverse Kombinationsmöglichkeiten von Gewichtigungsvarianten, allerdings bin ich bisher mit dieser einfachen Konfiguration am besten gefahren. 🙂

Ein Lockfile im Shell-Script

Gute Vorschläge und Ideen um Lock-Files in einem Shell-Script zu verwenden, gibt es wie Sand am Meer.

Es gehen – mittlerweile seit Jahren – tiefgreifenden Diskussionen einher, welche Variante nun die Sicherste ist und welche Scripts Race-Conditions haben.

Meine persönliche Variante, die sicherlich nicht im Millisekunden-Bereich stabil ist, ist die folgende:

Über die erste Zeile hole ich mir einen Lockfilenamen in /tmp der den Namen des Scripts+“.lock“ hat.

Das kill -0 prüft schlicht, ob der Prozess der das „Lock“ hat, auch tatsächlich noch läuft.

Trap sichert noch ab, daß, außer bei einem kill -9, das Lockfile auch gelöscht wird 🙂

Jenkins

Da ich in der Vergangenheit Jenkins bei vielen Kunden aufgebaut und/oder erweitert habe, zudem Plugin-Maintainer bin, werde ich jetzt hier auf dem Blog in Zukuft einfach mal eine Serie mit Tips- und Tricks zu Jenkins veröffentlichen 🙂

Die Artikel werden etwas chaotisch veröffentlicht, je nachdem wieviel Zeit ich habe, aber zum Schluß wird es für diverse Bereiche nochmals eine Zusammenfassung nach Themengebieten geben.

Bei Anregungen/Wünschen: einfach hier einen Kommentar hinterlassen 🙂

px3