7 ms·
Yeah I find young naive devops people implementing security watching and stuff like fail2ban but in the long run it reduces productivity. Stuff like fail2ban ca
by dalore 8y ago
Yeah I find young naive devops people implementing security watching and stuff like fail2ban but in the long run it reduces productivity. Stuff like fail2ban can block legitimate traffic (it blocked me on many occasion trying to work from home).
When I was young I too used to try implement detection and banning but realised it's a waste of time. Key only access to ssh and make sure you at least subscribe to security updates for all packages is enough.
For our own app we went the ELK route due to the number of log messages coming from our own application. But yes as you said it's a pain to manage. Also creating kibana graphs/views/desktop for each type of log is also painful.
A good service I believe would be someone to offer a turnkey/shrink wrapped managed ELK for self hosting. Not only managing the system side of it, but also offering services to help create custom kibana graphs.
- danieltillett 8y agoJust set a short ban time in fail2ban. I have it set to 5 minutes. The aim is just to slow down the kiddies so that my logs don’t fill with a zillion pointless attempts.
- spurgu 8y agoAnd/or just reconnect through another server or VPN.
- danieltillett 8y agoYes, but my aim is more to create a molasses pit to slow down the log fill rate rather than to ban anyone for long. If I manage to lock myself out I just get up and get a drink of water. Using a short ban time keeps the load of running fail2ban to a minimum. I at one point was banning the kiddies/bots for a week and 40% of the server load was chewed up just running fail2ban.
- gog 8y agoFail2ban has issues when you have a lot of IPs blocked in memory. The solution I came up with to this problem is to use a custom ban action that adds an IP to the blocked ipset list with a given TTL, but set fail2ban to think that the IP has to be only banned for 5 seconds or so. The result is that ipset purges the IP from the list after the TTL expires, but fail2bans working set is a 5 second rolling windows of blocked IPs. This works great and it's being used in production for a couple of years.
- danieltillett 8y agoSounds like a great solution. Have you written about this in any detail?
- atomical 8y agoDo you really need the space or is it just some anxiety issue / ocd issue?
- fragmede 8y agoIf a sufficiently interested botnet discovers your SSH server, it'll hammer your server with 10's of connections a second, from many different IPs. That doesn't take up enough bandwidth to be noticeable, but it can fill up the disk, when you're least expecting, which can cause all sorts of trouble. Of course there are ways to deal with it, but that's just extra work.
- atomical 8y agoFill up a terabyte? Doubt it, especially since logs are compressed nightly.
- ishaan12345 8y agoAre you serious? There are others https://riskemy.com/free-cloud-vulnerability-scanning-tools/ https://riskemy.com/free-cloud-vulnerability-scanning-tools/
- dalore 8y agoWhen your server is down and you need to ssh into an arbitrary 5 minute wait is going to frustrate you. You don't really need fail2ban at all. Just don't log failed password attempts. Key access only, no one is going to get in.
- danieltillett 8y agoI am not worried about people getting in via ssh, I am worried about some zero-day on some other service.
- combatentropy 8y ago> so that my logs don’t fill with a zillion pointless attempts What about moving SSH to a different port?
- danieltillett 8y agoI do this, but it is the port scanning that I am tracking. It is hard to find your ssh port if you get banned port scanning.