Debian 12 生产环境初始化安装与安全加固指南

结论先行：Debian 作为极其稳定轻量的服务器发行版，裸机上线后的第一优先级绝非堆砌应用，而是筑牢系统安全防线。核心标准流程包括：全量安全更新与内核升级、创建专属 sudo 管理员并严格锁定 root 登录、强制启用 Ed25519 密钥认证并更迭默认 22 端口、开启 BBR 拥塞控制调优 TCP 性能，最后配合 UFW 防火墙与 Fail2ban 阻断公网扫描与撞库攻击。

0、写在前面与终端选型避坑

每次开通一台新的 Debian 实例（无论是云服务器还是裸金属机器），面对只有一个 root 用户和随机密码的裸系统，必须建立一套标准化的加固作业流程。

在远程连接客户端的选择上，常用的工具有 SecureCRT、FinalShell、Termius 以及 VS Code Remote SSH：

SecureCRT：性能稳定、会话管理成熟，支持生成标准的 OpenSSH 格式密钥，适合严格的企业生产运维。
FinalShell：内置直观的文件目录树与系统性能监视浮窗，对新手友好。但在部分高延迟网络下快速粘贴长命令时，偶尔会出现字符错位或换行丢失的情况。解决办法是：先将多行脚本写入本地文本，或者直接在服务器端创建 .sh 文件后使用 bash script.sh 运行，避免大段剪贴板直接注入终端。

1、系统更新与基础依赖整备

Debian 镜像出厂时，软件源与内核往往停留在构建版本。第一步是同步最新的安全修补并安装必备的系统工具。

1.1 系统全量更新

# 更新本地软件包索引并执行完整升级（包含内核与依赖项替代）
sudo apt update && sudo apt full-upgrade -y

# 清理过期的无用安装包与缓存
sudo apt autoremove -y && sudo apt autoclean

apt full-upgrade 相比常规的 apt upgrade，具备智能处理依赖关系变更、在必要时升级或替换内核模块的能力。更新完成后，如果内核产生跨版本变动，建议执行 sudo reboot 重启一次。

1.2 必备工具套件安装

Debian 最小化安装往往连 sudo 和 curl 都没有预装。建议一次性装齐生产运维核心套件：

sudo apt install -y \
  sudo curl wget git htop vim tmux screen \
  net-tools dnsutils ufw fail2ban \
  ca-certificates gnupg lsb-release

podman / docker：Debian 官方源中推荐使用轻量级免守护进程的 podman，若业务强依赖 Docker 生态，后续可导入 Docker 官方 APT 仓库。
net-tools & dnsutils：提供 netstat、ifconfig 与 dig，是排查网络不可达问题的利器。

2、开启 BBR 拥塞控制与内核参数优化

Google BBR（Bottleneck Bandwidth and RTT）拥塞控制算法通过动态测量网络瓶颈带宽和往返时间，有效缓解丢包造成的传输断崖式下跌，对跨国网络连接提升显著。

2.1 检查内核版本与当前算法

Debian 10 之后的内核（4.9+）已原生内置 BBR 模块。查看当前内核版本与拥塞算法：

1 2	uname -r sysctl net.ipv4.tcp_congestion_control

2.2 永久启用 BBR

创建独立的 sysctl 配置覆盖文件 /etc/sysctl.d/99-bbr-tuning.conf：

sudo tee /etc/sysctl.d/99-bbr-tuning.conf << 'EOF'
# 启用基于 Fair Queue (FQ) 的调度器
net.core.default_qdisc = fq

# 指定 TCP 拥塞控制算法为 BBR
net.ipv4.tcp_congestion_control = bbr

# 调优文件句柄与 TCP 套接字最大连接数
fs.file-max = 1000000
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_slow_start_after_idle = 0
EOF

# 加载配置使之立即生效
sudo sysctl --system

验证 BBR 是否运行：

sysctl net.ipv4.tcp_congestion_control
# 正确输出应包含: net.ipv4.tcp_congestion_control = bbr

lsmod | grep bbr
# 正确输出应显示 tcp_bbr 模块已加载

3、纵深安全防御体系架构

为保证服务器不暴露在公网风险中，防御架构需分为访问隔离、密钥认证、网络过滤与行为封禁四个层次：

4、账户隔离与 Sudo 权限委派

绝不应该长期使用 root 用户登录生产系统。我们需要创建一个普通的管理账号（例如 ittinker）并赋予受限的 sudo 权限。

# 1. 创建普通运维用户
sudo adduser ittinker

# 2. 将用户加入 sudo 组
sudo usermod -aG sudo ittinker

# 3. 验证新用户权限是否生效
su - ittinker -c "sudo whoami"
# 输出应当为: root

5、SSH 密钥认证加固与端口迁移

为杜绝暴力破解，必须全面废止密码认证，采用高强度的现代加密算法，并将监听端口修改为高位非默认端口。

5.1 本地生成高强度 Ed25519 密钥对

相较于传统的 RSA 2048/4096，Ed25519 具备更短的密钥长度、极高的加解密性能以及出色的抗侧信道攻击能力。

