自研Python自动化渗透测试工具：架构设计、模块实现与合规实践

简介：这是一套面向网络安全初学者与渗透测试实践者的Python自动化渗透测试工具集，聚焦Web资产探测、漏洞扫描与报告生成等核心场景，助力安全人员高效开展红队演练与系统加固。压缩包共22个文件，含11个Python脚本（如webmap.py用于网络拓扑绘制、scanandverif.py执行扫描验证）、5个文本说明文件（含README.md与资源内容说明）、2个JS和2个CSS前端资源（支撑可视化报告展示），以及Core核心模块、wordlists字典库、bin可执行入口和report结果输出目录，结构完整、功能闭环。资源包仅59KB，轻量易部署，已吸引107人学习下载。用户可直接运行工具完成目标识别、弱口令检测、漏洞汇总与HTML格式报告生成，配套清晰的安装指引与参数说明，特别适合理解渗透测试流程、掌握Python安全工具开发范式及开展教学实验。 前阵子整理电脑里的安全工具目录，发现自己用Python写的自动化渗透测试工具，已经从最开始的几百行脚本膨胀成了带子模块、带数据库、带报告模板的小项目。它解决的问题很朴素：把授权渗透测试里那些重复、机械、容易出错的环节，比如资产枚举、端口探测、页面抓取、指纹识别、结果汇总，交给脚本去跑，让人把精力留在分析、验证和修复建议上。这篇文章把整个工具的思路、结构、关键模块和踩坑记录完整拆一遍，给打算自建自动化渗透测试工具的人一个可参考的起点。如果你熟悉Python基础，日常做安全测试，或者负责公司资产的例行风险评估，这篇文章正好对胃口。

1. 缘起：为什么安全团队需要一套自己的自动化渗透测试工具

先说个场景。做过授权渗透测试的人都懂，真正花时间的不只是找漏洞，更多是耗在前期准备和后期整理上。拿到一个目标资产范围，第一件事是枚举子域名、确认IP归属、扫端口、识别服务、抓页面、看指纹，这些动作如果全靠手动，一个中大型目标往往要花掉大半天。等真的发现问题了，又要手工记录、截图、评级、写报告。真正让专业测试人员产生价值的分析思路，反而被这些重复劳动挤占了。

当时我考虑过三个方案。

第一，买商业扫描器。价格不便宜，而且规则对我们是黑盒，有些检测项不适合我们的业务场景，想定制要等厂商排期。第二，直接拼开源工具。像Nmap、Masscan、httpx、ffuf这些单点能力都很强，但它们的输出格式各不相同，组合起来要写一堆胶水脚本，扫完一轮还要手工汇总数据。第三，自己用Python写。好处是想要什么功能就加什么，输出格式完全由自己控制，还能直接对接内部的通知机器人、工单系统。

我最后选了第三条路，但这里有个前提必须先讲清楚：这套工具只用于两类场景，一类是自己公司拥有或运维的资产，另一类是拿到客户书面授权、明确了测试范围和时间的项目。没有授权就跑自动化扫描，性质就是越权访问，工具再先进也不能碰这条线。

自研工具还有一个容易被忽略的价值：过程可审计。商业工具跑了什么请求，很多时候你不一定能拿到完整明细，但自研工具的每一个HTTP请求、每一次DNS查询，都走自己的日志模块，全部落到数据库里。出了问题可以回溯，出了争议可以拿日志自证，这在合规要求越来越严的环境下，对安全团队来说是实打实的刚需。

适用读者我也想清楚了：一个是刚接触Web安全测试，想搞懂工具内部逻辑的Python开发者；另一个是已经在做渗透测试，想把手头流程自动化、减负的工程师。前者能学到模块拆分和请求分析的基本套路，后者能找到可以直接改改就用的框架。

2. 整体架构与关键技术选型：先把模块边界画清楚

动手写代码之前，我花了一天时间画模块边界。自动化渗透测试工具最容易犯的错，是把所有功能塞进一个文件里，最后代码超过三千行，改一处要翻半天。我的做法是分层设计，每一层只管自己的事。

工具目录结构最终长这样：

pentool/ ├── main.py # CLI入口，参数解析与模块调度 ├── config.yaml # 目标、授权范围、并发数、超时等配置 ├── requirements.txt ├── modules/ │ ├── collector.py # 信息收集：子域名、端口、指纹 │ ├── detector.py # 基础探测与响应分析 │ ├── verifier.py # 单点验证，只接收指定目标的指定任务 │ ├── reporter.py # 报告生成 │ └── audit.py # 审计日志 ├── storage/ │ ├── db.py # SQLite初始化与读写 │ └── models.py # 数据表结构定义 ├── data/ │ ├── subdomain_dict.txt # 子域名词典 │ └── fingerprint.yaml # 指纹规则 └── output/ # 扫描结果与报告输出

