4 ms·

Sure but if I only used fail2ban for sshd why should I install two separate pieces of software to handle the problem which the actual software I want to run has

Sure but if I only used fail2ban for sshd why should I install two separate pieces of software to handle the problem which the actual software I want to run has it built in?

pixl97 2y ago
Turning every piece of software into a kitchen sink increases its security exposure in other ways.
- fragmede 2y ago
  a system where sshd outputs to a log file then someone else picks it up and then pokes at iptables, seems much more of hacky than having sshd supporting that natively, imo. Sshd is already tracking connection status, having it set the status to deny seems like less of a kitchen sink and more just about security. the S in ssh for secure, and this is just improving that.
- hnlmorg 2y ago
  Normally I would agree with you, but fail2ban is a Python routine which forks processes based on outcomes from log parsing via regex. There’s so many ways that can go wrong…and has gone wrong, from one or two experiences I’ve had in the past. This is exactly the sort of thing that should be part of the server. In exactly the same way that some protocol clients have waits between retries to avoid artificial rate limiting from the server.
  - 1oooqooq 2y ago
    still better trying to improve fail2ban than to add a (yet another) kitchen sink on sshd
    - hot_gril 2y ago
      fail2ban has been around for so long, people get impatient at some point
      - usrbinbash 2y ago
        Impatient about what exactly? fail2ban is battle tested for well over a decade. It is also an active project with regular updates: https://github.com/fail2ban/fail2ban/commits/master/ https://github.com/fail2ban/fail2ban/commits/master/
        hot_gril 2y ago
        What hnlmorg said a few comments up
  - usrbinbash 2y ago
    > There’s so many ways that can go wrong There are a lot of ways a builtin facility of one service can go wrong, especially if it ends up being active by default on a distro. `fail2ban` is common, well known, battle-tested. And its also [not without alternatives][1]. [1]: https://alternativeto.net/software/fail2ban/ https://alternativeto.net/software/fail2ban/
    - hnlmorg 2y ago
      As I’ve already posted, I’ve ran into bugs with fail2ban too. Also adding firewalling to SSH is hardly “kitchen sinking” (as another commenter described it). You’re literally just adding another layer of security into something that’s literally meant to be used as an out of the box solution for creating secure connections. If you want to take issue with the “kitchen sink” mentality of SSH then complain about its file transfer features or SOCKS support. They are arguably better examples of feature creep than literally just having the server own what connections it should allow.
      - usrbinbash 2y ago
        > Also adding firewalling to SSH is hardly “kitchen sinking” sshd is a service. It may be one among dozens of other services running on a host. Now imagine for a moment, if EVERY service on the host took that approach. Every backend service, every network-facing daemon, every database, every webserver, voip servers, networked logging engines, userspace network file systems, fileservers...they all now take security into their own hands. Every single one of them has its own fail2ban-ish mechanism, blocklists it manages, rules for what to block and how long, what triggers a block, if and when a block will be lifted... Oh, and of course, there is still also a firewall and other centralized systems in place, on top of all that. How fun would such a system be to administer do you think? As someone with sysadmin experience, I can confidently say that I would rather join an arctic expedition than take care of that mess. There is a REASON why we have things like WAFs and IDS, instead of building outward-facing-security directly into every single webservice.
        hnlmorg 2y ago
- nerdbert 2y ago
  fail2ban has a lot of moving parts, I don't think that's necessarily more secure. I would trust the OpenSSH developers to do a better job with the much simpler requirements associated with handling it within their own software.
usrbinbash 2y ago
> why should I install two separate pieces of software to handle the problem https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-philosophy-8f56ed4c29ae https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-...
- sleepybrett 2y ago
  generally i agree with this principle, but fail2ban is kind of a hacky pos.
  - usrbinbash 2y ago
    > but fail2ban is kind of a hacky pos. It's battle-tested for well over a decade, has accumulated 10.8k stars and 1.2k forks on github, so it seems to do something right no? Not to mention that even if it were otherwise, that's not a reason to ignore UNIX philosopies that have served the FOSS world well for over half a century at this point. Last but not least, there are any number of alternative solutions.
    - sleepybrett 2y ago
      Just because it's 'battle tested' and has stars and is useful does not preclude it from being a hacky pos. Reading logs using regexps and then twiddling IP tables is not the cleanest method of achieving this result. I would much prefer if this functionality were either handled like ssh or if there was some kind of standardized messaging (dbus?) that was more purposeful and didn't rely on regex. It's useful because you can hook it up to anything that produces logs, it's hacky because that means you are using regexp. If the log format changes, you're likely fucked, not to mention that regexps are notoriously hard to make 'air tight' and often screwed up by newbies. Add to that in a case where your regexes start missing fail2ban will stop doing it's job silently.. not great my friend. It's been a useful hack for a very long time, but I'd like to see us move on from it.

