pentest-checklist

⚠️ 仅限授权使用 本技能仅用于教育目的或经授权的安全评估。 在使用本工具之前，你必须获得系统所有者的明确书面许可。 滥用本工具属于违法行为，严格禁止。

强制确认关口 在执行任何针对目标进行探测、利用、更改、驻留、提取数据或尝试访问凭据的命令之前：

1. 要求用户说明确切的目标 URL、IP、账户或资源。
2. 要求用户确认书面授权及允许的范围。
3. 展示确切的命令并解释其预期效果。
4. 在当前对话中等待明确确认。

在没有该确认的情况下，保持只读状态，仅提供防御性指导。优先使用沙箱、一次性 VM 或受控实验环境。

仅限授权使用：仅将本技能用于经授权的安全评估、防御性验证或受控教育环境。

渗透测试清单

目的

提供一份全面的清单，用于规划、执行和跟进渗透测试。确保充分准备、恰当的范围界定以及所发现漏洞的有效修复。

输入/前提条件

• 清晰的测试业务目标
• 目标环境信息
• 预算和时间线约束
• 相关方联系人与授权
• 法律协议和范围文档

输出/交付物

• 已定义的渗透测试范围和目标
• 已准备的测试环境
• 安全监控数据
• 漏洞发现报告
• 修复计划和验证

核心工作流

阶段 1：范围定义

定义目标

• 明确测试目的 - 确定目标（发现漏洞、合规、客户保证）
• 验证渗透测试的必要性 - 确保渗透测试是正确的解决方案
• 使成果与目标一致 - 定义成功标准

参考问题：

• 你为什么要进行这次渗透测试？
• 你期望获得哪些具体成果？
• 你将如何处理这些发现？

了解你的测试类型

类型	目的	范围
外部渗透测试	评估外部攻击面	面向公众的系统
内部渗透测试	评估内部威胁风险	内部网络
Web 应用	发现应用漏洞	特定应用
社会工程	测试人员安全	员工、流程
红队	完整的对手模拟	整个组织

列举可能的威胁

• 识别高风险区域 - 哪里可能发生损害？
• 评估数据敏感性 - 哪些数据可能被泄露？
• 审查遗留系统 - 旧系统通常存在漏洞
• 绘制关键资产 - 确定测试目标的优先级

定义范围

• 列出范围内系统 - IP、域名、应用
• 定义范围外事项 - 需要避开的系统
• 设定测试边界 - 允许使用哪些技术？
• 记录排除项 - 第三方系统、生产数据

预算规划

因素	考虑事项
资产价值	价值越高 = 投入越高
复杂性	系统越多 = 时间越多
所需深度	彻底测试成本更高
声誉价值	知名公司收费更高

预算现实检查：

• 廉价的渗透测试往往产生糟糕的结果
• 使预算与资产关键性保持一致
• 考虑持续测试与一次性测试

阶段 2：环境准备

准备测试环境

• 生产与暂存决策 - 确定在哪里测试
• 设定测试限制 - 不对生产环境进行 DoS
• 安排测试窗口 - 尽量减少业务影响
• 创建测试账户 - 提供适当的访问级别

环境选项：

Production  - Realistic but risky
Staging     - Safer but may differ from production
Clone       - Ideal but resource-intensive

运行初步扫描

扫描器脚本可能会执行侵入性检查；请检查选定的插件，并根据书面交战规则约束速率、时长和目标。在首次主动扫描前，准备好经过验证的备份以及紧急停止方案和联系人，而不是等到开始修复时再准备。数据包捕获内容包含敏感数据：请使用受限存储空间、限制捕获时长和数据大小，并遵循约定的保留期限。是否需要通知或获得服务提供商批准，取决于其当前服务政策；请先核实，不要假定所有提供商都要求提交申请。

• 运行漏洞扫描器 - 优先发现已知问题
• 修复明显的漏洞 - 别浪费渗透测试时间
• 记录现有问题 - 与测试人员共享

常见的扫描前工具：

# 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

冻结开发

