#1737·lynis

HTTP-6708 excessively slow on modest nginx configurations with ModSecurity

Author: troubleshooterCreated Apr 27, 2026Updated Apr 27, 2026

HTTP-6708 is slow on every run.

Environment

  • Lynis version: 3.1.6
  • OS: Debian 13
  • Kernel: 6.12.74+deb13+1-amd64
  • nginx with ModSecurity (927 rules loaded)

Describe the issue

HTTP-6708 consistently takes ~11 seconds to complete, triggering a long-execution warning, despite the nginx configuration being small and parsing near-instantly.

Relevant system state

Configuration size:

2570 lines total across 12 config files
37 server_name entries (virtual hosts)

nginx parses its full configuration, including 927 ModSecurity rules, in 0.131 seconds:

$ time nginx -t
2026/04/27 14:17:54 [notice] 88625#88625: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/927/0)
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

real    0m0.131s
user    0m0.089s
sys     0m0.040s

Finding and reading all config files from disk takes 0.046 seconds:

$ time find /etc/nginx -type f -name "*.conf" -exec grep -l "" {} \;
[...12 files listed...]

real    0m0.046s
user    0m0.028s
sys     0m0.015s

Yet Lynis HTTP-6708 takes ~11 seconds on the same files.

Log output

  #  lynis audit system --quiet
  [WARNING]: Test HTTP-6708 had a long execution: 11.248315 seconds
  [WARNING]: Test CRYP-7902 had a long execution: 368.423856 seconds

Key observation

HTTP-6708 is registered with --network NO, meaning it performs purely static analysis of config files on disk. There are no network calls, DNS lookups, or upstream connections involved. The entire disk read completes in 0.046s, so the delay is entirely within Lynis's own parsing logic.

Suspected cause

The test likely performs multiple sequential grep passes over all config files — one pass per directive being checked — rather than a single-pass scan. With ModSecurity loading 927 rules across the config, repeated iteration over the full file tree compounds the overhead even on a modest configuration.

Expected behavior

HTTP-6708 should complete in well under a second on a configuration of this size, consistent with the time nginx itself takes to parse the same files.

Suggested fix

Consider refactoring the HTTP-6708 test logic to perform a single-pass read of all config files into memory (or a temporary aggregated file), then run all directive checks against that, rather than re-scanning the file tree for each individual check.


Note: A related long-execution issue was also filed for CRYP-7902 on the same system.