2. NodeSeek
  3. CloudCone 没有登录密钥的情况下更改了网络配置文件

CloudCone 没有登录密钥的情况下更改了网络配置文件

cobalt 2026-06-25 00:01 1

结论：CC 应该是通过类似于全盘镜像的形式，用镜像修改工具，自动化批量替换了网络配置文件，达到了无感更换 IP 地址。


CloudCone 也就是 CC 在一个多月之前开始提醒要更换机房和 IP 了，因为小鸡没太用所以一直没怎么管，今天下午给发来了已经更换 IP 的邮件，所以今天晚上就尝试连接。


刚开始用原 IP 连接发现已经连不上了，于是就到控制台找到了新 IP，然后 ssh 就连上了。测了个速发现下载速度好像没有之前 MC 机房快了，虽然 speedtest 软件里面显示 IP 还是 MC 的，不过具原因还得后面再排查一下。


接着突然想到我没有手动更换新 IP 呀，而且系统也是 DD 的 Debian 官方原版镜像，不存在什么 CC 的外控软件，难道是 DHCP 自动获取了新 IP？于是就找到了网络配置文件位置 /etc/network/interfaces，进去看到配置文件还是 DD 系统的时候写的固定 IP 和网关地址，不过 IP 和网关已经是新的了。


那 CC 是怎么做到迁移之后，在没有登录密码和密钥的情况下，把网络配置文件修改成了新的。接着在 Gemini 的辅助下分析出来，理论上外人确实没有办法远程修改网络配置文件，但是如果有整个系统镜像的话是可以做到的。


分析过程如下：



  1. 查看文件修改时间


root@watergodfm:/etc/network# stat /etc/network/interfaces

  File: /etc/network/interfaces

  Size: 486       	Blocks: 8          IO Block: 4096   regular file

Device: 254,1	Inode: 787031      Links: 1

Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Access: 2026-06-24 17:02:43.540000000 +0800

Modify: 2026-06-24 17:02:30.198894962 +0800

Change: 2026-06-24 17:02:30.198894962 +0800

 Birth: 2026-02-04 14:56:46.148000000 +0800

这里可以看到今天下午 17:02 网络配置文件被访问和修改了。



  1. 查看重启记录


root@watergodfm:/etc/network# last reboot

reboot   system boot  6.1.0-42-cloud-a Wed Jun 24 17:02   still running

这里可以看到在同一时间，系统有被启动的记录。


所以到这里就破案了，CC 应该是通过类似于全盘镜像的形式，用镜像修改工具，自动化批量替换了网络配置文件。


Gemini：


挂载虚拟磁盘（离线修改）

如果你的 VPS 在更换 IP 的过程中发生过闪断、强制重启，服务商可能使用了这种方式：



运作机制：服务商的控制后台在更换 IP 时，会先暂停你的虚拟机，然后直接在母机上将你的虚拟硬盘（如 .qcow2 或 raw 镜像）挂载到母机的临时目录中。



能力：母机直接无视你系统内的任何加密和密钥，直接像读写 U 盘一样修改你硬盘里的 /etc/network/interfaces 文件，修改完后再取消挂载并开机。

这个东西也好理解，就和 Windows 系统一样，只要没有开启 bitlock 全盘加密，就可以用 PE 系统进去看到硬盘里面的所有内容。


这个东西说起来也没什么影响，弄的过程中突然想到就排查了一下，如果真的想防止的话，可以开启系统自带的全盘加密功能。这样除非有登录密码或者密钥，其他请情况下就不太可能看到或修改硬盘内容了。

最新回复 (6)
  • 403Forbidden 06-25 00:02
    1楼

    看看是不是cloud-init qeme-agent这类

  • cobalt 楼主 06-25 00:06
    2楼

    @403Forbidden #1 这个排查了，看到这些进程是停止状态的

  • 403Forbidden 06-25 00:07
    3楼

    @cobalt #2 发布于6/25/2026, 12:06:19 AM

    @403Forbidden #1 这个排查了，看到这些进程是停止状态的


    只在开机会运行

  • cobalt 楼主 06-25 00:22
    4楼

    @403Forbidden #3

    嗯嗯，查了一下，

    我用命令找了一下，没有 cloud-init 的文件。


    root@watergodfm:/etc/network# ls /etc/cloud
    
ls: cannot access '/etc/cloud': No such file or directory
    
root@watergodfm:/etc/network# ls /var/lib/cloud
    
ls: cannot access '/var/lib/cloud': No such file or directory
    
root@watergodfm:/etc/network# cloud-init --version
    
-bash: cloud-init: command not found
    
root@watergodfm:/etc/network# systemctl status cloud-init
    
Unit cloud-init.service could not be found.
    
root@watergodfm:/etc/network# ls /etc/cloud/          # 检查配置文件目录
    
ls /var/log/cloud-init.log  # 检查是否存在运行日志
    
ls: cannot access '/etc/cloud/': No such file or directory
    
ls: cannot access '/var/log/cloud-init.log': No such file or directory

    下面是Gemini给的回复。


    这在理论上是完全成立的，但结合你的排查结果，我们已经可以把这两者排除。
    

    
1. 为什么不可能是 cloud-init？
    
cloud-init 确实是在开机时运行一次的典型代表。如果它存在，它会在系统刚引导时，读取厂商的元数据（Metadata）并重写网络文件。
    

    
但是你可以直接证明你的系统里没有它：
    

    
cloud-init 运行完后，会常驻为一个名为 cloud-init 的系统服务。
    

    
即使服务不常驻，它也必然会在系统盘留下痕迹。你可以通过运行 ls /etc/cloud 或 ls /var/lib/cloud 来验证。如果这些目录不存在，说明你的 DD 镜像是真正的纯净版，完全没有这个组件。
    

    
2. 为什么不可能是 qemu-guest-agent？
    
qemu-guest-agent 的工作原理决定了它无法在开机早期修改网络文件：
    

    
它是系统启动后，在用户态（User Space）运行的一个普通系统服务。
    

    
在系统刚开机、网络服务（networking.service）启动之前，qemu-guest-agent 服务甚至还没有被引导起来。
    

    
如果是它在开机后改的，文件的修改时间一定会晚于系统的开机时间（通常会晚几秒到十几秒），而不是像你现在这样，修改时间（17:02:30）几乎就是开机引导的时间点。
    

    
3. 决定性的“时间差”证据
    
我们来看一个时间逻辑：
    
如果你的系统是在 17:02 被厂商下发了改 IP 的任务，由于你没有运行任何在线代理，厂商必须通过底层重启你的 VPS。
    

    
如果是离线挂载修改：文件在 17:02:30 在硬盘里被母机改好，随后系统才真正加载内核、挂载根目录、运行第一个进程。
    

    
如果是开机自启脚本修改：系统必须先在 17:02:00 启动，加载内核，然后在 17:02:30 运行到某个脚本，这个脚本再把文件改掉。
  • GitLab 06-25 03:07
    5楼

    就是个虚拟机，直接读盘改就好了，正常的面板都有重置网络功能

  • cobalt 楼主 06-25 14:54
    6楼

    @GitLab #5

    嗯嗯，当时看到没密码的情况下改了配置，还有点奇怪，后面看到结果想想也正常。

* 帖子来源NodeSeek
附近帖子
返回
飞读
随机推荐