用途
pentest-checklist 提供一份覆盖渗透测试全流程的检查清单，目标是让测试前的准备更充分、范围界定更清晰，并让发现的漏洞得到有效修复与跟进。它强调这是面向已授权安全评估、防御性验证或受控教育环境的技能，要求使用者在实施任何主动操作前完成确认。
授权确认要求
技能规定：在运行任何会探测、利用、更改、持久化、提取数据或尝试凭据访问目标的命令之前，必须先执行强制确认流程：
- 要求用户说明确切的目标 URL、IP、账号或资源；
- 要求用户确认已获得书面授权以及允许的范围；
- 展示确切的命令并解释其预期影响；
- 在当前对话中等待用户的明确确认。
如果没有该确认，就保持只读状态，仅提供防御性指导。建议优先使用沙箱、一次性虚拟机或受控实验室环境。
输入与前置条件
- 明确的测试业务目标；
- 目标环境信息；
- 预算与时间限制；
- 相关联系人及授权；
- 法律协议与范围文档。
输出与交付物
- 明确的渗透测试范围与目标；
- 准备好的测试环境；
- 安全监控数据；
- 漏洞发现报告；
- 修复计划与验证。
核心工作流
阶段一：范围定义
- 定义目标：明确测试目的（发现漏洞、合规、客户保证），验证渗透测试是否为正确方案，使结果与目标对齐并定义成功标准。
- 了解测试类型：外部渗透测试（评估外部攻击面，范围是面向公众的系统）、内部渗透测试（评估内部人员威胁风险，范围是内部网络）、Web 应用测试（查找应用漏洞，针对特定应用）、社会工程（测试人员安全，涉及员工与流程）、红队（完整对手模拟，覆盖整个组织）。
- 枚举可能威胁：识别高风险区域、评估数据敏感性、审查遗留系统、梳理关键资产以确定测试优先级。
- 定义范围：列出范围内的系统（IP、域名、应用），定义范围外项目，设定测试边界（允许哪些技术），记录排除项（第三方系统、生产数据）。
- 预算规划：考虑资产价值、复杂度、所需深度、声誉价值。技能提示：便宜的渗透测试往往效果不佳，预算应与资产关键性对齐，并考虑持续性测试与一次性测试的取舍。
阶段二：环境准备
- 准备测试环境：决定在生产还是预发环境测试，设定测试限制（不在生产环境做 DoS），安排测试窗口以降低业务影响，创建测试账号并提供适当的访问级别。环境选项包括生产（真实但有风险）、预发（更安全但可能与生产不同）、克隆（理想但资源消耗大）。
- 运行初步扫描：执行漏洞扫描器先发现已知问题，修复明显漏洞以免浪费渗透测试时间，并记录已有问题告知测试人员。文中给出的预扫描命令示例：
# Network vulnerability scan
nmap -sV --script vuln TARGET
# Web vulnerability scan
nikto -h http://TARGET
- 审查安全策略：确认合规要求（GDPR、PCI-DSS、HIPAA），记录数据处理规则，确认法律授权并获得书面许可。
- 通知托管服务商：检查服务商政策，提交授权请求（AWS、Azure、GCP 的要求），并留存批准记录。文中列出的云厂商政策链接：AWS: https://aws.amazon.com/security/penetration-testing/ ；Azure: https://docs.microsoft.com/security/pentest ；GCP: https://cloud.google.com/security/overview 。
- 冻结开发：测试期间停止部署以保持环境一致，记录当前版本与系统状态，除非安全紧急情况，避免关键补丁变更。
阶段三：专业能力选择
- 寻找合格渗透测试人员：寻求推荐、核验资质（OSCP、GPEN、CEH、CREST）、检查参考（与之前的客户沟通）、使专长与范围匹配（Web、网络、移动等专家）。评估维度包括经验、方法论（OWASP、PTES、自定义方法）、报告（样本报告与详细程度）、沟通（可用性与更新频率）。
- 定义方法论：选择测试标准（PTES、OWASP、NIST），确定访问级别（黑盒、灰盒、白盒），商定技术手段（手动还是自动化），设定沟通节奏（更新与升级）。访问级别：黑盒（无信息，模拟外部攻击者）、灰盒（部分访问，模拟有限访问的内部人员）、白盒（完全访问，内部人员或详细审计）。
- 定义报告格式：审阅样本报告以确保质量满足需求，明确必需章节（执行摘要、技术细节），要求机器可读输出（CSV、XML 以便跟踪），商定风险评级（CVSS 或自定义量表）。报告应包含：面向管理层的执行摘要、带证据的技术发现、风险评级与优先级、修复建议、复测指导。
阶段四：监控
- 实施安全监控：部署 IDS/IPS，启用日志（完整审计追踪），配置 SIEM（集中日志分析），设置告警（实时通知）。文中给出的监控命令示例：
# Check security logs
tail -f /var/log/auth.log
tail -f /var/log/apache2/access.log
# Monitor network
tcpdump -i eth0 -w capture.pcap
- 配置日志：集中日志、设定保留期、启用详细日志（应用与系统层面）、测试日志采集。需要监控的关键日志：认证事件、应用错误、网络连接、文件访问、系统变更。
- 监控异常工具：跟踪错误率（异常峰值可能意味着测试），向运维团队简报以区分测试与攻击，记录基线（正常与渗透测试活动的差异）。
- 关注安全工具：检查 IDS 告警以区分渗透测试与真实攻击，监控 WAF 日志以追踪被拦截的尝试，检查终端防护的杀毒检测。
阶段五：修复
- 确保备份：验证备份完整性并测试恢复，记录恢复流程，隔离备份访问以使其不受测试影响。
- 预留修复时间：安排团队在测试后进行分析，安排修复实施，规划验证测试以确认修复有效。
- 测试期间打补丁政策：通常避免打补丁以保持环境一致，仅对关键问题例外（安全紧急情况），任何变更都要通知渗透测试人员。
- 清理流程：移除测试残留物（后门、脚本、文件），删除测试账号与渗透测试人员访问权限，恢复配置到原始状态，审计所有变更以确认清理完成。
- 安排下一次渗透测试：确定频率（每年、每季度、变更之后），考虑持续测试（漏洞赏金、持续评估），为未来测试做预算。影响频率的因素：发布频率、监管要求、风险容忍度、历史发现严重程度。
快速参考清单
测试前检查清单：范围已定义并记录；已获得授权；环境已准备；托管服务商已通知；团队已简报；监控已启用；备份已验证。
测试后检查清单：报告已收到并审阅；发现已排定优先级；修复已分派；修复已实施；验证测试已安排；环境已清理；下次测试已安排。
限制
- 生产环境测试存在固有风险；
- 预算限制会影响彻底程度；
- 时间限制可能限制覆盖范围；
- 测试人员专业水平差异很大；
- 发现的问题会很快过时。
示例
示例一：快速范围定义
**Target:** Corporate web application (app.company.com)
**Type:** Gray box web application pentest
**Duration:** 5 business days
**Excluded:** DoS testing, production database access
**Access:** Standard user account provided
示例二：监控设置
# Enable comprehensive logging
sudo systemctl restart rsyslog
sudo systemctl restart auditd
# Start packet capture
tcpdump -i eth0 -w /tmp/pentest_capture.pcap &
常见问题排查
- 范围蔓延：记录并要求变更审批；
- 测试影响生产：安排在非工作时间，使用预发环境；
- 发现存在争议：提供详细证据并复测；
- 修复延迟：按风险排定优先级并设定截止时间；
- 预算超支：明确范围，签订固定价格合同。
何时使用
该技能适用于执行概览中所述的工作流或操作。