Red Hat JBoss 核心服务 ModSecurity 指南

Red Hat JBoss Core Services 2.4.51

用于 Red Hat JBoss Middleware 产品。

Red Hat Customer Content Services

摘要

本书是使用 Red Hat JBoss Core Services Mod Security 模块的指南。

对红帽文档提供反馈

要报告错误或改进文档,请登录到 Red Hat JIRA 帐户并提交问题。如果您没有 Red Hat Jira 帐户,则会提示您创建一个帐户。

流程

  1. 单击以下链接 以创建 ticket
  2. Summary 中输入问题的简短描述。
  3. Description 中提供问题或功能增强的详细描述。包括一个指向文档中问题的 URL。
  4. Submit 创建问题,并将问题路由到适当的文档团队。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

第 1 章 ModSecurity 简介

1.1. 概述

本指南包括用于 Red Hat JBoss Core Services 2.4.51 的 ModSecurity v2.9 模块的信息和示例。ModSecurity 的有效性基于用户生成的规则。因此,本指南将说明如何创建和实施规则,但不会为您提供一组要使用的规则。

1.2. ModSecurity

ModSecurity 是一个 Web 应用程序防火墙(WAF)。Web 应用程序防火墙过滤、监控和阻止 HTTP 流量到 Web 应用。与常规防火墙不同,WAF 使用过滤器来确定与 HTTPD 服务器应用程序交互的内容和人员。ModSecurity 通过使用用户生成的安全规则,完成此任务。这些规则允许对 HTTP 流量进行可配置的实时监控,以便立即检测攻击。

第 2 章 ModSecurity 配置

2.1. RHEL 配置

2.1.1. 依赖项

ModSecurity 有几个依赖项才能正常工作。其中一些已包含在 Red Hat JBoss Core Services 中。下面提供了完整的列表:

依赖项JBCS 的一部分

Apache Portable Runtimes

Y

APR-Util

Y

mod_unique_id

Y

libcurl

Y

PCRE

Y

libxml2

N

Lua5.x

N

注意

Red Hat JBoss Core Services for windows 包含 libxml2 和 Lua5.x

2.1.2. 使用 Red Hat JBoss Core Services 安装

ModSecurity 作为 Red Hat JBoss Core Services 软件包的一部分。有关安装 Red Hat JBoss Core Services 的完整说明 ,请参阅 JBCS 安装指南

2.1.3. 初始配置

ModSecurity 作为 Red Hat JBoss Core Services 的一部分。这意味着 ModSecurity 预配置了,您不必使用 apxs 工具来构建和安装模块。为了进一步配置 Mod_sec,必须将模块加载到 HTTPD 中。

2.1.3.1. 启动 ModSecurity

在载入 ModSecurity 模块前,您必须加载 libxml2 和 lua5.1 库。使用以下命令载入库:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so

然后,使用以下方法载入 ModSecurity 模块:

LoadModule security2_module modules/mod_security2.so

2.1.3.2. 配置规则文件夹

ModSecurities 功能的后端是创建系统使用的规则。但是,我们必须知道存储规则的位置才能使用它们。JBCS 附带一个预配置的文件夹,位于 HTTPD_HOME/modsecurity.d。您可以将规则存储在这个文件夹中,或者位于其下的 activated_rules 文件夹。

此外,要使用这些规则,我们必须将 mod_security.conf.sample 文件设置为我们的规格。最重要的是,您需要将 文件名更改为 mod_security.conf。这可以通过以下命令完成:

mv mod_security.conf.sample ./mod_security.conf

在文件本身中,您可以为用于 ModSecurity 规则的所有配置指令设置参数。

2.1.3.3. PCRE Warning

