如何系统化加固 Netcup Linux VPS 与 Root Server（五层纵深防御安全架构蓝图）

在 Netcup G11、G11.5s、G12 与最新 G12.5 全系服务器的控制面板（servercontrolpanel.de）中，官方内置了 SCP 有状态防火墙（Stateful Firewall）。与运行在虚拟机内部的 ufw/iptables 不同，SCP 防火墙直接作用于 KVM 宿主机的虚拟网桥接口（tap 设备）上。这为您带来了两大无可替代的工程优势：（1）海量僵尸网络的端口扫描包在宿主机边缘就会被直接丢弃，完全不会消耗您虚拟机宝贵的 CPU 软中断（softirq）算力与内核连接追踪表（conntrack）；（2）无论虚拟机内部的 Docker 或 Kubernetes 如何修改客户机 iptables 转发链，都无法穿透 SCP 边缘防火墙向外暴露未授权端口。

由于 SCP 防火墙具备完整的连接状态追踪能力（Stateful Connection Tracking），当我们将出站（Egress）规则设为 ACCEPT ALL 时，任何由您服务器内部主动发起的 APT 软件源更新、DNS 递归查询或外部 Webhook 调用的回程数据包（ESTABLISHED,RELATED）都会被自动识别并放行；与此同时，位于入站规则集最底部的默认 DROP ALL 兜底策略会拦截所有未在上方白名单中显式放行的公网主动入站请求。您还可以将配置好的规则集保存为 SCP 防火墙策略模板（Firewall Policy Template），一键同步应用至名下的多台 Netcup 服务器。

在配置 SCP 有状态防火墙时，请特别留意下方表格中的第四行规则：务必放行入站 ICMP 与 ICMPv6 协议（尤其是 ICMPv6 Type 133 至 136 报文）。许多缺乏双栈网络经验的管理员习惯在防火墙中一刀切封禁全部 ICMP，这在 IPv4 时代或许只会影响 ping 诊断，但在 IPv6 架构下则会引发断网故障——因为 IPv6 废除了广播式的 ARP 协议，改用基于 ICMPv6 的邻居发现协议（NDP）来完成网关 fe80::1 的二层 MAC 寻址，且依赖 ICMPv6 Packet Too Big（Type 2）报文完成路径最大传输单元发现（PMTUD）。请登录 SCP 控制面板 → 选择您的服务器 → Firewall，配置以下基线规则集：

虽然 SCP 边缘防火墙封死了所有非业务端口，但 22（SSH）与 443（HTTPS）端口仍然必须向公网开放，这就需要主机级动态入侵防御系统（IPS）实时监测并阻断恶意爆破源。在 Ubuntu 24.04 LTS 与现代 Debian 12 最小化云镜像中，官方为了精简系统开销，默认不再预装传统的纯文本日志守护进程（rsyslog）——这意味着老教程里常写的 /var/log/auth.log 文件在您的服务器上根本不存在！如果您直接安装 fail2ban 而不显式指定 backend = systemd，Fail2ban 要么会因为找不到日志文件而直接启动失败，要么会静默漏掉记录在 systemd-journald 二进制日志中的所有认证失败事件。

为了在 Ubuntu 24.04 上让 Fail2ban 与 systemd-journald 无缝协同，安装时必须同步装上 python3-systemd C 语言绑定包，并在 /etc/fail2ban/jail.local 中显式声明 backend = systemd。同时，我们在 [sshd] 监狱中开启了 mode = aggressive（激进过滤模式）：普通模式仅统计完整的密码或密钥验证失败，而 aggressive 模式还会捕获恶意扫描器在协商加密算法阶段直接断开连接（Connection closed by authenticating user ... [preauth]）的探测行为，防止高频扫描耗尽 sshd 的未认证并发连接槽（MaxStartups）。

更关键的是，传统的固定 10 分钟封禁策略面对现代分布式僵尸网络早已形同虚设——攻击脚本只需暂停 10 分钟后即可继续枚举字典。下方提供的 /etc/fail2ban/jail.local 配置启用了指数级封禁时长递增机制（bantime.increment = true、bantime.factor = 2、bantime.maxtime = 5w）：首次触发封禁 1 小时，同一 IP 再次重犯自动翻倍为 2 小时、4 小时、8 小时……最高封禁长达 5 周（5w），且封禁历史持久化保存在 /var/lib/fail2ban/fail2ban.sqlite3 数据库中，重启服务器也不会丢失：

sudo apt update
sudo apt install -y fail2ban python3-systemd

cat << 'EOF' | sudo tee /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 5w
findtime = 15m
maxretry = 3
backend = systemd
banaction = ufw
banaction_allports = ufw
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
mode = aggressive
port = ssh
logpath = %(sshd_log)s
backend = systemd
EOF

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed:     0
`- Actions
   |- Currently banned: 0
   `- Total banned:     0

