5 ms·

fail2ban is the kind of pseudo-security applied just because someone's cousin mentioned that in his blog. It provides zero security. If your endpoint uses defa

fail2ban is the kind of pseudo-security applied just because someone's cousin mentioned that in his blog. It provides zero security. If your endpoint uses default usernames you will be shot anyway because of IP spread. If your security is good you add something that will block your legitimate connection when you are in the middle of nowhere and, shit, cannot access your <some service>.

d-z-m 2y ago
"security" is a term that has to be defined in relation to a threat model. If your threat model is an attacker with a static IP hammering your server, fail2ban does provide some security against that sort of attacker.
- BrandoElFollito 2y ago
  No it does not. If the packet is at your door it is too late already. Then either it does not matter in which case you do nothing, or it matters (DoS) and then you have other problems. You are right that security works in the context of a threat model. There are however useless tools that give a false sense of "security" that do not fit in any reasonable model. I have cases where I block whole ranges of IPs for "legal" reasons - it does not make sense but there you are, the ones who write the rules are not the ones who actually know the stuff.
  - d-z-m 2y ago
    > No it does not. If the packet is at your door it is too late already. Too late for what? Again, it only makes sense to talk about "security" in the context of a threat model. You can debate the reasonableness of that threat model, but that's another discussion. My threat model(for the sake of argument :^)) is an attacker with a static public IP address trying to bruteforce access to my service via repeated login attempts. I'll maintain(for now) that fail2ban can be an effective tool that does provide some security against an attacker of this kind.
    - BrandoElFollito 2y ago
      You wrote that someone is hammering your IP. This was for me the definition of a DoS. Nothing on your side will mitigate that. But it does not really matter anyway. Your threat model is a single IP attacking you. What are you concerned about? That they will find services that are exposed and attack them? You should be securing these. You will never be attacked by one IP. The exact same attack will be done from many, many IPs and you do not want to defend against IPs attacking you, but against them exploiting a vulnerability on your side. Of course there is the "why not an extra layer of protection". This is great when you want to obscure something (moving a port for instance) because this does not have an effect on your system. Just imagine what happens when fail2ban goes south and blocks all addresses, or half of them, or yours because you tried too many times. This is a moving part that is actually dangerous.
- SahAssar 2y ago
  If your server is on the internet with a public ssh server then it is probably providing some sort of internet service. That internet service is almost always easier to DoS than your openSSH server. If you are not providing a internet service then why is your SSH open to the internet?
  - kloop 2y ago
    > If you are not providing a internet service then why is your SSH open to the internet? So that I can ssh into it from various places and do stuff on my home server from elsewhere
    - SahAssar 2y ago
      So you are accessing that server's services from some network, why are you not only allowing SSH over that network? Or, if your service is open to the internet then why does not what I said above hold true?
      - kloop 2y ago
        I guess I am technically, but only for myself
        SahAssar 2y ago
        What is the networking difference between a service for yourself that you want to access from "various places" and a public service with auth checks for your key?
  - jszymborski 2y ago
    Maybe the service is provided over SSH via e.g. port-forwarding (or is simply "SSH access to a server").
    - SahAssar 2y ago
      Sure, but are L7 attacks easier than L4 against those servers? Adding more layers/software has a cost in configuration, maintenance, attack-surface, etc.
zbentley 2y ago
You're not wrong, but I'd say fail2ban still has value for junior operators seeking to reduce load and increase stability. If you don't know how to harden SSH, fail2ban is offers a much friendlier way to reduce the volume of logspam, CPU burn, and network traffic. It's just a pity that it's understood/documented/pitched as something that substantially increases security.
- BrandoElFollito 2y ago
  > If you don't know how to harden SSH then you do not open it to Internet. Otherwise you patch aggressively, you use ssh keys and not passwords and you move it to some random port to hide it a bit (it actually helps) > logspam you can filter this out in your log management tool > CPU burn if this is your concern, then you have a hep of issues you need to address. I have never seen a CPU perf hit because of such behaviour (there are cases where it happens, butthis is due to a vulnerability of the service) > network traffic the packet is here already, there is nothing to reduce
  - Karunamon 2y ago
    Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason. Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
    - BrandoElFollito 2y ago
      > Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason. yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV. > Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else. enumeration and brute force on SSH fail by design when using keys. As for other services I do not see how this helps - you will block random IPs hoping that a vulnerable site is not taken over if they happen to get back. It is not common (at least in my monitoring of several honeypots in various locations) to have the same IP being particularly visible. Sure they are back sometimes but this is quite exceptional. Anyway - it is not worth the hassle, better have proper hardening.
mmsc 2y ago
People don't believe it's possible for software to be secure, and need a secondary defense to "protect them".
- catalypso 2y ago
  > People don't believe it's possible for software to be secure Rightfully so. You'd statistically be almost always right considering a software unsecure given enough time (for the vulnerabilities to be introduced then found). > need a secondary defense to "protect them" Nothing wrong with that. It's called Defense in Depth and is rather advised. Once you understand that security measures are not bulletproof, stacking them proves to be an easy way to increase protection. The case of fail2ban is not trivial: reducing log noise is a great perk, and can indirectly help with monitoring (you'd more easily notice suspicious behaviour if it's the only thing on your logs), but it comes at the small cost of setting it up, and accepting the risk of having a shared IP unwillingly blocked.
- marcosdumay 2y ago
  Except that it explicitly doesn't protect against security bugs.