您希望避免 Apache 使用捆绑的 PCRE 库,以及对操作系统提供的 ModSecurity 链接。执行此操作的最简单方法是根据操作系统提供的 PCRE 库编译 Apache (或者,您可以根据您从主 PCRE 发行版站点下载的最新 PCRE 版本编译它)。您可以使用 --with-pcre 开关进行配置。如果您没有重新编译 Apache 的位置,那么为了成功编译 ModSecurity,您仍需要访问捆绑的 PCRE 标头(它们只在 Apache 源代码中可用),并更改包含 ModSecurity 的路径(如上面第 7 步中的操作)指向它们(通过 --with-pcre ModSecurity 配置选项)。请注意,如果您的 Apache 使用外部 PCRE 库,您可以使用 WITH_PCRE_STUDY 编译 ModSecurity,这可能会给您在正则表达式处理中小的性能边缘。非gcc 编译器可能会有问题,因为当前构建系统围绕 gcc 编译器设计,一些编译器/链接标志可能有所不同。要使用非gcc 编译器,您可能需要一些手动 Makefile tweaks,如果无法通过导出自定义 CFLAGS 和 CPPFLAGS 环境变量来解决问题。

2.1.3.4. 主要配置选项

enable-pcre-jit: 启用来自 pcre >= 8.20 的 JIT 支持,可以提高正则表达式性能。

enable-lua-cache: 启用 lua vm 缓存,它可以提高 lua 脚本性能。如果 ModSecurity 必须为每个事务运行多个脚本,会出现不同的区别。

enable-request-early: On ModSecurity 2.6 阶段已移到阶段 2 hook 中,如果您要使用此选项。

enable-htaccess-config :在设置了 AllowOverride Options 时,它将允许将以下指令用于 .htaccess 文件

2.2. Windows 配置

2.2.1. Windows 依赖项

ModSecurity 在 Windows 上有多个依赖项才能正常工作。其中一些已包含在 Red Hat JBoss Core Services 中。下面提供了完整的列表:

依赖项Windows 上 JBCS 的一部分

Apache Portable Runtimes

Y

APR-Util

Y

mod_unique_id

Y

libcurl

Y

PCRE

Y

libxml2

Y

Lua5.x

Y

2.2.2. Windows 安装

在窗口上运行 ModSecurity 所需的许多项目已包含在 JBCS 软件包中。但是,为了使 ModSecurity 正常工作,必须满足特定的条件。确保从源构建软件的目录包含您用于构建 Apache Web 服务器和 ModSecurity 源的 Apache 源。例如:

  • Apache 源位于 C:\ sourceDirectory\httpd-2.4.51
  • Apache 已安装 C:\Apache2451
  • ModSecurity 源位于 C:\ sourceDirectory\mod_security

在这种情况下,sourceDirectory 是与项目结合使用的通用目录。

另外,请确保您的构建环境具有正确的设置。PATH 环境变量必须包含 Visual Studio 变量,如 vsvars32.bat AND 和 CMAKE bin\ 目录所设置的。最后,将 和 环境变量设置为 Apache 源代码目录: C:\ sourceDirectory\httpd-2.4.51

确定您满足上述条件后,您可以将 JBCS 安装到 C: 驱动器上的相应位置。

ModSecurity 作为 Red Hat JBoss Core Services 软件包的一部分。有关安装 Red Hat JBoss Core Services 的完整说明 ,请参阅 JBCS 安装指南

2.2.3. Windows 配置

2.2.3.1. 启动 ModSecurity

在载入 ModSecurity 模块前,您必须加载 libxml2 和 lua5.1 库。使用以下命令载入库:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so

然后,使用以下方法载入 ModSecurity 模块:

LoadModule security2_module modules/mod_security2.so

2.2.3.2. 配置规则目录

ModSecurities 功能的后端是创建系统使用的规则。但是,我们必须知道存储规则的位置才能使用它们。JBCS 附带一个预配置的位于 HTTPD_HOME/modsecurity.d 的目录。您可以将规则存储在这个目录中,或者它下的 activated_rules 目录。

此外,要使用这些规则,我们必须将 mod_security.conf.sample 文件设置为我们的规格。最重要的是,您需要将 文件名更改为 mod_security.conf

2.2.3.3. 主要配置选项

enable-pcre-jit: 启用来自 pcre >= 8.20 的 JIT 支持,可以提高正则表达式性能。

