ModSecurity3_Nginx 指南

2019-02-13  本文已影响0人  猪蹄胖

如何在企业中应用ModSecurity，整理相关有用的要点，用于理解和调试

一、介绍

image.png

ModSecurity一开始有上图这哥们为了保护几个web应用程序而创建的，通过嵌入到web容器中，分析数据，阻挡恶意攻击，最初是Apache HTTP的插件。

作为WAF产品，ModSecurity专门关注HTTP流量，当发出HTTP请求时，ModSecurity检查请求的所有部分，如果请求被认为是恶意的，它可以被阻止、记录或同时记录，这取决于配置。

ModSecurity3.0 新的体系结构

image.png

警告说明

ModSecurity3.0 暂时还没有与上一个版本ModSecurity2.9进行功能对比，需要注意一下限制:

二、安装ModSecurity

使用nginx plus的好处

ModSecurity 3.0 for NGINX Plus被称为NGINX WAF，商业订阅有很多好处:

nginx源码编译

在nginx 1.11.5或更高版本中，可以直接通过编译动态模块，不需要重新编译nginx二进制文件，直接将动态模块加载到nginx配置中进行引用。

1、从nginx官方存储库下载安装

从官网下载源码：https://nginx.org
nginx版本1.11.5或更高版本（使用nginx动态模块）

2、安装依赖包

yum install epel-release
yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre pcre-devel libxml2 libxml2-devel autoconf automake lmdb-devel ssdeep-devel ssdeep-libs lua-devel libmaxminddb-devel git

3、下载编译libmodsecurity

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity
cd ModSecurity
git submodule init
git submodule update $ ./build.sh
./configure
make
make install

编译时间大概15分钟，取决于系统性能

4、下载nginx连接器源码，并编译成动态模块

git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

nginx -v
nginx version: nginx/1.13.7

wget http://nginx.org/download/nginx-1.13.7.tar.gz 
tar zxvf nginx-1.13.7.tar.gz

cd nginx-1.13.7
./configure --with-compat --add-dynamic-module=../ModSecurity-nginx $ make modules
cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules

5、加载nginx连机器动态模块

load_module modules/ngx_http_modsecurity_module.so;

nginx在读取配置时，会加载动态模块

Nginx Plus 安装说明

介绍如何安装NGINX web application firewall(WAF)。NGINX WAF构建在ModSecurity 3.0之上
NGINX WAF可以作为一个下载的动态模块提供给NGINX Plus客户，购买或开始免费试用NGINX WAF
先决条件：https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/

安装Nginx WAF

yum install nginx-plus-module-modsecurity

load_module modules/ngx_http_modsecurity_module.so;

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok 
nginx: configuration file /etc/nginx/nginx.conf test is successful

验证安装

配置本地demo程序

server {
    listen localhost:8085;
    location / {
        default_type text/plain;
        return 200 "Thank you for requesting ${request_uri}\n";
    } 
}

测试

nginx -s reload
curl -D - http://localhost:8085 HTTP/1.1 200 OK
#Server: nginx/1.11.10
#Date: Wed, 3 May 2017 08:55:29 GMT Content-Type: text/plain Content-Length: 27
#Connection: keep-alive 
Thank you for requesting /

配置nginx反向代理

server { 
    listen 80;
    location / {
    proxy_pass http://localhost:8085; proxy_set_header Host $host;
    } 
}

测试

nginx -s reload
curl -D - http://localhost HTTP/1.1 200 OK
#Server: nginx/1.11.10
#Date: Wed, 3 May 2017 08:58:02 GMT Content-Type: text/plain Content-Length: 27
#Connection: keep-alive 
Thank you for requesting /

开启SecRuleEngine，并且测试

# A test rule
SecRule ARGS:testparam "@contains test" "id:1234,deny,log,status:403"

三、安装OWASP Core Rule Set

CRS文件和目录结构

CRS的主配置文件定义了异常评分阈值、偏执级别和其他重要的ModSecurity配置
规则/ 目录包含组织成不同文件的规则，每个文件都有一个分配给它的编号

异常得分
CRS使用可配置的异常计分模型，每条触发的规则都会增加异常分数，如果分数超过配置的异常阈值，则事务被阻塞，异常级别如下:

使用Nikto工具

使用Nikto扫描工具生成恶意请求

git clone https://github.com/sullo/nikto Cloning into 'nikto'...
cd nikto
perl program/nikto.pl -h localhost
- Nikto v2.1.6
...
+ 7531 requests: 0 error(s) and 324 item(s) reported on remote host

接下来，我们启用CRS，然后测试它如何阻塞Nikto的大多数请求，从而减少报告的项目数量

安装并启动OWASP CRS

wget https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/ v3.0.0.tar.gz
tar -xzvf v3.0.0.tar.gz
mv owasp-modsecurity-crs-3.0.0 /usr/local
cd /usr/local/owasp-modsecurity-crs-3.0.0
cp crs-setup.conf.example crs-setup.conf

