安全实践 · 安全与合规

待环境验证

Linux 主机安全基线检查清单

围绕 SSH 访问、监听端口、账号权限与安全更新开展 Linux 基线检查,形成可追踪的整改、验收和恢复记录。

Linux安全加固
阅读导引 · 理解后再操作

这篇知识解决什么问题

安全基线阅读的重点不是收集更多检查命令,而是解释每个访问入口由谁使用、为何需要、在哪一层受到限制。把配置现状、业务例外与整改授权分开记录,既识别暴露面,也避免因一次加固丢失管理通道或阻断必要依赖。

以有效策略而不是文件片段作判断

SSH 包含文件、条件匹配、主机防火墙和上游访问规则可能共同决定实际结果。应明确检查的账号、来源和入口,再核对对应的生效证据。某一文件写着禁止或某一端口只在本机监听,都不足以说明整条访问路径的授权边界已经符合要求。

检查结论必须带责任与适用条件

服务账号、管理端口和目录权限应映射业务用途,而不是统一套用最严格值。把符合、待整改、获批例外和不适用分别记录,例外关联到期时间与复核人。没有读权限或证据不足的项目不能填通过,扫描结果也只覆盖工具实际检查的范围。

进入文章正文
关联架构图解7 个组件 · 点击展开

参考图用于阅读资产范围、人工风险评审、受控变更和备用管理通道之间的关系;本篇停留在基线取证与判定,不执行图中的加固或封禁,也未展开完整网络边界及发行版补丁链路。

查看场景架构与实施步骤
参考架构 · 非实时拓扑

资产、受控变更与备用访问架构

将资产确认、人工风险判断、Ansible 变更和认证日志防护分开,保留独立恢复通道,使每项加固都有明确对象、证据和单项回退入口。

  • 数据 / 请求
  • 控制 / 管理
  • 观测 / 查询

点击组件,在图下方查看职责;连线编号对应流向解读。小屏可横向滚动,或直接展开文字说明。

资产、受控变更与备用访问架构:组件关系图将资产确认、人工风险判断、Ansible 变更和认证日志防护分开,保留独立恢复通道,使每项加固都有明确对象、证据和单项回退入口。 资产清单 → 基线与风险评审:明确检查对象;基线与风险评审 → Ansible 控制端:批准单项任务;Ansible 控制端 → Linux 目标主机:受控 SSH 变更;备用管理通道 → Linux 目标主机:验证恢复入口;Linux 目标主机 → 认证与审计日志:记录认证事件;Fail2ban → 认证与审计日志:读取失败证据;Fail2ban → Linux 目标主机:封禁与解除。箭头说明见下方流向解读。
逻辑参考图,节点代表建议职责而非已经部署的服务;加固策略需按发行版、业务依赖和安全准入逐项确认。

资产清单

数据 / 制品

使用批准的主机与分组清单;已部署且通过安全准入时,可选复用 InfraGuard 台账。InfraGuard 不承担本方案的内置基线扫描或自动整改。

