NGINX/WAF出现 mkdir() “/var/tmp/nginx/client_body “failed(2:No such file or directory)

NGINX/WAF重启mkdir失败问题分析与解决

背景

WAF进行证书替换时,发现部分过滤节点 nginx重启遇到上述异常。

故障定位

1.使用“nginx -V” 查看waf nginx安装时添加的编译参数及配置信息。确认http-client-body-temp-path在编译过程当中配置存储路径,确认是否为安装问题。

http-client-body-temp-path配置说明

对生节点执行“nginx -V”;结果如下:

nginx version: styx2.5.0

built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)

built with OpenSSL 1.1.1  11 Sep 2018

TLS SNI support enabled

configure arguments: --prefix=/usr/local/nginx --sbin-path=/usr/sbin/nginx --conf-path=/usr/local/nginx/waf/nginx_lua.conf --error-log-path=/usr/local/nginx/logs/waf.error.log --http-log-path=/usr/local/nginx/logs/waf.access.log --pid-path=/usr/local/nginx/logs/nginx.pid --lock-path=/var/lock/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_stub_status_module --with-http_sub_module --with-http_gzip_static_module --without-http_upstream_hash_module --with-http_realip_module --with-file-aio --with-ipv6 --with-openssl=/usr/local/soft/waf_package/CNN55XX-SDK/apps/Turbo_SSL/openssl-1.1.1 --with-zlib=../zlib-1.2.8 --with-pcre=../pcre-8.38 --add-module=../ngx_devel_kit-master --add-module=../lua-nginx-module-0.10.12 --add-module=../nginx_upstream_hash-master --add-module=../nginx_upstream_check_module-master --add-module=../ngx_http_dyups_module-master --http-client-body-temp-path=/usr/local/soee/nginx/client_body_temp --http-proxy-temp-path=/usr/local/soee/nginx/proxy_temp --http-fastcgi-temp-path=/usr/local/soee/nginx/fastcgi_temp --http-uwsgi-temp-path=/usr/local/soee/nginx/uwsgi_temp --http-scgi-temp-path=/usr/local/soee/nginx/scgi_temp --with-cc-opt=' -DCAVIUM_SSL -DCAVIUM_ASYNC_SUPPORT -I /usr/local/soft/waf_package/CNN55XX-SDK/include -I/usr/local/soft/waf_package/CNN55XX-SDK/apps/Turbo_SSL/openssl-1.1.1 -I/usr/local/soft/waf_package/CNN55XX-SDK/apps/Turbo_SSL/openssl-1.1.1/ssl' --with-ld-opt='-Wl,-rpath=/usr/local/ssl/lib -L/usr/local/ssl/lib'

通过运维平台确认生产环境部分编辑路径与运维的安装脚本不一致;

运维安装手册对应的“http-client-body-temp-path”配置信息如下,确认生产环境存在该配置存储目录有多个:

--add-module=../ngx_devel_kit-master \
--add-module=../lua-nginx-module-0.10.7 \
--add-module=../nginx_upstream_hash-master \
--add-module=../nginx_upstream_check_module-master \
--add-module=../ngx_http_dyups_module-master \
--http-client-body-temp-path=/usr/local/nginx/client_body_temp \
--http-proxy-temp-path=/usr/local/nginx/proxy_temp \
--http-fastcgi-temp-path=/usr/local/nginx/fastcgi_temp \
--http-uwsgi-temp-path=/usr/local/nginx/uwsgi_temp \
--http-scgi-temp-path=/usr/local/nginx/scgi_temp \

通过对故障节点目录权限的检查,包括编译参数的检查,除发现节点上“http-client-body-temp-path”配置存储路径与运维安装脚本不一致,并未发现异常;

检查运维当晚重启报错故障节点编译配置等

[root@host10108929 ~]# nginx -V

nginx version: styx2.5.0

built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)

built with OpenSSL 1.0.2j  26 Sep 2016

TLS SNI support enabled