添加包括指令在主ModSecurity配置文件/etc/nginx/modsec/main

# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf
# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs-3.0.0/crs-setup.conf Include /usr/local/owasp-modsecurity-crs-3.0.0/rules/*.conf

nginx -s reload

Testing the CRS

了解CRS中的规则如何基于请求的特定特征来阻止Nikto的请求，我们的最终目标是显示CRS阻止Nikto的所有请求，这样Nikto检测到的所有漏洞都不会被攻击者利用

基于用户代理头禁用请求阻塞

CRS识别来自扫描仪(包括Nikto)的请求，通过检查用户代理报头，CRS被预先配置为阻止具有Nikto默认用户代理报头的请求。

curl -H "User-Agent: Nikto" http://localhost/ 
<html>
<head><title>403 Forbidden</title></head> 
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center> 
<hr><center>nginx/1.11.10</center> 
</body>
</html>

可以从日志中得知是关联了哪个规则集REQUEST-913-SCANNER- DETECTION.conf

消除对易受攻击文件的请求

当我们对web应用程序重新运行Nikto时，我们看到只有116个Nikto请求到达应用服务器，而没有启用CRS时只有324个，这表明CRS保护我们的应用程序免受Nikto请求暴露的大部分漏洞的影响

perl program/nikto.pl -h localhost
...
+ 7531 requests: 0 error(s) and 116 item(s) reported on remote host

可以通过在program/ nikto中添加-sitefile来更好地了解实际漏洞可能存在的地方，从而禁用这些请求。

# Default plug-in macros
# Remove plug-ins designed to be run standalone 
@@EXTRAS=dictionary;siebel;embedded 
@@DEFAULT=@@ALL;-@@EXTRAS;tests(report:500);-sitefiles

使用XSS尝试阻塞请求

perl program/nikto.pl -h localhost
- Nikto v2.1.6
...
+ 7435 requests: 0 error(s) and 26 item(s) reported on remote host

这26项中的大多数出现是因为OWASP CRS当前没有配置为阻止请求URL中包含XSS尝试的请求

<script>alert('Vulnerable')</script>

为了阻止尝试XSS的请求，在CRS的XSS应用程序攻击规则集request-941-Application-Attack-xsd.conf中，通过在每个规则的变量列表的开头添加REQUEST_URI，编辑规则941160和941320:

SecRule REQUEST_URI|REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/ ...
##重新加载nginx
nginx -s reload

重新运行nikto，会发现items变少了，然后根据日志信息，重新优化规则集

不支持检查响应体，因此配置这样的规则没有效果

四、安装Trustwave SpiderLabs 商业安全规则集

除了OWASP CRS之外，Trustwave SpiderLabs商业规则集还提供了其他保护，例如针对WordPress、Joomla、SharePoint和其他应用程序的特定规则集。

本章介绍Trustwave SpiderLabs商业规则集的安装，以安装ModSecurity的基本配置为基础，展示如何配置Trustwave SpiderLabs规则来保护创建的演示web应用程序

image.png

先决条件

配置Trust SpiderLabs规则

购买规则后，可以直接登入modsecurity的dashboard，然后在门户上定制Trustwate SpiderLabs规则，与OWASP CRS相比通过这个仪表盘简化了配置。

dashboard.modsecurity,org
需要账号密码登入，无法注册，需要付费购买。

配置向导

为web系统配置waf

Include "/etc/nginx/modsec/modsecurity.conf"
SecRemoteRules license-key https://url

SecDefaultAction "phase:2,log,auditlog,deny,status:403" 
SecDefaultAction "phase:1,log,auditlog,deny,status:403"

从Trustwave SpiderLabs下载规则需要注意一下几点

限制

不支持检查响应体

五、开启项目蜜罐

Project Honeypot维护一个已知恶意IP地址的列表，免费提供给公共ModSecurity与Project Honeypot集成，可以自动屏蔽Project Honeypot列表上的IP地址，这个过程称为IP信誉

蜜罐是如何工作的

项目蜜罐是一个社区维护的IP地址在线数据库，怀疑是垃圾邮件发送者或机器人，每个IP地址被分配一个威胁得分在0到255之间;数字越高，IP地址越有可能是恶意的。

搭建蜜罐

要开始使用项目蜜罐，请使用项目蜜罐提供的脚本在您的站点上设置一个蜜罐:

server {
    server_name www.example.com;

    location ~ \.php$ { 
        modsecurity off;
        root /code;
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass localhost:9000;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_ script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info; 
    }
}

Notes:

将蜜罐链接添加到所有页面

为了捕捉机器人和扫描器，在每个页面上插入一个到蜜罐脚本的链接，这个链接对于使用web浏览器的普通人是不可见的，但是对于机器人和扫描器是可见的，我们使用sub_filter指令将链接添加到每个页面的底部:

