做运维这几年，每次遇到企业Linux服务器安全检查，我第一反应就是先看防火墙和补丁。很多时候，不是系统被攻破后才想起加固，而是合规审计、等保测评、年度红蓝对抗这些轮番上阵，逼着我们把安全基线一点点补齐。说实话，企业级Linux防护并不是装个杀毒软件、开个防火墙就完事，它是一套以“防火墙配置 + 漏洞修复”为核心，再叠加审计、权限、统一基线管理的工程。这篇文章我就站在一线运维的角度，把从零到合规的完整思路、踩过的坑、以及可以直接落地的命令和配置一起理清楚。无论你是刚接手服务器的新手，还是正准备应付下一次安全巡检的同学，都能在这里找到一套能直接“抄作业”的路径。

1. 企业级Linux安全基线：先搞清楚合规究竟查什么

1.1 合规标准不是摆设：等保、CIS、PCI-DSS的共通点

很多新人一听到“合规”就头大，觉得是拿一堆高大上的文档压人。实际干下来，我发现无论国内常用等保，还是国际常见的CIS Benchmarks、PCI-DSS，落到Linux主机上查的东西出奇一致：身份鉴别、访问控制、安全审计、入侵防范、恶意代码防护、补丁管理。换句话说，合规本质上就是一套“有没有做、做没做对、被查时能不能拿出证据”的框架。

我之前陪某家做电商业务的客户做过一次内部预审，当时他们的服务器还停留在“能通就开、端口全放”的阶段。审计人员过来第一件事就是看防火墙策略：默认策略是拒绝还是允许？有没有多余的端口暴露在公网？再一看SSH，居然还允许root密码登录，补丁也停在半年以前。你说业务正常运行没问题，但审计那里直接挂掉。所以合规的第一步不是去背条文，而是先把自己服务器的“门面”收拾干净。

另外一个关键点是：合规标准不是一刀切。同样的配置，在测试环境可以宽松，在业务核心区就要严格收紧。CIS Level 1和Level 2的区别就代表了这种分级思想——Level 1是基础底线，Level 2是强化防护。做企业合规，千万别一上来就把所有服务器都当核心系统，否则运维成本会把你压垮。

1.2 安全审计常见的检查项：端口、服务、补丁、日志

合规审计最常翻的“作业”其实就是四个维度。第一，端口与服务：公网IP上到底开了哪些TCP/UDP端口？对应的服务是不是业务必需的？第二，补丁与漏洞：系统版本是否过时？关键CVE有没有修复？我用工具扫一眼就大概知道这家企业的运维水平。第三，日志与审计：有没有记录登录成功/失败？有没有集中存储日志？日志留存时间是否满足要求？第四，账号与权限：是否存在共享账号？普通用户是否有sudo权限？弱口令、空口令是不是一筛一大把。

以我自己的习惯，每次接到服务器巡检任务，第一轮先跑几条命令摸底：ss -tlnp看监听端口，systemctl list-units --type=service --state=running看运行服务，last -n 20看登录记录，再查一下/etc/passwd和/etc/sudoers。别小看这几条命令，审计时的问题大多数都能从里面翻出来。

1.3 动手前先做好风险评估与资产盘点

说到这我必须提醒一句：别急着改配置。我见过有同事接手安全加固任务，上来就按文档把防火墙默认策略改成拒绝，结果把数据库连结点给断了，业务直接告警。做任何加固前，先把资产盘清楚，分清楚哪台是数据库、哪台是应用、哪台需要对外开放。根据我的经验，至少要先整理出一张清单，包含：IP地址、主机名、作用、责任人、对外开放端口、依赖关系。

盘完资产再评估风险，给每台服务器定个优先级。比如公网Web服务器风险最高，内网GitLab次之，离线备份机最低。风险高的先处理，配置的颗粒度也更细。这一步做完，后面所有操作才有依据，不然就是在裸奔状态下叠被子，看似勤快其实没用。

2. 防火墙配置实战：从firewalld到nftables的选型与落地

