Martin Ansdell-Smith

mas server resources

Return to commonly accessed sites

Back to top of page

Server security

This page states some of my own approaches to server security. Use it thoughtfully and at your own risk.

Opening an unprotected server to Internet traffic is not going to end well for the server. Effectively securing or hardening a server is beyond the capability of most sysadmins but there are some basic steps that can be taken that may divert attacks away to easier targets or, at least, make the attack surface smaller.

Good coding and user practice underpin all the steps listed here. Users sharing passwords or emailing security credentials will undercut much of the good work.

So, the starting point is only to install what is needed. A minimal installation will have fewer vulnerabilities and fewer patches to apply day by day. What has to be installed must then be secured. Securing the server starts with the physical server and its environment.

Security does not begin, or end, with preventing access to bad actors. Basic InfoSec categories are

Ideally we want to achieve all four. This requires considering a wider range of risks and mitigations.

The extent of security concerns will differ if lives are at stake than if the server is for small-scale tests. Even for the latter, though, we do not want the server being used as part of a botnet or to give access to other parts of our network.

Effective encryption in motion is clearly necessary but this needs to be extended to system software and configuration. Availability, though, may limit the class and strength of encryption. Some target users may not have the latest browsers or sufficiently powerful machines to support cutting edge data security protocols. Nonetheless there will be a minimum baseline.

Multiple blocks in the way of attacks are essential. There will be times when one or more of the obstacles fail for reasons outside our direct control. It could be zero-day flaw in a key piece of software, or perhaps a failure of or change in firewall configuration that opens a previously closed port. Where possible, the system must have resilience against a single failure: especially against a failure in our assumptions of security provided by someone else.

Physical security

The server must be physically secure, probably with cages, locks, biometric controls and access logs. The service may warrant redundant power, networking and cooling, though these may affect the running costs. Server hardware and BIOS can introduce risks but may be beyond the sysadmin's control. For a bare metal server then management of options such as boot from CD or USB or installation of a USB wireless dongle need to be controllable. If, as will often be the case, it is a virtual server in a remote data center, then trust in the supplier and the virtualisation software need to be considered.

Server software level

The server should have supported software and be at a current patch state. Ideally for a cloud server it is a GNU/Linux 64-bit minimal install with ssh enabled for initial access using a key not a password and with no other network accessible services running. The rest of this page assumes that this will imply running systemd.

Before accessing the server for the first time ensure that emergency console access is available, usually via the cloud server provider's website. Access to that website must be protected by a strong password and, if available, two-factor authentication.


When first accessing the server, which should be via ssh using a key, the first tasks are to minimise the attack surface. Shut down and disable all unnecessary services and their associated ports at all runlevels. Ensure a server firewall is running and blocks all inbound ports on both IPv4 and IPv6 except those needed for the correct operation of the server. Disable ssh access using a password by setting PasswordAuthentication no in /etc/ssh/sshd_config. Set up a non-root user that has sudo privilege and, for some setups, may be in the wheel group. This user should also have the appropriate public ssh keys set up in .ssh/authorized_keys. Before logging out from the existing root session, ssh to the server as the new user and ensure that log in and sudo access are available. Then block root login via ssh by setting PermitRootLogin no in /etc/ssh/sshd_config.

This is also the time to regenerate the key used for ssh if there are any doubts about its integrity or strength. It should also have a strong passphrase to reduce the impact of key compromise.

ssh is a necessary safeguard for all Internet-accessible servers.


The firewall on the server is then configured, started and enabled to run at all subsequent reboots. It should prevent all unwanted inbound network accesses to the server. Most distributions have a firewall manager. This usually manages iptables for you but you can do this for yourself on most servers. As part of firewall setup consideration should be given to an ipset blacklist to block specified IP address ranges where this is appropriate.

Open ports and running services

ps, netstat and lsof are useful tools to help with finding unnecessary services and open ports. This will likely identify a handful of services such as avahi that are often enabled by default but which may not be needed in your configuration. For example,

$ netstat -nlut Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0* LISTEN tcp 0 0* LISTEN tcp 0 0* LISTEN tcp 0 0* LISTEN tcp 0 0* LISTEN tcp 0 0* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:25 :::* LISTEN tcp6 0 0 ::1:953 :::* LISTEN tcp6 0 0 :::443 :::* LISTEN udp 0 0* udp 0 0*

This example, this identifies UDP ports 39141 and 5353 as world-accessible using IPv4 unless the firewall prevents this. These could not be accounted for by services needed on the server. 5353 is mDNS and, with 39141 are both used by avahi. avahi was not required by this server and could be stopped by

systemctl disable avahi-daemon.socket avahi-daemon.service

This step may need to be repeated if avahi is upgraded on the server. Generally avahi cannot be uninstalled because of dependencies.

Other initial steps

There are then a series of setup steps to complete, if not yet done, such as

Once these steps are completed, reload the server and test them. Then take a backup. Only then go on to installing the software needed for the live services. After the software is installed and initial configuration completed, then the ports for the software can be opened.

User and data security

Only users who need remote access should have remote login available. Remote access should use ssh with a key. AllowUsers and AllowGroups in /etc/ssh/sshd_config can control this. Users that will be accessed with through sudo need a strong password as another line of defence.

Just as remote logins should only be over ssh, data movements should be over encrypted channels. So avoid ftp, tftp, telnet, rsh, rcp and http. Use protocols such as sftp, scp and https. Check the current recommendations for ciphers that should be enabled or disabled.

Keep logs and use them

In addition to actions before an attack there should be monitoring for attacks and for the results of penetrations. Appropriate logs need to be kept and checked, preferably automatically. A remote log server may protect evidence of server penetration. Rootkit detectors are an example of the latter. Fail2ban is also worth consideration to slow down an attacker, to reduce the load on a server of an attempted attack and to provide logging specific to attacks.

Back to top of page

References and Further Information

Many of these points and more are considered in detail in Greg Bledsoe’s article Server Hardening in a Linux Journal article dated .

Advice on the first ten minutes on an Ubuntu server on the Codelitt Incubator Blog on .

Most providers will have guidance on their website for securing servers and services. For example, Digital Ocean [Affiliate and discount link] has many tutorials including, for initial CentOS 7 setup:


Back to top of page