location / {
    proxy_set_header Host $host; 
    proxy_pass http://my_upstream;
    sub_filter '</html>'
                '<a href="http://www.example.com/test.php"> 
                <!-- hightest --></a></html>';
}

在核心规则集中启用IP信誉

SecHttpBlKey my_api_key SecAction "id:900500,\
phase:1,\
nolog,\
pass,\
t:none,\
:tx.block_search_ip=0,\    ##禁用了block_search_ip，不阻止搜索引擎爬行器
setvar:tx.block_suspicious_ip=1,\ 
setvar:tx.block_harvester_ip=1,\ 
setvar:tx.block_spammer_ip=1"

验证测试

自定义规则添加到/etc/nginx/modsec/main.conf
它将作为请求的一部分传入的IP地址参数的值发送给Project Honeypot

SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny, nolog,auditlog,msg:'RBL Match for SPAM Source'

运行curl命令来测试规则，如果IP地址已经被加入到蜜罐中，这个请求将被阻塞，状态码403

结论

Project Honeypot是一个非常有用的工具，可以自动屏蔽已知的恶意IP地址

六、日志

审计日志

ModSecurity会记录出发告警或错误日志，以及导致5xx和4xx响应的事务，不记录404，ModSecurity审计日志划分为以下几个部分：

阶段 描述
A 审计日志标题
B 请求头
C 请求体
D 保留
E 响应体
F 响应头
G 保留
H 审计日志流，包含其他数据
I 紧凑的请求主体替代C阶段部分，不包含文件
J 文件上传信息
K 包含于事务匹配的所有规则列表
Z 最后的边界

触发审计日志的条目的每个事物记录，都将记录在上述指定部分，记录哪些阶段可以选择性配置

配置审计日志

默认审计日志配置文件：/etc/nginx/modsec/modsecurity.conf

SecAuditEngine RelevantOnly

控制选项

SecAuditLogRelevantStatus "^(?:5|4(?!04))"

SecAuditLogRelevantStatus
如果SecAuditEngine被设置为RelevantOnly，那么这个指令将控制应该记录哪些HTTP响应状态代码。它是基于正则表达式的，上面的值将记录所有5xx和4xx响应，不包括404s

SecAuditLogParts ABIJDEFHZ

SecAuditLogParts
控制访问日志中应该包含哪些部分，只选择需要的部分，减少审计日志的大小

调试日志

debug log主要用于modscurity的调试，调试日志包含了modsecurity对事务的所有操作，调试日志列出了规则ID，可以根据规则ID进行快速查找故障

[4] (Rule: 1234) Executing operator "Contains" with param "test" against ARGS:testparam.
[9] Target value: "test" (Variable: ARGS:testparam) [9] Matched vars updated.
[4] Running [independent] (non-disruptive) action: log [9] Saving transaction to logs
[4] Rule returned 1.
[9] (SecDefaultAction) Running action: log
[9] Saving transaction to logs
[9] (SecDefaultAction) Running action: auditlog
[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)
[4] Running (non-disruptive) action: auditlog [4] Running (disruptive) action: deny

配置调试日志

默认调试日志禁用，因为会造成大量日志，影响系统运行，配置文件/etc/nginx/modsec/ modsecurity.conf

SecDebugLog /var/log/modsec_debug.log 
SecDebugLogLevel 9

七、在生产环境中使用ModSecurity的注意点

将ModSecurity部署应用到生产环境之前，需要完成以下几点配置

调优以最小化原则为准

SecAction \ "id:900110,\
phase:1,\ß
nolog,\
pass,\
t:none,\ setvar:tx.inbound_anomaly_score_threshold=1000,\
setvar:tx.outbound_anomaly_score_threshold=1000"

SecRemoveRuleByID rule-id

禁用审计日志

默认ModSecurity配置中启用了审计日志记录，但是在生产环境中需要禁用，有如下原因：

禁用审计日志：

SecAuditEngine off

通过使用Nginx原生的错误日志记录功能，记录所有被阻塞的事务（ModSecurity必须处于阻塞模式，否则没日志）

error_log  logs/error.log   error

不检查静态内容

分离出静态图像文件,以便ModSecurity不检查：

server { 
    listen 80;
    location / { modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/main.conf; proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
}
    location ~ \.(gif|jpg|png|jpeg|svg)$ {
        root /data/images; 
    }
}

建议对静态文件设置proxy_cache

Nginx限制DDOS和限制速率

ModSecurity动态模块目前不支持内置的CRS规则DDoS mitigation (REQUEST-912-DOS-PROTECTION.conf)，但是静态编译的支持。
举例：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server { 
    listen 80;
    location / {
        limit_req zone=mylimit;
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/main.conf; proxy_pass http://localhost:8085;
        proxy_set_header Host $host;
    } 
}

其他注意点

下面是一些在你使用ModSecurity进行生产时需要考虑的提示和技巧:

完成以上配置，可以提高ModSecurity使用中的性能，减少误报，充分利用ModSecurity和nginx

上一篇下一篇

猜你喜欢

热点阅读