Fail2Ban - Vom Nachtwächter zur Schwarmintelligenz

00:00:00: Stell dir mal vor, du baust ein brandneues Haus.

00:00:03: Okay, stell es mir vor!

00:00:04: Also du hast ein massives Fundament gegossen, du ziehst die Wände hoch, deckst das Dach – alles sieht super aus.

00:00:12: Aber… ähm … Du lässt dann einfach alle Türen und sämtliche Fenster im Erdgeschoss komplett offen stehen?

00:00:19: Keine Ute-Idee.

00:00:20: Überhaupt nicht.

00:00:21: Und das Haus steht auch nicht irgendwo idyllisch auf dem Land sondern direkt an der belebtesten chaotischen Kreuzung der Welt.

00:00:29: Oh, wow.

00:00:30: Ja?

00:00:30: Genau das ist nämlich die Realität.

00:00:32: wenn du heute also in der heutigen Zeit einen frischen Server im Internet hoch fährst.

00:00:37: Das ist echt ein erschreckend treffendes Bild und die Geschwindigkeit mit der dieses offene Haus da entdeckt wird is für viele ja ein echter Schock.

00:00:46: Absolut.

00:00:47: Wir reden hier halt nicht von Tagen

00:00:48: oder Stunden.

00:00:49: Nee eher Sekunden oder?

00:00:50: Genau Innerhalb von wenigen Minuten oft wirklich Sekunden klopfen automatisierte Scanner und Bots an dein digitales Haus

00:00:59: Krass!

00:01:00: Die rütteln an absolut jeden Türgriff, testen pausenlos Standardpasswörter wie Atmen oder eins zwei drei vier fünf.

00:01:09: Der Klassiker

00:01:10: Eben und die suchen nach der kleinsten vergessenen Schwachstelle.

00:01:14: Ein perfektes Beispiel dafür haben wir in einem Praxisbericht gesehen von der Sweet Good Seite

00:01:20: Stimmt.

00:01:20: das hatte ich auch in den Quellen gelesen

00:01:22: Ja – der Betreiber dort musste regelrecht eine digitale Stahltür für diese KI Scrapers zuschlagen

00:01:28: Weil es einfach zu viel wurde.

00:01:29: Genau, die schiere Masse an diesen automatisierten völlig sinnfreien Anfragen drohte einfach die Ressourcen seiner Seite komplett lahmzulegen.

00:01:38: Wahnsinn!

00:01:39: Und genau deshalb ist unsere heutige Analyse so extrem wichtig.

00:01:42: Definitiv

00:01:43: Wir schauen uns heute nämlich an wie du dieses digitale Haus in eine echte Festung verwandelst.

00:01:51: Wir haben uns dadurch einen massiven Berg an Material gewühlt von offiziellen Dokumentationen über tiefe Fachartikel bis hin zu den hitzigsten Diskussionen in Admin-Fohren aufredet.

00:02:04: Da ging es teilweise echt zur Sache!

00:02:06: Oh ja, und unser Ziel für dich heute ist es die Evolution der Serververteidigung wirklich zu verstehen

00:02:12: Schritt für Schritt.

00:02:13: Genau wir bauen das Wissen Schicht für Schicht auf.

00:02:16: Wir fangen bei der simplen aber ziemlich trügerischen Grundmauer an Die

00:02:20: Firewall

00:02:21: Richtig.

00:02:22: Dann schauen wir uns den isolierten Türsteher an und enden am Schluss bei einer hochmodernen, global vernetzten Schwarmintelligenz.

00:02:29: Eine sehr spannende Reise!

00:02:31: Denn was viele halt nicht wissen – einfach nur ein Schloss einzubauen?

00:02:36: Das reicht heute bei Weitem nicht mehr aus.

00:02:38: Weil die Angreifer schlauer werden.

00:02:40: Exakt.

00:02:41: Die Angreife haben extrem aufgerüstet also müssen wir das eben auch tun.

00:02:45: Logisch

00:02:47: Der erste Schritt, also die absolute Basis ist aber natürlich immer noch die Firewall.

00:02:52: Okay?

00:02:53: Lass uns da mal einsteigen!

00:02:55: Gerne.

00:02:56: und hier stoßen wir in den Guides besonders bei den Best Practices von Virtua Cloud unweigerlich auf ein Konzept das sich default-deny nennt.

00:03:05: Default-DENY.

00:03:07: Also wenn ich das richtig verstanden habe aus unseren Quellen ist es im Grunde die paranoideste Aber eben auch sicherste Einstellung, die man überhaupt wählen kann oder?

00:03:16: Ja das kann man so sagen.

00:03:17: Das bedeutet doch dass der Server sich komplett taub stellt.

00:03:21: also alles jeder einzelne Datenverkehr der von außen anklopft wird kategorisch vom Betriebssystem weggeworfen.

