We use cookies to ensure that we give you the best experience on our website.

在 Debian Linux 上使用 Apache 安装 ModSecurity

ModSecurity 是适用于 Apache HTTP 服务器的功能强大的开源 Web 应用程序防火墙 (WAF) 模块。 WAF 充当 Web 服务器和传入流量之间的安全层，实时分析 HTTP 请求并在恶意活动到达您的应用程序之前阻止恶意活动。 ModSecurity 可防御常见攻击，包括 SQL 注入（攻击者试图操纵数据库查询）、跨站点脚本（XSS，将恶意脚本注入网页）和远程代码执行尝试。

本指南介绍了如何使用 Digitalwave 存储库在 Debian 上安装 ModSecurity 2，该存储库提供了最新的稳定二进制文件。您还将配置 OWASP 核心规则集 (CRS)，这是由开放 Web 应用程序安全项目维护的预定义安全规则的综合集合。 ModSecurity 和 OWASP CRS 共同构成了一个强大的防御层在 Debian 上运行。对于生产部署，请将此设置与确保运输安全。

在继续安装 ModSecurity 之前，首先确保您的 Debian 系统已更新。此外，保持所有软件包最新不仅可以提高性能，还可以最大限度地减少安全漏洞：

sudo apt update && sudo apt upgrade

更新后，检查您的系统上是否安装了 Apache。如果缺少 Apache，请使用以下命令安装它：

sudo apt install apache2

添加 Digitalwave ModSecurity 存储库

接下来，为最新的 ModSecurity 软件包配置 Digitalwave 存储库。虽然 Debian 的默认存储库包括 ModSecurity，但可用版本通常已经过时，这可能会导致兼容性问题或缺少安全补丁。然而，Digitalwave 存储库提供了稳定、最新的 ModSecurity 二进制文件以及专为 Debian 和 Ubuntu 系统打包的 OWASP 核心规则集。

安装所需的依赖项

首先，安装安全存储库管理所需的软件包：

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

导入 GPG 密钥

接下来，下载并存储存储库 GPG 密钥以验证包的真实性：

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/digitalwave-modsecurity.gpg

添加存储库

现在，使用 DEB822 格式创建存储库配置文件，这是 Debian 12 及更高版本的现代标准：

cat <<EOF | sudo tee /etc/apt/sources.list.d/digitalwave-modsecurity.sources
Types: deb
URIs: https://modsecurity.digitalwave.hu/debian/
Suites: $(lsb_release -cs) $(lsb_release -cs)-backports
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /usr/share/keyrings/digitalwave-modsecurity.gpg
EOF

Debian 12 (Bookworm) 是当前受支持的最古老的稳定 Debian 版本，并使用上面所示的现代 DEB822 .sources 格式。所有当前和未来的 Debian 版本（12、13 Trixie 及更高版本）都使用此格式作为标准。 Debian 11 (Bullseye) 仍然使用旧版 .list 格式 - 如果运行 Debian 11，请改用替代命令格式。

配置 APT 包优先级

为了确保 APT 优先考虑 Digitalwave 存储库中的 ModSecurity 软件包而不是默认的 Debian 软件包，请创建固定配置：

cat <<EOF | sudo tee /etc/apt/preferences.d/99modsecurity
Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

接下来，更新包列表以包含新的存储库：

sudo apt update

然后，验证存储库优先级是否正确应用：

apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

输出应显示优先级为 900 的 Digitalwave 存储库，确认将从那里安装软件包：

libapache2-mod-security2:
  Installed: (none)
  Candidate: 2.9.7-1+deb12u1
  Version table:
     2.9.7-1+deb12u1 900
        900 https://modsecurity.digitalwave.hu/debian bookworm/main amd64 Packages
modsecurity-crs:
  Installed: (none)
  Candidate: 3.3.4-1
  Version table:
     3.3.4-1 900
        900 https://modsecurity.digitalwave.hu/debian bookworm-backports/main amd64 Packages

安装 ModSecurity 2 模块

现在，从 Digitalwave 存储库安装 ModSecurity Apache 模块：

sudo apt install libapache2-mod-security2

安装后，在 Apache 中启用该模块：

sudo a2enmod security2

输出确认模块已启用：

Enabling module security2.
To activate the new configuration, you need to run:
  systemctl restart apache2

最后，重新启动 Apache 以加载新模块：

sudo systemctl restart apache2

配置 ModSecurity 2

验证模块配置

ModSecurity 配置文件位于 /etc/apache2/mods-enabled/security2.conf。打开它来验证配置：

sudo nano /etc/apache2/mods-enabled/security2.conf

确认以下行存在且未注释，因为它包含 ModSecurity 目录中的配置文件：

