KeyHelp Community

Kommen sich Fail2ban und Crowdsec eigentlich in die Quere, oder könnten die parallel genutzt werden?

Falls ja, wäre ein Erfahrungsbericht mit beiden unter KH sehr interessant ...

Zum Topic:
Ich hab mir mal den Webauftritt von CrowdSec angeschaut und auch ein paar Meinungen zum Thema eingeholt, um meinen ersten Eindruck zu bestätigen...
Ich sehe leider keine Vorteile gegenüber f2b, dafür aber ein paar Nachteile.
Deswegen kurze Zwischenfrage:
Wo sollen bitte die Vorteile von CrowdSec liegen (und damit meine ich echte Vorteile, nicht irgendwelche Klicki Bunti WebUIs)? Mag mich mal jemand erleuchten?

slowmo wrote: ↑Sun 5. May 2024, 08:14 Ich finde Keyhelp vom Prinzip her ja nicht schlecht, aber es entfernt sich immer weiter vom "Stand der Technik"

Für deine Meinung und einen möglichen Gedankenaustausch zu dieser Thematik solltest du sinnvollerweise einen eigenen Thread (hier im OT Bereich) eröffnen...In diesem Thread wird das Thema eventuell untergehen

slowmo wrote: ↑Sun 5. May 2024, 08:14 Ich bin ja eigentlich ganz angetan von dieser Software, vor allem dem Community Aspekt, so dass Angreifer-IPs direkt wieder CrowdSec zur Verfügung gestellt werden.
...
Das sieht man leider auch dem phpBB Forum an, was doch kein Mensch mehr verwendet ... Discourse *hust* ist viel besser ...
...

Und es fehlt leider auch der native Docker-Support von Keyhelp, so dass auch viele andere Webanwendungen möglich sind, die mehr als nur die üblichen LAMP-Anforderungen der letzten 20 Jahre haben.
...

Bei Crowdsec stimme ich dir zu das ist nett und ich habe es auf einigen Servern laufen. Wesentlich angenehmer zu administrieren als die vernetzte Fail2ban Lösung die ich vorher gebaut hatte. Ich habe es noch nicht probiert aber meines Erachtens spricht ja nichts dagegen Fail2ban abzuschalten und Crowdsec zu installieren. Das kannst du dann halt nur nicht mehr über Keyhelp administrieren.

Bei allem anderen würde ich widersprechen, angefangen vom Phpbb das um Welten angenehmer zu bedienen ist als der Discourse Kram und auch übersichtlicher ist.

Für Docker gibt es zahleiche Oberflächen die man nutzen könnte, Keyhelp hat aber in meinen Augen einen ganz anderen Einsatzzweck der damit nicht wirklich kompatibel ist. Noch dazu bringt es unnütze Komplexität hinein die die Entwicklung unnötig verlangsamen würde.

Aber warum nutzt du du Keyhelp nicht einfach in nem LXC Container? Kommt ja deinem Szenario nah und Docker sollte parallel laufen(zumindest wüsste ich nichts was dagegen spricht). Ein paar LXC Keyhelps habe ich laufen und die tun ihren Dienst ohne Probleme.


An Sachen wie Cloudlinux wäre ich trotzdem interessiert.

--------------------------------------

Jolinar wrote: ↑Sun 5. May 2024, 14:05 Ich sehe leider keine Vorteile gegenüber f2b, dafür aber ein paar Nachteile.

In meinen Szenarien es Resourcenschonender und halt proaktiv. Viele Ips sind schon gesperrt bevor sie bei dir rumrandalieren können.

slowmo wrote: ↑Sun 5. May 2024, 08:14 Ich finde Keyhelp vom Prinzip her ja nicht schlecht, aber es entfernt sich immer weiter vom "Stand der Technik"

Also dazu würde mich echt mal eine Diskussion interessieren. Was ist denn Stand der Technik(bitte nicht Docker) ? Ich schaue mir regelmäßig den gesamten Markt an und soviel Innovation bei den Panels habe ich da generell in den letzten 10 Jahren nicht gesehen.
Ich bin da aber pragmatisch und lasse mich gerne überzeugen

Wo sollen bitte die Vorteile von CrowdSec liegen (und damit meine ich echte Vorteile, nicht irgendwelche Klicki Bunti WebUIs)? Mag mich mal jemand erleuchten?

Grob gesetzt ist es vergleichbar mir DNS Blacklists. Da profitierst du auch von Einträgen, welche von anderen Usern gemeldet worden sind. Andere profitieren damit auch von deinen Meldungen. So ist es auch bei CS.

Kommen sich Fail2ban und Crowdsec eigentlich in die Quere, oder könnten die parallel genutzt werden?

Parallele Nutzung ist grundsätzlich möglich. Wobei bei mir fail2ban nur noch sehr, sehr selten IPs sperrt.

Blackmoon wrote: ↑Sun 5. May 2024, 18:19 Grob gesetzt ist es vergleichbar mir DNS Blacklists. Da profitierst du auch von Einträgen, welche von anderen Usern gemeldet worden sind. Andere profitieren damit auch von deinen Meldungen. So ist es auch bei CS.

Das hat aber nichts mit Fail2ban zu tun ... blocking von bekannten attackierenden IP Adressen u. Ranges geht auch über ipset Blacklists.

Ralph wrote: ↑Mon 6. May 2024, 11:32 Das hat aber nichts mit Fail2ban zu tun ... blocking von bekannten attackierenden IP Adressen u. Ranges geht auch über ipset Blacklists.

