5 ms·

This. I really do not understand why people use fail2ban when the threat is somewhere else. It won't stop a ddos but will certainly, at some point, prevent you

This. I really do not understand why people use fail2ban when the threat is somewhere else. It won't stop a ddos but will certainly, at some point, prevent you from logging in.

thelopa 3y ago
I disable password authentication and use fail2ban. It's unlikely they will be able to brute force my key, but no server is perfect. sshd might be compromised one day. I’d rather have an extra layer of defense just in case.
- wkat4242 3y ago
  It's impossible they will brute force your key if you have a decent length. While I'm sure it is possible for some (mainly government) actors to brute force keys, I'm also sure these do not include the same low-hanging-fruit vandals blasting brute force attacks. And I'm also pretty sure you're not one of the select targets of these highly advanced actors. A vulnerability in sshd is indeed possible and happens once in a while. Fail2Ban won't stop this though because a known exploit will let them through on the first attempt. I personally view fail2ban more as nuisance control when it comes to SSH with password auth disabled. Minimizing the log crap, the wasted CPU resources by the failed handshakes. It's not really a security protection in that scenario. In other cases (e.g. web logins where passwords must be used) it of course is.
  - sophacles 3y ago
    Unless the maintainer of your distro's ssh package accidentally introduces an error that reduces the number of possible keys to, say - 32,767 total possible keys.[1] That's a brute-forcible number of keys that fail2ban would help mitigate. (1: https://research.swtch.com/openssl https://research.swtch.com/openssl)
    - rerdavies 3y ago
      Or the NSA subverts a cryptographic standard in order to produce predictable seeds for cryptographic random-number generators that are used to produce private keys. [1] (1: https://www.bbc.com/news/technology-24048343 https://www.bbc.com/news/technology-24048343 )
  - drpixie 3y ago
    INCONCEIVABLE! You keep using that word. I do not think it means what you think it means.
theamk 3y ago
It keeps the logs cleaner. If you either don't look at the logs at all, or have fancy log analysis systems, then it does not matter. But if you are in the middle, and just manually look at the logs every once in a while, this would be a great help. If you are logging in via ssh, the chances of being locked out arr low - using password auth is a bad idea, and once you set up ssh keys, the connection will always succeed. And in case of rare event like new system setup, you can always ssh via some other system, -J is great for that.
- admax88qqq 3y ago
  > the connection will always succeed. Not from my experience. If you have too many keys and certain ssh agents like gnome keyring don't pick up the key intelligently and will try a all the keys in some order often resulting in the server giving rejecting you due to too many failures.
  - theamk 3y ago
    Yeah, this is annoying. But you don't live with it -- you either move the extra keys to subdir, so that gnome keyring does not pick it; or use "IdentitiesOnly yes"/"IdentityFile foo" in .ssh/config to restrict certain hosts to certain keys (and yes, those work with ssh agent caching too). I know many people just don't care about working tool, and tolerate the pain, but hopefully if someone knows enough to setup fail2ban, they should also be able to setup ssh config. Especially since reliable ssh connections is such a high quality of life improvement.
  - oehpr 3y ago
    Yes I've hit this as well! Such an annoying behaviour. However I think it's a good habit to make records in `~/.ssh/config` for each of your servers anyway just to keep tabs what, where, who, and with what keys.
- BrandoElFollito 3y ago
  > It keeps the logs cleaner. I move my port somewhere else to reduce the clutter > manually look at the logs every once in a while I imagine that this is more by curiosity than anything else (which is a perfectly normal reason to do that - I do it from time to time just because). For logs analysis and alerting I have automated systems. > using password auth is a bad idea It is not if the password is correct, security speaking.
bandrami 3y ago
20 years ago port-knocking was supposed to solve this issue for good but it seems to have been never really been taken up. I'm not sure why.
- NavinF 3y ago
  Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs
  - bombela 3y ago
    With port knocking or a simple as having SSH on a non-standard port, the connection request stops before even opening the TCP connection. That's less load on the system, less logs, less writing to storage, etc. Less of what you don't want must surely be preferable.
    - 9dev 3y ago
      …all for the cost of vastly increased complexity. You’re just micromanaging your pets there. If the load of failed login attempts or the log writes brings your servers down, you have a whole lot of other problems to take care of.
    - NavinF 3y ago
      Are we talking about ssh on an ESP32 or a 2U server? You'd saturate my transit port before I noticed the load on my server or the logs that I filter by default. btw TCP is cheap compared to public key crypto
- corn13read2 3y ago
  This is really only effective for password based logins, but most logins these days are key based
  - bandrami 3y ago
    No, it cuts the DOS resource usage by a factor of 4 because a TCP connection is never opened.
tredre3 3y ago
> This. I really do not understand why people use fail2ban when the threat is somewhere else. Fail2ban keeps my log short enough that I can review them daily, I don't have to sift through thousands of login attempt. > It won't stop a ddos but will certainly, at some point, prevent you from logging in. Yup, losing my key and having no password access will do that.
- jrockway 3y ago
  I'm not sure manual log scanning is all that interesting. You probably want to produce a list of successful logins and review that regularly.
  - wkat4242 3y ago
    If an attacker manages a succesful login you've already lost. Better to catch them in the act while they're scoping you out.
    - jrockway 3y ago
      If your SSH key leaks you're not going to have a warning. All you'll see is a login from yourself that you don't remember. I am pretty sure we turned off password authentication like 10 posts up this thread.
      - elesiuta 3y ago
        This is why I require both a private key and a password. I have fail2ban configured to block IPs with invalid private keys after a couple attempts, and if the key is valid to email me and rate limit invalid password attempts. This gives a more than sufficient warning if my key leaks which is already very unlikely, and this just makes it much more unlikely for both to be compromised, and only took an extra 5 minutes to configure.
        phanimahesh 3y ago
        How do you configure emails on successful logins? Can you share your config, sufficiently anonymized?
tjoff 3y ago
I really don't understand why people use keys when the threat is somewhere else.
- BrandoElFollito 3y ago
  Assuming that your comment is serious, where is the threat in your opinion?
  - tjoff 3y ago
    Bad passwords.
    - BrandoElFollito 3y ago
      Then I do not understand. Keys are the answer to bad passwords (among other things)
      - tjoff 3y ago
        It is one answer. Good passwords is another.

This. I really do not understand why people use fail2ban when the threat is somewhere else. It won't stop a ddos but will certainly, at some point, prevent you from logging in.

thelopa 3y ago

I disable password authentication and use fail2ban. It's unlikely they will be able to brute force my key, but no server is perfect. sshd might be compromised one day. I’d rather have an extra layer of defense just in case.

wkat4242 3y ago
It's impossible they will brute force your key if you have a decent length. While I'm sure it is possible for some (mainly government) actors to brute force keys, I'm also sure these do not include the same low-hanging-fruit vandals blasting brute force attacks. And I'm also pretty sure you're not one of the select targets of these highly advanced actors. A vulnerability in sshd is indeed possible and happens once in a while. Fail2Ban won't stop this though because a known exploit will let them through on the first attempt. I personally view fail2ban more as nuisance control when it comes to SSH with password auth disabled. Minimizing the log crap, the wasted CPU resources by the failed handshakes. It's not really a security protection in that scenario. In other cases (e.g. web logins where passwords must be used) it of course is.
- sophacles 3y ago
  Unless the maintainer of your distro's ssh package accidentally introduces an error that reduces the number of possible keys to, say - 32,767 total possible keys.[1] That's a brute-forcible number of keys that fail2ban would help mitigate. (1: https://research.swtch.com/openssl https://research.swtch.com/openssl)
  - rerdavies 3y ago
    Or the NSA subverts a cryptographic standard in order to produce predictable seeds for cryptographic random-number generators that are used to produce private keys. [1] (1: https://www.bbc.com/news/technology-24048343 https://www.bbc.com/news/technology-24048343 )
- drpixie 3y ago
  INCONCEIVABLE! You keep using that word. I do not think it means what you think it means.

theamk 3y ago

It keeps the logs cleaner. If you either don't look at the logs at all, or have fancy log analysis systems, then it does not matter. But if you are in the middle, and just manually look at the logs every once in a while, this would be a great help. If you are logging in via ssh, the chances of being locked out arr low - using password auth is a bad idea, and once you set up ssh keys, the connection will always succeed. And in case of rare event like new system setup, you can always ssh via some other system, -J is great for that.

admax88qqq 3y ago
> the connection will always succeed. Not from my experience. If you have too many keys and certain ssh agents like gnome keyring don't pick up the key intelligently and will try a all the keys in some order often resulting in the server giving rejecting you due to too many failures.
- theamk 3y ago
  Yeah, this is annoying. But you don't live with it -- you either move the extra keys to subdir, so that gnome keyring does not pick it; or use "IdentitiesOnly yes"/"IdentityFile foo" in .ssh/config to restrict certain hosts to certain keys (and yes, those work with ssh agent caching too). I know many people just don't care about working tool, and tolerate the pain, but hopefully if someone knows enough to setup fail2ban, they should also be able to setup ssh config. Especially since reliable ssh connections is such a high quality of life improvement.
- oehpr 3y ago
  Yes I've hit this as well! Such an annoying behaviour. However I think it's a good habit to make records in `~/.ssh/config` for each of your servers anyway just to keep tabs what, where, who, and with what keys.
BrandoElFollito 3y ago
> It keeps the logs cleaner. I move my port somewhere else to reduce the clutter > manually look at the logs every once in a while I imagine that this is more by curiosity than anything else (which is a perfectly normal reason to do that - I do it from time to time just because). For logs analysis and alerting I have automated systems. > using password auth is a bad idea It is not if the password is correct, security speaking.

bandrami 3y ago

20 years ago port-knocking was supposed to solve this issue for good but it seems to have been never really been taken up. I'm not sure why.

NavinF 3y ago
Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs
- bombela 3y ago
  With port knocking or a simple as having SSH on a non-standard port, the connection request stops before even opening the TCP connection. That's less load on the system, less logs, less writing to storage, etc. Less of what you don't want must surely be preferable.
  - 9dev 3y ago
    …all for the cost of vastly increased complexity. You’re just micromanaging your pets there. If the load of failed login attempts or the log writes brings your servers down, you have a whole lot of other problems to take care of.
  - NavinF 3y ago
    Are we talking about ssh on an ESP32 or a 2U server? You'd saturate my transit port before I noticed the load on my server or the logs that I filter by default. btw TCP is cheap compared to public key crypto
corn13read2 3y ago
This is really only effective for password based logins, but most logins these days are key based
- bandrami 3y ago
  No, it cuts the DOS resource usage by a factor of 4 because a TCP connection is never opened.

tredre3 3y ago

> This. I really do not understand why people use fail2ban when the threat is somewhere else. Fail2ban keeps my log short enough that I can review them daily, I don't have to sift through thousands of login attempt. > It won't stop a ddos but will certainly, at some point, prevent you from logging in. Yup, losing my key and having no password access will do that.

jrockway 3y ago
I'm not sure manual log scanning is all that interesting. You probably want to produce a list of successful logins and review that regularly.
- wkat4242 3y ago
  If an attacker manages a succesful login you've already lost. Better to catch them in the act while they're scoping you out.
  - jrockway 3y ago
    If your SSH key leaks you're not going to have a warning. All you'll see is a login from yourself that you don't remember. I am pretty sure we turned off password authentication like 10 posts up this thread.
    - elesiuta 3y ago
      This is why I require both a private key and a password. I have fail2ban configured to block IPs with invalid private keys after a couple attempts, and if the key is valid to email me and rate limit invalid password attempts. This gives a more than sufficient warning if my key leaks which is already very unlikely, and this just makes it much more unlikely for both to be compromised, and only took an extra 5 minutes to configure.
      - phanimahesh 3y ago
        How do you configure emails on successful logins? Can you share your config, sufficiently anonymized?

tjoff 3y ago

I really don't understand why people use keys when the threat is somewhere else.

BrandoElFollito 3y ago
Assuming that your comment is serious, where is the threat in your opinion?
- tjoff 3y ago
  Bad passwords.
  - BrandoElFollito 3y ago
    Then I do not understand. Keys are the answer to bad passwords (among other things)
    - tjoff 3y ago
      It is one answer. Good passwords is another.