2.1 防火墙选型：生产环境选firewalld还是nftables

Linux防火墙这几年基本分成两大阵营：老的iptables体系，以及Red Hat系默认的firewalld，还有新一代的nftables。我日常打交道最多的是firewalld，因为RHEL/CentOS/Rocky这些系统默认都带，管理zone和安全域的思路也很清晰，适合大多数人。但如果你追求极致的性能和灵活度，或者跑的是纯内网高并发Nginx网关，那nftables绝对更合适，它是内核级netfilter的现代接口，语法比iptables更紧凑，性能也更好。

我自己选型的逻辑其实很简单：对配置可追溯、需要频繁加策略的通用服务器，强烈建议用firewalld；对需要自定义规则链、处理内容较多、希望规则集一眼能看全的高性能网关，则直接用nftables。两者都可以存为永久配置，重启不丢失。另外有个坑要提醒：别在同一台机器上混用iptables service和firewalld，很容易出现规则互相覆盖，排查起来会让你怀疑人生。

如果你还停留在用iptables命令逐条写规则的阶段，我劝你尽早切到firewalld。它虽然底层可能还是调用iptables或nftables，但给你包了一层zone和service的抽象，不会出现“配置几十条规则之后根本不知道哪条生效”的窘境。

2.2 基于firewalld的最小化放行策略配置

前面说了这么多，还是直接看实操。我一般会把服务器划分到几个zone里：public是暴露给公网，trusted是内部可信网络，internal是管理网段。每台机器默认zone设为public，然后按业务最小化放行端口。

首先确认firewalld在跑：

systemctl enable --now firewalld firewall-cmd --state

接着设置默认zone为public，并查看当前状态：

firewall-cmd --set-default-zone=public firewall-cmd --list-all --zone=public

假设一台Web服务器需要开放80和443端口，同时允许来自内网网段10.10.10.0/24的SSH管理访问，其余一律拒绝。配置命令如下：

firewall-cmd --permanent --zone=public --add-service=http firewall-cmd --permanent --zone=public --add-service=https firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.10.10.0/24" service name="ssh" accept' firewall-cmd --reload

细心的同学会注意到我没有把SSH直接放进public，而是用rich rule限制来源网段。这才是企业环境该有的姿势：管理端口永远不要对全互联网裸奔。等保和CIS里也反复强调，远程管理要限制源地址。这里有个小技巧：--permanent参数表示写入永久配置，但不会立即生效，必须配合--reload。如果你希望临时生效可以先不加permanent，测试没问题再永久化。

做完之后，我用firewall-cmd --list-all --zone=public验证，看到的结果应该是：http、https放行，ssh只对10.10.10.0/24源地址放行。有人会问，为什么不用--add-port=80/tcp？我推荐优先用service名称，因为一个service背后可能包含多个端口（比如http包含80，还可能有别的）。当服务比较标准时，用service管理起来更清晰，审计也更友好。

2.3 用nftables实现高性能规则集

如果机器上没装firewalld，或者你习惯更直接的规则编写方式，nftables是个值得掌握的工具。它比iptables更现代，还能处理IPv4和IPv6一体化的规则，避免重复配置两套。

一个最小可用的nftables配置分三步：建table、建chain、写rule。比如在入站方向创建一个叫filter的IPv4/IPv6通用表，然后建立input链：

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 { http, https } accept nft add rule inet filter input ip saddr 10.10.10.0/24 tcp dport ssh accept

注意最后那条用accept之前，整条链的默认策略已经是drop，所以规则顺序是：先放行已连接状态，再放行回环，然后放行业务端口，最后放行特定管理网段。这个顺序很重要，因为在大多数防火墙里，规则是顺序匹配，匹配即停止。如果我把drop策略放在中间，后面所有规则都会失效。

日常管理时，我习惯把nftables规则写进/etc/nftables.conf，然后systemctl restart nftables生效。用nft list ruleset查看当前规则集。生产环境修改规则时，我会先在命令行测试，确认不会断掉自己的SSH，再写入文件。这个教训是用一次严重的事故换来的——某次我在内网机器上调试，把drop策略写反了，结果远程被自己锁在外面，最后只能让机房同事手动重启。