IncludeOptional /etc/modsecurity/*.conf

Apache 默认情况下不注释此行。验证完毕后，关闭文件。

激活 ModSecurity 配置

接下来，激活 ModSecurity 配置。 ModSecurity 附带了推荐的配置文件。重命名它以激活 ModSecurity：

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

然后，打开配置文件以启用主动保护：

sudo nano /etc/modsecurity/modsecurity.conf

默认情况下，ModSecurity 在仅检测模式下运行，该模式会记录潜在威胁而不阻止它们。这对于初始测试很有用，但不提供主动保护。要启用阻止，请找到第 7 行附近的 SecRuleEngine 行并将其更改为：

SecRuleEngine DetectionOnly

到：

SecRuleEngine On

建议在仅检测模式下运行几天，然后再切换到打开模式。这使您可以在启用主动阻止之前查看日志并识别可能阻止合法流量的任何误报。

配置审核日志设置

此外，配置审核日志设置以进行全面监控。在配置文件的下方（大约第 224 行），找到 SecAuditLogParts 设置。但是，默认配置不会捕获所有有用的交易数据。因此，将行从：

SecAuditLogParts ABDEFHIJZ

到：

SecAuditLogParts ABCEFHJKZ

每个字母代表审核日志的一部分：A（审核日志标头）、B（请求标头）、C（请求正文）、E（响应正文）、F（最终响应标头）、H（带有附加数据的审核日志尾部）、J（上传文件信息）、K（匹配规则）和 Z（最终边界）。此配置提供全面的日志记录，用于分析被阻止的请求和排除误报。保存更改并退出编辑器。

进行这些更改后，重新启动 Apache 以应用配置：

sudo systemctl restart apache2

安装 OWASP 核心规则集

ModSecurity提供了处理安全规则的引擎，但需要一个规则集来识别和阻止威胁。此外，OWASP 核心规则集 (CRS) 是全球 Web 应用程序防火墙使用的行业标准规则集。它提供针对常见攻击媒介的防护，包括 SQL 注入、XSS、本地文件包含和远程代码执行。

虽然 Digitalwave 存储库包含 OWASP CRS 作为打包安装 (modsecurity-crs)，这简化了更新和维护，但您也可以直接从OWASP CRS GitHub 发布页面。本指南介绍了手动安装方法，让您可以完全控制 CRS 版本。

创建CRS目录

首先，创建一个目录来存储 OWASP CRS 文件：

sudo mkdir -p /etc/apache2/modsec/

下载并解压 CRS

接下来，下载最新的稳定 OWASP CRS 版本。截至撰写本文时，版本 4.20.0 是当前的稳定版本。但是，请始终验证最新版本GitHub 发布页面下载前：

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.20.0.tar.gz -O /tmp/coreruleset.tar.gz

下载后，将存档解压到 ModSecurity 目录：

sudo tar -xzf /tmp/coreruleset.tar.gz -C /etc/apache2/modsec/

然后，重命名该目录以便于参考：

sudo mv /etc/apache2/modsec/coreruleset-4.20.0 /etc/apache2/modsec/crs

OWASP CRS 项目每季度以及紧急安全补丁发布时发布更新。订阅GitHub 发布页面接收有关新版本的通知。

配置规则集

CRS 包含一个示例配置文件。复制它以激活规则集：

sudo cp /etc/apache2/modsec/crs/crs-setup.conf.example /etc/apache2/modsec/crs/crs-setup.conf

在 Apache 中启用规则

现在，编辑 ModSecurity Apache 配置以包含 CRS 规则：

sudo nano /etc/apache2/mods-enabled/security2.conf

在文件内，在结束之前添加以下行</IfModule>标签加载CRS配置和规则：

Include /etc/apache2/modsec/crs/crs-setup.conf
Include /etc/apache2/modsec/crs/rules/*.conf

此外，如果存在以下行，请将其注释掉或删除，以防止与手动 CRS 安装发生冲突：

# IncludeOptional /usr/share/modsecurity-crs/*.load

保存文件后，重新启动Apache以加载规则：

sudo systemctl restart apache2

了解 OWASP CRS 配置

OWASP 核心规则集提供了广泛的自定义选项。默认配置为大多数服务器提供可靠的保护，不会阻止合法流量或影响搜索引擎爬虫。本节介绍关键配置概念。

编辑 CRS 配置

打开CRS配置文件以自定义设置：

sudo nano /etc/apache2/modsec/crs/crs-setup.conf

CRS 评分模式

ModSecurity 与 CRS 以两种模式运行：

  • 异常评分模式（默认和推荐）：每条规则匹配都会为异常分数添加分数。处理完所有规则后，如果总分超过阈值，ModSecurity 会触发阻止操作（通常是 403 Forbidden 响应）。此外，此模式提供详细的日志记录，并允许通过分数阈值微调灵敏度。
  • 自包含模式：相反，每个规则独立作用，匹配后可以立即阻止请求。虽然这使用较少的资源，但它提供的灵活性和详细日志较少。因此，规则处理在触发阻止的第一个匹配后停止。

偏执程度

CRS 定义了四个偏执级别，用于控制规则应用的积极程度：

  • 偏执1级（默认）：适用于大多数生产环境，误报率极低。
  • 偏执2级：为需要更高安全性的环境启用附加规则。
  • 偏执狂3级：对于安全关键的应用程序，一些误报是可以接受的。
  • 偏执4级：最高的安全性和最高的误报率。仅在经过大量调整后才适用。

较高的偏执水平会启用更多的规则，增加安全覆盖范围，但也增加了阻止合法请求的可能性。因此，从偏执级别 1 开始，仅在监视日志数周以了解您的流量模式后才增加级别。

测试配置

要验证 ModSecurity 和 OWASP CRS 是否正常工作，请触发测试规则。首先，打开浏览器并访问以下 URL（将 yourdomain.com 替换为您的实际域名）：

https://yourdomain.com/index.html?exec=/bin/bash

如果 ModSecurity 配置正确且 SecRuleEngine 设置为 On，您将收到 403 Forbidden 错误。因此，这确认 CRS 在查询字符串中检测到命令注入尝试并阻止了该请求。

但是，如果您收到正常的页面响应而不是 403 错误，请验证：

  • 在 /etc/modsecurity/modsecurity.conf 中将 SecRuleEngine 设置为 On（不是DetectionOnly）
  • 配置更改后 Apache 重新启动
  • CRS 规则已正确包含在 security2.conf 文件中

管理误报和排除规则

运行 Web 应用程序防火墙时，管理误报是一项持续的任务。 CRS 旨在最大限度地减少默认偏执级别的误报，但某些应用程序或自定义功能可能会错误地触发规则。建议的方法是最初以较低的偏执级别运行，并在调整规则或提高安全级别之前监视日志数周。

特定于应用程序的排除

此外，CRS 还包含常见应用程序的内置排除配置文件。虽然这些默认情况下处于禁用状态，但可以在 crs-setup.conf 文件中启用它们。查找 id:900130 的 SecAction 块：

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

要启用特定应用程序的排除，请取消注释该块并将您使用的应用程序的值设置为 1。例如，要启用 WordPress 和 phpMyAdmin 排除：

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_wordpress=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1"

创建自定义排除规则

对于内置配置文件之外的自定义排除项，请使用 CRS 之前的排除文件。首先，复制示例文件：

sudo cp /etc/apache2/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

然后，编辑文件以添加自定义排除规则：

sudo nano /etc/apache2/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

每个排除规则都需要一个唯一的 ID 号。以下示例演示了常见的排除模式：

从所有规则中排除特定 URL 路径：

SecRule REQUEST_URI "@beginsWith /api/webhook" "id:1001,phase:1,nolog,allow,ctl:ruleEngine=off"

将特定 IP 地址列入白名单：

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" "id:1002,phase:1,nolog,allow,ctl:ruleEngine=off"

将子网列入白名单：

SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8,192.168.0.0/16" "id:1003,phase:1,nolog,allow,ctl:ruleEngine=off"

这些排除规则与用于根据重复的恶意行为创建动态阻止列表。

禁用特定规则

或者，如果特定规则始终导致合法功能误报，您可以针对特定路径而不是全局禁用它们。例如，要禁用管理区域的规则 941000-942999：

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

执行任何排除后，重新启动 Apache 以应用更改：

sudo systemctl restart apache2

监控日志中的误报

为了维持有效的 WAF 配置，定期日志分析至关重要。 ModSecurity 将阻止的请求和规则匹配记录到 /var/log/modsec_audit.log。因此，请查看此日志以识别需要排除规则的模式：

sudo tail -f /var/log/modsec_audit.log

分析日志时，查找经常与合法请求一起出现的规则 ID，并为这些特定场景创建有针对性的排除，而不是全局禁用规则。

配置日志轮转

要有效管理磁盘空间，请为 ModSecurity 审核日志配置日志轮换。由于这些日志在繁忙的服务器上会快速增长，因此实施日志轮换有助于管理磁盘空间并维护可读的日志文件。

首先，为 ModSecurity 创建一个 logrotate 配置文件：

sudo nano /etc/logrotate.d/modsecurity

接下来，添加以下配置：

/var/log/modsec_audit.log {
    rotate 31
    daily
    missingok
    compress
    delaycompress
    notifempty
}

这个配置：

  • 旋转 31：保留 31 天的日志（根据您的保留要求进行调整）
  • 日常的：每天轮换日志
  • 压缩：压缩旋转日志以节省磁盘空间
  • 延迟压缩：延迟压缩直到第二个旋转周期
  • 我失踪了：如果日志文件丢失，不会生成错误
  • 通知空：不轮换空日志文件

结论

ModSecurity 2 与 OWASP 核心规则集提供全面的保护，防止 Debian 服务器上的常见 Web 应用程序攻击。此外，Digitalwave 存储库通过提供最新的软件包简化了安装和维护。当与适当的日志监控和有针对性的排除规则相结合时，此配置为托管任何类型 Web 应用程序的 Apache Web 服务器形成了强大的安全层。

Related articles