00:03:27: Komplett ignoriert genau!

00:03:28: Keine

00:03:29: Ausnahmen da geht gar nichts durch

00:03:31: richtig.

00:03:32: und dann bordmann als admin ganz bewusst mikroskopisch kleine Löcher in diese dicke Mauer.

00:03:39: ein schönes Bild

00:03:41: Also zum Beispiel PORT-SWII für SSH.

00:03:45: Den braucht man ja zwingend, um sich überhaupt aus der Ferne auf dem eigenen Server einloggen zu können.

00:03:50: Exakt!

00:03:50: Ohne den stehst du selbst vor verschlossener Tür.

00:03:53: und um diese Löcher zu verwalten gibt es in der Linux Welt im Grunde zwei sehr populäre Werkzeuge

00:03:59: die in unseren Quellen auch immer wieder verglichen werden.

00:04:01: ne?

00:04:02: Genau das sind UFW und NF Tables.

00:04:08: Uncomplicated Firewall, richtig?

00:04:10: Richtig.

00:04:11: Und der Name ist da echt Programm!

00:04:13: Es ist unglaublich anfängerfreundlich.

00:04:16: Wie einfach ist es wirklich?

00:04:17: Naja du tippst einfach ufwallow-twenty two ein und die Tür ist offen.

00:04:22: Das ist echt simpel

00:04:23: Ja aber was man dabei halt unbedingt verstehen muss UFW ist eigentlich gar keine eigene Firewall.

00:04:29: Warte was?

00:04:30: Keine Firewall?

00:04:32: Nö

00:04:33: Es ist eigentlich nur eine hübsche einfache Benutzeroberfläche Ein sogenannter Webber.

00:04:38: Ah, okay.

00:04:39: Dieser Wapper schreibt im Hintergrund die eigentlichen extrem komplexen Kernelregeln deines Linux-Systems für dich also IP Tables

00:04:47: Verstehe.

00:04:48: Er nimmt mir quasi die kryptische Arbeit ab

00:04:51: Ganz genau.

00:04:52: Und auf der anderen Seite steht dann NF Tables.

00:04:54: Das wird ja überall als der moderne native Linux Standard gefeiert

00:04:59: Ist es auch.

00:05:00: Aber das sieht auf den ersten Blick deutlich kryptischer aus Weil es mit Tabellen und sogenannten Ketten arbeitet.

00:05:05: Ja

00:05:06: Die Lernkurve ist da auf jeden Fall steiler.

00:05:08: Aber es bietet eben tiefgreifende Funktionen wie zum Beispiel Rate Limiting,

00:05:12: ein extrem wichtiges Feature.

00:05:14: Nur um das kurz für dich einzuordnen, Rate Limitting bedeutet einfach dass man eine künstliche Bremse einbaut.

00:05:20: Also wenn jemand versucht tausend Mal pro Sekunde einen Passwort zu erraten sagt NFT-Bels einfach nein du darfst nur fünf mal pro Minute raten!

00:05:29: Genau

00:05:30: Das macht diese ganzen Brute Force-Angriffe mathematisch nahezu unmöglich, weil der Angreifer plötzlich Jahrzehnte bräuchte um alle Kombinationen durchzutesten.

00:05:39: Genau diese Tiefe macht NF Tables ja so wertvoll für Profis!

00:05:44: Aber egal ob man jetzt das simple UFW oder das komplexe NF Table nutzt es gibt eine goldene ziemlich schmerzhafte Lektion.

00:05:54: Die

00:05:54: lernt fast jeder Admin irgendwann mal Wenn du an diesen Mauer an Arbeit bist, ist die Wahrscheinlichkeit extrem hoch dass du dich versehentlich selbst aussperrst.

00:06:03: Ja man lacht aber das passiert oder?

00:06:05: Ständig!

00:06:06: Du aktivierst die Feierbau-Regeln hast aber im Eifer des Gefechts vergessen deine eigene SSA Verbindung explizit zu erlauben und zackt die Tür fällt ins Schloss der Schlüssel steckt von ihnen und du kommst einfach nicht mehr an deinen eigenen Server heran.

00:06:21: Der absolute Klassiker.

00:06:23: Aber die Experten in den Foren haben dafür einen echt genialen, fast schon banalen Trick.

00:06:32: Genau!

00:06:33: Bevor du irgendwelche Firewall-Regeln scharf schaltest, richtest du dir mit diesem Linuxbefehl einfach einen Failsafe ein.

00:06:41: Du sagst dem System quasi – In exakt fünf Minuten löscht du alle Firewallregeln komplett.

00:06:47: Absolut!

00:06:48: Wenn du dich dann aussperrst, holst du dir einfach in Ruhe einen Kaffee, wartest diese fünf Minuten und die Tür springt automatisch wieder auf.

00:06:55: Und wenn alles geklappt hat?