在本地工作机终端（Mac/Linux）中执行：

1	ssh-keygen -t ed25519 -C "admin@ittinker.com" -f ~/.ssh/id_ed25519_debian

如果使用 SecureCRT，可通过菜单 Tools -> Create Public Key 生成，格式选择 OpenSSH Key format (new)。

5.2 部署公钥至服务器并严密限制权限

在服务器的新用户家目录下配置 .ssh：

# 以 ittinker 用户身份登录执行，或者由 root 创建后更改归属
sudo -u ittinker mkdir -p /home/ittinker/.ssh
sudo -u ittinker touch /home/ittinker/.ssh/authorized_keys

# 写入你的本地公钥内容（将 YOUR_PUBLIC_KEY 替换为 id_ed25519_debian.pub 内容）
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... admin@ittinker.com" | sudo -u ittinker tee /home/ittinker/.ssh/authorized_keys > /dev/null

# 必须设置严格的文件权限，否则 SSH 守护进程出于安全策略会拒绝读取
sudo chmod 700 /home/ittinker/.ssh
sudo chmod 600 /home/ittinker/.ssh/authorized_keys
sudo chown -R ittinker:ittinker /home/ittinker/.ssh

5.3 强化 sshd_config 配置

Debian 12 推荐在 /etc/ssh/sshd_config.d/ 下增加独立的加固片段，而不是直接修改总文件：

sudo tee /etc/ssh/sshd_config.d/99-hardened.conf << 'EOF'
# 改用非标准端口，有效减少 99% 的全网批量自动化端口扫描
Port 22000

# 仅允许基于公钥认证
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# 彻底禁用密码登录
PasswordAuthentication no
PermitEmptyPasswords no

# 禁止 root 用户通过 SSH 直接登录
PermitRootLogin no

# 认证限制与连接保活
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# 禁用陈旧不安全的 X11 转发与 rhosts
X11Forwarding no
IgnoreRhosts yes
EOF

操作提示：在重启 SSH 服务之前，千万不要关闭当前的终端连接！先打开新的本地终端窗口，使用新端口和密钥测试连接：
1
ssh -i ~/.ssh/id_ed25519_debian -p 22000 ittinker@<服务器IP>
验证可以顺利登录并执行 sudo ls 后，再在原终端中确认生效。

测试通过后重载 SSH 守护进程：

1	sudo sshd -t && sudo systemctl restart ssh

6、UFW 防火墙精细化策略与连通性验证

UFW（Uncomplicated Firewall）是 iptables 的友好管理接口。必须贯彻“默认全部丢弃、按需显式放行”的原则。

6.1 初始化防火墙规则

# 默认策略：阻断所有未经许可的传入连接，放行传出连接
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 放行加固后的 SSH 自定义端口
sudo ufw allow 22000/tcp comment 'Custom SSH'

# 放行基础 Web 服务端口
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# 启用防火墙
sudo ufw enable

6.2 检查规则与连通性测试

1	sudo ufw status verbose

输出应呈现如下状态：

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22000/tcp (Custom SSH)     ALLOW IN    Anywhere
80/tcp (HTTP)              ALLOW IN    Anywhere
443/tcp (HTTPS)            ALLOW IN    Anywhere
22000/tcp (v6)             ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

若需从本地验证防火墙端口阻断状态，可在客户端通过 nc -zv <服务器IP> <端口> 检测：放行端口应立即返回 succeeded，未放行端口则会等待超时。

7、Fail2ban 自动化防撞库与源站 IP 隔离

即使更改了端口，长期暴露在公网仍可能被全端口扫描发现。Fail2ban 能够实时分析 /var/log/auth.log，对连续认证失败的源 IP 自动下发临时防火墙封禁规则。

7.1 配置 Fail2ban SSH 监狱

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo tee /etc/fail2ban/jail.d/sshd.local << 'EOF'
[sshd]
enabled = true
port = 22000
mode = aggressive
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 86400
EOF

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

检查防御状态与被拦截 IP：

1	sudo fail2ban-client status sshd

7.2 Cloudflare 源站安全隔离 (只允许 CDN IP 访问 80/443)

如果你的网站全部挂在 Cloudflare 后面，最佳安全实践是直接在 UFW 中收拢 80/443 访问权限，仅对 Cloudflare 官方公布的边缘回源 IP 段开放，阻断针对源站真实 IP 的直接嗅探与绕过 CDN 的攻击行为。

你可以使用开源项目 ittinker-scripts 中自带的 cloudflare-ufw 工具进行自动化管理：

1 2	# 获取官方 Cloudflare IPv4 与 IPv6 列表，并自动注入 UFW 规则 sudo bash -c "$(curl -fsSL https://raw.githubusercontent.com/Richardson/ittinker-scripts/main/cloudflare-ufw/install.sh)"

该工具会自动从 Cloudflare 官方接口拉取最新 IP 网段，在 UFW 中配置精准来源白名单，并在 /etc/cron.weekly/cloudflare-ufw-update 下建立定时任务，确保源站 IP 永远处在 CDN 护城河内部。