Securing nginx configurations: implementing OCSP stapling

Securing nginx configurations

Implementing OCSP stapling in nginx

OCSP stapling is a logical follow-up on Online Certificate Status Protocol. OCSP itselfs just checks if certificate is still valid by determining if it is on a revocation list.

The original OCSP protocol forces the client to check for the status of a certificate. This results in a lot of traffic for the CA behind the certificate.

OCSP stapling moves the check to the owner of the certificate. On a regular basis the Nginx server will perform the check, receiving a new OCSP response. This response is stapled upon the SSL/TLS process with the user client. Due to this addition, OCSP stapling ensures the client that the owner is keeping their certificate up-to-date and is still valid.


All these snippets needs to be added below the virtual host. OCSP stapling is only useful when using SSL and is enabled (ssl on or listen <port> ssl).

Enable OCSP stapling and verification

# Turn on stapling

ssl_stapling on;


# Enable verification
ssl_stapling_verify on;


Define certificate for OCSP stapling

Next is defining a certificate. This step is optional when the full certificate chain was already provided with the ssl_certificate statement. In case just the certificate is being used (not the parts of your CA), then this statement is needed:

# Define chained certificate (optional if already defined with ssl_certificate).
ssl_trusted_certificate /etc/nginx/ssl/rootCA_plus_intermediates_chained.crt;

Define nginx resolving

To ensure proper resolving used when querying the verification systems, define what resolvers and their cache time. We use a low timeout, to quickly move to the next resolver if the first one fails.

# Define resolvers, with a cache time of 10 minutes.


# Next define timeout for resolving, to limit timeout length.
resolver valid=10m;
resolver_timeout 5s;


You need at least nginx 1.3.7 for OCSP stapling to work.

Run nginx -t to test your configuration, before reloading.


5 Basic Principles of Linux System Security

5 Basic Principles of Linux System Security

It is still common that people do not know where to start when it comes to information security. With 5 basic principles we can improve the Linux system security and question ourselves if we have done enough.


1. Know your system(s)

The first principle is about knowing what your system is supposed to do. What is its primary role, what software packages does it need and who needs access?

By knowing the role of the system you can better defend it against known and unknown threats.


Security Measures:


  • Password policy
  • Proper software patch management
  • Configuration management
  • Documentation


2. Least Amount of Privilege

Each process running, or package installed, might become a target. Security professionals call this the “attack surface”. What you want is to minimize this attack surface by removing unneeded components, limit access and by default use a “deny unless” strategy. This latter means that access by default is blocked, unless you allow it (whitelisting).

Security Measures:


  • Use minimal/basic installation
  • Only allow access to people who really need it

3. Perform Defense in Depth

Protect the system by applying several layers of security. This principle is named “defense in depth” and can be compared with an onion: to get to the core, you have to peel of layer by layer. One broken defense might help us protect against full compromise.

Security Measures:


  • IPtables / Nftables
  • Hardening of software components

4. Protection is Key, Detection is a Must

Security focuses on the protection of assets. While this is a primary objective, we should consider that one day our defenses are broken. Therefore we want to know this as soon as possible, so we can properly act. This is where principle 3 and 4 both are linked. Set-up proper detection methods, similar to the trip wires used by the military.

Security Measures:


  • Linux audit framework
  • Remote Logging
  • Create backups and test them


5. Know your Enemy


You can only protect a system the right way, if you know what threats you are facing. Why would this system be a target and who would be targeting it? Perform a risk analysis and determine what potential threats your system might endure.


Security Measures:


  • Vulnerability scans
  • Penetration tests
  • Risk analysis


Using ClamAV for Linux PCI DSS requirement 5: Malware

PCI DSS requirement 5: Malware and Anti-Virus

An important part in the PCI DSS compliance, is checking for malicious software, or malware. By using anti-virus software like ClamAV, malware threats can be detected, and in most cases prevented. In this article we focus mainly on Linux environments, but of course most of these tips will apply to other platforms like Mac OS.

5.1. Verify presence of software

5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists.

First thing is actually determining if ClamAV is installed on the system. This can be done by querying the related package manager on Linux:

  • dpkg -l clamav
  • rpm -q clamav
  • pacman -Q clamav

5.1.1 Review documentation

5.1.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs;
– Detect all known types of malicious software,
– Remove all known types of malicious software, and
– Protect against all known types of malicious software.

The documentation of ClamAV can be found on its website. It can detect every common form of malware. Depending on the mode the software is used, it can prevent, detect or remove the related files.