00:06:57: Wenn alles geklapt hat und du noch drin bist, dann brichst du den Timer einfach manuell ab!

00:07:01: Sehr eleganter Workaround.

00:07:03: Aber hier müssen wir jetzt über etwas sprechen das mich bei der Recherche echt komplett vom Stuhl gehauen hat.

00:07:10: Du

00:07:11: meinst die Dockerfalle.

00:07:12: Ja Die sogenannte Docker-Falle.

00:07:15: Hier wird es nämlich für jeden der Anwendungen selbst hostet richtig, richtig gefährlich.

00:07:20: Oh

00:07:20: ja!

00:07:23: Das ist vielleicht eines der allergrößten Missverständnisse in der modernen IT-Infrastruktur.

00:07:28: Erklär mal?

00:07:29: Naja sehr viele Leute nutzen heute Docker um ihre Software isoliert in Containern laufen zu lassen.

00:07:35: Ist ja auch super praktisch.

00:07:36: Total.

00:07:37: Aber das führt oft zu einer massiven, trügerischen Illusion von Sicherheit wenn man gleichzeitig UFW als Firewall nutzt.

00:07:48: Lass mich mal versuchen das Bild von unserem Haus von vorhin weiterzuspinnen.

00:07:52: ok?

00:07:53: Schieß los!

00:07:53: Um zu erklären wie diese Falle zuschnappt Du kaufst ja also dieses massive Hochsicherheitsschloss.

00:07:59: in unserem Fall ist das UF W. Du konfigurierst alles, das Dashboard sagt ja alles ist aktiviert.

00:08:05: Du bist glücklich und denkst dir super niemand kommt rein!

00:08:07: Ein schönes Gefühl

00:08:08: Ja aber was du halt nicht weißt der Handwerker den du beauftragt hast also Docker hat einfach ungefragt eine dauerhaft offenen Hintertür für seine eigenen Lieferanten in deine Wand gebrochen.

00:08:20: ein toller Vergleich.

00:08:21: Aber wie passiert das?

00:08:22: technisch?

00:08:23: Also Docker manipuliert ja nicht die Firewall-Regeln Die URW dir vorne an zeigt oder?

00:08:27: Richtig Docker greift direkt auf die tiefer liegenden Netzwerkketten im Linux-Körnel zu.

00:08:33: Also an Ufw vorbei?

00:08:34: Genau, genauer gesagt geht Docker auf die sogenannte Pre-Routing-Kette.

00:08:39: Um das technische Warum dahinter mal kurz zu beleuchten, Linux verarbeitet Netzwerkanfragen in einer ganz bestimmten strikten Reihenfolge.

00:08:46: Okay!

00:08:47: Ufwe setzt seine Blockaden in der sogenannten Filterkette.

00:08:50: Das klingt logisch – da wird gefiltert

00:08:52: Ja aber das Problem ist dass Docker für sein Port Forwarding die Nuttkette nutzt Und diese Nut-Kette wird vom System abgearbeitet, bevor die Filterkette von UFW überhaupt erst gefragt wird.

00:09:04: Krass!

00:09:05: Das heißt Docker ist einfach schneller dran?

00:09:07: Genau.

00:09:08: Docker fängt den Traffic quasi schon am Gartenzaun ab und leitet ihn direkt in den Container

00:09:13: Noch bevor der Ufw Türsteher an der Haustür überhaupt den Ausweis kontrollieren kann.

00:09:18: Exakt so ist es.

00:09:19: Du tippst dann als admin ufw status ein Siehst das alles blockiert sein soll...

00:09:24: ...und fühlts dich sicher.

00:09:25: Ja Aber in Wahrheit sind deine Datenbankports über Docker sperrangelweit fürs gesamte Internet offen.

00:09:31: Wahnsinn!

00:09:32: Einfach ein kompletter Bypass?

00:09:34: Total.

00:09:34: Und genau das ist der Grund, warum Veteranen in produktiven Umgebungen oft auf NF-Tables schwören oder?

00:09:39: Richtig Dort hat man nämlich die absolute Kontrolle über den gesamten Regelsatz und alle Tabellen.

00:09:46: Man sieht sofort was Docker im Hintergrund eigentlich treibt.

00:09:49: Ok Puh Unsere Mauer steht jetzt also Idealerweise ohne diese versteckten Docker-Hintertüren

00:09:56: Hoffen wir es.

00:09:57: Aber eine Firewall hält ja letztlich nur ehrliche Leute oder dummes Kripte draußen.

00:10:02: Stimmt!

00:10:03: Was passiert denn, wenn ein Angreifer gar nicht erst versucht durch die Mauer zu brechen sondern sich ganz legal verhält?

00:10:10: Wie meinste das?

00:10:11: Naja er steckt einfach zehntausend verschiedene Schlüssel in das eine offiziell erlaubte Schloß also deinen SSH-Port.