核心的技术选型，我用一张表列出来。

几个关键决策背后的原因。

为什么不用MySQL而用SQLite。这套工具的部署场景就是一台跑测试的机器，没必要多带一个数据库服务。SQLite单文件存储，备份方便，并发读写对单机工具来说完全够用。唯一要注意的是SQLite写入锁，我开头几个月经常遇到"database is locked"，后来统一用WAL模式，并把所有写入操作封装在db.py里，问题就解决了。

为什么CLI而不是Web界面。Web界面看着高级，但一个命令行工具的价值在于可以被其他系统调用。我把它接进公司的定时任务，每周自动对核心资产做一次例行巡检，结果直接推送给相关负责人。如果做成Web服务，反而要额外考虑鉴权、会话管理、前端维护这些负担。CLI接口配合cron，是最省事的自动化路径。

为什么把audit.py单独拆一个模块。这是合规要求逼出来的。每个请求最好都留下记录，说明什么时候、对什么目标、发起了什么动作。如果审计逻辑散落在各个模块里，很容易漏记。单独拆出来之后，所有出口请求统一走audit.log_request()，后面出问题查日志非常方便。

架构定完之后，我的代码底线也定了：信息收集模块负责把资产面摸清楚，探测模块只做最小的验证请求，verifier模块坚持"单任务单目标"，绝不提供批量爆破入口。这个边界后面细讲。

3. 信息收集模块：从资产枚举到指纹识别的脚本化

信息收集是自动化渗透测试工具里投入产出比最高的部分。它不涉及攻击行为，只是通过公开的DNS解析、端口探测和HTTP请求把目标资产摸清楚，所以我把第一个完整功能就选在这里。

3.1 子域名枚举与存活验证

子域名枚举的基础思路是字典爆破加DNS解析。我维护了一份常用子域名词典，大概两万行，覆盖dev、test、api、admin这类常见前缀。核心逻辑不复杂，逐行读取字典，拼上主域名后做A记录解析，解析成功的就认为子域名可能存在。

代码大致长这样：

import dns.resolver resolver = dns.resolver.Resolver() resolver.nameservers = ['8.8.8.8', '223.5.5.5'] resolver.timeout = 5 resolver.lifetime = 8 def enum_subdomains(domain, wordlist_path): found = [] with open(wordlist_path, encoding='utf-8', errors='ignore') as f: for line in f: sub = line.strip() if not sub: continue fqdn = f"{sub}.{domain}" try: answers = resolver.resolve(fqdn, 'A') ips = [str(r) for r in answers] found.append({"domain": fqdn, "ips": ips}) except Exception: # 解析失败的原因很多：域名不存在、超时、DNS临时故障 # 这里直接跳过，不打印避免刷屏 continue return found

这里有几个细节值得说。

第一，DNS服务器固定用公共DNS，不要走系统默认配置，否则容易受本机网络环境影响。第二，lifetime参数必须设置，否则个别域名解析卡住会拖死整个枚举流程。第三，解析失败不代表域名一定不存在，可能是DNS临时故障，因此我后续会加一轮去重和二次确认，对疑似失败的高价值前缀做重试。

子域名枚举完成后，紧接着要过滤掉不存在的域名。做法是再发一次ANY或者A记录查询，并配合HTTP请求验证，能返回HTTP响应的才算真正存活的Web资产。这一步能过滤掉大量解析成功但早已下线的主机。

3.2 端口探测与服务识别

端口扫描这块，我一开始想过自己写TCP连接探测，但对比之后还是回到了Nmap。原因很简单，Nmap的指纹库和探测算法经过十几年打磨，自研很难超越，而且python-nmap这个库把XML结果解析成了Python对象，直接遍历就行。

关键配置是控制扫描范围。对Web渗透测试来说，最常用的端口就是那二三十个，像21、22、23、25、53、80、443、3306、3389、6379、8080、8443这些。我按业务场景把它们分类，默认只扫这些端口，避免全端口扫描带来的时间和流量开销。

import nmap COMMON_PORTS = "21,22,23,25,53,80,110,143,443,3306,3389,5432,6379,8080,8443,9000" def scan_ports(host, ports=COMMON_PORTS, arguments="-T3 -sV"): nm = nmap.PortScanner() nm.scan(hosts=host, ports=ports, arguments=arguments) result = [] for host in nm.all_hosts(): for proto in nm[host].all_protocols(): port_list = nm[host][proto].keys() for port in port_list: state = nm[host][proto][port].get("state") service = nm[host][proto][port].get("name", "") version = nm[host][proto][port].get("version", "") result.append({ "host": host, "port": port, "service": service, "version": version, "state": state, }) return result

