跳到主要内容

VulnHub 靶场笔记

这里整理 VulnHub 靶机相关的实验环境问题和通关记录索引。完整打靶过程放在具体靶机文章里；这个页面只沉淀反复会遇到的环境处理方法，方便下次快速定位。

外部入口：VulnHub 官网

靶机无法获取 IP​

有些 VulnHub 靶机导入虚拟机后，Kali 上无论用 arp-scan 还是 netdiscover 都扫不到目标 IP。这里不展开 VirtualBox NAT、桥接、Host-only 等正常网络配置，只记录一种靶机内部常见故障：系统实际识别到的网卡名，和配置文件里写死的旧网卡名不一致，导致 DHCP 没有跑起来。

典型现象​

  • 靶机正常开机，但 DHCP 没有拿到地址。
  • Kali 上 arp-scan、netdiscover 扫不到目标。
  • 靶机控制台没有明显报错，但网络服务没有把接口拉起来。
  • 进入靶机系统后，ip a 里能看到实际网卡名，但配置文件里写的是另一个名字。
  • 常见旧网卡名包括 eth0、ens33、enp0s3，实际网卡名可能变成 enp0s17、ens160 等。

快速处理流程​

  1. 通过 GRUB 进入单用户 Shell。
  2. 用 ip a 或 ip -br link 找到真实网卡名。
  3. 找到系统使用的是 Netplan 还是 ifupdown。
  4. 把配置文件里的旧网卡名替换成真实网卡名。
  5. 重启靶机，在 Kali 上重新扫描。

这个流程适合靶机没有可用账号、无法正常登录系统，但可以操作虚拟机控制台的场景。

进入单用户 Shell​

重启靶机，在 GRUB 菜单停住，选择第一项后按 e 编辑启动参数。

找到以 linux 开头的那一行：

  1. 把原来的 ro 改成 rw。
  2. 在这一行末尾追加 init=/bin/sh。
  3. 如果有 quiet，可以临时删掉，方便观察启动输出。
  4. 按 Ctrl+X 或 F10 启动。

成功后会进入一个 # 提示符的 shell。

如果文件系统仍然是只读状态，先重新挂载根目录：

mount -o remount,rw /

找到真实网卡名​

优先执行：

ip a

或者用更紧凑的输出：

ip -br link

记录当前真实网卡名，例如 enp0s17。

可以顺手查一下配置文件里写着什么旧网卡名：

grep -R "eth[0-9]\|ens[0-9]\|enp[0-9]" /etc/netplan /etc/network/interfaces 2>/dev/null

如果 grep 没有结果，不代表一定不是这个问题，只是说明配置可能在别的位置或文件内容比较特殊。

修改网络配置文件​

不同发行版使用的网络配置方式不同，按靶机实际文件选择一种即可。

Netplan 配置​

Ubuntu 新一些的版本通常使用 Netplan，配置文件一般在：

/etc/netplan/*.yaml

把里面旧的网卡名改成 ip a 看到的真实网卡名，并确保启用 DHCP。例如：

network:
  version: 2
  ethernets:
    enp0s17:
      dhcp4: true

注意 YAML 对缩进敏感，网卡名和 dhcp4 的层级不要写错。最容易出错的地方就是只改了一处网卡名，或者缩进从两个空格变成了不一致的空格。

ifupdown 配置​

Debian 或旧版本 Ubuntu 常见配置文件是：

/etc/network/interfaces

把文件里的旧网卡名替换为真实网卡名，例如：

auto enp0s17
iface enp0s17 inet dhcp

如果同一个旧网卡名出现多次，需要一起改掉。编辑器不可用时，也可以用 sed 替换，下面的 eth0 和 enp0s17 按实际情况修改：

sed -i 's/eth0/enp0s17/g' /etc/network/interfaces

重启并重新扫描​

保存配置后执行：

sync
reboot -f

靶机重启后，在 Kali 上重新扫描：

sudo arp-scan -l

也可以使用：

sudo arp-scan --localnet

如果仍然扫不到，可以再确认：

  • 靶机和 Kali 是否在同一个虚拟网络里。
  • 靶机是否真的重新读取了修改后的配置。
  • 配置文件里是否还有旧网卡名残留。
  • Netplan 的 YAML 缩进是否正确。
  • 靶机系统里是否禁用了 DHCP 客户端。
  • 是否存在多个网卡配置文件互相覆盖。