00:10:19: Ah ok dann sind wir bei der nächsten Ebene der Eskalation angekommen dem Brute Force Angriff

00:10:25: Genau.

00:10:26: Und hier reicht eine rein statische Mauer einfach nicht mehr aus, wir brauchen etwas das reagiert?

00:10:31: Etwas Aktives!

00:10:32: Ja und wenn man sich die Fachartikel dazu anschaut wie zum Beispiel die Analysen auf Blocks oder die detaillierten Guides landet man unweigerlich bei einem absoluten Urgestein der Server-Sicherheit.

00:10:45: Fail to ban.

00:10:46: Ganz genau fail to ban

00:10:47: also Fail to ban verstanden habe ist das im Grunde ein kleines Stück Software, dass ununterbrochen Deine Server-Logs mitliest.

00:10:56: Richtig!

00:10:57: Ein Mitleser.

00:10:58: Es ist wie so ein extrem aufmerksamer aber völlig pedantischer Archivar.

00:11:03: Schöner Vergleich

00:11:04: Es liest jede Zeile Nutzerrout falsches Passwort Nutzernatmen falsches passwort.

00:11:12: Und wenn es dann bemerkt, dass von einer bestimmten IP-Adresse in den letzten zehn Minuten sagen wir mal fünf Fehlversuche kamen.

00:11:19: Dann sagt es

00:11:20: Stopp!

00:11:20: Genau

00:11:21: Es greift dynamisch ein und schreibt sofort eine neue Regel in die Firewall Die diese spezielle IP Adresse für eine Stunde komplett aussperrt.

00:11:30: Das ist exakt der Mechanismus.

00:11:32: Aber um zu verstehen wo die Grenzen dieses eigentlich tollen Tools liegen müssen wir uns kurz ansehen wie das technisch macht.

00:11:40: Okay, schieß los.

00:11:42: Fail-to-Bahn wurde in der Programmiersprache Python geschrieben und verlässt sich extrem stark auf sogenannte reguläre Ausdrücke.

00:11:49: Kurz Ragex.

00:11:50: Genau, RageX Das ist eine Methode um innerhalb von riesigen Textmengen nach ganz spezifischen komplexen Mustern zu suchen.

00:11:58: Aber das musst du genauer erklären.

00:12:00: Warum ist dieses Suchen im Text überhaupt ein Problem?

00:12:03: Bei LockDateien normalerweise komplett unstrukturierter Text sind.

00:12:07: Da steht vielleicht ein Zeitstempel, dann kommt irgendein Wirrertext und eine IP-Adresse.

00:12:12: Manchmal in völlig unterschiedlichen Formaten?

00:12:14: Eben!

00:12:15: Und Rayjax muss sich wie so einen Detektiv durch jeden einzelnen Buchstaben dieser Textwüste arbeiten um zu prüfen ob die Zeile zu einem bekannten Angriffsmuster passt.

00:12:25: Das klingt anstrengend

00:12:26: Ist es auch... das erfordert enorm viel Rechenleistung.

00:12:30: Ah

00:12:30: ich verstehe

00:12:31: Wenn dein Server nun von einem echt großen Botnet angegriffen wird und plötzlich Tausende Log-Einträge pro Sekunde generiert werden, muss Fail to Ban diese komplexe Regex Suche tausendmal pro Sekund ausführen.

00:12:44: Oh je!

00:12:45: Und in der Praxis führt das dann oft dazu dass nicht der Angriff selbst den Server in die Knie zwingt sondern

00:12:50: Fail To Ban selbst?

00:12:51: Genau sondern die CPU-Auslastung von Fail to Ban, das verzweifelt versucht den Angriff zu analysieren.

00:12:57: Das

00:12:57: ist ja echt ironisch!

00:12:59: Der Wächter strengt sich so sehr an den Angreifer zu identifizieren, dass ihm selbst komplett die Luft ausgeht.

00:13:05: Genau so kann man das sagen.

00:13:07: Wenn ich nochmal auf unsere Analogie von vorhin zurückgreifen darf, Fail To Ban is wie ein extrem loyaler aber völlig isolierter Nachtwächter.

00:13:15: Er macht seinen Job fantastisch.

00:13:18: Er merkt sich das, wenn jemand fünfmal nacheinander an seine eigenen Tür rüttelt und wirft ihn hochkant raus.

00:13:26: Ziemlich effektiv!

00:13:27: Ja aber – und das ist der entscheidende Schwachpunkt – dieser Wächter hat kein Telefon.

00:13:32: Sehr guter Punkt.

00:13:33: Er ruft niemals den Nachtwächter des Nachbargebäudes an um ihn vorzuwahren.

00:13:38: also nach dem Motto pass auf hier treibt sich eine IP-Adresse mit einer Brechstange herum.

00:13:42: Nee, das macht er nicht.

00:13:42: Er lernt einfach nichts aus der Welt da draußen.

