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 root.
  • 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 -y flags so you can approve each package update as it comes.

Once those are finished, reboot! (sudo 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: (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 fail2ban:

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:

emacs /etc/fail2ban/jail.d/jail-debian.local

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:

# add multiple ip's separated by spaces
ignoreip  = 
bantime	  = 	3600
destemail =
banaction =	iptables-multiport
action	  =	%(action_mwl)s

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.