在ModSecurity Core Rule Set中为多站点服务器配置规则排除

前言

在管理运行多个网站的服务器时，安全配置往往面临一个挑战：如何为不同网站应用不同的安全规则。本文将详细介绍如何在ModSecurity Core Rule Set（CRS）环境下，为多站点服务器配置针对性的规则排除。

多站点环境下的安全挑战

当服务器运行多个网站时，每个网站可能有不同的安全需求。例如：

• 一个WordPress网站可能需要特定的规则排除来避免误报
• 一个自定义应用可能需要完全不同的安全配置
• 管理界面如phpMyAdmin需要自己的安全规则

如果简单地应用全局规则排除，可能会导致某些网站的安全防护不足，或者某些网站的正常功能被误拦截。

基于主机头的解决方案

基本实现原理

最直接的解决方案是利用HTTP请求中的Host头来区分不同的网站。ModSecurity可以通过检查Host头来决定应用哪些规则排除。

SecRule REQUEST_HEADERS:Host "@streq example1.com" \
    "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"

排除规则的范围控制

为了确保规则排除只应用于特定网站，可以添加反向规则：

SecRule REQUEST_HEADERS:Host "!@streq example1.com" \
    "id:1999,phase:1,pass,t:none,nolog,ctl:ruleRemoveById=1000-1998"

这条规则表示：如果Host头不是example1.com，则移除ID在1000-1998之间的所有规则。

多站点处理

对于多个WordPress站点，可以采用以下方式：

SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \
    "id:9507010,phase:1,pass,nolog,chain"
    SecRule REQUEST_HEADERS:Host "!@streq example1.com" \
        "t:none,chain"
        SecRule REQUEST_HEADERS:Host "!@streq example2.net" \
            "t:none,chain"
            SecRule REQUEST_HEADERS:Host "!@streq example3.xyz" \
                "t:none,setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'"

使用正则表达式简化配置

当多个站点有相似的域名模式时，可以使用正则表达式简化配置：

SecRule REQUEST_HEADERS:Host "!@rx ^wordpress\.example[23]?\.com$" \
    "t:none,setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'"

这条规则会匹配：

• wordpress.example.com
• wordpress.example2.com
• wordpress.example3.com

更优雅的解决方案：SecWebAppID

ModSecurity提供了更专业的解决方案——使用SecWebAppID。这种方法不依赖客户端提供的Host头，而是由服务器端配置决定。

配置方法

1. 在Nginx的server块中设置WebAppID：

server {
    modsecurity_rules 'SecWebAppID wordpress';
    # 其他配置
}

2. 在ModSecurity规则中使用WebAppID：

SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \
    "id:1400,phase:1,pass,nolog,chain"
    SecRule WebAppID "!@streq wordpress" \
        "t:none,setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'"

优势

1. 不依赖客户端提供的Host头，更安全可靠
2. 配置更简洁，不需要复杂的正则表达式或多重链式规则
3. 当域名变更时，只需修改Nginx配置，无需改动安全规则

规则ID规划建议

在多站点环境中，良好的规则ID规划非常重要：

1. 为每个应用分配足够大的ID范围（建议至少1000个ID）
2. 使用有规律的ID分配，例如：
   • 1000-1999：全局规则
   • 2000-2999：应用A
   • 3000-3999：应用B
3. 确保ID范围不与其他规则集冲突

插件配置顺序

在多站点环境中，插件配置的顺序至关重要：

1. 首先加载插件配置（*-config.conf）
2. 然后加载插件前置规则（*-before.conf）
3. 接着加载CRS核心规则
4. 最后加载插件后置规则（*-after.conf）

典型的main.conf配置示例：

Include modsecurity.conf
Include crs-setup.conf

# 插件配置
Include plugins/*-config.conf
Include plugins/*-before.conf

# CRS核心规则
Include rules/*.conf

# 插件后置规则
Include plugins/*-after.conf

最佳实践总结

1. 优先考虑使用SecWebAppID方案，它更安全可靠
2. 如果必须使用Host头方案，确保使用反向规则限制排除范围
3. 为每个应用分配足够的规则ID空间
4. 保持清晰的配置顺序
5. 定期审查规则排除，确保不会过度放宽安全限制

通过以上方法，管理员可以灵活地为多站点服务器中的每个网站配置精确的安全规则，既保证了安全性，又避免了不必要的功能限制。