1. 项目概述为什么选择Naxsi作为你的第一道防线如果你负责过线上Web服务的运维或安全大概率经历过这样的深夜告警某个不起眼的URL参数里被塞进了一串union select或者一个看似正常的POST请求体里藏了段scriptalert(1)/script。传统的网络防火墙对这类应用层攻击基本是“睁眼瞎”这时候你就需要一个专业的Web应用防火墙。市面上的商业WAF方案功能强大但价格也相当“美丽”对于很多初创团队或预算有限的项目来说直接劝退。Naxsi的出现很大程度上解决了这个痛点。它不是一个新的、独立的服务而是作为Nginx的一个模块来工作你可以把它理解成给Nginx这个“超级门卫”配上了一双“火眼金睛”和一套“格斗术”。Naxsi的核心是一个规则引擎通过分析HTTP请求的各个部分URL、参数、Header、Body与内置的恶意特征库进行匹配从而拦截SQL注入、跨站脚本、目录遍历等常见Web攻击。我最早在为一个内部管理系统做安全加固时接触到它当时的需求很简单零预算、快速上线、规则可控。Naxsi完美契合从研究到基本规则上线确实在10分钟左右就搞定了基础防护。那么谁适合看这篇教程我认为主要是三类人一是中小企业的运维或开发工程师需要快速为自有业务增加一道安全门槛二是个人项目或博客站长希望用最低成本提升站点安全性三是安全爱好者或学生想亲手搭建并理解WAF的工作原理。通过接下来的步骤你不仅能快速搭起一个可用的Naxsi更能理解其背后的拦截逻辑和调优方法做到知其然也知其所以然。2. 核心架构与工作原理拆解在动手安装之前花几分钟理解Naxsi是怎么工作的对于后续的规则调试和问题排查有巨大帮助。很多人在配置时踩坑根源在于把它当成了一个“黑盒”。2.1 Naxsi与Nginx的关系模块化安全Naxsi不是一个独立运行的后台服务这一点和ModSecurity等有些不同。它完全以模块的形式编译进Nginx。这意味着所有的流量过滤动作都发生在Nginx处理请求的生命周期内通常是NGX_HTTP_ACCESS_PHASE阶段。这种深度集成带来了两个直接好处首先是性能损耗极低因为不需要在进程间进行IPC通信其次是配置管理统一所有WAF相关的规则都写在Nginx的配置文件中维护起来非常方便。它的工作流程可以简化为“解析-匹配-裁决”三步。当一个HTTP请求到达Nginx时Naxsi模块会激活对请求行、请求头、请求体如果存在进行解析将其中的“元素”提取出来比如一个查询参数id1会被解析成id和1。然后这些元素会与内部规则我们称之为CheckRule进行匹配。匹配并非简单的字符串比对而是使用了自家的一套语法可以识别各种编码变形和攻击特征。2.2 规则引擎打分制与白名单机制这是Naxsi设计上最巧妙也最需要理解的部分。它采用了一种“负面安全模型”与“打分制”结合的策略。负面安全模型默认情况下它不知道什么是“好”的请求但它定义了大量什么是“坏”的请求特征。这些特征就是内置的规则集每条规则对应一种攻击模式并有一个分数称为score。例如检测到SQL注释符--的规则#1000可能计5分检测到union select的规则#1302可能计8分。打分制每个HTTP请求初始分数为0。当请求中的元素触发某条规则时就累加对应的分数。Naxsi为不同的检查目标如ARGS参数、BODY请求体、URL等分别设置一个分数阈值如$SQL: 8。只要任何一个目标的累计分数超过了其阈值整个请求就会被拦截。这种设计非常灵活。比如一个简单的单引号可能只触发低分规则但如果是id1 union select就会同时触发单引号和union select规则分数累加后很容易就超过$SQL阈值从而被拦截。但只有负面清单会误杀很多正常业务。比如一个博客的搜索功能用户输入test带个单引号是可能的但这会触发SQL注入规则。为此Naxsi引入了白名单机制。白名单不是简单地关闭某条规则而是精确地描述“在某个特定位置如特定的URL、特定的参数名允许出现哪些特征”。白名单的编写是Naxsi配置中最核心、最具技巧性的部分后面我们会详细展开。2.3 学习模式 vs. 拦截模式为了降低部署难度Naxsi提供了“学习模式”。在此模式下即使请求分数超标也不会真正拦截而是会将触发的规则详情记录到日志中。这相当于让Naxsi在线上环境“观摩学习”一段时间收集所有可能触发告警的正常请求模式。运维人员可以基于这些日志分析、提炼出精确的白名单规则。待白名单完善后再切换到“拦截模式”实现安全防护且不影响业务。强烈建议任何新业务上线Naxsi都必须先经过学习模式。3. 环境准备与Naxsi安装理论清楚了我们开始动手。目标是10分钟内从零搭建一个具备基础防护能力的Naxsi。我将以最常见的Ubuntu 20.04 LTS系统为例其他Linux发行版步骤类似主要是包管理器的区别。3.1 系统与Nginx基础环境检查首先确保你的系统已更新并安装了编译所需的工具链。sudo apt update sudo apt upgrade -y sudo apt install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev检查是否已有Nginx。如果有需要确认其版本和编译参数因为我们需要用相同的参数重新编译以添加Naxsi模块。nginx -V 21 | head -n 1这个命令会输出Nginx的版本和一大堆--with-xxx参数。把这些参数完整地复制保存下来至关重要如果系统没有安装Nginx则跳过此步。3.2 获取Naxsi源码并与Nginx整合我们不直接从仓库安装nginx-naxsi包因为那个包版本可能较旧。我推荐从源码编译这样版本可控也更灵活。下载Nginx稳定版和Naxsi源码# 创建一个工作目录并进入 mkdir ~/naxsi-build cd ~/naxsi-build # 下载Nginx源码以1.24.0为例请替换为最新稳定版 wget http://nginx.org/download/nginx-1.24.0.tar.gz tar -zxvf nginx-1.24.0.tar.gz # 下载Naxsi源码 wget https://github.com/nbs-system/naxsi/archive/refs/tags/1.3.tar.gz -O naxsi-1.3.tar.gz tar -zxvf naxsi-1.3.tar.gz编译并安装带Naxsi模块的Nginxcd nginx-1.24.0 # 配置编译参数。这里是最关键的一步。 # 如果你之前没有安装过Nginx使用一套基础参数即可。 # 如果你已有Nginx必须将之前nginx -V输出的所有--with-xxx、--add-module等参数都加上。 # 以下是一个基础示例请务必根据你的实际情况调整。 ./configure \ --prefix/etc/nginx \ --sbin-path/usr/sbin/nginx \ --modules-path/usr/lib/nginx/modules \ --conf-path/etc/nginx/nginx.conf \ --error-log-path/var/log/nginx/error.log \ --http-log-path/var/log/nginx/access.log \ --pid-path/var/run/nginx.pid \ --lock-path/var/run/nginx.lock \ --http-client-body-temp-path/var/cache/nginx/client_temp \ --http-proxy-temp-path/var/cache/nginx/proxy_temp \ --http-fastcgi-temp-path/var/cache/nginx/fastcgi_temp \ --http-uwsgi-temp-path/var/cache/nginx/uwsgi_temp \ --http-scgi-temp-path/var/cache/nginx/scgi_temp \ --usernginx \ --groupnginx \ --with-compat \ --with-file-aio \ --with-threads \ --with-http_addition_module \ --with-http_auth_request_module \ --with-http_dav_module \ --with-http_flv_module \ --with-http_gunzip_module \ --with-http_gzip_static_module \ --with-http_mp4_module \ --with-http_random_index_module \ --with-http_realip_module \ --with-http_secure_link_module \ --with-http_slice_module \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-http_v2_module \ --with-mail \ --with-mail_ssl_module \ --with-stream \ --with-stream_realip_module \ --with-stream_ssl_module \ --with-stream_ssl_preread_module \ --with-cc-opt-g -O2 -fstack-protector-strong -Wformat -Werrorformat-security -Wp,-D_FORTIFY_SOURCE2 -fPIC \ --with-ld-opt-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie \ --add-module../naxsi-1.3/naxsi_src/ # 这是关键添加Naxsi模块 # 编译并安装 make sudo make install注意如果你的服务器上已经运行着旧版Nginx直接make install会覆盖。在生产环境更稳妥的做法是将新编译好的nginx二进制文件位于objs/目录备份。停止旧Nginx服务。替换旧的二进制文件。启动服务。或者使用make upgrade进行热升级需要旧版本支持。验证安装sudo nginx -V 21 | grep naxsi如果输出中包含--add-module../naxsi-1.3/naxsi_src/则说明Naxsi模块已成功编译进去。3.3 核心配置文件部署安装完成后需要部署Naxsi的核心规则文件。复制核心规则文件# 将Naxsi的核心规则文件复制到Nginx配置目录 sudo cp ~/naxsi-build/naxsi-1.3/naxsi_config/naxsi_core.rules /etc/nginx/这个naxsi_core.rules文件包含了Naxsi默认的检测规则库定义了各种攻击特征的ID和分数。除非你非常了解每一条规则的含义否则不要轻易修改这个文件。创建Naxsi配置文件 在/etc/nginx/目录下创建一个单独的Naxsi配置文件例如naxsi.rules这样管理起来更清晰。sudo touch /etc/nginx/naxsi.rules这个文件我们后续会用来存放自定义的评分规则、白名单以及学习模式等配置。4. Nginx配置与Naxsi基础规则启用现在我们将Naxsi集成到具体的Nginx虚拟主机配置中。4.1 主配置与虚拟主机配置编辑你的Nginx主配置文件/etc/nginx/nginx.conf在http块中引入Naxsi的核心规则和你的自定义规则文件。http { ... # 引入Naxsi核心规则 include /etc/nginx/naxsi_core.rules; # 引入自定义Naxsi规则评分、白名单等 include /etc/nginx/naxsi.rules; ... }然后编辑你的目标站点的配置文件例如/etc/nginx/conf.d/your-site.conf。假设我们要保护一个运行在http://localhost:8080的后端应用。server { listen 80; server_name your-domain.com; # 替换为你的域名或IP # 启用Naxsi并指定规则文件 location / { # 开启Naxsi模块 SecRulesEnabled; # 开启学习模式初期必选生产环境关闭 LearningMode; # 指定拒绝访问时的行为在学习模式下此配置不生效但需保留 DeniedUrl /50x.html; # 定义各检查项的分数阈值 CheckRule $SQL 8 BLOCK; CheckRule $RFI 8 BLOCK; CheckRule $TRAVERSAL 4 BLOCK; CheckRule $EVADE 4 BLOCK; CheckRule $XSS 8 BLOCK; CheckRule $UPLOAD 8 BLOCK; # 当请求被拦截时返回403状态码并记录日志 error_page 403 /403.html; # 反向代理到实际应用 proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 定义一个用于展示拦截页面的location可选 location /50x.html { root /usr/share/nginx/html; internal; } }关键配置解析SecRulesEnabled在此location中启用Naxsi。LearningMode学习模式开关。开启后只记录违规日志不拦截请求。这是初始阶段最重要的安全阀DeniedUrl定义被拒绝时跳转的URL通常是一个错误页面。CheckRule定义拦截规则。格式为CheckRule “变量 操作符 阈值” 动作;。例如“$SQL 8” BLOCK表示当SQL相关规则累计分数达到8分时执行BLOCK动作拦截。这些阈值可以根据业务敏感度调整。error_page 403 /403.html将Naxsi拦截的请求返回403指向一个自定义错误页面提升用户体验。4.2 配置Naxsi日志记录为了分析学习模式下的日志需要配置Naxsi的专属日志格式。在http块中添加http { ... # 定义Naxsi的请求日志格式 log_format naxsi_log $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_cookie $request_body $naxsi_sig $naxsi_ver; # 定义Naxsi的拦截日志格式更详细 log_format naxsi_detailed $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_cookie $request_body $naxsi_sig $naxsi_ver $naxsi_rulez; ... }然后在你的server块中配置日志路径server { ... # 记录所有请求的Naxsi相关信息学习模式用 access_log /var/log/nginx/naxsi_access.log naxsi_log; # 仅记录被拦截请求的详细信息生产模式用 # error_log /var/log/nginx/naxsi_error.log; # Nginx错误日志默认已包含Naxsi拦截信息 ... }4.3 启动与基础测试检查配置并重载Nginxsudo nginx -t # 测试配置文件语法 sudo nginx -s reload # 如果Nginx已在运行重载配置。否则使用 sudo nginx 启动。触发一次测试攻击 打开浏览器或使用curl访问你的网站并在URL中附加一个简单的测试Payload例如http://your-domain.com/?id1或者使用curlcurl http://your-domain.com/?id1查看学习模式日志sudo tail -f /var/log/nginx/naxsi_access.log你应该能看到一条日志其中包含类似NAXSI_FMT: ...的字段里面记录了触发的规则ID如1000、分数、匹配的字符串1和位置ARGS:id。此时请求应该没有被拦截返回200因为处于学习模式。5. 从学习到生产白名单配置实战看到日志里大量的触发记录先别慌。这正是学习模式的意义区分恶意攻击和正常业务。接下来我们要根据日志生成白名单。5.1 分析学习日志并生成基础白名单Naxsi源码中提供了一个非常实用的Python脚本naxsi_src/nx_util.py可以帮助我们分析日志并生成初步的白名单建议。使用工具分析cd ~/naxsi-build/naxsi-1.3/naxsi_src/ # 假设我们已经收集了一段时间的日志将其复制过来分析 sudo cp /var/log/nginx/naxsi_access.log /tmp/ sudo python3 nx_util.py -c /tmp/naxsi_access.log -o /tmp/whitelist_suggestions.rules这个命令会分析日志找出频繁触发规则的、可能是正常的请求模式并生成一个白名单规则建议文件。理解生成的白名单规则 打开/tmp/whitelist_suggestions.rules你会看到类似下面的内容BasicRule wl:1000 mz:$URL:/some-path|$ARGS_VAR:id; BasicRule wl:1000, 1010 mz:$URL:/api/search|$ARGS_VAR:q;BasicRule白名单规则关键字。wl:1000白名单规则ID 1000。wl:表示白名单后面跟规则ID多个ID用逗号分隔。mz:...匹配区域。定义了这条白名单在什么条件下生效。$URL:/some-path表示URL路径为/some-path$ARGS_VAR:id表示参数名为id。|表示“且”的关系。整条规则的意思是在URL为/some-path且参数名为id的位置忽略规则ID为1000的告警。5.2 手动编写与优化白名单工具生成的建议是很好的起点但必须人工审核和优化。白名单的核心原则是范围尽可能精确。反面教材BasicRule wl:1000 “mz:ARGS”;这条规则意味着对所有请求的所有参数都忽略规则1000。这相当于完全放行了含有单引号的输入安全风险极大。正确做法按需白名单只为必要的业务功能添加白名单。例如用户注册时“昵称”字段可能允许输入单引号但“用户ID”字段绝对不允许。精确匹配结合$URL和具体的$ARGS_VAR参数名进行限制。使用正则表达式对于更复杂的场景可以使用$URL_X或$ARGS_VAR_X进行正则匹配但要非常小心避免过度匹配。示例一个博客站点的搜索功能/search?keywordxxx允许用户输入带特殊字符的关键词。# 为搜索接口的 keyword 参数白名单常见的SQL注入和XSS检测规则需根据日志确定具体ID BasicRule wl:1000,1001,1005 “mz:$URL:/search|$ARGS_VAR:keyword”; # 或者如果搜索接口是 /api/v1/search可以更精确 BasicRule wl:1000,1001,1005 “mz:$URL:/api/v1/search|$ARGS_VAR_X:^keyword$”;5.3 应用白名单并切换至拦截模式将精心编写和审核后的白名单规则添加到/etc/nginx/naxsi.rules文件中。修改站点配置文件关闭学习模式即注释掉或删除LearningMode;这一行。location / { SecRulesEnabled; # LearningMode; # 注释掉或删除这行切换为拦截模式 DeniedUrl /50x.html; CheckRule $SQL 8 BLOCK; ... }再次测试配置并重载Nginxsudo nginx -t sudo nginx -s reload进行验证测试正常业务测试访问你的网站进行搜索、登录、提交表单等正常操作确保功能不受影响。攻击测试再次尝试访问http://your-domain.com/?id1 union select 1,2,3--。这次你应该收到一个403 Forbidden错误页面并且在Nginx的错误日志/var/log/nginx/error.log中能看到详细的拦截记录。6. 高级配置、调优与监控基础防护搭建完成后可以通过一些高级配置来提升安全性、性能和可管理性。6.1 调整规则分数与阈值默认的naxsi_core.rules和阈值如$SQL:8是通用配置。你可以根据自身业务特点进行调整。提高敏感度对于管理后台等关键接口可以降低阈值例如将CheckRule $SQL 8 BLOCK;改为CheckRule $SQL 5 BLOCK;使得攻击更容易被拦截。降低误报如果某些规则对业务造成持续误报且无法通过精确白名单解决可以考虑在naxsi.rules中修改该规则的分数但不建议直接禁用核心规则。# 在naxsi.rules中重新定义某条规则的分数需知道规则ID MainRule rx:union msg:union sql keyword mz:ARGS|BODY|$HEADERS_VAR:Cookie s:$SQL:4 id:1302;将原规则ID 1302的分数从8分改为4分。操作前务必在测试环境验证并备份原规则文件。6.2 针对特定Location或请求方法配置你可以为不同的路径或请求方法设置不同的安全策略。server { ... # 对管理后台实施更严格的策略 location /admin/ { SecRulesEnabled; DeniedUrl /50x.html; CheckRule $SQL 4 BLOCK; # 阈值更低 CheckRule $XSS 4 BLOCK; # 禁止PUT/DELETE方法如果后台不用 if ($request_method !~ ^(GET|POST)$) { return 405; } proxy_pass http://backend_admin; } # 对公开API实施宽松策略但仍有基础防护 location /api/v1/public/ { SecRulesEnabled; DeniedUrl /50x.html; CheckRule $SQL 12 BLOCK; # 阈值稍高 CheckRule $RFI 12 BLOCK; proxy_pass http://backend_api; } # 静态资源完全放行不经过Naxsi检查提升性能 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { SecRulesDisabled; # 在此location禁用Naxsi expires 1y; add_header Cache-Control public, immutable; } ... }6.3 性能考量与监控性能影响Naxsi作为Nginx模块性能损耗主要来自规则匹配的复杂度。规则数量、白名单复杂度、请求体大小都会影响性能。对于高流量站点建议将静态资源location的SecRulesDisabled。避免使用过于宽泛的正则表达式白名单。在生产环境充分压测。监控告警拦截日志是重要的安全事件源。集中收集/var/log/nginx/error.log包含Naxsi拦截记录和/var/log/nginx/naxsi_access.log。使用ELK Stack、Grafana Loki或商业SIEM工具对日志进行分析监控拦截频率、攻击来源IP、攻击类型等。对短时间内来自同一IP的高频拦截设置告警这可能代表扫描或攻击行为。7. 常见问题与排查技巧实录即使按照教程操作在实际部署中也可能遇到问题。这里记录几个我踩过的坑和解决方法。7.1 问题Nginx启动失败报错“unknown directive “SecRulesEnabled””原因Naxsi模块没有成功编译进Nginx。最常见的原因是编译时--add-module路径错误或者编译后没有正确重启/替换Nginx二进制文件。排查运行sudo nginx -V 21 | grep naxsi确认输出中包含Naxsi模块路径。如果不包含说明编译时未添加。需要重新执行./configure ... --add-module../naxsi-1.3/naxsi_src/ make sudo make install。如果包含但依然报错可能是配置语法错误。检查nginx -t的输出看是否有其他错误。7.2 问题学习模式下正常业务请求也被大量记录日志刷屏原因这是正常现象说明你的业务请求中包含了Naxsi规则认为可疑的字符。这正是需要白名单的地方。处理不要慌张。运行nx_util.py脚本分析日志生成初步白名单建议。聚焦高频、固定的误报优先处理那些来自固定URL和参数、频繁触发的规则。例如/login接口的username参数总是触发1000规则单引号。编写精确的白名单规则应用到naxsi.rules中重载Nginx观察该误报是否消失。迭代进行直到主要业务流量的误报被消除。7.3 问题切换到拦截模式后某个正常功能报403错误原因为该功能编写的白名单规则不准确或覆盖不全或者有新的请求模式未在学习阶段覆盖到。排查立即查看Nginx错误日志sudo tail -f /var/log/nginx/error.log。找到对应403错误的记录其中NAXSI_FMT字段会详细说明触发了哪些规则、分数多少、匹配了什么内容、在哪个位置。根据日志信息分析是哪个参数、哪个值触发了规则。检查现有的白名单规则看是否覆盖了这个位置URL和参数名。如果没有补充一条。如果已有白名单但触发的规则ID不在白名单列表中将新的规则ID加入。修改配置重载Nginx测试功能是否恢复。7.4 问题如何测试Naxsi是否真的在有效拦截攻击方法使用一些简单的测试Payload进行验证。SQL注入/test?id1 OR 11XSS/test?qscriptalert(1)/script路径遍历/test?file../../../etc/passwd预期在拦截模式下上述请求应返回403并能在错误日志中看到对应的拦截记录。在学习模式下应返回200但在naxsi_access.log中有记录。工具可以使用sqlmap、XSStrike等专业工具进行更全面的测试但务必在授权和测试环境进行。7.5 性能调优小技巧请求体检查检查POST请求体$BODY是性能开销较大的操作。如果某些接口如文件上传确定不需要检查Body可以在对应location中通过CheckRule “$BODY” 0;来禁用对请求体的检查。日志级别生产环境下确保Nginx的错误日志级别不是debug避免Naxsi的详细匹配日志刷屏影响磁盘IO。定期审查白名单业务迭代后旧的接口可能下线但白名单还在。定期审计和清理不再需要的白名单规则是保持安全策略精简有效的必要工作。
1. 项目概述为什么选择Naxsi作为你的第一道防线如果你负责过线上Web服务的运维或安全大概率经历过这样的深夜告警某个不起眼的URL参数里被塞进了一串union select或者一个看似正常的POST请求体里藏了段scriptalert(1)/script。传统的网络防火墙对这类应用层攻击基本是“睁眼瞎”这时候你就需要一个专业的Web应用防火墙。市面上的商业WAF方案功能强大但价格也相当“美丽”对于很多初创团队或预算有限的项目来说直接劝退。Naxsi的出现很大程度上解决了这个痛点。它不是一个新的、独立的服务而是作为Nginx的一个模块来工作你可以把它理解成给Nginx这个“超级门卫”配上了一双“火眼金睛”和一套“格斗术”。Naxsi的核心是一个规则引擎通过分析HTTP请求的各个部分URL、参数、Header、Body与内置的恶意特征库进行匹配从而拦截SQL注入、跨站脚本、目录遍历等常见Web攻击。我最早在为一个内部管理系统做安全加固时接触到它当时的需求很简单零预算、快速上线、规则可控。Naxsi完美契合从研究到基本规则上线确实在10分钟左右就搞定了基础防护。那么谁适合看这篇教程我认为主要是三类人一是中小企业的运维或开发工程师需要快速为自有业务增加一道安全门槛二是个人项目或博客站长希望用最低成本提升站点安全性三是安全爱好者或学生想亲手搭建并理解WAF的工作原理。通过接下来的步骤你不仅能快速搭起一个可用的Naxsi更能理解其背后的拦截逻辑和调优方法做到知其然也知其所以然。2. 核心架构与工作原理拆解在动手安装之前花几分钟理解Naxsi是怎么工作的对于后续的规则调试和问题排查有巨大帮助。很多人在配置时踩坑根源在于把它当成了一个“黑盒”。2.1 Naxsi与Nginx的关系模块化安全Naxsi不是一个独立运行的后台服务这一点和ModSecurity等有些不同。它完全以模块的形式编译进Nginx。这意味着所有的流量过滤动作都发生在Nginx处理请求的生命周期内通常是NGX_HTTP_ACCESS_PHASE阶段。这种深度集成带来了两个直接好处首先是性能损耗极低因为不需要在进程间进行IPC通信其次是配置管理统一所有WAF相关的规则都写在Nginx的配置文件中维护起来非常方便。它的工作流程可以简化为“解析-匹配-裁决”三步。当一个HTTP请求到达Nginx时Naxsi模块会激活对请求行、请求头、请求体如果存在进行解析将其中的“元素”提取出来比如一个查询参数id1会被解析成id和1。然后这些元素会与内部规则我们称之为CheckRule进行匹配。匹配并非简单的字符串比对而是使用了自家的一套语法可以识别各种编码变形和攻击特征。2.2 规则引擎打分制与白名单机制这是Naxsi设计上最巧妙也最需要理解的部分。它采用了一种“负面安全模型”与“打分制”结合的策略。负面安全模型默认情况下它不知道什么是“好”的请求但它定义了大量什么是“坏”的请求特征。这些特征就是内置的规则集每条规则对应一种攻击模式并有一个分数称为score。例如检测到SQL注释符--的规则#1000可能计5分检测到union select的规则#1302可能计8分。打分制每个HTTP请求初始分数为0。当请求中的元素触发某条规则时就累加对应的分数。Naxsi为不同的检查目标如ARGS参数、BODY请求体、URL等分别设置一个分数阈值如$SQL: 8。只要任何一个目标的累计分数超过了其阈值整个请求就会被拦截。这种设计非常灵活。比如一个简单的单引号可能只触发低分规则但如果是id1 union select就会同时触发单引号和union select规则分数累加后很容易就超过$SQL阈值从而被拦截。但只有负面清单会误杀很多正常业务。比如一个博客的搜索功能用户输入test带个单引号是可能的但这会触发SQL注入规则。为此Naxsi引入了白名单机制。白名单不是简单地关闭某条规则而是精确地描述“在某个特定位置如特定的URL、特定的参数名允许出现哪些特征”。白名单的编写是Naxsi配置中最核心、最具技巧性的部分后面我们会详细展开。2.3 学习模式 vs. 拦截模式为了降低部署难度Naxsi提供了“学习模式”。在此模式下即使请求分数超标也不会真正拦截而是会将触发的规则详情记录到日志中。这相当于让Naxsi在线上环境“观摩学习”一段时间收集所有可能触发告警的正常请求模式。运维人员可以基于这些日志分析、提炼出精确的白名单规则。待白名单完善后再切换到“拦截模式”实现安全防护且不影响业务。强烈建议任何新业务上线Naxsi都必须先经过学习模式。3. 环境准备与Naxsi安装理论清楚了我们开始动手。目标是10分钟内从零搭建一个具备基础防护能力的Naxsi。我将以最常见的Ubuntu 20.04 LTS系统为例其他Linux发行版步骤类似主要是包管理器的区别。3.1 系统与Nginx基础环境检查首先确保你的系统已更新并安装了编译所需的工具链。sudo apt update sudo apt upgrade -y sudo apt install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev检查是否已有Nginx。如果有需要确认其版本和编译参数因为我们需要用相同的参数重新编译以添加Naxsi模块。nginx -V 21 | head -n 1这个命令会输出Nginx的版本和一大堆--with-xxx参数。把这些参数完整地复制保存下来至关重要如果系统没有安装Nginx则跳过此步。3.2 获取Naxsi源码并与Nginx整合我们不直接从仓库安装nginx-naxsi包因为那个包版本可能较旧。我推荐从源码编译这样版本可控也更灵活。下载Nginx稳定版和Naxsi源码# 创建一个工作目录并进入 mkdir ~/naxsi-build cd ~/naxsi-build # 下载Nginx源码以1.24.0为例请替换为最新稳定版 wget http://nginx.org/download/nginx-1.24.0.tar.gz tar -zxvf nginx-1.24.0.tar.gz # 下载Naxsi源码 wget https://github.com/nbs-system/naxsi/archive/refs/tags/1.3.tar.gz -O naxsi-1.3.tar.gz tar -zxvf naxsi-1.3.tar.gz编译并安装带Naxsi模块的Nginxcd nginx-1.24.0 # 配置编译参数。这里是最关键的一步。 # 如果你之前没有安装过Nginx使用一套基础参数即可。 # 如果你已有Nginx必须将之前nginx -V输出的所有--with-xxx、--add-module等参数都加上。 # 以下是一个基础示例请务必根据你的实际情况调整。 ./configure \ --prefix/etc/nginx \ --sbin-path/usr/sbin/nginx \ --modules-path/usr/lib/nginx/modules \ --conf-path/etc/nginx/nginx.conf \ --error-log-path/var/log/nginx/error.log \ --http-log-path/var/log/nginx/access.log \ --pid-path/var/run/nginx.pid \ --lock-path/var/run/nginx.lock \ --http-client-body-temp-path/var/cache/nginx/client_temp \ --http-proxy-temp-path/var/cache/nginx/proxy_temp \ --http-fastcgi-temp-path/var/cache/nginx/fastcgi_temp \ --http-uwsgi-temp-path/var/cache/nginx/uwsgi_temp \ --http-scgi-temp-path/var/cache/nginx/scgi_temp \ --usernginx \ --groupnginx \ --with-compat \ --with-file-aio \ --with-threads \ --with-http_addition_module \ --with-http_auth_request_module \ --with-http_dav_module \ --with-http_flv_module \ --with-http_gunzip_module \ --with-http_gzip_static_module \ --with-http_mp4_module \ --with-http_random_index_module \ --with-http_realip_module \ --with-http_secure_link_module \ --with-http_slice_module \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-http_v2_module \ --with-mail \ --with-mail_ssl_module \ --with-stream \ --with-stream_realip_module \ --with-stream_ssl_module \ --with-stream_ssl_preread_module \ --with-cc-opt-g -O2 -fstack-protector-strong -Wformat -Werrorformat-security -Wp,-D_FORTIFY_SOURCE2 -fPIC \ --with-ld-opt-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie \ --add-module../naxsi-1.3/naxsi_src/ # 这是关键添加Naxsi模块 # 编译并安装 make sudo make install注意如果你的服务器上已经运行着旧版Nginx直接make install会覆盖。在生产环境更稳妥的做法是将新编译好的nginx二进制文件位于objs/目录备份。停止旧Nginx服务。替换旧的二进制文件。启动服务。或者使用make upgrade进行热升级需要旧版本支持。验证安装sudo nginx -V 21 | grep naxsi如果输出中包含--add-module../naxsi-1.3/naxsi_src/则说明Naxsi模块已成功编译进去。3.3 核心配置文件部署安装完成后需要部署Naxsi的核心规则文件。复制核心规则文件# 将Naxsi的核心规则文件复制到Nginx配置目录 sudo cp ~/naxsi-build/naxsi-1.3/naxsi_config/naxsi_core.rules /etc/nginx/这个naxsi_core.rules文件包含了Naxsi默认的检测规则库定义了各种攻击特征的ID和分数。除非你非常了解每一条规则的含义否则不要轻易修改这个文件。创建Naxsi配置文件 在/etc/nginx/目录下创建一个单独的Naxsi配置文件例如naxsi.rules这样管理起来更清晰。sudo touch /etc/nginx/naxsi.rules这个文件我们后续会用来存放自定义的评分规则、白名单以及学习模式等配置。4. Nginx配置与Naxsi基础规则启用现在我们将Naxsi集成到具体的Nginx虚拟主机配置中。4.1 主配置与虚拟主机配置编辑你的Nginx主配置文件/etc/nginx/nginx.conf在http块中引入Naxsi的核心规则和你的自定义规则文件。http { ... # 引入Naxsi核心规则 include /etc/nginx/naxsi_core.rules; # 引入自定义Naxsi规则评分、白名单等 include /etc/nginx/naxsi.rules; ... }然后编辑你的目标站点的配置文件例如/etc/nginx/conf.d/your-site.conf。假设我们要保护一个运行在http://localhost:8080的后端应用。server { listen 80; server_name your-domain.com; # 替换为你的域名或IP # 启用Naxsi并指定规则文件 location / { # 开启Naxsi模块 SecRulesEnabled; # 开启学习模式初期必选生产环境关闭 LearningMode; # 指定拒绝访问时的行为在学习模式下此配置不生效但需保留 DeniedUrl /50x.html; # 定义各检查项的分数阈值 CheckRule $SQL 8 BLOCK; CheckRule $RFI 8 BLOCK; CheckRule $TRAVERSAL 4 BLOCK; CheckRule $EVADE 4 BLOCK; CheckRule $XSS 8 BLOCK; CheckRule $UPLOAD 8 BLOCK; # 当请求被拦截时返回403状态码并记录日志 error_page 403 /403.html; # 反向代理到实际应用 proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 定义一个用于展示拦截页面的location可选 location /50x.html { root /usr/share/nginx/html; internal; } }关键配置解析SecRulesEnabled在此location中启用Naxsi。LearningMode学习模式开关。开启后只记录违规日志不拦截请求。这是初始阶段最重要的安全阀DeniedUrl定义被拒绝时跳转的URL通常是一个错误页面。CheckRule定义拦截规则。格式为CheckRule “变量 操作符 阈值” 动作;。例如“$SQL 8” BLOCK表示当SQL相关规则累计分数达到8分时执行BLOCK动作拦截。这些阈值可以根据业务敏感度调整。error_page 403 /403.html将Naxsi拦截的请求返回403指向一个自定义错误页面提升用户体验。4.2 配置Naxsi日志记录为了分析学习模式下的日志需要配置Naxsi的专属日志格式。在http块中添加http { ... # 定义Naxsi的请求日志格式 log_format naxsi_log $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_cookie $request_body $naxsi_sig $naxsi_ver; # 定义Naxsi的拦截日志格式更详细 log_format naxsi_detailed $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_cookie $request_body $naxsi_sig $naxsi_ver $naxsi_rulez; ... }然后在你的server块中配置日志路径server { ... # 记录所有请求的Naxsi相关信息学习模式用 access_log /var/log/nginx/naxsi_access.log naxsi_log; # 仅记录被拦截请求的详细信息生产模式用 # error_log /var/log/nginx/naxsi_error.log; # Nginx错误日志默认已包含Naxsi拦截信息 ... }4.3 启动与基础测试检查配置并重载Nginxsudo nginx -t # 测试配置文件语法 sudo nginx -s reload # 如果Nginx已在运行重载配置。否则使用 sudo nginx 启动。触发一次测试攻击 打开浏览器或使用curl访问你的网站并在URL中附加一个简单的测试Payload例如http://your-domain.com/?id1或者使用curlcurl http://your-domain.com/?id1查看学习模式日志sudo tail -f /var/log/nginx/naxsi_access.log你应该能看到一条日志其中包含类似NAXSI_FMT: ...的字段里面记录了触发的规则ID如1000、分数、匹配的字符串1和位置ARGS:id。此时请求应该没有被拦截返回200因为处于学习模式。5. 从学习到生产白名单配置实战看到日志里大量的触发记录先别慌。这正是学习模式的意义区分恶意攻击和正常业务。接下来我们要根据日志生成白名单。5.1 分析学习日志并生成基础白名单Naxsi源码中提供了一个非常实用的Python脚本naxsi_src/nx_util.py可以帮助我们分析日志并生成初步的白名单建议。使用工具分析cd ~/naxsi-build/naxsi-1.3/naxsi_src/ # 假设我们已经收集了一段时间的日志将其复制过来分析 sudo cp /var/log/nginx/naxsi_access.log /tmp/ sudo python3 nx_util.py -c /tmp/naxsi_access.log -o /tmp/whitelist_suggestions.rules这个命令会分析日志找出频繁触发规则的、可能是正常的请求模式并生成一个白名单规则建议文件。理解生成的白名单规则 打开/tmp/whitelist_suggestions.rules你会看到类似下面的内容BasicRule wl:1000 mz:$URL:/some-path|$ARGS_VAR:id; BasicRule wl:1000, 1010 mz:$URL:/api/search|$ARGS_VAR:q;BasicRule白名单规则关键字。wl:1000白名单规则ID 1000。wl:表示白名单后面跟规则ID多个ID用逗号分隔。mz:...匹配区域。定义了这条白名单在什么条件下生效。$URL:/some-path表示URL路径为/some-path$ARGS_VAR:id表示参数名为id。|表示“且”的关系。整条规则的意思是在URL为/some-path且参数名为id的位置忽略规则ID为1000的告警。5.2 手动编写与优化白名单工具生成的建议是很好的起点但必须人工审核和优化。白名单的核心原则是范围尽可能精确。反面教材BasicRule wl:1000 “mz:ARGS”;这条规则意味着对所有请求的所有参数都忽略规则1000。这相当于完全放行了含有单引号的输入安全风险极大。正确做法按需白名单只为必要的业务功能添加白名单。例如用户注册时“昵称”字段可能允许输入单引号但“用户ID”字段绝对不允许。精确匹配结合$URL和具体的$ARGS_VAR参数名进行限制。使用正则表达式对于更复杂的场景可以使用$URL_X或$ARGS_VAR_X进行正则匹配但要非常小心避免过度匹配。示例一个博客站点的搜索功能/search?keywordxxx允许用户输入带特殊字符的关键词。# 为搜索接口的 keyword 参数白名单常见的SQL注入和XSS检测规则需根据日志确定具体ID BasicRule wl:1000,1001,1005 “mz:$URL:/search|$ARGS_VAR:keyword”; # 或者如果搜索接口是 /api/v1/search可以更精确 BasicRule wl:1000,1001,1005 “mz:$URL:/api/v1/search|$ARGS_VAR_X:^keyword$”;5.3 应用白名单并切换至拦截模式将精心编写和审核后的白名单规则添加到/etc/nginx/naxsi.rules文件中。修改站点配置文件关闭学习模式即注释掉或删除LearningMode;这一行。location / { SecRulesEnabled; # LearningMode; # 注释掉或删除这行切换为拦截模式 DeniedUrl /50x.html; CheckRule $SQL 8 BLOCK; ... }再次测试配置并重载Nginxsudo nginx -t sudo nginx -s reload进行验证测试正常业务测试访问你的网站进行搜索、登录、提交表单等正常操作确保功能不受影响。攻击测试再次尝试访问http://your-domain.com/?id1 union select 1,2,3--。这次你应该收到一个403 Forbidden错误页面并且在Nginx的错误日志/var/log/nginx/error.log中能看到详细的拦截记录。6. 高级配置、调优与监控基础防护搭建完成后可以通过一些高级配置来提升安全性、性能和可管理性。6.1 调整规则分数与阈值默认的naxsi_core.rules和阈值如$SQL:8是通用配置。你可以根据自身业务特点进行调整。提高敏感度对于管理后台等关键接口可以降低阈值例如将CheckRule $SQL 8 BLOCK;改为CheckRule $SQL 5 BLOCK;使得攻击更容易被拦截。降低误报如果某些规则对业务造成持续误报且无法通过精确白名单解决可以考虑在naxsi.rules中修改该规则的分数但不建议直接禁用核心规则。# 在naxsi.rules中重新定义某条规则的分数需知道规则ID MainRule rx:union msg:union sql keyword mz:ARGS|BODY|$HEADERS_VAR:Cookie s:$SQL:4 id:1302;将原规则ID 1302的分数从8分改为4分。操作前务必在测试环境验证并备份原规则文件。6.2 针对特定Location或请求方法配置你可以为不同的路径或请求方法设置不同的安全策略。server { ... # 对管理后台实施更严格的策略 location /admin/ { SecRulesEnabled; DeniedUrl /50x.html; CheckRule $SQL 4 BLOCK; # 阈值更低 CheckRule $XSS 4 BLOCK; # 禁止PUT/DELETE方法如果后台不用 if ($request_method !~ ^(GET|POST)$) { return 405; } proxy_pass http://backend_admin; } # 对公开API实施宽松策略但仍有基础防护 location /api/v1/public/ { SecRulesEnabled; DeniedUrl /50x.html; CheckRule $SQL 12 BLOCK; # 阈值稍高 CheckRule $RFI 12 BLOCK; proxy_pass http://backend_api; } # 静态资源完全放行不经过Naxsi检查提升性能 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { SecRulesDisabled; # 在此location禁用Naxsi expires 1y; add_header Cache-Control public, immutable; } ... }6.3 性能考量与监控性能影响Naxsi作为Nginx模块性能损耗主要来自规则匹配的复杂度。规则数量、白名单复杂度、请求体大小都会影响性能。对于高流量站点建议将静态资源location的SecRulesDisabled。避免使用过于宽泛的正则表达式白名单。在生产环境充分压测。监控告警拦截日志是重要的安全事件源。集中收集/var/log/nginx/error.log包含Naxsi拦截记录和/var/log/nginx/naxsi_access.log。使用ELK Stack、Grafana Loki或商业SIEM工具对日志进行分析监控拦截频率、攻击来源IP、攻击类型等。对短时间内来自同一IP的高频拦截设置告警这可能代表扫描或攻击行为。7. 常见问题与排查技巧实录即使按照教程操作在实际部署中也可能遇到问题。这里记录几个我踩过的坑和解决方法。7.1 问题Nginx启动失败报错“unknown directive “SecRulesEnabled””原因Naxsi模块没有成功编译进Nginx。最常见的原因是编译时--add-module路径错误或者编译后没有正确重启/替换Nginx二进制文件。排查运行sudo nginx -V 21 | grep naxsi确认输出中包含Naxsi模块路径。如果不包含说明编译时未添加。需要重新执行./configure ... --add-module../naxsi-1.3/naxsi_src/ make sudo make install。如果包含但依然报错可能是配置语法错误。检查nginx -t的输出看是否有其他错误。7.2 问题学习模式下正常业务请求也被大量记录日志刷屏原因这是正常现象说明你的业务请求中包含了Naxsi规则认为可疑的字符。这正是需要白名单的地方。处理不要慌张。运行nx_util.py脚本分析日志生成初步白名单建议。聚焦高频、固定的误报优先处理那些来自固定URL和参数、频繁触发的规则。例如/login接口的username参数总是触发1000规则单引号。编写精确的白名单规则应用到naxsi.rules中重载Nginx观察该误报是否消失。迭代进行直到主要业务流量的误报被消除。7.3 问题切换到拦截模式后某个正常功能报403错误原因为该功能编写的白名单规则不准确或覆盖不全或者有新的请求模式未在学习阶段覆盖到。排查立即查看Nginx错误日志sudo tail -f /var/log/nginx/error.log。找到对应403错误的记录其中NAXSI_FMT字段会详细说明触发了哪些规则、分数多少、匹配了什么内容、在哪个位置。根据日志信息分析是哪个参数、哪个值触发了规则。检查现有的白名单规则看是否覆盖了这个位置URL和参数名。如果没有补充一条。如果已有白名单但触发的规则ID不在白名单列表中将新的规则ID加入。修改配置重载Nginx测试功能是否恢复。7.4 问题如何测试Naxsi是否真的在有效拦截攻击方法使用一些简单的测试Payload进行验证。SQL注入/test?id1 OR 11XSS/test?qscriptalert(1)/script路径遍历/test?file../../../etc/passwd预期在拦截模式下上述请求应返回403并能在错误日志中看到对应的拦截记录。在学习模式下应返回200但在naxsi_access.log中有记录。工具可以使用sqlmap、XSStrike等专业工具进行更全面的测试但务必在授权和测试环境进行。7.5 性能调优小技巧请求体检查检查POST请求体$BODY是性能开销较大的操作。如果某些接口如文件上传确定不需要检查Body可以在对应location中通过CheckRule “$BODY” 0;来禁用对请求体的检查。日志级别生产环境下确保Nginx的错误日志级别不是debug避免Naxsi的详细匹配日志刷屏影响磁盘IO。定期审查白名单业务迭代后旧的接口可能下线但白名单还在。定期审计和清理不再需要的白名单规则是保持安全策略精简有效的必要工作。
)