linux主机安全基线如何设置：账号、SSH、防火墙与审计

先把上线前的风险范围划清楚

Linux 主机上线前最容易留下的薄弱点，通常不是某一个“高危漏洞”，而是几类基础配置同时偏松：默认账号未清理、root 可远程登录、SSH 仍允许密码爆破、防火墙规则过宽、登录失败和权限变更没有日志可查。这样的主机即使业务程序本身没有明显问题，也容易在暴露到公网后被扫描、撞库或横向利用。

这里的 linux 安全基线，建议理解为“上线前必须满足的最小安全配置集合”。它不等于百分百安全，也不能替代漏洞修复、业务权限设计和入侵检测，但可以显著降低常见攻击面。以下操作适用于常见 Debian、Ubuntu、CentOS、Rocky Linux、AlmaLinux 等发行版，具体命令需要先确认系统版本、SSH 服务名和当前防火墙组件。

上线前建议先满足三个前置条件：

已有可用的控制台、VNC、IPMI 或云平台远程登录方式，避免 SSH 配错后彻底失联。
已确认业务端口，例如 Web 服务常见为 80/443，数据库、管理后台、监控端口需结合实际服务确认，不能照抄规则。
修改 SSH、防火墙、sudo 配置前，保留一个已登录的 root 或管理员会话，不要在未验证新会话前断开。

威胁场景：公网 Linux 主机常见的三类入口

公网 Linux 主机上线后，SSH 端口通常会很快被扫描。攻击者不需要知道业务细节，只要发现 22 端口开放，就可能尝试 root、admin、test、oracle、postgres 等常见账号，并使用弱口令字典持续登录。

第二类风险来自权限扩大。比如临时账号没有过期、普通用户被加入了 sudo 组但没有操作留痕、多人共用同一个账号。这类问题在短期内不一定造成故障，但一旦出现误操作或异常登录，很难判断是谁、在什么时间、通过什么方式执行了命令。

第三类风险是网络面过宽。为了排障临时关闭防火墙，或者直接放行所有入站端口，是很多主机被误暴露的原因。防火墙不建议长期关闭，尤其是数据库、缓存、面板、内部 API 等服务，如果没有访问源限制，就可能被外部直接探测。

账号与 sudo 权限控制：先减少可登录身份

账号基线的目标不是“账号越少越好”，而是确保每个可登录账号都有明确用途、最小权限和可审计记录。上线前应重点检查四件事：root 是否需要远程登录、业务账号是否允许 shell、sudo 是否按人授权、临时账号是否有生命周期。

建立独立管理员账号，避免共用 root

建议创建个人管理员账号，再通过 sudo 执行需要提权的操作。不同发行版默认 sudo 管理组不同：Ubuntu/Debian 常用 sudo 组，RHEL 系常用 wheel 组。

# Ubuntu / Debian
sudo adduser ops_admin
sudo usermod -aG sudo ops_admin

# Rocky / AlmaLinux / CentOS
sudo useradd -m ops_admin
sudo passwd ops_admin
sudo usermod -aG wheel ops_admin

检查当前具备 sudo 权限的用户：

getent group sudo
getent group wheel

如果系统中存在历史账号，应逐一判断用途：

awk -F: '$3 >= 1000 {print $1,$3,$7}' /etc/passwd

结果中的第三列是 UID，第七列是登录 shell。业务运行账号如果不需要交互登录，建议使用 /usr/sbin/nologin 或 /sbin/nologin，避免被当作登录入口。

sudo usermod -s /usr/sbin/nologin appuser

不同系统的 nologin 路径可能不同，可先执行：

command -v nologin

sudo 配置必须用 visudo 管理

不要直接用编辑器修改 /etc/sudoers，语法错误可能导致所有 sudo 失效。应使用：

sudo visudo

如果需要给某个运维组授权，建议放到 /etc/sudoers.d/ 下，并使用 visudo -f 检查：

sudo visudo -f /etc/sudoers.d/ops-admin

示例：

%ops-admin ALL=(ALL) ALL

