香港节点服务器安全加固清单：SSH登录、防火墙规则与审计日志

先界定风险范围：上线前要挡住哪几类攻击

香港节点服务器刚分配公网 IP 后，最先遇到的通常不是“定向攻击”，而是自动化扫描：探测 22/TCP 是否开放，尝试 root、admin、test 等常见账号，继续枚举 Web、数据库、Redis、面板端口。如果 SSH 允许密码登录、防火墙默认放行、日志只保存在本机且没有留存策略，服务器还没正式上线，就已经暴露在高频撞库和弱口令攻击里。

上线前的最小可用安全基线可以概括为三件事：SSH 只允许可信身份和可信来源登录；防火墙只放行业务必需端口；审计日志能够记录关键操作并保留到足够排查的周期。以下内容默认面向常见 Linux 服务器，如 Ubuntu 22.04/24.04、Debian 12、Rocky Linux 8/9、AlmaLinux 8/9。不同发行版的服务名、日志路径和防火墙工具略有差异，操作前应先确认当前系统环境，并保留一条已登录的管理会话，避免误配置导致无法连接。

攻击面清单：先看暴露点，再做加固

安全加固不应从“套命令”开始，而应先确认香港节点服务器到底暴露了哪些入口。公网节点常见攻击面包括 SSH、Web 服务、数据库、缓存、面板、监控 Agent 和临时调试端口。

可以先在服务器上查看当前监听端口：

sudo ss -lntup

如果输出中出现 0.0.0.0:3306、0.0.0.0:6379、:::9200 这类监听，说明服务正在对所有 IPv4 或 IPv6 地址开放。此时不要只依赖应用密码，应优先通过防火墙和服务绑定地址降低暴露面。

优先加固一：SSH 登录限制

SSH 是服务器安全加固的第一道门。对于公网香港节点，推荐采用“密钥登录 + 禁止 root 直登 + 限制管理来源”的组合，而不是单纯改端口。修改 SSH 端口可以减少低质量扫描日志，但不能替代身份认证和防火墙限制。

1. 先准备可回滚条件

修改 SSH 前，建议先完成三项准备：

• 保留当前已登录的 SSH 会话，不要在新配置验证前断开；
• 确认服务商控制台、VNC、救援模式或带外管理可用；
• 备份 SSH 配置文件。

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)

如果系统使用 /etc/ssh/sshd_config.d/ 目录管理片段配置，建议新增独立文件，避免直接改动主配置造成后续维护困难。

2. 使用密钥登录并禁用高风险登录方式

先确认目标用户已正确写入公钥，且权限符合要求：

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

然后创建加固片段：

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers opsadmin
EOF

这里的 opsadmin 需要替换为实际运维账号。若业务依赖 SSH 隧道、跳板转发或远程开发工具，AllowTcpForwarding no 可能影响使用，应按实际需求调整。不要在未确认密钥可用前关闭密码登录，否则容易把自己锁在服务器外。

配置完成后先检查语法：

sudo sshd -t

没有输出通常表示语法检查通过。随后重载 SSH 服务。不同系统服务名可能是 ssh 或 sshd：

sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

验证时不要关闭原会话，另开一个终端测试：

ssh -i ~/.ssh/id_ed25519 opsadmin@your_server_ip

如果新会话能登录，再确认 root 和密码登录已被拒绝。若管理 IP 固定，还可以在防火墙层限制 SSH 来源；如果管理人员 IP 经常变化，更适合使用 VPN、堡垒机或零信任接入，而不是把 SSH 对 0.0.0.0/0 长期开着。

优先加固二：防火墙只放行必要端口

防火墙规则应遵循“默认拒绝入站，按需放行业务”的原则。不要为了排障长期关闭防火墙，也不要认为安装 SSL 证书就等于整站安全。SSL/TLS 主要解决传输加密和身份校验问题，不能阻止 SSH 暴力破解、数据库公网暴露或应用漏洞利用。

