Crowdsec or fail2ban?

chip

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

cpsd

I only use fail2ban but crowdsec https://github.com/crowdsecurity/crowdsec looks very interesting.

angelius

Fail2ban, because crowdsec use a lot more cpu and slow down my high traffic workloads

tentor

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

febryanvaldo

CrowdSec much more interesting though.

tedtomato

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.

ariq01

I'm using fail2ban rn, and planning to try crowdsec later

dosai

Those who use fail2ban, could you share your jail settings?

cpsd

@dosai said:
Those who use fail2ban, could you share your jail settings?

I am only watching for 3 login fails in SSH

chip

@tentor said:

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

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

BingoBongo

crowdsec if paid
Fail2ban if I need something good but free

tentor

@chip said:

@tentor said:

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

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

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.

concept

I've used Crowdsec before for some of my servers and its been pretty good.

MallocVoidstar

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.

chip

@tentor said:

@chip said:

@tentor said:

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

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

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 do this too and a random ass ssh port

tentor

@chip said:

@tentor said:

@chip said:

@tentor said:

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

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

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 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).

qquccs

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!

chip

@qquccs said:
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)

chip

@tentor said:

Random SSH port won't protect you from anything but will keep logs clean (from network noise which consists of scanners and bruteforcers).

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

tedtomato

@MallocVoidstar said:
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.

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...

Levi

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.

tedtomato

@LTniger said:
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...

Bob_v2

You can check also csf. It's a pretty robust program with a lot of options.

eva2000

@Bob_v2 said:
You can check also csf. It's a pretty robust program with a lot of options.

Yup

• Cloudflare WAF/Firewall/Rate Limiting and Transform Rules for first app level layer
• + 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.

alilet

Neither. Just change your default SSH port to something else and you are good to go.

chitree

@alilet said:
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.

wedge1001

@chitree said:

@alilet said:
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

vitobotta

I have used both but prefer Fail2ban as it's simpler and seems to react more quickly

chitree

@wedge1001 said:

@chitree said:

@alilet said:
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'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.

MannDude

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.

sycot

@tentor said:

@chip said:

@tentor said:

@chip said: So my questions are fail2ban or crowdsec, which is better ?

What are goals exactly?

@chip said: And if fail2ban does anyone have any guides on how to get it to work with debian 11 and almalinux?

https://www.tecmint.com/install-fail2ban-rocky-linux-almalinux/
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11

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

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.

do you have a suggestion for key management when you want to access your servers from many different hosts?