diff --git a/agent/.fpm b/agent/.fpm
index 50e677dc..f7646757 100644
--- a/agent/.fpm
+++ b/agent/.fpm
@@ -9,8 +9,6 @@
 --depends nodejs
 --depends nginx
 --depends libnginx-mod-stream
---depends libnginx-mod-http-modsecurity
---depends modsecurity-crs
 --depends ssl-cert
 --depends dnsmasq
 --deb-no-default-config-files
diff --git a/agent/templates/nginx.conf.ejs b/agent/templates/nginx.conf.ejs
index dad4b500..5238054c 100644
--- a/agent/templates/nginx.conf.ejs
+++ b/agent/templates/nginx.conf.ejs
@@ -43,9 +43,17 @@ http {
   proxy_cache_path /var/cache/nginx/auth_cache levels=1:2 keys_zone=auth_cache:1m
                    max_size=10m inactive=5m;
 
-  modsecurity on;
-  modsecurity_rules_file /etc/nginx/modsecurity_includes.conf;
-  modsecurity_transaction_id "$request_id";
+  <%_ /*
+    Upload throughput over HTTP/2 and HTTP/3. The small defaults (64k body
+    preread / h3 stream buffer, 256k per-worker h2 recv buffer) cap how much
+    request body a client may send before waiting on flow control, which
+    throttles large uploads through the proxy. The recv buffer is shared per
+    worker, so it is sized at several prereads to keep concurrent uploads
+    from starving each other.
+  */ -%>
+  http2_body_preread_size 4m;
+  http2_recv_buffer_size 16m;
+  http3_stream_buffer_size 4m;
 
   <%_ /* Modern TLS configuration */ -%>
   ssl_protocols TLSv1.2 TLSv1.3;
@@ -68,7 +76,6 @@ http {
     Internal error page server on a unix socket. Named locations proxy here
     with proxy_method GET so that NGINX's static file module will serve the
     HTML regardless of the original request method (POST, PUT, etc.).
-    ModSecurity is disabled to prevent re-evaluation of the original request.
   */ -%>
   upstream error_pages {
     server unix:/run/nginx-error-pages.sock;
@@ -76,7 +83,6 @@ http {
 
   server {
     listen unix:/run/nginx-error-pages.sock;
-    modsecurity off;
     ssi on;
 
     root /opt/opensource-server/error-pages;
diff --git a/error-pages/403.html b/error-pages/403.html
index f0c20d76..2967f5af 100644
--- a/error-pages/403.html
+++ b/error-pages/403.html
@@ -3,7 +3,7 @@
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>403 — Request Blocked</title>
+  <title>403 — Access Denied</title>
   <style>
     *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
 
@@ -150,10 +150,9 @@
 <body>
   <div class="container">
     <div class="status-code">403</div>
-    <h1>Request Blocked</h1>
+    <h1>Access Denied</h1>
     <p>
-      Your request was blocked by the web application firewall (WAF).
-      The request matched an OWASP Core Rule Set security rule.
+      You do not have permission to access this resource.
     </p>
     <div class="request-id">
       <div class="label">Request ID</div>
@@ -162,16 +161,14 @@ <h1>Request Blocked</h1>
     <div class="info">
       <strong>Think this is a mistake?</strong>
       Provide the request ID above to your server administrator.
-      The specific rule that triggered the block can be found in the
-      server audit log using this ID.
+      The request can be traced in the server logs using this ID.
     </div>
     <div class="examples">
-      <h2>Common triggers</h2>
+      <h2>Common causes</h2>
       <ul>
-        <li>SQL-like syntax in query parameters or form data</li>
-        <li>HTML or script tags in user input</li>
-        <li>Unusual HTTP headers or request methods</li>
-        <li>Path traversal patterns in the URL</li>
+        <li>Your account is not authorized for this application</li>
+        <li>You are signed in with the wrong account or group</li>
+        <li>The resource restricts access by policy</li>
       </ul>
     </div>
   </div>
diff --git a/images/agent/Dockerfile b/images/agent/Dockerfile
index c68d219a..4f71ac2b 100644
--- a/images/agent/Dockerfile
+++ b/images/agent/Dockerfile
@@ -5,30 +5,14 @@ FROM nodejs
 # opensource-* packages automatically
 COPY images/opensource-server.sources /etc/apt/sources.list.d/opensource-server.sources
 
-# Install the agent package (and its dependencies: nginx with stream +
-# ModSecurity modules, dnsmasq, ...) built by the builder image.
+# Install the agent package (and its dependencies: nginx with the stream
+# module, dnsmasq, ...) built by the builder image.
 RUN --mount=from=builder,source=/dist,target=/dist \
     apt-get update && \
     apt-get install -y /dist/opensource-agent_*.deb && \
     apt-get clean && \
     rm -rf /var/lib/apt/lists/*
 
-# configure nginx ModSecurity defaults
-RUN sed -i \
-        -e 's!^#\(include /usr/share/modsecurity-crs/owasp-crs.load\)$!\1!' \
-        /etc/nginx/modsecurity_includes.conf \
-    && sed -i -e 's/IncludeOptional/Include/' /usr/share/modsecurity-crs/owasp-crs.load \
-    && sed -i -e 's/^SecRuleEngine .*$/SecRuleEngine DetectionOnly/' /etc/nginx/modsecurity.conf
-
-# Logrotate overrides for NGINX and ModSecurity to work around a logrotate
-# repoen bug at https://github.com/owasp-modsecurity/ModSecurity-nginx/issues/351
-COPY ./images/agent/nginx.logrotate /etc/logrotate.d/nginx
-
-# Apply custom ModSecurity configurations. See the blame on that file for
-# details on what's been changed from stock.
-COPY ./images/agent/crs-setup.conf /etc/modsecurity/crs/crs-setup.conf
-COPY ./images/agent/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
-
 # Configure DNSMasq to only get its config from our agent
 RUN sed -i \
     -e 's/^CONFIG_DIR=\(.*\)$/#CONFIG_DIR=\1/' \
diff --git a/images/agent/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf b/images/agent/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
deleted file mode 100644
index 48639910..00000000
--- a/images/agent/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
+++ /dev/null
@@ -1,86 +0,0 @@
-# ------------------------------------------------------------------------
-# OWASP ModSecurity Core Rule Set ver.3.3.7
-# Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved.
-# Copyright (c) 2021-2024 Core Rule Set project. All rights reserved.
-#
-# The OWASP ModSecurity Core Rule Set is distributed under
-# Apache Software License (ASL) version 2
-# Please see the enclosed LICENSE file for full details.
-# ------------------------------------------------------------------------
-
-#
-# The purpose of this file is to hold LOCAL exceptions for your site.
-# The types of rules that would go into this file are one where you want
-# to unconditionally disable rules or modify their actions during startup.
-#
-# Please see the file REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example
-# for a description of the rule exclusions mechanism and the correct
-# use of this file.
-#
-
-#
-# Example Exclusion Rule: To unconditionally disable a rule ID
-#
-# ModSecurity Rule Exclusion: 942100 SQL Injection Detected via libinjection
-# SecRuleRemoveById 942100
-
-# Example Exclusion Rule: Remove a group of rules
-#
-# ModSecurity Rule Exclusion: Disable PHP injection rules
-# SecRuleRemoveByTag "attack-injection-php"
-
-#
-# Example Exclusion Rule: To unconditionally remove parameter "foo" from
-#                         inspection for SQLi rules
-#
-# ModSecurity Rule Exclusion: disable sqli rules for parameter foo.
-# SecRuleUpdateTargetByTag "attack-sqli" "!ARGS:foo"
-
-# I have opted to disabling the rule 920420 altogether, which is the rule
-# responsible for blocking requests based on the value of the Content-Type
-# header. While the rationale is sound, the cluster supports applications of too
-# varied configurations to feasibly whitelist every nessecary value. While this
-# does increase the likelihood of smuggled attacks via unparsed bodies, the
-# trade off has been deemed nessecary for usability in the cluster. Rule 920470
-# remains active which ensures the Content-Type header itself is conforming to
-# web standards which still reduces the overall attack surface.
-SecRuleRemoveById 920420
-
-
-# -- [[ Changing the Disruptive Action for Anomaly Mode ]] --
-#
-# In Anomaly Mode (default in CRS3), the rules in REQUEST-949-BLOCKING-EVALUATION.conf
-# and RESPONSE-959-BLOCKING-EVALUATION.conf check the accumulated attack scores
-# against your policy. To apply a disruptive action, they overwrite the default
-# actions specified in SecDefaultAction (setup.conf) with a 'deny' action.
-# This 'deny' is by default paired with a 'status:403' action.
-#
-# In order to change the disruptive action from 'deny' to something else,
-# you must use SecRuleUpdateActionByID directives AFTER the CRS rules
-# are configured, for instance in the RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf file.
-#
-# These actions only apply when using Anomaly Mode.
-#
-# Default action: block with error 403
-# (No configuration needed in this file if you want the default behavior.)
-#
-
-# Example: redirect back to the homepage on blocking
-#
-# SecRuleUpdateActionById 949110 "t:none,redirect:'http://%{request_headers.host}/'"
-# SecRuleUpdateActionById 959100 "t:none,redirect:'http://%{request_headers.host}/'"
-
-# Example: redirect to another URL on blocking
-#
-# SecRuleUpdateActionById 949110 "t:none,redirect:'http://example.com/report_problem'"
-# SecRuleUpdateActionById 959100 "t:none,redirect:'http://example.com/report_problem'"
-
-# Example: send an error 404
-#
-# SecRuleUpdateActionById 949110 "t:none,deny,status:404"
-# SecRuleUpdateActionById 959100 "t:none,deny,status:404"
-
-# Example: drop the connection (best for DoS attacks)
-#
-# SecRuleUpdateActionById 949110 "t:none,drop"
-# SecRuleUpdateActionById 959100 "t:none,drop"
diff --git a/images/agent/crs-setup.conf b/images/agent/crs-setup.conf
deleted file mode 100644
index d975da51..00000000
--- a/images/agent/crs-setup.conf
+++ /dev/null
@@ -1,882 +0,0 @@
-# ------------------------------------------------------------------------
-# OWASP ModSecurity Core Rule Set ver.3.3.7
-# Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved.
-# Copyright (c) 2021-2024 Core Rule Set project. All rights reserved.
-#
-# The OWASP ModSecurity Core Rule Set is distributed under
-# Apache Software License (ASL) version 2
-# Please see the enclosed LICENSE file for full details.
-# ------------------------------------------------------------------------
-
-
-#
-# -- [[ Introduction ]] --------------------------------------------------------
-#
-# The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack
-# detection rules that provide a base level of protection for any web
-# application. They are written for the open source, cross-platform
-# ModSecurity Web Application Firewall.
-#
-# See also:
-# https://coreruleset.org/
-# https://github.com/SpiderLabs/owasp-modsecurity-crs
-# https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
-#
-
-
-#
-# -- [[ System Requirements ]] -------------------------------------------------
-#
-# CRS requires ModSecurity version 2.8.0 or above.
-# We recommend to always use the newest ModSecurity version.
-#
-# The configuration directives/settings in this file are used to control
-# the OWASP ModSecurity CRS. These settings do **NOT** configure the main
-# ModSecurity settings (modsecurity.conf) such as SecRuleEngine,
-# SecRequestBodyAccess, SecAuditEngine, SecDebugLog, and XML processing.
-#
-# The CRS assumes that modsecurity.conf has been loaded. It is bundled with
-# ModSecurity. If you don't have it, you can get it from:
-# 2.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v2/master/modsecurity.conf-recommended
-# 3.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
-#
-# The order of file inclusion in your webserver configuration should always be:
-# 1. modsecurity.conf
-# 2. crs-setup.conf (this file)
-# 3. rules/*.conf (the CRS rule files)
-#
-# Please refer to the INSTALL file for detailed installation instructions.
-#
-
-
-#
-# -- [[ Mode of Operation: Anomaly Scoring vs. Self-Contained ]] ---------------
-#
-# The CRS can run in two modes:
-#
-# -- [[ Anomaly Scoring Mode (default) ]] --
-# In CRS3, anomaly mode is the default and recommended mode, since it gives the
-# most accurate log information and offers the most flexibility in setting your
-# blocking policies. It is also called "collaborative detection mode".
-# In this mode, each matching rule increases an 'anomaly score'.
-# At the conclusion of the inbound rules, and again at the conclusion of the
-# outbound rules, the anomaly score is checked, and the blocking evaluation
-# rules apply a disruptive action, by default returning an error 403.
-#
-# -- [[ Self-Contained Mode ]] --
-# In this mode, rules apply an action instantly. This was the CRS2 default.
-# It can lower resource usage, at the cost of less flexibility in blocking policy
-# and less informative audit logs (only the first detected threat is logged).
-# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
-# The first rule that matches will execute this action. In most cases this will
-# cause evaluation to stop after the first rule has matched, similar to how many
-# IDSs function.
-#
-# -- [[ Alert Logging Control ]] --
-# In the mode configuration, you must also adjust the desired logging options.
-# There are three common options for dealing with logging. By default CRS enables
-# logging to the webserver error log (or Event viewer) plus detailed logging to
-# the ModSecurity audit log (configured under SecAuditLog in modsecurity.conf).
-#
-# - To log to both error log and ModSecurity audit log file, use: "log,auditlog"
-# - To log *only* to the ModSecurity audit log file, use: "nolog,auditlog"
-# - To log *only* to the error log file, use: "log,noauditlog"
-#
-# Examples for the various modes follow.
-# You must leave one of the following options enabled.
-# Note that you must specify the same line for phase:1 and phase:2.
-#
-
-# Default: Anomaly Scoring mode, log to error log, log to ModSecurity audit log
-# - By default, offending requests are blocked with an error 403 response.
-# - To change the disruptive action, see RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example
-#   and review section 'Changing the Disruptive Action for Anomaly Mode'.
-# - In Apache, you can use ErrorDocument to show a friendly error page or
-#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
-#
-SecDefaultAction "phase:1,log,auditlog,pass"
-SecDefaultAction "phase:2,log,auditlog,pass"
-
-# Example: Anomaly Scoring mode, log only to ModSecurity audit log
-# - By default, offending requests are blocked with an error 403 response.
-# - To change the disruptive action, see RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example
-#   and review section 'Changing the Disruptive Action for Anomaly Mode'.
-# - In Apache, you can use ErrorDocument to show a friendly error page or
-#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
-#
-# SecDefaultAction "phase:1,nolog,auditlog,pass"
-# SecDefaultAction "phase:2,nolog,auditlog,pass"
-
-# Example: Self-contained mode, return error 403 on blocking
-# - In this configuration the default disruptive action becomes 'deny'. After a
-#   rule triggers, it will stop processing the request and return an error 403.
-# - You can also use a different error status, such as 404, 406, et cetera.
-# - In Apache, you can use ErrorDocument to show a friendly error page or
-#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
-#
-# SecDefaultAction "phase:1,log,auditlog,deny,status:403"
-# SecDefaultAction "phase:2,log,auditlog,deny,status:403"
-
-# Example: Self-contained mode, redirect back to homepage on blocking
-# - In this configuration the 'tag' action includes the Host header data in the
-#   log. This helps to identify which virtual host triggered the rule (if any).
-# - Note that this might cause redirect loops in some situations; for example
-#   if a Cookie or User-Agent header is blocked, it will also be blocked when
-#   the client subsequently tries to access the homepage. You can also redirect
-#   to another custom URL.
-# SecDefaultAction "phase:1,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
-# SecDefaultAction "phase:2,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
-
-
-#
-# -- [[ Paranoia Level Initialization ]] ---------------------------------------
-#
-# The Paranoia Level (PL) setting allows you to choose the desired level
-# of rule checks that will add to your anomaly scores.
-#
-# With each paranoia level increase, the CRS enables additional rules
-# giving you a higher level of security. However, higher paranoia levels
-# also increase the possibility of blocking some legitimate traffic due to
-# false alarms (also named false positives or FPs). If you use higher
-# paranoia levels, it is likely that you will need to add some exclusion
-# rules for certain requests and applications receiving complex input.
-#
-# - A paranoia level of 1 is default. In this level, most core rules
-#   are enabled. PL1 is advised for beginners, installations
-#   covering many different sites and applications, and for setups
-#   with standard security requirements.
-#   At PL1 you should face FPs rarely. If you encounter FPs, please
-#   open an issue on the CRS GitHub site and don't forget to attach your
-#   complete Audit Log record for the request with the issue.
-# - Paranoia level 2 includes many extra rules, for instance enabling
-#   many regexp-based SQL and XSS injection protections, and adding
-#   extra keywords checked for code injections. PL2 is advised
-#   for moderate to experienced users desiring more complete coverage
-#   and for installations with elevated security requirements.
-#   PL2 comes with some FPs which you need to handle.
-# - Paranoia level 3 enables more rules and keyword lists, and tweaks
-#   limits on special characters used. PL3 is aimed at users experienced
-#   at the handling of FPs and at installations with a high security
-#   requirement.
-# - Paranoia level 4 further restricts special characters.
-#   The highest level is advised for experienced users protecting
-#   installations with very high security requirements. Running PL4 will
-#   likely produce a very high number of FPs which have to be
-#   treated before the site can go productive.
-#
-# All rules will log their PL to the audit log;
-# example: [tag "paranoia-level/2"]. This allows you to deduct from the
-# audit log how the WAF behavior is affected by paranoia level.
-#
-# It is important to also look into the variable
-# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
-# defined below. Enabling it closes a possible bypass of CRS.
-#
-# Uncomment this rule to change the default:
-#
-#SecAction \
-#  "id:900000,\
-#   phase:1,\
-#   nolog,\
-#   pass,\
-#   t:none,\
-#   setvar:tx.paranoia_level=1"
-
-
-# It is possible to execute rules from a higher paranoia level but not include
-# them in the anomaly scoring. This allows you to take a well-tuned system on
-# paranoia level 1 and add rules from paranoia level 2 without having to fear
-# the new rules would lead to false positives that raise your score above the
-# threshold.
-# This optional feature is enabled by uncommenting the following rule and
-# setting the tx.executing_paranoia_level.
-# Technically, rules up to the level defined in tx.executing_paranoia_level
-# will be executed, but only the rules up to tx.paranoia_level affect the
-# anomaly scores.
-# By default, tx.executing_paranoia_level is set to tx.paranoia_level.
-# tx.executing_paranoia_level must not be lower than tx.paranoia_level.
-#
-# Please notice that setting tx.executing_paranoia_level to a higher paranoia
-# level results in a performance impact that is equally high as setting
-# tx.paranoia_level to said level.
-#
-#SecAction \
-#  "id:900001,\
-#   phase:1,\
-#   nolog,\
-#   pass,\
-#   t:none,\
-#   setvar:tx.executing_paranoia_level=1"
-
-
-#
-# -- [[ Enforce Body Processor URLENCODED ]] -----------------------------------
-#
-# ModSecurity selects the body processor based on the Content-Type request
-# header. But clients are not always setting the Content-Type header for their
-# request body payloads. This will leave ModSecurity with limited vision into
-# the payload.  The variable tx.enforce_bodyproc_urlencoded lets you force the
-# URLENCODED body processor in these situations. This is off by default, as it
-# implies a change of the behaviour of ModSecurity beyond CRS (the body
-# processor applies to all rules, not only CRS) and because it may lead to
-# false positives already on paranoia level 1. However, enabling this variable
-# closes a possible bypass of CRS so it should be considered.
-#
-# Uncomment this rule to change the default:
-#
-#SecAction \
-#  "id:900010,\
-#   phase:1,\
-#   nolog,\
-#   pass,\
-#   t:none,\
-#   setvar:tx.enforce_bodyproc_urlencoded=1"
-
-
-#
-# -- [[ Anomaly Mode Severity Levels ]] ----------------------------------------
-#
-# Each rule in the CRS has an associated severity level.
-# These are the default scoring points for each severity level.
-# These settings will be used to increment the anomaly score if a rule matches.
-# You may adjust these points to your liking, but this is usually not needed.
-#
-# - CRITICAL severity: Anomaly Score of 5.
-#       Mostly generated by the application attack rules (93x and 94x files).
-# - ERROR severity: Anomaly Score of 4.
-#       Generated mostly from outbound leakage rules (95x files).
-# - WARNING severity: Anomaly Score of 3.
-#       Generated mostly by malicious client rules (91x files).
-# - NOTICE severity: Anomaly Score of 2.
-#       Generated mostly by the protocol rules (92x files).
-#
-# In anomaly mode, these scores are cumulative.
-# So it's possible for a request to hit multiple rules.
-#
-# (Note: In this file, we use 'phase:1' to set CRS configuration variables.
-# In general, 'phase:request' is used. However, we want to make absolutely sure
-# that all configuration variables are set before the CRS rules are processed.)
-#
-#SecAction \
-# "id:900100,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.critical_anomaly_score=5,\
-#  setvar:tx.error_anomaly_score=4,\
-#  setvar:tx.warning_anomaly_score=3,\
-#  setvar:tx.notice_anomaly_score=2"
-
-
-#
-# -- [[ Anomaly Mode Blocking Threshold Levels ]] ------------------------------
-#
-# Here, you can specify at which cumulative anomaly score an inbound request,
-# or outbound response, gets blocked.
-#
-# Most detected inbound threats will give a critical score of 5.
-# Smaller violations, like violations of protocol/standards, carry lower scores.
-#
-# [ At default value ]
-# If you keep the blocking thresholds at the defaults, the CRS will work
-# similarly to previous CRS versions: a single critical rule match will cause
-# the request to be blocked and logged.
-#
-# [ Using higher values ]
-# If you want to make the CRS less sensitive, you can increase the blocking
-# thresholds, for instance to 7 (which would require multiple rule matches
-# before blocking) or 10 (which would require at least two critical alerts - or
-# a combination of many lesser alerts), or even higher. However, increasing the
-# thresholds might cause some attacks to bypass the CRS rules or your policies.
-#
-# [ New deployment strategy: Starting high and decreasing ]
-# It is a common practice to start a fresh CRS installation with elevated
-# anomaly scoring thresholds (>100) and then lower the limits as your
-# confidence in the setup grows. You may also look into the Sampling
-# Percentage section below for a different strategy to ease into a new
-# CRS installation.
-#
-# [ Anomaly Threshold / Paranoia Level Quadrant ]
-#
-#     High Anomaly Limit   |   High Anomaly Limit
-#     Low Paranoia Level   |   High Paranoia Level
-#     -> Fresh Site        |   -> Experimental Site
-# ------------------------------------------------------
-#     Low Anomaly Limit    |   Low Anomaly Limit
-#     Low Paranoia Level   |   High Paranoia Level
-#     -> Standard Site     |   -> High Security Site
-#
-# Uncomment this rule to change the defaults:
-#
-#SecAction \
-# "id:900110,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.inbound_anomaly_score_threshold=5,\
-#  setvar:tx.outbound_anomaly_score_threshold=4"
-
-#
-# -- [[ Application Specific Rule Exclusions ]] ----------------------------------------
-#
-# Some well-known applications may undertake actions that appear to be
-# malicious. This includes actions such as allowing HTML or Javascript within
-# parameters. In such cases the CRS aims to prevent false positives by allowing
-# administrators to enable prebuilt, application specific exclusions on an
-# application by application basis.
-# These application specific exclusions are distinct from the rules that would
-# be placed in the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS configuration file as
-# they are prebuilt for specific applications. The 'REQUEST-900' file is
-# designed for users to add their own custom exclusions. Note, using these
-# application specific exclusions may loosen restrictions of the CRS,
-# especially if used with an application they weren't designed for. As a result
-# they should be applied with care.
-# To use this functionality you must specify a supported application. To do so
-# uncomment rule 900130. In addition to uncommenting the rule you will need to
-# specify which application(s) you'd like to enable exclusions for. Only a
-# (very) limited set of applications are currently supported, please use the
-# filenames prefixed with 'REQUEST-903' to guide you in your selection.
-# Such filenames use the following convention:
-# REQUEST-903.9XXX-{APPNAME}-EXCLUSIONS-RULES.conf
-#
-# It is recommended if you run multiple web applications on your site to limit
-# the effects of the exclusion to only the path where the excluded webapp
-# resides using a rule similar to the following example:
-# SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:tx.crs_exclusions_wordpress=1
-
-#
-# Modify and uncomment this rule to select which application:
-#
-#SecAction \
-# "id:900130,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.crs_exclusions_cpanel=1,\
-#  setvar:tx.crs_exclusions_drupal=1,\
-#  setvar:tx.crs_exclusions_dokuwiki=1,\
-#  setvar:tx.crs_exclusions_nextcloud=1,\
-#  setvar:tx.crs_exclusions_wordpress=1,\
-#  setvar:tx.crs_exclusions_xenforo=1"
-
-#
-# -- [[ HTTP Policy Settings ]] ------------------------------------------------
-#
-# This section defines your policies for the HTTP protocol, such as:
-# - allowed HTTP versions, HTTP methods, allowed request Content-Types
-# - forbidden file extensions (e.g. .bak, .sql) and request headers (e.g. Proxy)
-#
-# These variables are used in the following rule files:
-# - REQUEST-911-METHOD-ENFORCEMENT.conf
-# - REQUEST-912-DOS-PROTECTION.conf
-# - REQUEST-920-PROTOCOL-ENFORCEMENT.conf
-
-# HTTP methods that a client is allowed to use.
-# Default: GET HEAD POST OPTIONS
-# Example: for RESTful APIs, add the following methods: PUT PATCH DELETE
-# Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK
-#          MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK
-# Uncomment this rule to change the default.
-#
-# We add PUT PATCH and DELETE per the above to allow standard RESTful API
-# semantics.
-SecAction \
- "id:900200,\
-  phase:1,\
-  nolog,\
-  pass,\
-  t:none,\
-  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE'"
-
-# Content-Types that a client is allowed to send in a request.
-# Default: |application/x-www-form-urlencoded| |multipart/form-data| |text/xml|
-# |application/xml| |application/soap+xml| |application/json|
-#
-# Please note, that the rule where CRS uses this variable (920420) evaluates it with operator
-# `@within`, which is case sensitive, but uses t:lowercase. You must add your whole custom
-# Content-Type with lowercase.
-#
-# Bypass Warning: some applications may not rely on the content-type request header in order
-# to parse the request body. This could make an attacker able to send malicious URLENCODED/JSON/XML
-# payloads without being detected by the WAF. Allowing request content-type that doesn't activate any
-# body processor (for example: "text/plain", "application/x-amf", "application/octet-stream", etc..)
-# could lead to a WAF bypass. For example, a malicious JSON payload submitted with a "text/plain"
-# content type may still be interpreted as JSON by a backend application but would not trigger the
-# JSON body parser at the WAF, leading to a bypass.
-#
-# When additional JSON content types are legitimately used in a deployment,
-# e.g. application/cloudevents+json, it is extremely important to ensure that a
-# rule exists to enable the engine's JSON body processor for these additional
-# JSON content types. Failure to do so can lead to a request body bypass. The
-# default JSON rule in modsecurity.conf-recommended (200001) will only activate
-# the JSON body processor for the specific content type application/json. The
-# optional modsecurity.conf-recommended rule 200006 can be used to enable the
-# JSON body processor for a wide variety of JSON content types.
-#
-# To prevent blocking request with not allowed content-type by default, you can create an exclusion
-# rule that removes rule 920420. For example:
-# SecRule REQUEST_HEADERS:Content-Type "@rx ^text/plain" \
-#  "id:1234,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  ctl:ruleRemoveById=920420,\
-#  chain"
-#  SecRule REQUEST_URI "@rx ^/foo/bar" "t:none"
-#
-# Uncomment this rule to change the default.
-#SecAction \
-# "id:900220,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/xml| |application/xml| |application/soap+xml| |application/json|'"
-
-# Allowed HTTP versions.
-# Default: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
-# Example for legacy clients: HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
-# Note that some web server versions use 'HTTP/2', some 'HTTP/2.0', so
-# we include both version strings by default.
-# Uncomment this rule to change the default.
-#
-# We add HTTP/3 and HTTP/3.0 to the list of allowed HTTP versions to support QUIC connections
-# via the ngx_http_v3_module. See https://github.com/mieweb/opensource-server/issues/211
-SecAction \
- "id:900230,\
-  phase:1,\
-  nolog,\
-  pass,\
-  t:none,\
-  setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 HTTP/3 HTTP/3.0'"
-
-# Forbidden file extensions.
-# Guards against unintended exposure of development/configuration files.
-# Default: .asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/
-# Example: .bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .rdb/ .sql/
-# Uncomment this rule to change the default.
-#SecAction \
-# "id:900240,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/'"
-
-# Forbidden request headers.
-# Header names should be lowercase, enclosed by /slashes/ as delimiters.
-# Default: /accept-charset/ /content-encoding/ /proxy/ /lock-token/ /content-range/ /if/
-#
-# Note: Accept-Charset is a deprecated header that should not be used by clients and
-# ignored by servers. It can be used for a response WAF bypass, by asking for a charset
-# that the WAF cannot decode.
-# Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset
-#
-# Note: Content-Encoding is used to list any encodings that have been applied to the
-# original payload. It is only used for compression, which isn't supported by CRS by
-# default since it blocks newlines and null bytes inside the request body. Most
-# compression algorithms require at least null bytes per RFC. Blocking it shouldn't
-# break anything and increases security since ModSecurity is incapable of properly
-# scanning compressed request bodies.
-#
-# Note: Blocking Proxy header prevents 'httpoxy' vulnerability: https://httpoxy.org
-#
-# Uncomment this rule to change the default.
-#SecAction \
-# "id:900250,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.restricted_headers=/accept-charset/ /content-encoding/ /proxy/ /lock-token/ /content-range/ /if/'"
-
-# File extensions considered static files.
-# Extensions include the dot, lowercase, enclosed by /slashes/ as delimiters.
-# Used in DoS protection rule. See section "Anti-Automation / DoS Protection".
-# Default: /.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/
-# Uncomment this rule to change the default.
-#SecAction \
-# "id:900260,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.static_extensions=/.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/'"
-
-# Content-Types charsets that a client is allowed to send in a request.
-# Default: utf-8|iso-8859-1|iso-8859-15|windows-1252
-# Uncomment this rule to change the default.
-# Use "|" to separate multiple charsets like in the rule defining
-# tx.allowed_request_content_type.
-#SecAction \
-# "id:900280,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.allowed_request_content_type_charset=utf-8|iso-8859-1|iso-8859-15|windows-1252'"
-
-#
-# -- [[ HTTP Argument/Upload Limits ]] -----------------------------------------
-#
-# Here you can define optional limits on HTTP get/post parameters and uploads.
-# This can help to prevent application specific DoS attacks.
-#
-# These values are checked in REQUEST-920-PROTOCOL-ENFORCEMENT.conf.
-# Beware of blocking legitimate traffic when enabling these limits.
-#
-
-# Block request if number of arguments is too high
-# Default: unlimited
-# Example: 255
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900300,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.max_num_args=255"
-
-# Block request if the length of any argument name is too high
-# Default: unlimited
-# Example: 100
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900310,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.arg_name_length=100"
-
-# Block request if the length of any argument value is too high
-# Default: unlimited
-# Example: 400
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900320,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.arg_length=400"
-
-# Block request if the total length of all combined arguments is too high
-# Default: unlimited
-# Example: 64000
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900330,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.total_arg_length=64000"
-
-# Block request if the file size of any individual uploaded file is too high
-# Default: unlimited
-# Example: 1048576
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900340,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.max_file_size=1048576"
-
-# Block request if the total size of all combined uploaded files is too high
-# Default: unlimited
-# Example: 1048576
-# Uncomment this rule to set a limit.
-#SecAction \
-# "id:900350,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.combined_file_sizes=1048576"
-
-
-#
-# -- [[ Easing In / Sampling Percentage ]] -------------------------------------
-#
-# Adding the Core Rule Set to an existing productive site can lead to false
-# positives, unexpected performance issues and other undesired side effects.
-#
-# It can be beneficial to test the water first by enabling the CRS for a
-# limited number of requests only and then, when you have solved the issues (if
-# any) and you have confidence in the setup, to raise the ratio of requests
-# being sent into the ruleset.
-#
-# Adjust the percentage of requests that are funnelled into the Core Rules by
-# setting TX.sampling_percentage below. The default is 100, meaning that every
-# request gets checked by the CRS.  The selection of requests, which are going
-# to be checked, is based on a pseudo random number generated by ModSecurity.
-#
-# If a request is allowed to pass without being checked by the CRS, there is no
-# entry in the audit log (for performance reasons), but an error log entry is
-# written.  If you want to disable the error log entry, then issue the
-# following directive somewhere after the inclusion of the CRS
-# (E.g., RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf).
-#
-# SecRuleUpdateActionById 901150 "nolog"
-#
-# ATTENTION: If this TX.sampling_percentage is below 100, then some of the
-# requests will bypass the Core Rules completely and you lose the ability to
-# protect your service with ModSecurity.
-#
-# Uncomment this rule to enable this feature:
-#
-#SecAction "id:900400,\
-#  phase:1,\
-#  pass,\
-#  nolog,\
-#  setvar:tx.sampling_percentage=100"
-
-
-#
-# -- [[ Project Honey Pot HTTP Blacklist ]] ------------------------------------
-#
-# Optionally, you can check the client IP address against the Project Honey Pot
-# HTTPBL (dnsbl.httpbl.org). In order to use this, you need to register to get a
-# free API key. Set it here with SecHttpBlKey.
-#
-# Project Honeypot returns multiple different malicious IP types.
-# You may specify which you want to block by enabling or disabling them below.
-#
-# Ref: https://www.projecthoneypot.org/httpbl.php
-# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecHttpBlKey
-#
-# Uncomment these rules to use this feature:
-#
-#SecHttpBlKey XXXXXXXXXXXXXXXXX
-#SecAction "id:900500,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.block_search_ip=1,\
-#  setvar:tx.block_suspicious_ip=1,\
-#  setvar:tx.block_harvester_ip=1,\
-#  setvar:tx.block_spammer_ip=1"
-
-
-#
-# -- [[ GeoIP Database ]] ------------------------------------------------------
-#
-# There are some rulesets that inspect geolocation data of the client IP address
-# (geoLookup). The CRS uses geoLookup to implement optional country blocking.
-#
-# To use geolocation, we make use of the MaxMind GeoIP database.
-# This database is not included with the CRS and must be downloaded.
-#
-# There are two formats for the GeoIP database. ModSecurity v2 uses GeoLite (.dat files),
-# and ModSecurity v3 uses GeoLite2 (.mmdb files).
-#
-# If you use ModSecurity 3, MaxMind provides a binary for updating GeoLite2 files,
-# see https://github.com/maxmind/geoipupdate.
-#
-# Download the package for your OS, and read https://dev.maxmind.com/geoip/geoipupdate/
-# for configuration options.
-#
-# Warning: GeoLite (not GeoLite2) databases are considered legacy, and not being updated anymore.
-# See https://support.maxmind.com/geolite-legacy-discontinuation-notice/ for more info.
-#
-# Therefore, if you use ModSecurity v2, you need to regenerate updated .dat files
-# from CSV files first.
-#
-# You can achieve this using https://github.com/sherpya/geolite2legacy
-# Pick the zip files from maxmind site:
-# https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip
-#
-# Follow the guidelines for installing the tool and run:
-# ./geolite2legacy.py -i GeoLite2-Country-CSV.zip \
-#                     -f geoname2fips.csv -o /usr/share/GeoliteCountry.dat
-#
-# Update the database regularly, see Step 3 of the configuration link above.
-#
-# By default, when you execute `sudo geoipupdate` on Linux, files from the free database
-# will be downloaded to `/usr/share/GeoIP` (both v1 and v2).
-#
-# Then choose from:
-#   - `GeoLite2-Country.mmdb` (if you are using ModSecurity v3)
-#   - `GeoLiteCountry.dat`    (if you are using ModSecurity v2)
-#
-# Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html
-# Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
-#
-# Uncomment only one of the next rules here to use this feature.
-# Choose the one depending on the ModSecurity version you are using, and change the path accordingly:
-#
-# For ModSecurity v3:
-#SecGeoLookupDB /usr/share/GeoIP/GeoLite2-Country.mmdb
-# For ModSecurity v2 (points to the converted one):
-#SecGeoLookupDB /usr/share/GeoIP/GeoLiteCountry.dat
-
-#
-# -=[ Block Countries ]=-
-#
-# Rules in the IP Reputation file can check the client against a list of high
-# risk country codes. These countries have to be defined in the variable
-# tx.high_risk_country_codes via their ISO 3166 two-letter country code:
-# https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements
-#
-# If you are sure that you are not getting any legitimate requests from a given
-# country, then you can disable all access from that country via this variable.
-# The rule performing the test has the rule id 910100.
-#
-# This rule requires SecGeoLookupDB to be enabled and the GeoIP database to be
-# downloaded (see the section "GeoIP Database" above.)
-#
-# By default, the list is empty. A list used by some sites was the following:
-# setvar:'tx.high_risk_country_codes=UA ID YU LT EG RO BG TR RU PK MY CN'"
-#
-# Uncomment this rule to use this feature:
-#
-#SecAction \
-# "id:900600,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.high_risk_country_codes='"
-
-
-#
-# -- [[ Anti-Automation / DoS Protection ]] ------------------------------------
-#
-# Optional DoS protection against clients making requests too quickly.
-#
-# When a client is making more than 100 requests (excluding static files) within
-# 60 seconds, this is considered a 'burst'. After two bursts, the client is
-# blocked for 600 seconds.
-#
-# Requests to static files are not counted towards DoS; they are listed in the
-# 'tx.static_extensions' setting, which you can change in this file (see
-# section "HTTP Policy Settings").
-#
-# For a detailed description, see rule file REQUEST-912-DOS-PROTECTION.conf.
-#
-# Uncomment this rule to use this feature:
-#
-#SecAction \
-# "id:900700,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:'tx.dos_burst_time_slice=60',\
-#  setvar:'tx.dos_counter_threshold=100',\
-#  setvar:'tx.dos_block_timeout=600'"
-
-
-#
-# -- [[ Check UTF-8 encoding ]] ------------------------------------------------
-#
-# The CRS can optionally check request contents for invalid UTF-8 encoding.
-# We only want to apply this check if UTF-8 encoding is actually used by the
-# site; otherwise it will result in false positives.
-#
-# Uncomment this rule to use this feature:
-#
-#SecAction \
-# "id:900950,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.crs_validate_utf8_encoding=1"
-
-
-#
-# -- [[ Blocking Based on IP Reputation ]] ------------------------------------
-#
-# Blocking based on reputation is permanent in the CRS. Unlike other rules,
-# which look at the individual request, the blocking of IPs is based on
-# a persistent record in the IP collection, which remains active for a
-# certain amount of time.
-#
-# There are two ways an individual client can become flagged for blocking:
-# - External information (RBL, GeoIP, etc.)
-# - Internal information (Core Rules)
-#
-# The record in the IP collection carries a flag, which tags requests from
-# individual clients with a flag named IP.reput_block_flag.
-# But the flag alone is not enough to have a client blocked. There is also
-# a global switch named tx.do_reput_block. This is off by default. If you set
-# it to 1 (=On), requests from clients with the IP.reput_block_flag will
-# be blocked for a certain duration.
-#
-# Variables
-# ip.reput_block_flag      Blocking flag for the IP collection record
-# ip.reput_block_reason    Reason (= rule message) that caused to blocking flag
-# tx.do_reput_block        Switch deciding if we really block based on flag
-# tx.reput_block_duration  Setting to define the duration of a block
-#
-# It may be important to know, that all the other core rules are skipped for
-# requests, when it is clear that they carry the blocking flag in question.
-#
-# Uncomment this rule to use this feature:
-#
-#SecAction \
-# "id:900960,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.do_reput_block=1"
-#
-# Uncomment this rule to change the blocking time:
-# Default: 300 (5 minutes)
-#
-#SecAction \
-# "id:900970,\
-#  phase:1,\
-#  nolog,\
-#  pass,\
-#  t:none,\
-#  setvar:tx.reput_block_duration=300"
-
-
-#
-# -- [[ Collection timeout ]] --------------------------------------------------
-#
-# Set the SecCollectionTimeout directive from the ModSecurity default (1 hour)
-# to a lower setting which is appropriate to most sites.
-# This increases performance by cleaning out stale collection (block) entries.
-#
-# This value should be greater than or equal to:
-# tx.reput_block_duration (see section "Blocking Based on IP Reputation") and
-# tx.dos_block_timeout (see section "Anti-Automation / DoS Protection").
-#
-# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecCollectionTimeout
-
-# Please keep this directive uncommented.
-# Default: 600 (10 minutes)
-SecCollectionTimeout 600
-
-
-#
-# -- [[ End of setup ]] --------------------------------------------------------
-#
-# The CRS checks the tx.crs_setup_version variable to ensure that the setup
-# has been loaded. If you are not planning to use this setup template,
-# you must manually set the tx.crs_setup_version variable before including
-# the CRS rules/* files.
-#
-# The variable is a numerical representation of the CRS version number.
-# E.g., v3.0.0 is represented as 300.
-#
-SecAction \
-    "id:900990,\
-    phase:1,\
-    pass,\
-    t:none,\
-    nolog,\
-    setvar:tx.crs_setup_version=337"
diff --git a/images/agent/nginx.logrotate b/images/agent/nginx.logrotate
deleted file mode 100644
index ef5a5585..00000000
--- a/images/agent/nginx.logrotate
+++ /dev/null
@@ -1,32 +0,0 @@
-/var/log/nginx/access.log
-/var/log/nginx/error.log
-/var/log/nginx/stream-access.log
-{
-	daily
-	missingok
-	rotate 14
-	compress
-	delaycompress
-	notifempty
-	create 0640 www-data adm
-	sharedscripts
-	prerotate
-		if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
-			run-parts /etc/logrotate.d/httpd-prerotate; \
-		fi \
-	endscript
-	postrotate
-		invoke-rc.d nginx rotate >/dev/null 2>&1
-	endscript
-}
-
-/var/log/nginx/modsec_audit.log
-{
-	daily
-	missingok
-	rotate 14
-	compress
-	delaycompress
-	notifempty
-	copytruncate
-}
diff --git a/mie-opensource-landing/docs/developers/docker-images.md b/mie-opensource-landing/docs/developers/docker-images.md
index 3645304a..6c4016b9 100644
--- a/mie-opensource-landing/docs/developers/docker-images.md
+++ b/mie-opensource-landing/docs/developers/docker-images.md
@@ -24,7 +24,7 @@ Extends base with Node.js 24 from NodeSource. Inherits LDAP authentication.
 
 ### Agent (`agent`)
 
-Extends nodejs with the `opensource-agent` package (check-in agent, nginx with ModSecurity/OWASP CRS, dnsmasq) and [acme.sh](https://github.com/acmesh-official/acme.sh) for ACME certificate management. Used as the networking layer for each site — handles reverse proxy, DNS, and TLS. See [Deploying Agents](../admins/deploying-agents.md).
+Extends nodejs with the `opensource-agent` package (check-in agent, nginx, dnsmasq) and [acme.sh](https://github.com/acmesh-official/acme.sh) for ACME certificate management. Used as the networking layer for each site — handles reverse proxy, DNS, and TLS. See [Deploying Agents](../admins/deploying-agents.md).
 
 **Registry:** `ghcr.io/mieweb/opensource-server/agent` · **Source:** [`images/agent/`](https://github.com/mieweb/opensource-server/tree/main/images/agent)
 
@@ -54,7 +54,7 @@ images/
 ├── docs/
 │   └── Dockerfile           # Extends base (nginx + opensource-docs)
 ├── agent/
-│   └── Dockerfile           # Extends nodejs (opensource-agent, ModSecurity, acme.sh)
+│   └── Dockerfile           # Extends nodejs (opensource-agent, acme.sh)
 └── manager/
     └── Dockerfile           # Extends agent (PostgreSQL + opensource-server/docs)
 ```
