3 ms·
If fail2ban is theater, so is a firewall, so is SELinux, so are filesystem permissions (a properly configured process would only read/write the files it's suppo
by matja 5y ago
If fail2ban is theater, so is a firewall, so is SELinux, so are filesystem permissions (a properly configured process would only read/write the files it's supposed to, right?).
If an remote vuln needs some stack-smashing technique that has a low probability of success, fail2ban is going to to slow that down - perhaps in a way that makes it more obvious in logs, buying you time to discover your broken configuration or out of date software. Same way that a firewall buys you time to find that your database is listening on 0.0.0.0.
- sk5t 5y ago> time to find that your database is listening on 0.0.0.0 I think that this would be the norm and desirable for databases serving clients other than the local host's. Plopping the database server onto a public network and allowing anyone at all to talk to it, on the other hand...
- rascul 5y agoI believe the implication is that a properly configured server isn't going to allow passwords, and fail2ban isn't much more than a log size reducer when passwords aren't allowed.
- randomtwiddler 5y agoI'm all about reducing the noise in log files. I've had three production servers go down for various clients and the primary reason was full disk, primarily due to log files.
- alternatetwo 5y agoWe've had a server go "down" due to log files too, but not because of size, but because of inodes. I think the samba server logged each incoming request into an empty text file with the IP. This eventually caused some problems, but we could still ssh in and delete the files ... but it's not fun to find out what even happened and to do that without autocomplete.
- tjoff 5y agoNothing wrong with a decent password.