00:13:45: Er agiert komplett in seinem eigenen kleinen Vakuum.

00:13:48: Das ist eine sehr genaue Beschreibung, dennoch dürfen wir nicht vergessen warum das Tool nach wie vor so beliebt ist.

00:13:56: Stimmt!

00:13:57: Auf Reddit lieben es ja viele.

00:13:58: Ja

00:13:59: wenn man durch die Forens scrollt sieht man Nutzer, die Fail to ban fast schon fanatisch verteidigen.

00:14:03: Warum genau?

00:14:04: Der Grund ist ganz simpel Es ist absolut transparent.

00:14:07: Alles passiert lokal auf deiner Maschine.

00:14:10: Fail to Ban funkt nicht nach Hause, es gibt keine fremden Server, keine Cloud-Abhängigkeit.

00:14:16: Du als Admin hast die absolute hundertprozentige

00:14:19: Kontrolle.".

00:14:20: Das ist natürlich ein Argument!

00:14:22: Ja – wenn du willst dass jemand nach zwei Fehlversuchen für ein ganzes Jahr gesperrt wird?

00:14:27: Dann isst er so.

00:14:28: Diese Kontrolle ist im Self-hosting Bereich für viele ein unantastbares Heiligtum.

00:14:34: Das verstehe ich absolut, jeder will Herr im eigenen Haus sein.

00:14:38: Aber diese Isolationen – also dieser Wächter ohne Telefon – der führt uns doch direkt zum nächsten großen Paradigmenwechsel oder?

00:14:46: Da hast du Recht!

00:14:48: Weil was wäre denn wenn wir diesen Nachtwächter mit Zehntausenden anderen auf der ganzen Welt vernetzen

00:14:53: könnten?!

00:14:54: Das wäre der Game Changer.

00:14:56: Wenn man sich die aktuellen Guides anschaut taucht ein Name immer wieder als der große moderne Herausforderer auf

00:15:02: Crowdsack.

00:15:03: Genau, CrowdSec.

00:15:05: Und CrowdSec löst eben genau die Probleme, die wir gerade bei Fail to Ban besprochen haben.

00:15:10: Das fängt schon bei der Architektur an.

00:15:12: Inwiefern?

00:15:13: CrowdSec ist nicht in Pfeifen geschrieben sondern in Go.

00:15:16: Okay und was bringt das?

00:15:18: Go ist eine kompilierte Sprache Die von Grund auf dafür entwickelt wurde Netzwerkanfragen und massiv parallele Prozesse extrem effizient zu verarbeiten.

00:15:27: Es ist um ein vielfaches Ressourcen schonender.

00:15:29: Gut für die CPU also.

00:15:31: Absolut, aber der wirklich große technische Sprung ist die Art und Weise wie es Logs liest.

00:15:36: Moment!

00:15:36: Es liest doch auch nur Text-Dateien oder nicht?

00:15:39: Was ist da

00:15:39: anders?!

00:15:40: Nicht ganz – CrowdSec ist darauf optimiert moderne strukturierte Formate wie JSON zu lesen.

00:15:46: Ah ok… Ein JSON-Log ist eben nicht einfach eine wilde Textwüste.

00:15:51: Es ist eher wie eine sauber sortierte Excel-Tabelle …

00:15:54: Mit Spalten

00:15:54: und so?

00:15:55: Genau Da gibt es klare Kategorien.

00:15:58: Hier ist das Feld für die IP, dort das Feld der Aktion.

00:16:02: Das Programm muss also nicht mehr mit aufwendigen Rejects-Mustern raten wo die Information überhaupt steht.

00:16:08: Es weiß es einfach?

00:16:09: Ja!

00:16:09: Es greift einfach direkt auf den richtigen Datenpunkt zu und das senkt den CPU Verbrauch im Vergleich zu Fail to Ben enorm.

00:16:16: Okay...das

00:16:17: ist unter der Haube also deutlich moderner und schlanker.

00:16:21: Aber das eigentliche Verkaufsargument, dass Feature des Fail-to-Band wirklich alt aussehen lässt ist doch diese Community Threat Intelligence oder?

00:16:30: Die KP.

00:16:30: Ganz genau!

00:16:31: Das ist also das Telefon unseres Wächters.

00:16:33: Richtig!

00:16:34: Zwerg eine bestimmte IP Adresse als aggressiv melden landet die sofort auf einer Liste.

00:16:39: Ja

00:16:40: weil sie zum Beispiel woanders schon SSH Passworter geraten hat.

00:16:44: Genau und dieser IP landet dann auf einer globalen Blockliste.

00:16:48: Dein Server lädt diese Liste herunter und der Angräfer prallt schon an deiner Firewall ab, bevor er überhaupt ein einziges Paket an deinen Web-Server schicken kann.

00:16:57: Das ist präventive Abwehr!

