2.3 环境准备与数据库

2.3 环境准备与数据库集成

本节摘要：SOURCE 3.1：msfdb init 配置 PostgreSQL；db_status 确认连接；db_nmap 结果写入 hosts/services，供 search 与 autopwn 关联。

动手：实验 lab 初始化

数据库是 Metasploit 的"记忆皮层"。没有它，扫描结果、主机信息、凭证都会随进程退出烟消云散，渗透测试退化为一系列孤立的脚本执行。初始化步骤如下：

# 一步完成 PostgreSQL 初始化（Kali 环境）
sudo msfdb init
# 内部动作：检查/启动 PostgreSQL → 创建数据库用户 → 创建 msf 数据库 → 初始化表结构 → 写入连接配置

# 进入控制台并验证数据库链路
msfconsole -q
db_status
# [*] postgresql connected to msf

# 用 db_nmap 扫描，结果自动落库
db_nmap -sV 192.168.56.0/24

# 查看数据库资产
hosts
services
​

SOURCE 强调：无数据库则扫描结果随会话丢失，无法「指哪打哪」关联 CVE 与主机。db_status 显示 postgresql connected 是后续所有工作流的前提。

数据持久化的价值

Metasploit 选择了 PostgreSQL，因为它擅长复杂查询、事务完整性与高并发。主机与端口是一对多、服务与漏洞是多对多——这种网状结构需要关系代数引擎支撑。

框架与数据库之间隔着一层 ActiveRecord ORM。你在控制台敲 services，本质是对 Ruby 对象（如 Mdm::Host 映射 hosts 表）的操作，而不是直接写 SQL。这也让复杂筛选成为可能：比如"列出所有开放 445 端口的 Windows 主机"。

# 数据库驱动的筛选示例
services -c port,proto,name -p 445     # 只看 445 端口服务
hosts -c address,os,comments            # 自定义列
vulns                                    # 查看已记录的漏洞
​

外部扫描数据导入

框架不强制所有数据自己产生。db_import 可以解析 Nmap 的 XML、Nessus 的 .nessus 文件，把异构数据清洗映射到统一模型。Nmap 的 OS 指纹、Nessus 的插件 ID 与 CVE 编号都会被保留——这相当于把第三方侦察成果变成框架可直接消费的情报。

# 把外部扫描结果导入（示例路径）
db_import /tmp/scan-results.xml
# [+] Imported 15 hosts and 42 services
​

Workspace：多项目逻辑隔离

一位顾问可能同时服务客户 A（金融机构）与客户 B（电商）。如果数据混在一个数据库视图里，既混乱又有合规风险。Workspace 通过在数据表引入 workspace_id 外键实现逻辑隔离——同一个物理数据库，逻辑上互不干扰。

workspace -a projectA        # 新建工作区
workspace                    # 列出所有工作区
workspace -s projectA        # 切换工作区（旧语法 -x 亦可）
workspace -d projectA        # 删除工作区
​

切换工作区时，框架自动在所有查询注入 WHERE workspace_id = current。资源脚本也可以显式指定 workspace，实现"脚本 A 只碰项目 A"的细粒度控制。

数据驱动的决策链

数据库的最高价值是驱动决策。记录到"目标 80 端口跑 Apache 2.4.49"之后，框架通过 references 表把服务版本与 CVE 编号、MSF 模块建立映射。用 search 定位模块时，不再是盲目翻目录，而是基于已知情报精准命中：

成功渗透后，Loot（战利品）与 Credentials（凭证）也结构化入库，可通过 creds 检索。这些凭证能被 auxiliary/scanner/smb/smb_login 等模块自动调用——"一次获取，全处使用"，这是横向移动的战术优势。

故障排查与调优

遇到 "Database connection failed"，按网络层到应用层的顺序排查：

# 1. 确认 PostgreSQL 在监听 5432
ss -lnt | grep 5432
# 2. 检查连接配置
cat ~/.msf4/database.yml        # 用户名/密码/连接串
# 3. 远程连接还需在 pg_hba.conf 配置访问控制
​

数据量涨到百万行时，services 查询可能变慢。高级用户可直接连库建索引：

CREATE INDEX idx_hosts_address ON hosts(address);
CREATE INDEX idx_services_port ON services(port);
​

定期执行 VACUUM 和 ANALYZE 清理死元数据、更新统计信息，能保持数据库健康。

工作区隔离要点

• 项目 A/B 用不同 workspace：workspace -a projectA，防止数据串扰与误操作
• 实验快照 VM 后再跑 exploit，失败可回滚
• 项目结束归档而非物理删除，保留审计证据

⚠️ 常见坑：PostgreSQL 未启动时 silently 降级无 db——每次进 console 先 db_status。如果 msfdb init 报端口占用，多半是旧实例未清干净。

💡 关键直觉：数据库是 MSF 的「态势感知内存」。扫描、导入、利用、取证都围绕它转；把 db_status 变成肌肉记忆，能省掉后面无数"为什么没数据"的排查时间。

要点串联

• msfdb 一键初始化 Kali 环境，内部自动编排 PostgreSQL
• db_nmap 桥接 Nmap 与 MSF，扫描结果直接成为数据库资产
• workspace 隔离客户/实验数据，ORM 层让数据可编程查询
• 决策链：服务版本 → CVE 映射 → exploit 候选，情报驱动而非盲目试错

手动连接与多库切换

msfdb init 是自动化路径，但理解手动连接能帮你应对非标准环境（比如团队共享数据库）：

# 手动连接 PostgreSQL（示例参数）
msfconsole -q
db_connect msf:password@127.0.0.1:5432/msf
# 语法：db_connect <user>:<pass>@<host>:<port>/<dbname>

# 验证连接
db_status
# [*] postgresql connected to msf
​

如果环境里已有外部 PostgreSQL（如团队统一数据库），用 db_connect 比重新 init 更合适。需要访问控制时，在服务器 pg_hba.conf 中放行 Metasploit 主机的 IP 即可。

凭证与 Loot 的结构化管理

数据库不只是存主机和端口，还存渗透中获取的"战利品"：

# 会话建立后，把屏幕输出与文件归档为 loot
meterpreter > getuid
# Server username: NT AUTHORITY\SYSTEM
meterpreter > run post/windows/gather/hashdump
# [+] 192.168.56.10 - Saved dump file to /root/.msf4/loot/...

# 回到控制台查看
loot
# host         service  type     name  content  info
# 192.168.56.10          windows.hashes    NTDS hashes dumped
creds
# 数据库中的凭证可被 smb_login 等模块复用
​

这些数据都带主机关联与时间信息，是后续报告与审计的直接素材。结构化存储的价值在于：一次获取，处处可查、可复用、可归档。

常见故障速查

# 快速自检三连
ss -lnt | grep 5432        # 数据库在监听吗
db_status                   # 框架连上了吗
hosts | head                # 数据入库了吗
​

记住：数据库是 MSF 的"态势感知内存"，一切情报都围绕它组织。把它视为基础设施的一部分，而非可选项。