1. 项目概述从扫描器到安全探针的进化在网络安全领域Nmap 这个名字几乎无人不晓。它被誉为“端口扫描之王”是渗透测试、安全评估和网络发现中不可或缺的瑞士军刀。但很多从业者尤其是刚入行的朋友往往只停留在使用nmap -sV 192.168.1.0/24这类基础命令的层面把它当作一个纯粹的端口和服务识别工具。这就像只把一台高精度数控机床当作锤子用实在是暴殄天物。Nmap 真正的威力很大程度上源于其内置的脚本引擎——NSE。NSE 允许你将 Nmap 从一个被动的信息收集者转变为一个主动的安全探针。想象一下在一次授权测试中你扫描到目标开放了 80 端口运行着 Apache 2.4.49。一个熟练的测试者会立刻想到那个著名的路径穿越漏洞。如果手动验证你需要打开浏览器或 Burp Suite构造特定的请求查看响应。但如果利用 NSE你可以在扫描阶段就自动完成对成百上千台主机的漏洞检测将结果直接整合进扫描报告。这种效率的提升是指数级的。我最初接触 NSE 脚本开发是因为在一次大型内网渗透项目中需要快速筛选出存在某个老旧 CMS 特定漏洞的主机。现成的公开脚本要么没有要么检测逻辑过时。硬着头皮开始自己写从照猫画虎到逐渐理解其运行机制踩了不少坑也积累了一套行之有效的开发和调试方法。今天我就把这些经验系统地分享出来目标是让你不仅能看懂、修改别人的脚本更能从零开始编写出贴合自己需求的、健壮的自定义漏洞检测脚本。2. NSE 脚本引擎核心机制解析要写好 NSE 脚本不能只知其然必须知其所以然。你得明白 Nmap 是如何调度、运行这些脚本的这样才能写出高效、兼容的代码。2.1 NSE 脚本的生命周期与运行阶段NSE 脚本并非在扫描的某个固定时间点全部运行。Nmap 根据脚本的“类别”和“运行规则”智能地安排它们的执行时机。理解这一点对脚本性能至关重要。NSE 脚本主要分为以下几类这决定了它们何时被调用prerule: 在所有主机扫描开始之前运行一次。通常用于全局性的设置比如加载一个大的漏洞特征库。例如一个脚本需要预先从网络下载最新的漏洞指纹就可以放在这里。hostrule: 针对每一个被发现存活的主机运行一次。它的输入是一个主机表host。这是进行主机层面检测如 SSH 弱口令爆破、SNMP 信息泄露的主要舞台。hostrule函数接收到的host对象包含了该主机的 IP、MAC 地址等信息。portrule: 针对每一个开放的端口运行。这是最常用、也是最核心的类别。它的输入是主机表host和端口表port。portrule函数会判断当前端口例如 TCP/80 运行着 HTTP是否满足脚本执行的条件。比如一个检测 HTTP 头注入的脚本其portrule就应该定义为当端口服务为http且状态为open时才执行。postrule: 在所有主机扫描结束后运行一次。常用于生成汇总报告、清理临时数据等收尾工作。一个常见的误解是认为脚本会对所有端口运行。实际上Nmap 会先调用脚本的portrule或hostrule函数进行“资格审核”。只有这些函数返回true脚本的action函数才会被执行。这种机制避免了无谓的请求极大地提升了效率。注意在portrule中应尽量使用shortport.port_or_service这类库函数进行判断而不是硬编码端口号。因为服务可能运行在非标准端口上比如 Web 服务在 8080Nmap 的服务探测-sV能识别出来你的脚本也应该能跟上。2.2 脚本结构与关键元素解剖一个标准的 NSE 脚本文件.nse就像一部 Lua 剧本结构清晰。我们以一个虚构的检测Apache Flink Dashboard未授权访问漏洞的脚本为例来拆解各个部分。-- 描述区块脚本的“身份证” description [[ Detects unauthorized access vulnerability in Apache Flink Dashboard. The vulnerability allows unauthenticated attackers to submit malicious jobs via the web dashboard. ]] -- 作者、许可证等信息 author Your Name license Same as Nmap--See https://nmap.org/book/man-legal.html categories {vuln, intrusive} -- 脚本分类 -- 依赖库声明 dependencies {http-vuln-cve2019-12321} -- 如果依赖其他NSE脚本 local http require http -- 加载Nmap内置的http库 local shortport require shortport -- 加载端口规则辅助库 local stdnse require stdnse -- 加载标准NSE函数库 local vulns require vulns -- 加载漏洞报告库 -- 运行规则定义脚本何时触发 portrule shortport.http -- 主逻辑函数脚本执行的核心 action function(host, port) -- 1. 初始化漏洞报告对象 local vuln { title Apache Flink Dashboard Unauthorized Access, state vulns.STATE.NOT_VULN, -- 初始状态设为非漏洞 IDS {CVE CVE-2020-17519}, -- 关联CVE编号 references { https://nvd.nist.gov/vuln/detail/CVE-2020-17519 }, description [[ The Apache Flink Dashboard does not properly enforce authentication, allowing remote attackers to submit arbitrary jobs. ]], } local report vulns.Report:new(SCRIPT_NAME, host, port) -- 2. 构造探测请求 -- 关键精准的探测路径和参数 local path /jobmanager/logs/ local options { header { [User-Agent] stdnse.get_script_ua(), -- 使用Nmap统一UA }, no_cache true -- 避免缓存影响结果 } -- 3. 发送HTTP请求并分析响应 local response http.get(host, port, path, options) -- 4. 漏洞判定逻辑这是核心 if response and response.status 200 then -- 检查响应内容中是否包含特定关键词这是漏洞存在的强信号 if response.body and response.body:match(Flink Dashboard) and response.body:match(Running Jobs) then -- 进一步验证尝试访问一个本应需要认证的API local test_path /jars/upload local test_resp http.get(host, port, test_path) if test_resp and test_resp.status 405 then -- 方法不允许但端点存在 vuln.state vulns.STATE.VULN -- 确认为漏洞 -- 可以附加更多证据到描述中 vuln.description vuln.description .. \n\nVulnerability confirmed: Unauthenticated access to .. path .. returned Flink dashboard. end end end -- 5. 返回漏洞报告 return report:make_output(vuln) end关键元素解读categories: 这里标记为{vuln, intrusive}。vuln表示这是一个漏洞检测脚本Nmap 会在输出中高亮显示。intrusive表示脚本可能对目标产生明显影响如写入操作、大量请求使用--script时如果不加-sC或明确指定默认不会运行这类脚本。根据你的脚本行为谨慎选择分类。shortport.http: 这是一个预定义的规则函数它等价于portrule function(host, port) return port.protocol tcp and port.service http and port.state open end。它确保了脚本只对开放的 HTTP/HTTPS 服务运行。vulns库: 这是必须掌握的库。它提供了标准化的漏洞报告格式。使用它生成的输出结构清晰能被其他工具如导入到漏洞管理平台更好地解析。永远不要简单地用return This host is vulnerable!来输出结果。探测逻辑的层次性: 好的漏洞检测脚本不是“一锤子买卖”。示例中采用了两步验证首先访问一个特定路径检查是否存在 Flink 特征如果存在再尝试访问一个敏感接口根据其响应如 405 方法不允许但证明端点可访问来加强判断减少误报。3. 从零开始编写你的第一个自定义漏洞检测脚本理论说得再多不如动手写一个。我们以实战中常见的一个需求为例检测目标 Web 服务是否暴露了敏感的/.git/目录。Git 目录泄露可能导致源代码、配置文件甚至数据库凭证的暴露危害极大。3.1 需求分析与环境搭建目标编写一个 NSE 脚本自动检测目标 Web 根目录下是否存在可访问的/.git/目录并尝试获取/.git/HEAD文件内容作为证据。环境准备安装 Nmap确保你的系统安装了最新版的 Nmap包含 NSE。Linux 系统通常通过包管理器安装Windows 可从官网下载安装包。脚本存放目录Nmap 会在多个路径搜索 NSE 脚本最常见的是/usr/share/nmap/scripts/Linux或Nmap安装目录\scripts\Windows。建议将自定义脚本放在这里方便调用。你也可以通过--datadir参数指定自定义路径。测试环境为了安全、合法地测试你需要在本地或可控的虚拟机中搭建一个测试靶机。例如使用 Docker 快速运行一个带有漏洞的 Web 应用或者故意在本地 Web 服务器的文档根目录下放置一个.git文件夹。3.2 脚本骨架与基础逻辑实现首先创建一个新文件命名为http-git-dir-disclosure.nse。local http require http local shortport require shortport local stdnse require stdnse local vulns require vulns description [[ Detects publicly accessible .git directories on web servers. Access to the .git directory may lead to source code disclosure. ]] author Security Researcher license Same as Nmap--See https://nmap.org/book/man-legal.html categories {discovery, safe} -- 因为是信息发现且请求简单标记为safe portrule shortport.http action function(host, port) -- 初始化漏洞报告对象即使我们主要做的是发现用vulns库也能格式化输出 local vuln { title Web Server .git Directory Disclosure, state vulns.STATE.NOT_VULN, description [[The .git directory is accessible on the web server.]], references { https://en.wikipedia.org/wiki/Git, https://blog.orange.tw/2018/03/ }, } local report vulns.Report:new(SCRIPT_NAME, host, port) -- 定义要探测的路径 local paths_to_check { /.git/, /.git/HEAD, /.git/index, /.git/config, } local found_evidence nil local found_path nil -- 遍历路径进行探测 for _, path in ipairs(paths_to_check) do stdnse.debug1(Probing path: %s, path) -- 调试信息运行时加 -d 参数可见 local response http.get(host, port, path, { no_cache true }) if response and response.status 200 then -- 对 /.git/HEAD 文件内容做特征验证 if path /.git/HEAD then if response.body and response.body:match(^ref: refs/heads/) then found_evidence response.body found_path path break -- 找到确凿证据停止探测 end elseif path /.git/ then -- 如果返回目录列表也视为发现但证据力度稍弱 found_evidence Directory listing enabled found_path path -- 不break继续尝试获取更确凿的HEAD文件 else -- 对于其他文件如果返回200也记录 found_evidence File accessible found_path path end end end -- 根据发现结果生成报告 if found_evidence then vuln.state vulns.STATE.VULN -- 在输出中附上发现的路径和证据摘要 vuln.description string.format(%s\n\nFound at path: %s\nEvidence: %s, vuln.description, found_path, stdnse.string_or_blank(found_evidence):sub(1, 100) .. ...) end return report:make_output(vuln) end第一版脚本的要点与潜在问题多路径探测我们不是只检查/.git/还检查了具体的 Git 文件。因为有些服务器配置了目录列表禁止但单个文件可能仍能访问。检查HEAD文件是最佳实践因为它很小且内容格式固定。证据验证脚本没有简单地把 HTTP 200 状态码当作漏洞存在的证据。对于HEAD文件它检查了内容是否匹配ref: refs/heads/这个 Git 特征这能有效避免将一些恰好返回 200 的错误页面误判为漏洞大大降低了误报率。性能考虑脚本对多个路径发起了顺序请求。在真正的扫描中如果目标网络延迟高这会拖慢速度。一个优化思路是使用http.pipeline库进行 HTTP 管道化请求但这会增加代码复杂度。对于初步版本顺序请求更易于理解和调试。3.3 脚本的注册与调用将写好的.nse文件放入 Nmap 的脚本目录后无需重启 Nmap 即可调用。调用方法指定脚本名nmap -p 80 --script http-git-dir-disclosure target使用类别nmap -p 80 --script discovery target因为我们的脚本分类包含discovery调试模式nmap -p 80 --script http-git-dir-disclosure -d --script-trace target-d启用调试输出级别 1-9数字越大越详细。--script-trace极其重要。它会显示脚本发送的每个数据包和接收到的每个响应是调试网络交互的利器。4. 高级技巧编写健壮且高效的漏洞检测逻辑基础脚本能跑通只是第一步。在真实、复杂的网络环境中我们需要让脚本更聪明、更健壮、更高效。4.1 处理网络异常与超时网络环境从不理想。脚本必须能优雅地处理超时、连接拒绝、SSL证书错误等情况。Nmap 的http库默认会处理一些但我们需要更精细的控制。action function(host, port) local vuln { ... } -- 初始化省略 local report vulns.Report:new(SCRIPT_NAME, host, port) -- 设置自定义超时和重试策略 local options { no_cache true, timeout 10000, -- 单个请求超时10秒 -- 注意http库的timeout参数在某些版本可能不直接支持需用socket库底层控制 } -- 使用pcall进行错误捕获 local status, response pcall(http.get, host, port, /.git/HEAD, options) if not status then -- pcall捕获到错误response变量此时是错误信息 stdnse.debug1(HTTP request failed: %s, response) -- 可以选择记录错误但不标记为漏洞 return nil -- 或者返回一个友好的错误信息 end -- 检查响应对象本身是否有效 if not response then stdnse.debug1(No response object returned.) return nil end -- 再检查状态码和内容 if response.status 200 then ... -- 后续验证逻辑 elseif response.status 403 or response.status 404 then stdnse.debug1(Path not accessible (HTTP %d)., response.status) -- 正常情况无需处理 else stdnse.debug1(Unexpected HTTP status: %d, response.status) end return report:make_output(vuln) end关键点使用pcallprotected call来调用可能出错的网络函数是一个好习惯。它能防止因为单个请求异常如 DNS 解析失败、连接超时导致整个脚本崩溃影响其他脚本的运行。4.2 实现精准的漏洞指纹识别漏洞检测的核心是“指纹”识别。对于 Web 漏洞这通常体现在响应内容、状态码、响应头、甚至响应时间上。内容匹配使用 Lua 的字符串模式匹配string.match或正则表达式通过stdnse库的search函数如果需要更复杂的功能可以考虑rex库。避免过于宽泛的匹配比如不要只匹配 “error”而要匹配具体的错误信息栈。-- 不好的例子误报率高 if response.body:match(error) then ... -- 好的例子针对特定漏洞的签名 if response.body:match(Apache Struts 2 Showcase) and response.body:match(Exception report) then ...状态码分析HTTP 状态码是重要线索。403 可能意味着路径存在但被禁止这有时也是信息泄露的一种表现确认了资源存在。401 表示需要认证结合某些漏洞如某些设备的默认口令可以关联判断。响应头检查服务器类型Server、框架标识X-Powered-By等头部信息是识别应用和版本的第一道关口。local server_header response.header[server] if server_header and server_header:match(Apache/2%.4%.%d) then -- 针对 Apache 2.4.x 系列的特定检测 end时序攻击Time-based Detection有些漏洞如盲注、条件竞争无法通过直接的响应内容判断。这时可以测量响应时间。但这种方法误差大受网络波动影响严重应谨慎使用并设置合理的基线。local start_time nmap.clock_ms() local response http.get(host, port, /vuln?paramsleep(5)) local end_time nmap.clock_ms() if (end_time - start_time) 4500 then -- 延迟超过4.5秒 -- 可能存在基于时间的盲注漏洞 end4.3 性能优化与脚本并行当扫描大量主机时脚本效率至关重要。减少不必要的请求在portrule阶段就严格过滤。如果脚本只针对 Tomcat就不要在 Nginx 服务上运行。使用连接复用Nmap 的http库在默认情况下会为同一个主机的多个脚本请求尝试复用连接如果支持 Keep-Alive。确保你的脚本没有做破坏连接复用的操作。理解 Nmap 的并行模型Nmap 本身是多线程的但一个脚本的action函数在单个主机-端口上是顺序执行的。如果你需要向同一个服务的不同路径发送大量请求考虑在action函数内使用协程coroutine或简单的循环但要注意不要阻塞太久。对于真正需要并行探测不同主机的场景那是 Nmap 引擎本身的工作。缓存机制如果多个脚本需要相同的基础信息比如都先要获取目标的根目录响应可以考虑编写一个prerule或hostrule脚本进行预抓取并将结果存入 Nmap 的注册表nmap.registry供其他脚本读取。避免重复请求。5. 调试实战让脚本乖乖听话开发过程中十之八九的时间都在调试。Nmap 提供了强大的调试工具。5.1 利用 Nmap 内置调试输出stdnse.debug1(),debug2(),debug3()这是你最好的朋友。它们用于输出不同级别的调试信息。debug1最重要debug3最详细。在关键逻辑分支、变量值变化处、网络请求前后插入它们。stdnse.debug1(Starting action for %s:%s, host.ip, port.number) local response http.get(host, port, path) stdnse.debug1(Received status: %d, body length: %d, response.status, #(response.body or ))运行脚本时使用-d参数查看调试信息nmap -d --script your-script target。-d后面可以跟数字1-3指定级别。--script-trace这是网络层调试的终极武器。它会打印出脚本发送的每一个原始数据包和接收到的原始响应。当你的脚本发送的请求不符合预期或者无法理解服务器的响应时一定要打开它。结合 Wireshark 使用效果更佳。--packet-trace比--script-trace更底层显示 Nmap 发送和接收的所有数据包信息量巨大通常用于解决复杂的网络问题。5.2 搭建本地测试环境不要直接在互联网或生产环境上测试脚本搭建一个本地测试环境是必须的。使用 Docker这是最快捷的方式。你可以轻松运行一个包含漏洞的特定服务版本。# 运行一个带有漏洞的旧版 Jenkins docker run -p 8080:8080 jenkins/jenkins:2.263.1-lts # 运行一个基础的 Apache 用于测试 .git 泄露 docker run -p 80:80 -v $(pwd)/webroot:/usr/local/apache2/htdocs httpd:alpine然后在webroot目录下创建一个.git文件夹和HEAD文件。使用虚拟机安装 Metasploitable、DVWA、WebGoat 等知名的漏洞练习平台。它们提供了丰富的、安全的测试场景。编写单元测试进阶Nmap 本身不提供 NSE 脚本的单元测试框架但你可以编写简单的 Lua 脚本模拟host和port对象调用你的action函数验证其逻辑。这有助于在修改代码后进行回归测试。5.3 常见问题与排查技巧实录以下是我在开发和调试 NSE 脚本中遇到的一些典型问题及解决方法问题1脚本在 Nmap 中根本不运行。检查点脚本文件是否放在正确的目录/usr/share/nmap/scripts/脚本文件名是否以.nse结尾脚本的语法是否有错误可以用nmap --script-updatedb更新脚本数据库它会检查语法。或者直接用lua -l your_script检查 Lua 语法但注意 Nmap 扩展的库可能找不到。你的portrule或hostrule函数是否返回了true在规则函数里加个stdnse.debug1(Rule matched!)看看。你是否使用了categories {intrusive}但没有在命令中显式启用默认的-sC不会运行intrusive脚本需要用--script vuln,intrusive这样指定。问题2脚本运行了但发送的请求不对。必杀技使用--script-trace。查看发送的数据包确认请求方法GET/POST、路径、头部、数据体是否完全符合你的预期。常见错误包括URL 编码问题需要编码的参数没有编码。HTTP 头部格式错误多一个或少一个换行符。POST 数据格式不对比如application/x-www-form-urlencoded和application/json弄混。问题3脚本误报率或漏报率高。原因分析指纹识别逻辑不够精确。解决方法误报高加强验证。不要只依赖状态码。检查响应内容中的多个特征点。引入“二次验证”机制像我们之前例子中检测/.git/HEAD那样。漏报高扩大特征识别范围。考虑目标应用的不同版本、不同部署方式路径前缀、反向代理可能导致的差异。查看--script-trace中服务器的实际响应寻找你没想到的指纹。问题4脚本运行速度太慢拖累整个扫描。优化方向检查portrule是否过于宽泛导致在不相关的端口上也运行减少网络请求能否通过一次请求获取更多信息能否缓存结果设置合理的超时为http请求设置timeout选项避免在无响应的服务上等待过久。评估脚本分类如果脚本确实很慢且具有侵入性将其标记为intrusive让用户知情并选择是否使用。问题5如何调试复杂的字符串匹配或正则表达式技巧将response.body写入一个临时文件然后在本地用文本编辑器或 Lua 交互式环境lua -i进行测试。local file io.open(/tmp/response.txt, w) if file then file:write(response.body) file:close() stdnse.debug1(Response body written to /tmp/response.txt) end这样你可以仔细分析服务器返回的实际内容并精炼你的匹配模式。编写 NSE 脚本是一个将安全研究思路工程化的过程。它要求你不仅理解漏洞原理还要具备严谨的逻辑思维和对网络协议的细致把握。从简单的目录探测到复杂的交互式漏洞验证每一步的成长都建立在不断的实践、调试和优化之上。当你能够熟练地为自己遇到的新漏洞、新场景快速打造出一把精准的检测“探针”时你会发现你的渗透测试效率和深度都将提升一个维度。
Nmap NSE脚本开发实战：从端口扫描到自定义漏洞检测
1. 项目概述从扫描器到安全探针的进化在网络安全领域Nmap 这个名字几乎无人不晓。它被誉为“端口扫描之王”是渗透测试、安全评估和网络发现中不可或缺的瑞士军刀。但很多从业者尤其是刚入行的朋友往往只停留在使用nmap -sV 192.168.1.0/24这类基础命令的层面把它当作一个纯粹的端口和服务识别工具。这就像只把一台高精度数控机床当作锤子用实在是暴殄天物。Nmap 真正的威力很大程度上源于其内置的脚本引擎——NSE。NSE 允许你将 Nmap 从一个被动的信息收集者转变为一个主动的安全探针。想象一下在一次授权测试中你扫描到目标开放了 80 端口运行着 Apache 2.4.49。一个熟练的测试者会立刻想到那个著名的路径穿越漏洞。如果手动验证你需要打开浏览器或 Burp Suite构造特定的请求查看响应。但如果利用 NSE你可以在扫描阶段就自动完成对成百上千台主机的漏洞检测将结果直接整合进扫描报告。这种效率的提升是指数级的。我最初接触 NSE 脚本开发是因为在一次大型内网渗透项目中需要快速筛选出存在某个老旧 CMS 特定漏洞的主机。现成的公开脚本要么没有要么检测逻辑过时。硬着头皮开始自己写从照猫画虎到逐渐理解其运行机制踩了不少坑也积累了一套行之有效的开发和调试方法。今天我就把这些经验系统地分享出来目标是让你不仅能看懂、修改别人的脚本更能从零开始编写出贴合自己需求的、健壮的自定义漏洞检测脚本。2. NSE 脚本引擎核心机制解析要写好 NSE 脚本不能只知其然必须知其所以然。你得明白 Nmap 是如何调度、运行这些脚本的这样才能写出高效、兼容的代码。2.1 NSE 脚本的生命周期与运行阶段NSE 脚本并非在扫描的某个固定时间点全部运行。Nmap 根据脚本的“类别”和“运行规则”智能地安排它们的执行时机。理解这一点对脚本性能至关重要。NSE 脚本主要分为以下几类这决定了它们何时被调用prerule: 在所有主机扫描开始之前运行一次。通常用于全局性的设置比如加载一个大的漏洞特征库。例如一个脚本需要预先从网络下载最新的漏洞指纹就可以放在这里。hostrule: 针对每一个被发现存活的主机运行一次。它的输入是一个主机表host。这是进行主机层面检测如 SSH 弱口令爆破、SNMP 信息泄露的主要舞台。hostrule函数接收到的host对象包含了该主机的 IP、MAC 地址等信息。portrule: 针对每一个开放的端口运行。这是最常用、也是最核心的类别。它的输入是主机表host和端口表port。portrule函数会判断当前端口例如 TCP/80 运行着 HTTP是否满足脚本执行的条件。比如一个检测 HTTP 头注入的脚本其portrule就应该定义为当端口服务为http且状态为open时才执行。postrule: 在所有主机扫描结束后运行一次。常用于生成汇总报告、清理临时数据等收尾工作。一个常见的误解是认为脚本会对所有端口运行。实际上Nmap 会先调用脚本的portrule或hostrule函数进行“资格审核”。只有这些函数返回true脚本的action函数才会被执行。这种机制避免了无谓的请求极大地提升了效率。注意在portrule中应尽量使用shortport.port_or_service这类库函数进行判断而不是硬编码端口号。因为服务可能运行在非标准端口上比如 Web 服务在 8080Nmap 的服务探测-sV能识别出来你的脚本也应该能跟上。2.2 脚本结构与关键元素解剖一个标准的 NSE 脚本文件.nse就像一部 Lua 剧本结构清晰。我们以一个虚构的检测Apache Flink Dashboard未授权访问漏洞的脚本为例来拆解各个部分。-- 描述区块脚本的“身份证” description [[ Detects unauthorized access vulnerability in Apache Flink Dashboard. The vulnerability allows unauthenticated attackers to submit malicious jobs via the web dashboard. ]] -- 作者、许可证等信息 author Your Name license Same as Nmap--See https://nmap.org/book/man-legal.html categories {vuln, intrusive} -- 脚本分类 -- 依赖库声明 dependencies {http-vuln-cve2019-12321} -- 如果依赖其他NSE脚本 local http require http -- 加载Nmap内置的http库 local shortport require shortport -- 加载端口规则辅助库 local stdnse require stdnse -- 加载标准NSE函数库 local vulns require vulns -- 加载漏洞报告库 -- 运行规则定义脚本何时触发 portrule shortport.http -- 主逻辑函数脚本执行的核心 action function(host, port) -- 1. 初始化漏洞报告对象 local vuln { title Apache Flink Dashboard Unauthorized Access, state vulns.STATE.NOT_VULN, -- 初始状态设为非漏洞 IDS {CVE CVE-2020-17519}, -- 关联CVE编号 references { https://nvd.nist.gov/vuln/detail/CVE-2020-17519 }, description [[ The Apache Flink Dashboard does not properly enforce authentication, allowing remote attackers to submit arbitrary jobs. ]], } local report vulns.Report:new(SCRIPT_NAME, host, port) -- 2. 构造探测请求 -- 关键精准的探测路径和参数 local path /jobmanager/logs/ local options { header { [User-Agent] stdnse.get_script_ua(), -- 使用Nmap统一UA }, no_cache true -- 避免缓存影响结果 } -- 3. 发送HTTP请求并分析响应 local response http.get(host, port, path, options) -- 4. 漏洞判定逻辑这是核心 if response and response.status 200 then -- 检查响应内容中是否包含特定关键词这是漏洞存在的强信号 if response.body and response.body:match(Flink Dashboard) and response.body:match(Running Jobs) then -- 进一步验证尝试访问一个本应需要认证的API local test_path /jars/upload local test_resp http.get(host, port, test_path) if test_resp and test_resp.status 405 then -- 方法不允许但端点存在 vuln.state vulns.STATE.VULN -- 确认为漏洞 -- 可以附加更多证据到描述中 vuln.description vuln.description .. \n\nVulnerability confirmed: Unauthenticated access to .. path .. returned Flink dashboard. end end end -- 5. 返回漏洞报告 return report:make_output(vuln) end关键元素解读categories: 这里标记为{vuln, intrusive}。vuln表示这是一个漏洞检测脚本Nmap 会在输出中高亮显示。intrusive表示脚本可能对目标产生明显影响如写入操作、大量请求使用--script时如果不加-sC或明确指定默认不会运行这类脚本。根据你的脚本行为谨慎选择分类。shortport.http: 这是一个预定义的规则函数它等价于portrule function(host, port) return port.protocol tcp and port.service http and port.state open end。它确保了脚本只对开放的 HTTP/HTTPS 服务运行。vulns库: 这是必须掌握的库。它提供了标准化的漏洞报告格式。使用它生成的输出结构清晰能被其他工具如导入到漏洞管理平台更好地解析。永远不要简单地用return This host is vulnerable!来输出结果。探测逻辑的层次性: 好的漏洞检测脚本不是“一锤子买卖”。示例中采用了两步验证首先访问一个特定路径检查是否存在 Flink 特征如果存在再尝试访问一个敏感接口根据其响应如 405 方法不允许但证明端点可访问来加强判断减少误报。3. 从零开始编写你的第一个自定义漏洞检测脚本理论说得再多不如动手写一个。我们以实战中常见的一个需求为例检测目标 Web 服务是否暴露了敏感的/.git/目录。Git 目录泄露可能导致源代码、配置文件甚至数据库凭证的暴露危害极大。3.1 需求分析与环境搭建目标编写一个 NSE 脚本自动检测目标 Web 根目录下是否存在可访问的/.git/目录并尝试获取/.git/HEAD文件内容作为证据。环境准备安装 Nmap确保你的系统安装了最新版的 Nmap包含 NSE。Linux 系统通常通过包管理器安装Windows 可从官网下载安装包。脚本存放目录Nmap 会在多个路径搜索 NSE 脚本最常见的是/usr/share/nmap/scripts/Linux或Nmap安装目录\scripts\Windows。建议将自定义脚本放在这里方便调用。你也可以通过--datadir参数指定自定义路径。测试环境为了安全、合法地测试你需要在本地或可控的虚拟机中搭建一个测试靶机。例如使用 Docker 快速运行一个带有漏洞的 Web 应用或者故意在本地 Web 服务器的文档根目录下放置一个.git文件夹。3.2 脚本骨架与基础逻辑实现首先创建一个新文件命名为http-git-dir-disclosure.nse。local http require http local shortport require shortport local stdnse require stdnse local vulns require vulns description [[ Detects publicly accessible .git directories on web servers. Access to the .git directory may lead to source code disclosure. ]] author Security Researcher license Same as Nmap--See https://nmap.org/book/man-legal.html categories {discovery, safe} -- 因为是信息发现且请求简单标记为safe portrule shortport.http action function(host, port) -- 初始化漏洞报告对象即使我们主要做的是发现用vulns库也能格式化输出 local vuln { title Web Server .git Directory Disclosure, state vulns.STATE.NOT_VULN, description [[The .git directory is accessible on the web server.]], references { https://en.wikipedia.org/wiki/Git, https://blog.orange.tw/2018/03/ }, } local report vulns.Report:new(SCRIPT_NAME, host, port) -- 定义要探测的路径 local paths_to_check { /.git/, /.git/HEAD, /.git/index, /.git/config, } local found_evidence nil local found_path nil -- 遍历路径进行探测 for _, path in ipairs(paths_to_check) do stdnse.debug1(Probing path: %s, path) -- 调试信息运行时加 -d 参数可见 local response http.get(host, port, path, { no_cache true }) if response and response.status 200 then -- 对 /.git/HEAD 文件内容做特征验证 if path /.git/HEAD then if response.body and response.body:match(^ref: refs/heads/) then found_evidence response.body found_path path break -- 找到确凿证据停止探测 end elseif path /.git/ then -- 如果返回目录列表也视为发现但证据力度稍弱 found_evidence Directory listing enabled found_path path -- 不break继续尝试获取更确凿的HEAD文件 else -- 对于其他文件如果返回200也记录 found_evidence File accessible found_path path end end end -- 根据发现结果生成报告 if found_evidence then vuln.state vulns.STATE.VULN -- 在输出中附上发现的路径和证据摘要 vuln.description string.format(%s\n\nFound at path: %s\nEvidence: %s, vuln.description, found_path, stdnse.string_or_blank(found_evidence):sub(1, 100) .. ...) end return report:make_output(vuln) end第一版脚本的要点与潜在问题多路径探测我们不是只检查/.git/还检查了具体的 Git 文件。因为有些服务器配置了目录列表禁止但单个文件可能仍能访问。检查HEAD文件是最佳实践因为它很小且内容格式固定。证据验证脚本没有简单地把 HTTP 200 状态码当作漏洞存在的证据。对于HEAD文件它检查了内容是否匹配ref: refs/heads/这个 Git 特征这能有效避免将一些恰好返回 200 的错误页面误判为漏洞大大降低了误报率。性能考虑脚本对多个路径发起了顺序请求。在真正的扫描中如果目标网络延迟高这会拖慢速度。一个优化思路是使用http.pipeline库进行 HTTP 管道化请求但这会增加代码复杂度。对于初步版本顺序请求更易于理解和调试。3.3 脚本的注册与调用将写好的.nse文件放入 Nmap 的脚本目录后无需重启 Nmap 即可调用。调用方法指定脚本名nmap -p 80 --script http-git-dir-disclosure target使用类别nmap -p 80 --script discovery target因为我们的脚本分类包含discovery调试模式nmap -p 80 --script http-git-dir-disclosure -d --script-trace target-d启用调试输出级别 1-9数字越大越详细。--script-trace极其重要。它会显示脚本发送的每个数据包和接收到的每个响应是调试网络交互的利器。4. 高级技巧编写健壮且高效的漏洞检测逻辑基础脚本能跑通只是第一步。在真实、复杂的网络环境中我们需要让脚本更聪明、更健壮、更高效。4.1 处理网络异常与超时网络环境从不理想。脚本必须能优雅地处理超时、连接拒绝、SSL证书错误等情况。Nmap 的http库默认会处理一些但我们需要更精细的控制。action function(host, port) local vuln { ... } -- 初始化省略 local report vulns.Report:new(SCRIPT_NAME, host, port) -- 设置自定义超时和重试策略 local options { no_cache true, timeout 10000, -- 单个请求超时10秒 -- 注意http库的timeout参数在某些版本可能不直接支持需用socket库底层控制 } -- 使用pcall进行错误捕获 local status, response pcall(http.get, host, port, /.git/HEAD, options) if not status then -- pcall捕获到错误response变量此时是错误信息 stdnse.debug1(HTTP request failed: %s, response) -- 可以选择记录错误但不标记为漏洞 return nil -- 或者返回一个友好的错误信息 end -- 检查响应对象本身是否有效 if not response then stdnse.debug1(No response object returned.) return nil end -- 再检查状态码和内容 if response.status 200 then ... -- 后续验证逻辑 elseif response.status 403 or response.status 404 then stdnse.debug1(Path not accessible (HTTP %d)., response.status) -- 正常情况无需处理 else stdnse.debug1(Unexpected HTTP status: %d, response.status) end return report:make_output(vuln) end关键点使用pcallprotected call来调用可能出错的网络函数是一个好习惯。它能防止因为单个请求异常如 DNS 解析失败、连接超时导致整个脚本崩溃影响其他脚本的运行。4.2 实现精准的漏洞指纹识别漏洞检测的核心是“指纹”识别。对于 Web 漏洞这通常体现在响应内容、状态码、响应头、甚至响应时间上。内容匹配使用 Lua 的字符串模式匹配string.match或正则表达式通过stdnse库的search函数如果需要更复杂的功能可以考虑rex库。避免过于宽泛的匹配比如不要只匹配 “error”而要匹配具体的错误信息栈。-- 不好的例子误报率高 if response.body:match(error) then ... -- 好的例子针对特定漏洞的签名 if response.body:match(Apache Struts 2 Showcase) and response.body:match(Exception report) then ...状态码分析HTTP 状态码是重要线索。403 可能意味着路径存在但被禁止这有时也是信息泄露的一种表现确认了资源存在。401 表示需要认证结合某些漏洞如某些设备的默认口令可以关联判断。响应头检查服务器类型Server、框架标识X-Powered-By等头部信息是识别应用和版本的第一道关口。local server_header response.header[server] if server_header and server_header:match(Apache/2%.4%.%d) then -- 针对 Apache 2.4.x 系列的特定检测 end时序攻击Time-based Detection有些漏洞如盲注、条件竞争无法通过直接的响应内容判断。这时可以测量响应时间。但这种方法误差大受网络波动影响严重应谨慎使用并设置合理的基线。local start_time nmap.clock_ms() local response http.get(host, port, /vuln?paramsleep(5)) local end_time nmap.clock_ms() if (end_time - start_time) 4500 then -- 延迟超过4.5秒 -- 可能存在基于时间的盲注漏洞 end4.3 性能优化与脚本并行当扫描大量主机时脚本效率至关重要。减少不必要的请求在portrule阶段就严格过滤。如果脚本只针对 Tomcat就不要在 Nginx 服务上运行。使用连接复用Nmap 的http库在默认情况下会为同一个主机的多个脚本请求尝试复用连接如果支持 Keep-Alive。确保你的脚本没有做破坏连接复用的操作。理解 Nmap 的并行模型Nmap 本身是多线程的但一个脚本的action函数在单个主机-端口上是顺序执行的。如果你需要向同一个服务的不同路径发送大量请求考虑在action函数内使用协程coroutine或简单的循环但要注意不要阻塞太久。对于真正需要并行探测不同主机的场景那是 Nmap 引擎本身的工作。缓存机制如果多个脚本需要相同的基础信息比如都先要获取目标的根目录响应可以考虑编写一个prerule或hostrule脚本进行预抓取并将结果存入 Nmap 的注册表nmap.registry供其他脚本读取。避免重复请求。5. 调试实战让脚本乖乖听话开发过程中十之八九的时间都在调试。Nmap 提供了强大的调试工具。5.1 利用 Nmap 内置调试输出stdnse.debug1(),debug2(),debug3()这是你最好的朋友。它们用于输出不同级别的调试信息。debug1最重要debug3最详细。在关键逻辑分支、变量值变化处、网络请求前后插入它们。stdnse.debug1(Starting action for %s:%s, host.ip, port.number) local response http.get(host, port, path) stdnse.debug1(Received status: %d, body length: %d, response.status, #(response.body or ))运行脚本时使用-d参数查看调试信息nmap -d --script your-script target。-d后面可以跟数字1-3指定级别。--script-trace这是网络层调试的终极武器。它会打印出脚本发送的每一个原始数据包和接收到的原始响应。当你的脚本发送的请求不符合预期或者无法理解服务器的响应时一定要打开它。结合 Wireshark 使用效果更佳。--packet-trace比--script-trace更底层显示 Nmap 发送和接收的所有数据包信息量巨大通常用于解决复杂的网络问题。5.2 搭建本地测试环境不要直接在互联网或生产环境上测试脚本搭建一个本地测试环境是必须的。使用 Docker这是最快捷的方式。你可以轻松运行一个包含漏洞的特定服务版本。# 运行一个带有漏洞的旧版 Jenkins docker run -p 8080:8080 jenkins/jenkins:2.263.1-lts # 运行一个基础的 Apache 用于测试 .git 泄露 docker run -p 80:80 -v $(pwd)/webroot:/usr/local/apache2/htdocs httpd:alpine然后在webroot目录下创建一个.git文件夹和HEAD文件。使用虚拟机安装 Metasploitable、DVWA、WebGoat 等知名的漏洞练习平台。它们提供了丰富的、安全的测试场景。编写单元测试进阶Nmap 本身不提供 NSE 脚本的单元测试框架但你可以编写简单的 Lua 脚本模拟host和port对象调用你的action函数验证其逻辑。这有助于在修改代码后进行回归测试。5.3 常见问题与排查技巧实录以下是我在开发和调试 NSE 脚本中遇到的一些典型问题及解决方法问题1脚本在 Nmap 中根本不运行。检查点脚本文件是否放在正确的目录/usr/share/nmap/scripts/脚本文件名是否以.nse结尾脚本的语法是否有错误可以用nmap --script-updatedb更新脚本数据库它会检查语法。或者直接用lua -l your_script检查 Lua 语法但注意 Nmap 扩展的库可能找不到。你的portrule或hostrule函数是否返回了true在规则函数里加个stdnse.debug1(Rule matched!)看看。你是否使用了categories {intrusive}但没有在命令中显式启用默认的-sC不会运行intrusive脚本需要用--script vuln,intrusive这样指定。问题2脚本运行了但发送的请求不对。必杀技使用--script-trace。查看发送的数据包确认请求方法GET/POST、路径、头部、数据体是否完全符合你的预期。常见错误包括URL 编码问题需要编码的参数没有编码。HTTP 头部格式错误多一个或少一个换行符。POST 数据格式不对比如application/x-www-form-urlencoded和application/json弄混。问题3脚本误报率或漏报率高。原因分析指纹识别逻辑不够精确。解决方法误报高加强验证。不要只依赖状态码。检查响应内容中的多个特征点。引入“二次验证”机制像我们之前例子中检测/.git/HEAD那样。漏报高扩大特征识别范围。考虑目标应用的不同版本、不同部署方式路径前缀、反向代理可能导致的差异。查看--script-trace中服务器的实际响应寻找你没想到的指纹。问题4脚本运行速度太慢拖累整个扫描。优化方向检查portrule是否过于宽泛导致在不相关的端口上也运行减少网络请求能否通过一次请求获取更多信息能否缓存结果设置合理的超时为http请求设置timeout选项避免在无响应的服务上等待过久。评估脚本分类如果脚本确实很慢且具有侵入性将其标记为intrusive让用户知情并选择是否使用。问题5如何调试复杂的字符串匹配或正则表达式技巧将response.body写入一个临时文件然后在本地用文本编辑器或 Lua 交互式环境lua -i进行测试。local file io.open(/tmp/response.txt, w) if file then file:write(response.body) file:close() stdnse.debug1(Response body written to /tmp/response.txt) end这样你可以仔细分析服务器返回的实际内容并精炼你的匹配模式。编写 NSE 脚本是一个将安全研究思路工程化的过程。它要求你不仅理解漏洞原理还要具备严谨的逻辑思维和对网络协议的细致把握。从简单的目录探测到复杂的交互式漏洞验证每一步的成长都建立在不断的实践、调试和优化之上。当你能够熟练地为自己遇到的新漏洞、新场景快速打造出一把精准的检测“探针”时你会发现你的渗透测试效率和深度都将提升一个维度。
