最近由于多种因素的叠加（主要是我自己的责任），我所在的实验室内网被入侵了。这篇博文记录一下分析得出的攻击时间线和经验教训。
背景
我们实验室的内网网段由一台网关服务器提供 NAT 服务，所有出流量均经过网关。而网关上有多个端口映射指向内网的多台提供 SSH 服务的设备，这些端口均不允许密码登录。 此外，实验室的有线网络还有一个 VLAN 提供校园网的 DHCP 服务；由于校园网 BRAS 设备的存在，如果不进行准入认证，则此网络的用户只能在同一个广播域（事实上是实验室所在大楼的某个 VLAN）中互相通信。
昨天下午（2024/1/29），同学们发现 SSH 连接内网部分服务器非常困难。我简单检查网关日志发现了大量校园网中的 SSH 攻击流量，导致 sshd 难以响应。
据此，我认为难以连接是正常现象，在网关重启了 fail2ban 后得到缓解（此前服务由于其他原因挂掉了）。
今天下午，同学反映内网的一些机器也有类似的问题，并且我们的网关出口地址被校园网封禁了。
这让我开始怀疑内部已经出了问题。经过一系列紧急排查、处理，我发现问题居然来自于我的 NUC，并且是多重因素的叠加导致类问题。
时间线
下面是经过日志分析、还原后得到的时间线。
- 2023 年某个时间点：我在 NUC 上创建了 VLAN2 的 systemd-networkd 配置文件，使用 DHCP 获取地址。当时使用完毕后，我运行了
networkctl down关闭接口，但没有移除配置文件。 - 2024-01-05 16:17:00：我在 NUC 上创建了具有弱密码的新用户
test并进行了一些 Debian 打包相关的测试。后续执行usermod锁定账户时，错误使用了-l而不是-L（命令应该会报错，但我或许没有看），因此系统中留下了可用的弱密码用户。 - 2024-01-15 16:30:00：由于内核更新，我重启了 NUC。此时 VLAN2 接口又被默认启用并通过 DHCP 获取了地址
166.111.A.foo。弱密码用户也继续存在于系统中。被攻击的隐患已经留下了。 - 2024-01-29 00:58:13：在 VLAN2 的同一个广播域中，地址为
166.111.A.bar的一台机器成功通过test账户登录了我的 NUC。自此，内网被击穿。
自此之后，实验室内网所有存在弱密码的机器（多为两个或三个字的账号，密码与账号相同）都被逐一攻陷。大约有七台机器（包含我的 NUC）被入侵，这些服务器在我们的内网、以及通过网关服务器对外进行疯狂的扫描和攻击，因此导致了内部和外部的 SSH 访问均不顺畅，最终被校园网封禁。
要成功入侵，需要以下条件同时被满足：
- 有机器同时存在内网和外网访问：我的 NUC 上的 VLAN2 接口由于系统重启被打开了。
- 在没有准入的情况下，能访问到我们的外网接口：同一个广播域下的其他机器已经被入侵。
- 机器上存在可用的弱密码账户：我在使用完
test用户后，由于大意锁定用户失败。
很遗憾，小丑竟是我自己。
事后分析
考虑到我是实验室的网络和设备管理员，绝大部分的机器我都有登录和 root 权限。一旦我的账户被攻破，后果不堪设想。 万幸的是，我的个人账户密码强度都还比较高，并且我没有在任何机器上放置 SSH 私钥。因此，攻击者只能获得普通用户的权限。而我平时也比较关注系统更新，因此没有留下什么严重的提权漏洞。 因此，攻击者在我的 NUC 上只获得了一个普通用户权限，仅仅能下载恶意程序进行进一步的扫描。
我进一步检查了其余被入侵的机器，幸运（或者说是侥幸）的是，这些弱密码用户也没有更高的权限。此外，攻击程序的日志也被保留下来了，其中有一个 scan.log 记录了所有被扫出来的弱口令机器地址、用户和密码。
通过我的初步检查，还没有非内网的机器被攻陷。
善后举措
为了预防此类事情再次发生，我将采取以下措施：
- 彻底清理所有被攻击的机器。如果无法清理（如没有管理权限），则先物理断开网络连接。
- 在内网中也普遍禁用 SSH 密码登录，毕竟遗留的弱密码到底有多少无法得知。这样即使某台机器被攻陷，也还有一些基本的安全防线。
- 在网关上部署更多的流量分析和监控（目前已经有 ntop，计划再部署 suricata），以便更早发现异常。