1. 放行策略建议

还要同时检查 IPv4 和 IPv6。如果服务器有 IPv6 地址，但只配置了 IPv4 防火墙，攻击者仍可能从 IPv6 访问服务。

2. Ubuntu/Debian 使用 UFW 的示例

以下示例假设管理员公网 IP 为 203.0.113.10，业务需要开放 80 和 443。执行前请替换为真实管理 IP，并确认当前 SSH 会话不要断开。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10/32 to any port 22 proto tcp comment 'admin-ssh'
sudo ufw allow 80/tcp comment 'http'
sudo ufw allow 443/tcp comment 'https'
sudo ufw enable
sudo ufw status verbose

如果需要同时限制 IPv6，应确认 /etc/default/ufw 中 IPV6=yes，并为 IPv6 管理地址添加对应规则。不要为了方便直接执行 ufw allow 22/tcp 后长期不收紧来源。

3. Rocky/AlmaLinux 使用 firewalld 的示例

RHEL 系发行版常用 firewalld。可以先添加来源限制规则，再移除默认 SSH 全网开放规则：

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --zone=public --remove-service=ssh
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --list-all

如果系统启用了 SELinux，变更 SSH 端口还需要同步设置 SELinux 端口类型和防火墙规则。单纯修改 sshd_config 中的 Port，在 SELinux 环境下可能导致 SSH 无法监听新端口。实际生产环境中，除非已有端口规范，不建议把“改端口”作为主要安全手段。

优先加固三：审计日志要能追溯、能留存

日志的价值不只在出事后排查，也在于提前发现异常。香港节点面向公网时，SSH 失败登录、异常 sudo、账户变更、防火墙变更、关键配置文件修改都应进入观察范围。

1. 确认系统认证日志位置

不同发行版路径不同：

• Ubuntu/Debian：常见认证日志为 /var/log/auth.log；
• Rocky/AlmaLinux：常见认证日志为 /var/log/secure；
• 使用 systemd 的系统也可通过 journalctl 查询 SSH 服务日志。

sudo journalctl -u ssh -u sshd --since "1 hour ago"

查看最近失败登录：

sudo grep -Ei "failed password|invalid user|authentication failure" /var/log/auth.log 2>/dev/null || sudo grep -Ei "failed password|invalid user|authentication failure" /var/log/secure

如果这里持续出现大量未知 IP 尝试登录，说明 SSH 已被扫描或暴力破解，应优先收紧来源 IP，而不是只增加密码复杂度。

2. 启用关键文件审计

auditd 可以记录关键配置文件被修改的行为。安装方式按发行版选择：

sudo apt update && sudo apt install -y auditd

或：

sudo dnf install -y audit audit-libs

可根据实际存在的路径添加审计规则，例如：

sudo tee /etc/audit/rules.d/hardening.rules >/dev/null <<'EOF'
-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /etc/ssh/sshd_config.d/ -p wa -k ssh_config
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
EOF

sudo augenrules --load
sudo auditctl -s

如果某些目录不存在，应删除对应规则后再加载，避免规则加载失败。查询 SSH 配置变更记录可使用：

sudo ausearch -k ssh_config

3. 设置日志留存和异地转存

只把日志留在本机并不可靠。攻击者获得权限后，可能清理登录痕迹；磁盘写满也会造成日志中断。建议至少做到：

• 本地日志保留 7～30 天，视合规要求和磁盘空间调整；
• 关键日志转发到独立日志服务器、SIEM 或对象存储；
• 开启时间同步，确保跨系统排查时日志时间一致；
• 监控 /var/log 和 /var/log/audit 磁盘占用，避免日志写满分区。

可以用以下方式确认时间同步状态：

timedatectl status

如果使用 systemd-journald，建议启用持久化存储并限制占用。修改前先备份配置：

sudo cp -a /etc/systemd/journald.conf /etc/systemd/journald.conf.bak.$(date +%F-%H%M%S)

