Linux server security is always a good topic of discussion that everyone seems to have a different opinion about. I have recently been building a number of new production servers which are all running Debian 9, and here are some of the steps that I have taken to make sure they are secure.
- These instructions are specifically for Debian 9, but they should work the same for Ubuntu or other Debian-derivatives.
The largest piece of this puzzle is an application named Fail2Ban which essentially monitors configured services for repeated exploit attempts (brute-force login, etc.) in order to block that source address. This took is both powerful and scary. If you mis-configure this app, you WILL lose access to your server.
There are a few other steps that I take to set servers up along with Fail2Ban, so strap-in and let’s get started…
- A fresh Debian 9 (Stretch) x64 server instance. (I use DigitalOcean)
- Logged in as
- All unused ports have been blocked with proper IPTables rules.
Update, Update, UPDATE!
This is probably the easiest one to do that a lot of people fail to do, but make sure you do this right out of the gate:
sudo apt update sudo apt dist-upgrade -y
- The above command can also be used regularly to maintain the updates regularly, though you may want to remove the
-yflags so you can approve each package update as it comes.
Once those are finished, reboot! (
Change the SSH Port
SSH exploits are probably one of the most basic attack points for a server, largely because the port for the service is usually standardized on port
22. A very simple way to slow these attacks down is to simply change the port.
When selecting a port, try to use something non-standard, and something that is not used for another service. You can check to see if any other ports are used by checking this site: https://www.speedguide.net/port.php?port=37623 (change the port number at the end of the URL to whichever one you want to check).
sudo sed -i "s/#Port 22/Port 37623/g" /etc/ssh/sshd_config sudo systemctl restart sshd.service
- Note: this change won’t actually take effect until you disconnect/reconnect.
Now you need to update your IPTables config to adapt to the new port:
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j DROP sudo iptables -A INPUT -p tcp --dport 37623 -j ACCEPT
Last part of this step is to configure IPTables rule persistence:
iptables-save > /etc/iptables.up.rules touch /etc/network/if-pre-up.d/iptables chmod +x /etc/network/if-pre-up.d/iptables echo '#!/bin/sh' >> /etc/network/if-pre-up.d/iptables echo '/sbin/iptables-restore < /etc/iptables.up.rules' >> /etc/network/if-pre-up.d/iptables
This will create a script at
/etc/network/if-pre-up.d/iptables to re-add those rules to IPTables after reboots. Be sure to update this script in the event you tweak any other rules.
Log out and back into the server using the new port number. For tips on making a shortcut with an SSH Config file (Click Here)
Install and Configure Fail2Ban to protect SSH
Use the standard method to install the stable version of
apt install fail2ban -y
Once installed, check the status to confirmed it is started:
service fail2ban status
Since fail2ban’s application files and default config’s may change when updated, you should make all of your edits to the local config versions:
I usually toss the majority of the contents of that file and replace it with the following, however the following code assumes that this server is a webserver running apache and some other functional apps. Feel free to remove any sections that doesn’t apply to your environment:
[DEFAULT] # add multiple ip's separated by spaces ignoreip = 127.0.0.1 bantime = 3600 destemail = firstname.lastname@example.org banaction = iptables-multiport action = %(action_mwl)s # JAILS [sshd] port = 37623 enabled = true maxretry = 3
Be sure to change your port number from above in the
[sshd]section. The rest of this can be ran with these defaults.
To complete the setup, type the following:
service fail2ban restart
As long as there are no errors, then you are all set. Any user who repeated bashes to the machine with wrong SSH passwords will automatically get banned for 3600 seconds.
To expand on this function more, I will be adding more articles including how to protect other services with
fail2ban like Apache or PostFix along with how to perma-ban repeated brute-force users.