00:16:59: Ein gewaltiger Unterschied zum reaktiven Ansatz.

00:17:02: Absolut Und hier ist auch das Geschäftsmodell des französischen Unternehmens hinter Cloudseck ziemlich clever gelöst – was aber auch oft zur Verwirrung führt.

00:17:10: Warum

00:17:10: das?

00:17:10: Naja die Software in sich ist komplett Open Source.

00:17:13: Du kannst den Quellercode einsehen und sie gratis nutzen.

00:17:16: Das System basiert nämlich auf einem Geben- und Nebenprinzip.

00:17:19: Warte,

00:17:20: lass mich raten!

00:17:21: Du meinst das Freemium-Modell?

00:17:23: Genau.

00:17:23: Wenn

00:17:23: ich als kleiner Nutzer bereit bin meine Angriffslocks mit der Community zu teilen Dann bekomme ich als Belohnung kostenlos Zugriff auf diese globale Blockliste.

00:17:33: Richtig?

00:17:34: Richtig.

00:17:34: Wenn ich aber ein riesiger Konzern bin, der sagt nein unsere internen Daten verlassen niemals das Haus.

00:17:41: Wir teilen aus Prinzip gar nichts.

00:17:43: Dann darf ich das Netzwerk trotzdem nutzen muss aber für den Zugang zur API bezahlen.

00:17:48: Exakt so funktioniert es!

00:17:50: Wer zum Schwarm beiträgt zahlt nichts.

00:17:52: Moment mal da muss sich jetzt sofort einhaken.

00:17:55: Ok schieß los

00:17:56: wenn Ich lese dass ein Tool meine Server locks also im Grunde die Bewegungsdaten auf meinem server automatisch an ein globales Netzwerk funkt.

00:18:06: Ja?

00:18:07: Da schrillen bei mir echt alle Datenschutzalarmglocken!

00:18:11: Das klingt wie ein massiver DSGVO-Albtaum, der nur darauf wartet von Anwälten zerflückt zu werden.

00:18:17: Das ist eine extrem wichtige und völlig berechtigte Frage.

00:18:21: Was passiert damit der Privatsphäre der Legitimnutzer meines Servers?

00:18:25: Wie gesagt das war auch auf Reddit die allererste Sorge der Community

00:18:28: Kann ich mir vorstellen.

00:18:29: Aber

00:18:30: wenn man da tief in die Quellen schaut gibt es hier klare Entwarnung.

00:18:34: Okay, warum?

00:18:35: Crowdsack lädt nicht einfach deine kompletten Lock-Dateien in die Cloud hoch!

00:18:39: Es teilt absolut keine Trafficdaten, keine Ur-ELS, die besucht wurden und vor allem keine Passwörter oder Payload-Inhalte.

00:18:47: Gut

00:18:47: das ist schon mal wichtig.

00:18:49: aber was genau wird dann geteilt?

00:18:51: Irgendwas muss ja fließen...

00:18:52: ...es sind im Grunde nur drei hochspezifische Metadaten.

00:18:56: und dass auch nur wenn ein Angriff erkannt wird.

00:18:58: Und die wären...?

00:18:59: Erstens der Zeitstempel des Angriffs, zweitens die IP-Adresse des Angreifers und drittens das Verhalten.

00:19:08: Das Verhalten?

00:19:10: Ja also die Regel, die getriegert wurde zum Beispiel SSH Brutors oder Portscan.

00:19:16: Ah okay!

00:19:17: Aus Sicht der DSGVO werden also überhaupt keine personenbezogenen Daten deiner unschuldigen Besucher übertragen sondern nur die isolierten Spuren von Angreifer gemeldet.

00:19:27: Okay, das ergibt Sinn und beruhigt mich jetzt etwas.

00:19:30: Aber lass uns von der Theorie mal in die Praxis

00:19:33: gehen!

00:19:33: Gerne

00:19:34: Wie baut man so ein modernes System tatsächlich auf?

00:19:38: Wenn ich mir die offizielle Dokumentation anschaue ist CrowdSec ja kein riesiger monolithischer Klotz den man einfach einmal installiert sondern es ist in verschiedene Bausteine unterteilt?

00:19:49: Richtig Es ist extrem modular aufgebaut.

00:19:52: Man kann sich das am besten wie einen Sicherheitsapparat vorstellen.

00:19:56: Es gibt drei Hauptkomponenten.

00:19:58: Zuerst die Lock-Processors, das sind sozusagen die Augen.

00:20:03: Ihre einzige Aufgabe ist es, die Lockdateien zu lesen und nach Mustern zu scannen.

00:20:08: Die Augen okay?

00:20:10: Und dann...

00:20:11: Dann gibt's die LAPI – die Local API.

00:20:13: Das ist das Gehirn

00:20:15: Verstehe!

