I actually refrain from using Crowdsec since we found ourselves with a friend banning each other for no known reasons. (I swear I'm a good boy)
this post was submitted on 04 May 2025
107 points (96.5% liked)
Selfhosted
46671 readers
269 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
As you probably know the crowdsec bouncer doesn't directly parse logs or do checks like F2B filters. It queries the crowdsec LAPI for decisions and applies them. The “allowed” or “whitelisted” IP logic is handled at the Security Engine or LAPI level, not by the bouncer itself.
You can whitelist an ip in /etc/crowdsec/whitelists.yaml or even whitelist decisions in the whitelist.yaml as such:
name: private-ips
description: Whitelist local and private IPs
whitelist:
reason: "Allow local and private IPs"
ip:
- "127.0.0.1"
- "192.168.1.0/24"
cidr:
- "10.0.0.0/8"
Then issue sudo systemctl reload crowdsec. Kind of the same concept as F2B's ignoreip option. If you are using Tailscale to administer the server, then it's easier to whitelist. IIRC, you can use cscli decisions add --type whitelist --ip 192.168.1.100 --duration 1y but it doesn't add them to the whitelist.yaml. Instead it keeps them in crowdsec's database managed by LAPI. To undo: cscli decisions delete --ip 192.168.1.100 --type whitelist
https://docs.crowdsec.net/u/getting_started/post_installation/whitelists/
With the bouncer setup, I assume I need to pass in where to look for logs or something for those to be passed into the lapi? I followed this CrowdSec and Nginx Proxy Manager , as far as I can tell everything is connected an running, I have crowdsec running on OpnSense via the plugin - it appears to be healthy as per the CrowdSec Console.
npm | [nginx ] nginx: [error] [lua] crowdsec.lua:62: init(): error loading captcha plugin: no recaptcha site key provided, can't use recaptcha
npm | [nginx ] nginx: [error] [lua] ban.lua:37: new(): BAN_TEMPLATE_PATH and REDIRECT_LOCATION variable are empty, will return HTTP 403 for ban decisions
npm | [nginx ] nginx: [alert] [lua] crowdsec_openresty.conf:5):11: [Crowdsec] Initialisation done
npm | [supervisor ] starting service 'app'...
npm | [app ] [5/5/2025] [11:26:30 PM] [Global ] › ℹ info Using Sqlite: /data/database.sqlite
npm | [supervisor ] all services started.
Care to elaborate? This seems kind of insanely specific.
Also, if you're using fail2ban, the same thing would happen.
I don't have much to elaborate on ^^' but yeah, could have been an hyper specific case but that was my experience with it. I assumed my ip was banned on the crowd or something like that and even if my friend unbanned me twice, the ban came back. Don't know what really happened for sure.
Ok...but crowdsec bans abusive IPs. Are you saying your actions got you banned for some reason?
Also, whitelist first. Ban second.
I truly don't think I did anything to get banned. The only thing "non-standard" I do, is having a seedbox
CrowSec, it's not one that you mentioned but once they locate the source of the malicious traffic, they send out a murder of trained attack birds to resolve the issue.
Nah, that one conflicts with my IPoAC networks unfortunately :(
RFC 1149 compatibility is expected in an upcoming release, keep an eye out.
Crowdsec with a central LAPI server. You should install it on the servers themselves to monitor the application logs directly. Then every bouncer(firewall, router, edge device) connected to the LAPI will all block the same IPs. I got sick of repeat offenders and upped the ban time to 1 year in hours.
Awesome that makes a lot of sense, cheers. So I'll install the Crowdsec agent on the Nginx Proxy Manager, and potentially also on the servers.
No problem. It's a great piece of software. I have it monitoring logs for nextcloud, vaultwarden, mailcow(postfix & dovecot), basic nginx proxies (just to be safe and for rate limiting). I have 4 OPNsense and 1 Debian bouncers.
I had an issue with so a note about setting up the bouncer on OPNsense. If you have the LAPI on a different machine you can currently only connect OPNsense to it using the command line. The LAPI options in the web interface are for defining the interface to bind to and run the LAPI on OPNsense itself. Which isn't an issue, I just wanted it on a VM so it's easier to keep online instead of it going down if the OPNsense it's on fails. Plus I like to keep SSH disabled on my OPNsense devices and spend a bit of time using cscli on the LAPI VM from time to time.
Cheers, I've since discovered that's is "bouncers" that I want on the endpoints I.e on my Nginx Proxy Manager. I'll just use the LAPI on the Opnsense box for now I think.
From the guy that has been accused of going overboard on security measures, I use both. It just depends on your setup tho. On a low resource server, I would pick crowdsec as it covers more ground than F2B. Running two log parsers does use more resources. ~ my 2 cents
I’ve been meaning to check out crowdsec because it seems to fit my niche usage. Wuzah seems VERY powerful and something I could likely use at work so that’s an advantage but very complex. Fail2ban is good at what it does but very simplistic and would require a lot of individual instances that would seem like a bear to maintain. CrowdSec seems like it’s in the Goldilocks zone somewhere in the middle. Pretty powerful, not terribly hard to manage, and not too difficult to install. But I haven’t done anything with any of them yet so I’m not very much help. I am curious what you go with though.
I'm currently going through a similar situation at the moment (OPNSense firewall, Traefik reverse proxy). For my solution, I'm going to be trial running the Crowdsec bouncer as a Traefik middleware, but that shouldn't discourage you from using Fail2Ban.
Fail2Ban: you set policies (or use presets) to tempban IPs that match certain heuristic or basic checks.
Crowdsec Bouncer: does fail2ban checks if allowed. Sends anonymous bad behavior reports to their servers and will also ban/captcha check IPs that are found in the aggregate list of current bad actors. Claims to be able to perform more advanced behavior checks and blacklists locally.
If you can help it, I don't necessarily recommend having OPNSense apply the firewall rules via API access from your server. It is technically a vulnerability vector unless you can only allow for creating a certain subset of deny rules. The solution you choose probably shouldn't be allowed to create allow rules on WAN for instance. In most cases, let the reverse proxy perform the traffic filtering if possible.
I did have that same thought actually, with opening up opnsense to be modified. But I also like the idea of it getting blocked before it even gets into my network, instead if letting it in initially and then blocking afterwards - that's kinda the whole job of a firewall after all ha ha
Im a lazy mofo. I use fail2ban since SWAG has one built in.
Crowdsec will block external, public, IPs
Fail2Ban will block login attempts (ie from anywhere)
I have a similar setup with pfSense, pfBlockerNG, HAProxy, etc, but I keep F2B running on my DMZ server in case something is ever compromised as it'll block / slow down anyone trying to move around the network.
Crowdsec blocks login attempts too.
Crowdsec is much more efficient than fail2ban. Fail2ban is a lot of old single-threaded Python code with inefficient log parsing/tailing routines. Crowdsec is a more modern Go codebase.
If you're looking at old-school solutions, there's also DenyHosts.
I've been using crowdsec .. but I've yet to see anyone banned but myself so far. Is everyone else having to write tons of whitelist parsers? I could whitelist my IP but I feel like that's sidestepping the issue and doesn't address friends/family also getting banned, coffeeshops, etc.
Feels like I'm missing something as so far it's been quite a pain to configure
Where did you have it setup? Is your proxy configured to forward the real IP?
It's set up on the same box as my caddy install. I believe it's getting passed the real IP because that's what gets banned, and what I type in to unban it.
It just sees normal operations as http probing. Like if some other service goes down, my GetHomepage will then 404 and that's seen as probing. It bans surprisingly quick. Even after just one or two events (normal for someone just visiting the homepage) it'll just kick em right out
I've been having to inspect every alert and hand write whitelist parsers to whitelist 404s or whatever it may be for that app. Slowly accumulating a workable collection.. but seems like I'm missing something as no one else seems to complain about this in threads like these
Another example is my brother got banned for normal audiobookshelf usage. He just thought the server was buggy. It was just blocking him without us really noticing or thinking much of it at the time. Not great
Crowdsec if you have many instances that need to report to each other.
If you just have a single instance and care to configure f2b for those services, then it's fine. I would suggest incorporating the use of public blocklists though.
Fail2ban unless you need the features that crowdsec provides. They are different tools with different purposes and different features.
I thought crowdsec does everything fail2ban does in addition to global block lists?
Fail2ban is a Free/Open-Source program to parse logs and take action based on the content of these logs. The most common use case is to detect authentication failures in logs and issue a firewall level ban based on that. It uses regex filters to parse the logs and policies called jails to determine which action to take (wait for more failures, run command xyz...). It's old, basic, customizable, does its job.
crowdsec is a commercial service [1] with a free offering, and some Free/Open-Source components. The architecture is quite different [2], it connects to Crowdec's (the company) servers to crowd-source detections, their service establishes a "threat score" for each IP based on detections they receive, and in exchange they provide [3] some of these threat feeds/blocklists back to their users. A separate crowdsec-bouncer process takes action based on your configuration.
If you want to build your own private shared/global blocklist based on crowdsec detections, you'll need to setup a crowdsec API server and configure all your crowdsec instances to use it. If you want to do this with fail2ban you'll need to setup your own sync mechanism (there are multiple options, I use a cron job+script that pulls IPs from all fail2ban instances using fail2ban-client status, builds an ipset, and pushes it to all my servers). If you need crowdsourced blocklists, there are multiple free options ([4] can be used directly by ipset).
Both can be used for roughly the same purpose, but are very different in how they work and the commercial model (or lack of) behind the scenes.
Neither. Use wazuh. You're welcome.