一、什么是基线扫描
基线扫描（Baseline Scanning）是信息安全领域中的一项基础工作，指的是将一台服务器（本文特指Linux物理机）当作体检对象，逐条对照预先定义好的"最低安全要求"进行核查，发现不符合项并给出修复建议的全过程。这些"最低安全要求"通常以政府法规、行业标准或国际规范的形式发布，如国内的等级保护2.0、关基、关保，以及国际的CIS Benchmark、NIST 800-53、DISA STIG等。基线扫描的核心目的在于"提前发现配置隐患、满足合规要求、降低安全事故概率"。
与漏洞扫描关注"代码缺陷"不同，基线扫描更关注"配置错误"。漏洞扫描侧重发现软件中存在的可被利用的漏洞（CVE、POC），而基线扫描则检查操作系统、中间件、数据库、容器等是否按照最佳实践进行了加固，例如SSH是否禁止root口令登录、审计日志是否开启、内核参数是否启用地址随机化等。两者互补，不可互相替代。
二、为什么要做基线扫描
1. 合规刚需
国内《网络安全法》配套标准GB/T 22239-2019（等保2.0）明确提出"安全计算环境"需满足42个控制点，涵盖身份鉴别、访问控制、安全审计、入侵防范、恶意代码防护等。
金融、电力、医疗等行业监管文件（如JR/T 0193、IEC 62443）要求每年至少完成一次基线核查并出具整改报告。
政企招标、SOC年审、ISO 27001认证、关基检查都把基线合规率作为硬性指标。
2. 责任免除
通过扫描留下"已尽职"证据链：报告、整改记录、复测截图可在事后溯源。
提前发现弱口令、幽灵账号、多余服务，有效缩短攻击面，降低被通报风险。
3. 经济收益
早期投入1小时扫描，可避免后期10小时应急抢修，减少业务中断和罚款损失。
统一基线后，运维自动化（Ansible/SaltStack）更容易落地，批量变更可回滚。
三、基线扫描查什么（四大维度）
1.系统层
- 内核参数：SYN Cookie、IP转发、ASLR、Core Dump限制
- SSH配置：Protocol 2、PermitRootLogin、MaxAuthTries、Banner
- 认证与授权：PAM密码复杂度、锁定策略、sudo权限精细化
- 防火墙：iptables/nftables默认策略、Loopback规则、管理口白名单
- 审计与日志：auditd规则、rsyslog远程发送、日志保存180天、权限640
- 强制访问控制：SELinux Enforcing、AppArmor Profile
2. 软件层
- 数据库：MySQL 删除test库、关闭local_infile、启用ssl；Redis绑定127.0.0.1、设置requirepass
- Web服务器：Nginx隐藏版本号、关闭server_tokens；Tomcat禁用manager/host-manager
- 容器平台：Docker daemon TLS、userns-remap、live-restore；kubelet启用--anonymous-auth=false
3. 账号层
- UID0非root账号、空口令/弱口令、长期90天未改密、离职幽灵账号
- 组权限：wheel组限制、sudoers文件写保护、.ssh目录700
4. 日志层
- 本地日志轮转logrotate、远程集中syslog、时间同步NTP/Chrony
- 文件完整性（AIDE、Wazuh FIM）开启，关键文件（/etc/passwd、/etc/sudoers）哈希监控
四、扫描方法论（七步闭环）
- 制定基线标准：选框架→划范围→定等级（高/中/低）
- 选择扫描工具：单机Lynis、合规OpenSCAP、批量Ansible、云安全中心
- 扫描前准备：低峰窗口、CPU/IO保护、全量备份、最小权限账号
- 执行扫描：命令行或控制台一键下发，输出原始日志
- 结果分析与风险定级：转CSV、映射合规条款、计算CVSS或CIS分值
- 修复与加固：自动remediate、Ansible playbook、手动特殊项
- 复测与持续监控：24h复测、高危清零、Git版本化、Wazuh/ossec持续监控、月度再扫
五、常见标准速览
国内
- GB/T 22239-2019 等保2.0：安全计算环境42控制点
- GB/T 25070-2019 关基：关键信息基础设施保护要求
- JR/T 0193-2020 金融：资金交易类系统加固指南
- IEC 62443-3-3 工业控制：电力、轨交、制造场景
国际
- CIS Benchmark（CentOS、Ubuntu、Docker、K8s分册）：最细最落地
- NIST SP 800-53 Rev5：18个控制族，框架型，供FedRAMP引用
- DISA STIG（Red Hat、MySQL、Windows）：军用/国企外包常见，条目最严苛
六、风险等级划分（三色法）
高危（红色）：立即整改，不超24小时
- 任何UID0非root账号
- 内核CVE>2025-10未打补丁
- SSH PermitRootLogin yes
中危（橙色）：限期7天
- 多余服务nfs-server、telnet.socket启用
- 审计规则缺失≥3条
低危（蓝色）：纳入月度变更
- 系统Banner未隐藏
- MOTD提示信息多余
七、工具图谱与适用场景
场景 |
推荐组合 |
特点 |
单机体检 |
Lynis + 自定义shell脚本 |
轻量、无Agent、生成HTML报告 |
合规对标 |
OpenSCAP + SCAP Security Guide |
官方XCCDF策略、支持--remediate自动修复、生成POAM报告 |
批量运维 |
Ansible + OpenSCAP / 自定义playbook |
并发上千台、先扫后修、回滚方便 |
云主机混合 |
华为云HSS、阿里云SCS、腾讯云T-Sec |
控制台一键下发、定时扫描、结果入事件中心 |
八、基线扫描 vs 漏洞扫描
- 基线扫描：检查"配置错误"，无CVE也能不合规；修复手段是改配置、关服务、加策略
- 漏洞扫描：检查"代码缺陷"，需打补丁或升级版本；输出是CVE编号、CVSS分值、可利用性
两者互补：同一台主机应先做基线扫描（0day也可能因加固而失效），再做漏洞扫描（发现必须打补丁的漏洞），最后统一出报告。
九、落地路线图（从理论到生产）
- 实验环境：选一台测试机，跑通Lynis与OpenSCAP，输出第一份报告
- 阅读官方文档：CIS Benchmark对应分册、等保2.0控制点清单
- 编写内部规范：把CIS/等保条目翻译成企业可执行checklist，标注自动/手动
- Ansible Playbook化：能自动修复的写成role，不能自动的写Manual Guide
- 小范围试点：开发环境→预生产→生产，灰度分批，保留回滚快照
- 持续监控：auditd + Wazuh，关键文件变更实时告警；日志转存ELK 180天
- 定期再扫：每月全量、季度对标新版CIS/等保、年度红蓝对抗验证
十、常见坑与技巧（实战速记）
- 误报处理：Lynis报"未安装iptables"失败，若实际使用nftables，可在custom.prf里加skip
- 性能限流：OpenSCAP单机会飙满CPU，使用nice -n 19 ionice -c3限流
- 容器场景：宿主机扫完还需对docker daemon、kubelet做CIS Docker/K8s Benchmark
- 多发行版差异：Debian/Ubuntu无/etc/sysconfig，sysctl规则拆到/etc/sysctl.d/*.conf
- 备份回滚：etckeeper自动提交/etc到Git，扫描前打LVM快照，remediate失败可秒回
基线扫描是Linux安全运维的"疫苗接种"，把"裸机"养成"合规机"的第一步。牢记"七步闭环"，先定标准再选工具，备份永远是第一；高危不过夜，中危七天毕；每月复测勤复盘，后续过等保、护网、ISO27001都能事半功倍。
