简介：基于Java的漏洞扫描系统资源包，适合有Java基础、希望进入网络安全扫描方向的开发者，也适用于高校信息安全实验课。包体共927个文件、约33.07MB，nse与lua脚本构成Nmap探测规则，class与jar为Java实现与依赖，xml、txt、properties承担配置和说明，另含启动脚本与数据库文件，便于直接导入工程或结合Nmap运行。
内容覆盖漏洞扫描系统的常见模块：端口扫描、服务识别、漏洞指纹匹配、策略管理、并发调度以及报告与警报机制。从Java Socket编程到NIO、ExecutorService的多线程优化，再到JUnit测试，均有对应代码与规则素材支撑。通过阅读扫描脚本和Java类，可以理解漏洞数据库如何组织、CVE条目如何匹配，以及如何设计灵活的扫描策略。资源包内置的Nmap探测数据、服务指纹库与辅助脚本，能为二次开发或功能扩展提供现成基础。当前已有183人学习，适合作为课程设计、毕业设计或自学入门参考。
1. 基于Java的漏洞扫描系统：为什么说是检测流水线而不是POC集合
拿到一个“基于Java的漏洞扫描系统.zip”时，很多人的第一反应是解压、看漏洞列表、跑几个POC试试。但如果你真的做过安全工具开发，会很快发现一个反直觉的事实：这类系统能不能用，根本不取决于你积累了多少条漏洞利用脚本，而取决于你有没有把“资产发现 → 指纹识别 → 检测编排 → 结果落库 → 报告输出”这条流水线搭起来。没有这条流水线，漏洞库再大也只是一堆无人调度的代码碎片。本篇文章就是沿着这条流水线，把一个Java漏洞扫描系统的骨架、核心模块、踩坑点和最小验证Demo讲清楚，适合想自己动手做安全工具的后端开发者，也适合正在评估开源扫描器源码的测试工程师。
2. 模块拆解：资产发现、指纹识别与目标数据模型的建立
2.1 端口扫描器选型：从Socket半连接到Nmap桥接
漏洞扫描的第一步是搞清楚目标暴露了哪些服务。常见做法有三种：直接Java Socket遍历端口、桥接Nmap/Masscan作为外部扫描器、以及用Netty之类的高性能NIO框架自己写。我一般不会一上来就上Netty——对于绝大多数内部安全评估场景，用Java标准Socket加并发控制已经足够，而且代码可读性好，出了问题也容易排查。
下面是一个最小可用的端口探测核心代码：
public class PortScanner { private static final int TIMEOUT_MS = 800; private static final int THREAD_POOL_SIZE = 128; public static boolean isPortOpen(String host, int port) { try (Socket socket = new Socket()) { socket.connect(new InetSocketAddress(host, port), TIMEOUT_MS); return true; } catch (IOException e) { return false; } } public static List<Integer> scan(String host, List<Integer> ports) throws InterruptedException { ExecutorService pool = Executors.newFixedThreadPool(THREAD_POOL_SIZE); List<Future<Boolean>> futures = new ArrayList<>(); List<Integer> openPorts = new CopyOnWriteArrayList<>(); for (int port : ports) { futures.add(pool.submit(() -> { if (isPortOpen(host, port)) { openPorts.add(port); } return true; })); } for (Future<Boolean> f : futures) { f.get(2, TimeUnit.SECONDS); } pool.shutdown(); return openPorts; } }注意这里巧妙的点是：如果用普通的for循环依次 connect，扫描一个网段的全部端口会慢到不可接受；用固定线程池把端口打散，每个线程负责一个端口探测，整体速度能提升几十倍。参数里TIMEOUT_MS=800是经验值——太短容易漏掉传输慢的目标，太长会被大量不可达IP拖住整个任务。THREAD_POOL_SIZE也需要根据本机内存和目标数量调整，一般安全工具控制在256以内，避免因为扫描行为像洪水攻击而触发目标安全设备告警。
2.2 指纹识别：从HTTP头到favicon哈希的指纹库设计
端口探测发现80/443开放之后，下一步是识别这个Web服务是Nginx、Apache还是某款中间件，版本大概多少。指纹识别是整个漏洞扫描系统的“瞄准镜”：瞄准镜歪了，后面所有POC都是乱打。
指纹采集来源通常有三个：HTTP响应头里的Server字段、页面HTML中的特征字符串、以及favicon.ico的哈希值。靠单一字段非常容易翻车，比如很多运维会隐藏Server头，或者统一替换成“nginx”。所以我的做法是把多源特征组合，给每个指纹匹配加分，超过阈值才算命中。
下面是一个基于正则的指纹匹配器示例：
public class FingerprintMatcher { private static List<FingerprintRule> rules = loadRules(); public static String match(String httpResponseHeader, String htmlBody) { int bestScore = 0; String bestName = "unknown"; for (FingerprintRule rule : rules) { int score = 0; if (rule.getHeaderPattern() != null && rule.getHeaderPattern().matcher(httpResponseHeader).find()) { score += 3; } if (rule.getBodyPattern() != null && rule.getBodyPattern().matcher(htmlBody).find()) { score += 2; } if (score > bestScore) { bestScore = score; bestName = rule.getProductName(); } } return bestName; } }很多初写扫描器的人会把指纹规则做成“只要匹配到一个特征就返回”，这会导致严重的误报。比如某博客系统标题里包含“Powered by Discourse”，正文也出现“discourse”，但其实是伪装页面。用加权打分制，至少命中两个特征才敢向漏洞面板推送检测任务，能少踩很多坑。
除了响应头与HTML，favicon哈希也是一个常被忽略的硬指纹。计算favicon的MD5后与已知库比对，命中率极高，而且在站点完全被CDN遮挡真实指纹时，favicon往往能暴露后端框架。
3. 漏洞检测引擎：插件化架构与POC执行的生命周期
3.1 用SPI实现漏洞插件加载：接口定义与类加载隔离
漏洞检测引擎的核心不是POC多，而是“新增一个漏洞检测逻辑时，不需要改动主框架”。Java里最省事的插件机制就是SPI（Service Provider Interface）。定义好接口后，每个漏洞检测插件是一个独立类，通过META-INF/services下的配置文件被ServiceLoader发现。
接口可以这样定义：
public interface VulnCheck { String getVulnId(); String getVulnName(); boolean appliesTo(String fingerPrintName); boolean check(ScanTarget target) throws IOException; }对应的某个检测中间件反序列化漏洞的插件实现：
public class RcePlugin implements VulnCheck { @Override public String getVulnId() { return "VULN-001"; } @Override public String getVulnName() { return "中间件反序列化远程命令执行"; } @Override public boolean appliesTo(String fingerPrintName) { return fingerPrintName.contains("某些中间件"); } @Override public boolean check(ScanTarget target) throws IOException { // 构造带恶意payload的POST请求 HttpRequest req = HttpRequest.post(target.getBaseUrl() + "/api/xxx") .body(EvilPayload.generate()) .timeout(Duration.ofSeconds(10)); HttpResponse resp = req.execute(); // 判断响应中是否出现命令执行的回显特征 return containsRceEcho(resp.body()); } }注意这里的appliesTo方法是省流量的关键。系统先拿到指纹识别结果，再遍历所有插件调用appliesTo，不匹配的插件直接跳过。很多开源扫描器刚做出来时慢得无法用于生产，就是因为在所有目标上执行所有POC；加了这个预筛选，扫描速度可以提升数倍。
SPI加载不要依赖第三方容器，纯JDK就能跑。唯一要注意的是类加载隔离：如果插件里依赖了不同版本的HttpClient，而主框架也用了HttpClient，轻则NoSuchMethodError，重则插件无法加载。我的习惯是插件包不打包第三方依赖，统一由主框架提供公共依赖，插件内只用主框架暴露的API。
3.2 请求构造与响应验证：从指纹预筛选到误报抑制
POC检测的执行生命周期可以拆成四步：指纹预筛选、构造请求、发送请求、响应验证。每一步都可能引入误报或漏报，尤其是响应验证这块，很多刚入门的开发者只在响应体里contains一个关键字，这种写法在真实目标上会翻车翻到怀疑人生。
比如检测SQL注入，很多教材教的“判断响应是否包含SQL syntax error”，但真实目标可能开启了全局错误捕获，所有异常都在统一JSON里返回；也可能用了参数化查询，根本没有注入，但响应里包含目标其他模块的文字，恰好命中关键字。
我一般会为每类漏洞封装独立的验证器，而不是在插件里写死contains：
public class SqlErrorInjectionValidator extends ResponseValidator { private static final Pattern[] ERROR_PATTERNS = new Pattern[]{ Pattern.compile("SQLSTATE\\[\\d+\\]"), Pattern.compile("JDBCException"), Pattern.compile("Unclosed quotation mark") }; public boolean validate(ResponseResult response, String payload) { if (!response.getStatusCode().isSuccess()) return false; String body = response.getBody(); // 通过多个正则同时匹配，降低单关键字误报 int hitCount = 0; for (Pattern p : ERROR_PATTERNS) { if (p.matcher(body).find()) hitCount++; } return hitCount >= 2; } }响应验证的另一个坑是“时间盲注”类检测。这类检测发送payload后，判断响应时间是否大于某个阈值。阈值太大会漏报，太小会因为目标本身慢而误报。我的参数默认是：正常响应平均时间乘以3，且至少大于3秒，同时发送相同请求两次取平均值，再和正常基线对比。不要只依赖一次请求的耗时，网络抖动是最大的玄学来源。
4. 任务调度与结果落库：把扫描过程变成可追踪的数据流
4.1 扫描任务的状态机与数据库表设计
扫描系统跑起来后，你会立刻发现：如果不把任务状态和中间结果存下来，一趟扫描跑完，你都不知道它现在扫到哪一步了，也无法断点续跑。所以数据库设计不是可选项，是刚需。
我常用的表结构有三张核心表：扫描任务表、资产目标表、漏洞发现表。扫描任务表拥有状态机：待运行 → 资产发现中 → 指纹识别中 → 漏洞检测中 → 已完成 / 已中断。中间步骤可以拆成独立状态，但最少要有“运行中”和“完成”两个状态，用于失败重试和进度显示。
建表SQL可以这样写：
CREATE TABLE scan_task ( task_id BIGINT PRIMARY KEY AUTO_INCREMENT, target VARCHAR(1024) NOT NULL, status TINYINT NOT NULL COMMENT '0-待运行 1-资产发现中 2-指纹识别中 3-漏洞检测中 4-已完成 5-中断', start_time DATETIME, end_time DATETIME, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE vuln_result ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT NOT NULL, host VARCHAR(255) NOT NULL, port INT NOT NULL, vuln_id VARCHAR(64) NOT NULL, vuln_name VARCHAR(512) NOT NULL, risk_level TINYINT COMMENT '1-低危 2-中危 3-高危 4-严重', request_snapshot TEXT, response_snapshot TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_task_host (task_id, host) );状态机不要过度设计。我见过有人把资产发现拆成“端口扫描中”“服务识别中”“指纹识别中”三个状态，结果代码里一半逻辑在处理状态转换时的竞态条件。对于内部工具，一个任务状态加一个阶段标记字段就够，真正要紧的是“执行到哪条目标、扫描到哪个端口”这种断点信息。
4.2 报告生成：用freemarker模板输出HTML与CSV
扫描结果最终要给运维或开发看，大部分人不喜欢打开数据库，而是想要一份可浏览的HTML报告或CSV表格。报告生成我通常用Freemarker，原因很简单：数据模型是一个Java Bean，模板里写循环输出，改样式时不用重新编译主系统。
模板片段示例（简化）：
<table border="1"> <tr><th>主机</th><th>端口</th><th>漏洞名</th><th>风险等级</th></tr> <#list vulnList as v> <tr> <td>${v.host}</td> <td>${v.port}</td> <td>${v.vulnName}</td> <td>${v.riskLevel}</td> </tr> </#list> </table>对应的Java输出逻辑：
Configuration cfg = new Configuration(Configuration.VERSION_2_7_0); cfg.setDefaultEncoding("UTF-8"); Template template = cfg.getTemplate("report.ftl"); Map<String, Object> data = new HashMap<>(); data.put("vulnList", vulnService.findByTaskId(taskId)); try (Writer out = new OutputStreamWriter(new FileOutputStream("report.html"), "UTF-8")) { template.process(data, out); }CSV生成则不需要模板引擎，直接用OpenCSV之类的库可按行写入。但要注意CSV的注入问题——如果漏洞描述中以=,+,-,@开头，Excel打开时会执行公式。最好的办法是导出时在异常字段前加单引号，或者强制把单元格格式设为文本。这一点经常被忽略，等报告发给客户之后发现公式执行才后悔，属于血泪经验。
5. 漏洞扫描系统的5个必踩坑与排查思路
5.1 并发打挂目标，扫描器被防火墙封禁
现象：从小规模扫描升级到全端口并发后，扫描到一半，目标站点开始返回大量502/504，或者干脆拒连接；过一会儿连我们自己服务器的出口IP都被目标防火墙封了。
原因：线程数设置过高，请求没有限速，扫描流量从目标视角看就是一次分布式拒绝服务攻击。尤其是不带延时地连续发起408/409请求，目标防火墙很容易触发主动防护策略。
解决：先降低线程池到32以下，再给每个请求加随机延时机。延时不是固定sleep，而应在200ms~800ms之间抖动，以此模拟真实用户访问节奏。另外给扫描系统增加“最大并发目标数”限制，默认同时只扫10个IP，比单IP大端口扫描安全得多。
5.2 POC验证的误报与漏报：响应匹配不能只看关键字
现象：某个插件把目标上所有页面都标记为存在某漏洞，原因是响应体中总包含一段公共JS代码里的关键字，该关键字恰好是漏洞特征。
原因：插件作者直接写了body.contains("漏洞特征")，没有考虑该特征可能出现在公共组件、错误提示、甚至前端框架源码里。
解决：把验证逻辑从插件中抽离，使用白名单加黑名单机制。比如检测某文件上传漏洞时，必须同时验证状态码为200、返回体中包含上传后的文件名、且文件名不是默认的upload_123.jpg。同时建议对“请求是否真的触发漏洞”做二次确认：再发一次正常请求到同一接口，对比两次响应差异。差异越小，误报越高。
5.3 线程池耗尽，扫描任务假死
现象：扫描系统跑了半小时后，任务一直停在某个状态，日志也不更新，进程不崩溃，但新任务提交不进去。
原因：业务线程池和HTTP请求线程池共用了同一个Executor，或者线程池没有设置拒绝策略，任务队列越积越多，最终堆内存耗尽触发频繁GC，看起来像假死。
解决：给不同阶段分配独立线程池。端口扫描用一个固定线程池，漏洞检测用另一个可动态调整的池，两者之间通过任务队列解耦。线程池必须设置setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy())，这个策略能让任务提交速度受控，而不是无限堆积。排查时先用jstack看线程栈，确认是不是在LinkedBlockingQueue.offer处阻塞。
5.4 目标站字符集与编码导致的指纹失效
现象：指纹识别结果忽高忽低，同一个目标在A机器上命中了框架，在B机器上识别为unknown。
原因：目标页面的编码可能是GBK或者GB18030，而扫描器用UTF-8解码，导致HTML特征串直接乱码，正则匹配失败。这种情况在国情下的老系统里非常常见，不是扫描器逻辑出错，而是编码转换的锅。
解决：获取响应后，先根据Content-Type里的charset或HTML meta标签确定编码，然后用对应Charset解码。Java里用InputStreamReader(is, Charset.forName(charset))包装即可。如果没有声明charset，就尝试用UTF-8和GBK各解码一次，匹配成功率高的一版作为最终页面内容。
5.5 Cookie过期与会话绑定带来的检测颠簸
现象：在扫描登录后的页面时，误报率突然飙升，同一漏洞第一次扫有、第二次扫无。
原因：目标站点的会话超时时间大约在20分钟，扫描器带着旧Cookie去访问，目标返回302跳转到登录页，而插件没有跟随跳转，把登录页的“密码框”当作漏洞回显特征。
解决：扫描前先执行登录获取会话，同时让会话保活——每隔5分钟访问一个轻量页面维持过期时间。每次请求携带Cookie后，还要检查响应状态是否为302且Location指向登录页，如果是则重新登录并重试该请求。这个重试逻辑只做一次，防止死循环。
6. 最小化验证：搭一个能出报告的扫描Demo，再谈分布式
最后想分享一个具体习惯：我拿到这类项目源码后，不会先读全部业务代码，而是用最小闭环验证“从目标输入到漏洞报告”的完整链路。通常写一个main方法，把端口扫描、指纹识别、插件检测和HTML报告串起来，只要这个链路能跑通，后面往分布式扩展才有底。
public static void main(String[] args) throws Exception { // 1. 端口扫描 List<Integer> openPorts = PortScanner.scan("192.168.1.100", IntStream.rangeClosed(1, 65535).boxed().collect(Collectors.toList())); // 2. 对Web端口做指纹识别 String finger = FingerprintMatcher.match(httpHeader, htmlBody); // 3. 根据指纹匹配漏洞插件 ServiceLoader<VulnCheck> plugins = ServiceLoader.load(VulnCheck.class); for (VulnCheck plugin : plugins) { if (plugin.appliesTo(finger)) { // 4. 执行检测并保存结果到数据库 boolean hasVuln = plugin.check(new ScanTarget("192.168.1.100", 80)); if (hasVuln) vulnDao.insert(...); } } // 5. 生成HTML报告 renderReport(taskId); }当你把这条链路跑通后，再往分布式走就简单多了：每个扫描节点只负责一个任务分片，主节点汇总结果写库，报告由独立服务生成。我个人的教训是，分布式不是第一步，单机跑通且不翻车的扫描器，才配谈架构扩展。做安全工具要时刻提醒自己，扫描器本身也可能成为破坏性工具，控制好并发和延时，永远比堆漏洞数量更重要。希望帮到你。
本文还有配套的精品资源，点击获取