第三层防线通过 /etc/sysctl.d/99-netcup-security.conf 对 Linux 内核的 TCP/IP 协议栈与用户态内存边界进行 CIS Benchmark 级别硬化。在网络层，开启 net.ipv4.tcp_syncookies = 1 可在半连接队列（SYN Backlog）遭遇分布式 SYN 洪水攻击塞满时，自动启用加密 Sequence Number 校验而不丢弃正常访客连接；开启 net.ipv4.tcp_rfc1337 = 1 可防御针对 TIME_WAIT 状态套接字的过早重置攻击；开启严格反向路径过滤（rp_filter = 1）则会校验每个入站数据包的源 IP 是否可通过入站网卡原路路由返回，当场丢弃伪造源 IP 的欺骗包。

与此同时，我们禁用了 IPv4 与 IPv6 的 ICMP 路由重定向接收与发送（accept_redirects = 0、secure_redirects = 0、send_redirects = 0）以及源路由选项（accept_source_route = 0），防止攻击者利用伪造的 ICMP Redirect 报文篡改内核路由表。值得特别说明的是，本配置特意保留了内核的 ip_forward 转发能力与 ICMPv6 邻居发现机制，因此与 Docker 容器网桥及 Netcup /64 IPv6 静态路由 100% 兼容。

在内核内存与文件系统防提权层面，设置 kernel.kptr_restrict = 2 会向所有用户态进程隐藏 /proc/kallsyms 中的内核函数真实内存地址（阻断基于 KASLR 绕过的 ROP 内核提权利用链）；设置 kernel.yama.ptrace_scope = 1 可阻止被攻陷的普通进程通过 ptrace() 附加到同用户的其他兄弟进程上窃取内存凭据；设置 fs.protected_hardlinks = 1 与 fs.protected_symlinks = 1 则能有效防御经典的 /tmp 临时目录符号链接竞态条件（TOCTOU）提权攻击：

cat << 'EOF' | sudo tee /etc/sysctl.d/99-netcup-security.conf
# TCP SYN 洪水防御与反向路径源地址防伪造过滤
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# 禁用 IPv4 与 IPv6 的 ICMP 路由重定向及源路由报文
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# 内核符号指针隐藏、ptrace 调试限制与软硬链接竞态保护
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF

sudo sysctl --system

* Applying /etc/sysctl.d/99-netcup-security.conf ...

理解 Linux 虚拟内存管理机制有助于堵住日常运维中最容易被忽视的安全盲区：当 Ubuntu 或 Debian 官方发布针对 libc6、libssl3（OpenSSL）或 libsystemd0 的紧急高危漏洞补丁时，unattended-upgrades 会在凌晨自动下载并解压新的 .deb 软件包，将磁盘上的 .so 动态链接库文件替换为新版本并解除旧 inode 的硬链接。然而，任何在更新前就已经处于运行状态的常驻守护进程（如 nginx、php-fpm、postfix、mariadbd），在重启进程之前，其虚拟内存地址空间（/proc/<pid>/maps 中标记为 (deleted)）映射并执行的依然是更新前驻留在物理 RAM 中的旧版带漏洞代码！

Ubuntu 24.04 LTS 预装了强大的 needrestart 工具，它会在每次 apt 或 dpkg 操作结束后自动扫描 /proc/*/maps，精准识别出哪些正在运行的 systemd 服务仍映射着已被替换的旧版共享库。但在默认配置下，needrestart 可能处于交互提示模式（i），在后台无人值守运行时未必会主动重启所有关联服务。

通过创建 /etc/needrestart/conf.d/99-netcup-auto.conf 并设置 $nrconf{restart} = 'a';，系统会在 unattended-upgrades 夜间打完底层安全补丁后，立即全自动平滑重启受影响的守护进程以加载新库代码，形成完整的闭环防护。此外，对于承载核心敏感数据的服务器，建议同步在 /etc/fstab 中为 /dev/shm 共享内存挂载点加上 noexec,nosuid,nodev 限制，并配合 auditd 审计守护进程监控对 /etc/passwd、/etc/shadow 与 /etc/ssh/sshd_config.d/ 的修改行为：

sudo apt install -y unattended-upgrades needrestart

# 配置 needrestart 在底层共享库修补后自动重启受影响的守护进程 ('a' = automatic)
sudo mkdir -p /etc/needrestart/conf.d
cat << 'EOF' | sudo tee /etc/needrestart/conf.d/99-netcup-auto.conf
# 自动重启受影响的服务进程 ('a')，而非交互式弹窗询问 ('i')
$nrconf{restart} = 'a';
EOF

# 运行 unattended-upgrades 模拟测试以核验自动修补配置正常
sudo unattended-upgrade --dry-run --debug | tail -n 10