netcup VPS 生产级基础安全加固完全指南（Debian 12避坑/SSH密钥/Docker绕过UFW隐患）

本页目录15 节

任何一台刚开通并拥有公网 IP 的 Linux 服务器，通常在开机 15 分钟内就会遭遇全球僵尸网络的自动化端口扫描与暴力破解。

默认的 22 端口每天会承受成千上万次以 root、admin、test 为用户名的密码撞库攻击。如果继续保留服务商下发的初始密码或者放任弱口令“裸奔”，机器沦为黑客挖矿肉鸡或发垃圾邮件跳板只是时间问题。

本文为你详解一套经过生产环境验证的系统级安全加固全流程，并重点指出 Debian 12 现代系统特有的配置陷阱与 Docker 绕过防火墙的严重漏洞。

---

零、操作前铁律：如何防范“把自己锁在门外”？#

在修改任何 SSH 配置与防火墙规则时，请务必执行以下纪律：

1. 绝对不要关闭当前的活动终端窗口！在配置完成并通过另一个全新终端窗口成功连入新端口前，当前窗口是你唯一的救命通道；
2. 确认掌握应急救援路径：如果真的不小心把 SSH 配置写错被断联，立刻登录 netcup 的 SCP 面板，点击 Screen（HTML5 VNC 控制台），直接进入物理级终端回滚错误配置。

---

一、升级系统并创建普通提权用户#

以官方下发的初始 root 密码登录后，首先更新系统并创建专门的运维普通用户：

# 1. 更新软件包源并升级到最新补丁
apt update && apt upgrade -y

# 2. 安装 sudo 与常用运维依赖包
apt install -y sudo curl wget ufw fail2ban

# 3. 创建普通用户（例如 deploy），并加入 sudo 提权组
adduser deploy
usermod -aG sudo deploy

# 4. 验证新用户是否拥有免密/密码 sudo 权限
su - deploy
sudo whoami   # 必须成功输出 root
exit

---

二、部署 ed25519 现代 SSH 密钥（弃用老旧密码认证）#

弃用容易被破解的老旧 RSA 2048 密钥，全面转向基于椭圆曲线的高强度、小体积的 ed25519 算法。

1. 在你本地电脑（Mac / Windows PowerShell）生成密钥对#

# 生成高安全密钥对（提示输入密码短语请妥善保管）
ssh-keygen -t ed25519 -C "[email protected]"

此时本地会生成两个文件：id_ed25519（私钥，严禁泄露给任何人）和 id_ed25519.pub（公钥）。

2. 将公钥一键注入服务器普通用户#

# 在你本地终端执行（自动将公钥写入服务器 ~/.ssh/authorized_keys）
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@你的服务器IP

---

三、加固 SSH 服务并修改端口（Debian 12 避坑实操）#

在 Debian 12 系统中，SSH 服务默认引入了 systemd 的 ssh.socket 监听机制。直接修改传统的 /etc/ssh/sshd_config 有时可能发生端口未完全生效的情况。

标准且优雅的加固姿势：#

在 /etc/ssh/sshd_config.d/ 目录下创建独立的自定义覆盖配置文件：

cat << 'EOF' > /etc/ssh/sshd_config.d/99-security.conf
# 1. 修改默认端口（避免脚本小子全网扫描 22 端口，建议选用 10000~65535 之间的高位端口）
Port 22222

# 2. 禁用 root 用户通过公网直接登录
PermitRootLogin no

# 3. 强制关闭密码认证（杜绝任何暴力穷举）
PasswordAuthentication no

# 4. 仅允许公钥认证
PubkeyAuthentication yes

# 5. 空闲连接超时保活设置（10分钟无响应自动断开）
ClientAliveInterval 300
ClientAliveCountMax 2

# 6. 仅允许指定的普通用户登录
AllowUsers deploy
EOF

重新加载 SSH 服务：#

# 重启 SSH 服务与对应套接字
systemctl daemon-reload
systemctl restart ssh

# 检查当前监听端口（确认新端口 22222 已处于 LISTEN 状态）
ss -tulpn | grep ssh

验证检查点：
在本地电脑打开一个全新的终端窗口，运行：
ssh -p 22222 deploy@你的服务器IP
确认无需密码即可凭借本地私钥秒级登录成功后，方可进行下一步！

