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.
ELI5: Is Fail2Ban Necessary for Me?
Noob questions;
So I read it's primarily for ssh and Apache but is it still necessary if I use ssh key and Nginx instead?
Is Fail2Ban going to reduce lastb log?
(how do you block notty login attempt actually?)
Other important usages?
Thanked by 1matthewkilpatrick
Comments
fail2ban permanent and persistent ban and you are good to go
https://arno0x0x.wordpress.com/2015/12/30/fail2ban-permanent-persistent-bans/
fail2ban is always useful if you expose something to internet
Can firewall rules grow infinitely without causing degraded performance?
So I'm kinda confused here, since fail2ban blocks login attempts but if you're using key and password disabled, isn't it going to be blocked anyway?
Well, last time i had something around 5k IP without performance issue so i don't really know how big the list can grow, potentially infinite
Yea but the attempt will be still logged, they just can't enter the password because you are using the key so the connection will be dropped after the key request but is established anyway before it
Tends to vary by IP range but it can be worse for some. I think it was around 50k rules last time that I started to see issues. Increased latency at begging of page loads and inability to troubleshoot the firewall rules effectively. Surely will vary by hardware too.
Rarely do you see the same IP months down the road, the catch and release defaults are actually pretty sane.
Not as crucial in that case.
An alternative to fail2ban is sshguard, which is much lighter on resources.
You can also whitelist the IP address(es) that iptables will allow into port 22.
The way fail2ban and sshguard work is by blocking that address/host so it doesn't hit you again. Simple, and usually effective.
No. This is just a given that the overhead will still have some overhead. I still use week-long bans, and if they come back too many times, I keep a counter for the bastards that come back, and just put them back in place, but overall I haven't seen anything to the point that it isn't enough for trivial scan attacks.
Changing the port ? That way the connection won't even established
Fail2ban in recent debians comes with a "recidive" (I think that's how they misspell it) rule that blocks ip's for a week once they've gotten a few shorter blocks. Right now it has just 8 rules active, so they do give up after a while.
SSH key + passwords disabled + root logins disabled... fine in most cases
One firewall rule that only allows (management) access from 1 IP (e.g., your management VPN/shell) is good too
Changing the port is not a permanent solution, first or after someone with a scanner on that port will scan your machine, be sure of that. Not using standard ports is a good thing but not a permanent solution. You can try port knocking https://en.wikipedia.org/wiki/Port_knocking
Quoting this in case you edit it.
You don't like porn knocking too?
Misclicked <- delete this
When one of your goals is reducing log entries, it's a very very good solution. I don't know about you, but my automated incoming SSH brute force attempts stack up to about 50,000 per day on port 22, and about 500 per day on port 2222.
Stealth SSH with fwknop - & a trick for using 4096 bit keys with fwknop.
You should still use fail2ban however there are a few nice filters included for nginx & apache.
i didn't say that is not good, is absolutely a best practice but if one of the scanner will find the port you will receive the attack anyway
Still , better than nothing. Most attack doesn't really care bout scanning port. They will brute Force on port 22.
I think you can change the SSH port and use certificate to login SSH. Then, the log will be reduce.
It would be great to have a OTP (one time port) for this.
if you want to make it 0 logins attempts in the log, disable root log-in.
or public key works well too.
Change default port to avoid bots, disable root login, enable key authentication. Done.
Also give ddos deflate a go as well.
This isn't the greatest script. You'd do a hell of a lot better by just disabling KeepAlive and altering your TCP settings accordingly. All this will do is close a multitude of source requests from the same host. It wont really help that much.
Fail2ban (and sshguard) will hinder the client from this being even slightly useful- but nothing is as good as upstream filtering.
Well, not so great. Perhaps.
But if you set the settings high enough, you can prevent abusing connections and permit healthy ones once you whitelist cloudflare etc. It's not a protection suite indeed. But it does help a bit in some cases.
fail2ban is great! Custom filters to auto manage blocks. Works for anything with a log. I highly recommend.
Yeah, I guess that ddos deflate could (as a side effect) cover some of the functionality of fail2ban or sshguard. But for those of us who are more concerned about forced entry attempts than about ddos attacks, fail2ban or sshguard seems to be the better option.
You can use fail2ban with Nginx too just needs reconfiguring fail2ban to read nginx log paths and log entries properly. fail2ban is more for app level. You can also use CSF Firewall for server level login failure bans for SSH, ftp etc.
You can see my Centmin Mod / CentOS 7 only right now implementation of fail2ban beta testing at
example of fail2ban.sh status output https://github.com/centminmod/centminmod-fail2ban#fail2bansh
iptables + IPSET would go along way in mitigating degradation but yeah can only help to a point. On Centmin Mod I configure CSF Firewall to use IPSET if initial install auto detects a kernel with IPSET support
Yeah I've had 10K ips banned via CSF Firewall + IPSET enabled and my Linode VPS handled it without breaking a sweat