• 测试期间停止部署 - 保持环境一致
• 记录当前版本 - 记录系统状态
• 避免应用关键补丁 - 除非出现安全紧急情况

阶段 3：选择专业人员

寻找合格的渗透测试人员

• 寻求推荐 - 询问可信来源
• 核实资质 - OSCP、GPEN、CEH、CREST
• 核查推荐人 - 联系以前的客户
• 让专业领域与范围匹配 - Web、网络、移动端专家

评估标准：

因素	要询问的问题
经验	从业年限、类似项目
方法论	OWASP、PTES、自定义方法
报告	报告样例、详细程度
沟通	响应情况、更新频率

定义方法论

• 选择测试标准 - PTES、OWASP、NIST
• 确定访问级别 - 黑盒、灰盒、白盒
• 商定技术手段 - 手动测试还是自动化测试
• 制定沟通安排 - 更新和升级机制

测试方法：

类型	访问级别	模拟对象
黑盒	无信息	外部攻击者
灰盒	部分访问权限	访问权限有限的内部人员
白盒	完全访问权限	内部人员／详细审计

定义报告格式

• 审阅报告样例 - 确保质量符合需求
• 指定必需章节 - 执行摘要、技术细节
• 要求机器可读的输出 - 用 CSV、XML 进行跟踪
• 商定风险评级 - CVSS、自定义量表

报告应包含：

• 面向管理层的执行摘要
• 附带证据的技术发现
• 风险评级和优先级排序
• 修复建议
• 复测指南

阶段 4：监控

实施安全监控

• 部署 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 日志 - 跟踪被拦截的尝试
• 检查终端防护 - 防病毒检测

阶段 5：修复

确保备份

• 验证备份完整性 - 测试恢复
• 记录恢复流程 - 确保了解如何恢复
• 隔离备份访问权限 - 防止测试影响备份

预留修复时间

• 安排团队可用时间 - 用于渗透测试后的分析
• 安排修复实施 - 处理发现的问题
• 规划验证测试 - 确认修复有效

测试期间的修补策略

• 通常避免修补 - 保持环境一致
• 关键问题除外 - 仅限安全紧急情况
• 沟通变更 - 将任何变更告知渗透测试人员

清理流程

• 移除测试产物 - 后门、脚本、文件
• 删除测试账户 - 移除渗透测试人员的访问权限
• 恢复配置 - 返回原始状态
• 确认清理完成 - 审核所有变更

安排下一次渗透测试

• 确定频率 - 每年、每季度或变更后
• 考虑持续测试 - 漏洞赏金、持续评估
• 为未来测试编制预算 - 提前规划

测试频率的影响因素：

• 发布频率
• 监管要求
• 风险承受能力
• 过往发现问题的严重程度

快速参考

渗透测试前检查清单

□ Scope defined and documented
□ Authorization obtained
□ Environment prepared
□ Hosting provider notified
□ Team briefed
□ Monitoring enabled
□ Backups verified

渗透测试后检查清单

□ Report received and reviewed
□ Findings prioritized
□ Remediation assigned
□ Fixes implemented
□ Verification testing scheduled
□ Environment cleaned up
□ Next test scheduled

限制

• 在生产环境中测试存在固有风险
• 预算限制会影响测试的全面程度
• 时间限制可能影响覆盖范围
• 测试人员的专业水平差异显著
• 发现的问题很快就会过时

示例

示例 1：快速定义范围

**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

示例 2：监控设置

# Enable comprehensive logging
sudo systemctl restart rsyslog
sudo systemctl restart auditd

# Start packet capture
tcpdump -i eth0 -w /tmp/pentest_capture.pcap &

故障排除

问题	解决方案
范围蔓延	记录变更并要求审批
测试影响生产环境	安排在非工作时间进行，使用预发布环境
对发现的问题存在争议	提供详细证据，重新测试
修复延迟	根据风险确定优先级，设定截止日期
超出预算	明确范围，签订固定价格合同

适用场景

此技能适用于执行概述中描述的工作流或操作。