查看关联工具
全部组件职责 7 个组件
资产清单
使用批准的主机与分组清单;已部署且通过安全准入时,可选复用 InfraGuard 台账。InfraGuard 不承担本方案的内置基线扫描或自动整改。工具介绍 资产清单
基线与风险评审
根据经审阅的检查项、实际系统证据及业务依赖形成整改清单,明确责任人、例外期限和恢复文件。
备用管理通道
在收紧 SSH、sudo 或网络前验证带外或第二管理路径,并保留当前会话直到新登录和业务回归通过。
Ansible 控制端
执行批准的独立配置任务,限定 inventory、批次和提权范围;检查模式结果仍需真实单机试点确认。工具介绍 Ansible 控制端
Linux 目标主机
承载已核对的业务服务和管理策略。变更按单项生效与回归,不把补丁、认证和防火墙一次性全量扩散。
Fail2ban
使用经测试的过滤器读取认证失败证据,通过所配动作限制来源;不是身份认证、边界防火墙或补丁治理的替代。工具介绍 Fail2ban
认证与审计日志
按实际发行版确认 journal 或文件后端,限制读取权限并监控留存空间,输出脱敏后用于风险复检。
流向解读 7 条连接
  1. 1

    资产清单 基线与风险评审

    控制 / 管理 · 明确检查对象

    资产范围用于限定检查对象,资产存在或 SSH 可执行并不自动代表安全检查通过。

  2. 2

    基线与风险评审 Ansible 控制端

    控制 / 管理 · 批准单项任务

    仅将已评审差异、恢复点和停止条件转为执行任务。

  3. 3

    Ansible 控制端 Linux 目标主机

    控制 / 管理 · 受控 SSH 变更

    通过授权管理身份应用配置,先试点再依批次验收结果推进。

  4. 4

    备用管理通道 Linux 目标主机

    控制 / 管理 · 验证恢复入口

    管理入口用于发生误锁定时恢复具体配置,不意味着可绕过组织访问控制。

  5. 5

    Linux 目标主机 认证与审计日志

    观测 / 查询 · 记录认证事件

    保存成功、拒绝与提权等事件,结合配置生效证据完成复检。

  6. 6

    Fail2ban 认证与审计日志

    观测 / 查询 · 读取失败证据

    Fail2ban 按实际日志后端匹配规则,应单独验证误命中和合法管理来源例外。

  7. 7

    Fail2ban Linux 目标主机

    控制 / 管理 · 封禁与解除

    调用配置的本机防护动作,观察封禁解除;错误规则只停用对应 jail,不批量清空防护。

故障域与操作边界

管理链路与业务链路不能一起失守

SSH 或防火墙错误可能阻断所有远程回退,备用路径必须提前实测;新会话验证前不关闭原会话。

防护命中不是完整安全证明

Fail2ban 只补充限制重复失败来源;漏洞判断还需发行版安全公告、包信息和业务风险,不能只比较版本字符串或基线分数。

批次失败只回退受影响项

不同发行版、账号依赖和业务角色是独立变更边界。停止后续批次,按主机与配置恢复,不用全量覆盖掩盖单点失败。

架构依据与版本核对 3 篇官方资料

图解是本站基于官方资料整理的逻辑参考;实施前仍需核对实际部署版本、组件支持范围与变更审批。

适用范围与前提

用于 Linux 服务器上线、例行巡检与安全加固前的基线核对。以下命令以使用 systemd、OpenSSH 和 firewalld 的 RHEL 类系统为例;其他发行版应先核对服务名与配置机制。需要获准的读取权限、资产清单及可用的应急登录路径。本文是检查参考,未对任何主机作出合规认证或安全验收结论。

账号、权限与归属

从资产负责人提供的账号清单开始,核对交互账号、服务账号、授权期限与 sudo 范围。关注无人负责的长期账号、多人共用身份和超出岗位需要的提权能力。检查关键目录的属主与权限时,依据服务用途和软件要求判定,不能以一个统一权限值覆盖所有路径。输出中包含身份信息时,按最小范围保存与共享,不复制密码散列或私钥。

远程登录与应急入口

核对 OpenSSH 的最终有效配置,而不仅检查主配置文件,因为包含文件及条件匹配可能改变结果。下面命令检查语法和默认有效配置;带有 Match 规则的环境还应使用相应连接条件检查实际结果。

sudo sshd -t
sudo sshd -T
systemctl status sshd --no-pager

核对管理入口是否限制到需要的来源、密钥是否归属明确、直接特权登录是否符合组织规范。调整认证方式前,先用独立会话验证目标管理员能够登录并提权,同时确认控制台或带外访问可用。不要在唯一远程连接中连续收紧认证与网络策略。

监听端口与防火墙

将监听地址和端口逐项映射到业务服务、负责人和允许访问范围,特别关注监听所有接口的管理端口。以下为只读检查;主机没有 firewalld 时,应检查实际采用的 nftables、云安全组等控制层。

ss -lntup
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all-zones
systemctl list-units --type=service --state=running --no-pager

结合真实入站路径核对主机规则和上游规则,不因某一层显示关闭便认定端口不可达。对不明服务先确认进程用途、依赖与启动来源,再进入变更流程。

补丁、强制访问控制与审计