configure arguments: --prefix=/usr/local/nginx --sbin-path=/usr/sbin/nginx --conf-path=/usr/local/nginx/waf/nginx_lua.conf --error-log-path=/usr/local/nginx/logs/waf.error.log --http-log-path=/usr/local/nginx/logs/waf.access.log --pid-path=/usr/local/nginx/logs/nginx.pid --lock-path=/var/lock/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_stub_status_module --with-http_sub_module --with-http_gzip_static_module --without-http_upstream_hash_module --with-http_realip_module --with-file-aio --with-ipv6 --with-zlib=../zlib-1.2.8 --with-pcre=../pcre-8.38 --add-module=../ngx_devel_kit-master --add-module=../lua-nginx-module-0.10.7 --add-module=../nginx_upstream_hash-master --add-module=../nginx_upstream_check_module-master --add-module=../ngx_http_dyups_module-master --http-client-body-temp-path=/var/tmp/nginx/client_body --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --http-scgi-temp-path=/var/tmp/nginx/scgi --with-cc-opt='-I/usr/local/ssl/include -Wno-error=deprecated-declarations' --with-ld-opt='-Wl,-rpath=/usr/local/ssl/lib -L/usr/local/ssl/lib'

发现其对应的目录与其他节点目录不一样、其他节点多为/usr/local……,进一步调研分析发现“/var/tmp”因为操作系统内部存在定时任务,其任务当中有脚本会定期清理/var/tmp目录内容,从而导致nginx再一次重启的时候因为该目录下内容被系统清理,从而发生nginx在重启过程当中出现该错误“[emerg] mkdir() "/var/tmp/nginx/client_body" failed (13: Permission denied)”

下面该代码段为cron脚本,默认情况30天清理未使用的文件及目录;

flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
	-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
	-X '/tmp/hsperfdata_*' 10d /tmp
/usr/sbin/tmpwatch "$flags" 30d /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
    if [ -d "$d" ]; then
	/usr/sbin/tmpwatch "$flags" -f 30d "$d"
    fi
done

解决方案:

1.重启的过程当中如果发现类似错误,可以通过重新创建"/var/tmp/nginx/client_body"目录,nginx可以正常运行。但后续该节点可能出现用户上传过大文件丢失等问题。

2.重新安装,通过在编译参数当中自定义指定非/var/tmp目录,避免再被系统清理。如下所示

--add-module=../ngx_devel_kit-master \
--add-module=../lua-nginx-module-0.10.7 \
--add-module=../nginx_upstream_hash-master \
--add-module=../nginx_upstream_check_module-master \
--add-module=../ngx_http_dyups_module-master \
--http-client-body-temp-path=/usr/local/nginx/client_body_temp \
--http-proxy-temp-path=/usr/local/nginx/proxy_temp \
--http-fastcgi-temp-path=/usr/local/nginx/fastcgi_temp \
--http-uwsgi-temp-path=/usr/local/nginx/uwsgi_temp \
--http-scgi-temp-path=/usr/local/nginx/scgi_temp \

3.通过调整nginx.conf配置文件,重新指定“http-client-body-temp-path”配置存储位置,重启nginx后即可,具体配置如下:

