简介《LINUX安全加固手册》是一份面向Linux系统运维人员、安全工程师和初学者的实操型参考文档核心聚焦用户账户安全与网络服务安全两大模块。内容从系统安装阶段的安全设置切入系统梳理密码安全策略、密码强度检测、密码影子文件Password Shadowing与密码管理再深入解释服务过滤、/etc/inetd.conf、R服务、Tcp_wrapper、/etc/hosts.equiv等关键配置文件形成从入口部署到日常维护的加固主线。资源为单个PDF文件大小仅40KB轻量易保存方便随时查询。目前已有1330人学习下载。手册后半部分还覆盖NFS文件共享、tftp简单文件传输、Sendmail邮件服务、finger查询、UUCP等常见服务的风险点读者既可按照目录逐项对照检查也能直接参考其中关于密码策略与服务访问控制的具体做法快速落地为一套可执行的安全基线对不熟悉Linux安全配置的新手这份检查顺序也能帮助减少遗漏适合作为团队内部培训或上线前自查的参考材料。1. 加固不是装完系统就算完一台服务器真正能上线前还差什么一份 Linux 安全加固手册看起来厚拆开其实就六层账号口令、文件权限、服务暴露面、内核参数、审计留痕、基线核验。我见过太多团队装好系统、配完 IP 就丢上线结果撑不过三天就被扫出弱口令root 被人直接登进去。真正的问题不是内核漏洞而是配置层面没人管。本文围绕 Linux 安全加固这条主线按我自己交付服务器时习惯的顺序把每一步的命令、参数和翻车点一次讲透。适合刚接手服务器的运维也适合做基线核查交付的工程师照着做能少踩一半的坑。2. 账号与口令先管住人和密码再谈纵深防御2.1 第一步不是装软件而是清空无效账号拿到一台机器我不会先装 fail2ban 或杀毒而是先看这台机器上有多少账号。绝大多数入侵都是从一个不该存在的账号开始的尤其是 UID 为 0 的伪 root、无密码账号、离职员工的遗留账号。先看 UID 0 的账号正常情况应该只有 root 一个# 列出所有 UID 为 0 的账号 awk -F: ($3 0) {print $1} /etc/passwd逻辑说明/etc/passwd每行按冒号分成七个字段第三个字段是 UID。UID 为 0 意味着这个账号拥有与 root 相同的权限哪怕它叫别的名字。这个命令应该只在输出里看到 root多出来的任何一个名字都要盯死。再看哪些账号没有密码或者密码字段是异常状态# 找出没有口令的账号$2 为空或为 ! 都算异常 awk -F: ($2 || $2 !) {print $1} /etc/shadow逻辑说明/etc/shadow只有 root 能读第二个字段是口令散列。如果为空说明这个账号不需要密码就能登录如果是!或*通常表示锁定但也可能是创建后从没初始化过密码。把输出逐个人工核对确认是服务账号还是人为创建的孤儿账号。处理办法分两种确定没用的直接删暂时不敢删的先锁# 锁定账号保留 home 目录和 uid usermod -L 用户名 # 删除账号并清理 home 与邮件池 userdel -r 用户名参数说明usermod -L是在 shadow 密码字段前面加一个!比直接删安全适合“这个人可能还要回来”的场景。userdel -r会一并删掉家目录和/var/spool/mail下的文件执行前务必确认没有该用户遗留的重要数据。顺带处理 sudoers。很多团队把 sudo 权限给了所有人或者把普通用户加进wheel组之后再也不审计。我一般先备份再编辑cp /etc/sudoers /etc/sudoers.bak.$(date %F) visudo参数说明visudo会做语法校验写错了不会让你保存这比直接vim /etc/sudoers靠谱得多。备份文件名里带日期出问题能快速回滚。sudoers 里要重点看两处%wheel ALL(ALL) ALL是否给了过大的组权限以及有没有单独给某个用户NOPASSWD的裸授权。2.2 密码策略与密码过期提醒改 login.defs 要配 chage 才完整口令策略是所有加固里投入产出比最高的一项。我见过不少服务器 root 密码是123456还开了 SSH 密码登录这种机器在公网活不过一天。改密码策略的核心在三个文件/etc/login.defs、/etc/pam.d/system-auth或password-auth、以及存量用户要用chage单独刷。先看/etc/login.defs里的几个关键项# /etc/login.defs 中需要确认的四项 PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 14参数说明PASS_MAX_DAYS是密码最长使用天数90 天是比较常规的节奏PASS_MIN_DAYS是两次修改的最小间隔设 7 天防止用户把密码立即改回原密码PASS_WARN_AGE是过期前多少天开始提醒这就是很多人搜的“linux密码过期提醒通知”的配置来源。需要特别注意login.defs只对之后的密码修改生效存量用户的过期时间不会自动变。所以改完login.defs之后必须对现有用户批量刷新# 对 UID 1000 的普通用户统一设置密码策略 for u in $(awk -F: ($3 1000) {print $1} /etc/passwd); do chage -M 90 -m 7 -W 14 $u done # 单独查看某个用户的当前策略 chage -l 用户名逻辑说明awk -F: ($3 1000)表示只挑 UID 不低于 1000 的普通用户避免把系统账号也圈进去。chage -M 90对应最大天数-m 7对应最小天数-W 14对应提前提醒天数。chage -l是事后检查用的能看到该用户密码过期时间、最小修改间隔、账号过期时间排查问题时比直接读 shadow 更直观。有些团队还会加一道 pam 强度校验在 RHEL/CentOS 系上改/etc/pam.d/system-auth# 密码强度校验长度 12 且包含大写、小写、数字、特殊字符 password requisite pam_pwquality.so try_first_pass retry3 minlen12 dcredit-1 ucredit-1 lcredit-1 ocredit-1参数说明minlen12是总长度下限dcredit-1、ucredit-1、lcredit-1、ocredit-1分别要求至少包含一个数字、大写字母、小写字母、特殊字符。负号表示“至少多少个”正数才是“最多扣多少分”。retry3允许用户重试三次不要设成 1否则误伤率太高。2.3 登录失败锁定pam_faillock 的配置顺序别放错暴力破解是公网服务器的日常SSH 日志里每天都有来自各种 IP 的Failed password刷屏。与其只靠 fail2ban 事后封禁更稳妥的是在 PAM 层做登录失败计数。RHEL 8 之前的系统常用pam_tally2之后版本建议用pam_faillock替代。在/etc/pam.d/system-auth的 auth 段和 account 段分别插入# auth 段开头 auth required pam_faillock.so preauth audit silent deny5 unlock_time900 # auth 段中间放在 pam_unix.so 之后 auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time900 # account 段 account required pam_faillock.so参数说明deny5表示连续失败 5 次锁定unlock_time900表示锁 15 分钟。silent参数让锁定前的提示不泄露过多账号信息。配置顺序非常关键——preauth必须在最前面authfail必须在pam_unix.so后面否则可能出现认证成功也被计数的怪现象。我见过有人把顺序放错导致管理员自己输错一次密码就被锁最后只能单用户模式进去改配置。手动解锁用这个命令不需要重启任何服务faillock --user 用户名 --reset这条命令在排查“用户被锁了又不知道原因”的场景里是刚需。加完策略后一定要自己试一次连续错 5 次确认行为符合预期再离开终端。3. 文件系统与权限把提权路径一条条焊死3.1 SUID/SGID 排查先看清你的系统里哪些文件带着 root 权限Linux 提权攻击里最常见的一类就是利用系统里残留的 SUID 文件。SUID 的意思是一个二进制文件运行时进程的有效 UID 会变成文件属主的 UID。如果一个属主为 root 的普通命令带着 SUID 位任何用户执行它都等于临时获得了 root 权限——这就是“linux提权”这条热词背后最常见的利用链。先把自己系统里的 SUID/SGID 文件翻出来# 找出所有带 SUID4000的文件不跨文件系统 find / -xdev -type f -perm -4000 -ls 2/dev/null # 找出所有带 SGID2000的文件 find / -xdev -type f -perm -2000 -ls 2/dev/null参数说明-xdev表示只在当前文件系统内搜索不进入/proc、/sys、挂载的移动硬盘等否则会产生大量噪音和权限报错。-perm -4000的写法是“只要包含 SUID 位就命中”而不是“必须恰好是 4000”这样能覆盖4755、4750等常见变体。2/dev/null把无权限访问目录的报错丢掉不然输出会淹没有效结果。拿到清单后逐一核对是否属于系统包# RHEL/CentOS 系 rpm -qf /usr/bin/passwd # Debian/Ubuntu 系 dpkg -S /usr/bin/passwd逻辑说明这两条命令用来回答“这个文件是系统自带的还是后放的”。passwd、sudo、su本身就必须带 SUID保留没问题真正危险的是/usr/bin/vim、/usr/bin/find、/usr/bin/tar这类工具被人为加了 SUID。确认是非法残留的直接去位chmod u-s /tmp/可疑文件如果你的系统里/usr/bin/find带着 SUID任何用户都能通过find . -exec /bin/sh;直接拿到 shell这种文件留着就是给攻击者送 root。除了清理还要定期把命令结果落盘对比我习惯每周跑一次并把输出存到/var/log/suid_audit.log方便追溯变更。3.2 挂载选项/tmp、/dev/shm、/var/tmp 三个入口要封住/tmp是另一个经典战场。攻击者的写入脚本、下载的恶意载荷、提权工具的临时落地路径绝大多数都在/tmp和/dev/shm。对这两个目录追加noexec、nosuid、nodev挂载选项能直接废掉一堆落盘执行的攻击脚本。先看当前挂载情况findmnt /tmp findmnt /dev/shm如果/tmp不是独立分区而是在/根分区上那没法单独改挂载选项只能靠后续的目录权限和/etc/systemd/system层面的 tmpfs 规则来补。独立分区的情况下编辑/etc/fstab给对应行加选项# /etc/fstab 中 /tmp 和 /dev/shm 的推荐配置 /dev/mapper/vg-tmp /tmp xfs defaults,noexec,nosuid,nodev 0 0 tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0参数说明noexec禁止在该文件系统上直接执行任何二进制文件nosuid忽略 SUID/SGID 位nodev不识别设备文件。这三个是一套组合拳单独只加noexec会被perl -e ...或python -c ...这类解释器绕过但配合nosuid能堵住大部分落盘提权路径。/dev/shm改完要立即生效就重新挂载mount -o remount,noexec,nosuid,nodev /dev/shm注意/dev/shm是 tmpfs改 fstab 后重启也会保持/tmp如果是 LVM 分区remount 命令类似但要注意当前是否有进程把可执行文件留在/tmp上——比如 Java 的java.io.tmpdir默认就指向/tmp你把它noexec了JVM 启动可能直接报Failed to create temporary file。改之前用lsof D /tmp看一眼有哪些进程在用别在业务高峰期动手。/var/tmp经常被人忽略它和/tmp一样可写但很多系统的清理机制不会扫它。如果它是独立分区同样加上这三个选项如果不是那就确保它的权限不是 777chmod 1777 /var/tmp权限 1777 里的1是粘滞位意味着只有文件属主能删除自己的文件防止我叫“你删我文件”的跨用户攻击。3.3 不可变属性与 umask关键文件要锁但别锁到没退路对极其敏感的系统文件可以用chattr i设置不可变属性。设置了之后即使是 root 也不能修改、删除、重命名该文件。这个操作我一般只用在/etc/passwd、/etc/shadow、/etc/ssh/sshd_config这几个文件上而不是整个目录。# 查看当前不可变属性 lsattr /etc/shadow # 设置不可变防止被篡改 chattr i /etc/shadow参数说明i是 immutable 的缩写设置后lsattr会显示----i-----------。注意这招对 root 同样生效所以你的“后悔药”就是自己改配置前先解除属性# 升级或改密码前解除 chattr -i /etc/shadow # 完成后再加回去 chattr i /etc/shadow有很多人把/etc/passwd、/etc/shadow都加了i结果某次 yum update 时 rpm 事务脚本要替换这两个文件直接报错中断最后整个包管理器处于半坏状态。我的建议是只在交付前、确认不会频繁变更用户和密码的阶段加锁平时保持不加靠审计规则盯着就够了。默认的 umask 是 022意味着新建文件权限为 644、目录为 755。对多用户服务器来说这个值偏松任何人都能读你 home 目录下的配置文件而配置里往往带着数据库密码或者 API 密钥。收紧 umask 到 027# /etc/profile 末尾追加对登录 shell 生效 echo umask 027 /etc/profile # 立即对当前会话生效 umask 027参数说明027表示新建文件的组权限去掉写权限其他用户只有执行权。效果是新建文件 640、目录 750。对 web 服务这类需要其他用户读文件的场景027可能太紧可以折中用022保持读权限但不开放写。改完 umask 后用umask命令验证当前值并让业务方重启一下应用确认临时文件和 Session 目录的权限没有异常。4. 服务与 SSH把系统的门面收窄到一扇门4.1 SSH 加固先从“留一条退路”开始SSH 是服务器最重要的入口也是被扫描爆破最频繁的端口。加固 SSH 的第一原则不是“改端口”而是“先确保自己不会把唯一入口关掉”。我见过太多人上来就把PermitRootLogin no和PasswordAuthentication no一起打开然后发现自己的公钥没装进去人已经在机房千里之外——这种翻车一次就长记性。正确的顺序是先放公钥、验证能登录再关密码登录# 在服务器上创建 .ssh 目录并设置权限 mkdir -p ~/.ssh chmod 700 ~/.ssh # 追加公钥用 而不是 别覆盖已有内容 cat id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys参数说明.ssh目录权限必须是 700authorized_keys文件必须是 600。权限过松时 sshd 会直接忽略这个文件而且不会给出明显报错。是追加如果服务器上已经有过期的公钥覆盖写会直接把原管理员挤出系统。公钥验证能登录之后再改/etc/ssh/sshd_config# /etc/ssh/sshd_config 常用加固项 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 LoginGraceTime 30 ClientAliveInterval 300 ClientAliveCountMax 0 AllowUsers ops deploy参数说明PermitRootLogin no禁止 root 直连管理员用普通用户登录后再 su 或 sudo审计日志里能留下账号名PasswordAuthentication no关闭密码认证只允许密钥这一步对防爆破效果立竿见影MaxAuthTries 3限制单次连接最大尝试次数LoginGraceTime 30限制登录超时时间防止慢速爆破挂住连接AllowUsers是白名单只允许列出的用户从 SSH 登录比在防火墙里封 IP 更硬核。改完配置先做语法检查再 reload不要直接 restart# 语法检查 sshd -t # 语法通过后保持当前连接不动另开一个窗口验证新配置能连上 systemctl reload sshd逻辑说明sshd -t只检查配置合法性不重启服务。确认语法无误后用reload而不是restart因为 reload 只重新读配置不断开现有连接。就算新配置有问题当前连接还在你还有机会改回来。这是 SSH 加固里最重要的一个操作习惯。4.2 服务暴露面从 systemd 视角做最小化启动Linux 默认安装会拉起一堆你根本用不到的服务avahi-daemon、cups、postfix还有一些发行版自带的远程管理代理。每个监听中的服务都是一个攻击面你无法确定它们有没有隐藏漏洞。所以排查监听端口、关停无用服务是每次加固的必修课。先看当前所有正在监听的服务# 列出所有正在运行的 service 单元 systemctl list-units --typeservice --staterunning # 查看实际监听端口的进程 ss -lntup参数说明ss -lntup是现在推荐替代netstat的命令-l只看监听中的-n不做域名解析-t只看 TCP-u看 UDP-p显示对应进程。输出里每一行都是一个潜在入口对照业务需求逐个问“这个端口谁在用、能不能不监听”。确认无用的服务直接停掉并禁用有些还要 mask# 停止并禁止开机自启 systemctl disable avahi-daemon --now # mask 掉防止被其他服务依赖而拉起来 systemctl mask cups.socket参数说明disable --now是“停止当前 禁止开机自启”的组合操作。mask比disable更狠它会把这个单元链接到/dev/null任何显式或隐式的启动请求都会失败即使另一个服务在依赖列表里写了它也拉不起来。对cups.socket这类基于 socket 激活的服务直接 disable 是不够的因为打印任务一来它会被唤醒mask 才能彻底关死。4.3 端口与防火墙默认拒绝而不是默认放行公网服务器上防火墙策略的核心是“默认拒绝白名单放行”不是“默认放行黑名单封禁”。大多数发行版默认的 zone 是public策略是放行大量常见端口这个对服务器来说太宽松了。我习惯把默认 zone 直接切到drop然后精确放行需要对外提供的服务# 默认 zone 切为 drop未匹配规则的全部丢弃 firewall-cmd --permanent --set-default-zonedrop # 放行 SSH如果用密钥登录且改了端口换成自己的端口 firewall-cmd --permanent --add-servicessh # 只放行业务端口比如 80/443 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps # 重新加载使配置生效 firewall-cmd --reload参数说明--permanent表示写入持久化配置不加的话重启后丢失。dropzone 会对未放行的流量直接丢弃而不是返回拒绝包从攻击者的扫描视角看这些端口像是不存在能显著减少被进一步探测的概率。切 zone 时务必确认 SSH 服务已经在放行列表里否则防火墙 reload 的瞬间你就会被踢出服务器——这是个非常经典的翻车点。如果系统用的是iptables而非 firewalld最稳妥的收尾策略是把默认策略改为 DROP# 先把当前规则备份别在前面的规则验证完之前清空 iptables-save /root/iptables.rules.bak # 设置默认策略为 DROP iptables -P INPUT DROP iptables -P FORWARD DROP注意直接改默认策略之前一定确保自己能通过其他方式回到机器比如带外管理卡或云控制台的 VNC。我见过有人执行完iptables -P INPUT DROP才发现 22 端口的放行规则写在了后面当前连接没断但新连接全部超时那叫一个后悔药都没得吃。5. 常见问题排查加固后系统“飞了”先查这五件事5.1 密码过期策略误伤自动化任务现象某天开始cron 脚本和定时备份任务大面积失败日志里出现认证失败或“password expired”的错误部分服务间调用也开始报 401。原因批量执行chage -M 90时把服务账号也圈进去了。服务账号不需要人工登录密码过期后没有机制自动续期依赖密码认证的定时任务全部失效。这类账号的密码过期时间往往还是“从未设置”状态一旦策略落地就立刻出问题。解决服务账号单独管理不参与普通用户的密码周期。恢复操作用chage取消过期时间并检查状态# 对服务账号取消密码过期 chage -E -1 服务账号 # 检查所有账号的过期状态找出遗漏 chage -l 服务账号 | grep -E Password expires|Account expires参数说明-E -1表示取消账号过期时间-1对 chage 来说就是“无限期”。排查时用chage -l看输出里的Password expires字段一旦发现password must be changed之类的标记就该知道问题出在密码周期上。5.2 sshd 配置改坏后连不上的排查现象执行systemctl reload sshd后新连接全部被拒绝要么提示Permission denied要么直接超时当前连接还活着但不敢断断了就回不去了。原因PermitRootLogin no和PasswordAuthentication no同时启用而自己的公钥并没有真正生效可能是.ssh目录权限不对或者 authorized_keys 内容被覆盖也可能是AllowUsers名单里写错了用户名把自己漏掉了。解决先别慌检查当前会话还在然后做三件事# 1. 确认目标端口还在监听 ss -lntp | grep :22 # 2. 用 verbose 模式测试密钥认证是否正常 ssh -v -i 自己的私钥 用户名目标IP # 3. 检查 authorized_keys 的权限和内容 ls -la ~/.ssh/ cat ~/.ssh/authorized_keys公钥文件权限必须是 600目录必须是 700authorized_keys 里不能有多余换行或格式错误的 key。如果确认配置有问题就在当前已连接的会话里改回去并 reload保命要紧。以后再改 sshd_config 时养成“先sshd -t再另开连接验证最后才 reload”的习惯就不会再把自己关在门外。5.3 /tmp 加 noexec 后安装包失败的排查现象给/tmp加了noexec挂载选项后某天安装新软件时报Permission denied或者段错误尤其是安装包是二进制形式的、需要用/tmp做临时解压目录的软件。原因安装程序把临时文件写到/tmp再执行noexec直接拒绝执行任何位于该文件系统上的二进制安装当然失败。类似情况也会发生在/dev/shm上——一些 Java 应用和数据库会用它做共享内存映射。解决给这些程序单独指定可执行的临时目录而不是取消 noexec# 创建专用临时目录1777 保持粘滞位 mkdir -p /opt/tmp chmod 1777 /opt/tmp # 对安装过程单独指定 TMPDIR TMPDIR/opt/tmp ./installer.sh # 对 Java 应用在启动参数里指定 java -Djava.io.tmpdir/opt/tmp -jar app.jar参数说明TMPDIR是大多数程序都会尊重的环境变量用它覆盖默认的/tmp即可绕过 noexec。/opt/tmp的权限用 1777粘滞位保证多用户环境下不能互相删文件。如果程序是 systemd 启动的在 unit 文件里加EnvironmentTMPDIR/opt/tmp改完记得systemctl daemon-reload。5.4 chattr i 之后升级失败的排查现象在某次yum update或apt upgrade时报错提示无法删除或替换/etc/shadow、/etc/passwd包管理器直接中断重启后系统处于半更新状态。原因之前执行过chattr i /etc/shadow不可变属性对 root 一样生效。rpm 事务脚本在更新时要替换这些文件发现属性不可变就直接失败。解决升级前统一解除升级后重新加回# 查看当前哪些关键文件带 immutable 属性 lsattr /etc/passwd /etc/shadow /etc/ssh/sshd_config # 升级前批量解除 chattr -i /etc/passwd /etc/shadow /etc/ssh/sshd_config # 升级完成后重新锁定 chattr i /etc/shadow /etc/ssh/sshd_config我的习惯是/etc/passwd不加锁因为用户管理操作太频繁加了反而制造麻烦/etc/shadow和sshd_config可以加但每次系统升级前都要走一遍“先解后锁”的流程。如果不放心可以在升级脚本里把chattr -i和chattr i写成一对放在升级命令前后。5.5 锁定策略把自己锁在门外的排查现象管理员输错两三次密码后整个账号被锁死faillock --user 用户名 --status显示多个失败记录有时甚至内网跳板机的固定 IP 也被连坐。原因pam_faillock的deny阈值设得太低比如 3 次或者是自动化脚本、监控采集器用了错误的凭据反复探测把失败计数刷上去了。解决先解锁当前用户再调策略# 解锁指定用户 faillock --user 用户名 --reset # 查看当前所有失败记录 faillock --user 用户名 --status如果要彻底避免误伤可以把运维跳板机的 IP 加进pam_faillock.so的ignore列表或者把deny调高到 5 次、unlock_time保留 900 秒。记住一点任何锁定策略都必须留一个不经过 PAM 的应急入口比如带外管理卡或者本地 console否则人不在机房时只能干瞪眼。6. 内核参数与基线验证从加固到能证明加固6.1 几个必须动但别乱动的 sysctl 参数sysctl 是内核运行时参数改对了能挡住一批低水平攻击改错了可能直接让网络行为异常。我只设置以下几个经过验证的参数其余尽量不动# /etc/sysctl.d/99-hardening.conf net.ipv4.tcp_syncookies 1 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.all.accept_source_route 0 net.ipv4.icmp_echo_ignore_broadcasts 1参数说明tcp_syncookies是 SYN Flood 的基础防护半开连接队列耗尽时启用 cookie 机制rp_filter开启反向路径过滤丢弃源地址伪造的包accept_redirects0不接受 ICMP 重定向防止中间人劫持路由accept_source_route0禁用源路由选项icmp_echo_ignore_broadcasts忽略广播 ping减少被用作反射放大攻击的风险。不要碰tcp_tw_recycle它在 NAT 环境下会引发连接超时问题4.12 之后的内核已经把它移除了。生效并验证sysctl -p /etc/sysctl.d/99-hardening.conf sysctl net.ipv4.tcp_syncookies6.2 用审计规则证明加固还在生效配置改完只是开始关键是三个月后还能证明这些配置还在。auditd 是 Linux 自带的审计框架对关键文件的读写执行操作留痕# 为关键文件添加审计规则 auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config auditctl -w /etc/passwd -p wa -k userdb auditctl -w /etc/shadow -p wa -k userdb # 查看最近所有关于 sshd_config 的变更 ausearch -k sshd_config -ts recent参数说明-w指定监控文件-p wa表示记录写入和属性变更-k是给规则打标签方便后续检索。ausearch -ts recent查看最近时间段的记录能用一条命令回答“这周有没有人改过 sshd 配置”。为了配合日常巡检写一个加固基线自检脚本是一个很值得投入的收尾动作#!/bin/bash # 加固基线自检脚本输出当前状态人工对比差异 echo SUID 文件正常只有 passwd/ sudo 等系统命令 find / -xdev -type f -perm -4000 2/dev/null echo SSH 允许密码登录状态应为 no grep -E ^PasswordAuthentication /etc/ssh/sshd_config echo 空密码账号 awk -F: ($2 ) {print $1} /etc/shadow echo 监听端口 ss -lntup这个脚本不追求自动判定它的价值是把分散的检查项汇总到一次输出里拿到结果后与上一次的基线做 diff任何新增的 SUID 文件、端口或密码状态都是需要警惕的信号。我自己的习惯是每个月跑一次输出重定向到文件里再对比配合 auditd 的日志任何异常变更都有迹可循。第一次做完整加固时也翻过车把 SSH 密码登录关了才发现公钥没生效还好当时的连接没断从那以后每次改配置都先留退路再动手。这套流程走下来服务器的安全状态不只看上去稳出了问题还能追希望帮到你。本文还有配套的精品资源点击获取