2.4 防火墙配置的常见坑：规则顺序、状态匹配、IPv6、Docker网桥

我接触的防火墙问题里，有八成不是配置语法错，而是逻辑坑和联动坑。第一个坑是规则顺序，刚才提过；第二个坑是忘了做状态匹配。现代TCP连接是双向的，入站数据包如果没先放行established/related状态，服务器主动外联的响应包会被挡在外面。所以我在所有INPUT链上都会保留ct state established,related accept。

第三个坑更隐蔽：IPv6。不少企业只配了IPv4的防火墙，一看IPv6根本没有任何规则，默认sysctl里甚至都没禁用IPv6，攻击者直接从IPv6地址绕过安全防线。我在加固时，要么在/etc/sysctl.conf里设置net.ipv6.conf.all.disable_ipv6=1来禁用，要么老老实实配一套IPv6规则，两者必选其一。

第四个坑是Docker。Docker的网桥和iptables有天然冲突，因为Docker会往nat表写入规则，firewalld有时候管不住它。我踩过的解法是：尽量不要用--network host乱映射端口，而是对外暴露端口时用-p并在宿主机防火墙里精确放行。同时可以把Docker的IP转发规则放到专门的链里，避免被firewalld清掉。最让人头疼的是firewall-cmd --reload经常把Docker链刷没，我在生产上会减少手动reload，改用firewall-cmd --runtime-to-permanent来固化运行时的规则，临时场景也不动底层链。

3. 漏洞修复实战：从扫描到加固的完整流程

3.1 漏洞扫描工具选型：OpenVAS、Trivy、Nessus的综合对比

光靠人工检查漏洞肯定不行，必须把扫描工具纳入日常操作。我自己常用的有这几套：OpenVAS适合内网深度扫描，覆盖系统漏洞和Web漏洞，但部署重、扫描慢；Trivy主要扫容器和文件系统里的软件漏洞，轻量快速，在CI阶段用非常合适；Nessus的漏洞库全、报告专业度高，商业环境用得多，但价格对个人略贵。说实话，工具不在多，关键是要坚持周期扫描。

如果一台机器跑的是常规Linux发行版，我会先用系统自带的包管理检查更新源里的安全补丁。像CentOS/RHEL上，yum --security相关的插件可以过滤出安全更新；Ubuntu上则用apt list --upgradable再配合ubuntu-security-status。这一步最原始，有时也最有效。

3.2 漏洞优先级排序与风险评级：别被高危漏洞吓到

扫描报告出来，高危漏洞往往一大片。这时候别急着每一个都去修，先按“可利用性 + 资产重要性 + 当前暴露面”三维排序。举个例子，内网开发机上有几个中危漏洞，但对外没有暴露，修复优先级可以排低；公网Web前端如果出现一个可远程利用的高危漏洞，即便CVSS分数只有8分，也比那些9分但在内网深处且难以触达的问题更紧急。

CVSS分数是重要参考，但它只是理论危险性，真实风险还要看你的网络边界。我之前处理过一个Tomcat反序列化漏洞，扫描报的是高危，但经过排查发现Tomcat只监听内网，而且防火墙只允许特定跳板机访问，实际可利用性很低。最终我们把它排到普通补丁窗口处理，而不是半夜紧急升级。这就是风险上下文的意义。

3.3 系统补丁与软件升级策略：线上与离线环境的落地

小到一台机器，大到几千台集群，补丁策略必须分场景。先说最简单的情况：在确保有回滚的前提下，直接用包管理器升级。

# RHEL系 yum update -y yum install -y yum-plugin-security yum update --security # Debian系 apt update apt upgrade -y apt list --upgradable

