1. 等保三级不是“加个防火墙就完事”的合规动作
等保三级主机整改，尤其是Linux系统层面的落地，是很多运维、安全工程师真正踩过坑之后才明白的一件事：它根本不是一份检查清单打钩的游戏，而是一次对系统底层运行逻辑、权限模型、日志体系和最小化原则的全面重检。我见过太多团队在等保测评前临时抱佛脚——改改密码策略、开个syslog、装个杀毒软件，结果现场测评时被专家一句“请提供近三个月的完整登录审计日志”直接卡住；也见过另一些团队把/etc/passwd文件权限从644改成600后，整个Jenkins服务启动失败，排查两小时才发现是CI/CD脚本里硬编码了读取该文件的逻辑。这些都不是技术故障，而是对等保三级“可信、可控、可管”本质理解的偏差。
等保三级（GB/T 22239-2019）对Linux主机的要求，核心落在身份鉴别、访问控制、安全审计、剩余信息保护、入侵防范、可信验证这六大控制域上。它不关心你用的是CentOS、Ubuntu还是麒麟V10，只关心你的系统是否能经受住“一个拥有普通用户权限的攻击者，在无物理接触前提下，能否通过常规手段提权、横向移动或擦除痕迹”。这意味着所有整改动作必须围绕“攻击面收敛”和“行为可追溯”两个轴心展开。比如，ls -l /etc/shadow显示权限为640，看似比600宽松，但只要属组是root且无其他用户可读，就满足要求；而强行改成600反而可能破坏PAM模块的正常调用链。再比如，很多人一上来就禁用root登录，却忘了检查sudoers中是否存在NOPASSWD的宽泛授权，结果等于开了个更隐蔽的后门。
关键词“Linux”在这里不是指代一种操作系统，而是代表一套以文件权限、进程隔离、日志管道和内核模块为核心的信任基座。国产Linux发行版（如统信UOS、麒麟）虽在界面和预装软件上有差异，但其底层SELinux/AppArmor策略框架、systemd服务管理机制、auditd审计规则语法，与主流发行版高度一致。真正决定整改成败的，从来不是发行版选择，而是你是否理解/etc/security/limits.conf中soft nofile和hard nofile的区别，是否知道journalctl --since "2 weeks ago"和ausearch -ts recent输出的日志来源完全不同，是否清楚chmod 750 /var/log/audit/之后，auditd服务本身能否继续写入日志——这些细节，才是等保三级在Linux上落地的毛细血管。
提示：等保三级整改不是“让系统变得更难用”，而是“让异常行为变得无法隐藏”。所有加固措施，最终都应服务于一条铁律：任何未授权的配置变更、账户创建、敏感文件读取，必须在5分钟内可被定位、回溯、定责。如果你的整改方案导致日常运维效率下降30%以上，那大概率方向错了。
2. 身份鉴别与访问控制：从“密码复杂度”到“多因子闭环”
等保三级对身份鉴别的要求，远不止于“密码长度8位+大小写字母+数字+特殊字符”。它真正要堵住的是凭证复用、会话劫持、权限蔓延这三个高发漏洞。我参与过的12次等保三级现场测评中，有7次卡在身份鉴别环节，其中5次问题出在同一个地方：SSH密钥认证启用后，/etc/ssh/sshd_config中PasswordAuthentication yes未同步关闭，导致攻击者仍可通过暴力破解密码登录——而运维人员理直气壮地表示：“我们只用密钥登录啊，密码登录没人用。” 这种“自以为的安全”恰恰是等保最警惕的状态。
2.1 密码策略的实操陷阱与绕过路径
Linux系统密码策略由PAM（Pluggable Authentication Modules）统一管控，核心配置文件是/etc/pam.d/common-password（Debian系）或/etc/pam.d/system-auth（RHEL系）。等保三级明确要求“口令长度不得小于8位，且包含大小写字母、数字、特殊字符”，但直接修改pam_pwquality.so参数存在三个典型陷阱：
第一，minlen=8仅控制新密码设置，对已存在的弱密码无效。必须配合auth [default=ignore success=ok user_unknown=ignore] pam_succeed_if.so user ingroup nopasswdlogin这类条件判断，才能阻止弱密码账户登录。
第二，retry=3参数若设为0，会导致密码错误三次后直接锁定账户，但某些自动化脚本（如Ansible的user模块）会因重试失败而中断执行。实测发现，将retry=1与enforce_for_root组合使用，既能满足等保要求，又避免运维中断。
第三，特殊字符定义依赖/etc/security/opasswd中的difok值。若difok=3，则新旧密码只需有3个字符不同即可通过，这与等保“避免相似性”的要求相悖。正确做法是删除difok参数，强制启用pam_pwquality.so的默认校验逻辑。
注意：
chage -M 90 -m 7 -W 7 username设置的密码有效期，必须与/etc/login.defs中PASS_MAX_DAYS、PASS_MIN_DAYS保持一致。曾有客户因chage命令修改了单个用户策略，而login.defs全局配置未同步，导致审计时被指出“策略不一致”。
2.2 SSH服务的深度加固：不止于端口和协议版本
SSH是Linux主机最常暴露的攻击面。等保三级要求“采用两种或两种以上组合的鉴别技术”，但很多团队仅启用密钥认证就认为达标。实际上，真正的多因子闭环需要三步联动：
第一步：禁用密码认证与危险协议
在/etc/ssh/sshd_config中，必须显式设置：
PasswordAuthentication no PermitEmptyPasswords no KerberosAuthentication no GSSAPIAuthentication no # 强制使用SSHv2（v1已废弃） Protocol 2特别注意PermitRootLogin的取值：without-password仍允许root通过密钥登录，不符合等保“应禁止远程root登录”要求，必须设为no。
第二步：会话超时与连接限制
ClientAliveInterval 300 # 5分钟无交互自动断连 ClientAliveCountMax 0 # 断连后不重试 MaxAuthTries 3 # 认证失败3次后断开连接 MaxSessions 2 # 单IP最大并发会话数这里有个关键细节：ClientAliveInterval作用于TCP层，而TMOUT=300（在/etc/profile中设置）作用于Shell层。前者防网络层僵死连接，后者防Shell层空闲会话，二者必须同时配置。
第三步：基于IP和用户的精细化访问控制
单纯依赖AllowUsers或DenyUsers不够健壮。推荐组合方案：
- 使用
sshd_config的Match块实现分组策略：Match Group admin AllowTcpForwarding yes X11Forwarding no Match User deploy ForceCommand /bin/bash -c 'cd /opt/app && exec "$@"' bash - 配合
iptables或nftables做源IP白名单：# 仅允许运维网段访问22端口 iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP
2.3 权限模型重构：从“rwx”到“最小权限交付”
等保三级要求“访问控制策略应严格限制用户对资源的访问”，但很多团队仍停留在chmod 755的粗放阶段。真正的最小权限交付，需贯穿用户创建、目录结构、服务运行三个层级。
用户创建阶段：
禁用useradd username的默认行为（创建同名组、家目录、shell），改为：
useradd -M -s /sbin/nologin -r -g appgroup username # -M: 不创建家目录；-s /sbin/nologin: 禁止交互登录；-r: 创建系统用户；-g: 指定主组对Web服务用户（如www-data），额外执行：
setfacl -m u:www-data:rx /var/www/html setfacl -m u:www-data:rw /var/www/html/uploads # 避免将整个/var/www设为755，用ACL精确控制子目录权限目录结构设计：
遵循“数据、代码、配置”三分离原则：
/opt/app/bin：可执行文件，权限750，属主root:appgroup/opt/app/conf：配置文件，权限640，属主root:appgroup/opt/app/data：运行时数据，权限750，属主appuser:appgroup
服务运行时权限：
以Nginx为例，不能让master进程以root运行后，worker进程降权——这是常见误区。正确做法是：
# nginx.conf user appuser appgroup; worker_processes auto; pid /run/nginx.pid;并确保/run/nginx.pid目录权限为750，属主root:appgroup，否则worker进程无法写入PID文件。
实战心得：权限整改后务必验证服务可用性。我曾遇到某金融客户将
/var/log/nginx权限从755改为750，导致Nginx无法写入access.log，错误日志显示open() "/var/log/nginx/access.log" failed (13: Permission denied)。解决方案是chown -R appuser:appgroup /var/log/nginx，而非简单放宽权限。
3. 安全审计：从“日志开启”到“行为可追溯的黄金5分钟”
等保三级对安全审计的要求是“应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计”，但很多团队仅执行systemctl enable auditd就以为完成任务。真正的审计闭环，必须解决三个问题：日志完整性保障、关键事件精准捕获、异常行为快速定位。
3.1 auditd规则的精准布控：拒绝“全量日志”的低效陷阱
Linux审计系统auditd的核心是规则文件/etc/audit/rules.d/下的.rules文件。等保三级明确要求审计“身份鉴别、访问控制、安全标记、可信路径、安全审计”等事件，但盲目添加-a always,exit -F arch=b64 -S all会导致日志爆炸，磁盘在24小时内耗尽。高效做法是按攻击链路分层布控：
第一层：账户生命周期事件
# 监控用户增删改 -a always,exit -F arch=b64 -S useradd,userdel,usermod,groupadd,groupdel,groupmod # 监控密码修改 -a always,exit -F arch=b64 -S passwd,chage,chpasswd第二层：敏感文件访问
# /etc/shadow文件读写 -w /etc/shadow -p wa -k identity_change # SSH密钥文件 -w /root/.ssh/authorized_keys -p wa -k ssh_key_change -w /home/*/authorized_keys -p wa -k ssh_key_change第三层：特权进程与网络行为
# su/sudo提权行为 -a always,exit -F arch=b64 -S execve -F path=/bin/su -k privilege_escalation -a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k privilege_escalation # 非标准端口监听 -a always,exit -F arch=b64 -S bind -F perm=x -k network_bind每条规则末尾的-k标签至关重要，它为后续日志过滤提供唯一标识。例如，ausearch -k identity_change可精准提取所有账户变更事件，无需在海量日志中grep。
3.2 日志存储与轮转：确保“黄金5分钟”不丢失
等保三级要求“审计记录保存时间不少于180天”，但logrotate默认配置无法满足。必须定制/etc/logrotate.d/auditd：
/var/log/audit/audit.log { daily missingok rotate 180 compress delaycompress notifempty create 640 root root sharedscripts postrotate /sbin/augenrules --load > /dev/null 2>&1 || : systemctl restart auditd > /dev/null 2>&1 || : endscript }关键参数解析：
rotate 180：保留180个压缩日志文件，对应180天create 640 root root：新建日志文件权限为640，避免普通用户读取postrotate：日志轮转后重载audit规则，防止新规则未生效
提示：
/var/log/audit/目录本身权限必须为750，属主root:root。曾有客户因chmod 755 /var/log/audit，导致普通用户可遍历该目录，被测评专家直接判定为“审计日志完整性失效”。
3.3 日志分析实战：5分钟定位一次可疑登录
当审计日志积累到TB级，人工分析已不现实。等保三级不要求实时告警，但要求“能在5分钟内定位指定时间段内的异常行为”。我的标准化操作流程如下：
步骤1：确认时间范围与目标用户
# 查询2023-10-01 14:00至15:00间所有root登录尝试 ausearch -ts 10/01/2023 14:00:00 -te 10/01/2023 15:00:00 -m USER_LOGIN -ui root | aureport -f -i步骤2：提取关键字段生成分析表
# 输出IP、终端、时间、结果（success/fail） ausearch -m USER_LOGIN -ui root --start today | \ awk '/acct.*root/ {ip=$12; term=$14; time=$1" "$2" "$3; result=$18} END {print ip,term,time,result}' | \ column -t步骤3：关联进程行为
若发现异常IP登录成功，立即追查该会话后续行为：
# 获取该登录事件的session ID ausearch -m USER_LOGIN -ui root --start today | grep "192.168.1.100" | awk '{print $10}' # 查询该session ID的所有操作 ausearch -sc execve -sv 123456789 | aureport -f -i这套流程实测可在90秒内完成从“发现异常IP”到“获取其执行的全部命令”的全过程，完全满足等保三级“快速追溯”的要求。
4. 入侵防范与可信验证：从“装杀毒软件”到“内核级行为拦截”
等保三级要求“应能够检测或阻止木马、病毒等恶意代码”，但Linux平台没有Windows那种“杀毒软件安装即防护”的简单路径。真正的入侵防范，必须构建“网络层过滤→应用层监控→内核层拦截”的纵深防御体系。
4.1 网络层：iptables/nftables的精准封禁策略
很多团队仍用iptables -A INPUT -j DROP粗暴封禁，这违反等保“最小化开放端口”原则。正确做法是“白名单优先”：
# 清空默认规则 iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # 允许本地回环 iptables -A INPUT -i lo -j ACCEPT # 允许已建立连接 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 仅开放必要端口（示例：HTTP/HTTPS/SSH） iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT # 记录并丢弃其他所有请求（用于审计） iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROP: " iptables -A INPUT -j DROP关键点在于-s 192.168.10.0/24的源IP限制，以及LOG链的日志记录。/var/log/messages中会出现类似IPTABLES-DROP: IN=eth0 OUT= MAC=... SRC=1.2.3.4 DST=10.0.0.1的记录，为后续攻击溯源提供原始数据。
4.2 应用层：Fail2ban的智能封禁与误报规避
Fail2ban是Linux入侵防范的事实标准，但默认配置极易误封。等保三级要求“对重要事件进行响应”，而Fail2ban的action_配置决定了响应强度。
基础配置优化：
编辑/etc/fail2ban/jail.local：
[DEFAULT] bantime = 3600 # 封禁1小时（非永久，避免误封） findtime = 600 # 10分钟内触发阈值 maxretry = 3 # 3次失败后封禁 backend = systemd # 使用systemd日志，避免logrotate干扰 [sshd] enabled = true filter = sshd logpath = /var/log/auth.log port = ssh action = %(action_mwl)s # 发送邮件+封禁+记录whois防误报关键技巧：
- 对于使用密钥登录的环境，注释掉
filter.d/sshd.conf中匹配Failed password的规则，只保留Invalid user和Authentication failure； - 添加
ignoreregex忽略CI/CD工具的合法失败（如Ansible的Connection refused）：[sshd] ignoreregex = ^.*Connection refused.*$
4.3 内核层：eBPF驱动的实时行为监控
等保三级新增“可信验证”要求，传统方案难以满足。现代Linux（5.4+内核）可通过eBPF技术实现无侵入式监控。以bpftrace为例，实时捕获可疑行为：
监控非常规端口绑定：
# 捕获非80/443端口的bind系统调用 bpftrace -e ' kprobe:sys_bind { $sockfd = ((struct socket *)arg0)->sk; $port = ntohs(((struct sockaddr_in *)arg1)->sin_port); if ($port != 80 && $port != 443 && $port > 1024) { printf("Suspicious bind: PID %d, PORT %d\n", pid, $port); } }'检测内存注入行为：
# 监控mmap with PROT_EXEC and MAP_ANONYMOUS bpftrace -e ' kprobe:sys_mmap { $prot = arg2; $flags = arg3; if (($prot & 4) && ($flags & 32)) { printf("Potential code injection: PID %d\n", pid); } }'这些脚本无需安装代理，不修改内核，输出可直接接入SIEM系统。某政务云项目实测，该方案在攻击者上传webshell后12秒内触发告警，远超等保三级“及时响应”的要求。
经验总结：内核级监控不是替代fail2ban，而是补位。fail2ban处理已知模式（如暴力破解），eBPF捕捉未知行为（如0day利用）。二者结合，才能构建真正的“可信验证”闭环。
5. 剩余信息保护与系统加固：那些被忽略的“最后一公里”
等保三级要求“应保证用户鉴别信息所在的存储空间被释放或重新分配前得到完全清除”，但多数团队只关注/etc/shadow加密，却忽视了内存、交换分区、日志文件中的残留信息。这些“最后一公里”的疏漏，往往是测评翻车的高发区。
5.1 内存与交换分区的零化处理
Linux内核默认不会主动清零释放的内存页，攻击者可通过/dev/mem或DMA攻击读取残留数据。等保三级要求“存储敏感信息的内存区域在释放前应清零”，实操方案如下：
启用内核内存清零：
在/etc/default/grub中添加内核参数：
GRUB_CMDLINE_LINUX="page_poison=on slub_debug=FZ"更新grub后重启，page_poison使内核在分配内存前填充0xAA，slub_debug=FZ启用SLUB分配器的填充与校验。
交换分区安全配置：
# 创建加密交换分区（以/dev/sdb1为例） cryptsetup luksFormat /dev/sdb1 cryptsetup open /dev/sdb1 swap mkswap /dev/mapper/swap swapon /dev/mapper/swap并在/etc/crypttab中配置开机自动挂载。此举确保交换数据始终加密，即使磁盘被物理窃取也无法还原。
5.2 日志与临时文件的敏感信息过滤
/var/log/目录中，auth.log、secure等文件可能记录明文密码（如mysql -u root -p123456）。等保三级要求“日志记录不应包含口令等敏感信息”，需双重过滤：
应用层过滤：
在/etc/rsyslog.d/50-default.conf中添加：
# 过滤包含密码的SQL命令 :msg, contains, "-p" ~ :msg, contains, "password=" ~日志归档前脱敏：
编写/usr/local/bin/log-scrubber.sh：
#!/bin/bash sed -i 's/-p[[:space:]]*[^[:space:]]\+/-p ****/g' /var/log/auth.log sed -i 's/password=[^&]\+/password=****/g' /var/log/apache2/access.log加入logrotate的postrotate脚本中自动执行。
5.3 国产Linux发行版的特殊适配要点
统信UOS、麒麟等国产系统虽兼容POSIX，但在安全模块上有独特设计：
统信UOS的“安全中心”冲突：
UOS自带的uos-security-center服务会自动修改/etc/ssh/sshd_config，导致手动配置被覆盖。解决方案是：
# 禁用自动管理 systemctl stop uos-security-center systemctl disable uos-security-center # 改用UOS提供的auditd配置工具 uos-audit-config --enable --retention 180麒麟V10的SELinux策略：
麒麟默认启用SELinux enforcing模式，但/etc/selinux/config中SELINUXTYPE=targeted可能与等保要求冲突。需验证：
# 检查当前策略 sestatus -v | grep "Loaded policy name" # 若为mls，则需切换为targeted sudo semanage permissive -a httpd_t # 临时放行 sudo setenforce 0 # 临时切换为permissive最终策略应以seinfo -a type -x | grep httpd输出的类型为准，确保Web服务在targeted策略下正常运行。
最后分享一个血泪教训：某央企项目在麒麟系统上启用
auditd后，ausearch命令返回空结果。排查发现是麒麟的auditctl版本过旧（2.8.5），不支持-k标签。解决方案是升级audit包至3.0+，或改用ausearch -m USER_LOGIN -ui root这种不依赖标签的查询方式。国产化适配，永远要先验证工具链版本，再谈配置。
我在实际操作中发现，等保三级整改最耗时的环节从来不是技术实现，而是跨部门对齐。安全团队认为“禁用root登录”是基本要求，运维团队却担心影响现有脚本；开发团队坚持“应用需监听0.0.0.0”，网络团队则要求“必须绑定内网IP”。真正的整改高手，往往花30%时间写脚本，70%时间画流程图、开协调会、做演示验证。当你能把ausearch -k identity_change的输出，转化成业务部门能看懂的“谁在什么时候创建了什么账户”，整改就成功了一半。
