Fail2Ban not installed, big security issue!

Hi

I just wanted to add that when SSH is publicly accessible, especially when the bitcoin and lightning node is exposed. SSH access should be properly protected.

by simply running: sudo apt-get install fail2ban

A service that IP ban computers for 10 minutes that attempt too many failed login attempts is automatically set up.

After setting this up myself my log showed:

tail -f /var/log/fail2ban.log

2018-08-08 09:05:13,556 fail2ban.filter         [31984]: INFO    [sshd] Found 121.18.238.123 - 2018-08-08 09:05:13
2018-08-08 09:05:16,261 fail2ban.filter         [31984]: INFO    [sshd] Found 121.18.238.123 - 2018-08-08 09:05:15
2018-08-08 09:05:26,252 fail2ban.filter         [31984]: INFO    [sshd] Found 121.18.238.123 - 2018-08-08 09:05:25
2018-08-08 09:05:28,957 fail2ban.filter         [31984]: INFO    [sshd] Found 121.18.238.123 - 2018-08-08 09:05:28
2018-08-08 09:05:39,332 fail2ban.filter         [31984]: INFO    [sshd] Found 121.18.238.123 - 2018-08-08 09:05:31
2018-08-08 09:05:39,826 fail2ban.actions        [31984]: NOTICE  [sshd] Ban 121.18.238.123

As you can see an Chinese IP address has been attempting to log in every couple of seconds for god knows how long. As soon as I installed Fail2Ban this IP was banned from access.

[NicolasDorier]

Fixed with https://mastodon.social/@BTCPayServer/100541625451629987

[harding]

If your server is protected by a secure passphrase (or, even better, has password access disabled and logins only using a private key), fail2ban and similar tools don’t add any security. However, the cryptographic setup for an SSH session (which happens before a passphrase is provided) is computationally expensive for both sides of the connection, so I’ve seen low-power computers (e.g. RPi version 1) CPUs overwhelmed by just by attempted passphrase brute forcing.

Fail2ban is a good and easy solution to this, although you do want to keep the ban time small in my experience—I’ve locked myself out of several systems before by, e.g., entering the wrong password several times in a row by accident. Another solution is requiring logins in sshd_config only using private keys (obviously after setting that up first), as I believe that will reject passphrase attempts before the expensive cryptographic setup starts.