生产环境更稳妥的做法是先在一台预发机上升级验证，确认业务无损，再批量推送。我见过太多不看依赖直接yum update -y把内核升到不兼容版本，导致NFS挂载失败、数据库驱动炸掉的案例。所以应对内核和重要组件（如OpenSSL、glibc）单独走变更流程，先备份，再做快照，再升级，升级后立刻跑业务健康检查。

离线内网或者等保要求比较严格的网络，补丁往往需要从隔离区导入。这时我会先在跳板机下载好RPM包或deb包，校验GPG签名，再统一拷贝到内网机器。注意依赖关系，用yumdownloader --resolve或apt-get download把依赖包一并拉全，不然内网装到一半缺依赖特别尴尬。内核补丁类升级，记得预留双内核空间，这样新内核起不来还能从grub引导回旧版本。

3.4 常见漏洞类别的配置修复：SSH、内核参数、服务暴露

有些漏洞不依赖补丁，靠配置调整就能大幅降低风险。我先把操作中最常用的几个写出来。

第一个是SSH加固。修改/etc/ssh/sshd_config：

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes Protocol 2 MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 0

我见过很多团队自认为内网就无所谓，结果等保测评抽查直接要求整改。根用户远程登录被爆破是攻击者最爱的入口，建议所有人的服务器都禁用root直接SSH，管理员通过普通账号加sudo切换到root，再叠加公钥认证。密码登录看着方便，但暴力破解在公网机器上几乎是24小时不间断的，关掉它等于关上一扇大门。

第二个是内核参数修正，写在/etc/sysctl.conf里：

net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.default.secure_redirects = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1

这些属于CIS基线里经典的“防欺骗、防扫描、防重定向”项。执行完记得sysctl -p生效。设置rp_filter尤其在多网卡机器上要小心，有时候会误伤负载均衡的实时回包，建议先在低峰期验证。

第三个是关闭不必要的服务。systemctl list-unit-files | grep enabled挨个看，像Telnet、FTP、rsh这类明文协议服务一律停掉。打印服务、CUPS、Avahi这类在企业服务器上很少用到，也尽量disable。每个不必要服务都可能是新的攻击面，减少服务数量比加多少安全软件都实在。

4. 企业合规落地：审计日志、权限加固与安全运营

4.1 审计日志：从rsyslog到auditd的配置要点

防火墙和补丁做得再漂亮，没有日志，审计就是空话。等保里有一句话叫“对安全事件进行记录、分析、留存”，要满足这一点，首先要保证每个关键操作都进入日志，并且日志不能被本地篡改。我一般分两层来做：一是rsyslog服务负责把系统日志、内核日志、认证日志集中转发；二是auditd负责记录安全相关系统调用，比如文件访问、权限变更。

先看最简单的系统日志集中。修改/etc/rsyslog.conf或客户端配置，把日志转发到日志服务器：

*.* @@192.168.18.50:514

假如日志服务器不支持TCP，可以单写@表示UDP。但UDP会丢日志，重要场景我坚持用TCP或者加TLS。客户端配完记得重启rsyslog：systemctl restart rsyslog。

auditd的配置我一般这样：

systemctl enable --now auditd auditctl -w /etc/passwd -p wa -k passwd_changes

-w表示对文件做监控，-p wa表示记录写和属性变更操作，-k是给事件加标签，方便后续用ausearch检索。生产上除了passwd，我还会盯住/etc/sudoers、/etc/ssh/sshd_config、/root/.bashrc这些高价值文件。规则填好后用auditctl -l确认加载，之后所有变更都会写进/var/log/audit/audit.log。

审计这块有个坑是日志轮转和留存天数。默认logrotate可能在30天就清空，但企业合规往往要求至少留6个月。我通常会在/etc/logrotate.d/底下调整轮转周期，并把日志同步到远程存储，之后再按天切片。没有远程日志中心时，可以先给/var/log/挂个独立分区并设置权限，至少降低本机被清理后的取证难度。

4.2 账号权限加固：sudo策略、PAM和SSH密钥管理

