Hi all.
When I was setting up my server while back I have noticed 100’s of entries in my:
/var/log/auth.log
about failed log in attempts from various IP’s with various logins. I wondered what it was until I saw this:
https://www.youtube.com/watch?v=7CP-JB4QARo
Conclusions? There is at least one (wishful thinking…) bot out there which will scan the entire range of IP’s for opened port 22 and will use some brute-force tool trying to crack it. Now that’s not a very positive conclusion for all the SSH users…
What can be done about this? There are several thing You can do.
A) Forbid the root’s log in.
B) Install and configure fail2ban.
C) Change the SSH port from 22 to something above the 10100
D) Limit users so that they can log only from a selected IP (or IP range).
E) Use stronger encryption.
F) Disable password authentication and use authentication keys instead.
I use all of them.
A) Forbidding the root’s log in is a must. Root is the only 100% sure login on every Linux based system. Attacker don’t have to guess it. It’s there for sure. Now all he has to do is to guess the password. Blocking root’s login will make him to guess Your user login and password. This is more difficult for them and that’s the whole point.
To do this You need to do two things. Add the word root to the /etc/ssh/denyusers file:
su -c "echo 'root' > /etc/ssh/denyusers"
un# and change the value of PermitRootLogin from yes to no in the /etc/ssh/sshd_config file:
su -c "sed -i 's/#PermitRootLogin yes/PermitRootLogin no/i' /etc/ssh/sshd_config"
and then restart the sshd daemon.
systemctl restart sshd
Those settings will block all the attempts of root log in to Your SSH server and yet will allow You to use su command for Your convenience. Why? Even if attacker knows root password he will not be able to log in. However user who is logged into the system via SSH can raise his / her privileges using su command. This is far more secure and comfortable in the same time. Sometimes root’s privileges are necessary so its important to be able to gain root and yet You have to log in as user and know the root’s password to gain full control over the machine.
B) Another method – Fail2ban – (You will find it in the repositories) will add a firewall rules to block all the attempts of connecting to the SSH port for a machine that unsuccessfully tried to log in X amount of times in Y time period. Example – xxx.yyy.zzz.uuu machine tried to log in with logins jack, ann, mark 3 times in 20 minutes period so it got banned for an hour.
In this Arch Linux wiki article You will find out how to configure fail2ban with shorewall firewall.
Fail2ban configuration file can be found here:
/etc/fail2ban/jail.conf
and if You have local e-mail server configured it can be set so that fail2ban will send You a message with notifications about new events.
Fail2ban will protect not only SSH but also FTP, SFTP, and other protocols that are using authentication. Very very cool tool indeed.
Here are my .conf files for shorewall and fail2ban edited to work well together, protect sshd and keep you informed via e-mail.
C) Another thing that You can do is to change the port of the SSH server to something above 10100 – I will use 20202 as an example. Here is how its done.
su -c "sed -i 's/#Port 22/Port 20202/i' /etc/ssh/sshd_config"
Don’t forget the modify the firewall rule to open tcp port 20202 instead of default port 22.
You need to restart sshd for this change to take place:
systemctl restart sshd
From now on You will need to add -p 20202 to Your ssh command. Example:
ssh -p 20202 -l mylogin remotemachine.net
Why changing the port and why above 10100? Default port for SSH is 22. All the script kiddies aka skiddies will use that port in their bots. Even if script kiddie is smart and will scan Your IP with port scanner like nmap – by default he will scan first 10000 ports only. Setting up SSH above that will cause the port scanner to find ZIP, ZERO, NADA, BIG BOBKAS. Even if skiddy is smarter then that and he will scan all the 65k ports the open port will be shown as unknown service. He would have to add few more switches to the nmap to find out that its a SSH server. Skiddies are mostly lazy and they are going after the easy prey. Making it just that little bit more difficult can be a blessing for Your security.
D) Limiting users to be able to log in from a certain IP or IP range will improve the security of Your SSH server too. Let’s say one of Your users has a static IP and will always only use this machine to log into Your server – if someone finds out what his password is and will try to log in from a different IP the attempt will fail…
To achieve this You need to add AllowUsers directive as a last line in Your /etc/ssh/sshd_config file.
Here is an example:
AllowUsers johnnyb brandon anthony@73.12.134.14 robin@192.168.0.100 luke@64.*.*.*
In this case users johnnyb and brandon can log in from ANY IP, anthony can only log in from the IP 73.12.134.14, robin can only use local network IP 192.168.0.100 and luke is allowed to log in from the IP range starting with 64.
As always – restart sshd service for this to take effect.
systemctl restart sshd
E) To make the SSH server even more secure I would recommend enforcing strong crypto. By doing this You are forcing the clients to only use the very strong and secure cipher.
Add this line somewhere in the /etc/ssh/sshd_config:
Ciphers aes256-ctr
and restart the SSH server.
systemctl restart sshd
F) As I have wrote here in the post about passwordless SSH authentication using password as a authentication method is not all that secure. You can disable the possibility of authenticating with a password in the /etc/ssh/sshd_config file.
First what You need to do is create the set of keys and make sure that You have a working authentication with the public and private key.
Next You need to un# the PasswordAuthentication directive and change its value from yes to no:
su -c "sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/i' /etc/ssh/sshd_config"
and of course restart the SSH server:
systemctl restart sshd
Thanks for reading. This is all for now. Possibly I will edit this post to add more stuff.
Cheers.
Andrzej