Sure but if I only used fail2ban for sshd why should I install two separate pieces of software to handle the problem which the actual software I want to run has it built in?

pixl97 2y ago

Turning every piece of software into a kitchen sink increases its security exposure in other ways.

fragmede 2y ago
a system where sshd outputs to a log file then someone else picks it up and then pokes at iptables, seems much more of hacky than having sshd supporting that natively, imo. Sshd is already tracking connection status, having it set the status to deny seems like less of a kitchen sink and more just about security. the S in ssh for secure, and this is just improving that.
hnlmorg 2y ago
Normally I would agree with you, but fail2ban is a Python routine which forks processes based on outcomes from log parsing via regex. There’s so many ways that can go wrong…and has gone wrong, from one or two experiences I’ve had in the past. This is exactly the sort of thing that should be part of the server. In exactly the same way that some protocol clients have waits between retries to avoid artificial rate limiting from the server.
- 1oooqooq 2y ago
  still better trying to improve fail2ban than to add a (yet another) kitchen sink on sshd
  - hot_gril 2y ago
    fail2ban has been around for so long, people get impatient at some point
    - usrbinbash 2y ago
      Impatient about what exactly? fail2ban is battle tested for well over a decade. It is also an active project with regular updates: https://github.com/fail2ban/fail2ban/commits/master/ https://github.com/fail2ban/fail2ban/commits/master/
      - hot_gril 2y ago
        What hnlmorg said a few comments up
- usrbinbash 2y ago
  > There’s so many ways that can go wrong There are a lot of ways a builtin facility of one service can go wrong, especially if it ends up being active by default on a distro. `fail2ban` is common, well known, battle-tested. And its also [not without alternatives][1]. [1]: https://alternativeto.net/software/fail2ban/ https://alternativeto.net/software/fail2ban/
  - hnlmorg 2y ago
    As I’ve already posted, I’ve ran into bugs with fail2ban too. Also adding firewalling to SSH is hardly “kitchen sinking” (as another commenter described it). You’re literally just adding another layer of security into something that’s literally meant to be used as an out of the box solution for creating secure connections. If you want to take issue with the “kitchen sink” mentality of SSH then complain about its file transfer features or SOCKS support. They are arguably better examples of feature creep than literally just having the server own what connections it should allow.
    - usrbinbash 2y ago
      > Also adding firewalling to SSH is hardly “kitchen sinking” sshd is a service. It may be one among dozens of other services running on a host. Now imagine for a moment, if EVERY service on the host took that approach. Every backend service, every network-facing daemon, every database, every webserver, voip servers, networked logging engines, userspace network file systems, fileservers...they all now take security into their own hands. Every single one of them has its own fail2ban-ish mechanism, blocklists it manages, rules for what to block and how long, what triggers a block, if and when a block will be lifted... Oh, and of course, there is still also a firewall and other centralized systems in place, on top of all that. How fun would such a system be to administer do you think? As someone with sysadmin experience, I can confidently say that I would rather join an arctic expedition than take care of that mess. There is a REASON why we have things like WAFs and IDS, instead of building outward-facing-security directly into every single webservice.
      - hnlmorg 2y ago
nerdbert 2y ago
fail2ban has a lot of moving parts, I don't think that's necessarily more secure. I would trust the OpenSSH developers to do a better job with the much simpler requirements associated with handling it within their own software.

usrbinbash 2y ago

> why should I install two separate pieces of software to handle the problem https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-philosophy-8f56ed4c29ae https://alanj.medium.com/do-one-thing-and-do-it-well-a-unix-...

sleepybrett 2y ago
generally i agree with this principle, but fail2ban is kind of a hacky pos.
- usrbinbash 2y ago
  > but fail2ban is kind of a hacky pos. It's battle-tested for well over a decade, has accumulated 10.8k stars and 1.2k forks on github, so it seems to do something right no? Not to mention that even if it were otherwise, that's not a reason to ignore UNIX philosopies that have served the FOSS world well for over half a century at this point. Last but not least, there are any number of alternative solutions.
  - sleepybrett 2y ago
    Just because it's 'battle tested' and has stars and is useful does not preclude it from being a hacky pos. Reading logs using regexps and then twiddling IP tables is not the cleanest method of achieving this result. I would much prefer if this functionality were either handled like ssh or if there was some kind of standardized messaging (dbus?) that was more purposeful and didn't rely on regex. It's useful because you can hook it up to anything that produces logs, it's hacky because that means you are using regexp. If the log format changes, you're likely fucked, not to mention that regexps are notoriously hard to make 'air tight' and often screwed up by newbies. Add to that in a case where your regexes start missing fail2ban will stop doing it's job silently.. not great my friend. It's been a useful hack for a very long time, but I'd like to see us move on from it.