扫描参数里我只用了-T3和-sV，没有加-p-全端口，也没有放开-O做操作系统识别。原因一是授权测试要控制对目标的影响，全端口扫描容易被对方的流量监控设备盯上；二是-sV的版本识别信息对漏洞研判已经足够，操作系统识别交给后续指纹模块去推断，不额外增加探测包。

3.3 Web指纹识别

指纹识别的思路是提取目标HTTP响应里的几个特征，和已知指纹规则比对。我主要看三处：响应头里的Server和X-Powered-By字段、页面HTML里的生成器标签、以及favicon图标哈希。

响应头识别最简单，拿到headers字典直接查。常见Web服务器的指纹一眼就能看出来，比如nginx/1.18.0、Apache/2.4.29。有些业务系统会在HTML里写<meta name="generator" content="ThinkPHP 5.0.24">，这也是很明确的指纹特征。favicon哈希这类识别，我会把目标站点favicon的MD5值和公开指纹库比对，命中概率相当高。

指纹识别的代码不复杂，核心是做好超时和异常兜底。我踩过的坑是请求目标首页时偶尔会触发重定向，导致请求被带到登录页，抓到的指纹是登录页框架而不是目标应用本身。解决方案是记录重定向链路的最终URL，并和原始URL对比，当作一个辅助判断条件。

4. 探测与验证模块：如何让检测器既高效又不出格

信息收集做完之后，工具就有了目标资产的完整画像：有哪些子域名、哪些端口开着、跑的是什么服务。接下来进入探测环节，这一步最敏感，也最考验设计功力。我的原则是：探测模块只做"最小验证"，不做"利用"。

4.1 探测器的设计原则

我给自己定了几条硬规则，写死在模块注释里，也写进了代码逻辑。

第一，单请求验证优先。一个检测项最多发两三个请求，能确认就确认，不能确认就标记为待人工审核，绝不为了验证自动发大量变体请求。第二，不做任何利用动作。探测的目的只是确认"目标是否存在某种异常响应"，而不是把异常变成实际危害。第三，所有请求进入审计日志。谁在什么时间对什么目标发起了什么请求，全部可回溯。

基于这几条规则，我把探测器抽象成了一个函数：给定一个目标URL和一个检测逻辑，返回检测结果。检测逻辑本身不是写死的规则库，而是一套响应分析框架。

4.2 响应分析的四个维度

一个探测请求发出去，返回的响应可以从四个维度判断：状态码、页面长度、关键字、响应时间。单独看任何一个维度都可能误判，组合起来可靠性就好很多。

def analyze_response(resp, baseline): result = {} # 维度一：状态码 result["status_code"] = resp.status_code # 维度二：页面长度 result["content_length"] = len(resp.content) # 维度三：关键字，这里只做示例，正则匹配逻辑由具体检测项决定 # result["keyword_hit"] = bool(re.search(pattern, resp.text)) # 维度四：响应时间，取秒，保留三位小数 result["response_time"] = round(resp.elapsed.total_seconds(), 3) # 与baseline对比，记录偏差 result["length_diff"] = ( result["content_length"] - baseline["content_length"] if baseline else 0 ) return result

这个函数本身不包含任何攻击逻辑，它就是一个通用工具。真正有价值的检测项，是在这个框架之上，由人根据业务场景和专业知识去配置判断规则。比如某个检测项发现响应状态码从200变成了403，页面长度明显缩短，说明请求被安全设备拦截了，这本身就是一条值得关注的信号。

响应时间这个维度很容易被忽略，但它对判断服务是否异常很有用。正常情况下接口响应稳定在200毫秒，某个探测请求突然耗时5000毫秒，很可能说明这个请求触发了某个自定义逻辑，比如日志拦截、慢查询注入、或者业务规则里的异常分支。这类信号单看没有结论，但可以筛选出来交给人进一步分析。

4.3 范围限制与审计兜底

自动化工具最大的风险不是功能不够，而是误用。我在代码层面对探测范围做了三重限制。

配置文件里写死了允许探测的目标列表：

scope: allowlist: - "*.example.com" - "10.0.0.0/24" denylist: - "10.0.0.5"