---

四、配置 UFW 防火墙与警惕“Docker 绕过 UFW”常见坑点#

1. 基础防火墙策略配置#

# 默认拒绝所有未经允许的入站流量
ufw default deny incoming
# 默认允许所有出站流量
ufw default allow outgoing

# 放行你的自定义 SSH 端口（关键步骤，切勿遗漏）
ufw allow 22222/tcp comment 'Custom SSH Port'

# 放行常规 Web 服务端口
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

# 开启防火墙并设为开机自启
ufw enable

# 查看当前已生效的防火墙规则
ufw status verbose

---

2. 警惕常见坑点：Docker 默认绕过 UFW 防火墙！#

这是让不少运维人员踩坑的常见网络问题：

• 问题机理：

当你在 Linux 上安装 Docker 后，Docker 引擎默认会自动修改底层内核的 iptables 规则（创建 DOCKER 链）。
由于其规则链处于网络数据包处理的最顶端（PREROUTING），它会无视 UFW 的屏蔽规则，直接将容器端口向公网开放。

• 真实案例：

你以为你在 UFW 里封死了 3306 端口，外部连不上；但在你的 docker-compose.yml 里写了：

  ports:
    - "3306:3306"   # 错误：这会默认监听在 0.0.0.0:3306 暴露给公网
  

扫描器可以直接扫描你服务器的 3306 端口，越过 UFW 直连你的 MySQL 数据库。

正确的安全绑定规范：

所有内部数据库、Redis、私有管理端（如 Portainer），在 Docker 端口映射时必须显式绑定到本机环回地址 127.0.0.1：

ports:
  - "127.0.0.1:3306:3306"   # 安全：仅允许宿主机内部应用访问，公网无法直连

只有面向公共访客的 Nginx/Caddy（80 和 443 端口），才允许直接公开映射。

---

五、部署 Fail2ban 防御暴力试探（Debian 12 适配）#

在 Debian 12 默认最小化安装中，系统不再默认将认证日志写入传统的 /var/log/auth.log，而是完全由 systemd-journald 接管。

如果直接使用默认配置启动 fail2ban，它会因为找不到日志文件而启动失败。

修复并配置 fail2ban：#

cat << 'EOF' > /etc/fail2ban/jail.local
[DEFAULT]
# 封禁时长 1 小时
bantime = 3600
# 统计时间窗口 10 分钟
findtime = 600
# 允许失败尝试次数（超过直接封禁 IP）
maxretry = 3
# 关键适配：指定从 systemd 日志读取
backend = systemd

[sshd]
enabled = true
port = 22222
EOF

# 重启并激活服务
systemctl restart fail2ban
systemctl enable fail2ban

# 查看当前针对 SSH 的封禁状态与封禁 IP 列表
fail2ban-client status sshd

---

六、开启无人值守自动安全补丁（Unattended-Upgrades）#

对于长期运行的自用生产服务器，开启自动化安全更新能确保当 OpenSSL 或 Linux 内核曝出零日漏洞时，系统在第一时间自动拉取官方安全补丁：

apt install -y unattended-upgrades
# 激活自动更新配置
dpkg-reconfigure -plow unattended-upgrades   # 在弹出的交互界面选择“是/Yes”

---

七、终极安全检查核对表#

在你的业务正式上线对外提供服务前，请逐条核对：

• [ ] 系统已完成 apt update && apt upgrade 最新升级；
• [ ] 创建了带 sudo 权限的普通运维用户；
• [ ] 部署了高强度 ed25519 SSH 密钥对；
• [ ] 修改了默认 22 端口，并在新端口验证登录无误；
• [ ] 彻底禁用了 PasswordAuthentication 与 PermitRootLogin；
• [ ] 开启了 UFW 防火墙，且仅放行了必要的 SSH、80、443 端口；
• [ ] 检查所有 Docker 容器端口，内部数据库严格绑定到了 127.0.0.1；
• [ ] fail2ban 正常处于 Active 运行状态，并成功监听自定义 SSH 端口；
• [ ] 在 SCP 面板验证确认：一旦断联，知道如何使用 Screen (VNC) 应急救命。