enable-lua-cache: 启用 lua vm 缓存,它可以提高 lua 脚本性能。如果 ModSecurity 必须为每个事务运行多个脚本,会出现不同的区别。

enable-request-early: On ModSecurity 2.6 阶段已移到阶段 2 hook 中,如果您要使用此选项。

enable-htaccess-config :在设置了 AllowOverride Options 时,它将允许将以下指令用于 .htaccess 文件

第 3 章 ModSecurity Rules Making

3.1. 配置示例

3.1.1. 背景信息

configuration Directives : ModSecurity 的配置指令与 Apache 服务器指令类似。大多数 ModSecurity 指令可以在各种 Apache 范围指令内使用。但是,还有其他一些,它们只能在主配置文件中使用一次。这些规则以及核心规则文件应包含在 httpd.conf 文件之外的文件中,并使用 Apache "Include" 指令调用。这样可以更轻松地更新/迁移规则。此文档的参考部分可找到配置指令的完整列表:

3.2. 规则示例

3.2.1. 背景信息

ModSecurity 主要可在用户创建自定义规则时正常工作。这些自定义规则指定在运行时对 Mod_sec 检查的内容。规则在 Apache 请求周期的 5 个阶段实施。五个阶段及其语法名称如下:

请求标头 → REQUEST_HEADERS

请求正文 → REQUEST_BODY

响应标头 → RESPONSE_HEADERS

响应正文 → RESPONSE_BODY

Logging → LOGGING

3.2.2. 规则 1 示例:

本节解释了一个自定义规则示例。提供的自定义规则检查请求是否更改了历史记录。通常,规则有 4 个部分:配置指令、变量、运算符和操作。如需配置指令、变量、运算符和转换/操作的完整列表,请参阅本指南的参考部分。该规则如下:

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

规则以 SecRule 开始。这是一个配置指令,它会创建一个规则,该规则将使用所选操作器分析所选变量。您的大多数规则都将使用此配置指令。

然后,该规则将继续执行变量: REQUEST_URI 此变量包含查询字符串数据在内的完整请求 URL。

接下来,Operator 被定义为 "@streq /index.php"。 @streq 会检查字符串值等于 /index.php 文件。但是,在发生这种情况前,我们的转换/操作将发生。它们被定义为 "id:1,phase:1,t:lowercase,deny "。在这个命令中,规则在阶段 1 中获取 HTTP 请求的 URI 部分,并将值转换为小写。然后,它会检查转换的值以查看它是否等于 /index.php。如果等同于,Modsecurity 将拒绝请求,且不会处理进一步的规则。

3.2.3. 规则 2 示例:

本节解释了更复杂的示例规则。提供的自定义规则检查请求是否更改了历史记录。通常,规则有 4 个部分:配置指令、变量、运算符和操作。如需配置指令、变量、运算符和转换/操作的完整列表,请参阅本指南的参考部分。该规则如下:

SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attack detected'

规则以 SecRule 开始。这是一个配置指令,它会创建一个规则,该规则将使用所选操作器分析所选变量。您的大部分规则都将使用此配置指令。

然后,该规则会继续执行变量: REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS 在这里有 4 个变量,每个变量定义了规则检查的不同部分。

接下来,为请求定义 operator。在本例中,规则检查 JS 方法 history.pushstate ()history.replacestate ()。假设已找到这些值,最后一个部分将执行。

最后一个部分定义将要发生的转换和操作。在这种情况下,它首先定义规则发生的处理阶段。然后,它运行 拒绝logmsg 操作。拒绝 将停止规则处理并截获事务。log 将指示需要创建一个日志。msg 将输出带有日志的消息。消息被定义为 'history-based attacks detected'。

第 4 章 ModSecurity 参考

4.1. 附录

本节包含 SpiderLabs 提供的 ModSecurity 文档的重要引用。它有指向用于创建规则的以下项目的完整列表:

4.1.1. Actions

Actions

4.1.2. 配置指令

配置指令

4.1.3. Operator

Operator

4.1.4. 转换功能

转换功能

4.1.5. 变量

变量

法律通告

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.