2021年9月3日我把手上这套CentOS 7系统安全加固清单又更新了一轮。之所以这么认真地维护它是因为最近翻了好几台生产服务器的登录日志SSH暴力破解尝试几乎成了日常背景噪音每天都有大量来自陌生地址的试探请求。还没有做加固的CentOS 7直接丢到生产环境里跑运气成分实在太大万一被拿到权限轻则丢数据重则业务瘫痪。CentOS 7这些年在服务器市场的占有率不用我多说了生命周期长、稳定性好很多老业务一跑就是好几年。但正因为它太常见也成了攻击者最熟悉的目标。这篇文章不搞花架子把我实际用过的加固步骤完整整理出来从账号密码、SSH、防火墙、文件权限、日志审计、内核参数一直到怎么把加固变成一件持续跟进的事每一步都讲清楚为什么这么做、怎么做、做完怎么验证。不管你是刚接手Linux服务器的新人还是已经管了几十台机器的老运维这套内容都能直接拿来参考。基础薄弱的读者也不用担心我会把关键概念用比较容易理解的方式解释复杂操作会附上完整命令。1. 加固前的基本功先搞清楚要保护什么很多人拿到服务器第一反应就是改端口、换密码、关几个服务一顿操作猛如虎结果业务崩了或者安全窟窿还在。我见过最典型的例子一台服务器SSH和密码都做得挺到位但上面跑着一个旧版本的Web服务漏洞一堆照样被拖进肉鸡。为什么要反复强调“先梳理再动手”因为你连这台机器上有哪些入口都不知道加固就是在盲人摸象。1.1 资产梳理别连自己系统上跑着什么都不知道资产梳理听起来像大公司的流程其实几台服务器同样需要。花二十分钟把下面这些信息摸清楚当前监听了哪些端口ss -tlnp跑了哪些进程ps aux或ps -ef系统上开了哪些服务systemctl list-unit-files --typeservice --stateenabled哪些用户有登录权限awk -F: $31000{print $1} /etc/passwd网卡与IP规划ip addr我有一次接手一台“没人知道归谁管”的服务器一查发现对外开放了3306端口MySQL直接暴露在公网跑的还是弱口令。之所以没人发现是因为所有人都以为这台机器是别人在管。先摸清家底后面每一条加固规则你才能判断“该不该动”和“动了有什么影响”。1.2 快照与备份加固定坏了还能回得去加固过程中最容易翻车的就是改配置改到一半把自己锁在门外或者某个参数搞错了导致服务起不来。物理机或者云主机操作前一定要留退路云主机关停、打快照。几分钟的事但能救命。实体机至少备份好/etc目录。tar -czf /root/etc_backup_日期.tar.gz /etc手头机器没法快照时提前准备一个备用登录通道比如带外管理卡或者物理控制台。还有一个很土但很实用的技巧改SSH配置之前先开一个不断开的root会话然后再改。改完不要直接关掉当前会话而是新开一个终端测试登录确认没问题再关。这条建议我几乎每次帮别人排错时都会提一遍。1.3 加固基线用什么标准来衡量安全状态现在讲安全基线很多文档都会提CIS基准、等保要求这些词但对于绝大多数中小企业来说被审计约束的情况并不多。我理解的加固基线是一份“自己看得懂、照着能执行、执行完能验证”的清单内容包括密码复杂度与有效期远程登录的认证方式对外开放端口的白名单关键文件权限日志留存策略系统更新策略没有基线的话加固做到哪一步、有没有漏项全靠记忆后面一忙就全忘了。我自己的习惯是在文档里把每一项都标记为“待做 / 已做 / 已验证”三种状态验证过的打勾。安全没有所谓做完的时候但每个时间点都要能说清楚“现在做到了什么程度”。2. 账号与认证从第一道门开始堵账号和口令是系统最外层的防线也是暴力破解最集中的攻击点。这块配置改动小、见效快但对业务的干扰也最小适合作为整个加固流程的第一站。2.1 密码策略让弱密码无处遁形CentOS 7默认的密码策略其实偏宽松必须手动收紧。我通常会同时改两个地方第一个是/etc/login.defs里这几个参数PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 14第二个是/etc/security/pwquality.conf这个配合PAM的pwquality模块使用用来校验新密码的复杂度minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1minlen12是密码最短长度后面四个负一分别表示新密码中至少要包含一个数字、一个大写字母、一个小写字母和一个特殊字符。如果担心运维记不住复杂密码可以适当放宽minlen到10但四类字符的要求建议保留。密码策略不是越复杂越好太复杂了人就会把密码写在便签纸上那样更危险。改完这些之后新建用户的密码策略就自动生效了。至于存量密码可以强制用户下次登录时修改用chage -d 0 用户名也可以直接在文档里记录一个“密码轮换日”。2.2 登录失败锁定防止一条道跑到黑的暴力破解密码策略管理的是“密码本身健不健壮”而登录失败锁定处理的是“有人反复试探密码”这种情况。CentOS 7上我习惯用pam_faillockauth required pam_faillock.so preauth audit silent deny5 unlock_time300 auth sufficient pam_unix.so auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time300 account required pam_faillock.so这段配置要放到/etc/pam.d/password-auth和/etc/pam.d/system-auth两个文件里位置很讲究。特别是pam_unix.so前后的顺序放错了可能导致锁定不生效。连续输错5次账户锁定5分钟。这个配置看起来简单但在实际环境里有个坑如果公司有人写脚本批量跑登录测试锁定的账户可能包含正常用户导致业务那边找上门来。建议unlock_time先设短一点比如300秒跑一段时间确认误伤少再考虑加长。2.3 SSH加固别把钥匙挂在门口SSH是Linux服务器最常用的远程入口也是最容易被试探的服务。我每次加固SSH核心是改/etc/ssh/sshd_config里的这些项PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 AllowUsers ops user1 user2 ClientAliveInterval 300 ClientAliveCountMax 2 Protocol 2逐条解释一下PermitRootLogin no禁止root直接远程登录。日常运维用普通用户登录再通过su -或sudo切到root。这一步能防掉大量针对root账户的暴力尝试。PasswordAuthentication no关闭密码登录只允许密钥认证。很多人觉得这一步“太麻烦”但密钥的强度比任何复杂密码都高得多而且不会因为用户在不同机器上重复使用同一密码而失守。MaxAuthTries 3SSH连接尝试次数上限防止一次连接内反复试密码。AllowUsers白名单只允许指定用户通过SSH登录。配合PermitRootLogin no基本上把暴力破解的入口堵得差不多了。ClientAliveInterval 300和ClientAliveCountMax 2空闲会话10分钟后开始探测探测失败则断开。这个可以防一些挂在服务器上不动的僵尸会话同时也能让离职员工或者遗忘的会话尽早退出。改完记得先检查语法再重载sshd -t systemctl reload sshd有一点必须提醒关闭密码登录之前先确认你的公钥已经写到了authorized_keys里并且用新会话测试能登录。我见过有人把PasswordAuthentication改成no之后才发现自己的密钥没配好结果被锁在外面最后只能通过带外管理卡或物理机登录救回来。公钥文件建议权限设为600目录设为700。另外如果你不想彻底砍掉密码登录至少把PermitRootLogin设为prohibit-password也就是root只能密钥登录。这是一种折中方案适合那些业务上实在需要root直连的老系统。2.4 sudo权限给每个操作一个留痕的机会账号层面还有一个经常被忽略的点sudo授权。默认情况下wheel组的用户拥有全部sudo权限这没问题但如果团队里每个人都有完完全全的root操作权限出了问题很难定位是谁干的。建议做两件事尽量让成员使用自己的账号而不是共享一个root密码或者共用同一把密钥。在/etc/sudoers里按角色拆分授权比如运维组拥有全部权限但只读查看类操作可以分给更多同事。visudo编辑时注意保留%wheel ALL(ALL) ALL这种基础行别为了“安全”把系统默认配置删太狠否则后续管理会给自己添堵。3. 网络层防线防火墙和端口最小化账号层的门看住了下一步就是网络层的“门禁”。很多服务器默认开着大量端口业务用到的可能只有一两个剩下的全是在给攻击者留通道。最小化开放端口这件事值得花时间慢慢捋清楚。3.1 firewalld的正确用法先拒绝一切再放行需要的CentOS 7默认防火墙是firewalld很多教程会教你怎么放行端口但很少强调默认策略应该是“拒绝一切”。如果你的默认区域还是public且带了一堆服务建议先做一次收紧firewall-cmd --get-default-zone firewall-cmd --zonepublic --list-all我自己的做法是先把默认区域调整为一个“只允许必要入口”的专用区域firewall-cmd --set-default-zonedrop firewall-cmd --zonedrop --list-alldrop区域的特点是所有入站请求都被丢弃除非显式放行。放到实际环境里就是先断掉所有外部到服务器的连接然后一根根把“业务必须的管子”接回去firewall-cmd --permanent --zonedrop --add-servicehttp firewall-cmd --permanent --zonedrop --add-servicehttps firewall-cmd --permanent --zonedrop --add-port8443/tcp firewall-cmd --reload注意drop区域丢弃连接时客户端感受到的是“超时”而不是“拒绝”这样反而能让扫描器更难判断端口是否存在对很多自动化扫描工具来说是很好的干扰。3.2 检查监听端口与最小化暴露面防火墙配置得再好如果服务本身监听在0.0.0.0上依然可能被内网其他机器访问。加固时要做一次全面排查ss -tlnp看到类似:3306、:6379、:5432这样的端口监听在公网网卡上就要警惕了。数据库、缓存服务这类东西最好只监听内网IPMySQL改/etc/my.cnf里的bind-address127.0.0.1如果确实要给应用服务器访问改成内网IP。Redis默认无密码且监听所有网卡非常危险。改bind和protected-mode yes。MongoDB、Elasticsearch同理能绑内网就绑内网能加认证就加认证。开放端口的检查建议做成常规动作每次业务上线都确认一遍“这个端口还需要吗”。有些端口当时是排障临时放开的事后忘了关这是最常见的隐患之一。3.3 fail2ban给你的SSH加上自动封禁机制有了密码策略、密钥认证和防火墙白名单SSH暴力破解已经能挡住大部分。但既然攻击者还在不厌其烦地试探我还喜欢加一道自动封禁的保险——fail2ban。它做的事情很简单监控日志发现异常尝试就自动在防火墙层面封掉来源IP一段时间。安装方式yum install -y epel-release yum install -y fail2ban配置文件写在/etc/fail2ban/jail.local里[DEFAULT] ignoreip 127.0.0.1/8 你自己的管理网段 bantime 3600 findtime 600 maxretry 5 [sshd] enabled true port ssh logpath %(sshd_backend)s然后启动并查看状态systemctl enable fail2ban systemctl start fail2ban fail2ban-client status sshdignoreip必须包含你自己日常登录的出口IP否则容易把管理员自己也关在外面。之前有位同事在家办公家里IP是动态的某天早上连续输错几次密码fail2ban把家里IP封了一整天都登不上服务器后来还是通过跳板机绕进去解封的。办公网络有固定的管理跳板机的话建议把全部运维操作都收敛到跳板机ignoreip只放行跳板机地址。fail2ban配置成功后我一般会故意输错几次密码测试确认封禁和自动解封都正常。4. 文件系统与权限把系统的地基夯牢账号和网络都加固完了但攻击者如果已经通过漏洞进来接下来在系统里能做什么很大程度取决于文件权限和关键目录的防护。这一步做得好即使被入侵对方也很难提权、很难持久化、很难拿到更多的敏感信息。4.1 关键文件权限收紧Linux下所有东西都是文件权限设置直接决定谁能看、谁能改、谁能执行。下面这几类文件是必须逐一检查的文件或目录建议权限说明/etc/passwd644所有用户可读但只有root能改/etc/shadow600或000密码哈希所在禁止普通用户读取/etc/gshadow600或000组密码哈希/etc/ssh/sshd_config600SSH配置防止被篡改/etc/sudoers440sudo授权文件/root 目录700防止其他人查看管理员目录内容检查完权限后还要检查一个容易被忽略的问题账户异常。用下面这两条命令快速筛查awk -F: $30{print $1} /etc/passwd awk -F: ($2){print $1} /etc/shadow第一条找出UID为0的用户正常情况下只有root第二条找出没有密码的账户。我在给一台老服务器做体检时发现系统里有一个后门创建的UID为0的账号隐藏在所有正常账户里不仔细看根本发现不了。这类检查建议每个月至少手动跑一次。4.2 挂载选项与特殊权限位别让/tmp成为攻击者的乐园攻击者进入系统后最喜欢往/tmp、/var/tmp、/dev/shm这些目录写东西因为通常都是可写的。除了清理这些目录里的可疑文件更好的办法是让这些分区“不能执行新文件”tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0在/etc/fstab里给/tmp和/dev/shm加上noexec,nosuid,nodev选项意味着这些目录下面不能直接运行二进制程序、不能创建特殊权限文件、不能创建设备文件。攻击者就算能往这里丢东西也没法直接执行等于废掉了一只手。这里有个细节/tmp如果本身是独立的磁盘分区直接改/etc/fstab对应行即可。如果它是根分区下的目录则不能随便加noexec因为有些程序确实依赖/tmp目录下文件的执行权限。加之前先用mount -o remount,noexec /tmp临时试一次确认影响可接受再写进配置。改完fstab最好执行一次mount -a验证语法避免重启时因为配置错误起不来。SUID/SGID权限也是重灾区。SUID程序可以以文件属主的身份执行如果一个普通用户可写的程序被设置了SUID且属主是root那就等于白送一个提权通道。排查方法find / -perm -4000 -type f 2/dev/null find / -perm -2000 -type f 2/dev/null正常情况下系统自身的SUID文件就那么些/usr/bin/passwd、/usr/bin/sudo等。一旦看到不该出现的文件比如某个普通目录下出现了SUID的shell基本可以判断系统已经被入侵过。发现可疑SUID文件时不要急着删先保留现场、记录时间戳和哈希再分析来源。4.3 文件完整性校验让篡改无处可藏加固做得再好也无法百分百防住所有攻击。关键在于文件被改了你能不能及时发现。AIDE就是一个典型的文件完整性检测工具它先给系统文件“拍一张指纹照”之后定期比对发现任何变化就告警。安装与初始化yum install -y aide aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz然后写个定时任务每天凌晨比对一次0 3 * * * /usr/sbin/aide --check /var/log/aide_check.log 21AIDE的初始化过程相当耗时间文件多的服务器可能要跑一两个小时建议放业务低峰期做。另外aide.db.gz本身要妥善保管最好定期拷贝到离线位置否则攻击者一旦连这个数据库一起改了完整性校验就失去意义。文件完整性检测没法帮你阻止攻击但它能大幅缩短“已经被入侵但没人知道”的时间窗口。很多攻击者进来之后会改执行文件、改配置、留后门这些改动都逃不过AIDE的眼睛。5. 日志与审计出了问题要知道发生了什么系统被入侵并不可怕可怕的是事后查不到入侵过程。日志审计这一块很多管理员觉得“反正没人看”但在真正的安全事件处理中日志往往是最重要的证据。提前配好日志策略等于给未来的自己留了一盏灯。5.1 rsyslog把日志集中到一个安全的地方CentOS 7默认的/var/log/messages、/var/log/secure都在本机。本机日志最大的问题是攻击者拿到root权限后第一件事往往是清日志。要解决这个问题最有效的手段是把日志实时转发到一台独立的日志服务器在/etc/rsyslog.conf里取消注释或添加*.* 192.168.10.50:514其中表示UDP传输表示TCP传输。日志服务器需要开启相应的监听端口。用TCP的话传输更可靠不会因为网络抖动丢日志适合已经明确要上日志集中管理的环境。日志集中之后建议给日志服务器设置独立的访问权限不要和业务服务器共用同一个账号体系。哪怕业务服务器被攻破日志服务器是干净的你还能靠它还原入侵路径。很多企业的合规审计也要求日志保存一定期限我一般会在日志服务器上保留90天以上的原始日志。5.2 auditd监控那些不该被动的文件rsyslog侧重大量系统日志的存储和转发而auditd更像是一个精准的“摄像头”专门盯着关键文件和关键操作。安装和基本使用systemctl enable auditd systemctl start auditd添加监控规则比如auditctl -w /etc/passwd -p wa -k identity auditctl -w /etc/shadow -p wa -k identity auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config auditctl -w /etc/sudoers -p wa -k sudoers这里的-w指定文件-p wa表示监控写操作和属性修改-k是给规则打标签方便后续查询。规则添加后用auditctl -l确认生效再通过ausearch -k identity查询相关记录。添加审计规则要特别注意别“一上来就全面监控”。如果加上-a exit,always -S openat这种对所有文件的打开操作进行审计的规则日志量会瞬间暴涨磁盘都能被打满。先从关键文件和敏感操作开始跑一段时间根据磁盘和告警情况再调整。5.3 日志轮转与保存策略日志增长的势头很猛不处理的话几个月就能把磁盘撑爆。CentOS 7上默认有logrotate但默认配置往往不够需要调整。以/var/log/messages为例可以放在/etc/logrotate.d/syslog里统一管理/var/log/messages /var/log/secure /var/log/maillog { daily rotate 30 compress delaycompress missingok notifempty }意思是每天轮转一次保留30天的日志轮转后压缩。30天只是一个基准审计要求严格的场景可以调到90天甚至更长但要提前估好磁盘占用量。还有systemd自带的journal日志默认在/var/log/journal/里也可能慢慢变大。可以设置一下journalctl --vacuum-size200M或者在/etc/systemd/journald.conf里设置SystemMaxUse200M避免journal吃满磁盘。一个实操中的小细节开启日志转发之后一定要在日志服务器上确认真的收到数据而不是配置完就不管了。我见过好几回转发配置写错了本地日志和远程日志都没记录等到排查问题的时候才发现啥也没有。6. 内核与服务加固让系统本身更抗打外围防线都设好了最后再回到系统自身的“体质”上。内核参数、SELinux、开机自启服务这些项决定了系统在最坏情况下能扛到什么程度。6.1 SELinux劝你别再一上来关掉它CentOS 7默认SELinux是enforcing强制状态但太多人为了省事装完系统第一件事就是setenforce 0然后写进配置彻底关闭。对于安全加固来说SELinux是一道非常有效的纵深防线它能限制进程的权限边界即便某个服务被攻破攻击者也没法随意访问整个文件系统。如果业务确实不兼容至少不要直接关闭而是先切到permissive宽容模式setenforce 1 getenforce在permissive模式下系统不会真的拦截操作但会把违反策略的行为记录到AVC日志里。过几天翻一下日志看看有哪些操作被记录、来自哪些进程再针对性调整ausearch -m avc -ts recent我自己的经验是很多服务在SELinux下跑不起来往往不是SELinux的错而是对应策略没写对。比如Nginx要访问某个非标准目录只需要chcon或者配置正确的文件上下文即可根本不用整个关闭SELinux。维护SELinux策略需要一点学习成本但换成攻击者视角面对开启SELinux的系统他们能利用的空间会窄很多。6.2 内核参数把网络栈和资源消耗的坑填平/etc/sysctl.conf是内核参数的常驻配置文件。我通常会按下面这份清单逐项核对net.ipv4.ip_forward 0 net.ipv4.conf.all.send_redirects 0 net.ipv4.conf.default.send_redirects 0 net.ipv4.tcp_syncookies 1 net.ipv4.icmp_echo_ignore_broadcasts 1 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 kernel.randomize_va_space 2 fs.suid_dumpable 0 kernel.core_uses_pid 1这些参数的作用可以这么理解tcp_syncookies1抗SYN Flood攻击半连接队列被塞满时启用SYN Cookie机制。accept_redirects0不接受ICMP重定向报文防止路由表被恶意篡改。rp_filter1开启反向路径过滤减少IP欺骗。randomize_va_space2开启地址空间布局随机化ASLR让内存攻击更难命中目标。suid_dumpable0禁止SUID程序产生核心转储文件防止核心转储里泄露内存敏感信息。修改之后用sysctl -p加载再用sysctl 参数名逐个确认生效。注意一部分内核参数比如kernel.randomize_va_space只有在系统启动时设置才可靠运行中改可能不生效。所以我一般把这些参数写进配置文件后挑一台机器测试重启确认没问题再推广。6.3 裁剪开机自启服务少一个服务少一个攻击面系统装得越久装的软件和服务就越多。很多服务根本用不上却默认开机启动、持续监听端口白白增大攻击面。建议跑一下systemctl list-unit-files --typeservice --stateenabled逐一过一遍把和业务无关的服务禁用掉。常见的可以禁用的有bluetooth.service服务器上不会用到蓝牙cups.service打印服务服务器上很少需要avahi-daemon.servicemDNS广播内网环境大多数不需要postfix.service如果不在这台机器上发邮件可以考虑停掉abrt*.service应用崩溃报告工具生产环境可以直接关禁用方式systemctl disable --now 服务名但这里必须泼盆冷水千万别为了“精简”而把所有看不懂的服务都禁用。每个服务的启用和禁用都要结合业务确认。我是先在停掉之前用systemctl stop临时停止服务观察几天业务是否正常确认没问题再执行disable。曾经有人没确认就禁了dbus结果系统直接起不来只能进单用户模式修复。在服务裁剪上另一个经验是重装系统时最好选择“最小化”安装不带图形界面、不带办公软件。很多流行的发行版服务器版本都提供Minimal模式装好后按需再补软件从源头上减少不必要的软件包和服务。7. 安全加固不是一次性的持续更新与应急响应标题里特意加了“持续更新”因为安全加固最怕的就是“一次性运动”。很多团队年初做了一次加固之后就再也不管了。可业务会变、人员会流动、漏洞会不断冒出来如果不持续维护年初的加固成果到了年末早就褪色了。7.1 漏洞跟踪与补丁管理CentOS 7的软件源里补丁更新是持续的安全公告也会不断发布。一个基本动作是安装安全更新yum install -y yum-plugin-security yum update --security如果不方便全量打补丁至少也要保证高危漏洞的补丁在公告发布后尽快更新。我自己会订阅发行版的安全通告邮件或者定期查看CVE库重点关注和业务相关的组件。补丁升级前建议先在测试机或者低峰期操作毕竟生产环境的稳定性和安全性一样重要。每次应急响应圈子里出现新的高危漏洞不管是Web组件还是系统组件我都会回到这份加固清单把相关版本号、影响范围、处置方法补进去。这就是“持续更新”的实际意义清单不是死的它跟着新威胁一起成长。7.2 安全巡检脚本把重复检查自动化人工巡检最大的问题是“坚持不下来”。今天记得下个月就忘了一年之后彻底放飞。解决这个问题最好的方式是把巡检项写成一个脚本交给cron跑检查项至少包括当前系统待更新安全补丁数量UID为0的账户是否有新的变化空密码账户/etc/ssh/sshd_config有没有被修改新增/消失的监听端口SUID文件清单对比最近7天的失败登录记录摘要关键用户目录下authorized_keys的变化每天定时执行一次输出结果写到日志文件有异常才触发邮件或消息通知。因为脚本如果每天发一大堆正常报告几天后就没有人会认真看了。我之前就用一个简单的脚本盯 authorized_keys 的变化某次发现离职同事的密钥还留在服务器上当时要不是脚本记录下来根本不会想起来去清理。7.3 应急响应的最小预案做了那么多加固万一还是被入侵了怎么办提前准备一个最简单的预案可以省掉很多慌乱第一步保护现场。立刻备份/var/log、/etc、当前进程列表、登录记录。有条件的话直接做一次全盘快照。第二步断网隔离。把受感染的服务器从业务网络中断开避免横向扩散。第三步分析来源。翻日志、翻bash历史、检查可疑进程和定时任务搞清楚攻击者是怎么进来的。第四步恢复与加固。重装或者清理后复盘加固清单里哪条没做到位补上之后再重新上线。应急响应里最重要的原则是“不要慌着删东西”。我见过有人发现服务器被入侵第一反应是rm -rf可疑文件结果线索全没了。先备份原始数据再做分析和处理。这份预案写在文档里平时看不出来价值用上的时候能救整个团队。写在最后一点个人体会这套CentOS 7系统安全加固清单从年初维护到现在已经迭代了好几轮。每次更新都是因为实际踩了坑、遇到了新情况或者是圈子里又爆出了值得警惕的漏洞。做安全这份工作最大的错觉就是“我上个月已经加固过了”。攻击者不会休息加固清单自然也不能停在某个固定的时间点。我自己的习惯是每季度把这份清单完整过一遍重新检查和确认账号、跑一遍文件完整性校验、核对防火墙端口、清理离职人员的公钥和账号、把最近三个月的安全公告翻一遍。每次做完再在文档末尾记录一下这次更新了哪些内容。这个节奏不重但能让安全状态始终保持在可解释、可追溯的水平上。上面这些步骤你不需要一次全部做完完全可以挑出当前风险最高的几项先动手比如密码策略、SSH加固、防火墙默认策略然后再慢慢补齐其余部分。安全这东西做得早就是赚到。