Na da ist ja nur der Bonus, zusätzlich zu den Blocking Features. Wobei Ipsets auch ihre Berechtigung haben, ich habe zb auf einigen Servern alle Tor Exit Nodes darauf geblockt und auch komplette Länder sperrt man so schnell mal aus.

Das Thema ist schon ein gutes Stück älter aber wollte hier mal dazu beitragen.

Mein Setup ist etwas komplexer aufgebaut:
Ich habe CrowdSec direkt auf meiner OPNsense-Firewall installiert, wo es als sogenannte Local API (LAPI) fungiert. Diese LAPI ist der zentrale Baustein für meine verteilte Sicherheitsarchitektur. Alle anderen Server/Instanzen im Netzwerk nutzen diese zentrale CrowdSec-Instanz, um erkannte Angriffe oder verdächtiges Verhalten an die OPNsense zu melden. Die OPNsense-Firewall wiederum blockiert daraufhin netzwerkweit die IP-Adresse des Angreifers, also nicht nur für die betroffene Instanz, sondern für alle Systeme hinter der Firewall. So funktioniert CrowdSec bei mir als koordinierter Verteidigungsmechanismus.
Das Ganze funktioniert auch Standalone. Also ohne OPNsense, pfSense oder sonst was. Beispielsweise direkt auf einem Server mit iptables.

CrowdSec und Fail2Ban können problemlos parallel betrieben werden.
Es ist nicht notwendig, Fail2Ban zu deinstallieren oder zu deaktivieren. Beide Systeme arbeiten unabhängig voneinander und lassen sich problemlos nebeneinander nutzen.

Die CrowdSec-Installation ist erfreulich unkompliziert. Hier eine kurze Anleitung mit iptables:

1. CrowdSec Repository und Installationsscript laden
Das offizielle Installationsskript zieht automatisch alle nötigen Komponenten (Repo, Schlüssel, etc.):
2. Security Engine installieren
Hier wird die eigentliche Erkennungsengine von CrowdSec installiert. Diese analysiert Logdateien, erkennt Angriffe und erstellt “Decisions” (z. B. Blockieren einer IP):
3. IPTables Bouncer installieren
Der sogenannte Bouncer ist dafür zuständig, erkannte Angreifer auch tatsächlich zu blockieren. Hier konkret per iptables. Voraussetzung dafür ist, dass iptables auch auf dem System installiert ist. (Alternativ gibt’s auch Bouncer für pfSense/OPNsense etc.) CrowdSec unterstützt sowohl IPv4 als auch IPv6. Dabei wird automatisch eine Anbindung an die Blocklisten von CrowdSec Threat Intelligence eingerichtet. Das heißt, bereits bekannte, bösartige IP-Adressen aus der globalen CrowdSec-Community werden sofort blockiert, auch wenn sie dein System noch gar nicht angegriffen haben.


4. Setup Wizard ausführen
Der Wizard erkennt automatisch installierte Dienste von KeyHelp (wie z. B. sshd, apache, postfix, etc.) und richtet dafür passende Logparser und Erkennungsregeln ein: Während der Einrichtung habe ich alle vorgeschlagenen Dienste ausgewählt, um möglichst viel Angriffsfläche abzudecken. Dadurch wird für jeden Dienst ein passender Parser aktiviert, der die jeweiligen Logdateien auswertet (z. B. /var/log/auth.log für SSH).


5. (Optional) Anbindung an die CrowdSec Console
Wer seine Sicherheitslage zentral überwachen möchte, kann den lokalen CrowdSec-Agenten mit der offiziellen CrowdSec Console verbinden. Dort sieht man alle erkannten Angriffe, Statistiken, blockierte IPs und mehr bequem über eine Weboberfläche. Dazu bei CrowdSec registrieren https://app.crowdsec.net/. Nach dem Einloggen solltet ihr einen vorgefertigten API-Befehl finden. Etwa sowas wie:
CrowdSec ist damit installiert, aktiv und blockiert zuverlässig. Durch die gemeinsame Nutzung profitiert jeder von der Schwarmintelligenz. Je mehr mitmachen, desto effektiver wird der Schutz für alle.

Nach nur zwei Tagen Laufzeit wurden bei mir bereits mehrere verdächtige Aktivitäten erkannt und vermutlich hunderte schädliche Anfragen automatisch im Vorfeld blockiert, dank der bereits zusätzlich zu CrowdSec vorhandenen Aliases und Firewall-Regeln in OPNsense.

Dabei war eine beachtliche Bandbreite an Angriffstypen vertreten:

Danke erstmal an @lrab für deinen ausführlichen Beitrag!

Eine Frage hätte ich da aber:

lrab wrote: ↑Sat 14. Jun 2025, 15:28 Während der Einrichtung habe ich alle vorgeschlagenen Dienste ausgewählt, um möglichst viel Angriffsfläche abzudecken. Dadurch wird für jeden Dienst ein passender Parser aktiviert, der die jeweiligen Logdateien auswertet (z. B. /var/log/auth.log für SSH).

Verarbeitet Crowdsec auch die modernere Loggingvariante im Journal?

Jolinar wrote: ↑Sat 14. Jun 2025, 16:34 Verarbeitet Crowdsec auch die modernere Loggingvariante im Journal?

Hallo Jolinar,
ja CrowdSec unterstützt auch Journal. https://docs.crowdsec.net/docs/data_sources/journald/
Eben kurz nachgeschaut, für SSH nutzt CrowdSec nach dem Setup Wizard sogar Journal:



Für Apache die Logfiles: