Hey all, i’ve decided I should probably setup something else to help block nefarious IP addresses. I’ve been looking into CrowdSec and Fail2Ban but i’m not really sure the best one to use.
My setup is OpnSense -> Nginx Proxy Manager -> Servers. I think I need to setup CrowdSec/Fail2Ban on the Nginx Proxy Manager to filter the access logs, then ideally it would setup the blocks on OpnSense - but i’m not sure that can be done?
Any experience in a setup like this? I’ve found a few guides but some of them seem fairly outdated.
Edit: thanks everybody for the great info. General consensus seems to be with crowdsec so I’ll go down that path and see how it goes.
You must log in or register to comment.
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)
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.yamlor 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’signoreipoption. If you are using Tailscale to administer the server, then it’s easier to whitelist. IIRC, you can usecscli decisions add --type whitelist --ip 192.168.1.100 --duration 1ybut 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 whitelisthttps://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.Hey bro. I apologize for getting back to you so late. Did you ever get this resolved? I’m not hugely knowledgeable about the intricacies of nginx. I went with Caddy, but there is probably some commonality between the two. lmk
All good, yea its because I need crowdsec installed on the proxy as well - not just the bouncer - in order to actually send the logs to Opnsense.
I ended up having some weird performance issues so I pulled it all out for now and will revisit another time.
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.
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
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.
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’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.
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 byipset).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.
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
Neither. Use wazuh. You’re welcome.
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.
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.
Why not just put everything behind a VPN and stop worrying?
How does this help with something like a mail server for a small org? Honest question.
It doesn’t.
It doesn’t, but I wouldn’t recommend selfhosting email for a small org. The low price of Office 365 or whatever Google is calling their business product now is far cheaper than the anguish of running your own server and dealing with spam, both incoming and making sure there’s none outgoing, and making sure your recipient servers aren’t considering your spam.
Our small mail server is doing OK. Incoming spam is an issue but not a massive problem. Outgoing spam doesn’t exist. Once a year the IP ends up on the Microsoft blocklist but using the deliverability form to submit mitigation requests is easy enough and takes half a day or so to sort out.
I’m looking forward to seeing what the Thunderbird team does with Stalwart.
That reminds me I’ve been meaning to spin up a server, install Stalwart and test it out.
VPNs are not a panacea by any stretch of the imagination. they are good for certain use cases but from OP’s description they would do next to nothing
It would protect all the services. Instead of having to secure each one, you only expose the VPN server and connect to that. You don’t have to worry about North Korean hackers breaching your services if they’re not exposed at all, only the single VPN service. Less attack surface, less worry.
And basically useless if you need external users to be able to connect to the services.
This is a scenario where a single node VPN would reduce, not increase OP’s security stance. You do have to worry about NK hackers breaching your services because they’re all exposed through the single node VPN server. Same attack surface, less knowledge needed to hit the target with the payload.
