pentest-checklist

渗透测试清单

目的

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

输入/前提条件

• 明确的测试业务目标
• 目标环境信息
• 预算和时间线限制
• 利益相关方联系人和授权
• 法律协议和范围文档

输出/交付物

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

核心工作流

阶段 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
• 确定访问级别 - 黑盒、灰盒、白盒
• 就技术手段达成一致 - 手动测试 vs. 自动化测试
• 设定沟通计划 - 更新与升级

测试方法：

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

定义报告格式

• 审阅示例报告 - 确保质量满足需求
• 指定必需章节 - 执行摘要、技术细节
• 要求机器可读输出 - 用于跟踪的 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

配置日志记录

• 集中管理日志 - 从所有系统聚合
• 设置保留期限 - 保留日志以供分析
• 启用详细日志记录 - 应用和系统级别
• 测试日志收集 - 验证所有来源正常工作

需要监控的关键日志：

• 身份验证事件
• 应用错误
• 网络连接
• 文件访问
• 系统变更

监控异常工具

• 跟踪错误率 - 异常峰值表明存在测试
• 向运营团队通报 - 区分测试与攻击
• 记录基线 - 正常活动 vs. 渗透测试活动

关注安全工具

• 查看 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 &

故障排查

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