香港节点Kernel 7.2服务器安全加固，哪些端口与权限要先处理？

部署在香港节点、直接暴露公网地址的 Linux 服务器，安全加固应先处理“能否被访问”和“谁能执行高权限操作”两个问题：先清点并收敛监听端口，再保护 SSH 等认证入口，随后落实最小权限、补丁更新、防火墙和审计。管理端口必须在启用默认拒绝策略前放行，否则最常见的结果不是攻击告警，而是管理员先把自己锁在服务器外。

“Kernel 7.2”不能单独作为补丁依据。它可能是发行版或服务商的内核分支命名，也可能只是 uname -r 中的一部分；真正决定补丁能否正确安装的是发行版、内核软件包来源和当前运行内核。以下步骤适用于常见的 Debian/Ubuntu 与 RHEL 系发行版，命令执行前应先核对系统类型、管理通道和当前防火墙实现。

一、准备条件：确认环境、通道与回滚点

1. 确认发行版和实际运行内核

先以具有 sudo 权限的账号登录，不建议直接使用 root 作为日常操作账号。执行以下命令收集环境信息：

id
cat /etc/os-release
uname -r
uname -a
systemctl --version | head -n 1
timedatectl status

重点关注以下信息：

• ID、VERSION_ID：决定使用 apt、dnf 还是其他包管理器。
• uname -r：这是当前正在运行的内核，不一定等于磁盘上已安装的最新内核。
• timedatectl：审计日志和补丁记录需要可靠的时间。香港节点可以使用 Asia/Hong_Kong，也可以统一使用 UTC，但团队必须保持一致。
• 是否存在 IPv6：如果服务器有公网 IPv6 地址，不能只配置 IPv4 防火墙。

检查“Kernel 7.2”对应的软件包来源：

command -v apt-get >/dev/null && dpkg -S "/boot/vmlinuz-$(uname -r)" 2>/dev/null || true
command -v rpm >/dev/null && rpm -qf "/boot/vmlinuz-$(uname -r)" 2>/dev/null || true

如果输出显示为自定义包、服务商内核包或无法找到归属包，不要直接从其他网站下载一个相似版本覆盖当前内核。应先确认服务商仓库、发行版仓库或内部镜像的更新路径。内核字符串相同，也不代表发行版补丁级别相同。

2. 确保存在带外管理通道

在修改 SSH、防火墙或内核前，至少满足以下条件之一：

• 云平台控制台可以打开串口、VNC 或远程终端；
• 数据中心提供独立管理口；
• 已建立第二个管理员 SSH 会话，并且该会话使用不同账号或不同来源地址；
• 已创建可恢复的云硬盘快照或文件系统备份。

快照不是防火墙配置的替代品。快照恢复可能需要重启、挂载磁盘或联系服务商，不能把它当成实时回滚按钮。

3. 备份关键配置

下面的示例会备份 SSH、sudo、防火墙和系统服务配置。备份文件中可能包含敏感信息，应设置为仅 root 可读，并在变更确认后按内部留存策略处理。

install -d -m 700 /root/hardening-backup
tar --xattrs --acls -czf "/root/hardening-backup/etc-$(date +%F-%H%M%S).tar.gz" \
  /etc/ssh /etc/sudoers /etc/sudoers.d /etc/systemd/system \
  /etc/ufw /etc/firewalld /etc/nftables.conf 2>/dev/null || true
