Published on: April 12, 2019 by Nidhin George
Scenario:
Do we need security through obscurity? My answer would be ‘yes‘, we need security through obscurity as well. Well changing the ssh port from the default 22 to a non-default one is desired and is recommended by me. But do not simply rely on this method though for SSH security.
On a publicly accessible server with default port as 22, you will see thousands of failed login attempts of which 99.9% would be brute force attempts to login as root or using common usernames known. At the same time, if you change the default port to a random one like 22289, then there will be less login failures. This is because, there are many bots out there which exploit scans against IP addresses who have been found to be running a specific service, in this case SSH. It could be scans or actual login attempts. There are firewalls like csf/lfd, bfw, fail2ban etc available which can help block the IP addresses which tries to brute force the service though. Also you can have rate-limiting rules written to block the IPs which exceeds a given rate of connections to port 22.
Also certain bugs like heartbleed, allows for attacking and gaining access to your server just by connecting to an open ssh port. By using non-standard ssh port, we can avoid this. But again, patching the sshd is the best solution than keeping on running your server on non-default ssh port. You may also think of port-knocking where in, anyone who want to ssh to the server should knock a port other than the SSH port, to get themselves login to the server. Depending on how you write a port-knocking rule, you can tell the system to REJECT or DROP a direct ssh connection attempt to SSH port.
Don’t exit from the current session, unless you login to the SSH using the new ssh port.
Consider you are running the SSH port on 22289 and unfortunately ssh service got crashed. Since the default ssh port is changed to something else which is above the privileged port number of 1024, a normal user can run a fake sshd service on port 22289 and gather the password of all the users trying to login.
How would you stop this? Well ssh host keys and known_hosts file would alert you, but normal users wont bother. Even though, a sysadmin should detect whether a normal user is running the daemons, I am wondering whether it is possible to add non-privileged port to the list of privileged ports of <1024. Well I don’t know.
Here is a list of things you can do to make sure that the SSH is relatively secure.
Change your SSH port to non-default one
Allow only password less authentication
If possible modify your PAM to have the 2FA setup.
Enable port-knocking for SSH
Enable rate-limiting for the service
Don’t allow direct root logins even through password-less authentication
Disable empty passwords and configure idle timeout interval
If possible allow only certain users and IPs to access the SSH service
Make sure that port-scanning is taken care of using any of the third party tools.
Don’t disable SELinux, unless you are testing or doing a PoC or you don’t have time to fix the broken applications and binaries
Category : Security, server
Nidhin has started his career as a Linux System Administrator since 2013 and holds vast experience in server administration, CMS management and cPanel systems. Apart from this he's a movie buff and have a huge collection of movies.
Add new commentSIGN IN