00:20:16: Die LAP I sammelt alle Informationen von den Prozessors, gleicht sie mit der globalen Community Blockliste ab und trifft an die Entscheidung Ist das ein Angriff oder nicht?

00:20:25: Und dann fehlen noch die Muskeln, oder?

00:20:27: Genau.

00:20:28: Die sogenannten Bouncer!

00:20:29: Die Bouncer sind kleine Programme, die direkt an deiner Firewall sitzen

00:20:33: Also zum Beispiel an NF-Tables Ja

00:20:36: Oder direkt an deinem Webserver.

00:20:38: Sie führen die Befehle der LAPI blind aus und blockieren den Datenverkehr dann physisch.

00:20:43: Wenn man sich jetzt ein echtes Angriffsszenario vorstellt läuft das also so ab Ein Bot greift mein Webserver an.

00:20:51: Die Augen Also der Lock-Processor sehen das fehlerhafte Verhalten im Lock.

00:20:56: Sie melden es dem Gehirn, der LAPI.

00:20:58: Stimmt!

00:20:59: Das Gehirnsagt ist ein Angriff und befiehlt den Muskel an der Firewall, lasst diese IP nicht mehr durch.

00:21:06: Genauso ist es...

00:21:06: Und das passiert alles in Millisekunden?

00:21:09: Völlig richtig.

00:21:10: Diese Entkopplung von Gehirnen und Muskeln macht es gerade für größere Netzwerke so unglaublich mächtig.

00:21:15: Wie meinst du

00:21:16: das?!

00:21:16: Du könntest zum Beispiel fünf verschiedene Webserver betreiben.

00:21:19: Alle haben ihre eigenen Augen und Muskeln, aber sie sprechen alle mit nur einem einzigen zentralen Gehirn in deinem Netzwerk.

00:21:26: Ah!

00:21:27: Das heißt wenn auf Server A ein Angreifer erkannt wird, sagt das zentrale Gehirnen sofort allen Bounzern auf Server B C D und E Bescheid diese IP ebenfalls zu blockieren?

00:21:38: Exakt

00:21:39: eine absolute Synergie.

00:21:41: Und auf GitHub findet man ja auch Best Practices wie man das noch weiter anpassen kann.

00:21:47: Wenn man zum Beispiel von einem hartnäckigen Botnet genervt wird, kann man diese Standardsperrzeit von vier Stunden ganz einfach auf achtundvierzig Stunden oder sogar eine Woche hochdrehen.

00:21:58: Ziemlich nützlich!

00:21:59: Aber so genial das alles auch klingt... Auf Reddit gibt es dann nicht nur Jubel?

00:22:04: Nee, da stimmt.

00:22:05: Diese ganze Automatisierung bringt nämlich auch philosophische Konflikte mit sich.

00:22:10: Ein Nutzer namens Techfoo hat das in einer Diskussion sehr poandisch als Blackbox kritisiert.

00:22:16: Seine Kritik trifft da einen echt wunden Punkt bei allen Schwarmintelligenzsystemen,

00:22:21: die

00:22:23: Gefahr von False Positives also falschen Alarmen.

00:22:26: Seiner Sorge ist ja berechtigt.

00:22:27: was passiert wenn das Crowdsac-Netzwerk ein Fehler macht?

00:22:31: Was ist wenn die Community eine völlig legitime IP Adresse fälschlicherweise als bösartig einstuft?

00:22:38: Dann sperren Zehntausende Server weltweit diese IP blind aus, ohne überhaupt Fragen zu stellen.

00:22:44: Genau das ist das Problem!

00:22:45: Der Admin sitzt dann da und weiß überhaupt nicht warum ein legitimer Kunde plötzlich nicht mehr auf die Webseite kommt.

00:22:52: Das ist genau der Grund, warum Nutzer wie dieser Techfoo lieber bei der alten Methode von Fail to Ban bleiben wo sie jede einzelne Sperre selbst nachvollziehen können.

00:23:01: Auf der anderen Seite der Debatte stehen dann Administratoren, die riesige hochkomplexe Setups mit Proxmox-Clustern und dedizierten Firewalls betreiben.

00:23:11: Für sie ist CrowdSec ein absoluter Segen!

00:23:14: Ein anderer Nutzer beschrieb da wie er einen gigantischen Filter aufgebaut hat, der massenweise Mülltraffic schon am äußersten Rand seines Netzwerks vernichtet.

00:23:23: Also lange bevor dieser Traffic überhaupt die empfindlichen inneren Server erreicht?

00:23:27: Exakt.

00:23:29: Da drängt sich mir aber eine ganz praktische Frage auf.

00:23:31: Hau raus!

00:23:32: Wenn du jetzt zuhörst und sagst, hey ich betreibe kein Enterprise-Netzwerk, ich habe nur einen kleinen Raspberry Pi oder so ein günstigen Server für meinen Blog ist so ein vernetztes KI Schwarmkonstrukt dann nicht der absolute Overkill?

