1. 先想清楚Linux加固到底在防什么每次有人让我帮忙看一眼服务器安全性我第一句话都不是问装了什么东西而是反问一句你希望这台机器被攻破之后损失上限是多少这个问题听起来很虚但恰恰决定了加固方案的边界。很多教程上来就让你改SSH端口、关root登录、装Fail2ban照做一遍感觉挺踏实实际上只挡住了最外围的“随手扫描流量”真正有目标的攻击者连腰都没弯。Linux系统安全加固本质上是做两件事收缩攻击面增加攻击成本。攻击面指的是这台机器对外暴露的所有入口——开放端口、运行的服务、可登录的账户、可执行的文件、可被篡改的配置。攻击成本则是攻击者拿到权限之后还要花多大精力才能稳住脚跟、扩大战果。我见过不少团队把精力全花在第一件事上结果一台机器被人种了后门因为文件权限太松散任何用户都能往启动目录里丢东西加固做了等于没做。这篇文章是系统安全加固系列的第一篇聚焦Linux环境。我会按我自己在生产环境里实际操作的顺序来讲先收敛账户和登录入口再压SSH风险面然后调内核参数和文件系统权限最后补上审计和监控。每一节都会说清楚这么做的原因以及哪些环节容易踩坑。内容偏实战适合刚接手服务器运维的开发者也适合想系统梳理安全基线的人。我现在所在的团队长期维护几十台Linux节点有云主机也有物理机发行版以 CentOS 和 Ubuntu 为主。下面所有配置都是这两类系统上验证过的Debian 系和 RHEL 系的主要差异我会单独标注其他发行版参考思路即可。2. 账户与登录入口的收敛删掉不用的门比把门锁换得更高级更重要2.1 从账户清单开始我接手任何一台机器第一件事永远是跑cat /etc/passwd和cat /etc/shadow把每一行都过一遍。这一步非常基础但很多人从来没有认真看过自己机器上到底有多少个账户。默认安装的Linux系统会带出一批系统账户比如 daemon、bin、lp、mail、nobody 这些它们多数是历史遗留没有登录Shell也没有实际用途但留着它们没有任何好处——每个账户都是一个潜在的身份载体。生产环境里更常见的问题是自己创建的账户冗余。比如项目早期测试时建的临时账号或者某个同事离职之后没人清理的旧账号甚至还有直接给应用创建了超级用户权限账户的情况。我的建议是每台机器上可交互登录的账户控制在个位数最好就是两三个管理员再加一个专用的部署账户。其他一律删除或者锁定。检查账户的时候重点看三列是否有可用的Shell/bin/bash、/bin/sh这类是否在 shadow 文件里有密码哈希以及 UID 是否为 0。任何 UID 为 0 的非 root 账户都是极其危险的信号等于直接给了另一个超级用户权限。我见过某台机器上有个叫 sync 的老账户 UID 是 0一查是很多年以前有人图方便直接改的这就是典型的隐藏风险。2.2 清理和锁定的正确姿势清理账户不是直接userdel -r就完事。我的操作顺序是先锁定、再观察、最后删除。因为有些账户虽然在 passwd 里存在但可能被某个启动脚本或者 cron 任务引用直接删掉会导致服务起不来。锁定命令有两种passwd -l username和usermod -L username效果类似都是在 shadow 文件的密码字段前加个感叹号让密码验证永远失败。但注意这只禁止了密码登录如果账户配置了SSH密钥依然可以登录。所以更稳妥的做法是把 Shell 也换掉usermod -s /sbin/nologin username这样即使有人拿着这个账户的密钥来登录也会直接被拒绝分配Shell。对于已经确定废弃的账户等观察一两周没有服务报错之后再执行userdel -r username连同家目录一起清掉。还有一个细节容易被忽略检查/etc/sudoers或者/etc/sudoers.d/目录下的文件。很多时候账户是清理了但 sudo 授权条目还留着万一 UID 被复用新账户自动继承管理员权限。我习惯是清理账户的同时把对应的 sudo 条目一并删掉并且每年做一次授权清单复核。2.3 root 账户的处理思路root 该不该直接禁用这是安全加固里争议最多的话题之一。我的观点是root 账户不应该被删但应该让它无法直接被登录所有管理操作通过 sudo 来执行。原因是 root 一旦被设置为不可登录攻击者就算拿下了某个普通账户也还需要再攻破 sudo 的密码验证多了一层阻力。具体配置在后面SSH部分会详细讲这里先说明一个容易踩的坑不要随手passwd -l root。很多教程这么教但如果你用的是某些云平台的镜像系统里根本没有其他可用的 sudo 用户锁掉 root 之后你可能连机器都进不去。正确顺序是先创建一个具备 sudo 权限的管理账户测试能正常登录再处理 root 的登录限制。3. SSH 加固攻击者最常敲的窗口值得花一半精力去守3.1 从密钥登录和禁用密码开始SSH 是几乎所有Linux服务器最常被扫描的入口。默认的 22 端口配合密码认证每天都会被互联网上的扫描器尝试成千上万次。我见过最夸张的一台机器/var/log/secure里一天刷了十几万条失败登录记录全是来自各种僵尸网络的 SSH 爆破。加固第一步永远是更换认证方式禁用密码登录只允许密钥认证。这一步做完暴力破解基本就断了路因为攻击者没有你的私钥再怎么试密码也无济于事。操作前必须确认所有管理员已经生成并配置好了自己的公钥。生成密钥推荐用 Ed25519 算法而不是老旧的 RSAssh-keygen -t ed25519 -a 100 -C your_identifier-a 100指定 KDF 迭代次数默认值偏小适当调高可以延缓私钥被暴力猜测的速度。公钥放到服务器的~/.ssh/authorized_keys之后记得检查文件权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys权限不对的话sshd 会直接忽略这个文件导致密钥登录失败反而是个隐藏的坑。确认所有管理员都能用密钥登录之后再修改 sshd_configPasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM no这里有个细节ChallengeResponseAuthentication是老的键盘交互式认证开关很多时候以为关了密码登录但 PAM 模块还会允许空密码或简单密码尤其是 Ubuntu 上常见。我建议直接禁掉UsePAM不过要注意这个选项会影响到某些依赖 PAM 做二次认证的场景如果机器上有特殊需求至少保持ChallengeResponseAuthentication no。改完配置后sshd -t systemctl reload sshdsshd -t是语法自检这条命令不通过就绝对不能 reload不然你可能发现自己被锁在外面。另外reload 不会断开已建立的连接所以理论上不会把自己踢掉线但为了保险我建议测试新连接之前先开启第二个SSH会话保持一个兜底通道。3.2 改端口到底有没有用把 SSH 端口从 22 改成别的比如 2222、10022很多人觉得这是纯粹的心理安慰。我的评价是它治标不治本但确实是低成本降低扫描噪音的有效手段。互联网上的自动扫描器主要针对默认端口改了端口大量无差别扫描就会绕开你。但必须清醒认识到有针对性的攻击者可以快速扫描端口找到 SSH 服务。所以改端口只能作为辅助手段不能替代密钥认证和后续的访问控制。改的方式很简单Port 10022建议选择一个不常见的端口范围在 1024 到 65535 之间。改完别忘了更新防火墙放行规则否则自己先被挡在外面。另外如果机器上跑了 SELinux还需要同步调整端口标签semanage port -a -t ssh_port_t -p tcp 10022这个细节很容易漏掉很多 CentOS 用户改了端口死活连不上查半天才发现是 SELinux 拦截。3.3 用 AllowUsers 和 MaxAuthTries 压缩入口SSH 还有一个很重要的配置是限制允许登录的用户名单和认证尝试次数。AllowUsers的效果是白名单机制只有名单里的账户才能尝试登录名单之外的直接拒绝连密码验证环节都不会进入。我用一个专门的部署账户为例AllowUsers deploy admin1 admin2这样配置之后即使系统里还有残余的弱密码账户攻击者也没办法从SSH这个入口去试。MaxAuthTries控制的是每次连接允许的认证尝试次数默认值是 6有点偏大。我一般压到 3MaxAuthTries 3 LoginGraceTime 30LoginGraceTime是登录超时时间超过30秒没完成认证就断开连接。这两个参数组合起来配合密钥认证基本把SSH爆破的空间压缩到了很小。注意AllowUsers配置只能匹配用户名或者用户来源IP的格式。如果管理员经常从动态 IP 登录不要在这里绑得太死否则容易把自己锁在门外。我建议在 AllowUsers 里只控制用户名把来源 IP 的限制交给防火墙去做。3.4 关于 sshd_config 的权限和归属有一件事很多人都没注意到/etc/ssh/sshd_config这个文件本身如果权限过于宽松任何能写入的用户都可以给 sshd 偷偷加配置比如插一个危险的端口转发或者放行某个恶意账户。所以安装完系统之后我建议检查一下ls -l /etc/ssh/sshd_config确认归属是 root:root权限为 644 或更严格。/etc/ssh/目录下的主机密钥文件更敏感ssh_host_ed25519_key这种私钥文件权限应该是 600一旦泄露攻击者可以用它来伪装你的服务器发起中间人攻击。算法层面的调整也值得做。一些老版本系统还允许ssh-dss和ssh-rsa签名算法这两种都已经不安全了建议显式禁用KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512 HostKeyAlgorithms sk-ssh-ed25519openssh.com,ssh-ed25519 PubkeyAcceptedAlgorithms ssh-ed25519 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com,aes128-gcmopenssh.com配置完之后同样要sshd -t检查。这里提醒一句老版本的 OpenSSH7.0 以下可能不认识这些新算法名升级 OpenSSH 之前不要贸然套用否则会出现所有客户端都连不上的局面。4. 内核参数与网络栈让恶意数据包连敲门的机会都少了4.1 通过 sysctl 收紧网络行为Linux 内核的网络协议栈提供了很多可调参数其中一部分和系统安全息息相关。我平时会专门整理一批 sysctl 参数作为基线统一分发到所有服务器上。比较核心的有这么几个net.ipv4.ip_forward 0 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.all.send_redirects 0 net.ipv4.conf.all.accept_source_route 0 net.ipv4.tcp_syncookies 1 net.ipv4.icmp_echo_ignore_broadcasts 1 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.all.log_martians 1逐个解释一下。accept_redirects说的是是否接受ICMP重定向报文。重定向是路由器用来告诉主机“你走这条路更近”的机制但对于服务器来说基本用不上反而可能被攻击者用来篡改路由表把流量引到恶意设备上。关掉没毛病。accept_source_route是 IPv4 源路由选项攻击者可以用它指定数据包的传输路径从而绕过防火墙检测。现在的网络环境里源路由几乎没有合法用途直接关闭。tcp_syncookies是 SYN Cookie 机制当 SYN 队列被占满时通过构造特殊序列号的响应包来验证连接合法性这是抵御 SYN Flood 攻击的有效武器。默认值可能是 0务必改成 1。rp_filter是反向路径过滤启用后内核会检查数据包进来的接口是否与路由表一致不一致就丢弃。这是防 IP 地址伪造的重要手段。注意不要和net.ipv4.conf.all.rp_filter混淆all的值是逻辑或关系必须确保所有网卡的rp_filter都为 1。写入配置的方式是放在/etc/sysctl.d/99-security.conf里然后执行sysctl --system或sysctl -p生效。建议用独立文件而不是直接改/etc/sysctl.conf后续哪个参数出了问题方便单独排查和回滚。验证方式sysctl net.ipv4.tcp_syncookies4.2 关键网络层限制配合防火墙我见过一些团队调了很多内核参数却忘记检查防火墙规则结果服务器对外开放了十几个端口攻击面比预想的大得多。内核参数只能加固协议栈的行为但端口是否对外可访问是防火墙决定的事。我这里说一个“最小开放端口”的原则一台普通的Web服务器对外只需要开放 80HTTP和 443HTTPSSSH 端口只对管理网段开放。其余端口一律拒绝。用 nftables 或者 iptables 实现。下面是 nftables 的一个最小示例nft add table inet filter nft add chain inet filter input { type filter hook input priority 0; policy drop; } nft add rule inet filter input ct state established,related accept nft add rule inet filter input iif lo accept nft add rule inet filter input tcp dport 80 accept nft add rule inet filter input tcp dport 443 accept nft add rule inet filter input tcp dport 10022 ip saddr 192.168.10.0/24 accept注意策略是默认丢弃然后逐条放行。这个顺序千万不要写反先放行再丢弃会导致规则混乱。ct state established,related accept这一条很重要它保证已经建立的连接不会被误伤否则你的出站响应对应包会被自己防火墙拦掉表现为“能出去不能回来”。删除端口前先确认服务确实没在监听。判断监听状态ss -tlnp这个命令列出所有正在监听的TCP端口和对应进程比老的netstat -anp更简洁也是排查端口遗漏的首选工具。4.3 AIDE与文件完整性基线从网络层转向文件层网络和登录入口收紧了攻击者的直接入口变少但我们还要防“已经被突破之后”的情况。Linux 文件繁多攻击者留下的后门往往藏在某些关键系统文件里比如把/usr/bin/systemctl替换成带后门的版本或者往/etc/ld.so.preload里塞恶意动态库。这类篡改用肉眼看很难发现必须依赖文件完整性校验工具。AIDEAdvanced Intrusion Detection Environment是我常用的工具。它会在系统干净状态时采集文件哈希、权限、属主、文件大小等信息生成基线数据库。之后定期扫描对比一旦发现文件发生变化就告警。初始化过程aideinit默认数据库路径是/var/lib/aide/aide.db.gz。生产环境建议把数据库存放路径改到独立磁盘分区甚至远程存储否则攻击者同时篡改了文件又更新了数据库校验就形同虚设。我见过一台机器被人改了/bin/ls顺手也把 AIDE 数据库更新了等发现时已经过去了几个月。AIDE 的配置文件中有一个重要选项是排除目录比如/proc、/sys、/dev这些动态目录不能纳入校验否则每次扫描都会有大量噪音。另外/var/log/和/tmp/这类内容频繁变化的目录也建议排除聚焦于静态文件更有效。校验频率方面我是在 cron 里配置每天凌晨执行一次0 3 * * * /usr/bin/aide --check /var/log/aide/aide.log 21增量模式-C可以在每日全量检查之间快速对比小范围变化有异常就立即查。这个工具本身不防篡改但它提供的告警能力让排查时间从几个月缩短到几小时。5. 文件系统与关键目录权限松一分风险大十分5.1 挂载参数中的安全取舍文件系统层面的加固容易被忽略因为平时很少有人仔细看/etc/fstab。但攻击者一旦拿到受限权限能做的破坏很大程度上取决于文件系统挂载时给了多少自由度。不少发行版默认把某些目录挂载得过于宽松。拿 Linux 最常用的 ext4 和 XFS 来说挂载时可以指定一些安全相关的选项。比如/tmp目录很多服务都会往这里写临时文件但/tmp本身不应该是可执行程序的存放地。攻击者可以往/tmp丢一个 payload然后诱导某个高权限进程去执行这是很经典的提权路径。我建议在 fstab 里这样挂载/tmp/tmp ext4 defaults,noexec,nosuid,nodev 0 0noexec禁止执行二进制文件nosuid禁止SUID位生效nodev禁止设备文件。这三个选项叠加起来能在很大程度上削弱临时目录的攻击价值。这里有个坑有些程序的安装包需要从/tmp跑安装脚本挂上noexec之后会报权限错误。遇到这种情况要么临时mount -o remount,exec /tmp再装要么把安装包换个路径。/home或者专门的数据目录也建议加上nodev,nosuid。这几个选项不会影响正常读写只限制特殊文件类型的创建和访问性价比极高。查看当前挂载参数mount | grep /tmp如果之前没有指定可以用mount -o remount,noexec,nosuid,nodev /tmp临时改但要想永久生效必须改 fstab。5.2 关键文件与SUID的基线管理Linux 系统里 SUID 是个很有意思的机制。它允许普通用户以文件属主的身份执行某个程序典型例子是/usr/bin/passwd。这个机制本身不是坏事但攻击者可以用它来做文章。一个自定义的 SUID 二进制文件可以让普通用户直接获得 root 的权限执行某个操作甚至直接派生一个 root Shell。所以每隔一段时间我会扫描一遍全盘的 SUID 文件find / -perm -4000 -type f 2/dev/null正常情况下输出的文件应该是一个可预期的清单比如/bin/mount、/usr/bin/su、/usr/bin/passwd这些。如果清单里出现了奇怪的文件路径或者新增了不明来历的 SUID 文件就要高度警惕了。删除 SUID 位用chmod u-s /path/to/file另一个需要关注的是关键文件的可写权限。我建议检查一下系统里有哪些重要目录被赋予了other用户的写权限find / -xdev -type d -perm -0002 -print正常系统里输出应该很少最多是/tmp和/var/tmp这类明确需要共享写入的目录。如果发现/etc、/usr、/var下的目录有全局写权限那基本属于配置事故攻击者可以往这些目录里植入恶意脚本静默等待触发。/etc/shadow的权限也值得单独检查正常应该是 000 或 600。有些老系统为了兼容某些工具把 shadow 设成 644等于把密码哈希撒得满地都是。密码哈希一旦被拿走去跑字典攻击就是时间问题了。5.3 锁定关键的“隐藏”开关最后一个容易被忽视的是cron目录和启动脚本。攻击者特别喜欢把反弹 Shell 脚本挂在/etc/cron.d/或者写入/etc/crontab因为这种方式即使系统重启也能保持持久化。我建议定期检查这几个位置ls -la /etc/cron.d/ cat /etc/crontab同时留意/etc/systemd/system/下有没有新增的.service文件尤其是名字故意伪装成系统服务的那种。检测方法就是不定期对比目录内容的快照或者用前面提到的 AIDE 对这些路径做重点监控。补充一个实用习惯所有新部署的服务都应该用独立的低权限账户运行不要用 root 直接跑。比如 Nginx、MySQL、Redis它们在各自的发行版包里都有对应的专用账户检查一下确认没有被改成 root 就行。6. 审计与监控加固不是一锤子买卖6.1 auditd让每个敏感操作都留下记录安全加固做到这里攻击面已经被大幅收缩。但没有任何一套配置是永久有效的攻击者在想尽办法绕过规则。这时候最需要的是审计能力——系统里有没有发生不该发生的动作如果有能不能回溯到具体的人和命令。Linux 自带的 auditd 是目前最可靠的内核级审计方案。它基于内核的审计框架能记录文件访问、系统调用、登录事件、账户变更等关键操作。安装和启动非常简单yum install audit systemctl enable auditd systemctl start auditd重点在规则配置。以监控/etc/passwd、/etc/shadow、/etc/sshd_config这几个核心文件为例auditctl -w /etc/passwd -p wa -k passwd_watch auditctl -w /etc/shadow -p wa -k shadow_watch auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_watch-w指定被监控文件-p wa表示记录写入和修改属性操作-k是为规则打的标签方便后期筛选日志。这些规则只是临时生效要把它们持久化应该写进/etc/audit/rules.d/audit.rules或者使用auditctl -R导入。查看审计日志有三种方式ausearch按条件查询aureport生成统计报告/var/log/audit/audit.log直接翻原始日志。排查时我常用ausearch -k passwd_watch -ts today这条命令列出今天所有针对 passwd 文件的写操作包括发起进程、用户ID、命令路径定位问题非常高效。审计规则别上来就一把梭全监控那是给自己制造噪音。我建议分阶段先覆盖登录和关键账户文件跑一段时间观察量级再逐步扩大到二进制目录和配置目录。6.2 登录安全从 PAM 配置到账户锁定策略PAMPluggable Authentication Modules是 Linux 系统认证框架的核心几乎所有的认证入口——SSH、su、sudo、图形登录——最终都会经过它。PAM 配置里有两个常用的安全模块值得加强pam_tally2和pam_faillock。它们的作用是账户锁定连续多次认证失败后暂时锁定账户防止暴力破解。Ubuntu 上我用pam_faillock比较多配置在/etc/pam.d/common-auth和/etc/pam.d/common-account里auth required pam_faillock.so preauth silent audit deny4 unlock_time900 auth required pam_faillock.so authfail audit deny4 unlock_time900 account required pam_faillock.so含义是连续失败4次锁定15分钟。不建议把阈值降得太低比如 2 次否则管理员自己输错几次密码就被锁了运维事故比安全风险更让人头疼。CentOS/RHEL 上的配置路径稍有不同用的是/etc/pam.d/password-auth和/etc/pam.d/system-auth模块名是pam_faillock也更常见。改 PAM 配置前一定要备份原始文件并且用pam-auth-update检查语法一致性配置错误可能导致所有人都无法登录。还有一个秘密被很多人忽略/etc/securetty。这个文件控制 root 允许从哪些终端登录如果里面有不该出现的伪终端名称等于给 root 登录开了小门。建议只保留基本的控制台条目其余删掉。6.3 日志侵入检测的简单套路日志排查是所有安全监控的基础。但日志文件本身也可能被篡改所以有一件事必须在加固阶段就做好让日志及时转走。最简单的方式是配置 rsyslog 把关键日志转发到集中的日志服务器或者至少同步到独立的存储位置。在/etc/rsyslog.conf里加一行*.* 192.168.10.10:514让所有日志实时外送到日志收集节点。即使攻击者清了本机日志集中平台上的记录依然存在。这是事后溯源的救命稻草强烈建议在生产环境落地。日常巡检我一般看这几类日志日志路径关注内容/var/log/secure 或 auth.log登录成功/失败、sudo 使用记录/var/log/croncron 任务执行是否有异常新条目/var/log/messages 或 syslog网络、内核、系统级报错/var/log/audit/audit.log审计事件特别是有失败和拒绝的事件圈出重点之后我习惯用一条命令快速过滤暴力破解尝试grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20列出尝试次数最多的来源IP。这个数据不仅用于应急也用来做防火墙的黑名单配置或者买云厂商的安全组策略参考。7. 工具推荐加固之后还要能持续看见风险配置做完了但如果只是手动检查一遍过了两个月又回到原样。我习惯在每台机器上部署一套轻量级安全监控工具把“事后发现”变成“实时预警”。第一梯队的工具是 RKHunter 和 Chkrootkit专门用来检测rootkit和后门。RKHunter 扫描已知恶意程序的特征码对比系统二进制文件的哈希值检查网络端口异常绑定。我把它配置成每天执行一次并输出报告rkhunter --check --sk第一次运行时会因为系统文件属主权限和其他因素产生告警需要根据实际情况生成白名单。这一步挺重要否则每天收到一堆误报最后连告警都不看了。第二梯队是 Osquery。它是 Facebook 开源的系统插桩工具把操作系统抽象成一张可以 SQL 查询的表。比如我想查所有监听的端口SELECT * FROM listening_ports;或者查所有 UID 为 0 的用户SELECT * FROM users WHERE uid 0;Osquery 的价值在于可以集中管理同时它可以把采集结果发送到集中平台做规则检测。对有一定基础设施规模、又不想上重型的商业化安全工作台的情况这个方案是性价比很高的中间选择。另外还有一个方向是配置基线检查工具像 OpenSCAP、Lynis。Lynis 是傻瓜式的好东西一条命令输出系统安全状况报告lynis audit system它会检查系统更新状态、文件权限、用户配置、网络设置、软件漏洞等数百个项目然后给出一个 hardening index 和一个建议清单。虽然没有实现自动化修复但作为持续巡检的补充维度很有用。把这些工具全部配上之后加固体系才算完整登录入口有强认证网络层有最小开放文件系统有权限约束文件变化有完整性校验操作行为有审计日志风险状态有定期扫描。这条链路闭合了才能真正降低运营一台Linux系统的安全焦虑。8. 我自己踩过的三个“加固陷阱”技术清单讲完了我想单独说说实际运维里最容易翻车的三个点因为每一步我都吃过亏。第一个坑是改 SSH 配置时没有留兜底通道。有一年我在一台离线的物理机上调整 sshd_config把PasswordAuthentication设成 no然后执行了 reload随后发现自己当前的连接因为配置改变被踢了密钥认证又因为 localhost 主机的密钥权限问题失败。结果是我人就在机房但机器的SSH理论上已经把我放逐了最后只能通过带外管理口登录修复。现在我的习惯是改任何 SSH 配置之前先screen开一个会话然后在里面sudo su到另一个用户或者干脆同时在机器上开两个连接测试。对待改动大型服务配置永远默认会有问题都需要先给自己留一条后路。第二个坑是防火墙规则顺序写反。当时在给一台生产数据库服务器做加固我要求默认策略 drop但我在规则里先写了一堆 drop最后才写 accept 放行导致业务连接被自己防火墙拦截。排查了半天发现是对外端口没有放行而连接本地时因为回环接口放行了所以本地测试一切正常只有外部访问异常。这个教训让我养成了“写完防火墙规则第一件事用另一台机器验证外部访问”的习惯。第三个坑和 AIDE 有关。我很早就部署了 AIDE但数据库存在了本机结果在一次真实的入侵事件里攻击者不仅伪造了几个二进制还顺手更新了 AIDE 数据库。等我们发现文件不对劲时重新比对已经无从谈起。从那以后我把 AIDE 数据库定期同步到独立的备份存储且每次检查之后马上把新基线外传避免“既当运动员又当裁判”的局面。这三件事的共性其实都是同一个安全加固不是配置下发了就万事大吉它需要持续的维护、冗余的安全通道和对策失败时的预案。这也是我写系统安全加固系列的一个初衷——不是给一份抄完就忘的配置单而是希望每个接过服务器运维的人都建立起一套自己的安全检查节奏和危机应对意识。这一篇是 Linux 环境的做法之后的系列里我会继续顺着应用层、容器层和云上架构的加固思路往下走。