mas server resources
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.
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.
- ssh-audit python script to give recommendations for best SSH key, cipher and MAC choices.
- ssh security considerations in a blog posting by Aris from . It rates ease of implementation and security benefits for the measures proposed.
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
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 127.0.0.1:9000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:953 0.0.0.0:*
LISTEN tcp 0 0 0.0.0.0:443 0.0.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 0.0.0.0:39141 0.0.0.0:* udp
0 0 0.0.0.0:5353 0.0.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 stepsThere are then a series of setup steps to complete, if not yet done, such as
- Set the hostname and FQDN
- Edit /etc/hosts for localhost and the hostname for both IPv4 and IPv6
- Set up A and AAAA DNS records for the host
- Complete initial updates (e.g. yum update). This may also need a kernel update on reload using the method setup by the hosting company
- Configure timezone
- Configure NTP synchronization, including setting the hardware clock. At the of writing it is best, for security, to avoid using IPv6 time servers from a pool
- Create a Swap File
- Install bind server, if desired
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.
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:
- How To Connect To Your Droplet with SSH
- Initial server setup with CentOS 7
- Additional recommended steps for new CentOS 7 servers>
- systemd for (impatient) sysadmins, a primer by Tyler Langlois includes parameter over-rides, timers, and path units.