81–90 of 149 posts
I would probably use something like pam_tally or pam_shield, since it's taking counts directly from the login flow and not via log files. Mentioned in other comments, protecting from brute force isn't really the big benefit. The benefit is reducing noise in logs so that you can see more serious activity.
Earlier quoted context omitted.
I _WANT_ to harvest IP's of PC's trying to SSH into any of my servers. I want them because then I can block ALL traffic coming from their IP's. At my last gig, I had thousands of domains and hundreds of servers running on every major (and a shitload of minor) service provider. I custom scripted all these servers to compile all the IP's that attempted a connection, send those lists back to HQ, and then distribute back…
There is a whole Internet worth of random IPv4 addresses being variously used to variously attack various computers. Your blocklist doesn't even approximate it. What's the point of trying to track and block 0.000000001% of the machines that might be used to attack you?
I get keys are better than passwords, but how do you enforce key rotation for non-technical users when they can barely manage to changer their passwords? I much prefer 2FA than keys for non-technical users.
Perhaps I'm overlooking something?
Earlier quoted context omitted.
Fail2ban is written in Python and managed to have a vulnerability.
Since when being written in Python automatically makes a program less vulnerability prone than usual?
No programming language can stop a determined developer from creating a vulnerability, but some languages make the task easier than others.
One to two lines of iptables limits connection attempts, making a brute force attack take thousands of years. No logging, no monitoring, no extra software. If you only use SSH keys, no brute force attack will work anyway. https://www.systutorials.com/how-to-use-iptables-to-limit-ra... https://making.pusher.com/per-ip-rate-limiting-with-iptables... https://stackoverflow.com/questions/18616246/iptables-limit-... https:…
The iptables methods all have the flaw that multiple sequential short-lived successful connections will trigger a ban too. Limiting Internet-facing SSH connections to key-only is definitely a good idea, though.
If you disable password auth completely (you're using key auth... right???) most of the password bruteforcers will just go away.
I'd expect a (ex?) crypto developer to think security from another perspective, but what if the key is leaked? It's time another prevention system may save your day.
The only help against that scenario is a true multi factor setup, or maybe a hardware-based security token that needs a second factor (fingerprint or PIN) to unlock.
Earlier quoted context omitted.
I agree. I never understood why people use all this stuff. If you use strong enough passwords, it's impossible to be brute-forced, simple as that. If you can't control people on your servers and afraid of weak passwords, just disable password authentication and that's about it. Now the issue of logs is real. I tried to configure debian to remove noise from the logs and I couldn't. May be someone with more knowledge w…
> I never understood why people use all this stuff ... Now the issue of logs is real. I tried to configure debian to remove noise from the logs and I couldn't. Sounds like you understand at least one reason people use stuff like this (including, most prominently, fail2ban ). Rate limiting and banning IPs trying to brute force and/or probe open ports (not just SSH) goes a long way to cleaning up your logs, your real t…
You don't need fail2ban to rate-limit SSH.
RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize.
> trying to brute force
AuthenticationMethods publickey
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin noEarlier quoted context omitted.
The iptables methods all have the flaw that multiple sequential short-lived successful connections will trigger a ban too. Limiting Internet-facing SSH connections to key-only is definitely a good idea, though.
I experienced this at a previous company. Yocto/bitbake wanted to do a lot of git clones over SSH very quickly, but a firewall interpreted this as a brute force because it couldn’t tell that each SSH connection was actually successfully authenticating.
ServerAliveInterval 60
ControlMaster auto
ControlPath ~/.ssh/conn/%r@%h:%p
ControlPersist 1h
In a sane configuration, the only thing a tool like this should be doing for you is keeping your logs clear. If you're deploying something to mitigate the risk of brute-force attacks on your server, the problem is that it's possible to brute-force your server, not that you don't have an autoblocking system enabled. These tools are popular, but I think they're kind of silly. Later I read some comments below, which com…
But it's even scarier: it's written in C.