Best Practices for Setting Up a New Server

In this article you can find a list of things that I immediately try to put into place after installing a new server.

Put automatic security updates on
So you don’t skip any important security updates. If your system is business critical, please leave (general) automatic updates off, as applications tend to rely on each other. It’s best to first test these updates to see if nothing breaks.

Smart partitioning
Everyone needs to decide this for there own but I prefer to put /var/log on a different partition. A (D)DoS attack could generate a lot of logs, which could fill up your hard disk quickly, making your system unresponsive.
Put /tmp also on a separate partition and only mount it with the right permissions, like noexec. Also, like /var/log, /tmp can dynamically expand, which can result in saturation of the whole root partition, if not placed on a separate partition.

Decent SSH configuration
As explained in an earlier post, try to setup your SSH configuration as tight as possible from the beginning. If possible generate some private/public key pair and use it to login remotely.

Central logging
Use syslog, syslog-ng, or ksyslogd to let your applications on your server log to a central logging server. I prefer syslog-ng, as this supports encryption. You can use a log correlator like spunk or log stash to analyze your logs.

System monitoring
Use a monitoring system to monitor your hardware and software, like free disk space, CPU usage, network connection,… . Nagios and Zabbix are two free monitoring systems.

Set up a host based firewall and intrusion detection system
Set up a simple host firewall like ufw. A ridiculously short howto can be found in an earlier post I made, but it will get you started.
As an network-based intrusion detection system you can use Snort or Suricata, but since this post is more focused on systems, you can use a host-based intrusion detection system like OSSEC, which can run as a stand-alone HIDS or in a agent/manager setup. OSSEC can also be a good alternative to collect logs to a central place, as it also provides encryption (by default).

Split management traffic from the publicly available services
Every system you install should be connected to two separate (V)LANs. One for the services they provide, and one for the management of the system (SSH access, LDAP authentication, monitoring, central logging,…). The latter should be some kind of private network. The more services are accessible from the Internet the more risk they get exploited. If the SSH service is not accessible from the Internet, it cannot be exploited.

Get some kind of backup solution in place
And test your disaster recovery procedure!
You can use different tools for this. It depends if you want to backup on tapes, another system or an external hard drive. You can use something relatively easy like rsync or a script. It’s a good practice to use some kind of versioning system to backup /etc for example. You can use svn for that. If a system would crash you can always roll back to your previous configuration.
For bigger environments you could use Bacula.
Don’t forget to do as well incremental as full backups. A good practice could be to perform daily incremental backups and weekly full backups.

Hook up your system to some kind of central authentication system like an AD or LDAP. Kerberos is integrated to AD by default. If possible use two-factor authentication. Google authenticator; is free and easy to implement.Yubi keys are another alternative, not that expensive and easy in use (and small).

If you think about anything else, feel free to contribute.