4 ms·

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

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 would suggest how to do so. Because I'd like to see successful authentications in the logs and only those. So that could be a valid reason to change port, etc. But that's only because logs are lacking proper configurability.

mtlmtlmtlmtl 4y ago
Have you looked into logrotate?
n4bz0r 4y ago
> I tried to configure debian to remove noise from the logs and I couldn't. Not very elegant (as in, not with built-in tools), but using Logstash would be one way of achieving that. There probably is a better (simpler) way, though. https://www.elastic.co/guide/en/logstash/current/pipeline.html https://www.elastic.co/guide/en/logstash/current/pipeline.ht... Edit: After some research, rsyslog seems like a more appropriate candidate. But the docs don't seem too novice-friendly and the configuration is quite obscure. Tradeoffs. https://en.m.wikipedia.org/wiki/Rsyslog https://en.m.wikipedia.org/wiki/Rsyslog
deathanatos 4y ago
I primarily use it for logs. However, I've worked at a lot of startups, and no matter how much you try to discipline people, someone thinks their circumstance is special (and it somehow requires a password-based login), or someone is just lazy and sets a password for unfathomable reasons. So, for those people, I run fail2ban to allow it to act as a rate-limiter. But tptacek is right, in any sane situation, you don't really need it. But sometimes the situation isn't sane. > just disable password authentication and that's about it. a.) for what ever reason, I've had third-parties insist on passwords. (In healthcare¹, too. Ugh.) b.) For quite a while, Azure's "AADLogin" used keyboard-interactive, which meant that you couldn't disable it. Thankfully, that got fixed in a recent version. ¹In addition to fail2ban, we also did firewalls at the cloud level. The password was a good (secure) one, but I'd sleep easier with a key-based login.
- jcrawfordor 4y ago
  Big issue in healthcare is a lot of legacy integration brokers that had SFTP bolted on post-release using the existing UX and config framework for FTP, which had historically been the dominant protocol in healthcare. Depending on the broker sometimes key auth isn't supported at all, it is supported but has to be configured in a strange way that's different from the normal SFTP/FTP config, or it's supported just fine but the company has business processes like paperwork for their integration subcontractor that still assume FTP is used (this latter one does unfortunately come up...). You'll see the same thing in financial software for basically the same reasons.
b112 4y ago
apt-get install logcheck
theteapot 4y ago
> 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.
themoonisachees 4y ago
I don't think anybody with a sane config need fail2ban or similar. But as a sysadmin who works for clients who don't understand such concepts, sometimes it's easier going "okay, we will install it on your systems for $x" than explaining why it's useless. It's a business politics tool.

mtlmtlmtlmtl 4y ago

Have you looked into logrotate?

n4bz0r 4y ago

> I tried to configure debian to remove noise from the logs and I couldn't. Not very elegant (as in, not with built-in tools), but using Logstash would be one way of achieving that. There probably is a better (simpler) way, though. https://www.elastic.co/guide/en/logstash/current/pipeline.html https://www.elastic.co/guide/en/logstash/current/pipeline.ht... Edit: After some research, rsyslog seems like a more appropriate candidate. But the docs don't seem too novice-friendly and the configuration is quite obscure. Tradeoffs. https://en.m.wikipedia.org/wiki/Rsyslog https://en.m.wikipedia.org/wiki/Rsyslog

deathanatos 4y ago

I primarily use it for logs. However, I've worked at a lot of startups, and no matter how much you try to discipline people, someone thinks their circumstance is special (and it somehow requires a password-based login), or someone is just lazy and sets a password for unfathomable reasons. So, for those people, I run fail2ban to allow it to act as a rate-limiter. But tptacek is right, in any sane situation, you don't really need it. But sometimes the situation isn't sane. > just disable password authentication and that's about it. a.) for what ever reason, I've had third-parties insist on passwords. (In healthcare¹, too. Ugh.) b.) For quite a while, Azure's "AADLogin" used keyboard-interactive, which meant that you couldn't disable it. Thankfully, that got fixed in a recent version. ¹In addition to fail2ban, we also did firewalls at the cloud level. The password was a good (secure) one, but I'd sleep easier with a key-based login.

jcrawfordor 4y ago
Big issue in healthcare is a lot of legacy integration brokers that had SFTP bolted on post-release using the existing UX and config framework for FTP, which had historically been the dominant protocol in healthcare. Depending on the broker sometimes key auth isn't supported at all, it is supported but has to be configured in a strange way that's different from the normal SFTP/FTP config, or it's supported just fine but the company has business processes like paperwork for their integration subcontractor that still assume FTP is used (this latter one does unfortunately come up...). You'll see the same thing in financial software for basically the same reasons.

b112 4y ago

apt-get install logcheck

theteapot 4y ago

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

themoonisachees 4y ago

I don't think anybody with a sane config need fail2ban or similar. But as a sysadmin who works for clients who don't understand such concepts, sometimes it's easier going "okay, we will install it on your systems for $x" than explaining why it's useless. It's a business politics tool.