http {
    default_type application/octet-stream;
    server_tokens off;
    sendfile on;
    client_max_body_size 200m;
    client_body_buffer_size 4096k;
	client_body_temp_path /usr/local/nginx/client_body_temp;
    client_header_buffer_size 256k;
    large_client_header_buffers 8 256k;

附录

《关于Linux系统中/tmp目录的清除问题》关于Linux系统中/tmp目录的清除问题-优快云博客

《Linux临时目录/tmp与/var/tmp》https://www.cnblogs.com/fuqian/p/17143415.html

《Module ngx_http_core_module》Module ngx_http_core_module

(1)先备份nginx.conf: cd /usr/local/nginx/conf cp ./nginx.conf ./nginx.conf.bak (2)修改nginx.conf中配置modsecurity的内容,将规则目录改为自己的目录(先不用OWASP提供的核心规则文件,减少实验干扰): vi ./nginx.conf 将原内容(位于 http 和 每1个 server 配置之间,大约第18~37行的位置): modsecurity on; modsecurity_rules_file /usr/local/nginx/conf/modsecurity/modsecurity.conf; 改为: modsecurity on; modsecurity_rules_file /usr/local/nginx/conf/my-modsecurity/modsecurity.conf; 保存修改。 紧接着准备用于存放自定义规则配置的目录和modsecurity全局配置文件: mkdir /usr/local/nginx/conf/my-modsecurity echo -n > /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecRuleEngine On" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecRequestBodyAccess On" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecResponseBodyAccess On" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecAuditEngine On" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecAuditLogParts ABIJDEFHZ" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecAuditLogType Serial" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf echo "SecAuditLog /var/log/modsec_audit.log" >> /usr/local/nginx/conf/my-modsecurity/modsecurity.conf (3)修改nginx.conf配置文件,在保留原有1个server站点的基础上再增加1个server站点配置 vi ./nginx.conf 将原内容: #server { # listen 8000; # listen somename:8080; # server_name somename alias another.alias; # location / { # root html; # index index.html index.htm; # } #} 改为: server { listen 8000; # listen somename:8080; # server_name somename alias another.alias; location / { root html2; index index.html index.htm; } } 保存修改。 再创建该站点文件存储根目录和首页: mkdir /usr/local/nginx/html2 echo "<HTML><BODY><h2>This is my website2.</h2></BODY></HTML>" > /usr/local/nginx/html2/index.html 然后,设置主机防火墙允许外部访问该站点所使用的8000端口: 防火墙开放80端口的外部访问(仅需执行一次即可): firewall-cmd --zone=public --add-port=8000/tcp --permanent firewall-cmd --reload 最后,刷新nginx配置: /usr/local/nginx/sbin/nginx -s reload 用浏览器访问:http://服务器IP:8000/ 验证每2个站点网页是否正常显示。 (4)日志清理工作 为避免日志内容过多,干扰实施,清空之前的日志内容: echo -n > /var/log/modsec_audit.log echo -n > /usr/local/nginx/logs/error.log echo -n > /usr/local/nginx/logs/access.log (5)为第1个站点自定义规则,阻止以下xss攻击: http://192.168.80.130/?param=%22%3E%3Cscript%3Ealert(1);%3C/script%3E 准备规则文件:/usr/local/nginx/conf/my-modsecurity/site1-rule.conf 编辑nginx配置文件,将该规则文件只装配到第1个站点上(即在“listen 80;”这行内容下方插入以下一行内容。行末尾的分号不能遗漏): modsecurity_rules_file /usr/local/nginx/conf/my-modsecurity/site1-rule.conf; 规则文件内容:建议自行查阅资料实现。 使用工具检测规则文件格式规范: python3 /opt/coreruleset/util/crs-rules-check/rules-check.py \ -r /usr/local/nginx/conf/my-modsecurity/site1-rule.conf \ -t /opt/coreruleset/util/APPROVED_TAGS -v 4.15.0 规则文件内容参考: SecRule ARGS_GET "@rx (?i)<script[^>]*>[\s\S]*?" \ "id:1001,\ phase:2,\ deny,\ t:none,t:lowercase,\ status:403,\ msg:'XSS Attack Detected in URL Parameter',\ logdata:'Matched Data: %{MATCHED_VAR}',\ tag:'attack-xss',\ severity:'CRITICAL'" 刷新nginx配置: /usr/local/nginx/sbin/nginx -s reload 最后,验证攻击行为是否被有效阻挡。 (6)为第2个站点自定义规则,阻止以下涉嫌敏感信息泄露的请求: http://服务器IP:8000/?username=admin&password=123456 准备规则文件:/usr/local/nginx/conf/my-modsecurity/site2-rule.conf 其它步骤参考为第1个站点自定义规则相关步骤。 【附1】coreruleset项目提供的 rules-check.py Rule检测工具(检测功能强大)安装步骤: 1、进入服务器,先联网安装python3 yum -y install python3 2、进入开源项目coreruleset目录,安装 rules-check 工具依赖的第三方 python 组件包 cd /opt/coreruleset/util/crs-rules-check pip3 install -r ./requirements.txt -i https://mirrors.aliyun.com/pypi/simple 3、规则检测 python3 /opt/coreruleset/util/crs-rules-check/rules-check.py -r /usr/local/nginx/conf/my-modsecurity/site1-rule.conf -t /opt/coreruleset/util/APPROVED_TAGS -v 4.15.0 【附2】modsecurity项目提供的 modsec-rules-check Rule检测工具(简单易用)安装步骤: 1、进入服务器ModSecurity目录,安装其提供的 tools cd /opt/ModSecurity/tools/ make make install 2、规则检测 /usr/local/modsecurity/bin/modsec-rules-check /usr/local/nginx/conf/my-modsecurity/site1-rule.conf
06-28
### 配置 Nginx 的 ModSecurity 模块以阻止 XSS 攻击和敏感信息泄露 为了有效防御 XSS(跨站脚本攻击)和防止敏感信息(如密码)在请求中被泄露,可以通过配置 ModSecurity 模块来实现。ModSecurity 是一个功能强大的 Web 应用防火墙(WAF),支持自定义规则编写,可对 HTTP 请求进行深度检查并阻断恶意流量。 #### 启用 ModSecurity 并加载基础配置 首先,确保已正确安装并启用了 ModSecurity 模块。可以在 Nginx 的 `location` 块中启用 ModSecurity,并指定其主配置文件: ```nginx location / { ModSecurityEnabled on; ModSecurityConfig modsecurity.conf; } ``` 此配置将为该路径下的所有请求启用 ModSecurity 引擎,并加载全局配置文件 `modsecurity.conf` [^1]。 #### 自定义规则阻止 XSS 攻击 在 ModSecurity 中,可通过编写自定义规则检测并拦截包含 `<script>` 标签或其他常见 XSS 载荷的请求。例如,在规则文件中添加如下内容: ```apache SecRule ARGS "<script" "id:1001,phase:2,deny,status:403,msg:'XSS Attack Detected'" ``` 上述规则会在请求参数中检测到 `<script` 字符串时触发阻断操作,返回 403 状态码并记录日志。可根据实际需求调整正则表达式以覆盖更多 XSS 变种攻击形式 [^1]。 #### 防止敏感信息泄露(如密码) 为了防止用户在 URL 参数中传输密码等敏感字段,可以使用以下规则检测请求参数中的关键词: ```apache SecRule ARGS "(password|passwd|pass)=.*" "id:1002,phase:2,deny,status:403,msg:'Password leakage attempt detected'" ``` 该规则会检测请求参数中是否包含类似 `password=xxx` 的字段,并在匹配成功时拒绝请求。建议结合审计日志分析工具进一步确认潜在威胁 [^2]。 #### 测试验证规则是否生效 完成配置后,重新加载 Nginx 服务以应用新规则: ```bash nginx -t && systemctl reload nginx ``` 随后,可以使用以下测试 URL 来验证规则是否能够成功拦截 XSS 和敏感信息泄露请求: - **XSS 攻击测试:** ```bash curl -v "http://服务器IP/?param=%22%3E%3Cscript%3Ealert(1);%3C/script%3E" ``` - **密码泄露测试:** ```bash curl -v "http://服务器IP/?password=123456" ``` 预期结果是返回 HTTP 403 状态码,且 ModSecurity 日志中记录了相关事件信息。通过查看 `/var/log/modsec_audit.log` 文件,可以确认规则是否被正确触发 [^2]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

慢跑的华哥

一杯咖啡可以吸收宇宙的能量

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值