启动时，模块会先校验传入的目标是否在allowlist里，不在直接拒绝运行。这个逻辑阻止了"拿到工具随便输个网址就跑"的情况。虽然对懂技术的人来说改配置文件不难，但它提供了一个明确的提示：工具只设计给授权范围使用。

审计日志模块记录每一次探测请求的目标、时间、User-Agent、参数，以及模块名。日志表结构很简单，就是一个audit_logs表，但它的作用是整个工具合规性的根基。有一次客户问我们某个时间点有没有对他们的某个端口发起过连接，我直接SQL查询三秒钟给出答案，客户当场就放心了。

5. 结果存储与报告生成：自动化测试的可追溯闭环

信息收集和探测的数据如果没有存储和管理，测试做完就散了。所以从最开始，我就坚持所有结果都要落库。这样不光能生成报告，还能做历史数据的对比分析。

5.1 SQLite表结构设计

我设计了几张核心表：targets存目标资产信息，scan_results存每次探测的结果，vulnerabilities存确认的风险项，audit_logs存审计日志，scan_tasks存每一次任务运行的元信息。建表语句大概是这样的：

CREATE TABLE targets ( id INTEGER PRIMARY KEY AUTOINCREMENT, domain TEXT NOT NULL, ip TEXT, port INTEGER, service TEXT, version TEXT, fingerprint TEXT, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE scan_results ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id INTEGER, target_id INTEGER, check_name TEXT, severity TEXT, status TEXT, evidence TEXT, created_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE TABLE audit_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id INTEGER, time TEXT, action TEXT, target TEXT, detail TEXT );

evidence字段很重要，它记录的是原始证据，比如一段响应片段、一个响应头内容、或者一张响应截图路径。没有证据的风险项就是裸奔，报告里写再多结论都没说服力。后续如果要做趋势分析，scan_tasks和scan_results两张表联合查询就能看出同一个目标前后几次扫描的风险变化。

5.2 去重与置信度处理

自动化测试跑起来之后，结果里会混入大量重复项和低置信度项。比如同一个Web应用，同时被端口扫描和Web指纹识别标记了，两个模块各自上报，报告里就会出现两条。

我的处理办法是建一个统一的置信度机制。每个检测项在提交结果时，附带一个置信度评分，0到100之间。只有置信度高于80的才自动进入"待确认风险"列表，低于80的统一归入"需人工复核"列表。定期脚本会遍历scan_results表，按target_id和check_name分组去重，保留置信度最高的那条记录。这套机制救了我很多次，至少避免了"同一个问题在报告里出现三遍"的尴尬。

5.3 用Jinja2生成HTML报告

报告生成我用Jinja2，因为模板可维护性比直接拼HTML字符串好太多。一个报告模板包含这几部分：任务概述、目标范围、资产清单、风险发现、证据附件、修复建议。

报告生成的核心逻辑，就是把数据库里查出来的数据传给模板：

from jinja2 import Environment, FileSystemLoader def generate_report(task_id, output_path="output/report.html"): data = query_scan_data(task_id) env = Environment( loader=FileSystemLoader("templates") ) template = env.get_template("report.html") html = template.render( task=data["task"], targets=data["targets"], risks=data["risks"], summary=data["summary"], ) with open(output_path, "w", encoding="utf-8") as f: f.write(html) return output_path

报告里的风险等级我用统一的评定规则：结合资产重要性、漏洞类型的通用评分、以及实际可利用性三个因素综合判断。自动化工具算出来的等级是一个参考值，最终评级需要人工确认。这个原则我在报告模板里写明，避免生成一份看起来全是"高危"但实际没有验证的吓人报告。

生成的报告除了给人看，还直接对接了内部工单系统。任务结束后，脚本会调用工单接口，把高危项自动创建成待处理任务，分派给对应负责人。整个闭环跑通之后，从扫描到风险同步到责任人的时间从原来的半天缩短到了20分钟。

6. 实跑调试记录：超时、并发与去重这几个老问题

工具从能跑到跑稳，中间经历了不少波折。这里记录几个印象最深刻的坑，都是实际项目里真实踩过的，给各位做个参考。

6.1 超时问题：requests不设置timeout的后果

最开始写HTTP请求模块的时候，我偷懒没有统一设置timeout，结果遇到一个响应特别慢的目标，整个扫描进程卡了十分钟。更糟糕的是，线程池里其他任务也被阻塞，半天下来只扫了几个目标。后来我做了两件事：第一，所有requests请求统一走一个封装函数，默认设置timeout=(3, 5)，分别代表连接超时和读取超时；第二，DNS解析也加了lifetime限制。这才彻底解决卡死问题。

6.2 并发控制：线程数不是越大越好