chmod 600 /root/hardening-backup/*.tar.gz

分别记录当前防火墙状态：

ufw status numbered 2>/dev/null || true
firewall-cmd --get-active-zones 2>/dev/null || true
firewall-cmd --list-all-zones 2>/dev/null || true
nft list ruleset 2>/dev/null > /root/hardening-backup/nft-before.txt || true

这些命令出现“命令不存在”并不代表失败，通常只是该服务器没有使用对应防火墙工具。后续应只选择当前实际使用的一个管理入口，避免同时用 UFW、firewalld 和手工 nftables 维护同一套规则。

二、第一优先级：清点端口并收敛公网暴露面

1. 查看所有监听端口

先从端口和进程对应关系入手，而不是直接关闭“看起来可疑”的端口：

ss -H -lntup
ss -H -lnup
systemctl list-sockets --all

参数含义如下：

• -l：只看监听状态；
• -n：不进行域名解析，避免等待；
• -t：TCP；
• -u：UDP；
• -p：显示关联进程，通常需要 root 权限。

典型输出可能类似下面的模拟结果，实际端口和进程名称以服务器为准：

tcp LISTEN 0  128 0.0.0.0:22    0.0.0.0:* users:(("sshd",pid=812,fd=3))
tcp LISTEN 0  511 0.0.0.0:80    0.0.0.0:* users:(("nginx",pid=1042,fd=6))
tcp LISTEN 0  511 [::]:443      [::]:*    users:(("nginx",pid=1042,fd=7))
tcp LISTEN 0  100 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=930,fd=6))

0.0.0.0 或 [::] 表示服务可能接受所有 IPv4 或 IPv6 地址上的连接；127.0.0.1 通常只接受本机访问，但仍需结合应用配置确认。

2. 按业务逐个判断端口

常见端口的处理优先级如下：

数据库端口“没有密码”不是唯一问题。即使密码足够复杂，公网可达也会增加扫描、漏洞利用和认证消耗面。更稳妥的状态是应用监听本机或私网地址，防火墙只允许必要的应用网段。

定位某个端口属于哪个 systemd 服务，可以使用：

ps -fp 812
systemctl status sshd 2>/dev/null || systemctl status ssh 2>/dev/null
systemctl status nginx

如果进程由容器或第三方守护程序启动，还要检查容器端口映射和启动脚本：

command -v docker >/dev/null && docker ps --format 'table {{.Names}}\t{{.Ports}}'
grep -R "^[^#].*:[0-9]\+:" /etc/systemd/system /lib/systemd/system 2>/dev/null | head

不要仅执行 kill 或直接删除服务目录。先确认监听端口的业务归属、配置文件、开机启动方式和回滚方法。

3. 配置主机防火墙

云平台安全组、服务商边界防火墙和 Linux 主机防火墙应形成相同或更严格的访问边界。管理端口的来源地址最好使用固定办公出口、堡垒机或管理网段；示例中的 203.0.113.10/32 是文档保留地址，不能直接作为真实规则使用。

Debian/Ubuntu 使用 UFW

先查看已有规则，确认没有依赖旧规则的业务：

ufw status verbose

在第二个 SSH 会话保持连接的前提下，按实际端口添加规则。以下示例允许管理地址访问 TCP 22，并开放 Web 端口：

ufw allow from 203.0.113.10/32 to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw default allow outgoing
ufw default deny incoming
ufw logging low
ufw --force enable

如果 SSH 使用其他端口，应先添加该端口规则，再考虑关闭 22。不要把“修改 SSH 端口”当作主要安全措施；端口变化只能减少低质量扫描，不能替代密钥认证和来源限制。

验证规则：

ufw status numbered
ufw show raw | head -n 80

RHEL 系使用 firewalld

先确认活动区域：

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all

若实际活动区域为 public，并且 Web 服务确实需要对外提供，可添加：

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload
firewall-cmd --zone=public --list-all

如果要限制 SSH 来源，必须先确认当前 ssh 服务规则不会与新规则冲突。一个示例流程如下：

firewall-cmd --permanent --zone=public --remove-service=ssh
firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="22" protocol="tcp" accept'
firewall-cmd --reload
firewall-cmd --zone=public --list-all

该操作可能导致原有管理来源失去连接，只有在第二会话、控制台或明确的管理网段规则已验证时才执行。IPv6 管理来源需要单独添加 family="ipv6" 的规则，不能用 IPv4 规则替代。

4. 验证端口是否真正收敛

本机检查只能说明规则和服务配置的状态，不能完全代表公网可见结果。应从允许的管理地址和一个不应被允许的外部地址分别测试：

nc -vz -w 5 服务器公网地址 22
nc -vz -w 5 服务器公网地址 80
nc -vz -w 5 服务器公网地址 443
nc -vz -w 5 服务器公网地址 3306

预期结果是：

• SSH、Web 等业务端口从允许来源连接成功；
• 数据库、缓存和未授权管理端口从外部连接失败或超时；
• IPv4 和 IPv6 的结果符合设计；
• 防火墙状态重载或服务器重启后仍然保持。

如果 nc 显示端口开放，但防火墙规则中没有对应放行项，应检查云平台安全组、容器端口映射或上游负载均衡。若本机监听为 127.0.0.1，外部仍然连接成功，则可能连接到另一层代理或其他地址，需要核对解析和入口设备。

三、第二优先级：保护认证入口

1. 创建独立管理账号

不要在尚未准备新账号时关闭 root 登录或密码登录。先创建管理员账号、导入公钥并验证 sudo。

Debian/Ubuntu 示例：

useradd -m -s /bin/bash secadmin
usermod -aG sudo secadmin

RHEL 系示例：

useradd -m -s /bin/bash secadmin
usermod -aG wheel secadmin

将预先核验过的公钥保存为 /root/secadmin_authorized_keys，再设置正确的目录和文件权限：

install -d -o secadmin -g secadmin -m 700 /home/secadmin/.ssh
install -o secadmin -g secadmin -m 600 \
  /root/secadmin_authorized_keys \
  /home/secadmin/.ssh/authorized_keys

为账号配置 sudo 权限时，不建议直接修改主文件。使用 visudo 校验独立配置：

printf '%s\n' 'secadmin ALL=(ALL:ALL) ALL' > /etc/sudoers.d/secadmin
chmod 440 /etc/sudoers.d/secadmin
visudo -cf /etc/sudoers

在 RHEL 系上也可使用：

printf '%s\n' 'secadmin ALL=(ALL) ALL' > /etc/sudoers.d/secadmin
chmod 440 /etc/sudoers.d/secadmin
visudo -cf /etc/sudoers

从新的终端验证：

ssh secadmin@服务器公网地址
sudo -v
id

只有新账号能够登录并成功执行 sudo -v，才进入下一步。

2. 调整 SSH 服务配置

先备份并检查当前有效配置：

cp -a /etc/ssh/sshd_config \
  "/root/hardening-backup/sshd_config.$(date +%F-%H%M%S)"

sshd -T | egrep 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|maxauthtries|allowusers|x11forwarding|allowtcpforwarding'

如果系统支持 /etc/ssh/sshd_config.d/ 且主配置已包含该目录，可建立独立加固文件：

cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
X11Forwarding no
EOF
chmod 600 /etc/ssh/sshd_config.d/99-hardening.conf

以下配置需要按业务决定，不能机械启用：

• AllowUsers 或 AllowGroups：适合明确管理账号的服务器，但会影响自动化账号、监控账号和应急账号；
• AllowTcpForwarding no：可减少转发能力，但可能破坏合法运维通道；
• ClientAliveInterval 与 ClientAliveCountMax：可回收失联会话，但不应替代账号和网络控制；
• 修改 Port：需要同步更新云安全组、主机防火墙、监控和自动化脚本。

先验证语法，再重载，不要直接重启：

sshd -t

sshd -t 无输出通常表示语法通过。随后根据服务名重载：

systemctl reload ssh 2>/dev/null || systemctl reload sshd
systemctl is-active ssh 2>/dev/null || systemctl is-active sshd

在原连接不关闭的情况下，使用第二个终端重新登录并执行：

ssh secadmin@服务器公网地址
sudo -v

如果新会话成功、旧会话仍然稳定，才可关闭原有 root 会话。

3. 认证异常处理

• Permission denied (publickey)：检查公钥是否为单行、目录是否为 700、文件是否为 600，并确认属主是目标账号。
• sudo: unable to resolve host：检查主机名与 /etc/hosts、DNS 配置，不要为了消除提示而放宽 sudo 权限。
• SSH 服务重载失败：立即查看 sshd -t 和 journalctl -u ssh -u sshd -n 80 --no-pager，不要继续修改防火墙。
• 所有会话都断开：通过控制台恢复备份的 SSH 配置；如果只是密码登录被关闭，则使用已验证的公钥账号登录。
• 自动化任务无法登录：核对其专用账号是否被 AllowUsers 排除，不要重新开放 root 登录作为临时解决方案。

四、第三优先级：落实最小权限和服务隔离

1. 检查过宽的文件权限

先查看 /etc 和自定义程序目录中是否存在普通用户可写文件：

find /etc /usr/local/bin -xdev -type f -perm /022 -ls 2>/dev/null

检查 SUID 文件时只做清单，不要直接批量删除：

find / -xdev -type f -perm -4000 \
  -printf '%m %u %g %p\n' 2>/dev/null

SUID 程序可能是发行版正常组件。正确做法是将清单与系统软件包核对，确认来源、用途和最近变更，再决定是否移除软件包或调整权限。直接执行全盘 chmod 可能破坏 SSH、sudo、日志和服务启动。

检查关键目录：

stat -c '%A %a %U:%G %n' /etc/passwd /etc/shadow /etc/group /etc/sudoers
ls -ld /tmp /var/tmp

/tmp 和 /var/tmp 通常需要设置粘滞位，例如权限显示为 1777。如果目录承载业务文件，先确认没有被应用用作固定工作目录，再修改权限。

2. 让应用使用专用账号

应用、Web 服务和任务程序不应长期以 root 身份运行。创建系统账号时，应根据系统实际路径确认 nologin 位置：

command -v nologin
useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

如果 nologin 位于 /sbin/nologin，应替换命令中的路径。之后检查服务配置中的 User=、Group= 或启动脚本：

systemctl cat example.service
systemctl show example.service -p User -p Group

对独立应用目录，可以使用类似下面的示例权限模型，但不能未经确认直接套到现有网站目录：

chown -R root:appsvc /srv/example-app
find /srv/example-app -type d -exec chmod 750 {} +
find /srv/example-app -type f -exec chmod 640 {} +

需要写入的上传目录、缓存目录或运行时目录，应单独划分，避免把整个代码目录设为可写。每次执行递归 chown 或 chmod 前，应确认路径没有变量为空、没有软链接指向系统目录，也没有多个服务共享该目录。

3. 对 systemd 服务增加隔离

对支持 systemd 的应用，可以使用 drop-in 配置增加基础隔离：

systemctl edit example.service

写入：

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=full

保存后执行：

systemctl daemon-reload
systemctl restart example.service
systemctl status example.service --no-pager

如果应用需要写入 /var/lib/example、读取特定用户目录或调用额外内核能力，上述选项可能导致启动失败。异常时查看：

journalctl -u example.service -b -n 100 --no-pager

将 ProtectSystem=strict、ReadWritePaths=、网络命名空间和能力集限制作为测试后再启用的增强项。最小权限的目标是减少服务能访问和修改的范围，而不是让服务在没有验证的情况下立即失去所有运行能力。

五、补丁和内核快速响应

1. 先模拟更新，再正式更新

Debian/Ubuntu：

apt-get update
apt list --upgradable
apt-get -s upgrade

如果内核或关键依赖需要联动升级，再单独评估：

apt-get -s dist-upgrade

模拟结果中若出现删除核心网络、SSH、文件系统或云代理组件的计划，应先停止执行并确认原因。确认仓库和变更范围后再执行正式更新：

apt-get upgrade

RHEL 系：

dnf check-update
dnf updateinfo list updates security
dnf upgrade --assumeno

dnf check-update 返回代码 100 通常表示存在可更新包，不等同于命令故障。查看模拟结果后，可按维护窗口执行：

dnf upgrade

如果组织明确使用安全公告元数据，也可以评估：

dnf upgrade --security

不要混用不同发行版的内核包，也不要使用未经验证的脚本替换包管理器。对于“7.2”这类自定义版本，首先核对：

uname -r
rpm -qf "/boot/vmlinuz-$(uname -r)" 2>/dev/null || true
dpkg -S "/boot/vmlinuz-$(uname -r)" 2>/dev/null || true

2. 判断是否需要重启

用户空间库更新后，部分服务可以通过重启服务加载新库；内核更新则通常要重启才能使用新内核。检查当前运行内核和已安装内核：

uname -r
ls -lh /boot/vmlinuz* /boot/initramfs* 2>/dev/null

Debian/Ubuntu 可检查：

command -v needrestart >/dev/null && needrestart -b

RHEL 系可检查：

command -v needs-restarting >/dev/null && needs-restarting -r

重启前确认以下事项：

• 已记录当前运行内核版本；
• 旧内核仍保留在 /boot，没有被提前清理；
• 云控制台或串口可用；
• 业务维护窗口已确认；
• SSH 新账号和防火墙规则已经验证；
• 数据库、队列和应用具备正常停止或自动恢复能力。

执行重启：

systemctl reboot

服务器恢复后检查：

uname -r
uptime
systemctl --failed
journalctl -b -k -p warning..alert --no-pager

成功标准不是“版本号变成 7.2”或其他指定字符串，而是：运行中的内核来自批准的软件包来源，目标漏洞对应的修复包已安装，关键服务正常，日志没有出现新的启动错误。

3. 建立漏洞补丁快速响应流程

收到内核或系统组件漏洞通知后，可按下面顺序处理：

1. 记录漏洞影响的组件、受影响版本、是否需要本地权限或网络可达。
2. 在目标服务器执行 uname -r、包归属和仓库核验，确认不是只看字符串版本。
3. 先在同发行版、同架构的测试实例模拟更新。
4. 对生产香港节点创建快照或确认可用备份，安排维护窗口。
5. 更新安全包，必要时同步更新内核和引导文件。
6. 重启后验证内核、端口、SSH、应用、磁盘和日志。
7. 保存更新前后版本、执行时间、异常和回滚结果。

如果补丁尚未提供，不能通过随意更换内核、关闭防火墙或开放更多端口来“缓解”问题。可优先采取供应商公告中明确支持的配置缓解措施，例如限制来源、关闭非必要服务、将后端服务绑定到本机或私网，并持续跟踪正式修复包。

六、防火墙之后的审计和持续检查

1. 保证日志可持久保存

检查 journald 当前状态：

journalctl --disk-usage
journalctl -b -p warning..alert --no-pager

如果日志重启后丢失，可启用持久化目录：

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
journalctl --disk-usage

日志保留量应结合磁盘空间设置。示例配置如下：

mkdir -p /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/20-retention.conf <<'EOF'
[Journal]
SystemMaxUse=1G
MaxRetentionSec=30day
EOF
systemctl restart systemd-journald

1G 和 30day 只是示例值。若磁盘小于该容量，或者服务器承担高频日志业务，应按日志增长量重新估算，并配置外部日志归档。

2. 启用 auditd 记录关键变更

Debian/Ubuntu：

apt-get install auditd
systemctl enable --now auditd

RHEL 系：

dnf install audit
systemctl enable --now auditd

创建一组基础规则：

cat > /etc/audit/rules.d/50-hardening.rules <<'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/sudoers.d -p wa -k privilege
-w /etc/ssh/sshd_config -p wa -k ssh
-w /etc/ssh/sshd_config.d -p wa -k ssh
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands
EOF
augenrules --load
auditctl -s
auditctl -l

user_commands 规则可能产生较多日志，磁盘容量和审计策略不足时，不应盲目扩大记录范围。审计重点应放在账号、sudo、SSH、防火墙、服务文件和关键应用配置。

验证规则是否能产生记录：

ausearch -k identity -ts today --interpret
ausearch -k ssh -ts today --interpret

若 augenrules --load 报错，应查看具体规则语法和当前审计锁定状态。有些系统启用了不可运行时修改的审计模式，这时需要在维护窗口通过配置和重启加载新规则。

3. 建立定期人工核对项

可以将以下命令纳入每日或每周检查：

ss -H -lntup
systemctl --failed
journalctl -p err..alert --since "24 hours ago" --no-pager
last -a | head -n 20
lastb -a | head -n 20

重点关注：

• 新增的公网监听端口；
• SSH 失败登录是否突然增加；
• 不明服务是否被设置为开机启动；
• sudo、SSH 和防火墙配置是否发生非计划变更；
• 内核启动日志是否出现文件系统、驱动或安全模块错误。

香港节点的地理位置不能代替访问控制。来源地址可能来自任何地区，且攻击流量可能经过云平台、被盗账号或自动化扫描网络；应以端口、身份和来源策略为准，而不是以 IP 地理归属作为安全判断。

七、异常处理顺序

出现问题时，优先采用低风险、可观察的处理方式：

1. 先检查云安全组、主机防火墙和服务监听状态，确认是网络拒绝、端口未监听还是应用自身报错。
2. 再检查 SSH 有效配置、账号公钥、sudoers 语法和服务日志。
3. 接着检查服务账号权限、目录属主、SELinux 或其他强制访问控制日志。
4. 最后再考虑回滚内核、还原系统配置或重启服务器。

常见现象与处理方向如下：

八、验收与回滚检查项

完成加固后，建议将以下结果作为一次验收记录：

• [ ] cat /etc/os-release、uname -r 和内核包归属已记录。
• [ ] 当前运行内核来自批准的软件包来源，旧内核仍保留到稳定运行完成。
• [ ] ss -H -lntup 中每个公网监听端口都有业务归属。
• [ ] SSH 仅允许必要来源，公钥账号可登录，sudo -v 成功。
• [ ] root 远程登录和不必要的密码认证已按计划关闭。
• [ ] 80/443 等业务端口从允许来源可达，数据库、缓存和内部服务从外部不可达。
• [ ] IPv4、IPv6、云安全组和主机防火墙规则没有明显缺口。
• [ ] 关键服务不以 root 运行，应用目录没有不必要的全局写权限。
• [ ] sshd -t、visudo -cf /etc/sudoers、systemctl --failed 和内核日志检查通过。
• [ ] journald 持久化、auditd 规则和日志保留策略已经验证。
• [ ] 变更前备份、执行时间、变更项和责任人已留档。

需要回滚 SSH 配置时，先通过控制台或保留的管理会话恢复备份，再验证并重载：

rm -f /etc/ssh/sshd_config.d/99-hardening.conf
cp -a /root/hardening-backup/sshd_config.变更时间 /etc/ssh/sshd_config
sshd -t
systemctl reload ssh 2>/dev/null || systemctl reload sshd

实际执行时应将示例中的备份文件名替换为真实文件名。UFW 可以使用 ufw status numbered 找到规则编号后逐条删除，或在确认无其他依赖时执行：

ufw disable

firewalld 应恢复变更前保存的区域配置后再重载；使用 nftables 的服务器则只能将变更前导出的规则集加载回同一套后端。回滚防火墙前必须保留控制台通道，避免恢复过程中再次断开。

如果新内核启动异常，应在控制台的引导菜单选择旧内核启动，确认网络、磁盘和服务恢复后，再根据发行版包管理器处理新内核包。不要在未完成验证前删除旧内核。文件权限和服务账号变更则应从带 ACL、扩展属性的备份中恢复，不能只凭记忆执行一组反向 chmod。