@lmhopfe

Port Scanning is going to happen when you’re dealing with public facing servers, regardless of their utility (i.e. web server, database server, etc). As long as you’re running a firewall that will block those exceeding a threshold limit, you should be fine.

As for the SSH Port, from a security standpoint, changing the port number is security by obscurity and not a highly regarded practice since it only functions as a very small deterrent. At the same time, even though many people look down upon it, I always change the default SSH port and block all attempts to connect on 22 (TCP & UDP). It’s the default port, it’s well-known, and it’s the first SSH port that will be tried. If you can stop an IP on the first attempt, you won’t need to stop the same IP from trying to connect again.

That said, most attacks aren’t going to be from a single IP, so you’re going to be blocking numerous IP’s that attempt to connect on that port, but that’s simply the nature of running a web server.

Filter out the bad and filter in the good – either way, you filter the traffic. On the backend, a firewall functions as one defense mechanism, as long as your rules are setup correctly. For example, you should have your deny all rule before your allow .... rules. With ufw, that’s as simple as:

ufw disable \
&& ufw default deny \
&& ufw allow 80/tcp \
&& ufw allow 443/tcp \
&& ufw allow 53/tcp \
&& ufw allow 53/udp \
&& ufw allow SSHPORT/tcp

… SSHPORT should be replaced with your actual SSH port, of course :-). If you’re not sure if you set your deny rule before the others, you can simply run:

ufw reset

… to reset ufw and then run the multi-command above which will allow traffic on 80 (HTTP), 443 (HTTPS), 53 (DNS) and SSHPORT which is your chosen SSH port.

Once your rules are in place:

ufw enable

And the firewall is active once again.

Yes. I would move SSH back to port 22. There’s no real useful reason to change it.