Service audit
A large part of security consists of analyzing our systems, understanding the available attack surfaces and locking down the components as much as possible.
A service audit is a way of knowing which services are running on a given system, which ports they use for communication and which protocols are accepted. This information can help you configure the services that must be publicly accessible, the firewall settings, and monitoring and alerting.
How does auditing services improve security?
Servers can run processes for internal purposes and to serve external clients. Every running service, whether it is intended to be internal or public, represents an extended attack surface for malicious users. The more services you run, the greater the risk of a vulnerability affecting your software.
Once you have a good idea of the network services running on your machine, you can start analyzing those services. When you carry out a service audit, ask yourself the following questions about each running service:
- Does this service need to be running?
- Is the service running on network interfaces on which it should not be running?
- Should the service be bound to a public or a private network interface?
- Are my firewall rules structured to pass legitimate traffic to this service?
- Are my firewall rules blocking traffic that is not legitimate?
- Do I have a method for receiving security alerts about vulnerabilities for each of these services?
This type of service audit should be standard practice when setting up a new server in your infrastructure. Carrying out service audits every few months will also help you detect any services whose configurations may have been changed unintentionally.
How to carry out service audits
To audit the network services running on your system, use the command that lists all the TCP and UDP ports in use on a server. An example command that shows the program name, the PID and the addresses used to listen for TCP and UDP traffic is:
- sudo ss -plunt
You will receive output similar to this:
The main columns that require your attention are the Netid, Local Address: Port and Process name columns. If the local address: port is 0.0.0.0, the service accepts connections on all IPv4 network interfaces. If the address is [::], the service accepts connections on all IPv6 interfaces. In the example output above, SSH and Nginx are both listening on all public interfaces, on the IPv4 and IPv6 network stacks.
With this example output, you can decide whether you want to allow SSH and Nginx to listen on both interfaces, or only on one or the other. As a general rule, you should disable the services that run on unused interfaces. For example, if your site only needs to be accessible over IPv4, you would explicitly prevent a service from listening on the IPv6 interfaces in order to reduce the number of exposed services.
Unattended updates
Keeping your servers up to date with patches is essential in order to guarantee a good baseline level of security. Outdated servers and insecure versions of software are responsible for the majority of compromises, but regular updates can mitigate vulnerabilities and prevent attackers from gaining a foothold on your servers.
Traditional updates require an administrator to check and install the updates of the various packages on their server manually; this can take a lot of time and it is possible to forget or miss a major update. Unattended updates, by contrast, allow the system to update a majority of packages automatically.
How do unattended updates improve security?
Implementing unattended updates reduces the level of effort required to keep your servers secure and shortens the period during which your servers may be vulnerable to known bugs. In the event of a vulnerability affecting the software on your servers, your servers will be vulnerable for as long as it takes you to run the updates. Daily unattended upgrades will ensure that you do not miss any package and that any vulnerable software is patched as soon as fixes are available.
Together with the service audit mentioned earlier, running updates automatically can considerably reduce your exposure to attacks and reduce the time spent maintaining the security of your server.
How to implement unattended updates
most server distributions now offer unattended updates as an option. For example, on Ubuntu, an administrator can run:
sudo apt install unattended-upgradesNote: These mechanisms will only automatically update the software installed through your system's package manager. Make sure that any additional software you run, such as web applications, is either configured for automatic updates or checked manually on a regular basis.
Disable directory indexes
Most web servers are configured by default to display directory indexes when a user accesses a directory that has no index file. For example, if you were to create a directory called download s on your web server without any additional configuration, all the files would be visible to anyone browsing the directory. In many cases this is not a security problem, but it is quite possible that something confidential would be exposed. For example, if you were to create an index directory on your web server for your website, the directory might contain the home page file of your website and a configuration file containing the credentials of the website's main database. Without disabling directory indexes, both files in the folder would be visible to anyone browsing the directory.
How does disabling directory indexes improve security?
Directory indexes serve legitimate purposes, but they often unintentionally expose files to visitors. Disabling directory indexes by default for your web server removes the risk of accidental data loss, leakage or exploitation by making the directory files invisible to visitors. Visitors can still access the files if they exist in the directory, but disabling indexing makes the files much harder to discover unintentionally.
In most cases, disabling directory indexes consists of adding a line to the configuration of your web server.
- Nginx disables directory indexes by default, so if you use Nginx, you should not need to make any changes.
- The pageDirectoryListings on the Apache wiki explains how to disable directory listings. Make sure to use Options -Indexes.
Back up frequently
Although they are not strictly a security measure, backups can be crucial for saving compromised systems and data, and for analyzing how the system was compromised. For example, if your server is compromised by ransomware (a malicious tool or virus that encrypts files and only decrypts them if the attacker receives a sum of money), a lack of backups may mean that your only choice is to pay in order to get your data back. If your systems and data are backed up regularly and securely, you will be able to access and recover your data without interacting with the compromised system.
How do frequent backups improve security?
Frequent backups make it possible to recover data in the event of accidental deletion and in the event of an attack in which your data is deleted or corrupted. In both cases, they help mitigate the risk of data loss by keeping copies of the data from before an accidental deletion or from before an attack took place.
In addition to ransomware cases, regular backups can help with the forensic analysis of long-term attacks. If you do not have a history of your data, it can be difficult, or even impossible, to determine when an attack began and which data was compromised.
How to implement frequent backups
When implementing backups for your systems, consider the recovery of compromised or deleted data as the objective. Ask yourself the question: if my server disappears tomorrow, what steps must be taken to get it back up and running securely with as little work as possible?
Here are some other questions to consider when drawing up a disaster recovery plan:
- Should the most recent backup always be used? Depending on how often your data changes and on when a compromise or a deletion occurs, this may reduce the risk of falling back by default to an older backup.
- What is the actual process for restoring the backup?
- Do you need to create a new server or restore the existing server?
- How long can you survive without this server in operation?
- Do you need off-site backups?