ClamAV can be used in several ways:

Daemon mode

Processes can interface with the Clam daemon and request a file descriptor to be tested. The daemon then will return if the file is OK, or a different code (infected, no permissions etc).

Manual scanner

The clamscan utility can be used to manually check files. This is also a great way of running a regular scan on Linux machines, by using clamscan in a cronjob.

5.1.2 Monitoring of malware threats

5.1.2 Interview personnel to verify that evolving malware
threats are monitored and evaluated for systems not currently
considered to be commonly affected by malicious software, in
order to confirm whether such systems continue to not require
anti-virus software.

This is a procedural item to test by interviewing the technical contact persons.

5.2 Management of anti-virus mechanisms

5.2 Ensure that all anti-virus mechanisms are maintained as follows:
- Are kept current,
- Perform periodic scans
- Generate audit logs which are retained per PCI DSS Requirement 10.7.

5.2.a Policies and procedures for anti-virus definitions

5.2.a Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date.

This is a non-technical item and should be checked in the documentation of the organization.

5.2.b ClamAV configuration

“5.2.b Examine anti-virus configurations, including the master installation of the software to verify anti-virus mechanisms are:
– Configured to perform automatic updates, and
– Configured to perform periodic scans.

To keep ClamAV up-to-date, the freshclam utility can be used. Additionally monitoring can be set to check that signatures are regularly updated. One option is to use the clamconf utility and determine the date of the signatures.

5.2.c Proper functioning of ClamAV

5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:
– The anti-virus software and definitions are current.
– Periodic scans are performed.

To ensure this item of the PCI DSS compliance verification is completely done, perform the following steps.


Determine how freshclam is running (freshclam in daemon mode or manual). Additionally check if it is properly logging to /var/log/clamav/freshclam.log. Determine if freshclam encountered any issues, like outdated definitions.

Clamd and clamscan

Check if clamscan is scheduled via a cronjob. Additionally check if clamd is running and available for other software components to use it (e.g. mailbox scanning via MTA).

5.2.d ClamAV logging

5.2.d Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that:
– Anti-virus software log generation is enabled, and
– Logs are retained in accordance with PCI DSS Requirement 10.7.

Check the log files in /var/log/clamav and determine if the software is properly running. The configuration files (/etc/clamav/clamd.conf and /etc/clamav/freshclam.conf) should have a log file defined. Use the clamconf utility to quickly determine if logging is enabled:

# clamconf | grep log
LogFile = "/var/log/clamav/clamd.log"
LogSyslog disabled
DevLiblog disabled
LogSyslog disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
Screenshot of clamconf utility

Clamconf utility shows all settings of clamd, clamscan and freshclam

5.3.a ClamAV configuration and status

5.3.a Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify the anti-virus software is actively running.

Check the process listing to see if ClamAV is running. If the Clam daemon is used, the clamd process should show up. It is common to see also the freshclam utility showing up, when using it as a daemon.

5.3.b Protection of ClamAV configuration files

5.3.b Examine anti-virus configurations, including the master
installation of the software and a sample of system
components, to verify that the anti-virus software cannot be
disabled or altered by users.

Check the file permissions of the following files:

  • /etc/clamav/clamd.conf
  • /etc/clamav/freshclam.conf

The files should be owned by the root user. Only root should be able to change the configuration file.

5.3.c Procedures regarding ClamAV management

5.3.c Interview responsible personnel and observe processes to
verify that anti-virus software cannot be disabled or altered by
users, unless specifically authorized by management on a
case-by-case basis for a limited time period.

This is a procedural test.

5.4 Documentation regarding malware protection

5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are:
- Documented,
- In use, and
- Known to all affected parties.

This is also procedural and needs manual testing, by interviewing.

Common findings

As can be seen, PCI DSS is extensive when it comes to testing anti-virus and malware solutions. Some common findings on Linux systems include the lack of anti-virus, outdated virus definitions, or not properly configured.

Empty database

Use monitoring to determine if signatures are loaded.

Database information
Database directory: /var/lib/clamav
Total number of signatures: 0

Signatures outdated

Another common issue is that the signature files are not up-to-date. This can be easily tested by reviewing log files, or feeding them into your SIEM.

Screenshot of ClamAV signatures being outdated

ClamAV signatures outdated


Clamscan not functioning

To check if ClamAV is properly working, download the EICAR test file and run clamscan.

Screenshot of clamscan running EICAR

Testing ClamAV with EICAR test file


« Older Entries