示例配置项如下：

sudo mkdir -p /var/log/journal
sudo sed -i 's/^#\?Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
sudo sed -i 's/^#\?SystemMaxUse=.*/SystemMaxUse=1G/' /etc/systemd/journald.conf
sudo sed -i 's/^#\?MaxRetentionSec=.*/MaxRetentionSec=30day/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

日志留存周期不应凭感觉设定。一个简单估算方法是：可用日志空间 ÷ 每日新增日志量 ≈ 可保留天数。例如每天新增 200MB 日志，预留 6GB 空间，本地大约可保留 30 天；如果 Web 访问日志、审计日志和应用日志都在同一分区，还要预留峰值空间。

验证：不要只看服务“已启动”

安全配置上线后，需要从服务器本机和外部网络两个视角验证。

服务器本机检查监听端口：

sudo ss -lntup

防火墙检查：

sudo ufw status verbose 2>/dev/null || sudo firewall-cmd --list-all

SSH 配置检查：

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|maxauthtries|allowusers'

外部验证建议从授权的管理网络发起，不要使用未授权扫描。重点确认：

• 非管理 IP 无法连接 SSH；
• 管理 IP 可以通过密钥登录；
• root 不能直接登录；
• 80/443 按业务预期开放；
• 数据库、缓存、内部管理端口不对公网开放；
• 失败登录、成功登录、sudo 操作能在日志中查到；
• 修改 SSH 或 sudo 配置后，auditd 能记录对应事件。

如果使用云防火墙、安全组或上游 ACL，还需要确认它们与系统内防火墙规则一致。上游放行但系统拒绝，业务会不通；上游全放行但系统规则误删，风险会突然扩大。

回滚：提前准备比临时救火更重要

SSH 和防火墙配置都属于高风险操作，回滚方案应在变更前写清楚。最常见的回滚路径包括：

1. 使用保留的 SSH 会话恢复配置；
2. 通过控制台/VNC 登录服务器修正规则；
3. 使用救援模式挂载系统盘恢复配置文件；
4. 临时放行管理 IP，而不是长期关闭防火墙。

SSH 配置异常时，可恢复备份并重载服务：

sudo cp -a /etc/ssh/sshd_config.bak.YYYY-MM-DD-HHMMSS /etc/ssh/sshd_config
sudo rm -f /etc/ssh/sshd_config.d/10-hardening.conf
sudo sshd -t
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

UFW 规则导致无法访问时，优先通过控制台添加正确来源规则；只有在紧急恢复连接时，才临时关闭防火墙，恢复后必须重新启用并复核规则：

sudo ufw allow from 203.0.113.10/32 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

firewalld 可重新添加管理 IP 规则并持久化：

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --list-all

回滚不是把所有安全策略撤掉，而是恢复到“可登录、可排查、暴露面仍受控”的状态。

持续观察：上线后重点盯这些信号

安全加固不是一次性动作。香港节点上线后，建议把以下事件纳入日常告警或巡检：

• SSH 失败登录次数突然上升；
• 出现非维护时间段的成功登录；
• sudo、su、新增用户、修改 authorized_keys 等高权限行为；
• 防火墙规则被修改或服务端口新增监听；
• /var/log/auth.log、/var/log/secure、audit.log 出现异常空档；
• 日志分区使用率持续升高；
• 时间同步异常，导致日志时间漂移；
• Web 日志中出现高频扫描、路径遍历、管理后台爆破。

如果运维团队成员经常跨网络登录，不建议把 SSH 长期暴露给所有来源。更稳妥的做法是使用固定 VPN 出口、堡垒机、短时授权规则或集中身份认证。服务器安全加固的目标不是追求“绝对安全”，而是在不影响业务上线的前提下，把可预见的入侵路径压到最低，并确保异常发生时有日志可查、有规则可回滚、有人员能及时响应。