New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Crowdsec or fail2ban?
I've just stumbled upon crowdsec after seeing someone mention it here? ... and ive looked at fail2bam before but never really had much look with it
So my questions are fail2ban or crowdsec, which is better ?
And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?
Thanks
Thanked by 1BasToTheMax
Comments
I only use fail2ban but crowdsec https://github.com/crowdsecurity/crowdsec looks very interesting.
Fail2ban, because crowdsec use a lot more cpu and slow down my high traffic workloads
What are goals exactly?
https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11
CrowdSec much more interesting though.
CrowdSec will block many attacks before they even reach your servers, because it regularly downloads central IP files.
fail2ban is a paper map, CrowdSec is Waze.
CPU and RAM usage is not very high.
I'm using fail2ban rn, and planning to try crowdsec later
Those who use fail2ban, could you share your jail settings?
I am only watching for 3 login fails in SSH
My goals are to make it as hard as possible for the bad guys trying to login, already using csf with the ip lists and ipset configured
crowdsec if paid
Fail2ban if I need something good but free
For this you don't need fail2ban nor crowdsec - proper configuration of your server is enough. The best practice for SSH is to use public key authentication, disable remote root access (use sudo when needed root access), forbid password based authentication at all.
I've used Crowdsec before for some of my servers and its been pretty good.
CrowdSec uses a lot of CPU for me, even with 0 network activity on server. I just don't allow SSH password auth and don't expose unsafe services to the network.
I do this too and a random ass ssh port
Random SSH port won't protect you from anything but will keep logs clean (from network noise which consists of scanners and bruteforcers).
fail2ban is used by a lot of people, and people are using it.
If something goes wrong, it's easier to find the answer.
So if it's not particularly important, you should keep using fail2ban!
I'm actually currently not using either ... but have installed and configured fail2ban on various vps's I have and will see how it goes (it can only help really)
No but its a small step that makes it that much more difficult to login in the first place ... making my stuff a less attractive target to someone who has left ssh on port 22
CrowdSec is not just for SSH. Can monitor other types of logs, web apps etc.
Of course, if you don't expose any of those, then you don't need it...
Crowdsec -- proactive measure against possible threats. Used by those who don't have enough time/competence/faith in fail2ban.
Fail2ban - reactive measure. This means that your precious L7 will be touched in dirty ways before f2b will spank them. A lot more configurable, free to tune up for specific use case.
Personally I avoid both solutions. Unnecessary waste of precious VPS resource. Firewall your-self appropriate, rate limit, manipulate port access. That's it. Do not be lazy.
Firewalls, port access restrictions etc. don't protect against many attacks CrowdSec would protect against...
You can check also csf. It's a pretty robust program with a lot of options.
Yup
+
CSF Firewall for server side combined with CSF Blocklist with AbuseIPDB blocklist. Just polished off my implementation https://github.com/centminmod/centminmod-abuseipdb-reporter ^_^+
fail2ban with CSF Firewall and Cloudflare Firewall API block actions to pass offending IP to both CSF Firewall locally + Cloudflare Firewall API.Neither. Just change your default SSH port to something else and you are good to go.
Just setup wireguard tunnel and only allow SSH to an internal IP on the configured wireguard subnet.
Until wireguard fails and you have to hope that you can access and/or reboot via controlpabel.
I also thought about that and ditched it.
I now have:
Public IP: only with ssh-key (and the more critical systems only from multiple, IPs)
Private: password is fine
I have used both but prefer Fail2ban as it's simpler and seems to react more quickly
I've never had wireguard fail & I've been using it for years now. I did not think of that.
I always disable SSH password login.
Big fan of fail2ban for general use. I made this a while back to make it easier to review current blocks and jails: https://github.com/Incognify/fail2ban-at-a-glance
May be handy for some.
do you have a suggestion for key management when you want to access your servers from many different hosts?