如果业务确实需要免密执行某个固定命令，应限制到具体命令，不要直接给 NOPASSWD: ALL。例如只允许重载 Nginx：

deploy ALL=(root) NOPASSWD: /usr/sbin/nginx -s reload

这类授权要谨慎，因为脚本、通配符和可写目录可能间接扩大权限。上线前应检查 sudo 规则是否存在过宽配置：

sudo grep -R "NOPASSWD\|ALL=(ALL).*ALL" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

SSH 登录策略与密钥管理：先验证，再收紧

SSH 是 Linux 主机最常见的管理入口。安全基线推荐使用密钥登录、限制 root 远程登录、减少可登录用户范围，并根据业务要求决定是否修改默认端口。需要注意，改端口只能减少低质量扫描，不等于真正的安全控制；密钥、权限和访问来源限制更重要。

修改 SSH 前先备份并检查服务名

常见配置文件为 /etc/ssh/sshd_config，部分新系统会使用 /etc/ssh/sshd_config.d/*.conf 覆盖配置。修改前先备份：

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

确认 SSH 服务名：

systemctl status ssh
systemctl status sshd

Ubuntu/Debian 多数为 ssh，RHEL 系多数为 sshd。后续重载服务时应以实际结果为准。

使用密钥登录并保护 authorized_keys 权限

在本地管理终端生成密钥：

ssh-keygen -t ed25519 -C "ops_admin@server"

将公钥写入服务器用户目录：

ssh-copy-id ops_admin@服务器IP

如果没有 ssh-copy-id，可手动创建：

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

服务端用户家目录和 .ssh 权限过宽时，SSH 可能拒绝读取密钥。可检查：

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

密钥管理建议遵循以下原则：

每个人使用独立密钥，不多人共用同一个私钥。
私钥不得上传到服务器、代码仓库或工单附件。
离职、岗位变更或外包结束时，及时移除对应公钥。
重要主机可为私钥设置 passphrase，并结合堡垒机或集中审计系统管理。

收紧 sshd_config 的核心项

建议新建一个独立配置片段，便于回滚和审计。若系统不支持 sshd_config.d，再写入主配置文件。

sudo mkdir -p /etc/ssh/sshd_config.d
sudo nano /etc/ssh/sshd_config.d/10-baseline.conf

参考配置如下：

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers ops_admin
MaxAuthTries 3
LoginGraceTime 30

配置说明：

PermitRootLogin no：禁止 root 直接远程登录，改用普通账号加 sudo。
PasswordAuthentication no：关闭密码登录，前提是密钥登录已经验证成功。
AllowUsers ops_admin：只允许指定用户 SSH 登录，多人运维时应列出所有管理员账号。
MaxAuthTries 3：降低单连接内反复尝试密码或密钥的机会。
X11Forwarding no：多数服务器不需要图形转发，可关闭。

保存后先做语法检查：

sudo sshd -t

没有输出通常表示语法通过。然后重载服务，不建议直接重启当前会话依赖的 SSH：

# Ubuntu / Debian 常见
sudo systemctl reload ssh

# RHEL / Rocky / AlmaLinux 常见
sudo systemctl reload sshd

保持当前窗口不关闭，另开一个新终端测试：

ssh ops_admin@服务器IP
sudo -l

确认可以登录并具备预期 sudo 权限后，再测试 root 和密码登录是否被拒绝。若新会话无法登录，应立即使用原会话回滚配置。

防火墙放行原则：默认拒绝，按服务最小开放

防火墙基线的核心原则是：入站默认拒绝，只放行业务必需端口；管理端口限制来源；出站是否限制由业务依赖决定。不同业务端口放行策略必须结合实际服务确认，例如数据库只应允许应用服务器或内网访问，不能因为“排障方便”直接开放到公网。

先盘点监听端口，再写规则

上线前先查看当前监听端口和进程：

sudo ss -lntup

重点关注：

0.0.0.0:端口 或 [::]:端口：表示监听所有地址，公网环境下可能直接暴露。
127.0.0.1:端口：仅本机访问，通常风险较低。
数据库、Redis、Elasticsearch、管理面板、Prometheus 等服务是否意外监听公网地址。

可以形成一张放行清单：

端口	协议	用途	放行来源	是否必须公网开放
22 或自定义 SSH 端口	TCP	运维登录	固定办公 IP / 堡垒机	不建议全网开放
80	TCP	HTTP	全网或指定代理	视业务而定
443	TCP	HTTPS	全网或指定代理	视业务而定
数据库端口	TCP	应用访问	应用服务器内网 IP	不建议公网开放
监控端口	TCP	指标采集	监控服务器 IP	不建议公网开放

Ubuntu 使用 UFW 的示例

启用防火墙前务必先放行当前 SSH 来源，否则可能断开连接。假设管理来源为 203.0.113.10，SSH 端口为 22：

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

如果当前 SSH 管理来源不是固定 IP，可以暂时放行 SSH 端口，但上线后应尽快改为固定来源、VPN 或堡垒机访问：

sudo ufw allow 22/tcp

RHEL 系使用 firewalld 的示例

先查看当前区域和服务：

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

放行 Web 服务，并限制 SSH 来源可使用 rich rule：

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" service name="ssh" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

如果系统原本默认放行了 SSH 服务，而你已经添加了来源限制，需要确认是否仍存在全网 SSH 放行。不同 zone 配置差异较大，删除规则前要确认当前连接来源，避免误断。

sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

这一步有断连风险，只应在确认 rich rule 已生效、且有控制台回退手段时执行。

审计与日志检查：配置是否生效要靠日志验证

安全基线不是写完配置就结束，必须验证登录行为、防火墙命中、sudo 提权和异常失败是否有记录。日志能回答三个问题：谁登录了、从哪里登录、执行了什么高权限操作。

检查 SSH 登录与失败记录

Debian/Ubuntu 常见日志：

sudo grep -E "Accepted|Failed|Invalid user|Disconnected" /var/log/auth.log | tail -n 50

RHEL/Rocky/AlmaLinux 常见日志：

sudo grep -E "Accepted|Failed|Invalid user|Disconnected" /var/log/secure | tail -n 50

使用 systemd 的系统也可以查看服务日志：

# 根据实际服务名选择 ssh 或 sshd
sudo journalctl -u ssh --since "1 hour ago"
sudo journalctl -u sshd --since "1 hour ago"

结果解释：

Accepted publickey：密钥登录成功，符合推荐基线。
Accepted password：仍存在密码登录，需要确认是否符合预期。
Failed password for root：root 密码尝试，应确认 root 登录是否已经禁止。
Invalid user：有人尝试不存在账号，公网主机常见，但频率过高时应增加来源限制或使用防爆破策略。

检查 sudo 和账号变更记录

查看近期登录用户：

last -a | head

查看失败登录记录：

sudo lastb -a | head

部分系统默认没有启用或没有生成 /var/log/btmp，如果命令无结果，不代表没有攻击，只能说明该日志来源不可用或尚无记录。

查看 sudo 使用记录：

sudo grep "sudo:" /var/log/auth.log 2>/dev/null | tail -n 30
sudo grep "sudo:" /var/log/secure 2>/dev/null | tail -n 30

如果需要更完整的系统审计，可以启用 auditd。安装方式依发行版不同：

# Ubuntu / Debian
sudo apt update
sudo apt install auditd audispd-plugins

# Rocky / AlmaLinux / CentOS
sudo dnf install audit audit-libs
sudo systemctl enable --now auditd

查看认证相关事件示例：

sudo ausearch -m USER_LOGIN,USER_AUTH,USER_ACCT -ts recent

auditd 适合记录关键系统事件，但规则过多会增加日志量和排查成本。上线前至少应保证 SSH、sudo、系统认证日志可读、时间准确，并配置好日志轮转。

时间同步会影响审计可信度

如果服务器时间不准，登录时间、攻击时间线和业务日志会对不上。检查时间同步状态：

timedatectl

常见系统可启用 chrony 或 systemd-timesyncd，具体以发行版默认组件为准。安全审计中，时间一致性是基础条件，不建议忽略。

上线前验证清单：按风险优先级逐项确认

建议按“账号 → SSH → 防火墙 → 日志”的顺序验证，因为账号和 SSH 配错会直接影响管理入口，防火墙配错会影响业务访问，日志则用于确认前两者是否真正生效。

保持当前管理员会话不断开，另开新终端测试 SSH。
使用普通管理员账号登录，确认密钥登录成功。
执行 sudo -l，确认 sudo 权限符合预期。
尝试 root SSH 登录，应被拒绝。
如已关闭密码登录，使用无密钥方式测试，应被拒绝。
使用 ss -lntup 确认监听端口与预期一致。
使用防火墙状态命令确认只放行必要端口。
从允许来源访问 SSH，从非允许来源验证无法访问。
访问业务端口，例如 80/443，确认业务没有被误拦截。
查看认证日志，确认成功、失败、sudo 操作都有记录。

常用验证命令：

sudo sshd -t
sudo ss -lntup
sudo journalctl --since "30 minutes ago" | grep -Ei "ssh|sudo|auth|failed|accepted"

如果服务器承载线上业务，建议在低峰期执行防火墙和 SSH 策略变更，并提前准备回滚命令。

应急处理：SSH 或防火墙配置失误时如何回滚

安全加固最怕“改完无法登录”。因此每一次修改都应有明确回滚条件：新 SSH 会话无法建立、业务端口无法访问、防火墙规则与预期不符、日志出现大量拒绝且影响正常用户时，应立即回退。

SSH 配置回滚

如果新会话无法登录，但旧会话还在，先恢复备份：

sudo cp /etc/ssh/sshd_config.bak.日期时间 /etc/ssh/sshd_config
sudo rm -f /etc/ssh/sshd_config.d/10-baseline.conf
sudo sshd -t

确认语法无误后重载服务：

# Ubuntu / Debian 常见
sudo systemctl reload ssh

# RHEL / Rocky / AlmaLinux 常见
sudo systemctl reload sshd

如果所有 SSH 会话都已断开，只能通过控制台、VNC、IPMI 或云平台救援模式进入系统，再恢复配置。

防火墙规则回滚

UFW 可先查看规则编号：

sudo ufw status numbered

再删除错误规则：

sudo ufw delete 编号

如需临时恢复管理入口，可添加来源放行：

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

firewalld 可查看当前规则：

sudo firewall-cmd --list-all

删除错误的永久规则后重新加载：

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

如果误拦截了 SSH，应优先从控制台进入后修正规则，而不是长期关闭防火墙。短时间停用防火墙只适合隔离环境排障，排障后必须恢复最小放行策略。

持续观察项：上线后不要把基线当成一次性任务

Linux 主机安全基线需要随着业务变化持续校准。新增服务、调整管理来源、增加运维人员、迁移数据库，都可能让原来的规则不再合适。建议至少定期检查以下内容：

/etc/passwd 中是否出现未知可登录账号。
sudoers 是否新增过宽授权。
ss -lntup 是否出现未登记监听端口。
SSH 日志中是否仍有大量密码尝试或 root 尝试。
防火墙规则是否存在临时放行后未清理的端口。
离职或不再维护项目的人员公钥是否仍在 authorized_keys 中。
认证日志、sudo 日志和 auditd 日志是否正常轮转，磁盘是否被日志占满。

当出现以下情况时，应触发回滚或重新评估：新策略影响业务访问、管理员无法通过预期方式登录、日志无法记录关键操作、端口放行范围超出业务清单、临时账号和临时规则超过约定期限仍未清理。安全基线的价值在于让主机处于“可管理、可验证、可回退”的状态，而不是追求一次配置后永远不变。

Linux运维安全加固 SSH 防火墙日志审计

上一篇 海外服务器部署Next.js SSR站点，PM2、Nginx反向代理与HTTPS配置如何配合 下一篇 香港节点网站访问速度慢，性能测试应同时看TTFB、带宽与应用耗时