eikenberry 2y ago
I always read the main use case had nothing to do with security, but was to reduce log spam.
ars 2y ago
fail2ban increases your server performance. It cuts down on enormous amounts of logging from failed attempts, and reduces the CPU used to deal with the failures. Some sites get a mind boggling amount of attempts. For example I sysadmin some Jewish sites, and they get exponentially more hacking attempts than the sites not mainly used by Jews. (This was before the current war mind you, I'm sure it's worse now.)

d-z-m 2y ago

"security" is a term that has to be defined in relation to a threat model. If your threat model is an attacker with a static IP hammering your server, fail2ban does provide some security against that sort of attacker.

BrandoElFollito 2y ago
No it does not. If the packet is at your door it is too late already. Then either it does not matter in which case you do nothing, or it matters (DoS) and then you have other problems. You are right that security works in the context of a threat model. There are however useless tools that give a false sense of "security" that do not fit in any reasonable model. I have cases where I block whole ranges of IPs for "legal" reasons - it does not make sense but there you are, the ones who write the rules are not the ones who actually know the stuff.
- d-z-m 2y ago
  > No it does not. If the packet is at your door it is too late already. Too late for what? Again, it only makes sense to talk about "security" in the context of a threat model. You can debate the reasonableness of that threat model, but that's another discussion. My threat model(for the sake of argument :^)) is an attacker with a static public IP address trying to bruteforce access to my service via repeated login attempts. I'll maintain(for now) that fail2ban can be an effective tool that does provide some security against an attacker of this kind.
  - BrandoElFollito 2y ago
    You wrote that someone is hammering your IP. This was for me the definition of a DoS. Nothing on your side will mitigate that. But it does not really matter anyway. Your threat model is a single IP attacking you. What are you concerned about? That they will find services that are exposed and attack them? You should be securing these. You will never be attacked by one IP. The exact same attack will be done from many, many IPs and you do not want to defend against IPs attacking you, but against them exploiting a vulnerability on your side. Of course there is the "why not an extra layer of protection". This is great when you want to obscure something (moving a port for instance) because this does not have an effect on your system. Just imagine what happens when fail2ban goes south and blocks all addresses, or half of them, or yours because you tried too many times. This is a moving part that is actually dangerous.
SahAssar 2y ago
If your server is on the internet with a public ssh server then it is probably providing some sort of internet service. That internet service is almost always easier to DoS than your openSSH server. If you are not providing a internet service then why is your SSH open to the internet?
- kloop 2y ago
  > If you are not providing a internet service then why is your SSH open to the internet? So that I can ssh into it from various places and do stuff on my home server from elsewhere
  - SahAssar 2y ago
    So you are accessing that server's services from some network, why are you not only allowing SSH over that network? Or, if your service is open to the internet then why does not what I said above hold true?
    - kloop 2y ago
      I guess I am technically, but only for myself
      - SahAssar 2y ago
        What is the networking difference between a service for yourself that you want to access from "various places" and a public service with auth checks for your key?
- jszymborski 2y ago
  Maybe the service is provided over SSH via e.g. port-forwarding (or is simply "SSH access to a server").
  - SahAssar 2y ago
    Sure, but are L7 attacks easier than L4 against those servers? Adding more layers/software has a cost in configuration, maintenance, attack-surface, etc.

zbentley 2y ago

You're not wrong, but I'd say fail2ban still has value for junior operators seeking to reduce load and increase stability. If you don't know how to harden SSH, fail2ban is offers a much friendlier way to reduce the volume of logspam, CPU burn, and network traffic. It's just a pity that it's understood/documented/pitched as something that substantially increases security.

BrandoElFollito 2y ago
> If you don't know how to harden SSH then you do not open it to Internet. Otherwise you patch aggressively, you use ssh keys and not passwords and you move it to some random port to hide it a bit (it actually helps) > logspam you can filter this out in your log management tool > CPU burn if this is your concern, then you have a hep of issues you need to address. I have never seen a CPU perf hit because of such behaviour (there are cases where it happens, butthis is due to a vulnerability of the service) > network traffic the packet is here already, there is nothing to reduce
- Karunamon 2y ago
  Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason. Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
  - BrandoElFollito 2y ago
    > Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason. yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV. > Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else. enumeration and brute force on SSH fail by design when using keys. As for other services I do not see how this helps - you will block random IPs hoping that a vulnerable site is not taken over if they happen to get back. It is not common (at least in my monitoring of several honeypots in various locations) to have the same IP being particularly visible. Sure they are back sometimes but this is quite exceptional. Anyway - it is not worth the hassle, better have proper hardening.

mmsc 2y ago

People don't believe it's possible for software to be secure, and need a secondary defense to "protect them".

catalypso 2y ago
> People don't believe it's possible for software to be secure Rightfully so. You'd statistically be almost always right considering a software unsecure given enough time (for the vulnerabilities to be introduced then found). > need a secondary defense to "protect them" Nothing wrong with that. It's called Defense in Depth and is rather advised. Once you understand that security measures are not bulletproof, stacking them proves to be an easy way to increase protection. The case of fail2ban is not trivial: reducing log noise is a great perk, and can indirectly help with monitoring (you'd more easily notice suspicious behaviour if it's the only thing on your logs), but it comes at the small cost of setting it up, and accepting the risk of having a shared IP unwillingly blocked.
marcosdumay 2y ago
Except that it explicitly doesn't protect against security bugs.

eikenberry 2y ago

I always read the main use case had nothing to do with security, but was to reduce log spam.

ars 2y ago

fail2ban increases your server performance. It cuts down on enormous amounts of logging from failed attempts, and reduces the CPU used to deal with the failures. Some sites get a mind boggling amount of attempts. For example I sysadmin some Jewish sites, and they get exponentially more hacking attempts than the sites not mainly used by Jews. (This was before the current war mind you, I'm sure it's worse now.)