SecAuditLogType HTTPS blocking requests

[ledzepp4eva]

Hey,
I've been testing the new SecAuditLogType HTTPS setting, but sending the requests to logstash. This is so far working fine, however I noticed in DetectionOnly mode requests are blocked until the logs have been sent and modsecurity has received an ACK from logstash. Once the ACK has been received the rest of the page loads fine, however this does cause a delay in the requests which is not ideal.

Thanks,
Liam

Config

  # Log Directory                                                                                                       
  SecAuditLog http://xxx.xxx.xxx.xxx:port                                                                                                                                                      
  SecAuditEngine RelevantOnly                                                                                           
  SecAuditLogRelevantStatus "^(?:5|4(?!04))"                                                                            
  SecAuditLogParts ABCFHZ                                                                                               
  SecAuditLogType HTTPS                                                                                                                                                                                              
  SecAuditLogFormat JSON                                                                                                
  SecAuditLogDirMode 0755                                                                                               
  SecAuditLogFileMode 0644

Output from dev tools
Modsec Detectiononly

Modsec off

modsec on

[zimmerle]

Hi @ledzepp4eva,

Indeed there is no extra thread or process to handle the https delivery. However it should happens on the logging phase, where all the site content was already delivered to the end user.

Assuming that you are using nginx, you may have it configured to handle content on a single thread, using a single worker. That may be the reason why the second and third request delayed until the logs were delivered.

The optimization of the deliverable schema is very tied to your connector usage and or platform. In nginx you can play with threads and workers numbers. You can also construct your own connector to speed up the deliverable in a fashion that fits better the architecture of the library consumer.

The implementation is very simple and independent of internal modsec structures, The example code is available here:
https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/audit_log/writer/https.cc

[ledzepp4eva]

Hey @zimmerle,

I do have more than 1 worker_process configured, so this shouldn't be the case I believe.
I'll have a look at the connector option, as we do use lua in other parts of the configuration as a possible option.
Thanks,
Liam
p.s.
If it is of any use this is the nginx configuration

user            nginx;
pid             /var/run/nginx.pid;
worker_processes 12;

events {
  worker_connections  8192;
  multi_accept on;
}

error_log    syslog:server=example.com,facility=local3,severity=debug,tag=nginx;


worker_rlimit_nofile 800000;

http {

  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;

  log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" ' '$upstream_cache_status '
                  '$request_time $server_port $ssl_protocol $ssl_cipher $server_addr $host $hostname '
                  '"$upstream_addr" ' '"$upstream_status" ' '"$upstream_response_time" ' '"$upstream_response_length" '
                  '$ssl_session_reused ' '$ssl_server_name' ' "$request_id"';

 access_log syslog:server=example.com,facility=local4,severity=debug,tag= main;

  ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
  ssl_ecdh_curve              X25519:P-256:P-384:P-224:P-521;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_dhparam /etc/nginx/ssl/dhparam.pem;
  ssl_prefer_server_ciphers       on;


  variables_hash_bucket_size 2048;
  map_hash_bucket_size 128;
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  server_tokens off;
  open_file_cache max=10000;
  http2_push_preload on;

  limit_req_status 429;

  include /etc/nginx/conf.d/*.conf;
}

[zimmerle]

Apparently you are using http2 and it is holding the next delivery till finish the logging phase. In that case I would suggest an async model by saving the files to disk where a second process can be used to delivery the content to your end server. To avoid the I/O bottleneck I also suggest the utilization of a RAM disk.

[ledzepp4eva]

Thanks for the reply. Apologies for not mentioning it earlier, but I am trying to avoid writing to the disk because of issue #1927

I have sent the logs to a nginx instance that responds straight away with a 200 ok to minimise the latency