Linux企业级安全加固实战指南手里托管着几台业务服务器的朋友大概率都有过这样的时刻半夜收到预警邮件说某台机器被连续尝试 SSH 登录或者跑了一个history一看自己都忘了什么时候留下的 root 密码。我在这行摸爬滚打十几年被入侵、被勒索、被审计、被领导半夜打电话叫起来的情况都经历过真正意识到一件很残酷的事能用和安全之间隔着一整套 Linux 企业级安全加固的活儿。这篇内容不是给你抄文档的是我把这些年在生产环境里做过的加固项目、踩过的坑、后来总结出的方法论一条一条拆开来讲。适合刚接手服务器运维的兄弟也适合被安全整改通知逼得焦头烂额的负责人。核心思路就一句话把攻击面收缩到最小把每一次权限变更都变成可审计的让入侵者就算进来了也拿不走东西、删不掉日志、跑不长久。下面我按实战顺序把整个加固链路讲透。1. 先弄清加固边界资产盘点、威胁模型与加固到什么程度很多人的第一反应是直接改配置先把 sshd 端口改了、把密码策略调严再说。我的经验是这一步最容易出大事。你在不知道业务依赖什么的情况下动手轻则误伤调用方重则把生产环境锁死最后连夜回滚。加固的前提是先盘清楚手里到底有什么。1.1 我通常会先做的资产清单不要凭空想象花半小时把服务器上真正在跑的东西列出来。我一般用这么几个命令扫底systemctl list-units --typeservice --staterunning ss -tlnp ip addr show cat /etc/passwd | grep -E /bin/(bash|sh)$这几条命令分别回答四个问题系统上有哪些服务在跑、哪些端口在监听、网络拓扑长什么样、哪些账号可以登进 shell。做完之后整理成一张表至少包含主机名和 IP、操作系统版本、对外端口及对应进程、登录方式、数据存放路径、备份策略。这张表就是后面所有加固动作的基准线。1.2 别把可用性锁死了加固不是越严越好这里必须泼一盆冷水。很多新手拿到 CIS Benchmark 或者等保要求就一条一条往上堆结果 Nginx 起不来了、数据库连不上了、内核参数被改崩了。安全加固的目标是降低风险不是把系统变成堡垒然后业务全挂。我每次动手前都会先问三个问题这台机器承载的核心业务是什么挂了会怎样谁的运维习惯会受这些策略影响有没有例外通道是否有回滚方案变更窗口是几点举个例子有人建议把 SSH 的MaxAuthTries调成 2初衷是防暴破但如果你的运维团队有人习惯用密码登录且容易手滑这个参数会把正常用户也锁掉。我的做法是先收紧到 4观察一个月日志确认没有误杀再进一步收。渐进式收紧是生产环境加固的第一原则。2. SSH 入口改造密钥、白名单与登录风控三板斧SSH 是服务器最大的暴露面没有之一。我见过太多被入侵的案例根因都是 SSH 配置裸奔密码登录开着、root 直登开着、几十个老员工的公钥堆积在 authorized_keys 里。入口不收拾后面做再多都是白搭。2.1 基于密钥登录的正确落地姿势我的原则很简单线上环境一律禁止密码登录只保留密钥。密钥登录本身不难难在规范落地。很多团队的公钥管理是混乱的离职员工不删、换电脑不更新、还有人把私钥传到代码仓库里。我建议按这个流程走客户端生成密钥对ssh-keygen -t ed25519 -a 100优先用 ed25519兼容性不够再退到 RSA 4096。公钥通过带外方式传到服务器比如先走堡垒机的管理通道或者让管理员手动写入~/.ssh/authorized_keys。在authorized_keys文件里做限制restrict,command/usr/local/bin/check_tunnel.sh,from10.10.0.0/16 ssh-ed25519 AAAAC3Nza... useropsrestrict表示禁用端口转发、X11 转发、pty 分配等潜在危险能力from限定来源 IPcommand可以把密钥绑定到特定脚本上。这样即使私钥泄露攻击者拿到的也是一个受限的壳。2.2 sshd_config 里必须逐行过一遍的防护项在/etc/ssh/sshd_config里以下配置项我会逐个确认缺一不可配置项推荐值为什么这么设PermitRootLoginprohibit-password禁止 root 密码登录但允许 root 用密钥登录兼顾管理便利PasswordAuthenticationno彻底关闭密码认证阻断暴力破解PubkeyAuthenticationyes开启公钥认证MaxAuthTries4限制单次连接认证尝试次数防自动化爆破LoginGraceTime30限制登录超时防止并发连接耗尽连接数ClientAliveInterval/ClientAliveCountMax300/2心跳检测清理僵尸连接和挂着的终端AllowUsers具体名单白名单只允许指定用户 SSH 登录Protocol2只允许 SSHv2X11Forwardingno关闭 X11 转发PermitEmptyPasswordsno禁止空密码这里特别说一下AllowUsers。它比PermitRootLogin更细致可以指定AllowUsers alice bob192.168.1.0/24直接把所有不在名单里的人排除在 SSH 之外。配合Match块还能对不同用户组施加不同策略比如给甲方运维开一个只能用密钥、只能从指定 IP 进来的账号。改完配置务必先做语法检查再平滑重启sshd -t systemctl reload sshd2.3 fail2ban 与 SSH 的联动配置有人觉得关了密码登录fail2ban 就没用了。其实不然密钥登录时代SSH 仍然会被扫还会有人尝试利用 SSRF 或者内网跳板发起连接。我习惯保留 fail2ban用 jail 把扫描源 IP 拉黑一段观察期。关键不是默认配置而是把时间窗口调短、动作做狠[sshd] enabled true port ssh filter sshd logpath /var/log/secure maxretry 3 bantime 3600 findtime 300 action iptables-allportsfindtime是统计窗口maxretry是窗口内失败次数bantime是封禁时长。我建议bantime别设永久容易被误封后把自己关门外1 小时够用之后再看日志判断要不要永久封。还得多说一句所有 SSHD 相关的日志必须走远程集中否则攻击者进来第一件事就是truncate -s 0 /var/log/secure你连他做了什么都不知道。3. 网络层收缩防火墙从默认放行改成默认拒绝业务跑起来之后开发经常随手开端口Redis 6379、MongoDB 27017图省事就全开0.0.0.0结果被扫描器扫到数据被拖。网络层加固的核心不是开哪些端口而是把所有没在清单里的端口全部拒掉。3.1 服务暴露面的清理清单我接手的每台机器第一件事是清点端口然后把不该暴露的全部收回来。常见重灾区中间件管理端口Redis、Memcached、MongoDB 默认不带认证或弱认证绝不能暴露公网必须绑定内网 IP 或 Unix Socket。监控端口Node Exporter、Prometheus 的 web 端口默认无鉴权暴露出去等于把系统指标送给别人。调试端口Java 远程调试端口jdwp、Python 调试端口很多还是从开发环境直接带上线的。数据库端口MySQL 3306、PostgreSQL 5432只能对应用服务器的 IP 段放开。文件共享与备份通道rsync、NFS、SMB端口范围大容易成为横向移动的跳板。清理的原则是所有监听地址优先绑定127.0.0.1或内网 IP必须对外的才走防火墙或负载均衡。3.2 firewalld 区域策略与端口收敛的实战写法主流发行版里我建议统一用 firewalld 管理它的 zone 模型符合按信任级别分区的思路。默认区改成 drop再单独建业务区firewall-cmd --set-default-zonedrop firewall-cmd --permanent --new-zoneweb firewall-cmd --permanent --zoneweb --add-servicessh firewall-cmd --permanent --zoneweb --add-servicehttp firewall-cmd --permanent --zoneweb --add-servicehttps firewall-cmd --permanent --zoneweb --add-source0.0.0.0/0 firewall-cmd --reload这里的关键是把默认 zone 设为drop所有流量先丢一边然后web区只放行 80/443/22。如果要限制数据库端口只对应用服务器开放就不要再新建 zone 了直接对源 IP 加规则firewall-cmd --permanent --zoneinternal --add-rich-rulerule familyipv4 source address10.20.0.0/16 port port3306 protocoltcp accept3.3 反向代理与跳板机场景的围栏设计再进阶一层生产环境我不建议任何后端服务直连公网。最稳妥的架构是公网流量只进到 Nginx/负载均衡后端用私有网段通信管理操作全部走跳板机。这个模式下防火墙规则就非常简单了公网节点只放行 80/443。后端节点只接受来自负载均衡节点的流量。所有服务器的 22 端口只放行跳板机 IP。如果你管的是云上环境安全组和云防火墙也属于这一层别只依赖系统防火墙。我曾经遇到某团队只在云安全组层面放行了 3306没在系统层配置任何限制等安全组策略被某次变更覆盖后数据库直接裸奔了 24 小时。最佳实践是双层限制云安全组收一道、系统防火墙再收一道两层都写了规则单层失效也不至于裸奔。4. 用户与权限治理最小权限不是口头说说权限加固是最容易和业务冲突的部分。开发说我就要 root 权限装个包测试说直接给我 root 吧不然跑不起来。但如果连执行kill和rm -rf /的人都没有经过身份鉴别代码发布和误操作造成的损失绝对比你省下的那点沟通成本大得多。4.1 账号生命周期的四个检查点我要求团队定期盘一遍服务器账号重点检查四个地方是否有共享账号多人共用 root 或共用某个应用账号出事根本查不到是谁干的。坚决消灭共享账号一人一号哪怕是临时使用的账号也要实名。是否有离职账号每季度和 HR 对一次名单离职后 24 小时内禁用账号包括云平台上的子账号。是否有多余的 shell 账号grep -E /bin/(bash|sh)$ /etc/passwd列出的账号逐个人名核对。服务运行账号如nginx、mysql一律改为/sbin/nologin。uid 0 账号排查awk -F: $30{print $1} /etc/passwd除了 root 之外不应该有 uid 0 的账号留存。另外账号过期策略也要设上。每个人我都建了独立的个人账号并设置合理密码有效期同时强制首次登录改密码。这样即使密码泄露过一段时间也会失效。4.2 sudo 策略的可审计化改造直接给 root 是最偷懒也最危险的做法。我的做法是root 密码设一个超强密码后封存日常运维一律用普通用户加 sudo。sudo 要精细到命令级别用 sudoers 配置来实现Cmnd_Alias SERVICE_CMDS /bin/systemctl start nginx, /bin/systemctl stop nginx, /bin/systemctl restart nginx Cmnd_Alias LOG_CMDS /bin/journalctl, /usr/bin/tail opsuser ALL(root) NOPASSWD: SERVICE_CMDS, LOG_CMDS把常用命令收敛进别名组比直接给ALL权限风险低得多。注意systemctl千万别开太宽因为systemctl edit或systemctl restart某些服务可能间接写入配置或干掉守护进程。命令白名单里永远优先用sudoedit而不是sudo vimsudoedit能规避编辑器被 hook 的风险。审计方面sudo 日志要记录到独立的日志文件。我习惯配置/etc/sudoers里的Defaults logfile/var/log/sudo.log再把这份日志做远程采集。谁在几点钟用了什么权限执行了什么命令一查一个准。4.3 PAM 密码策略与锁定策略配置密码策略这一层我建议用 PAM 模块来管理。修改/etc/pam.d/system-auth和/etc/pam.d/password-auth加入密码复杂度与失败锁定password requisite pam_pwquality.so try_first_pass local_users_only retry3 minlen14 dcredit-1 ucredit-1 lcredit-1 ocredit-1 auth required pam_faillock.so preauth audit silent deny5 unlock_time900 auth required pam_faillock.so authfail audit deny5 unlock_time900minlen14是密码最小长度dcredit/ucredit/lcredit/ocredit-1表示大写、小写、数字、特殊字符至少各 1 个。pam_faillock.so配置 5 次失败锁定 15 分钟防止密码被循环猜解。这里要提醒一句PAM 配置顺序非常敏感pam_faillock的preauth和authfail行位置不对会导致锁定策略失效或者用户永远被锁。改完先用一个测试账号登录验证不要拿生产账号直接试。5. 文件、内核与强制访问控制的纵深防线网络层和账号层都收紧了接下来是系统本身的纵深防御。这一层解决的是即使攻击者拿到 shell他也不能为所欲为。很多人说 SELinux 太麻烦直接关掉但我的建议是在做过评估的业务场景里SELinux/AppArmor 一定要开这是最后一道兜底。5.1 关键文件和目录的权限与 immutable 保护先处理一批高风险文件。我的加固清单是这样的/etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config权限和属主必须严格属主 root权限 644 或 600。尤其是/etc/shadow必须 600。关键二进制文件/usr/bin/passwd、/usr/bin/sudo、/bin/su等用rpm -V或dpkg -V定期校验完整性。日志文件目录/var/log/secure、/var/log/messages设置chattr a只允许追加不允许删除和修改。chattr a是个非常实用的招它防止入侵者清空审计日志。虽然专业攻击者会先尝试lsattr然后想办法去掉这个属性但至少能挡住 90% 的脚本小子。chattr i我一般只用在/etc/ssh/sshd_config这类配置文件上防止有人偷偷篡改后重启服务。要改配置时先chattr -i改完再加回去。对关键目录比如/tmp、/var/tmp挂载时要加上nosuid,noexec选项防止攻击者把提权工具扔到临时目录里执行。改/etc/fstab后要重新挂载验证不要重启后再发现挂载失败。5.2 内核参数sysctl 加固清单及理由sysctl 这部分最容易出问题网上抄来的参数不能直接套每一个都要理解它在当前内核版本上的意义。我在生产环境稳定使用的核心项如下内核参数推荐值作用net.ipv4.tcp_syncookies1开启 SYN Cookie缓解 SYN Floodnet.ipv4.conf.all.rp_filter1开启反向路径过滤防止 IP 欺骗net.ipv4.conf.default.accept_source_route0关闭 IP 源路由防止路由欺骗攻击net.ipv4.conf.all.accept_redirects0不接收 ICMP 重定向包net.ipv4.icmp_echo_ignore_broadcasts1忽略广播 ping防止 Smurf 攻击kernel.randomize_va_space2开启 ASLR增加内存攻击难度kernel.dmesg_restrict1非 root 用户不能读取内核日志防止敏感信息泄露kernel.kptr_restrict2隐藏内核符号地址修改方式写在/etc/sysctl.d/99-hardening.conf然后sysctl --system生效。需要注意tcp_syncookies遇到高并发场景可能会影响性能rp_filter在多线接入和不对称路由环境会误杀合法流量。所以参数要分批次上每批上线后看业务错误率而不是一次全怼上去。5.3 SELinux / AppArmor 的启用与排错方法首选选项是 SELinux对 Red Hat 系是标配Ubuntu/Debian 系一般用 AppArmor。很多人嫌 SELinux 烦是因为它一开始会大量拦截业务行为报错信息又不直观。我的处理思路是分三步先确认业务进程的服务类型和文件上下文。比如 Nginx 读了它不该读的目录先用audit2allow -a看拒绝记录判断是业务设计问题还是上下文标注问题。用restorecon -Rv修复文件上下文而不是直接把SELinuxdisabled写死。90% 的报错是因为新加的文件没有恢复到正确的httpd_sys_content_t等类型。如果实在遇到和业务强冲突的策略用setsebool或者编写自定义策略模块把特定动作放行不做全局关闭。以下这些布尔值在 Web 架构里经常需要调整配置前一定确认业务场景setsebool -P httpd_can_network_connect 1 setsebool -P httpd_can_network_connect_db 1 setsebool -P httpd_execmem 0 # 保持关闭防止 Web 进程执行内存代码再用一个简单的习惯SELinux 开启前记录/var/log/audit/audit.log的行数开启后对比增量排除高峰期的误报。6. 让入侵者无处遁形审计与完整性校验权限策略做得再好也不可能 100% 防住所有攻击。安全体系的最后一块拼图是检测与溯源你未必拦得住他进来但一定要让他进来后留下痕迹并且让你在最短时间内发现。6.1 auditd 规则设计与日志的远程集中auditd是 Linux 自带的审计框架很多人的配置是默认的默认只记录部分认证事件远远不够。我会在/etc/audit/rules.d/hardening.rules里加这么一组规则-w /etc/passwd -p wa -k identity_file -w /etc/shadow -p wa -k identity_file -w /etc/sudoers -p wa -k sudoers_changes -w /var/log/secure -p wa -k logfile_changes -a always,exit -F archb64 -S execve -F uid0 -k root_exec -a always,exit -F archb64 -S openat -F dir/home -F a20x2 -k user_home_open_write前几行是文件监控-k给规则打标签execve规则会把 root 执行的每一个命令都记录到审计日志里。这两条规则合起来等于给入侵者拿到 root 后的一举一动都装了监控。审计日志最好实时发送到远程日志服务器我用 rsyslog 的 imfile 模块读取 audit.log 转发或者直接装 auditd 的 remote logging 插件。没有远程日志的话攻击者清掉本地日志整个流程就白做了。6.2 文件完整性监控从 AIDE 到运行时校验文件完整性是发现被改过什么的关键。AIDEAdvanced Intrusion Detection Environment是我的首选它基于基线数据库对比文件哈希和权限。初始化很简单aideinit mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz然后定义要监控的目录。默认配置监控面太大生产环境会把数据目录、日志目录全部纳入导致每天大量误报。我习惯只监控系统关键目录数据目录不纳入完整性监控而是用数据库自身机制来校验。在/etc/aide.conf里改成类似/etc static /bin static /usr/bin static /opt/custom static !/opt/custom/data/.* !/var/log/.*\.log$static表示同时检查权限、属主、大小、哈希生成基线后每晚跑一次任何二进制被替换都能在早晨的巡检报告里看到。校验命令aide --check | grep -E ^(Summary|New file|Removed file)更进阶的做法是运行时校验用 Osquery 或者其他工具检测进程的可执行文件路径是否在预期目录、加载了哪些动态库、监听了哪些端口。每次出现异常立刻对审计日志和完整基线做对比判断是正常发版还是被恶意篡改。6.3 安全事件排查的常见路径最后说下真的出事时我的排查习惯。把时间线拉长从这几个入口查先看认证日志grep -E Failed|Accepted /var/log/secure找出可疑的登录记录。再审计 root 执行ausearch -k root_exec -ts today恢复root 在这个时间段内执行了什么命令。找异常计划任务重点检查/etc/crontab、/var/spool/cron/、/etc/cron.d/攻击者最喜欢把反弹 shell 藏在定时任务里。检查 SSH 公钥逐行确认authorized_keys里的每一条公钥都是本人持有。检查系统服务systemctl list-unit-files | grep enabled把可疑的 service 找出来并定位对应文件。这套路径是经过验证的大多数入侵者在清理痕迹时只顾日志很少第一时间把 cron、公钥和 systemd 服务文件清理干净。只要你平时建立了干净基线排查速度会快很多。7. 加固之后的事补丁、基线检查与可持续运营很多团队做完一轮加固就以为完事了三个月后配置漂移得一塌糊涂等于白做。安全加固不是一次性工程而是一个持续运营的过程。我这里分享几个我认为最重要的长效机制。7.1 CVE 跟踪与补丁灰度发布补丁管理是持续性安全的关键。漏洞扫描器报出来一堆高危你不能不修也不能一股脑全修。我的做法是对线上系统做 CVE 数据源跟进关注官方安全通告而不是等扫描器报。按风险的三个维度排序是否可远程利用、是否存在于公网组件、业务影响面多大。可远程利用 公网组件最优先当天或当天夜里就补。补丁强制走灰度先在测试环境验证再推一台非核心生产机观察 24 小时最后批量推全量。内核补丁记得留回滚窗口万一业务异常需要grub2-set-default回退到旧内核。7.2 基线检查与自动化巡检脚本配置漂移防不胜防最好的办法是配置管理工具或脚本固化基线。我习惯把加固项写成检查脚本定时跑结果推送到监控系统。检查项至少包括sshd_config 关键项是否与基线一致防火墙默认 zone 是否仍是 drop是否出现新的监听端口是否存在新的 uid 0 用户AIDE 昨夜校验是否有异常关键进程是否还处于 SELinux 的正确上下文脚本输出是一个简单的 JSON监控系统拿到后根据历史数据判断变化。对偏离基线的机器自动打开审批流程而不是直接改掉——避免脚本自动变更误伤业务。7.3 加固误伤业务时的回滚预案这一节专门写给上过生产的人。无论你的策略多严谨总有意外情况。最常见的几个防火墙规则写错管理端口被拒连不上服务器。回滚方案是带外管理KVM/IPMI或者云平台 VNC 登录后手动放行。PAM 配置错误所有 SSHD 会话被锁。我自己的坑改了pam_faillock重启 sshd 后自己也被锁还好有另一个带外通道能进去改回来。SELinux 策略导致应用大面积 503。可以执行setenforce 0先临时降级再处理策略问题不要慌着重启。所以做每一项变更前我都会确认我这台机器的回滚手段是什么并记录在变更单里。没有回滚方案的变更宁可不做。这是我在生产环境里用无数次血的教训换来的本能。在自己把几百台服务器全部收编成这种状态之后我最真实的体会是安全不是买一堆工具而是把系统设计得默认失败希望渺茫。层层设防步步留痕让攻击者的每一步尝试成本都成倍增加。最后分享一个我坚持多年的小习惯每次加固完都会主动从攻击者视角走一遍自己的机器试着用踩点、爆破、提权、清痕这几个步骤去挑战自己的防线然后根据暴露出来的问题继续修正。这套方法不复杂只要坚持做比你买任何昂贵的安全产品都有用。