我最早接触Linux加固，是在某公司机房帮忙处理一批“上线三天就被扫描爆破”的机器。当时团队的第一反应是装杀毒、改密码，结果一周后又被拖进了挖矿进程。那件事让我意识到，所谓企业级安全加固，不是装一两个安全软件，而是把整个系统的暴露面一层层收回去。这篇内容就是围绕“Linux企业级安全加固”这个主题，把我在实际运维中反复用到的加固项、配置方法和踩坑经历梳理出来。里面没有高深的理论堆砌，全部是能直接落到生产环境的操作，适合刚接手服务器运维的初级工程师，也适合已经管了一批机器、想系统性梳理安全策略的中级运维。你不需要看完立刻全部照做，但每一条都可以作为基线去对照检查。
1. 先讲清楚企业级加固的整体思路
1.1 为什么不能照抄“安全清单”
很多新手拿到一份Linux安全加固文档，会逐条执行，比如禁用root远程登录、改SSH端口、设置密码复杂度。这些操作本身没有错，但直接照搬有个问题：你并不清楚每一条背后的假设。企业级环境不是单台虚拟机，它有业务连续性要求、有多套环境差异、有变更审批流程，还有各种历史遗留的账号和脚本。照抄清单的结果往往是：加固完第二天，监控报警说业务连不上数据库，或者某个自动化任务突然用root跑不了。
我个人的经验是先做资产盘点，再做风险排序，最后才谈配置调整。你要知道自己有哪些机器在对外提供服务，开放了哪些端口，哪些账号还在使用，哪些服务是开机自启。没有这个基础，任何加固动作都是盲目的。企业级加固不是追求“最安全”，而是在“可用”和“安全”之间找到业务能接受的平衡点。
1.2 企业环境下的三类加固目标
企业级Linux加固通常会分成三个层面：主机基础加固、网络访问控制、持续审计溯源。只有这三块同时到位，才算真正闭环。
主机基础加固解决“系统自身漏洞被利用”的问题，包括账号口令策略、文件权限、内核参数、服务最小化，目标是让攻击者即使拿到一个普通用户权限，也无法轻易提权或横向移动。网络访问控制解决“谁能访问我的服务”的问题，包括防火墙策略、SSH访问限制、端口收敛，目标是减少暴露面。持续审计溯源解决“出了问题怎么查”的问题，包括系统日志、audit审计规则、文件完整性监控，目标是一旦发生安全事件，你有足够的信息还原攻击路径。
这三类目标对应到具体的加固动作，我会在后面逐一展开。先强调一点：这三者不是先后关系，而是并行关系。只做账号加固不做防火墙，等于把门锁换好了却不关窗户；只做防火墙不做日志审计，等于抓住了贼也说不清他是怎么进来的。
1.3 加固前必须具备的准备工作
如果这台机器已经跑着生产业务，动手加固前请务必完成三件事。第一，确认备份机制可用。我见过不止一次，加固脚本里把某个目录权限改成750，结果业务进程因为无法读取配置文件直接崩溃，备份又因为没挂载到位而恢复不了。第二，确保你有一条不依赖SSH的应急通道。很多加固项会调整SSH配置或防火墙规则，一旦配置错误，你可能会把自己锁在机器外面。企业环境通常有带外管理或控制台访问，本地机房有KVM，云环境有VNC或管理终端，这些都是你的救命通道。第三，准备一个变更窗口。别在业务高峰期间改系统参数，尤其像内核参数、PAM配置这种改动影响面广，尽量安排在业务低峰，并提前跟相关团队打招呼。
2. 账号与认证是加固的第一道大门
2.1 账号盘点：清理闲置账号与异常登录
Linux系统的账号体系往往是被忽略的重灾区。很多机器上躺着几年没动过的旧账号，有些还是建号时顺手设置的弱密码。我在某公司的安全排查中发现，一个闲置账号竟然是两年前离职同事留下的，而且密码策略是永不过期，攻击者只要爆破成功就能以合法账号身份登录。
账号盘点可以分三步走。第一步，列出所有本地账号，重点关注uid为0的账号，因为这类账号拥有root权限。用awk -F: '$3==0 {print $1}' /etc/passwd就能查出来，正常情况下应该只有root。第二步，检查哪些账号可以登录shell，也就是/etc/passwd中登录shell不是/sbin/nologin或/bin/false的账号，这些账号理论上都有交互登录能力。第三步，把所有账号的密码状态检查一遍，看哪些账号密码没有过期时间，哪些账号已经锁定了。
# 列出uid为0的所有账号 awk -F: '$3==0 {print $1}' /etc/passwd # 列出所有可登录shell的账号 grep -E "/(bash|sh|zsh)$" /etc/passwd # 检查账号密码状态 passwd -S 账号名对确认不再使用的账号，建议直接清理或锁定，而不是只改密码。锁定用passwd -l 账号名，临时停用可以用usermod -L，彻底删除用userdel -r 账号名。生产环境我会优先选择锁定而不是删除，因为删除账号可能导致某些历史文件的属主变成uid数字，反而造成权限混乱。
2.2 sudo权限收紧：最小授权落到实处
sudo权限可以说是一把双刃剑。企业环境里经常出现的情况是，为了省事，直接给所有运维人员分配了NOPASSWD: ALL的sudo权限。这种配置等于把root口令换成了多个弱口令入口，一旦某个运维账号被盗，攻击者就能直接获得全套系统权限。
我建议对sudo权限做一次系统性梳理。检查/etc/sudoers以及/etc/sudoers.d/目录下的所有规则，看看每个用户实际能执行哪些命令。原则很明确：能指定命令就不要给ALL，能指定参数就不要给通配。比如某个用户只需要重启某个服务，就写用户名 ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart 服务名，而不是让他能sudo systemctl操作所有服务。
# 检查当前用户的sudo权限 sudo -l # 打开sudoers配置 visudo # 查看sudoers.d目录下的规则 ls -l /etc/sudoers.d/这里还有一个容易被忽略的点：sudo日志。务必确保sudo的日志被记录到独立的文件里，方便审计追踪。在sudoers里设置Defaults logfile="/var/log/sudo.log"，并且指定Defaults log_input, log_output记录输入输出，关键操作就能留存完整证据。这条我在实际溯源中用过，效果比系统auth日志更直观，因为它记录了用户实际执行的命令。
2.3 PAM认证加固：口令策略与账户锁定
PAM是Linux认证框架的核心。很多加固文档会建议修改/etc/login.defs里的密码策略，比如设置PASS_MAX_DAYS 90表示90天到期。但这里有个误区，login.defs只对新建用户生效，对已有用户需要手动用chage命令调整。
# 设置现有用户密码90天过期 chage -M 90 -m 7 -W 14 用户名 # 查看用户密码过期信息 chage -l 用户名密码复杂度策略一般在/etc/security/pwquality.conf里配置。我会设置minlen = 12以及至少包含2种字符类型，并开启dict_check = 1防止使用字典词汇。另一个关键项是账户锁定策略，也就是防止暴力破解。在/etc/pam.d/system-auth里配置pam_faillock.so，可以连续登录失败5次后锁定账号15分钟。
# system-auth中典型的faillock配置 auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900 auth sufficient pam_unix.so try_first_pass nullok auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 account required pam_faillock.so需要注意的是，PAM配置改动有风险。我在某一次调整认证规则时，因为没有认真检查su的PAM配置，导致所有用户无法切换root，现场恢复只能通过重启进入单用户模式。所以任何PAM改动前，建议保留原始配置备份，并且确认当前的SSH会话保持在线，不要中途断开。
2.4 SSH安全加固：从端口到算法全面收紧
SSH是企业Linux最常见的入口，也是最容易被爆破的目标。网上关于“改SSH端口”的讨论很多，但我建议首先做的是禁用root密码登录、强制使用密钥认证，这比换端口有效得多。可以按顺序处理以下几项。
第一，修改/etc/ssh/sshd_config，设置PermitRootLogin no和PasswordAuthentication no。禁用root密码登录后，即使攻击者猜到root密码也无法直接登录；禁用密码登录后，密码爆破基本失效。这里一定要确认所有运维人员的公钥都已经配置到位，否则改完就登录不进去了。第二，设定MaxAuthTries 3限制认证尝试次数，设定ClientAliveInterval 300和ClientAliveCountMax 2清理僵死连接。第三，限制允许登录的用户或组，比如AllowGroups wheel，只有wheel组的用户能SSH登录。第四，修改监听端口可选，如果你有大量扫描干扰，把Port 22改成一个高位端口确实能降低噪音，但不要迷信“改端口就安全”，这只是安全通过隐蔽，真正的安全来自密钥和访问控制。
# 加固前的配置文件备份 cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) # 修改配置后先测试语法 sshd -t # 重启SSH服务 systemctl reload sshd另外强烈建议配置防火墙只允许指定来源IP访问SSH端口。如果办公网出口IP固定，直接限制来源IP的效果立竿见影。云环境通过安全组限制也能够达到同样效果，相当于在多个层面做了网络访问控制。
3. 系统参数与文件权限加固
3.1 内核参数加固：让攻击者难以利用系统漏洞
Linux内核参数里有很多跟网络栈和内存管理相关的sysctl项，适当收紧可以提高系统的抗攻击能力。这里我不会堆砌所有参数，只讲生产环境里实测过、效果明显且不会影响正常业务的几项。
网络层重点设置net.ipv4.conf.all.accept_redirects = 0和net.ipv4.conf.all.accept_source_route = 0，防止基于ICMP重定向的路由欺骗攻击。同时设置net.ipv4.conf.all.rp_filter = 1开启反向路径过滤，减少IP伪造。针对SYN Flood攻击，设置net.ipv4.tcp_syncookies = 1启用SYN Cookie。
# 写入内核参数配置文件 cat >> /etc/sysctl.d/99-security.conf <<'EOF' net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.rp_filter = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 4096 kernel.core_uses_pid = 1 kernel.dmesg_restrict = 1 fs.suid_dumpable = 0 EOF # 应用配置 sysctl -p /etc/sysctl.d/99-security.confkernel.dmesg_restrict = 1控制非特权用户读取内核日志，可以减少信息泄露。fs.suid_dumpable = 0禁止SUID程序触发core dump，也是常见的提权防护项。还有一点需要注意，每个参数在应用前最好先确认当前值和你的业务是否有冲突，比如某些容器环境或特殊网络环境对rp_filter的依赖程度不同，改完后用sysctl -a | grep rp_filter确认生效情况。
3.2 文件系统分区与挂载选项：利用只读和nosuid限制危害
文件系统挂载选项是安全加固里性价比很高但容易被忽略的一块。特别是/tmp、/var/tmp、/dev/shm这类可写目录，如果安全意识不够，经常成为攻击者上传恶意文件和提权的跳板。
对于需要限制的目录，建议在/etc/fstab中补充挂载选项。nosuid禁止在目录中运行setuid程序，noexec禁止直接执行该分区上的二进制文件，nodev禁止在该分区上创建设备文件。以/tmp为例，我会在fstab中配置为nosuid,nodev,noexec。这里要特别提醒一句：noexec可能会影响某些依赖/tmp执行程序的业务，比如某些安装脚本、临时编译文件、Java应用自定义tmpdir。如果遇到业务报错，可以在应用的systemd服务里设置私有/tmp目录，或者单独为某个子目录去掉noexec。
# /etc/fstab示例 # 设备 挂载点 类型 选项 转储 检查 tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev,size=256M 0 0 /dev/sdb1 /tmp ext4 defaults,noexec,nosuid,nodev,noatime 0 0修改fstab后执行mount -o remount /tmp验证，不要等到重启才发现挂载失败。除此之外，考虑单独划分/home分区并启用nosuid,nodev，防止用户目录下的恶意程序产生更多权限。云主机如果没有独立分区，这些选项的价值就有限，但你可以通过systemd-tmpfiles或定期清理脚本达到类似的目的。
3.3 SUID与SGID：清理提权隐患
SUID和SGID权限是Linux提权攻击的主要路径之一。攻击者一旦发现某个SUID程序存在漏洞，或者能往某个可写目录放入带SUID的恶意程序，就以普通用户身份获得root执行能力。所以定期扫描系统中所有SUID/SGID文件，是企业级加固的必备动作。
# 查找全盘SUID/SGID文件 find / -perm -4000 -o -perm -2000 2>/dev/null | grep -v '^/proc'发现可疑项时，不要急着删除或去掉SUID位，先确认这些文件来自哪个软件包。用rpm -Vf 文件路径或dpkg -S 文件路径反查软件包来源。系统自带的SUID文件一般都有明确用途，比如sudo、ping、mount等。如果你看到某个非标准目录下出现SUID二进制，或者文件写入时间异常，这基本上可以直接判定为入侵痕迹。
这里也分享一个经验：可以用chattr +i保护关键系统文件，防止被篡改。比如给/etc/passwd、/etc/shadow加上不可变属性。但需要注意，使用chattr +i后，任何程序包括root也无法直接修改该文件，后续做账号变更时会受限，所以只在清理完异常后临时使用或者对特定目录使用。
3.4 服务最小化：关掉不必要的东西
企业里的Linux服务器经常跑着一堆用不上的服务。你打开ss -tlnp一看，可能除了业务端口，还有打印服务、蓝牙服务、邮件服务在监听。每一个开放端口都是一张攻击面，严格来说，默认安装的很多服务都应当通过systemctl disable --now关闭。
我在加固时有个习惯动作，直接检查系统中处于监听状态的TCP/UDP端口，然后逐一确认端口对应的服务是否被业务依赖。对于确认不需要的服务，执行systemctl stop并将服务mask掉，防止手动启动。典型的做法是systemctl mask avahi-daemon、systemctl mask cups等。
# 查看当前监听端口 ss -tulnp # 停止并禁用不需要的服务 systemctl disable --now 服务名 # 彻底屏蔽服务，防止被手动启动 systemctl mask 服务名服务最小化不仅指关闭服务，还包括删除不必要的软件包。对于测试类工具、编译工具、常见渗透工具，建议从生产环境移除。如果业务确实需要编译器环境，也要通过白名单方式严格管理。这一条在合规检查和被入侵后的溯源中都经常被提及，因为它直接决定攻击者能不能顺利落地工具。
3.5 SELinux与AppArmor：访问控制别只停留在“建议开启”
每次讲Linux加固，SELinux都是一个绕不开的话题。很多运维人员对SELinux的第一反应是“太麻烦”，遇到权限问题直接setenforce 0。我承认SELinux的排错确实有一定门槛，但在企业级环境里，一个未知的0day漏洞或者配置错误，SELinux往往是最后的防线。
如果你的系统是CentOS、RHEL、Rocky这类发行版，优先使用SELinux；如果是Ubuntu、Debian，通常使用AppArmor。核心思路不是打开强制模式就完事，而是确保策略没有完全失控。我建议在加固时执行以下检查：首先确认getenforce是Enforcing状态，其次检查/var/log/audit/audit.log中有没有大量avc拒绝记录，如果有，说明有业务进程被SELinux策略拦截。
# 查看SELinux状态 getenforce # 查看最近被SELinux拒绝的日志 grep "denied" /var/log/audit/audit.log | tail -20 # 给问题域生成allow模块（针对常见场景） audit2allow -a -M local_policy semodule -i local_policy.pp这里要注意，audit2allow虽然能快速解决拒绝问题，但不要无脑把所有拒绝全部放行，否则SELinux形同虚设。正确做法是先分析被拒绝的进程和访问路径，确认属于正常业务后再针对性地放行。我在某次调试Nginx和PHP-FPM时，就是通过ausearch -m avc -ts recent定位到Nginx对PHP-FPM的socket访问被拒，然后专门生成了一条allow规则，既保留了SELinux的保护，又解决了业务问题。
4. 网络访问控制与安全监控
4.1 防火墙策略：从默认放行改为默认拒绝
很多Linux服务器的iptables策略是空的，相当于所有端口对外暴露。有些云主机即使配了安全组，系统内部防火墙也没有做任何限制。企业级加固里，防火墙策略必须从“默认放行”改成“默认拒绝”。简单来说，只放行业务需要的端口和来源IP，其他请求一律丢掉。
这里我以firewalld为例。首先确认默认策略是拒绝，然后按需添加规则。比如Web服务器只开放80和443端口，SSH端口只允许运维办公网IP访问。
# 修改默认区域策略为拒绝 firewall-cmd --permanent --set-default-zone=drop firewall-cmd --reload # 放行业务端口 firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https # 仅允许指定IP访问SSH firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" port port="22" protocol="tcp" accept' firewall-cmd --reload # 查看当前规则 firewall-cmd --list-all没有firewalld的系统可以用nftables或iptables，思路一样。需要提醒的是，修改默认区域策略前务必确认SSH端口对应的规则已经添加为白名单，否则规则reload瞬间你就会被断开。我自己的习惯是先添加一个临时规则放行SSH，再修改默认区域，确认连接正常后再收紧临时规则。如果使用iptables，建议通过服务方式管理规则，避免重启后规则丢失。
4.2 端口与服务收敛：从网络层缩小攻击面
防火墙策略解决的是“谁能访问”，端口收敛解决的是“该不该暴露”。有些中间件默认监听所有网卡的端口，比如某些数据库会同时绑定0.0.0.0，虽然云安全组限制了外部访问，但如果同一VPC内还有其他机器被攻陷，内部横向移动就能轻松连上这些端口。
我的建议是所有服务默认只监听内网IP或回环地址。修改监听的思路很简单，比如MySQL把bind-address改成内网IP，Redis加上protected-mode和绑定IP。另外要养成用ss -lntp检查端口绑定的习惯，确认每个端口都绑定在期望的地址上。
# 检查端口绑定情况 ss -lntp # 查看进程二进制位置和启动参数 ps -ef | grep 服务名Kubernetes里因为Service转发和NodePort的需求，端口治理会复杂一些，但原则不变：非必要不暴露。对于云上机器，安全组规则也要定期清理，很多安全事件就是从一条宽松的安全组规则开始的。
4.3 auditd审计：让每一次执行都有记录
安全加固的最后一公里是审计。系统好不好用是一回事，出事之后能不能查清楚是另一回事。Linux自带的auditd就是企业级审计的核心工具。建议在加固阶段就配置好，不要等到事件发生后再补救。
安装auditd后，重点配置规则。我的常用规则包括：监控/etc/passwd、/etc/shadow、/etc/sudoers的写操作，监控/var/run/utmp、wtmp等登录记录文件的写操作，监控sudo提权行为，以及对关键服务二进制目录的写操作。
# 添加审计规则 auditctl -w /etc/passwd -p wa -k identity-file auditctl -w /etc/shadow -p wa -k identity-file auditctl -w /etc/sudoers -p wa -k sudoers-file auditctl -w /etc/ssh/sshd_config -p wa -k sshd-config auditctl -a always,exit -F arch=b64 -S execve -k program-execution # 查看审计日志 ausearch -k identity-file -ts today # 查看所有auditd规则 auditctl -l审计规则不是加得越多越好。规则过多会产生海量日志，反而导致真正重要的线索淹没在噪音里。我建议把重点放在敏感文件、提权行为、登录行为这三类，其他业务路径按需补充。另外，配置auditd日志的磁盘空间上限很重要，避免日志把根分区写满。我一般设置max_log_file = 1024和num_logs = 5做日志轮转。
4.4 日志集中与完整性校验：企业级审计的兜底方案
单台机器的安全日志即使配置再完善，也有被篡改的可能。如果攻击者拿到了root权限，他可以直接清空/var/log下的内容。所以企业级环境一定要把日志实时发送到远程日志服务器或云日志平台。这个动作在合规审计里几乎是必查项。
先说说日志实时传输。很多人的第一反应是rsyslog。在/etc/rsyslog.conf里配置远程日志目标就可以，但要注意传输过程中的加密和认证，防止日志在传输途中被篡改。更可靠的方式是用日志采集代理，比如Filebeat之类的轻量级采集器，把日志稳定推送到集中平台。另外要确保系统时钟使用NTP同步，因为日志时间戳如果不一致，后期关联分析会非常痛苦。
文件完整性校验方面，可以使用AIDE这类工具。AIDE首次初始化会生成一个数据库，记录关键文件的哈希值，之后定期比对，任何被修改的文件都会报警。
# 初始化AIDE数据库 aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz # 定期执行完整性检查 aide --check我一般会把AIDE检查做成每天一次的定时任务，并把输出结果汇总到日志平台。需要注意的是，AIDE的数据库文件本身应该存储在安全的地方，比如单独的加密分区或远程存储，否则攻击者改完文件后同步更新数据库，检查就失去了意义。
4.5 入侵检测与日常巡检：加固是持续的过程
企业级安全加固不是一次性项目，而是一个持续的过程。即使你完成了账号、SSH、内核、防火墙、SELinux和审计的所有加固，也不能高枕无忧。新漏洞会不断出现，业务配置会持续变化，人员的账号权限也会调整。
日常巡检我建议至少覆盖以下几项：检查SSH登录日志中有没有大量Failed password记录，检查系统有没有新增加的可登录账号，检查/etc/cron.d和用户的crontab有没有异常任务，检查系统进程中有没有可疑的高CPU进程，检查最近修改的可执行文件。这些巡检动作不一定要复杂脚本，一个简单的shell脚本加上日志推送，就能满足大多数场景。
# 查看最近的SSH登录记录 last -20 # 检查认证失败的来源 grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20 # 查看所有用户的crontab for user in $(cut -d: -f1 /etc/passwd); do crontab -l -u $user 2>/dev/null; done这里也分享一下我在实际排查中的心得。有一次告警平台通知某台机器存在异常外连，常规检查没发现问题，后来我看了一眼该用户的.bashrc，发现里面被注入了一行下载脚本的命令。这种隐藏恶意代码的方式非常隐蔽，因为它只在用户登录shell时触发，不会在进程列表中出现。所以巡检时不要只盯着进程和端口，也要检查用户的shell初始化文件，比如/etc/profile、/etc/bashrc、~/.bashrc、~/.profile。
5. 实战中反复踩过的坑
5.1 自己把自己锁在SSH门外
这是我见过最多也是最尴尬的事故。加固SSH时把PasswordAuthentication改成no，然后把PermitRootLogin改成no，结果公钥未正确配置，或者作者把公钥写进了错误的文件，导致所有管理员都无法登录。更糟糕的是，如果同时修改了防火墙默认策略，想恢复都很难找到入口。
实际处理建议：改动SSH配置前，先开启一个额外的root会话或确认带外管理通道可用。配置文件修改完成先执行sshd -t验证语法，然后执行systemctl reload sshd，不要使用restart，reload不会中断现有连接。改完后不要立刻关闭当前会话，新开一个终端测试新配置连接正常，再关闭旧的。
注意：任何涉及SSH、防火墙、sudo的变更，务必保留至少一个已认证的活跃会话，否则一旦配置有误，你可能彻底失去访问入口。
5.2 SELinux开启后业务突然403
很多人在运维中遇到过这样的情况：关闭SELinux后业务一切正常，一旦开启强模式，Web服务就返回403或无法连接后端。排查思路不能简单粗暴地继续关闭SELinux，而是先通过日志确定被拦截的具体操作。
ausearch -m avc -ts recent能看到最近的SELinux拒绝记录。比如Nginx无法读取某个静态文件目录，可能是目录的SELinux上下文不对，用restorecon -Rv 目录恢复默认上下文即可。如果是Nginx代理后端连接被拒，通常是因为httpd_can_network_connect这个布尔值没有开启。
# 查看影响Web连接的SELinux布尔值 getsebool -a | grep httpd # 临时允许Web服务发起网络连接 setsebool -P httpd_can_network_connect 1这里要提醒，setsebool -P是持久化设置，会写入SELinux策略，一定要确认业务确实需要才开启。
5.3 加固脚本误伤业务：权限与挂载选项的影响
某次我给一台机器的/tmp目录加上noexec，结果当天下午就有同事反馈某个Java应用的临时文件执行失败。原因很简单，Java的java.io.tmpdir默认就是/tmp，某些框架会在临时目录下生成可执行脚本。类似情况还有给/home分区加上nodev，但某些虚拟机监控脚本需要在home目录创建设备节点。
这类问题没有完全规避的办法，但有个原则：变更之前查业务依赖。对于/tmp这类目录，建议做成白名单式的临时目录规划，或者通过systemd的单位设置PrivateTmp=true，让每个服务使用自己的私有临时目录，既隔离又安全。挂载选项调整后，一定要在业务低峰逐一验证受影响的服务状态。
5.4 日志泛滥的审计配置
我曾经遇到过一台机器因为auditd规则配置过多，导致systemd日志每天上GB，最后根分区写满，数据库进入只读模式。这是一个非常典型的“安全加固反伤业务”案例。审计是必要的，但一定要控制粒度和存储。
我的经验是：先根据合规要求列出必须监控的关键项，再按优先级上线。对于低频高价值行为，比如sudo提权、/etc/shadow修改，可以精细监控；对于高频低价值行为，比如普通的HTTP请求，不要用auditd去记录，交给业务日志即可。同时设置日志文件大小和轮转，配合定期归档，避免日志占满磁盘。
6. 最后再分享一个小技巧
做完整套加固之后，建议把每一步变更都写成文档并回顾一遍，尤其是那些“当时觉得无所谓”的配置项。我在一次复盘中发现自己曾为了排查一个问题临时关闭了SELinux，后来问题解决后忘记恢复，这个隐患挂了一个月才被发现。安全加固的真正难点从来不是配置有多复杂，而是配置能不能长期保持有效。
我的习惯是做一个只读的基线检查脚本，每次登录服务器先跑一遍，对照基线阈值输出差异。比如检查SSH配置是否被改动、root账号是否被锁定、防火墙规则是否变化、关键文件哈希是否一致。这样即使有运维人员在紧急修复时临时改动了安全配置，也能及时被提示恢复。脚本本身不用写得花哨，把系统命令组合起来，配合定时任务和日志平台，就能形成一套低成本的持续加固机制。
“Linux企业级安全加固”这个主题，讲短期动作，就是账号、SSH、内核、防火墙、SELinux、审计这几块；讲长期能力，才是持续巡检、配置管理和应急响应。按照这篇内容里的顺序逐项落下去，你的服务器暴露面会明显收窄，而这个过程并不需要复杂的商业安全产品，大部分工作用Linux自带的工具就能完成。真正的价值在于你愿意花时间做一遍，而不是收藏一堆加固文档。