00:23:47: Verbraucht das nicht mehr Ressourcen als es am Ende spart?

00:23:52: Das ist ne sehr... Intuitive Annahme klar, aber tatsächlich ist exakt das Gegenteil der Fall.

00:23:59: Echt?

00:24:00: Warum das?

00:24:01: Gerade extrem schwache Hardware profitiert massiv davon wenn dieser ganze Mülltraffic schon geblockt wird bevor er den Webserver überhaupt erreicht.

00:24:09: Ah

00:24:09: ich verstehe!

00:24:10: Wenn ein Datenpaket von der Firewall abgewiesen wird kostet dass die CPU deines kleinen Raspberry Pies so gut wie gar nichts.

00:24:17: Aber wenn es durchkommt...

00:24:18: Wenn du den Angriff durchlässt und dein Webseurer eine Fehlermeldung generieren muss, Logs geschrieben werden müssen – das frisst richtig CPU.

00:24:27: Stimmt!

00:24:28: Die Block-Listen von Crowdsac räumen auf bevor die Arbeit überhaupt entsteht.

00:24:33: Interessanterweise zeigt sich in der Praxis sogar dass viele erfahrene Admins einfach beide Welten kombinieren.

00:24:39: Beide?

00:24:40: Wie

00:24:40: das?!

00:24:40: Sie nutzen Crowdsack für das grobe Rauschen aus dem globale Netz und lassen Fail-to-Band parallel laufen, für ganz spezifische lokale Dienste die sie zu hundert Prozent manuell kontrollieren wollen.

00:24:52: Das ist eigentlich der perfekte Kompromiss!

00:24:54: Die Synergie aus beidem?

00:24:55: Okay was nehmen wir aus all diesen Quellen heute mit?

00:24:57: Eine ganze

00:24:58: Menge.

00:24:58: Wir

00:24:58: haben gesehen wie essentiell ein solides Fundament ist also eine Default Denive Firewall mit NF Tables bei der man immer die gefährliche Docker Falle im Hinterkopf behalten muss?

00:25:07: Definitiv

00:25:08: Wir haben verstanden, warum der loyale Fail-to-Ban Nachtwächter so beliebt ist.

00:25:13: Aber durch Rejax eben an seine Leistungsgrenzen stoßen kann.

00:25:17: Und wir haben die faszinierende Mechanik der Crowdsack Schwarmintelligenz dekonstruiert... ...die gefahren präventiv abwert!

00:25:25: Wenn man das große Bild betrachten geht es hier halt nicht mehr nur um Tools.

00:25:28: Es geht um eine echte Veränderung der Denkweise.

00:25:30: Inwiefern?

00:25:31: Egal ob du dich für deinen nächsten Job vorbereitest oder heute Abend dein erstes eigenes Home Lab aufsetzt Du musst verstehen, dass Sicherheit einfach nicht mehr isoliert im stillen Kämmerlein stattfindet.

00:25:42: Richtig!

00:25:42: Die Angreifer nutzen riesige vernetzte Botnets.

00:25:45: sie kooperieren.

00:25:46: um überhaupt eine Chance zu haben muss unsere Abwehrstruktur das genauso tun.

00:25:51: Kollaborative Verteidigung ist die Zukunft.

00:25:54: aber bevor wir diese Analyse beenden gibt es da einen Gedanken der mir seit dem Lesen dieser ganzen Konzepte echt keine Ruhe mehr lässt?

00:26:01: Oh jetzt bin ich gespannt.

00:26:03: Crowdsack verlässt sich auf den Konsens der Community.

00:26:07: Wer bösartiges Verhalten meldet, erhöht langsam seinen sogenannten Trust-Score im System.

00:26:15: Aber stell dir doch mal folgendes Szenario vor!

00:26:18: Was wäre wenn ein gigantisches hochgradig koordiniertes Botnetz anfängt das System ganz langsam und gezielt zu manipulieren?

00:26:28: Sie könnten sich doch monatelang vorbildlich verhalten, nur um ihren Trustscore künstlich in die Höhe zu treiben.

00:26:36: Und dann an einem bestimmten Tag X fangen Zehntausende dieser Bots an völlig legitime IP-Adressen massenhaft und synchron als bösartig zu melden – vielleicht die von einem Konkurrenten oder sogar einer kritischen Infrastruktur?

00:26:52: Das wäre fatal!

00:26:53: Könnte man diese großartige Schwarmintelligenz so manipulieren, dass sie sich quasi als Waffe gegen das System selbst richtet und legitim in Traffic weltweit blockiert?

00:27:05: Das ist ein faszinierendes aber auch gruseliges Katz-und-Maus Spiel, das wohl nie wirklich endet.

00:27:10: Absolut!

00:27:11: Denk mal drüber nach bis zu unserer nächsten Analyse.