Keep away massive SSH login attempts

[EuclideanCoffee]

I work in security. I've seen so many exploits in network forensics. I do not like opening my private home LAN for any reason.

[TheFu]

Don't think I've ever seen anyone attack openvpn ports. I have seen some scans and some bad connection attempts, but after a few attempts, they gave up and never returned. Just a few attempts in a week.

Back when I ran ssh on 22/tcp, I was seeing over 1000 attacks an hour, every hour, for weeks, before I put restrictions in place. Ignorance was bliss.

I wasn't paranoid until one of my systems was hacked and they attempted to convert it a C&C node. It wasn't a high profile server, they just happened to scan and find it with some BIND software that was 3 months out of date. This was around 2002. Fortunately, they only got in and then attempted to gain root, but failed. The method they used trying to gain root caused an warning email to be sent with each attempt - I awoke with over 1400 emails. I wasn't going to miss that.

I think being lucky is good, but taking reasonable basic security steps and having automatic, versioned, backups is better. The problem is that what we think is basic security, someone really new would see as being paranoid. After all, nobody has any interest in their little server, right?

[Elmi77]

Hi,

fail2ban is a really nice tool and seems to do the job, so thanks for the hint!

No idea why it is not installed by default on Ubuntu Server...

[DuckHook]

…No idea why it is not installed by default on Ubuntu Server...

Because many of us do not have our servers open to the WAN. We only run our servers within our local LAN. For me, fail2ban would be an impediment.

[Elmi77]

OK, update: fail2ban could massively reduce the hacking attempts, but not completely stop it. So an other question: is there a possibility to limit SSH-access based on the geolocation of the source IP? I know that people from exactly two countries are allowed to log in, so a filter which permits only these countries would be a nice solution also for these spoofed IPs which are random.

[The Cog]

Good geolocation filters will limit hacking attempts to the those from the countries that you whitelist, but will not stop those.

Like SeijiSensei, I would suggest using a VPN connection from your users. Except that I think I would favour wireguard over openvpn because I think it's much easier to configure. And wireguard won't even respond to callers unless their initial packet is encrypted with the correct key, so it's not easily discoverable.

[TheFu]

OK, update: fail2ban could massively reduce the hacking attempts, but not completely stop it. So an other question: is there a possibility to limit SSH-access based on the geolocation of the source IP? I know that people from exactly two countries are allowed to log in, so a filter which permits only these countries would be a nice solution also for these spoofed IPs which are random.

Don't think blacklist. Think whitelist. That means blacklist every IP (don't for get IPv6) and only allow the specific subnets access. In short, ask your users.

fail2ban doesn't prevent hacking attempts. It just catches most of them. They are still happening, but it would be better to have a belt AND suspenders when it comes to security since we all make mistakes and accidentally misconfigure things. Firewall controls are 1 layer. Which other layers have you decided to use?

IMHO, the 3 most useful are:
* never allow passwords, use ed25519 ssh keys for all internet-based connections.
* move to a non-standard port
* setup fail2fan

My link above covers each of these.

If you add in blocking the world from access and adding a few whitelist subnets, that will drastically reduce your exposure and you won't need to trust fail2ban nearly so much.

And don't forget IPv6. Your client machines on the LAN may be making IPv6 connections that your firewall isn't filtering at all.

[Doug S]

The simple iptables "recent" module method hasn't been mentioned on this thread yet (mentioned it many times on these forums).
Someone attempting to log in gets 3 tries, then they, and any other IP address within 10 least significant bits, are banned for over 1 day, from any port, not just the SSH port.
In recent years, it has been noticed that attackers simply change to another IP address once they get locked out, so I know default to blocking an entire sub-net:

#Arbitrary bit mask for the automatic IP blocking stuff (v2.08)
#
BIT_MASK="255.255.252.0"
...
# Allow any related traffic coming back to the server in.
#
#
$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT
...
# Dynamic Badguy List. Detect and DROP Bad IPs that do password attacks on SSH.
# Once they are on the BADGUY list then DROP all packets from them.
# Sometimes make the lock time very long. Typically to try to get rid of coordinated attacks from China.
$IPTABLES -A INPUT -i $EXTIF -m recent --mask $BIT_MASK --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -m recent --mask $BIT_MASK --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -m recent --mask $BIT_MASK --set --name BADGUY_SSH -j ACCEPT

I also change the sshd_config file, adding this:

< #Smythies.com
< #Limit the number of bad passwords per connection to 2. Default is 6.
< #Then the iptables connection counter will kick in sooner to drop
< #password attack hackers.
< MaxAuthTries 2
<
103,105d88
<
< # Smythies.com allowed users:
< AllowUsers doug

Someone asked about blocking by geo location. In the end I felt I had to block China, Russia and some others, using ipset:

    pkts      bytes target     prot opt in     out     source               destination
  239984 12814127 DROP       all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0            match-set china src
    4444   298983 DROP       all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0            match-set hongkong src
   17394   750936 DROP       all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0            match-set romania src
 1215881 50190401 DROP       all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0            match-set russia src
   20046   854677 DROP       all  --  enp4s0 *       0.0.0.0/0            0.0.0.0/0            match-set ukraine src

Now, truth be known, since I no longer travel for business and since SSH attacks were increasing at an alarming rate, I no longer allow any external SSH access, and have an iptables rule by-passing the above:

# OVERIDES: Secure Shell on port 22. email on port 25
#
# Sometimes I uncomment the next lines to simply disable external access.
# e-mail is too much hassle and I don't travel for business anymore.
# The conttant break-in attempts are a lot to keep up with.
echo disable external ssh access.
$IPTABLES -A INPUT -i $EXTIF -m state --state NEW -p tcp -s $UNIVERSE -d $EXTIP --dport 22 -j DROP
echo disable external email delivery.
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 25 -j DROP

Note: The reason I always left it as port 22, was because I used to study the attackers methods and methodology patterns.

[TheFu]

I suspect there's a typo? IPSEC should be ipset?

I use ipset. Thought it would be overkill for a small office, with a beginner admin, to protect ssh.
What's that saying? "Perfect is the enemy of done."

I use ipset to protect attacks on smtp and http, but not specifically for ssh. My http and smtp servers don't allow ssh except from my specific IPv4 subnet.

[skipbarker]

Mirroring some of the other suggestions.
1. Use Fail2Ban
2. Use RSA key authentication (no passwords)