记录系统版本、补丁来源、维护窗口及需要重启的组件。补丁检查应区分“可用更新”和“已安装且已生效”。核对 SELinux 的当前模式与异常拒绝记录,由具体策略和应用需求解释问题,避免将关闭保护机制作为默认修复。检查 auditd 状态、审计日志可用空间、轮转和集中留存链路;审计记录帮助追溯行为,但不能替代访问控制。

验收与证据格式

为每项检查保存主机、时间、实际值、期望值、判定依据和责任人。结果分为符合、待整改、已批准例外和不适用,例外必须包含原因及到期时间。加固后至少验证管理登录、业务入口、服务依赖、监控采集和审计写入均正常,再关闭整改项。扫描工具的通过结果仅覆盖其配置与规则范围,仍需核对人工确认的业务例外。

停止与回退条件

如果发现未知特权账号、疑似被篡改的文件或持续异常登录,先保存证据并按事件处理流程升级,不把巡检直接变成批量清理。调整后出现登录失败、业务连接中断或审计无法写入时,停止后续主机变更,使用已准备的入口恢复对应配置版本。回退应针对实际改动项并再次验证,避免临时放开所有端口造成新的暴露。

参考资料

从现象到判断

先收集证据,再缩小范围。以下是判读路径,不代表已经确认根因或获准变更。

  1. 文档要求限制的登录方式仍出现成功事件,或不同管理员对同一主机得到不同结果,主配置文件却看不出差别。

    只读核对
    读取获准的 SSH 有效配置与相关条件规则,结合指定时间的认证事件,核对账号、来源、服务版本及配置路径。
    如何判读
    差异可能来自条件匹配、配置未生效或不同入口;必须先解释访问条件,不能仅凭文件内容认定策略已执行。
  2. 发现没有明确负责人的监听端口,或者资产清单未登记的后台服务,现有防火墙检查结论又互相矛盾。

    只读核对
    只读关联监听地址、端口、进程、服务单元和资产归属,查看实际采用的主机及上游规则,不扩大网络扫描范围。
    如何判读
    监听意味着本机存在服务入口,不等于公网可达;记录已知路径与未知边界,交由服务负责人确认必要性和范围。
  3. 加固工单显示已完成,但安全更新、审计留存或账号期限仍缺少生效证据,检查工具的汇总分数却显示正常。

    只读核对
    读取软件包及运行版本、审计服务和留存状态、例外到期清单,并与本次变更对象和批准的检查标准逐项对照。
    如何判读
    安装、运行生效和持续留存是不同结果;无法取得对应证据的项保持待复核,不从总体分数推导所有风险已关闭。
常见误区与判断边界 2 项

把可登录误当作应急路径独立

两个终端若都依赖同一 SSH 配置、同一账号和同一网络规则,并不形成独立恢复能力。备用路径还需要清楚的责任、授权及可用记录。本篇可核对现有验证材料,但不能因为保留了一个终端窗口便批准同时收紧全部访问层。

审计日志不能替代访问控制

能记录登录和提权有助于追溯,但不能阻止过度授权,也不能据日志暂时安静推断没有风险。若发现不明特权身份或疑似篡改,应保全证据并进入事件响应;批量删除账号、清理日志或关闭防护都超出基线只读检查范围。

交接时应留下的证据

作为记录提纲使用,不是自动检查结果;未取得的证据应标记缺口,并注明负责人。

  • 记录主机资产编号、系统发行版、角色、负责人和检查身份,列明基线版本及本次实际获得的读取范围与限制。
  • 为每个管理入口保存账号和来源条件、有效策略及脱敏认证证据,注明主机规则之外尚需哪一方确认网络边界。
  • 将端口、进程、服务和业务用途关联成清单,为未知项分配负责人,保存已批准例外的依据、到期日及复核状态。
  • 按检查项登记实际值、预期值、生效证据与未验证内容,补充备用管理通道的既有验证记录和整改授权边界。

记录需包含环境、版本、时间与时区;分享前脱敏,不附访问令牌、密码或完整业务敏感数据。

继续阅读与资料核对

补充相关主题,再结合当前环境的实施记录形成结论。

返回原理导读

DOUYA OPS ECOSYSTEM

贡献你的经验,帮助更多运维人

把故障复盘、标准流程和最佳实践沉淀为可检索、可复用的知识内容。