Securing Your Server


In a previous article, we went through the steps of setting up a LAMP server, and a PrestaShop e-commerce solution.  The next step here is to lock down our server and secure it.

Security isn’t just important for keeping your services and web pages running, it is also crucial to protect sensitive data.  Some servers have data ranging from personal names, passwords, email addresses, essential login credentials, credit card numbers, banking credentials and information, addresses, and social security numbers.  It is crucial to maintain security no matter what data and how small is on your system.  Even protecting your uptime and services can be crucial as downtime cost money for any business.


In our previous articles, we left off with server install and setup.  The next thing to do is to secure our SSH login.  To do this, we open up the config file as follows…

sudo nano /etc/ssh/sshd_config

Make the following changes….

  • change the default port number.  The default port 22 on a public server is easily recodnizable as remote login by brute force attackers.
  • secondly, disable root login. (PermitRootLogin no)
  • Now, set (X11Forwarding no)
  • Now, we can either set “AllowUsers username1 username2” if your list is small, or as an alternative for systems with many / multiple remote connected users, “AllowGroups remoteConnection”.
  • You can create the group with the following command…

groupadd remoteConnection

  • Add an users to remoteConnection group with the following command…

sudo usermod -a -G remoteConnection user1

The next step is our firewall.  By default, TTOS Linux uses iptables + ufw.  If you are using another debian or ubuntu based operating system, you can install this with the following command…

sudo apt-get install iptables ufw

After this is installed, we need to set up some rules.  First, we need to edit the openssh config file and change the port to the new port that we assigned when configuring ssh.  The command to open the file in our editor is the following…

sudo nano /etc/ufw/applications.d/openssh-server

From here, we simply change the port and save the file.

The next step is to add some rules.

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw allow ssh

sudo ufw allow 80/tcp

If your server does not connect to ssh with this rule, this means that the config file in the applications.d folder was not properly set up.  In this case, you can simply manually add the port rule.  And this method works with any application if you know the ports.  Use the following command and change port 22 to the port number needed…

sudo ufw allow 22/tcp

If you wanted to ban a specific IP from connecting, you can do it like this…

sudo ufw deny

To view ports used, disable firewall with…

sudo ufw disable

Run all programs and services requiring network access. Then type the following…

sudo netstat -tulpn > ~/netstat.txt

Enable firewall with…

sudo ufw enable

Now, open netstat.txt with nano, and write down all ports of programs that aren’t working.  Then simply enable the port with tcp or udp as shown previously.

Next step is to set up a simple but very effective Host Intrusion Detection System and Host Intrusion Prevention System.  There are many to choose from, and you can run multiples types.  My favorite is one in server use would have to be fail2ban.  fail2ban works by monitoring log files in real time for filtered events.  For example, the usage we will be setting up here is monitoring the auth.log for failed login attempts.  When a few consecutive login attempts are made within a specified time, the IP address is jailed for a set amount of time.  You can set the jail to infinite but this causes issues when someone legitimately forgot their login credentials and locked themselves out.  Another reason is that many publicly used IP addresses are dynamic and constantly reassigned.  So, if you ban an IP, the next person to get the IP won’t be able to access your website or web services until their IP is refreshed with one not blacklisted.  I personally prefer periodic checking of the logs and you can manually perma ban repeat offenders.  Tripwire is another favorite, but you can setup other IDS’s on the system with fail2ban as you wish.

First off, lets install it with the following command…

sudo apt-get install fail2ban

By default, fail2ban interacts directly with iptables.  We previously set up ufw, so we are going to edit fail2ban to interact directly with ufw instead.  We open the config file as follows…

sudo nano /etc/fail2ban/jail.conf

Now, look for the ssh jail and edit it to the following….


enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
action = ufw-ssh
bantime = 600

The next thing to do is to create the ban action for ufw-ssh.

sudo nano /etc/fail2ban/action.d/ufw-ssh.conf

Next is to fill it with valid rule set to use ufw instead of iptables.  Paste the following into the file and save it…

actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from <ip> to any app OpenSSH
actionunban = ufw delete deny from <ip> to any app OpenSSH

Normally, we would restart individual services with sudo service servicename reload or sudo service servicename restart, however since we changed a few services and we want to make sure everything is still configured after boot up, we want to reboot the system and make sure all changes are in effect.  We do this with the following command…

sudo init 6

Now, we can wait and check status.  It was only minutes from server uptime that i recieved my first 3 bans.  You can check status of ban and firewall rules with the following commands…

sudo ufw status

sudo fail2ban-client status

sudo fail2ban-client status ssh

if “sudo fail2ban-client status” does not list ssh as a currently running jail, you can add it with the following command…

sudo nano /etc/fail2ban/jail.local

Under the SSH jail section, set

enabled = true

Now we need to restart fail2ban.  Personally, on TTOS Linux, I have issues with just fail2ban restarting and reloading, so I use the following two commands to reload the configuration…

sudo service fail2ban stop

sudo service fail2ban start

Now we can check the status again and ensure that the ssh jail is enabled.  And when you see a jailed IP listed in the fail2ban status for ssh, you should see a rule added to ufw for the same IP.  This means it is blocking repeated failed login attempts effectively rendering brute force attacks useless!




  • UFW leaves too much to be desired in terms of total control. IPTables ain’t all that bad, the syntax is actually fairly simple.

    • I use IP tables in my production systems, however I find it easier to teach with UFW. UFW simplifies the syntax to more “human readable” and nothing more. This means that UFW is just an user interface to IPTables and does not extend any functionality. The overhead to the system is very minimal therefore it has no effect on any server hardware from the last two decades. Just like any other system, saving resources and overhead means faster boot up recovery times, and that your system can handle that much more load before resources are maxed out and every little kb of RAM, and every CPU thread will eventually add up. I hope you enjoyed the tutorial, more will be coming in the next two weeks.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.