权限加固的优先级我认为是：最小权限 + 可追溯。所有运维人员用个人账号登录，任何提权行为必须走sudo，并且sudo日志也要保留。一个简单的sudo配置示例：

# /etc/sudoers.d/admin Cmnd_Alias ADMIN_CMDS = /usr/bin/systemctl, /usr/bin/yum, /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/groupadd %opsadmin ALL=(ALL) NOPASSWD: ADMIN_CMDS

这里我用了一个命令别名，把团队常用的管理命令放进去，不直接给ALL权限。注意，NOPASSWD能减少密码交互，但也意味着只要登录成功就能直接提权，需要在信任度高的团队内网使用。对外网或者外包人员，建议去掉NOPASSWD，强制要求sudo输入密码。

PAM这边建议在/etc/pam.d/system-auth或对应发行版的PAM配置里，加上密码复杂度策略和账户锁定策略。拿RHEL系来说，可以在/etc/security/pwquality.conf里配置：

minlen = 12 minclass = 4 try_first_pass = 3 retry = 3

强制密码长度12位以上，包含大小写、数字、符号四种字符。认证失败次数锁定，可以通过/etc/pam.d/password-auth和/etc/pam.d/system-auth添加pam_faillock.so实现。

auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900 auth sufficient pam_unix.so auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

别问我为什么强调这个，因为我见过太多生产环境密码清一色Admin@123，扫描器下场五分钟能进三台机器。密码策略虽然是老生常谈，但等保检查时它是必查项。

SSH密钥管理方面，务必将所有用户公钥统一存放，避免各自覆盖authorized_keys。有条件就部署一个基于签名的SSH CA中心，用主机证书替代繁琐的密钥分发，这样回收权限时只需要吊销对应的证书签发身份。没有条件的话，至少做一个公钥管理脚本，把各服务器的/home/xxx/.ssh/authorized_keys纳入统一配置管理工具，禁止手工乱写。

4.3 等保合规自查清单与整改流程

每次应对合规检查，我都会提前一周做一次自查。自查清单其实很简单，把之前的要点汇总成一张表格，逐台对照。下面是我常用的一部分：

检查完把不符合项记进整改清单，按严重程度排序。整改完成后再复测，留下截图和命令记录。这里我想提醒的是，整个流程一定要留痕。等保测评时专家不可能把每台服务器都亲自看一遍，能给出一份“现状、差距、整改、复测”的闭环记录，比口头解释有说服力得多。

4.4 持续合规：自动化巡检与基线漂移检测

一次性整改到位并不难，难的是让配置三个月后仍然符合要求。我都遇到过这样的情况：刚做完等保整改，某天同事图省事，临时开了一个8080端口对外测试，防火墙加了--permanent，但忘了开完就删，结果下次合规检查又挂。所以持续合规必须靠自动化。

我建议把机器纳入配置管理（比如Ansible），把防火墙规则、SSH配置、sysctl参数、审计规则全部用代码描述，任何人要变更都要走仓库。定期（比如每周）跑一次巡检脚本，检查清单项是否和历史基线一致。如果发现漂移，立刻报警并且自动修复或提示人工介入。

还可以在计划任务里加入简单的基线对拍：

# 每周一9点巡检 0 9 * * 1 root /usr/local/bin/security_check.sh > /var/log/sec_check.log

脚本里面无非就是一堆firewall-cmd --list-all、sshd -T、auditctl -l和本地配置文件的哈希比对。你看，这些命令就是从前面各项步骤里打包出来的，敲一遍落成脚本，后面就是躺平式监控。

最后再分享一个经验：合规是一个持续改进的过程，不要指望一次整改就永久高枕无忧。我在实际项目里最受益的做法是“攻防视角倒推配置”——每次修复漏洞后，我都会反过来思考“假如我是攻击者，这个端口和权限组合能不能被利用”，然后用同样的方式测试自己的加固。防火墙是边界，补丁是肌肉，审计是大脑，三者一起运转，企业Linux安全才真正撑得住合规审查。希望我这套沉淀下来的实践路径，能帮你少走一些弯路。