1. 项目概述为什么用Java做端口扫描和网络探测先聊一个我常被问的问题做网络端口扫描网上一抓一大把现成的工具比如某知名扫描器一条命令行就能扫完一个网段为什么还要自己用Java写一套这个问题我以前也想过。后来在实际工作中遇到了几件事才改变看法。有一次某公司让我帮忙排查一批服务器对外开放的端口情况。那批机器差不多有两百台系统版本混杂有些还没装任何扫描工具临时装也不方便。更麻烦的是安全审计要求所有结果以统一格式归档必须包含端口状态、对应服务、开放时间、源IP、目标IP、协议类型、扫描耗时等十几个字段。现成工具输出格式很固定定制起来费劲。第二个场景更常见。某安全演练期间内网某些业务系统流量异常需要快速判断是不是有服务意外监听在非预期端口上。当时需要把扫描能力和内部的告警平台联动发现高危端口开放后自动触发工单。这种需求用现成工具显然不好接但用Java写一套扫描探测程序做成一个独立服务很容易就嵌入到整个安全运营流程里了。所以标题里说的“Java实现网络端口扫描和网络探测报告”本质不是一个“造轮子”的活儿而是围绕端口扫描这个基础能力做一套可定制、可集成、可生成结构化报告的技术组件。Java在网络编程这块的生态成熟Socket机制底层、并发模型清晰跑在服务器上不依赖其他运行时——只要机器有JDK拿着打包好的JAR丢上去就能跑。这篇文章里我会把整个实现思路、核心代码、运行效果、常见坑一步步拆开讲清楚。适合三类人看一是刚接触网络安全、想理解端口扫描底层原理的学生二是需要在内部网络做资产梳理和端口合规检查的运维或安全工程师三是想自己动手写一套网络探测工具的开发者。照着这篇文章你可以实现一个带并发扫描、端口服务识别和扫描报告生成的完整工具。2. 整体设计思路扫描功能背后的方案选型2.1 端口扫描的核心逻辑一次Socket连接尝试先把端口扫描的底层逻辑讲透。一台机器对外提供服务总是通过“IP地址端口号”这个组合来标示。192.168.1.10:80指的是IP为192.168.1.10的这台机器上的80号端口。如果这个端口上有程序在监听那别的主机尝试连接它时双方可以建立起一条数据通路。Java里建立这种连接最基础的方式就是Socket。new Socket() 底层会执行一次三次握手的过程。这个过程中如果端口开放Connect会成功如果端口关闭操作系统会返回Connection refused如果中间被防火墙拦截往往表现为连接超时。这里有一个很好用的特性——绝大多数网络通信库都允许设置连接超时时间。Java的Socket类提供了connect(SocketAddress endpoint, int timeout)这个重载方法意思是“我只给你X毫秒若在规定时间内连不上就不等了”。那扫描就变成一个很直白的循环拿到一个IP再从1到65535遍历端口号逐个创建Socket连接去测试。能连上说明端口开放被拒绝说明端口关闭超时说明可能被防火墙过滤或者主机不可达。这个方案虽然直白性能却很差。假设一个端口连接耗时约200毫秒超时时间单线程扫65535个端口最坏情况要3个多小时。所以必须上并发这是后面要解决的核心问题之一。2.2 方案选型TCP Connect扫描为什么是首选端口扫描常见分三种TCP Connect扫描、SYN半开扫描、UDP扫描。Java里最方便、最可靠的是TCP Connect扫描也就是完整地执行三次握手机制。其实Java天然就不适合做SYN半开扫描——因为半开扫描需要自己构造IP包绕过操作系统协议栈。Java标准库不提供这种能力真要实现得用JNI调用底层C库或者借助第三方库。对一个以“快速落地、报告清晰、集成方便”为目标的工具来说没必要为了追求那一点隐蔽性把架构搞复杂。那TCP Connect扫描有什么好处第一实现简单都是现成的API。第二结果准确度高能直接拿到端口状态、连接耗时。第三对目标系统来说这种扫描会完成完整连接所以在程序自身的日志里能看到正常的连接记录在多数内部网络环境中不敏感。在授权范围内做安全评估时TCP Connect扫描的准确性足够了。SYN扫描那种隐蔽性主要用在攻防对抗场景这超出了我们这篇文章要解决的问题。2.3 为什么用Java而不是Python聊方案选型时总有朋友问Python写扫描工具不更快吗确实Python的socket库十来行就能写一个基础扫描器很多网上的教程也是这么教的。但用Java有两个实际优势。第一部署形态不一样。Python脚本运行依赖解释器和一堆第三方库在服务器上还得pip install这个那个。Java直接打成JAR目标机器只要有JRE双击或命令行一条java -jar就能跑还能用Systemd等工具做成后台服务。第二并发能力。Python有GIL锁多线程做I/O密集任务时性能远不如Java。端口扫描这种高度I/O密集的场景Java用线程池能轻松跑几百个并发Python在类似强度下容易吃紧。实际测过同样是扫一个C段254台主机的常用端口Java用50个线程大概两三分钟扫完Python不开多进程的话会明显慢。当然不是说Python不好而是让你看清楚我为什么选Java。这个选择直接影响后面并发、超时控制、报告生成这些模块的写法。3. 核心实现拆解从单线程扫描到并发优化3.1 最简单的开始同步单端口扫描不说废话先来一个最基础的版本。这个版本逻辑非常清楚一端口一连接是后续所有高级功能的地基。import java.net.InetSocketAddress; import java.net.Socket; public class SimplePortScanner { public static void main(String[] args) { String host 127.0.0.1; int port 80; boolean isOpen checkPort(host, port, 3000); System.out.println(String.format(%s:%d is %s, host, port, isOpen ? OPEN : CLOSED)); } public static boolean checkPort(String host, int port, int timeout) { try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), timeout); return true; } catch (Exception e) { return false; } } }这段代码的逻辑很单纯new Socket()创建未连接的Socketconnect方法发起连接在timeout毫秒内没连上就抛异常。只要connect方法正常返回就说明端口开放。用try-with-resources连接结束后Socket自动关闭不会泄漏连接资源。这里有两个容易被忽略的点要特别注意。第一timeout必须设置不能省。如果不指定超时时间操作系统默认的TCP连接超时可能长达120秒。扫描遇到一个被防火墙丢弃SYN包的端口单是这一个端口就要卡两分钟。65535个端口这样扫下去一天都跑不完。第二connect方法抛出的异常类型不同可以辅助判断端口状态。ConnectException表示连接被拒绝基本确认端口是关闭的SocketTimeoutException表示超时可能是防火墙拦了也可能主机不通。这个细节在后面做结果归类时非常有价值。3.2 单机全端口扫描从for循环到线程池有了单端口检测全端口扫描就是加个循环。但还得解决效率问题。我直接给你看两个版本对比一下感受会更深。第一个版本串行循环。for (int port 1; port 65535; port) { boolean open checkPort(host, port, 2000); if (open) { System.out.println(Port port is open); } }这个版本干净直观但真要跑起来就知道多难受。假设目标网络环境没那么理想平均每个关闭端口的检测耗时约1秒有的是被拒绝有的是超时那这个for循环跑完得18个小时。如果扫描多个主机时间还会线性叠加。这显然不行。第二个版本线程池并发扫描。import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class ConcurrentPortScanner { private static final int THREAD_COUNT 100; private static final int TIMEOUT_MS 1000; public static void main(String[] args) throws InterruptedException { String host 192.168.1.10; ExecutorService executor Executors.newFixedThreadPool(THREAD_COUNT); for (int port 1; port 65535; port) { final int currentPort port; executor.submit(() - { if (checkPort(host, currentPort, TIMEOUT_MS)) { System.out.println(currentPort is open); } }); } executor.shutdown(); boolean finished executor.awaitTermination(10, TimeUnit.MINUTES); if (!finished) { System.out.println(Timeout waiting for tasks to complete); } } }这个版本的核心变化是用Executors.newFixedThreadPool创建了一个固定100线程的线程池把每个端口的扫描任务交给线程池执行。65535个端口分成100个线程去并发处理总耗时大约降为原来的百分之一。这里注意一个关键点为什么要awaitTermination而不是shutdown完事因为shutdown只是通知线程池不再接收新任务但已经提交的任务还在后台跑。awaitTermination才是真正堵塞到所有任务完成或者到达指定的等待时间。如果不等它主线程可能提前退出JVM直接把还在运行的扫描线程全部干掉了扫描结果会不完整。3.3 线程数不是越大越好并发参数怎么定看到线程池有同学可能想“那我直接开1000个线程不是更快吗”真不是这样。端口扫描这个场景虽然是I/O密集但每个Socket连接本身要消耗文件描述符。Linux下每个TCP连接都会占用一个文件描述符进程默认的文件描述符上限通常是1024用ulimit -n可以查。假如你开1000个线程并发建连接每个线程又同时跑着一个Socket文件描述符很快就耗光了然后大量任务直接抛IOException扫描结果被污染。另外还有TCP连接表的问题。大量并发连接会导致连接表短时间内被占满反而触发目标系统拒绝服务。对端口扫描工具来说把目标扫崩了绝对不是期望的结果。我的建议是这么定参数本机性能有限、目标在内网线程数20到50比较温和。目标在内网且网络状况好100到200速度可观。公网环境或者不确定目标承受能力控制在50以内宁慢勿崩。这个取舍背后其实就是安全测试里常说的“动静可控”。你是来做资产梳理的不是来压测的没必要拼速度。4. 服务识别与网络探测扫到端口之后怎么办4.1 服务指纹识别端口号并不等于服务扫到22端口就说“这是SSH服务”其实是偷懒的做法。端口号是约定俗成的但管理员完全可以把SSH改成监听在2222端口中间件也可能自动占用高位端口。所以真正要做服务识别得主动连接上去跟服务握一次手或者读取目标的欢迎信息banner。Java里实现这个很简单建立Socket连接后通过输入流读取对方返回的文本。很多服务在连接建立后会主动发送一段标志信息比如SSH服务会返回类似“SSH-2.0-OpenSSH_8.9p1”的字符串HTTP服务会返回“HTTP/1.1 200 OK”等状态行。给个核心代码片段public static String grabBanner(String host, int port, int timeout) { try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), timeout); socket.setSoTimeout(timeout); socket.getOutputStream().write(\r\n.getBytes()); socket.getOutputStream().flush(); StringBuilder banner new StringBuilder(); BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream())); String line; while ((line reader.readLine()) ! null) { banner.append(line).append(\n); if (banner.length() 512) { break; } } return banner.toString().trim(); } catch (Exception e) { return null; } }这里有个实操细节有的服务不会主动发banner需要你先发送一点数据“戳”它一下才回应。所以代码里先写入一个回车换行很多协议对这个都会有反应。另外还要注意有些服务在收到非法数据后可能会直接断开连接所以读取的时候要准备好异常处理。设setSoTimeout很重要不然如果对方一直不返回数据readLine会永久阻塞。设一个超时时间最多等这么久没数据就放弃。拿到banner后可以跟一个内置的指纹库做匹配把“SSH-2.0-OpenSSH”这类字符串归类成“SSH服务”。指纹库可以自己维护也可以参考网上公开的版本但注意不要引入一些可能有许可约束的复杂组件这个工具保持轻量才灵活。4.2 一个C段主机的网络探测流程端口扫描是一个维度网络探测是另一个维度。这里所谓的网络探测指的是一次综合性的信息收集过程——确定哪些主机在线、有哪些开放端口、运行什么服务最终形成一份网段级的资产地图。我做一个类似的项目时整体的扫描流程是这样设计的第一步先做存活探测。本机发送ICMP Ping报文或者TCP连接某个最常用端口如80、443判断主机是否在线。排除掉那些完全不可达的IP避免后续做全端口扫描浪费时间。第二步对判定为存活的主机做端口扫描。先扫常见端口比如21、22、23、80、443、445、3306、6379、8080这些速度很快先把高危端口捞出来。如果时间充裕再做全端口扫描。第三步对开放端口做服务识别获取banner并结合端口号推断服务类型。第四步生成报告。把扫描到的结果汇总按IP统计、按端口统计输出成可以归档和进一步分析的格式。这个流程看起来简单但每一步都有细节。比如ICMP探测很多云主机和Windows防火墙默认会屏蔽ICMP单纯用Ping来判断存活会漏掉大量在线主机。所以我的建议是存活探测用“ICMP TCP常见端口探测”组合的方式只要任一手段有响应就判定主机存活。4.3 扫描报告的数据结构设计做网络探测报告最难的不是数据可视化而是数据建模。报告是给人看的但中间环节的数据结构是给程序用的。我花了些时间设计一套结构分享给你。整个报告可以分三层第一层是扫描任务元信息。包括任务名称、扫描时间、扫描范围、扫描策略用了多少线程、什么超时时间、任务耗时。第二层是指定范围内的主机列表。每一台主机有IP、主机状态在线或离线、MAC地址如果条件允许获取、操作系统指纹猜测、开放端口总数。第三层是端口明细。每个开放端口需要记录端口号、协议类型、服务类型、banner样本、连接耗时、风险等级。在Java里我推荐直接用Map里嵌List再嵌Map的写法来做临时存储等全部扫描完后再序列化成JSON或文本报告。如果项目继续演进可以考虑用封装的类来定义这些结构但对于一个内部工具来说轻量级的Map结构更灵活改字段不用重新编译整个类。报告输出方面我建议同时输出两种格式JSON格式用于程序处理文本格式给人快速看。JSON序列化用现成的库也行自己拼也行关键是把层级关系理清楚。5. 实操过程完整演示从编写到运行一份扫描报告5.1 完整骨架代码一个能直接跑起来的版本前面拆了一堆概念这里给你一份能直接编译运行的完整示例。这个版本集合了线程池并发扫描、超时控制、banner识别、报告生成四个模块。为了代码可控我把它控制在一个文件内实际项目可以再按需拆分。import java.io.*; import java.net.*; import java.time.LocalDateTime; import java.util.*; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class NetworkScannerDemo { private static final int THREAD_COUNT 100; private static final int TIMEOUT_MS 1200; // 通过IP前缀扫描一个C段网段的常见端口 public static void main(String[] args) throws Exception { String ipPrefix 192.168.1; // 按实际网段修改 int[] ports {21, 22, 23, 25, 80, 110, 143, 443, 445, 3306, 3389, 6379, 8080, 9090, 9092}; MapString, ListMapString, Object reportData new ConcurrentHashMap(); long startTime System.currentTimeMillis(); ExecutorService executor Executors.newFixedThreadPool(THREAD_COUNT); for (int hostNum 1; hostNum 254; hostNum) { final String host ipPrefix . hostNum; for (int port : ports) { executor.submit(() - { MapString, Object result scanPort(host, port); if ((Boolean) result.get(open)) { String banner result.get(banner) null ? : result.get(banner).toString(); ListMapString, Object hostPorts reportData.computeIfAbsent(host, k - new ArrayList()); synchronized (hostPorts) { hostPorts.add(result); } System.out.println([OPEN] host : port - banner); } }); } } executor.shutdown(); executor.awaitTermination(30, TimeUnit.MINUTES); long costTime System.currentTimeMillis() - startTime; generateReport(reportData, costTime); } public static MapString, Object scanPort(String host, int port) { MapString, Object result new HashMap(); result.put(ip, host); result.put(port, port); result.put(open, false); long start System.currentTimeMillis(); try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), TIMEOUT_MS); result.put(open, true); socket.setSoTimeout(600); String banner readBanner(socket); result.put(banner, banner); result.put(service, guessService(port, banner)); } catch (Exception e) { result.put(error, e.getClass().getSimpleName()); } result.put(cost_ms, System.currentTimeMillis() - start); return result; } public static String readBanner(Socket socket) { try { socket.getOutputStream().write(\r\n.getBytes()); socket.getOutputStream().flush(); BufferedReader reader new BufferedReader(new InputStreamReader(socket.getInputStream())); StringBuilder sb new StringBuilder(); int totalRead 0; String line; while ((line reader.readLine()) ! null totalRead 512) { sb.append(line).append( | ); totalRead line.length(); } return sb.toString().trim(); } catch (Exception e) { return ; } } public static String guessService(int port, String banner) { if (banner ! null !banner.isEmpty()) { if (banner.contains(SSH)) return ssh; if (banner.startsWith(HTTP) || banner.contains(nginx) || banner.contains(Apache)) return http; if (banner.contains(MySQL)) return mysql; if (banner.contains(Redis)) return redis; } // 基于端口号的兜底猜测 switch (port) { case 21: return ftp; case 22: return ssh; case 23: return telnet; case 25: return smtp; case 80: return http; case 443: return https; case 3306: return mysql; case 6379: return redis; default: return unknown; } } public static void generateReport(MapString, ListMapString, Object data, long costTime) throws IOException { try (BufferedWriter writer new BufferedWriter(new FileWriter(scan_report_ System.currentTimeMillis() .txt))) { writer.write( 网络扫描报告 \n); writer.write(生成时间: LocalDateTime.now() \n); writer.write(扫描耗时: costTime ms\n); writer.write(在线主机数量: data.size() \n\n); for (Map.EntryString, ListMapString, Object entry : data.entrySet()) { writer.write(Host: entry.getKey() ( entry.getValue().size() open ports)\n); for (MapString, Object portInfo : entry.getValue()) { writer.write( - Port: portInfo.get(port) , service: portInfo.get(service) , banner: portInfo.get(banner) \n); } writer.write(\n); } } } }这段代码的组织逻辑不复杂外层循环先枚举IP和端口把每个扫描任务提交到线程池。scanPort方法负责做一次完整的端口探测连接、记录耗时、抓取banner。返回的结果Map用ConcurrentHashMap按IP分组收集起来。最后统一生成一份文本报告。要注意的是我用了ConcurrentHashMap加synchronized来保证线程安全。ConcurrentHashMap保证的是Map自身的并发安全但是“拿到一个key的List之后往这个List里添加元素”这个操作如果不额外加锁还是可能出问题。代码里对list加synchronized块就是防止多个线程同时往同一个主机的list里塞数据。如果项目里准备用更复杂的结构建议直接用CopyOnWriteArrayList能省去手动加锁的麻烦。5.2 运行效果与结果解读假设你跑在192.168.1.0/24这个网段代码输出会是这个感觉[OPEN] 192.168.1.1:22 - SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 | [OPEN] 192.168.1.1:80 - HTTP/1.1 403 Forbidden [OPEN] 192.168.1.10:3306 - 8.0.32-log [OPEN] 192.168.1.10:6379 - $3 ... 扫描结束报告文件内容大致是 网络扫描报告 生成时间: 2025-01-15T15:30:22 扫描耗时: 32481 ms 在线主机数量: 12 Host: 192.168.1.1 (2 open ports) - Port: 22, service: ssh, banner: SSH-2.0-OpenSSH_8.9p1 - Port: 80, service: http, banner: HTTP/1.1 403 Forbidden这份报告能直接拿来做资产登记。发现一个本不该开放的高危端口比如某台数据库服务器暴露了6379端口且没有密码认证那就应该立刻走告警流程。这里顺便分享一个我从实际项目里总结的经验扫描结果里出现的banner信息往往会暴露出软件的具体版本号。比如上面那个“8.9p1 Ubuntu”和“8.0.32-log”这些版本号可以直接关联到已知漏洞库。所以在设计报告结构时一定要把banner单独留一个字段而不是只写一个“服务类型”。5.3 超时参数和线程数如何配合调整前面说了线程数不能无脑调大但超时参数和线程数是配套调整的。它们共同决定了扫描的总耗时和扰动程度。你可以这样理解假设100个线程并发扫描每个端口的平均探测耗时是1秒含超时等待那么100个任务一批就是1秒。但如果你把线程数拉到200同时把超时时间从1秒降到500毫秒那每批任务耗时可能就是0.6秒左右总量不变的情况下总耗时反而缩短了因为单位时间内能处理的任务数变多了。当然这两者都不是无限优化的。超时时间设得太短比如200毫秒在公网环境下很多正常开放的端口也会因为网络RTT往返时延较高被误判为不通。内网延迟低可以设短一点公网扫描建议至少1000到2000毫秒。下面这张表是我在不同场景下的经验参数可以参考扫描场景线程数超时时间(ms)内网资产梳理50-100800-1200公网授权扫描20-502000-3000单个主机全端口100-2001000CPU受限宿主机10-201500注意“单机全端口扫描”时线程数可以大一点因为目标只有一个连接表压力小瓶颈主要在本机。而扫“一个C段的常见端口”时目标分散但每台机器的连接表也在承受压力所以线程数要克制一些。6. 扫描报告的进阶设计把数据变成决策依据6.1 风险分级让报告不再是一堆端口列表早期的扫描报告我只输出端口列表后来看多了才发现这种报告“有数据没信息”。管理层看报告最关心的是“现在有什么风险有多严重”。所以我对报告做了分级设计。风险等级可以这么划分高危端口清单里把数据库端口3306、5432、6379、远程管理端口22、3389、23、文件共享端口445、139单拎出来标记为高危。如果banner里匹配到特定中间件的低版本也自动升高风险等级。中危端口包括常用Web端口80、443的非预期暴露比如内网测试环境把8080暴露到了外网边界。低危则是那些无身份验证信息也不常见的端口。生成报告时统计部分增加风险分布例如风险概览 高危端口: 3 中危端口: 2 低危端口: 7然后按风险等级排序输出明细。这份报告的价值立刻不一样了——安全负责人拿到后可以快速定位到最需要处理的三台主机。6.2 报告格式的取舍文本、JSON还是HTML报告格式可以按使用对象来定。文本报告适合运维同学直接看JSON报告适合交给告警平台做自动处理HTML报告适合给管理层演示有颜色标记、有统计图表观感专业。如果是给机器消费JSON是首选。下面是JSON结构的一个示例{ task: corp_internal_scan, scan_time: 2025-01-15T15:30:22, cost_seconds: 32, total_hosts: 254, online_hosts: 12, high_risk_ports: 3, hosts: [ { ip: 192.168.1.1, open_ports: [ {port: 22, service: ssh, banner: SSH-2.0-OpenSSH_8.9p1, risk: low}, {port: 80, service: http, banner: HTTP/1.1 403, risk: low} ] } ] }生成JSON在Java里有很多库可以用比如某种常用的JSON库。我建议用对象映射的方式而不是自己拼字符串因为嵌套结构一旦复杂手拼字符串很容易出错转义符、中括号、逗号漏一个都会导致整个JSON无法解析。自己封装好结构类之后序列化是自动完成的后期增删字段也方便。6.3 报告自动归档与告警联动报告生成不是终点归档才是。实际项目中我一般会每天定时跑一次扫描报告按日期命名放到固定目录同时通过HTTP回调把高危结果推送给告警平台。这个联动不是项目核心但对实际运维帮助极大。流程是定时任务每天凌晨触发扫描脚本。程序扫描完成后生成JSON报告。解析JSON筛选出risk为high的端口。调用内部告警API带上主机IP、端口、服务、banner触发工单或消息通知。这一步在Java里做起来非常顺手。只要在生成报告的模块之后加一个HTTP客户端的调用整个工具就从“被动扫描器”变成了“主动安全巡检系统”。7. 常见问题与排查技巧实录7.1 连接超时误判为端口关闭这是扫描中最容易踩的坑。本地网络环境正常时端口关闭会快速收到Connection refused但中间如果有防火墙防火墙会把你的SYN包直接丢弃表现就是长时间没有响应最后SocketTimeoutException。所以不要把“超时”和“关闭”混为一谈。在报告的字段里我把结果细分成open、closed、filtered三种状态。closed是收到了拒绝包filtered是超时不可达。实际排查时如果发现大量filtered状态基本可以断定中间存在防火墙策略或者目标主机离线。要处理这个问题可以像下面这样区分异常catch (ConnectException e) { result.put(status, closed); } catch (SocketTimeoutException e) { result.put(status, filtered); } catch (IOException e) { result.put(status, unreachable); }7.2 扫描本机扫描不到服务我第一次写扫描器时扫描127.0.0.1发现明明启动了某个服务但扫描结果却显示端口没开。排查了半天发现是服务监听的地址问题。很多程序默认监听在IPv6的地址上或者只监听localhost。Java的Socket连接目标如果写的是127.0.0.1走的IPv4协议栈如果服务端只在IPv6的::1地址上监听那就连不上。解决方法是扫描时同时探测IPv4和IPv6两种地址或者确认服务监听配置。另一个常见原因是本机防火墙放行规则。Windows和Linux自带的防火墙可能会拦截本机回环之外的连接但通常不影响127.0.0.1本身。如果连127.0.0.1都不通最可能是监听地址绑定的问题。7.3 连接数过多导致操作系统资源耗尽线程数设得太大或者并发时每个连接又长时间不释放可能导致“Too many open files”。出现这个问题时Java的IOException会频繁报错扫描结果大量超时。处理方法分两层。第一层代码层面控制并发数和连接释放。确保Socket用了try-with-resources连接创建后及时关闭。第二层操作系统层面把文件描述符上限调高。临时调整可以用ulimit -n 65535永久调整要改配置文件。这个问题在高强度扫描公网大网段时特别容易遇到。我的习惯是扫描前先看当前文件描述符使用情况如果其他服务占了很多就适当降低线程数。7.4 如何降低扫描对目标网络的影响做安全评估要记住一句话你的扫描工具是一把刀可以用来切菜也可以用来伤人。对内网做资产梳理时扫描本身就是在给网络设备制造额外的连接请求。网络设备有连接数限制的比如某些防火墙、负载均衡设备大量半连接或短连接会占用连接表导致正常业务请求被拒绝。为了降低影响我会采取这些措施单个主机的扫描并发不要太高尤其是目标网络质量一般时。扫描时段选择业务低峰期比如凌晨。先扫常见端口再根据情况决定要不要做全端口扫描。对关键生产设备可以临时通过策略白名单排除某些管理地址。7.5 不同操作系统的防火墙行为差异Windows默认防火墙会拦截大部分端口扫描除非该端口对应的程序被允许监听。所以内网有很多Windows主机时你可能发现扫描结果大量是filtered状态。这不代表主机宕了只说明防火墙策略比较严格。Linux要看发行版和iptables规则。默认没有额外规则时TCP Connect扫描得到的结果比较准确。但部分发行版开启了fail2ban等工具高频连接会触发封禁。开始扫描前我通常建议先小范围测试一下如果遇到连接被封禁的情况把并发调低或者分时段分批扫。8. 工具的使用边界与合规提醒这块内容我斟酌了很久还是决定要写。端口扫描能力本身是中性的就像一把万能钥匙——开锁师傅拿着它是职业工具别人拿着就可能违法。Java这套代码放在网络安全评估工程师手里是发现资产暴露面、排除隐患的好帮手如果用在未经授权的目标上性质就完全变了。每次在实际网络环境中运行这类工具之前必须有明确授权。这个授权可以来自内部安全管理制度可以是项目合同中的渗透测试条款也可以是客户签字的测试授权书。口头答应的不算数出了问题口说无凭。扫描范围也要严格控制。写好了扫描整个B段的能力不代表拿到授权就要扫整个B段。授权范围是哪个网段就扫哪个网段多一个IP都不碰。这种克制是对客户负责也是对自己负责。报告里涉及的数据同样需要保护。扫描报告包含了网段内主机、开放端口、服务版本这些敏感性很高的资产信息如果落到不该看的人手里等于把攻击面地图交了出去。所以报告生成后要加密存储、按需分发、定期清理。我见过有些团队扫描完把报告丢在共享目录里连权限都没设置这种做法隐患很大。再提醒一点不要把自己写的扫描工具打包成通用工具到处发。越是好用的网络探测工具越要控制传播范围。内部工具就该有内部工具的自觉——日志留痕、授权校验、用途追踪这些该加的功能一个都不能少。9. 从简单扫描到资产测绘后续还能怎么扩展这套工具最让我满意的地方是它像一个积木底座往上搭什么都方便。我后来在它基础上做了两次大的扩展思路分享给你。第一次扩展是集成了更全的服务指纹库。原来是靠端口号猜服务后来改成连接后获取banner再和几百条指纹规则做精确匹配识别率明显提升。比如识别出某个Web端口后面跑的是某版本框架配合漏洞情报就能自动给出修复建议。第二次扩展是做资产变化对比。每周跑一次扫描把结果存到数据库然后自动对比两周之间的端口变化——新增了哪些端口、关闭了哪些端口。这样任何一次非预期的端口开放都会被及时盯住。实际效果很好某次新员工部署了一个业务组件但忘了申请安全审批就是被这种周对比发现的。还可以继续扩展的方向很多把扫描能力做成Web服务给同事提供一个输入网段就能自助扫描的界面增加子域名探测、证书信息抓取或者跟内部的CMDB联动把扫描到的服务和资产登记表做自动比对。能力边界越大越要把授权和审计机制同步做好。最后说一点我的个人体会。写程序本身不难难的是一次一次扫描后怎么把结果沉淀成对业务有意义的信息。端口扫描工具的终点不是扫出65535个端口而是帮助团队看清自己的网络资产、确认风险边界让每一次告警和每一次修复都有依据。这也是为什么我会花那么多精力在报告设计上——数据最终要为人所用人看得懂、能决策工具才算真正有价值。 
长河君 · 2026/10/16 8:12:28 · 阅读 1.2k Java实现端口扫描与网络探测：从并发扫描到报告生成
1. 项目概述为什么用Java做端口扫描和网络探测先聊一个我常被问的问题做网络端口扫描网上一抓一大把现成的工具比如某知名扫描器一条命令行就能扫完一个网段为什么还要自己用Java写一套这个问题我以前也想过。后来在实际工作中遇到了几件事才改变看法。有一次某公司让我帮忙排查一批服务器对外开放的端口情况。那批机器差不多有两百台系统版本混杂有些还没装任何扫描工具临时装也不方便。更麻烦的是安全审计要求所有结果以统一格式归档必须包含端口状态、对应服务、开放时间、源IP、目标IP、协议类型、扫描耗时等十几个字段。现成工具输出格式很固定定制起来费劲。第二个场景更常见。某安全演练期间内网某些业务系统流量异常需要快速判断是不是有服务意外监听在非预期端口上。当时需要把扫描能力和内部的告警平台联动发现高危端口开放后自动触发工单。这种需求用现成工具显然不好接但用Java写一套扫描探测程序做成一个独立服务很容易就嵌入到整个安全运营流程里了。所以标题里说的“Java实现网络端口扫描和网络探测报告”本质不是一个“造轮子”的活儿而是围绕端口扫描这个基础能力做一套可定制、可集成、可生成结构化报告的技术组件。Java在网络编程这块的生态成熟Socket机制底层、并发模型清晰跑在服务器上不依赖其他运行时——只要机器有JDK拿着打包好的JAR丢上去就能跑。这篇文章里我会把整个实现思路、核心代码、运行效果、常见坑一步步拆开讲清楚。适合三类人看一是刚接触网络安全、想理解端口扫描底层原理的学生二是需要在内部网络做资产梳理和端口合规检查的运维或安全工程师三是想自己动手写一套网络探测工具的开发者。照着这篇文章你可以实现一个带并发扫描、端口服务识别和扫描报告生成的完整工具。2. 整体设计思路扫描功能背后的方案选型2.1 端口扫描的核心逻辑一次Socket连接尝试先把端口扫描的底层逻辑讲透。一台机器对外提供服务总是通过“IP地址端口号”这个组合来标示。192.168.1.10:80指的是IP为192.168.1.10的这台机器上的80号端口。如果这个端口上有程序在监听那别的主机尝试连接它时双方可以建立起一条数据通路。Java里建立这种连接最基础的方式就是Socket。new Socket() 底层会执行一次三次握手的过程。这个过程中如果端口开放Connect会成功如果端口关闭操作系统会返回Connection refused如果中间被防火墙拦截往往表现为连接超时。这里有一个很好用的特性——绝大多数网络通信库都允许设置连接超时时间。Java的Socket类提供了connect(SocketAddress endpoint, int timeout)这个重载方法意思是“我只给你X毫秒若在规定时间内连不上就不等了”。那扫描就变成一个很直白的循环拿到一个IP再从1到65535遍历端口号逐个创建Socket连接去测试。能连上说明端口开放被拒绝说明端口关闭超时说明可能被防火墙过滤或者主机不可达。这个方案虽然直白性能却很差。假设一个端口连接耗时约200毫秒超时时间单线程扫65535个端口最坏情况要3个多小时。所以必须上并发这是后面要解决的核心问题之一。2.2 方案选型TCP Connect扫描为什么是首选端口扫描常见分三种TCP Connect扫描、SYN半开扫描、UDP扫描。Java里最方便、最可靠的是TCP Connect扫描也就是完整地执行三次握手机制。其实Java天然就不适合做SYN半开扫描——因为半开扫描需要自己构造IP包绕过操作系统协议栈。Java标准库不提供这种能力真要实现得用JNI调用底层C库或者借助第三方库。对一个以“快速落地、报告清晰、集成方便”为目标的工具来说没必要为了追求那一点隐蔽性把架构搞复杂。那TCP Connect扫描有什么好处第一实现简单都是现成的API。第二结果准确度高能直接拿到端口状态、连接耗时。第三对目标系统来说这种扫描会完成完整连接所以在程序自身的日志里能看到正常的连接记录在多数内部网络环境中不敏感。在授权范围内做安全评估时TCP Connect扫描的准确性足够了。SYN扫描那种隐蔽性主要用在攻防对抗场景这超出了我们这篇文章要解决的问题。2.3 为什么用Java而不是Python聊方案选型时总有朋友问Python写扫描工具不更快吗确实Python的socket库十来行就能写一个基础扫描器很多网上的教程也是这么教的。但用Java有两个实际优势。第一部署形态不一样。Python脚本运行依赖解释器和一堆第三方库在服务器上还得pip install这个那个。Java直接打成JAR目标机器只要有JRE双击或命令行一条java -jar就能跑还能用Systemd等工具做成后台服务。第二并发能力。Python有GIL锁多线程做I/O密集任务时性能远不如Java。端口扫描这种高度I/O密集的场景Java用线程池能轻松跑几百个并发Python在类似强度下容易吃紧。实际测过同样是扫一个C段254台主机的常用端口Java用50个线程大概两三分钟扫完Python不开多进程的话会明显慢。当然不是说Python不好而是让你看清楚我为什么选Java。这个选择直接影响后面并发、超时控制、报告生成这些模块的写法。3. 核心实现拆解从单线程扫描到并发优化3.1 最简单的开始同步单端口扫描不说废话先来一个最基础的版本。这个版本逻辑非常清楚一端口一连接是后续所有高级功能的地基。import java.net.InetSocketAddress; import java.net.Socket; public class SimplePortScanner { public static void main(String[] args) { String host 127.0.0.1; int port 80; boolean isOpen checkPort(host, port, 3000); System.out.println(String.format(%s:%d is %s, host, port, isOpen ? OPEN : CLOSED)); } public static boolean checkPort(String host, int port, int timeout) { try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), timeout); return true; } catch (Exception e) { return false; } } }这段代码的逻辑很单纯new Socket()创建未连接的Socketconnect方法发起连接在timeout毫秒内没连上就抛异常。只要connect方法正常返回就说明端口开放。用try-with-resources连接结束后Socket自动关闭不会泄漏连接资源。这里有两个容易被忽略的点要特别注意。第一timeout必须设置不能省。如果不指定超时时间操作系统默认的TCP连接超时可能长达120秒。扫描遇到一个被防火墙丢弃SYN包的端口单是这一个端口就要卡两分钟。65535个端口这样扫下去一天都跑不完。第二connect方法抛出的异常类型不同可以辅助判断端口状态。ConnectException表示连接被拒绝基本确认端口是关闭的SocketTimeoutException表示超时可能是防火墙拦了也可能主机不通。这个细节在后面做结果归类时非常有价值。3.2 单机全端口扫描从for循环到线程池有了单端口检测全端口扫描就是加个循环。但还得解决效率问题。我直接给你看两个版本对比一下感受会更深。第一个版本串行循环。for (int port 1; port 65535; port) { boolean open checkPort(host, port, 2000); if (open) { System.out.println(Port port is open); } }这个版本干净直观但真要跑起来就知道多难受。假设目标网络环境没那么理想平均每个关闭端口的检测耗时约1秒有的是被拒绝有的是超时那这个for循环跑完得18个小时。如果扫描多个主机时间还会线性叠加。这显然不行。第二个版本线程池并发扫描。import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class ConcurrentPortScanner { private static final int THREAD_COUNT 100; private static final int TIMEOUT_MS 1000; public static void main(String[] args) throws InterruptedException { String host 192.168.1.10; ExecutorService executor Executors.newFixedThreadPool(THREAD_COUNT); for (int port 1; port 65535; port) { final int currentPort port; executor.submit(() - { if (checkPort(host, currentPort, TIMEOUT_MS)) { System.out.println(currentPort is open); } }); } executor.shutdown(); boolean finished executor.awaitTermination(10, TimeUnit.MINUTES); if (!finished) { System.out.println(Timeout waiting for tasks to complete); } } }这个版本的核心变化是用Executors.newFixedThreadPool创建了一个固定100线程的线程池把每个端口的扫描任务交给线程池执行。65535个端口分成100个线程去并发处理总耗时大约降为原来的百分之一。这里注意一个关键点为什么要awaitTermination而不是shutdown完事因为shutdown只是通知线程池不再接收新任务但已经提交的任务还在后台跑。awaitTermination才是真正堵塞到所有任务完成或者到达指定的等待时间。如果不等它主线程可能提前退出JVM直接把还在运行的扫描线程全部干掉了扫描结果会不完整。3.3 线程数不是越大越好并发参数怎么定看到线程池有同学可能想“那我直接开1000个线程不是更快吗”真不是这样。端口扫描这个场景虽然是I/O密集但每个Socket连接本身要消耗文件描述符。Linux下每个TCP连接都会占用一个文件描述符进程默认的文件描述符上限通常是1024用ulimit -n可以查。假如你开1000个线程并发建连接每个线程又同时跑着一个Socket文件描述符很快就耗光了然后大量任务直接抛IOException扫描结果被污染。另外还有TCP连接表的问题。大量并发连接会导致连接表短时间内被占满反而触发目标系统拒绝服务。对端口扫描工具来说把目标扫崩了绝对不是期望的结果。我的建议是这么定参数本机性能有限、目标在内网线程数20到50比较温和。目标在内网且网络状况好100到200速度可观。公网环境或者不确定目标承受能力控制在50以内宁慢勿崩。这个取舍背后其实就是安全测试里常说的“动静可控”。你是来做资产梳理的不是来压测的没必要拼速度。4. 服务识别与网络探测扫到端口之后怎么办4.1 服务指纹识别端口号并不等于服务扫到22端口就说“这是SSH服务”其实是偷懒的做法。端口号是约定俗成的但管理员完全可以把SSH改成监听在2222端口中间件也可能自动占用高位端口。所以真正要做服务识别得主动连接上去跟服务握一次手或者读取目标的欢迎信息banner。Java里实现这个很简单建立Socket连接后通过输入流读取对方返回的文本。很多服务在连接建立后会主动发送一段标志信息比如SSH服务会返回类似“SSH-2.0-OpenSSH_8.9p1”的字符串HTTP服务会返回“HTTP/1.1 200 OK”等状态行。给个核心代码片段public static String grabBanner(String host, int port, int timeout) { try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), timeout); socket.setSoTimeout(timeout); socket.getOutputStream().write(\r\n.getBytes()); socket.getOutputStream().flush(); StringBuilder banner new StringBuilder(); BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream())); String line; while ((line reader.readLine()) ! null) { banner.append(line).append(\n); if (banner.length() 512) { break; } } return banner.toString().trim(); } catch (Exception e) { return null; } }这里有个实操细节有的服务不会主动发banner需要你先发送一点数据“戳”它一下才回应。所以代码里先写入一个回车换行很多协议对这个都会有反应。另外还要注意有些服务在收到非法数据后可能会直接断开连接所以读取的时候要准备好异常处理。设setSoTimeout很重要不然如果对方一直不返回数据readLine会永久阻塞。设一个超时时间最多等这么久没数据就放弃。拿到banner后可以跟一个内置的指纹库做匹配把“SSH-2.0-OpenSSH”这类字符串归类成“SSH服务”。指纹库可以自己维护也可以参考网上公开的版本但注意不要引入一些可能有许可约束的复杂组件这个工具保持轻量才灵活。4.2 一个C段主机的网络探测流程端口扫描是一个维度网络探测是另一个维度。这里所谓的网络探测指的是一次综合性的信息收集过程——确定哪些主机在线、有哪些开放端口、运行什么服务最终形成一份网段级的资产地图。我做一个类似的项目时整体的扫描流程是这样设计的第一步先做存活探测。本机发送ICMP Ping报文或者TCP连接某个最常用端口如80、443判断主机是否在线。排除掉那些完全不可达的IP避免后续做全端口扫描浪费时间。第二步对判定为存活的主机做端口扫描。先扫常见端口比如21、22、23、80、443、445、3306、6379、8080这些速度很快先把高危端口捞出来。如果时间充裕再做全端口扫描。第三步对开放端口做服务识别获取banner并结合端口号推断服务类型。第四步生成报告。把扫描到的结果汇总按IP统计、按端口统计输出成可以归档和进一步分析的格式。这个流程看起来简单但每一步都有细节。比如ICMP探测很多云主机和Windows防火墙默认会屏蔽ICMP单纯用Ping来判断存活会漏掉大量在线主机。所以我的建议是存活探测用“ICMP TCP常见端口探测”组合的方式只要任一手段有响应就判定主机存活。4.3 扫描报告的数据结构设计做网络探测报告最难的不是数据可视化而是数据建模。报告是给人看的但中间环节的数据结构是给程序用的。我花了些时间设计一套结构分享给你。整个报告可以分三层第一层是扫描任务元信息。包括任务名称、扫描时间、扫描范围、扫描策略用了多少线程、什么超时时间、任务耗时。第二层是指定范围内的主机列表。每一台主机有IP、主机状态在线或离线、MAC地址如果条件允许获取、操作系统指纹猜测、开放端口总数。第三层是端口明细。每个开放端口需要记录端口号、协议类型、服务类型、banner样本、连接耗时、风险等级。在Java里我推荐直接用Map里嵌List再嵌Map的写法来做临时存储等全部扫描完后再序列化成JSON或文本报告。如果项目继续演进可以考虑用封装的类来定义这些结构但对于一个内部工具来说轻量级的Map结构更灵活改字段不用重新编译整个类。报告输出方面我建议同时输出两种格式JSON格式用于程序处理文本格式给人快速看。JSON序列化用现成的库也行自己拼也行关键是把层级关系理清楚。5. 实操过程完整演示从编写到运行一份扫描报告5.1 完整骨架代码一个能直接跑起来的版本前面拆了一堆概念这里给你一份能直接编译运行的完整示例。这个版本集合了线程池并发扫描、超时控制、banner识别、报告生成四个模块。为了代码可控我把它控制在一个文件内实际项目可以再按需拆分。import java.io.*; import java.net.*; import java.time.LocalDateTime; import java.util.*; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class NetworkScannerDemo { private static final int THREAD_COUNT 100; private static final int TIMEOUT_MS 1200; // 通过IP前缀扫描一个C段网段的常见端口 public static void main(String[] args) throws Exception { String ipPrefix 192.168.1; // 按实际网段修改 int[] ports {21, 22, 23, 25, 80, 110, 143, 443, 445, 3306, 3389, 6379, 8080, 9090, 9092}; MapString, ListMapString, Object reportData new ConcurrentHashMap(); long startTime System.currentTimeMillis(); ExecutorService executor Executors.newFixedThreadPool(THREAD_COUNT); for (int hostNum 1; hostNum 254; hostNum) { final String host ipPrefix . hostNum; for (int port : ports) { executor.submit(() - { MapString, Object result scanPort(host, port); if ((Boolean) result.get(open)) { String banner result.get(banner) null ? : result.get(banner).toString(); ListMapString, Object hostPorts reportData.computeIfAbsent(host, k - new ArrayList()); synchronized (hostPorts) { hostPorts.add(result); } System.out.println([OPEN] host : port - banner); } }); } } executor.shutdown(); executor.awaitTermination(30, TimeUnit.MINUTES); long costTime System.currentTimeMillis() - startTime; generateReport(reportData, costTime); } public static MapString, Object scanPort(String host, int port) { MapString, Object result new HashMap(); result.put(ip, host); result.put(port, port); result.put(open, false); long start System.currentTimeMillis(); try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), TIMEOUT_MS); result.put(open, true); socket.setSoTimeout(600); String banner readBanner(socket); result.put(banner, banner); result.put(service, guessService(port, banner)); } catch (Exception e) { result.put(error, e.getClass().getSimpleName()); } result.put(cost_ms, System.currentTimeMillis() - start); return result; } public static String readBanner(Socket socket) { try { socket.getOutputStream().write(\r\n.getBytes()); socket.getOutputStream().flush(); BufferedReader reader new BufferedReader(new InputStreamReader(socket.getInputStream())); StringBuilder sb new StringBuilder(); int totalRead 0; String line; while ((line reader.readLine()) ! null totalRead 512) { sb.append(line).append( | ); totalRead line.length(); } return sb.toString().trim(); } catch (Exception e) { return ; } } public static String guessService(int port, String banner) { if (banner ! null !banner.isEmpty()) { if (banner.contains(SSH)) return ssh; if (banner.startsWith(HTTP) || banner.contains(nginx) || banner.contains(Apache)) return http; if (banner.contains(MySQL)) return mysql; if (banner.contains(Redis)) return redis; } // 基于端口号的兜底猜测 switch (port) { case 21: return ftp; case 22: return ssh; case 23: return telnet; case 25: return smtp; case 80: return http; case 443: return https; case 3306: return mysql; case 6379: return redis; default: return unknown; } } public static void generateReport(MapString, ListMapString, Object data, long costTime) throws IOException { try (BufferedWriter writer new BufferedWriter(new FileWriter(scan_report_ System.currentTimeMillis() .txt))) { writer.write( 网络扫描报告 \n); writer.write(生成时间: LocalDateTime.now() \n); writer.write(扫描耗时: costTime ms\n); writer.write(在线主机数量: data.size() \n\n); for (Map.EntryString, ListMapString, Object entry : data.entrySet()) { writer.write(Host: entry.getKey() ( entry.getValue().size() open ports)\n); for (MapString, Object portInfo : entry.getValue()) { writer.write( - Port: portInfo.get(port) , service: portInfo.get(service) , banner: portInfo.get(banner) \n); } writer.write(\n); } } } }这段代码的组织逻辑不复杂外层循环先枚举IP和端口把每个扫描任务提交到线程池。scanPort方法负责做一次完整的端口探测连接、记录耗时、抓取banner。返回的结果Map用ConcurrentHashMap按IP分组收集起来。最后统一生成一份文本报告。要注意的是我用了ConcurrentHashMap加synchronized来保证线程安全。ConcurrentHashMap保证的是Map自身的并发安全但是“拿到一个key的List之后往这个List里添加元素”这个操作如果不额外加锁还是可能出问题。代码里对list加synchronized块就是防止多个线程同时往同一个主机的list里塞数据。如果项目里准备用更复杂的结构建议直接用CopyOnWriteArrayList能省去手动加锁的麻烦。5.2 运行效果与结果解读假设你跑在192.168.1.0/24这个网段代码输出会是这个感觉[OPEN] 192.168.1.1:22 - SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 | [OPEN] 192.168.1.1:80 - HTTP/1.1 403 Forbidden [OPEN] 192.168.1.10:3306 - 8.0.32-log [OPEN] 192.168.1.10:6379 - $3 ... 扫描结束报告文件内容大致是 网络扫描报告 生成时间: 2025-01-15T15:30:22 扫描耗时: 32481 ms 在线主机数量: 12 Host: 192.168.1.1 (2 open ports) - Port: 22, service: ssh, banner: SSH-2.0-OpenSSH_8.9p1 - Port: 80, service: http, banner: HTTP/1.1 403 Forbidden这份报告能直接拿来做资产登记。发现一个本不该开放的高危端口比如某台数据库服务器暴露了6379端口且没有密码认证那就应该立刻走告警流程。这里顺便分享一个我从实际项目里总结的经验扫描结果里出现的banner信息往往会暴露出软件的具体版本号。比如上面那个“8.9p1 Ubuntu”和“8.0.32-log”这些版本号可以直接关联到已知漏洞库。所以在设计报告结构时一定要把banner单独留一个字段而不是只写一个“服务类型”。5.3 超时参数和线程数如何配合调整前面说了线程数不能无脑调大但超时参数和线程数是配套调整的。它们共同决定了扫描的总耗时和扰动程度。你可以这样理解假设100个线程并发扫描每个端口的平均探测耗时是1秒含超时等待那么100个任务一批就是1秒。但如果你把线程数拉到200同时把超时时间从1秒降到500毫秒那每批任务耗时可能就是0.6秒左右总量不变的情况下总耗时反而缩短了因为单位时间内能处理的任务数变多了。当然这两者都不是无限优化的。超时时间设得太短比如200毫秒在公网环境下很多正常开放的端口也会因为网络RTT往返时延较高被误判为不通。内网延迟低可以设短一点公网扫描建议至少1000到2000毫秒。下面这张表是我在不同场景下的经验参数可以参考扫描场景线程数超时时间(ms)内网资产梳理50-100800-1200公网授权扫描20-502000-3000单个主机全端口100-2001000CPU受限宿主机10-201500注意“单机全端口扫描”时线程数可以大一点因为目标只有一个连接表压力小瓶颈主要在本机。而扫“一个C段的常见端口”时目标分散但每台机器的连接表也在承受压力所以线程数要克制一些。6. 扫描报告的进阶设计把数据变成决策依据6.1 风险分级让报告不再是一堆端口列表早期的扫描报告我只输出端口列表后来看多了才发现这种报告“有数据没信息”。管理层看报告最关心的是“现在有什么风险有多严重”。所以我对报告做了分级设计。风险等级可以这么划分高危端口清单里把数据库端口3306、5432、6379、远程管理端口22、3389、23、文件共享端口445、139单拎出来标记为高危。如果banner里匹配到特定中间件的低版本也自动升高风险等级。中危端口包括常用Web端口80、443的非预期暴露比如内网测试环境把8080暴露到了外网边界。低危则是那些无身份验证信息也不常见的端口。生成报告时统计部分增加风险分布例如风险概览 高危端口: 3 中危端口: 2 低危端口: 7然后按风险等级排序输出明细。这份报告的价值立刻不一样了——安全负责人拿到后可以快速定位到最需要处理的三台主机。6.2 报告格式的取舍文本、JSON还是HTML报告格式可以按使用对象来定。文本报告适合运维同学直接看JSON报告适合交给告警平台做自动处理HTML报告适合给管理层演示有颜色标记、有统计图表观感专业。如果是给机器消费JSON是首选。下面是JSON结构的一个示例{ task: corp_internal_scan, scan_time: 2025-01-15T15:30:22, cost_seconds: 32, total_hosts: 254, online_hosts: 12, high_risk_ports: 3, hosts: [ { ip: 192.168.1.1, open_ports: [ {port: 22, service: ssh, banner: SSH-2.0-OpenSSH_8.9p1, risk: low}, {port: 80, service: http, banner: HTTP/1.1 403, risk: low} ] } ] }生成JSON在Java里有很多库可以用比如某种常用的JSON库。我建议用对象映射的方式而不是自己拼字符串因为嵌套结构一旦复杂手拼字符串很容易出错转义符、中括号、逗号漏一个都会导致整个JSON无法解析。自己封装好结构类之后序列化是自动完成的后期增删字段也方便。6.3 报告自动归档与告警联动报告生成不是终点归档才是。实际项目中我一般会每天定时跑一次扫描报告按日期命名放到固定目录同时通过HTTP回调把高危结果推送给告警平台。这个联动不是项目核心但对实际运维帮助极大。流程是定时任务每天凌晨触发扫描脚本。程序扫描完成后生成JSON报告。解析JSON筛选出risk为high的端口。调用内部告警API带上主机IP、端口、服务、banner触发工单或消息通知。这一步在Java里做起来非常顺手。只要在生成报告的模块之后加一个HTTP客户端的调用整个工具就从“被动扫描器”变成了“主动安全巡检系统”。7. 常见问题与排查技巧实录7.1 连接超时误判为端口关闭这是扫描中最容易踩的坑。本地网络环境正常时端口关闭会快速收到Connection refused但中间如果有防火墙防火墙会把你的SYN包直接丢弃表现就是长时间没有响应最后SocketTimeoutException。所以不要把“超时”和“关闭”混为一谈。在报告的字段里我把结果细分成open、closed、filtered三种状态。closed是收到了拒绝包filtered是超时不可达。实际排查时如果发现大量filtered状态基本可以断定中间存在防火墙策略或者目标主机离线。要处理这个问题可以像下面这样区分异常catch (ConnectException e) { result.put(status, closed); } catch (SocketTimeoutException e) { result.put(status, filtered); } catch (IOException e) { result.put(status, unreachable); }7.2 扫描本机扫描不到服务我第一次写扫描器时扫描127.0.0.1发现明明启动了某个服务但扫描结果却显示端口没开。排查了半天发现是服务监听的地址问题。很多程序默认监听在IPv6的地址上或者只监听localhost。Java的Socket连接目标如果写的是127.0.0.1走的IPv4协议栈如果服务端只在IPv6的::1地址上监听那就连不上。解决方法是扫描时同时探测IPv4和IPv6两种地址或者确认服务监听配置。另一个常见原因是本机防火墙放行规则。Windows和Linux自带的防火墙可能会拦截本机回环之外的连接但通常不影响127.0.0.1本身。如果连127.0.0.1都不通最可能是监听地址绑定的问题。7.3 连接数过多导致操作系统资源耗尽线程数设得太大或者并发时每个连接又长时间不释放可能导致“Too many open files”。出现这个问题时Java的IOException会频繁报错扫描结果大量超时。处理方法分两层。第一层代码层面控制并发数和连接释放。确保Socket用了try-with-resources连接创建后及时关闭。第二层操作系统层面把文件描述符上限调高。临时调整可以用ulimit -n 65535永久调整要改配置文件。这个问题在高强度扫描公网大网段时特别容易遇到。我的习惯是扫描前先看当前文件描述符使用情况如果其他服务占了很多就适当降低线程数。7.4 如何降低扫描对目标网络的影响做安全评估要记住一句话你的扫描工具是一把刀可以用来切菜也可以用来伤人。对内网做资产梳理时扫描本身就是在给网络设备制造额外的连接请求。网络设备有连接数限制的比如某些防火墙、负载均衡设备大量半连接或短连接会占用连接表导致正常业务请求被拒绝。为了降低影响我会采取这些措施单个主机的扫描并发不要太高尤其是目标网络质量一般时。扫描时段选择业务低峰期比如凌晨。先扫常见端口再根据情况决定要不要做全端口扫描。对关键生产设备可以临时通过策略白名单排除某些管理地址。7.5 不同操作系统的防火墙行为差异Windows默认防火墙会拦截大部分端口扫描除非该端口对应的程序被允许监听。所以内网有很多Windows主机时你可能发现扫描结果大量是filtered状态。这不代表主机宕了只说明防火墙策略比较严格。Linux要看发行版和iptables规则。默认没有额外规则时TCP Connect扫描得到的结果比较准确。但部分发行版开启了fail2ban等工具高频连接会触发封禁。开始扫描前我通常建议先小范围测试一下如果遇到连接被封禁的情况把并发调低或者分时段分批扫。8. 工具的使用边界与合规提醒这块内容我斟酌了很久还是决定要写。端口扫描能力本身是中性的就像一把万能钥匙——开锁师傅拿着它是职业工具别人拿着就可能违法。Java这套代码放在网络安全评估工程师手里是发现资产暴露面、排除隐患的好帮手如果用在未经授权的目标上性质就完全变了。每次在实际网络环境中运行这类工具之前必须有明确授权。这个授权可以来自内部安全管理制度可以是项目合同中的渗透测试条款也可以是客户签字的测试授权书。口头答应的不算数出了问题口说无凭。扫描范围也要严格控制。写好了扫描整个B段的能力不代表拿到授权就要扫整个B段。授权范围是哪个网段就扫哪个网段多一个IP都不碰。这种克制是对客户负责也是对自己负责。报告里涉及的数据同样需要保护。扫描报告包含了网段内主机、开放端口、服务版本这些敏感性很高的资产信息如果落到不该看的人手里等于把攻击面地图交了出去。所以报告生成后要加密存储、按需分发、定期清理。我见过有些团队扫描完把报告丢在共享目录里连权限都没设置这种做法隐患很大。再提醒一点不要把自己写的扫描工具打包成通用工具到处发。越是好用的网络探测工具越要控制传播范围。内部工具就该有内部工具的自觉——日志留痕、授权校验、用途追踪这些该加的功能一个都不能少。9. 从简单扫描到资产测绘后续还能怎么扩展这套工具最让我满意的地方是它像一个积木底座往上搭什么都方便。我后来在它基础上做了两次大的扩展思路分享给你。第一次扩展是集成了更全的服务指纹库。原来是靠端口号猜服务后来改成连接后获取banner再和几百条指纹规则做精确匹配识别率明显提升。比如识别出某个Web端口后面跑的是某版本框架配合漏洞情报就能自动给出修复建议。第二次扩展是做资产变化对比。每周跑一次扫描把结果存到数据库然后自动对比两周之间的端口变化——新增了哪些端口、关闭了哪些端口。这样任何一次非预期的端口开放都会被及时盯住。实际效果很好某次新员工部署了一个业务组件但忘了申请安全审批就是被这种周对比发现的。还可以继续扩展的方向很多把扫描能力做成Web服务给同事提供一个输入网段就能自助扫描的界面增加子域名探测、证书信息抓取或者跟内部的CMDB联动把扫描到的服务和资产登记表做自动比对。能力边界越大越要把授权和审计机制同步做好。最后说一点我的个人体会。写程序本身不难难的是一次一次扫描后怎么把结果沉淀成对业务有意义的信息。端口扫描工具的终点不是扫出65535个端口而是帮助团队看清自己的网络资产、确认风险边界让每一次告警和每一次修复都有依据。这也是为什么我会花那么多精力在报告设计上——数据最终要为人所用人看得懂、能决策工具才算真正有价值。