干安全这行久了你会发现一个规律Nmap的命令行参数背得再熟碰到真实环境还是不够用。默认的NSE脚本库虽然覆盖了常见漏洞但遇到特定设备、特定版本、特定业务逻辑总差那么一点。与其翻遍全网找现成POC不如自己动手写一个定制化NSE脚本。我在做内网渗透和合规基线核查时靠这一招省了至少一半的时间也让很多本来漏报的漏洞被精准揪出来。这篇内容不讲Nmap怎么安装、基础端口扫描命令怎么写这些文档里都有。我要分享的是怎么从零写一个自己的NSE脚本把它挂进Nmap扫描流程里形成一套有针对性的漏洞探测方案。适合三类人看一是安全测试工程师想快速验证私有协议或自研系统的风险点二是运维安全管理员需要周期性核查内部服务配置是否达标三是刚接触NSE、想搞懂脚本引擎底层逻辑的初学者。看完之后你至少能独立写出一两个能上生产环境的探测脚本并且知道怎么调优、怎么排查问题。1. 为什么默认NSE脚本不够用定制到底解决什么问题Nmap自带的600多个NSE脚本确实强但它们是面向通用场景的。真实目标往往有点“怪”私有协议、阉割版Web容器、特定固件的物联网设备、内网里的老旧中间件。默认脚本要么探测规则太宽泛导致误报要么压根不识别目标特征直接返回空结果。我自己踩过最典型的一个坑某次扫描内网摄像头Nmap识别出端口是8080但默认的http-enum脚本什么都没跑出来。后来抓包一看这个摄像头固件的登录接口路径是/cgi-bin/config.cgi不是标准路径。默认脚本根本不会去探测这种路径这时候定制脚本就是唯一高效的路。1.1 NSE脚本引擎的工作流程理解原理才能写出不犯傻的脚本NSENmap Scripting Engine本质上是把Lua脚本嵌入到Nmap扫描流程里。每个脚本通过规则rule决定在什么阶段运行主要分四类pre-rule在扫描前跑post-rule在扫描后跑host-rule针对每个主机跑port-rule针对每个开放端口跑。大部分漏洞探测脚本都挂在port-rule上因为你需要先拿到端口和服务信息再决定要不要发包探测。理解了这套机制你就明白为什么有的脚本会被重复执行如果你写的portrule没有限定具体的服务名和端口范围它会在每一个开放端口上都执行一遍。比如你探测的明显是Web漏洞但没有声明shortport.http作为端口规则脚本就会往FTP、SSH这些端口也发HTTP包除了浪费时间还可能把目标设备打挂。定制脚本的第一步就是搞清portrule的写法把执行范围卡死。1.2 定制脚本的三种典型需求私有协议、配置核查、多阶段联动我总结下来定制NSE脚本的需求基本逃不出这三种。第一种是私有协议识别和漏洞探测比如某个工业控制设备的Modbus寄存器地址或者自研Java应用的心跳接口默认脚本完全没有规则只能靠写脚本模拟客户端握手。第二种是配置项核查比如检测Redis服务有没有开启protected-mode、数据库是否允许匿名登录、Web响应头是否缺失X-Frame-Options等这类需求在合规检查里特别常见用NSE脚本可以批量跑比手工一条条看高效得多。第三种是多阶段联动先用pre-rule跑一次发现阶段再用post-rule汇总多个结果形成报告比如先扫描网段内所有主机的22端口再对支持的算法做一轮降级探测最后汇总成一张主机安全矩阵。这三种需求有一个共同点你都需要对目标协议或者业务特征有清晰的了解。定制脚本不是凭空猜而是要先把目标的握手流程、响应结构、漏洞触发条件搞清楚。这也解释了我为什么总跟团队成员说写NSE脚本前先花一小时看抓包结果比直接写代码管用十倍。2. NSE脚本基础结构拆解先搞清楚每个字段干嘛的一个标准的NSE脚本本质是一个Lua模块它除了包含探测逻辑还包含了Nmap调度器需要读取的元信息和执行规则。很多人第一次接触NSE照着网上的模板复制粘贴结果一运行就报“script is missing description”之类的错误。说白了就是没搞懂结构。下面我把一个完整脚本的最小骨架拆开讲。2.1 description、author、license、categories元信息不是可选项local shortport require(shortport) local stdnse require(stdnse) local http require(http) description [[ Detects whether the target web server exposes a sensitive config backup file. The script sends a GET request to /backup/config.zip and checks if the response contains a valid ZIP header. This is a safe check that only performs one HTTP request. ]] -- usage -- nmap -p 80 --script http-config-backup target -- args http-config-backup.path Path to check. Default /backup/config.zip -- output -- PORT STATE SERVICE -- 80/tcp open http -- | http-config-backup: Potential config backup exposed at /backup/config.zip -- |_ ZIP archive detected, size 31245 bytes author Chronospace license Same as Nmap--See https://nmap.org/book/man-legal.html categories {default, safe, vuln}description字段是人读的提示也会被nmap --script-help调用。更重要的是Nmap 7.0以上版本会解析output和usage注释来自动生成帮助信息所以写规范一点后续维护成本会低很多。categories字段直接影响脚本运行时是否被默认加载。如果你想写一个默认就会跑的脚本可以加入default类别如果只是专项扫描建议只写safe和vuln避免每次都弹出来浪费时间。author和license必须存在否则Nmap会拒绝加载。2.2 portrule和action探测的入口与核心逻辑portrule shortport.http action function(host, port) local path stdnse.get_script_args(http-config-backup.path) or /backup/config.zip local response http.get(host, port, {path path, timeout 5000}) if response.status 200 then -- Check ZIP magic bytes PK (0x504b) local body response.body or local first_bytes body:sub(1, 2) if first_bytes PK then local size response.header[content-length] or #body return string.format(Potential config backup exposed at %s; ZIP archive detected, size %s bytes, path, size) end end return nil endportrule返回true或false决定action要不要在当前端口上运行。这里用shortport.http它会匹配服务识别为http、http-alt、https等常见Web服务端口同时也会尝试对开放端口发起HTTP请求进行指纹确认。action函数接收host和port两个参数返回nil表示没发现问题返回字符串则会作为脚本输出显示在Nmap结果里。注意http.get这类库函数已经内置了超时和错误处理但我在实际使用中仍然习惯传一个timeout参数防止某些设备响应极慢导致扫描卡住。2.3 常用NSE库速览你不需要重复造轮子NSE自带了一批标准库比如http封装了HTTP请求、shortport封装了端口匹配、stdnse提供了参数解析、日志输出、字符串处理等工具函数string和table是Lua标准库用来做文本匹配和数据结构操作。最重要的是stdnse我强烈建议你在动手前花半小时翻一翻它的API文档很多看起来复杂的逻辑其实用stdnse.get_script_args、stdnse.format_output、stdnse.join这几行就能写出来。写定制脚本最忌讳什么都自己造手写正则解析HTTP响应很容易出错直接用http.response对象配合header表反而干净利落。3. 定制化漏洞探测实战从需求到脚本的完整步骤前两节把原理和基础结构讲清楚了这一节我会带着你从头走一遍完整的实战流程。我们假设一个很常见的需求某公司内网有一批老旧的管理系统负责人怀疑有配置文件泄露风险但默认NSE脚本扫不出来。你作为安全工程师需要写一个脚本对这些系统做一轮检查。3.1 明确探测目标和漏洞特征先回答三个问题写脚本前我会先问自己三个问题目标在哪个端口、使用什么协议、漏洞触发时响应有什么特征。以配置泄露为例假设管理系统是Web服务端口是8080指纹识别出是Tomcat。漏洞特征可能是/WEB-INF/web.xml可以直接通过GET访问并且响应内容包含web-app标签。这就是很好的探测特征。再比如你怀疑目标存在目录列举漏洞可以尝试访问/images/如果响应状态是200且页面包含Directory Listing或者Index of字样就可以报告风险。这里有个关键点漏洞探测不是把nmap --scriptvuln跑一遍就算完事。你需要针对目标的实际情况设计探测路径和匹配规则。常规vuln类脚本追求的是覆盖面广而定制脚本追求的是精准和低误报。在设计特征时尽量选取具有唯一性的标识ZIP文件的魔术字节、HTML页面中特定标题、JSON响应中某个固定字段避免用过于宽泛的“包含error字样”这种规则。3.2 编写探测逻辑结合端口与服务做精细控制local shortport require(shortport) local http require(http) local stdnse require(stdnse) description [[ Checks for exposed Tomcat WEB-INF files via direct GET request. Will only run against services identified as http or tomcat. ]] author Chronospace license Same as Nmap--See https://nmap.org/book/man-legal.html categories {vuln, safe} portrule function(host, port) -- 只对那种识别为http或者tomcat的端口进行探测 local service port.service if service http or service tomcat or service https then return true end -- 如果没有识别出服务但是常见的8080/8000/8443端口也试一下 local port_number tonumber(port.number) if port_number 8080 or port_number 8000 or port_number 8443 then return true end return false end action function(host, port) local paths {/WEB-INF/web.xml, /WEB-INF/applicationContext.xml} local results {} for _, path in ipairs(paths) do local response http.get(host, port, {path path, timeout 6000}) if response.status 200 and response.body and response.body:find(web-app) then results[#results 1] string.format(Exposed file: %s (status %d), path, response.status) end end if #results 0 then return stdnse.format_output(true, results) end end这个脚本有几个值得注意的细节。第一portrule里直接通过port.service做第一步过滤第二再用端口号兜底避免漏掉服务识别不准确的目标。第二在action里用一个paths数组循环请求多个路径用results表收集所有发现最后通过stdnse.format_output输出多行结果。第三匹配条件用了web.xml文件中很典型的web-app节点这个特征基本不会出现在正常公开页面里误报率很低。在实际环境中我还习惯加上对响应头的检测比如Content-Type是否为application/xml再进一步降低误报。3.3 注册脚本并测试运行一步步验证正确性脚本写好后保存为/usr/share/nmap/scripts/http-tomcat-web-inf.nse或者你自己定义的Nmap script目录。然后执行nmap --script-updatedb让Nmap刷新脚本数据库。这一步很多菜鸟会漏掉导致--script http-tomcat-web-inf提示找不到脚本。接着用一个测试环境验证最简单的办法是本机起一个包含WEB-INF/web.xml的Java Web项目或者直接找个内网测试靶机nmap -p 8080 --script http-tomcat-web-inf 192.168.1.100我建议先用--script-help http-tomcat-web-inf确认脚本被正确加载再用--script-trace查看详细的请求和响应报文调试时特别有用。--script-trace会把Nmap发出的每一个字节和接收到的每一个字节都打印出来一旦发现脚本逻辑没生效马上能看出是请求路径不对、响应解析问题、还是HTTP版本差异导致。3.4 实例延伸探测远程服务是否允许匿名登录再举一个除了Web场景之外的例子因为内网里FTP和Redis这类服务才是重灾区。比如你想检查一批FTP服务器是不是允许匿名登录可以这么写local shortport require(shortport) local ftp require(ftp) portrule shortport.port_or_service({21}, {ftp, ftp-data}) action function(host, port) local status, code, message ftp.connect(host, port, {timeout 5000}) if not status then return nil end local reply ftp.login(host, port, anonymous, anonymousexample.com) -- 230 表示登录成功 if reply and reply:match(^230) then return Anonymous FTP login allowed end end这个小例子说明一件事NSE已经为你封装了FTP、SMTP、MySQL等常见协议的交互库。如果你的探测目标是标准协议优先搜索NSE自带库别自己用socket从零写握手。只有目标使用私有协议时才需要回到最底层用socket库手动发送原始字节。我自己在写物联网设备探测时经常就是直接构造十六进制报文然后匹配响应的特定偏移值。4. 进阶技巧多阶段扫描、性能调优与结果格式化基础脚本能跑通之后你会面临下一个真实问题扫描一个内网几百台机器脚本并发慢、超时设置不合理、结果输出乱糟糟没法直接当报告用。这一节分享几个我常用到的进阶操作。4.1 控制并发、超时与依赖别让脚本拖垮整个扫描NSE脚本的并发模型是Nmap默认开启几十个并行脚本槽位但每个脚本内部是单线程的。因此脚本运行慢的主要原因是超时设得太大、发包次数太多、或者使用了阻塞式库调用。我常用的策略是把单请求超时控制在3000~6000毫秒之间探测路径超过5个时把脚本拆成多个独立脚本让Nmap的并行机制去分摊压力尽量只对必要的端口发起连接不做大范围端口再探测。另外如果一个脚本依赖另一个脚本的结果可以用--script参数同时加载多个脚本并在脚本里通过safe类别避免重复运行。反正记住一条原则探测脚本应该尽量轻量一次扫描塞太多重逻辑最后落得个自己先卡死。4.2 与Nmap扫描阶段的集成pre-rule和post-rule的妙用定制脚本不一定非得按端口跑也可以在整个扫描之前或之后做点事情。比如你可以在pre-rule里读取一个IP清单文件然后生成针对每个IP的扫描任务或者在post-rule里汇总所有端口探测结果直接生成一份HTML报告。下面是个简单示例prerule function() local file io.open(/tmp/monitor_hosts.txt, r) if file then for line in file:lines() do stdnse.debug1(Pre-scan check target: %s, line) end file:close() end endpost-rule则更常用在结果联动的场景。例如你前面已经通过多个脚本探测出一批主机开放了6379端口后一个脚本可以读取Nmap保存的XML输出结果提取所有开放Redis的主机IP再批量做未授权访问验证并把结果汇总输出。这种多阶段联动模式特别适合周期性的漏洞核查任务第一阶段全端口发现第二阶段服务指纹识别第三阶段只对匹配服务做定制漏洞探测。4.3 结果格式化输出直接来当报告用默认的Nmap输出在终端里看还算清晰但交给领导或者客户时我一般会直接用NSE脚本生成结构化结果。这里就需要用到stdnse.format_output它可以输出一个带层次结构的表格配合nmap -oA生成XML格式后续再用工具转成Excel。如果你希望脚本输出JSON也可以自己把结果用json库序列化。不过要注意Nmap内置的json支持是有限的复杂嵌套时容易出问题不如把扫描结果用-oX输出后用Python脚本解析这样更灵活。我在实际写报告时会这样做NSE脚本只负责把发现的关键字段打出来比如IP、端口、漏洞URL、响应头字段然后用一个外部的Python脚本把这些字段拼接到表格模板里。这样每个脚本只做一件事输出干净后续流程也容易自动化。别试图在一个脚本里塞太多展示逻辑维护成本会直线上升。5. 常见问题与排查技巧实录写NSE脚本最折磨人的不是语法而是排查“为什么不生效”。这里把我在实战中遇到的高频问题整理成一个速查表你照着核对能省不少时间。现象可能原因排查思路--script xxx提示找不到脚本没有放到Nmap的scripts目录或没有执行--script-updatedb运行nmap --script-updatedb再用nmap --script-help xxx验证脚本运行了但没有任何输出portrule没有匹配到目标端口或action里返回了nil先用--script-trace看脚本有没有执行再在action开头添加stdnse.debug1输出扫描特别慢超时设置太长或脚本对每个端口都发起大量探测请求缩短timeout缩小端口范围给portrule加更具体的服务匹配条件出现大量误报匹配规则太宽泛比如只看状态码200就报告改用更精确的响应体匹配特征或增加额外的响应头校验脚本之间互相干扰多个脚本开启相同端口连接导致目标服务崩溃或触发封禁错开扫描时间配置--max-parallelism限制并发或把有冲突的脚本拆到不同轮次执行5.1 脚本加载失败与语法错误的快速定位NSE是Lua 5.3环境最常遇到的错误是attempt to index a nil value多半是库函数名拼错了或者返回值为nil没判断。建议在写每段逻辑时先确认函数的返回值数量和类型。http.get返回的可能是response、status、body等字段但某些自定义端口上可能返回nil所以在访问response.body前一定要判断response是否为nil。另外Nmap的脚本数据库更新机制也有坑如果你是修改了已有脚本要先进scripts目录确认文件名和脚本内部的description字段没有语法高亮异常再执行nmap --script-updatedb。如果更新后还是加载不了直接用lua -e require(xxx)做语法检查前提是装了Lua环境。5.2 误报与漏报的平衡怎么设置匹配规则才靠谱误报和漏报是一场永恒的博弈。我的经验是在定制漏洞探测里宁可有几条漏报也不要让误报刷屏。因为误报会让后续人工复核成本极高导致整个自动化流程被废弃。具体操作上我会给匹配规则设计成“双重确认”先看状态码再看内容特征。比如探测目录列举漏洞仅状态码200不够必须同时满足页面中没有html标签的目录结构、有Index of /字样或者Directory Listing字样才输出结果。匹配字符串时用string.find而不是直接用避免大小写差异。还可以配合response.header里的server字段确认Web容器类型不同类型的容器目录列举页面特征不一样。5.3 合规与伦理提醒别把自己搭进去定制NSE脚本是安全测试的利器但它本质上就是主动扫描和探测工具。一个很容易被忽略的问题是在对方没有授权的情况下哪怕是低危探测也可能被视为恶意行为。并且当你的脚本发出非常规请求时可能触发对方的入侵检测或WAF报警。所以每次写脚本前先确认测试范围和授权边界。我个人的习惯是脚本里写明categories {safe}并且单次探测请求控制在个位数避免高频请求造成目标不可用。扫描过程中我会用--scan-delay或者--max-rate限制发包速率减少对业务系统的影响。另外如果发现了漏洞报告里一定要写清楚修复建议。比如前文提到的Tomcat WEB-INF泄露修复方式就是配置DispatcheServlet拦截对WEB-INF和META-INF的访问或者关闭默认映射。只有带着修复建议的探测才真正算是安全测试不然和捣乱的扫描器没区别。5.4 一个容易被忽略的坑traceroute探测与漏洞修复的关系很多人在拿到Nmap扫描报告后会看到一条“允许traceroute探测”的告警下意识以为是自己没关某个Nmap选项。实际上这条告警跟Nmap本身没有直接关系它指的是目标主机响应了ICMP时间戳请求、地址掩码请求或traceroute数据包可能被用来探知网络拓扑和主机存活状态。如果需要在系统层面修复常见的做法是在防火墙里禁用ICMP type 8和type 13/14的入站请求或者用系统内核参数关闭响应。比如Linux下可以通过/etc/sysctl.conf设置net.ipv4.icmp_echo_ignore_all和net.ipv4.icmp_ignore_bogus_error_responses但这会同时关闭正常的Ping响应生产环境要谨慎。这个问题和NSE定制的关系在于你可以写一个pre-rule脚本在扫描前记录Nmap默认发送的ICMP探测行为再对比扫描结果中暴露的开放端口从而在报告中准确区分“主机本身的系统漏洞”和“扫描行为导致的现象”。我见过不少新手把扫描报告里“traceroute探测”当成了Nmap的漏洞结果在防护墙里封了一堆正常端口业务直接受影响。这一点特别值得提出来希望你别再踩坑。最后再分享一个小技巧如果你要进阶到真正的NSE高手建议把Nmap自带的scripts目录当成教材读一遍。随便挑几个脚本例如http-title.nse、mysql-info.nse、smb-vuln-ms17-010.nse看看它们的portrule怎么写的、action里怎么处理多状态、结果怎么格式化。这些代码是社区十几年的智慧结晶比市面上任何教程都值钱。我自己就是在研究这些脚本时突然开了窍原来定制探测的核心就是“精准匹配目标特征”这七个字。你的脚本不需要写得多花哨能解决当前问题、输出清晰、别人也看得懂就是好脚本。扫描路上祝你一写一个准少踩几个坑。
定制NSE脚本实战：从零编写精准漏洞探测工具
干安全这行久了你会发现一个规律Nmap的命令行参数背得再熟碰到真实环境还是不够用。默认的NSE脚本库虽然覆盖了常见漏洞但遇到特定设备、特定版本、特定业务逻辑总差那么一点。与其翻遍全网找现成POC不如自己动手写一个定制化NSE脚本。我在做内网渗透和合规基线核查时靠这一招省了至少一半的时间也让很多本来漏报的漏洞被精准揪出来。这篇内容不讲Nmap怎么安装、基础端口扫描命令怎么写这些文档里都有。我要分享的是怎么从零写一个自己的NSE脚本把它挂进Nmap扫描流程里形成一套有针对性的漏洞探测方案。适合三类人看一是安全测试工程师想快速验证私有协议或自研系统的风险点二是运维安全管理员需要周期性核查内部服务配置是否达标三是刚接触NSE、想搞懂脚本引擎底层逻辑的初学者。看完之后你至少能独立写出一两个能上生产环境的探测脚本并且知道怎么调优、怎么排查问题。1. 为什么默认NSE脚本不够用定制到底解决什么问题Nmap自带的600多个NSE脚本确实强但它们是面向通用场景的。真实目标往往有点“怪”私有协议、阉割版Web容器、特定固件的物联网设备、内网里的老旧中间件。默认脚本要么探测规则太宽泛导致误报要么压根不识别目标特征直接返回空结果。我自己踩过最典型的一个坑某次扫描内网摄像头Nmap识别出端口是8080但默认的http-enum脚本什么都没跑出来。后来抓包一看这个摄像头固件的登录接口路径是/cgi-bin/config.cgi不是标准路径。默认脚本根本不会去探测这种路径这时候定制脚本就是唯一高效的路。1.1 NSE脚本引擎的工作流程理解原理才能写出不犯傻的脚本NSENmap Scripting Engine本质上是把Lua脚本嵌入到Nmap扫描流程里。每个脚本通过规则rule决定在什么阶段运行主要分四类pre-rule在扫描前跑post-rule在扫描后跑host-rule针对每个主机跑port-rule针对每个开放端口跑。大部分漏洞探测脚本都挂在port-rule上因为你需要先拿到端口和服务信息再决定要不要发包探测。理解了这套机制你就明白为什么有的脚本会被重复执行如果你写的portrule没有限定具体的服务名和端口范围它会在每一个开放端口上都执行一遍。比如你探测的明显是Web漏洞但没有声明shortport.http作为端口规则脚本就会往FTP、SSH这些端口也发HTTP包除了浪费时间还可能把目标设备打挂。定制脚本的第一步就是搞清portrule的写法把执行范围卡死。1.2 定制脚本的三种典型需求私有协议、配置核查、多阶段联动我总结下来定制NSE脚本的需求基本逃不出这三种。第一种是私有协议识别和漏洞探测比如某个工业控制设备的Modbus寄存器地址或者自研Java应用的心跳接口默认脚本完全没有规则只能靠写脚本模拟客户端握手。第二种是配置项核查比如检测Redis服务有没有开启protected-mode、数据库是否允许匿名登录、Web响应头是否缺失X-Frame-Options等这类需求在合规检查里特别常见用NSE脚本可以批量跑比手工一条条看高效得多。第三种是多阶段联动先用pre-rule跑一次发现阶段再用post-rule汇总多个结果形成报告比如先扫描网段内所有主机的22端口再对支持的算法做一轮降级探测最后汇总成一张主机安全矩阵。这三种需求有一个共同点你都需要对目标协议或者业务特征有清晰的了解。定制脚本不是凭空猜而是要先把目标的握手流程、响应结构、漏洞触发条件搞清楚。这也解释了我为什么总跟团队成员说写NSE脚本前先花一小时看抓包结果比直接写代码管用十倍。2. NSE脚本基础结构拆解先搞清楚每个字段干嘛的一个标准的NSE脚本本质是一个Lua模块它除了包含探测逻辑还包含了Nmap调度器需要读取的元信息和执行规则。很多人第一次接触NSE照着网上的模板复制粘贴结果一运行就报“script is missing description”之类的错误。说白了就是没搞懂结构。下面我把一个完整脚本的最小骨架拆开讲。2.1 description、author、license、categories元信息不是可选项local shortport require(shortport) local stdnse require(stdnse) local http require(http) description [[ Detects whether the target web server exposes a sensitive config backup file. The script sends a GET request to /backup/config.zip and checks if the response contains a valid ZIP header. This is a safe check that only performs one HTTP request. ]] -- usage -- nmap -p 80 --script http-config-backup target -- args http-config-backup.path Path to check. Default /backup/config.zip -- output -- PORT STATE SERVICE -- 80/tcp open http -- | http-config-backup: Potential config backup exposed at /backup/config.zip -- |_ ZIP archive detected, size 31245 bytes author Chronospace license Same as Nmap--See https://nmap.org/book/man-legal.html categories {default, safe, vuln}description字段是人读的提示也会被nmap --script-help调用。更重要的是Nmap 7.0以上版本会解析output和usage注释来自动生成帮助信息所以写规范一点后续维护成本会低很多。categories字段直接影响脚本运行时是否被默认加载。如果你想写一个默认就会跑的脚本可以加入default类别如果只是专项扫描建议只写safe和vuln避免每次都弹出来浪费时间。author和license必须存在否则Nmap会拒绝加载。2.2 portrule和action探测的入口与核心逻辑portrule shortport.http action function(host, port) local path stdnse.get_script_args(http-config-backup.path) or /backup/config.zip local response http.get(host, port, {path path, timeout 5000}) if response.status 200 then -- Check ZIP magic bytes PK (0x504b) local body response.body or local first_bytes body:sub(1, 2) if first_bytes PK then local size response.header[content-length] or #body return string.format(Potential config backup exposed at %s; ZIP archive detected, size %s bytes, path, size) end end return nil endportrule返回true或false决定action要不要在当前端口上运行。这里用shortport.http它会匹配服务识别为http、http-alt、https等常见Web服务端口同时也会尝试对开放端口发起HTTP请求进行指纹确认。action函数接收host和port两个参数返回nil表示没发现问题返回字符串则会作为脚本输出显示在Nmap结果里。注意http.get这类库函数已经内置了超时和错误处理但我在实际使用中仍然习惯传一个timeout参数防止某些设备响应极慢导致扫描卡住。2.3 常用NSE库速览你不需要重复造轮子NSE自带了一批标准库比如http封装了HTTP请求、shortport封装了端口匹配、stdnse提供了参数解析、日志输出、字符串处理等工具函数string和table是Lua标准库用来做文本匹配和数据结构操作。最重要的是stdnse我强烈建议你在动手前花半小时翻一翻它的API文档很多看起来复杂的逻辑其实用stdnse.get_script_args、stdnse.format_output、stdnse.join这几行就能写出来。写定制脚本最忌讳什么都自己造手写正则解析HTTP响应很容易出错直接用http.response对象配合header表反而干净利落。3. 定制化漏洞探测实战从需求到脚本的完整步骤前两节把原理和基础结构讲清楚了这一节我会带着你从头走一遍完整的实战流程。我们假设一个很常见的需求某公司内网有一批老旧的管理系统负责人怀疑有配置文件泄露风险但默认NSE脚本扫不出来。你作为安全工程师需要写一个脚本对这些系统做一轮检查。3.1 明确探测目标和漏洞特征先回答三个问题写脚本前我会先问自己三个问题目标在哪个端口、使用什么协议、漏洞触发时响应有什么特征。以配置泄露为例假设管理系统是Web服务端口是8080指纹识别出是Tomcat。漏洞特征可能是/WEB-INF/web.xml可以直接通过GET访问并且响应内容包含web-app标签。这就是很好的探测特征。再比如你怀疑目标存在目录列举漏洞可以尝试访问/images/如果响应状态是200且页面包含Directory Listing或者Index of字样就可以报告风险。这里有个关键点漏洞探测不是把nmap --scriptvuln跑一遍就算完事。你需要针对目标的实际情况设计探测路径和匹配规则。常规vuln类脚本追求的是覆盖面广而定制脚本追求的是精准和低误报。在设计特征时尽量选取具有唯一性的标识ZIP文件的魔术字节、HTML页面中特定标题、JSON响应中某个固定字段避免用过于宽泛的“包含error字样”这种规则。3.2 编写探测逻辑结合端口与服务做精细控制local shortport require(shortport) local http require(http) local stdnse require(stdnse) description [[ Checks for exposed Tomcat WEB-INF files via direct GET request. Will only run against services identified as http or tomcat. ]] author Chronospace license Same as Nmap--See https://nmap.org/book/man-legal.html categories {vuln, safe} portrule function(host, port) -- 只对那种识别为http或者tomcat的端口进行探测 local service port.service if service http or service tomcat or service https then return true end -- 如果没有识别出服务但是常见的8080/8000/8443端口也试一下 local port_number tonumber(port.number) if port_number 8080 or port_number 8000 or port_number 8443 then return true end return false end action function(host, port) local paths {/WEB-INF/web.xml, /WEB-INF/applicationContext.xml} local results {} for _, path in ipairs(paths) do local response http.get(host, port, {path path, timeout 6000}) if response.status 200 and response.body and response.body:find(web-app) then results[#results 1] string.format(Exposed file: %s (status %d), path, response.status) end end if #results 0 then return stdnse.format_output(true, results) end end这个脚本有几个值得注意的细节。第一portrule里直接通过port.service做第一步过滤第二再用端口号兜底避免漏掉服务识别不准确的目标。第二在action里用一个paths数组循环请求多个路径用results表收集所有发现最后通过stdnse.format_output输出多行结果。第三匹配条件用了web.xml文件中很典型的web-app节点这个特征基本不会出现在正常公开页面里误报率很低。在实际环境中我还习惯加上对响应头的检测比如Content-Type是否为application/xml再进一步降低误报。3.3 注册脚本并测试运行一步步验证正确性脚本写好后保存为/usr/share/nmap/scripts/http-tomcat-web-inf.nse或者你自己定义的Nmap script目录。然后执行nmap --script-updatedb让Nmap刷新脚本数据库。这一步很多菜鸟会漏掉导致--script http-tomcat-web-inf提示找不到脚本。接着用一个测试环境验证最简单的办法是本机起一个包含WEB-INF/web.xml的Java Web项目或者直接找个内网测试靶机nmap -p 8080 --script http-tomcat-web-inf 192.168.1.100我建议先用--script-help http-tomcat-web-inf确认脚本被正确加载再用--script-trace查看详细的请求和响应报文调试时特别有用。--script-trace会把Nmap发出的每一个字节和接收到的每一个字节都打印出来一旦发现脚本逻辑没生效马上能看出是请求路径不对、响应解析问题、还是HTTP版本差异导致。3.4 实例延伸探测远程服务是否允许匿名登录再举一个除了Web场景之外的例子因为内网里FTP和Redis这类服务才是重灾区。比如你想检查一批FTP服务器是不是允许匿名登录可以这么写local shortport require(shortport) local ftp require(ftp) portrule shortport.port_or_service({21}, {ftp, ftp-data}) action function(host, port) local status, code, message ftp.connect(host, port, {timeout 5000}) if not status then return nil end local reply ftp.login(host, port, anonymous, anonymousexample.com) -- 230 表示登录成功 if reply and reply:match(^230) then return Anonymous FTP login allowed end end这个小例子说明一件事NSE已经为你封装了FTP、SMTP、MySQL等常见协议的交互库。如果你的探测目标是标准协议优先搜索NSE自带库别自己用socket从零写握手。只有目标使用私有协议时才需要回到最底层用socket库手动发送原始字节。我自己在写物联网设备探测时经常就是直接构造十六进制报文然后匹配响应的特定偏移值。4. 进阶技巧多阶段扫描、性能调优与结果格式化基础脚本能跑通之后你会面临下一个真实问题扫描一个内网几百台机器脚本并发慢、超时设置不合理、结果输出乱糟糟没法直接当报告用。这一节分享几个我常用到的进阶操作。4.1 控制并发、超时与依赖别让脚本拖垮整个扫描NSE脚本的并发模型是Nmap默认开启几十个并行脚本槽位但每个脚本内部是单线程的。因此脚本运行慢的主要原因是超时设得太大、发包次数太多、或者使用了阻塞式库调用。我常用的策略是把单请求超时控制在3000~6000毫秒之间探测路径超过5个时把脚本拆成多个独立脚本让Nmap的并行机制去分摊压力尽量只对必要的端口发起连接不做大范围端口再探测。另外如果一个脚本依赖另一个脚本的结果可以用--script参数同时加载多个脚本并在脚本里通过safe类别避免重复运行。反正记住一条原则探测脚本应该尽量轻量一次扫描塞太多重逻辑最后落得个自己先卡死。4.2 与Nmap扫描阶段的集成pre-rule和post-rule的妙用定制脚本不一定非得按端口跑也可以在整个扫描之前或之后做点事情。比如你可以在pre-rule里读取一个IP清单文件然后生成针对每个IP的扫描任务或者在post-rule里汇总所有端口探测结果直接生成一份HTML报告。下面是个简单示例prerule function() local file io.open(/tmp/monitor_hosts.txt, r) if file then for line in file:lines() do stdnse.debug1(Pre-scan check target: %s, line) end file:close() end endpost-rule则更常用在结果联动的场景。例如你前面已经通过多个脚本探测出一批主机开放了6379端口后一个脚本可以读取Nmap保存的XML输出结果提取所有开放Redis的主机IP再批量做未授权访问验证并把结果汇总输出。这种多阶段联动模式特别适合周期性的漏洞核查任务第一阶段全端口发现第二阶段服务指纹识别第三阶段只对匹配服务做定制漏洞探测。4.3 结果格式化输出直接来当报告用默认的Nmap输出在终端里看还算清晰但交给领导或者客户时我一般会直接用NSE脚本生成结构化结果。这里就需要用到stdnse.format_output它可以输出一个带层次结构的表格配合nmap -oA生成XML格式后续再用工具转成Excel。如果你希望脚本输出JSON也可以自己把结果用json库序列化。不过要注意Nmap内置的json支持是有限的复杂嵌套时容易出问题不如把扫描结果用-oX输出后用Python脚本解析这样更灵活。我在实际写报告时会这样做NSE脚本只负责把发现的关键字段打出来比如IP、端口、漏洞URL、响应头字段然后用一个外部的Python脚本把这些字段拼接到表格模板里。这样每个脚本只做一件事输出干净后续流程也容易自动化。别试图在一个脚本里塞太多展示逻辑维护成本会直线上升。5. 常见问题与排查技巧实录写NSE脚本最折磨人的不是语法而是排查“为什么不生效”。这里把我在实战中遇到的高频问题整理成一个速查表你照着核对能省不少时间。现象可能原因排查思路--script xxx提示找不到脚本没有放到Nmap的scripts目录或没有执行--script-updatedb运行nmap --script-updatedb再用nmap --script-help xxx验证脚本运行了但没有任何输出portrule没有匹配到目标端口或action里返回了nil先用--script-trace看脚本有没有执行再在action开头添加stdnse.debug1输出扫描特别慢超时设置太长或脚本对每个端口都发起大量探测请求缩短timeout缩小端口范围给portrule加更具体的服务匹配条件出现大量误报匹配规则太宽泛比如只看状态码200就报告改用更精确的响应体匹配特征或增加额外的响应头校验脚本之间互相干扰多个脚本开启相同端口连接导致目标服务崩溃或触发封禁错开扫描时间配置--max-parallelism限制并发或把有冲突的脚本拆到不同轮次执行5.1 脚本加载失败与语法错误的快速定位NSE是Lua 5.3环境最常遇到的错误是attempt to index a nil value多半是库函数名拼错了或者返回值为nil没判断。建议在写每段逻辑时先确认函数的返回值数量和类型。http.get返回的可能是response、status、body等字段但某些自定义端口上可能返回nil所以在访问response.body前一定要判断response是否为nil。另外Nmap的脚本数据库更新机制也有坑如果你是修改了已有脚本要先进scripts目录确认文件名和脚本内部的description字段没有语法高亮异常再执行nmap --script-updatedb。如果更新后还是加载不了直接用lua -e require(xxx)做语法检查前提是装了Lua环境。5.2 误报与漏报的平衡怎么设置匹配规则才靠谱误报和漏报是一场永恒的博弈。我的经验是在定制漏洞探测里宁可有几条漏报也不要让误报刷屏。因为误报会让后续人工复核成本极高导致整个自动化流程被废弃。具体操作上我会给匹配规则设计成“双重确认”先看状态码再看内容特征。比如探测目录列举漏洞仅状态码200不够必须同时满足页面中没有html标签的目录结构、有Index of /字样或者Directory Listing字样才输出结果。匹配字符串时用string.find而不是直接用避免大小写差异。还可以配合response.header里的server字段确认Web容器类型不同类型的容器目录列举页面特征不一样。5.3 合规与伦理提醒别把自己搭进去定制NSE脚本是安全测试的利器但它本质上就是主动扫描和探测工具。一个很容易被忽略的问题是在对方没有授权的情况下哪怕是低危探测也可能被视为恶意行为。并且当你的脚本发出非常规请求时可能触发对方的入侵检测或WAF报警。所以每次写脚本前先确认测试范围和授权边界。我个人的习惯是脚本里写明categories {safe}并且单次探测请求控制在个位数避免高频请求造成目标不可用。扫描过程中我会用--scan-delay或者--max-rate限制发包速率减少对业务系统的影响。另外如果发现了漏洞报告里一定要写清楚修复建议。比如前文提到的Tomcat WEB-INF泄露修复方式就是配置DispatcheServlet拦截对WEB-INF和META-INF的访问或者关闭默认映射。只有带着修复建议的探测才真正算是安全测试不然和捣乱的扫描器没区别。5.4 一个容易被忽略的坑traceroute探测与漏洞修复的关系很多人在拿到Nmap扫描报告后会看到一条“允许traceroute探测”的告警下意识以为是自己没关某个Nmap选项。实际上这条告警跟Nmap本身没有直接关系它指的是目标主机响应了ICMP时间戳请求、地址掩码请求或traceroute数据包可能被用来探知网络拓扑和主机存活状态。如果需要在系统层面修复常见的做法是在防火墙里禁用ICMP type 8和type 13/14的入站请求或者用系统内核参数关闭响应。比如Linux下可以通过/etc/sysctl.conf设置net.ipv4.icmp_echo_ignore_all和net.ipv4.icmp_ignore_bogus_error_responses但这会同时关闭正常的Ping响应生产环境要谨慎。这个问题和NSE定制的关系在于你可以写一个pre-rule脚本在扫描前记录Nmap默认发送的ICMP探测行为再对比扫描结果中暴露的开放端口从而在报告中准确区分“主机本身的系统漏洞”和“扫描行为导致的现象”。我见过不少新手把扫描报告里“traceroute探测”当成了Nmap的漏洞结果在防护墙里封了一堆正常端口业务直接受影响。这一点特别值得提出来希望你别再踩坑。最后再分享一个小技巧如果你要进阶到真正的NSE高手建议把Nmap自带的scripts目录当成教材读一遍。随便挑几个脚本例如http-title.nse、mysql-info.nse、smb-vuln-ms17-010.nse看看它们的portrule怎么写的、action里怎么处理多状态、结果怎么格式化。这些代码是社区十几年的智慧结晶比市面上任何教程都值钱。我自己就是在研究这些脚本时突然开了窍原来定制探测的核心就是“精准匹配目标特征”这七个字。你的脚本不需要写得多花哨能解决当前问题、输出清晰、别人也看得懂就是好脚本。扫描路上祝你一写一个准少踩几个坑。
