Linux服务器安全加固实战：从基线核查到SSH加固与验收闭环

简介面向信息安全工程师、等保建设与运维人员这份网络安全加固服务方案以信息系统脆弱性分析及修补为主线适用于安全服务项目规划、投标方案编写和加固实施。方案将安全加固拆解为可独立交付的服务项章节既可单独用于某一类设备加固也能组合成完整的安全解决方案内容源自工作实践替换关键词即可复用。资源包内为1个docx文件整体99KB文档从安全加固概述、补丁与弱口令等概念、服务必要性、客户收益到实施标准、服务原则、加固范围与具体加固内容均有完整呈现。目前已有145人学习下载。不同于泛泛模板方案覆盖网络设备、主机操作系统、数据库及常见中间件等对象并参照等保与相关国标可作为撰写安全服务方案时的直接素材或结构骨架。1. 一份docx能签下来的加固服务靠的不是漏扫报告而是边界和节奏做过一次才知道网络安全加固服务这个事儿交付物看着是一份 docx实际上它是甲乙双方之间的“合同级界面”。漏扫报告只能说明系统哪儿有洞而加固服务方案要回答的是——按什么标准改、改到什么程度算完、改坏了谁负责、怎么证明改过。没把这四句话说清楚再好的技术动作也落不了地后续验收和回款全是扯皮。这份 docx 的读者是带着具体诉求来的甲方安全负责人要看覆盖面和合规依据乙方项目经理要看工时和变更窗口一线工程师要看基线模板和命令。所以整篇方案的核心不是堆漏洞列表而是把“安全加固”从一次漫无目的的修补变成一条可执行、可复核、可回退的流水线。新手照着能走完第一轮基线加固熟手能在这个框架里塞进自己的脚本和参数集。2. 基线核查先行选对模板、定好参数再做加固才有底2.1 为什么必须先从基线核查开始而不是直接漏扫很多人拿到加固项目第一反应是跑一遍漏洞扫描然后照着漏洞列表逐个打补丁。这个思路在少量服务器上勉强能用一旦资产超过几十台就会发现扫描器报的“高危”里有大量误报和重复信息真正需要人工判断的配置类问题反而没被覆盖。安全加固的本质是把系统从“能跑”推到“符合某种安全预期”而这个预期必须是可描述的——描述它的东西就是安全基线。安全基线本质上是一组配置项的判定标准比如口令策略、账号权限、服务暴露面、审计日志、文件权限、内核参数。它解决的是“凭什么这么改”的问题。没有基线加固就变成个人经验发挥换一个人结果完全不同验收也没法量化。常见的基线来源有三个层次等保测评要求、CIS Benchmark、厂商安全规范。等保是合规底线CIS 是业界通用最佳实践厂商规范最贴合具体产品但覆盖范围窄。我的习惯做法是外部合规项目以等保二级或三级要求为主基线内部自查项目以 CIS Benchmark 为主基线两侧交叉的地方取严格值。基线模板选定之后下一步是把它落成一张可勾选的核查表。不要直接用官网那份几百页的 PDF 到现场翻效率太低。我会把核查项拆成五类身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范。每一类里再按“核查项名称、检查方法、预期结果、风险等级”四列整理成表格。这样做的另一个好处是每个核查项天然对应一条加固命令或一个配置修改后续的执行和回归测试全部能追溯到这张表上。2.2 基线核查模板怎么搭五个域的核查项设计一个能直接开工的基线核查表至少覆盖下面五个域。以 Linux 服务器为例常见的核查项如下表核查域典型核查项预期结果风险等级身份鉴别口令最小长度、复杂度、有效期长度不小于8位包含两类以上字符有效期不大于90天高访问控制账号权限分配、sudoers、远程登录限制仅业务账号可登录root 禁止直接 SSH高安全审计syslog/auditd 状态、登录事件记录auditd 运行中日志异地留存中入侵防范开放端口清单、高危服务状态、内核参数仅业务端口开放危险服务已停用高恶意代码防范杀毒/EDR Agent 状态Agent 在线病毒库已更新中这个模板不是直接抄的需要根据服务器角色做裁剪。数据库服务器要额外关注监听地址和数据文件权限Web 服务器要重点查上传目录的执行权限容器节点要看 Docker daemon 的远程访问开关。我给每个核查项加了“适用资产”一列模板下发后每个资产先自动过滤掉不适用的项减少现场核查工作量。核查命令的写法也要固定下来。比如检查口令策略用cat /etc/pam.d/system-auth和cat /etc/login.defs检查登录限制用cat /etc/ssh/sshd_config。这些命令散落在不同文件里如果每次都临时敲结果记录就不一致。建议把核查项做成脚本或半自动化的采集工具一次性收集所有配置状态再拿采集结果和基线比对。手工核查只处理脚本覆盖不到的内容比如应用配置里不能全局改动的部分。2.3 基线核查前必须安排的三件准备工作基线核查不是拿个脚本上去跑就完事前面有大量准备工作不做核查结果是不准的。第一需要一份更新的资产清单包括 IP、主机名、操作系统版本、运行角色、责任人。没有这份清单核查范围就是一笔糊涂账。第二需要对核心业务服务器做快照备份或配置备份核查脚本本身不会改配置但任何扫描性操作都有触发问题的可能这个后悔药必须先备好。第三要跟业务方确认变更窗口——核查不需要停业务但后续加固操作需要核查阶段就得把加固的窗口期一起敲定。这期间有一件容易忽略的事基线核查不只是看配置还要看流量侧的实际开放端口。用ss -lntp看监听端口和防火墙策略对比经常能发现防火墙策略放通了但服务根本没监听或者服务监听了但防火墙策略没放行。这类差异在核查表里要单独标记因为这些不是配置加固能解决的需要走网络变更流程。基线核查报告里把这些差异列出来实际上是在替后续工作划定责任边界。3. 加固实施五类动作账号、口令、服务、端口、日志的参数化配置3.1 账号与口令策略加固先定参数再动手避免业务账号被锁死账号与口令是加固的第一步也是现场最容易出事故的一步。口令策略改得过严业务方维护脚本里的明文密码直接失效账号锁定策略配置不当运维误操作三次就把自己关在门外。这条线要用参数化思维来做每个配置项先定推荐值和业务确认值再落到命令里。以下是 Linux 账号口令策略的一组推荐参数可直接作为基线蓝本配置项推荐值说明PASS_MAX_DAYS90口令最长有效期PASS_MIN_DAYS7口令最短修改间隔防止立即循环修改绕过PASS_MIN_LEN8口令最小长度PASS_WARN_AGE14过期前提醒天数口令复杂度至少包含大写、小写、数字、特殊字符中两类通过 pam_pwquality 配置账户锁定阈值连续失败5次锁定15分钟通过 pam_faillock 配置修改/etc/login.defs中的有效期参数后记得chage -l验证已有用户的实际策略。这里有个常见坑login.defs 只对新创建或下一次修改口令后的用户生效存量用户的密码有效期要用chage -M 90 用户名逐个落实。批量处理时我会写一个循环脚本读取/etc/shadow里所有普通用户逐个设置密码过期时间跳过 root 和 nologin 的用户。sudoers 的核查也放在这一阶段。生产环境建议把 sudo 权限收敛到最小范围能用普通用户加指定命令授权的不要直接给 ALL。改 sudoers 必须用visudo语法错了会直接导致 sudo 不可用别用普通编辑器改完再覆盖。3.2 SSH 与远程管理加固改端口、禁root、限来源三步设置远程管理的暴露面是所有服务器里最容易被打的点。SSH 加固的常规三步是禁用 root 直接登录、限制 SSH 监听来源、更换默认端口。直接给出我常用的一组监听与认证参数适用于内网生产环境参数设置说明Port2222 或 自定义高位端口减少自动化扫描命中率但需同步防火墙放行PermitRootLoginno禁止 root 直接 SSH管理员用普通账号 sudoPasswordAuthenticationno生产环境建议关闭改用密钥PubkeyAuthenticationyes启用公钥认证AllowUsers指定运维账号白名单之外的账号一律拒绝ClientAliveInterval / ClientAliveCountMax300 / 2自动断开闲置连接改 SSHD 配置前先执行sshd -t检查语法然后systemctl reload sshd而不是 restart这样已经建立的连接不会断。如果是通过 SSH 远程操作开启新配置后先不要关当前窗口另开一个终端验证新端口能登录确认没问题再关掉旧窗口这是 SSH 加固保命的操作习惯。公钥认证开启后还有一件配套工作清理~/.ssh/authorized_keys里的历史公钥。很多服务器跑了两三年里面躺着已经离职人员的公钥这等于给旧员工留了后门。批量巡检时把每个用户的 authorized_keys 拉出来人工核对一遍只保留当前运维团队的密钥。3.3 服务与端口收敛关掉用不上的才是最好的加固端口和服务是攻击面最直接的体现。服务器的端口收敛策略很简单默认全部拒绝按需放行。操作上有两个层次一是停用不必要的系统服务二是在防火墙层做白名单。服务清理环节按systemctl list-unit-files --typeservice拉出全部服务逐个确认保留或禁用。常见的可直接禁用项有telnet.socket、rlogin、rsh、sendmail企业环境邮件服务基本走专用设备、avahi-daemon。不确认的服务先查一下依赖关系systemctl list-dependencies 服务名能看出哪些东西关联着它。端口白名单放行时我习惯用 firewalld 或 iptables 完成规则构成是“默认DROP 显式ACCEPT”。比如一台业务服务器放行 80/443只允许运维网段访问 SSH 端口# 默认策略设为拒绝 iptables -P INPUT DROP iptables -P FORWARD DROP # 放行本地回环 iptables -A INPUT -i lo -j ACCEPT # 放行已建立的连接及相关连接 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 仅允许运维网段访问SSH(实际端口以你设置的为准) iptables -A INPUT -s 10.10.0.0/16 -p tcp --dport 2222 -j ACCEPT # 放行业务端口 iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT这段命令的逻辑是先把 INPUT 和 FORWARD 链默认策略改成 DROP实现白名单制然后依次放行回环、既有连接和指定来源的访问。注意放行顺序不能乱ESTABLISHED 规则必须放在 DROP 之前否则已经建立的连接会被自己防火墙掐断。iptables 规则用iptables-save /etc/sysconfig/iptables持久化CentOS 7 之后也可以直接用 firewalld 的 rich rule 实现同样的效果但 iptables 规则写起来更直观排查时用iptables -L -n --line-numbers看顺序也方便。3.4 审计与日志加固配置了不等于有记录记录不等于查得到审计这块是加固方案里最容易被忽视、也是验收时最容易返工的部分。要求就三条关键操作有记录、记录不会被篡改、记录真正发出去。Linux 上对应的是 auditd 和 rsyslog 的组合。auditd 的重点是给关键文件和敏感操作加监控规则。常用规则如下# 审计/etc/passwd、/etc/shadow等关键文件的写操作 auditctl -w /etc/passwd -p wa -k identity_file_changes auditctl -w /etc/shadow -p wa -k identity_file_changes auditctl -w /etc/sudoers -p wa -k sudoers_changes # 审计账号相关系统调用 auditctl -a always,exit -S execve -k process_execution规则里-w表示对特定文件做 watch-p wa表示监控写入和属性变化-k是给规则打标签方便后续用ausearch -k 标签检索。execve 的规则会产生大量日志适合在安全要求高的核心资产上开启普通办公服务器不建议全局加否则日志量会很快撑爆分区。auditd 规则通过/etc/audit/rules.d/audit.rules持久化用auditctl -D清空再-R载入是测试规则的高效办法。日志转发要确认 rsyslog 配置指向了日志服务器。/etc/rsyslog.conf里加一行*.* 10.0.0.8:514就能把全部日志转发到远端 syslog 服务端配合内网日志平台按天轮转和索引。验收时最快的方式是tail -f /var/log/messages看有没有转发错误。日志没到远端平台加固就是空转——事后追溯时本机日志被清掉谁也救不了你。4. 加固落地五个常见翻车现场现象、原因与处置流程4.1 SSH 参数改完所有运维终端都连不上服务器这个事故几乎每个干过加固的人都遇到过。现象ssh 配置修改后 reload 没报错但新开的终端连接全部超时或拒绝。原因分两类一类是防火墙没有放行新端口另一类是 PermitRootLogin 已改成 no而运维账号还没来得及配置公钥。后者更隐蔽因为 sshd 服务是正常的但认证方式的限制把所有人都挡在了外面。解决流程通过带外管理或云控制台登录把PermitRootLogin临时改回 yes用 root 登录后配置好至少一个运维账号的公钥再改回来。更稳的做法是改任何认证参数之前先确认有一个可直接登录的备用通道云上就是 VNC 控制台物理机就是 iLO/IDRAC。没有带外通道就开始加固 SSH就是在赌自己的手速。4.2 口令策略收紧后业务系统开始陆续报登录失败这种现象多出现在有大量自动化任务的系统。原因业务脚本或采集任务里写死了旧密码而账号密码有效期被强制改为 90 天后脚本不会主动感知密码策略变更一旦密码到期就直接重试。排查时先看业务日志里失败次数最多的是哪个账号确认是服务账号后对该账号单独配置例外策略或者走密码轮换流程。解决生产环境的密码策略不能一刀切要对服务账号做白名单管理单独设置长有效期密码并纳入密码保险箱定期轮换。血的教训就是加固策略上线前先盘点主机上的 cron 任务和 systemd timer凡是有硬编码密码的脚本全部列入改造计划。4.3 防火墙默认策略改成 DROP 之后业务访问出现大批量超时这个原因非常没有技术含量但发生频率极高。现象iptables 规则保存并重启后业务系统之间相互访问大面积超时。原因用了白名单制但放行规则不完整常见漏掉的三个跨网段的数据库访问端口、分布式服务的内部通信端口、健康检查来源的 IP。解决出现超时先不要急着清空规则用iptables -L -n --line-numbers和tcpdump对比业务端口找出实际被 DROP 的来源 IP 和端口补上 ACCEPT 规则。这类事故最好的预防是在变更窗口前拿防火墙规则和业务连接长时间段内的ss -tn输出做一次交叉比对把所有活跃链接的目的端口和来源 IP 都白名单化了再切。4.4 加固完成第二天服务器被对方的监控平台判定为失联现象加固后服务器本身运行正常业务也没有报障但监控平台开始大量告警。原因审计日志转发配置改动了 rsyslog或者防火墙把监控平台的采集端口给过滤了。这类问题排查时最忌讳上来就重启服务。解决先查防火墙规则里有没有放行监控网段再查 rsyslog 的状态最后确认 keepalived 或 agent 的通信端口没有被服务收敛策略误杀。我习惯在加固方案里加一列“监控采集例外端口”执行前先把这个清单和防火墙规则合并避免策略上线后监控失效导致出现真实安全事件时无人收到告警。4.5 服务禁用后依赖它的上层应用直接起不来现象按加固清单禁用了一批“多余服务”重启服务器后某个应用无法启动。原因没有做服务依赖分析禁用了某个看似无关的基础服务比如 messagebus、systemd-journald 或 ntp 相关的服务。解决禁用服务前用systemctl list-dependencies --reverse 服务名反向查看有哪些上层依赖再决定是否需要替代方案而不是直接 disable。常见的踩坑是这个看到chronyd觉得是时间同步服务顺手禁了结果分布式应用互相之间时间偏差过大直接报错。时间同步服务不属于可清理项这属于必须保留的底座能力。5. 复测与验收闭环把“做完了”变成“可验证”5.1 基线复扫与漏洞复核同一个工具、同一套标准做前后对比加固做完之后不能直接写验收报告要重新跑一遍基线核查。复测和首次核查使用同一套脚本和模板才能保证结果可对比。重点看三个状态之前不合规的项是否全部变成合规、新增了哪些例外项、有没有配置在加固过程中被改回来。复测报告只需要列出“增量差异”而不是把整份基线表再抄一遍——甲方关心的是那些字段从红色变成绿色关心的不是你已经做对了多少项。漏洞扫描的复扫同样强调工具一致性。首发漏扫和复扫隔了一个加固周期如果用不同扫描器结果对比会失真。扫描器之间对漏洞的检测规则和误报率差异很大混合使用容易把问题搅浑。我通常在复扫报告里附一张对照表左边是首发漏洞及风险等级右边是复扫结果和处置状态处置状态只留三种已修复、风险接受、修复中。把漏扫报告和加固基线表对应起来是验收汇报时最能说服甲方的东西。5.2 业务验证的三种方式功能、性能、权限三线并行加固的本质是改变了系统所以回归验证必不可少。业务验证按三条线并行推进——功能线、性能线、权限线。功能线最简单的做法是跑一遍核心业务的冒烟用例确认关键接口响应正常性能线观察加固前后 CPU、内存、磁盘IO的变化特别关注审计规则开启后有没有带来明显的日志写入压力权限线验证各类账号的访问边界运维账号能登录且权限符合预期越权访问被正确拒绝。下表是一个可直接套用的验收清单验证项方法通过标准业务接口调用核心接口或页面响应码 200耗时变化在 10% 以内系统资源观察 cpu/mem/io 15分钟无持续尖峰负载与加固前基本持平账号权限用普通账号执行 sudo -l仅返回被授权的命令列表远程登录从外部网络访问 SSH 新端口连接正常来源白名单外 IP 被拒绝审计日志触发一次登录失败查询 auditd5 分钟内在日志平台检索到对应事件权限线的验证最容易走形式因为很少有人真的去试那些“不该成功”的操作。但做得好的团队会针对每个加固项设计一个反向测试用例比如测试 root 禁止 SSH 到底是配置生效了还是只是改了文档。我会把反向测试结果单独记在验收文档里标注为“负向验证”这类内容在等保测评时非常加分。5.3 验收报告怎么写差距报告加整改记录加风险接受单验收环节最终交付的文档不止一份而是三件套加固差距报告、整改记录、风险接受单。差距报告是基线核查的最终版列出所有项的实际值和期望值整改记录是每一个加固操作的动作凭证包括执行人、时间、变更单号、具体操作内容风险接受单是不可修复项的正式归责文件。风险接受单是很多方案漏掉的部分。总有一些兼容性约束导致个别项无法加固比如老旧数据库版本必须使用弱加密协议才可以支撑存量客户端。这类问题技术上修不了但不能让它不了了之需要让甲方业务负责人签字确认已知风险并接受。这份文件的价值在于它把剩余风险从乙方转移到了甲方决策层后续出现安全问题时有明确的责任依据。一份加固服务方案能在验收阶段不扯皮的靠的往往就是这份清单做得足够干净。5.4 有条件的团队可以做一轮“攻击视角盲测”复测没问题不代表可以直接交付。如果是面向金融、政务这些安全要求高的客户我会建议在验收前做一轮攻击视角验证。可以借助内网搭建的模拟靶标也可以请专门的测试人员对加固后的系统做一次轻量级攻击测试重点验证边界防护是否真的挡住常见漏洞利用和暴力破解。现在不少 SRC 平台开放了企业侧的众测模式如果客户预算允许把加固后的系统挂到众测平台做一轮真实攻击验证得到的结果比内部验证更有说服力。盲测发现的问题往往会和基线核查不在一个维度上比如逻辑漏洞、越权接口、配置绕过。这个环节发现的问题如果能清零验收报告的分量就不一样了。资金不够的团队至少可以用开源扫描器和已知漏洞验证脚本做一轮自测能挡掉大部分低垂的果子。6. 让方案可交付的进阶技巧责任矩阵、时间表和变更窗口设计方案能不能顺利执行一半靠技术一半靠管理。这里说一个我做了四次加固项目才悟出来的技巧把加固动作按影响范围分成“可在业务时间执行”和“必须停机执行”两档然后为每个动作分配执行窗口、责任人和回退方式。一份可执行的加固方案本质上就是一张带权重的执行时间表。设计责任矩阵时最少要覆盖三个角色执行工程师、业务接口人、变更审批人。执行工程师负责在窗口内完成操作业务接口人负责确认业务影响和验证结果变更审批人负责判断动作是否放行。三个角色缺一个动作执行就会出现推诿。事件表格至少包含“操作内容、影响的业务或端口、执行窗口、预计耗时、回退方案、验证人”六列。有了这张表现场执行员完全不需要做临场决策按表操作即可。窗口设计上有一个实用原则账号口令类的加固可以先做因为影响相对可控且单台耗时短防火墙和服务收敛类的操作必须放在最后并且要预留回退时间。把所有高风险动作安排在变更窗口的黄金时间段前半小时做低风险动作、中间做高危动作、末尾半小时预留意外回退。别把所有改动堆到最后十分钟那时候出现误操作没有任何容错空间。还有一个容易被忽略的细节每次变更操作前把原有配置用 tar 包备份到独立目录并生成配置文件的校验和。# 备份配置文件并记录哈希便于回滚时校验是否被意外改动 tar czf /backup/config_before_hardening_$(date %Y%m%d).tar.gz \ /etc/ssh /etc/pam.d /etc/login.defs /etc/sudoers /etc/audit md5sum /etc/ssh/sshd_config /backup/sshd_config.md5这两行的逻辑很简单但价值很大tar 包确保了有一个一键恢复的现场md5 文件则用于回滚后确认配置文件完整还原。执行的工程师不需要记住所有改过的细节只需要知道回滚时从备份解压覆盖、重启服务就能恢复。我做过几十台服务器的批量加固翻车的时候靠的就是这套备份机制快速回到安全状态。回滚操作要写进方案里而不是留到出问题时在脑子里现想——出了问题再翻命令记录本身就是事故处理里最浪费时间的环节。最后一条是贯穿所有加固项目的底线加固方案不追求一步到位它追求的是每一步都可回退。你今天的方案永远做不到完美但能做到“出了事不影响业务、不背黑锅、有据可查”这套方法就能在下一个项目里继续用。希望这些参数表和操作习惯能帮到你把网络安全加固这份 docx 做成真正咬得动的硬骨头。本文还有配套的精品资源点击获取