Locking down port 22 further

Unsupported Modifications
1

I’m currently at my parents and using their BT connection. This is dual stack with a fixed IPv6 /64 and a dynamic IPv4 address.

I recently changed my VPS over to OVH which provides me with an IPv6 as well as an IPv4 address.
This has afforded me a way of limiting the ability to connect to SSH still further than simply using SSH keys.

Before doing this I do recommend making sure that you can use the KVM login at your VPS provider in order to prevent yourself from being completely locked out should things go awry…

Once you’ve done this it’s time to:

  1. Add a rule to UFW to allow SSH connections from my home /64
    sudo ufw add limit from 2a00:23c5:4183:eb00::/64 to any port 22 proto tcp
  2. Delete the rules to allow SSH connections from all IPv6 and IPv4 addresses

Currently these are my UFW firewall rules:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
53                         ALLOW       Anywhere
25/tcp                     ALLOW       Anywhere
587/tcp                    ALLOW       Anywhere
993/tcp                    ALLOW       Anywhere
995/tcp                    ALLOW       Anywhere
4190/tcp                   ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
465/tcp                    ALLOW       Anywhere
53 (v6)                    ALLOW       Anywhere (v6)
25/tcp (v6)                ALLOW       Anywhere (v6)
587/tcp (v6)               ALLOW       Anywhere (v6)
993/tcp (v6)               ALLOW       Anywhere (v6)
995/tcp (v6)               ALLOW       Anywhere (v6)
4190/tcp (v6)              ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)
465/tcp (v6)               ALLOW       Anywhere (v6)
22/tcp                     LIMIT       2a00:23c5:4183:eb00::/64

I did consider adding a rule for IPv4 but unlike Virgin Media cable IPv4 addresses which are sticky for months or years at a time, BT IPv4 addresses change at unspecified intervals, even when the router is not rebooted.

2

What if your ipv6 changes? You will be locked out of the machine?

3

The /64 is tied to the BT account and remains constant. I have windows set up to use privacy addresses, so the actual IP address does change periodically, but will always be within the same /64.

However OVH and 1&1Ionos both allow you to log in to the machine from a KVM terminal from your VPS control panel, I can’t speak for other VPS providers, but I imagine that they’d have something similar.

4

Why not simply change from the default port 22 to an obscure port?

Many will argue that security by obscurity is ineffective on its own, and I agree – but it certainly cuts down on the unwanted login attempts. If someone really wanted to target YOU they would simply do a port scan – but the numpty’s who are just looking for low lying fruit are not going to bother.

5

To be honest - Doing this cuts down on unwanted SSH logins just as well. Anyone trying to do a port scan from outside the allowed IP addresses won’t see port 22 at all

For example here’s what nMap sees over IPv4

Discovered open port 53/tcp on 51.195.149.130
Discovered open port 25/tcp on 51.195.149.130
Discovered open port 80/tcp on 51.195.149.130
Discovered open port 995/tcp on 51.195.149.130
Discovered open port 993/tcp on 51.195.149.130
Discovered open port 443/tcp on 51.195.149.130
Discovered open port 587/tcp on 51.195.149.130
Discovered open port 465/tcp on 51.195.149.130

To anyone who’s not on my home network they also see the same when scanning the servers IPv6 address.

Just because the server is sitting on a public facing IP address, it doesn’t mean that all my services have to be visible to everyone.

6

but is having folks try logging in actually a problem (drain on resources?)

I suppose you have ssh all bolted down with all the security best practices so whats the problem?

(or alternate way of looking at this; if you restrict to the /64 tied to your home internet; would you dare to make ssh login unauthenticated!)

7

For what it’s worth, I did this for a while but once Shodan indexes your box again the automated attempts start right back up. It’s actually interesting to watch. For a while, you drop to literally 0 on fail2ban, only for it to creep back up to the norm after a week or so.

8

No you wouldn’t. But where practicable, it’s best to take a layered approach to security. Limiting access to SSH by network IP is one layer. Authenticated access is another IMHO.

Tim