6 ms·

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

> 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 time state, as well as other things, like frustrating the attacker, not wasting connections on them. Having said that, this particular tool looks a bit shit ...

traceroute66 4y ago
> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no
- theteapot 4y ago
  > (not just SSH) ... We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.
  - nix23 4y ago
    Exactly, fail2ban/blacklistd is for software who lacks certain function ssh has for example sendmail, asterisk etc: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d https://github.com/fail2ban/fail2ban/tree/master/config/filt...
- tlamponi 4y ago
  Not disagreeing in general and disallowing password login for root is IMO really a no-brainer. But, it's nonetheless a fact that a (temporary) nft drop rule in the kernel is much more effective than traffic hitting a user space daemon like SSH. Some NICs even allow offloading that (e.g., in form of a bpf program) to the card itself, so that such traffic won't ever hit the system (CPU) at all. So yes, SSH can be made secure and rate-limited without anything else, but that won't be the most efficient solution; now fail2ban/sshguard/... ain't no free lunch either, so one needs to weight the added (IMO small, but still) complexity against benefits in a specific use case.
- BoardsOfCanada 4y ago
  Just to double check my sshd settings I logged in to a server I have, and while it had "PasswordAuthentication no" set in the normal place in the config file, there was a line added to the very end of it "PasswordAuthentication yes", which I guess overrides the previous one. The server is reinstalling the OS right now...
  - pferde 4y ago
    FWIW, your guess is incorrect. From sshd_config(5): "For each keyword, the first obtained value will be used." Still, if you cannot explain how that second line got in there, it is probably prudent to reinstall (perhaps even reflash BIOS).

traceroute66 4y ago

> Rate limiting You don't need fail2ban to rate-limit SSH. RFTM ... MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize. > trying to brute force AuthenticationMethods publickey PasswordAuthentication no ChallengeResponseAuthentication no PermitRootLogin no

theteapot 4y ago
> (not just SSH) ... We know about the SSH daemon config. You still get all sorts of probing that isn't a brute force on SSH.
- nix23 4y ago
  Exactly, fail2ban/blacklistd is for software who lacks certain function ssh has for example sendmail, asterisk etc: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d https://github.com/fail2ban/fail2ban/tree/master/config/filt...
tlamponi 4y ago
Not disagreeing in general and disallowing password login for root is IMO really a no-brainer. But, it's nonetheless a fact that a (temporary) nft drop rule in the kernel is much more effective than traffic hitting a user space daemon like SSH. Some NICs even allow offloading that (e.g., in form of a bpf program) to the card itself, so that such traffic won't ever hit the system (CPU) at all. So yes, SSH can be made secure and rate-limited without anything else, but that won't be the most efficient solution; now fail2ban/sshguard/... ain't no free lunch either, so one needs to weight the added (IMO small, but still) complexity against benefits in a specific use case.
BoardsOfCanada 4y ago
Just to double check my sshd settings I logged in to a server I have, and while it had "PasswordAuthentication no" set in the normal place in the config file, there was a line added to the very end of it "PasswordAuthentication yes", which I guess overrides the previous one. The server is reinstalling the OS right now...
- pferde 4y ago
  FWIW, your guess is incorrect. From sshd_config(5): "For each keyword, the first obtained value will be used." Still, if you cannot explain how that second line got in there, it is probably prudent to reinstall (perhaps even reflash BIOS).