自研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/ # 扫描结果与报告输出核心的技术选型我用一张表列出来。功能模块选型选择理由命令行入口argparse标准库零依赖足够用不需要引入ClickHTTP请求requests同步调试方便超时和代理控制成熟并发采集concurrent.futures标准库线程池能控制最大并发数DNS解析dnspython支持自定义DNS服务器和超时控制端口扫描python-nmap复用Nmap能力输出结构化XML好解析数据存储SQLite单机工具最合适免安装免运维报告生成Jinja2模板渲染干净换肤容易几个关键决策背后的原因。为什么不用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, encodingutf-8, errorsignore) 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, portsCOMMON_PORTS, arguments-T3 -sV): nm nmap.PortScanner() nm.scan(hostshost, portsports, argumentsarguments) 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 namegenerator contentThinkPHP 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_pathoutput/report.html): data query_scan_data(task_id) env Environment( loaderFileSystemLoader(templates) ) template env.get_template(report.html) html template.render( taskdata[task], targetsdata[targets], risksdata[risks], summarydata[summary], ) with open(output_path, w, encodingutf-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。解决方案很简单读取文件时指定encodingutf-8, errorsignore。这个细节很小但确实能卡住人半小时。6.5 User-Agent伪装与合规边界有些目标服务器会拦截默认的Python-requests User-Agent。为了拿到正常响应我在HTTP请求里把User-Agent设成了浏览器的值。这个操作本身没有争议但我坚持在代码注释里写明伪装UA只是为了获取公开可访问的信息不是绕过授权机制。如果目标明确要求阻止自动化访问就不应该硬闯这是合规底线。6.6 定时任务的稳定性工具接入cron之后我遇到了新的挑战。定时任务无人值守一旦出现异常没人及时发现。后来我在main.py里加了一个全局异常捕获任何模块抛异常都写入日志并调用Webhook通知到工作群。现在工具跑了三个月定时任务成功率稳定在98%以上剩下的2%基本是目标侧网络波动属于正常现象。7. 安全合规红线自动化工具绝不能越过的边界这一节是我认为整篇文章中最重要的一节。自动化渗透测试工具本质上是效率放大器合法使用放大效率非法使用放大风险。工具本身没有善恶但使用它的人必须清楚边界在哪里。我从项目立项第一天就给自己列了一份合规红线清单这里分享出来。一是授权明确。测试前必须有书面授权明确测试范围、测试时间、测试方法、授权方签章。这个文件是安全测试的护身符。没有它再牛的自动化工具也是非法访问的工具箱。二是范围限定。工具启动时强制校验目标是否在授权范围内不允许自由输入任意域名。这不是功能缺陷而是有意设计。授权范围之外的资产哪怕技术上一眼就能看到问题也不应该主动去碰。三是影响可控。自动化工具不能无限加速地扫。扫描参数要设计成对目标影响最小的模式一个请求失败就退避不放任自流地并发。干扰到业务运行本身就是事故。四是数据安全。测试过程中获取到的数据包括扫描结果、响应内容、审计日志都要按照最低权限原则处理。报告脱敏、存储加密、访问留痕这些都是基本要求。五是过程可审计。每一次扫描、每一个请求、每一条结果都要有日志。审计日志的留存时间要覆盖合同要求通常不少于六个月。真出了问题日志比解释更有说服力。六是应急准备。即使按规范操作也可能触发目标侧的安全告警。工具要能配合应急响应快速停止扫描、导出日志、说明情况。团队内部做自动化工具的代码评审时我甚至在代码里加了扫描目标的黑名单校验把一些明显不该测试的资产段写死在配置里。这套机制不是为了防范恶意使用而是防止手滑和AUTO PILOT状态下没有人工把关的低级失误。最后想说的是自研自动化渗透测试工具的过程远不只是写代码那么轻松。你会发现真正有工程价值的部分是老生常谈的架构设计、异常处理、数据建模而不是花哨的攻击技巧。工具最大的贡献不是替代人做决定而是把需要人花费大量时间的信息收集和整理工作自动完成让人把时间花在真正需要人类智能的深度分析上。这套代码没有停留在我的个人电脑里它已经被团队成员复用跑在每周的例行安全检查中成了团队基础设施的一部分。如果你也想从零构建类似的工具我建议从最小可用版本开始先让一个信息收集模块跑通再逐步加入检测和报告模块架构上预留好扩展点。工具是越用越顺手的这句话在自动化渗透测试工具这个场景里尤其成立。本文还有配套的精品资源点击获取