刚开始用ThreadPoolExecutor，我图快把max_workers设成了30，结果目标服务直接返回503，我们的出口IP还被对方临时封了一段时间。后来我把默认并发数降到10，并在配置里暴露出来，让使用者根据目标承受能力自行调整。自动化测试不是越猛越好，对目标的影响也要控制在合理范围内，这本身就是专业性的体现。

6.3 结果去重：同一个问题别报告三遍

信息收集阶段，同一个IP可能对应多个域名，同一个域名可能同时被多个子域名枚举线程扫到。如果不去重，最终报告会非常难看。我加了一个组合去重逻辑：以"目标IP加端口加问题类型"作为唯一键，后续记录和它一样就不再重复入库，而是增加一个occurrence_count字段计数。这样报告里能看到该问题出现的频次，但不会影响阅读体验。

6.4 字典文件编码：Windows下的大坑

我最初在自己Mac上开发的，子域名词典是UTF-8编码，一切正常。后来同事在Windows上跑，直接报UnicodeDecodeError。解决方案很简单，读取文件时指定encoding='utf-8', errors='ignore'。这个细节很小，但确实能卡住人半小时。

6.5 User-Agent伪装与合规边界

有些目标服务器会拦截默认的Python-requests User-Agent。为了拿到正常响应，我在HTTP请求里把User-Agent设成了浏览器的值。这个操作本身没有争议，但我坚持在代码注释里写明：伪装UA只是为了获取公开可访问的信息，不是绕过授权机制。如果目标明确要求阻止自动化访问，就不应该硬闯，这是合规底线。

6.6 定时任务的稳定性

工具接入cron之后，我遇到了新的挑战。定时任务无人值守，一旦出现异常没人及时发现。后来我在main.py里加了一个全局异常捕获，任何模块抛异常都写入日志，并调用Webhook通知到工作群。现在工具跑了三个月，定时任务成功率稳定在98%以上，剩下的2%基本是目标侧网络波动，属于正常现象。

7. 安全合规红线：自动化工具绝不能越过的边界

这一节是我认为整篇文章中最重要的一节。自动化渗透测试工具本质上是效率放大器，合法使用放大效率，非法使用放大风险。工具本身没有善恶，但使用它的人必须清楚边界在哪里。

我从项目立项第一天就给自己列了一份合规红线清单，这里分享出来。

一是授权明确。测试前必须有书面授权，明确测试范围、测试时间、测试方法、授权方签章。这个文件是安全测试的护身符。没有它，再牛的自动化工具也是非法访问的工具箱。

二是范围限定。工具启动时强制校验目标是否在授权范围内，不允许自由输入任意域名。这不是功能缺陷，而是有意设计。授权范围之外的资产，哪怕技术上一眼就能看到问题，也不应该主动去碰。

三是影响可控。自动化工具不能无限加速地扫。扫描参数要设计成对目标影响最小的模式，一个请求失败就退避，不放任自流地并发。干扰到业务运行，本身就是事故。

四是数据安全。测试过程中获取到的数据，包括扫描结果、响应内容、审计日志，都要按照最低权限原则处理。报告脱敏、存储加密、访问留痕，这些都是基本要求。

五是过程可审计。每一次扫描、每一个请求、每一条结果都要有日志。审计日志的留存时间要覆盖合同要求，通常不少于六个月。真出了问题，日志比解释更有说服力。

六是应急准备。即使按规范操作，也可能触发目标侧的安全告警。工具要能配合应急响应，快速停止扫描、导出日志、说明情况。

团队内部做自动化工具的代码评审时，我甚至在代码里加了扫描目标的黑名单校验，把一些明显不该测试的资产段写死在配置里。这套机制不是为了防范恶意使用，而是防止"手滑"和"AUTO PILOT"状态下没有人工把关的低级失误。

最后想说的是，自研自动化渗透测试工具的过程，远不只是写代码那么轻松。你会发现，真正有工程价值的部分是老生常谈的架构设计、异常处理、数据建模，而不是花哨的攻击技巧。工具最大的贡献不是替代人做决定，而是把需要人花费大量时间的信息收集和整理工作自动完成，让人把时间花在真正需要人类智能的深度分析上。这套代码没有停留在我的个人电脑里，它已经被团队成员复用，跑在每周的例行安全检查中，成了团队基础设施的一部分。如果你也想从零构建类似的工具，我建议从最小可用版本开始，先让一个信息收集模块跑通，再逐步加入检测和报告模块，架构上预留好扩展点。工具是越用越顺手的，这句话在自动化渗透测试工具这个场景里，尤其成立。

本文还有配套的精品资源，点击获取