<p>Lynis 扫描内核安全需 root 权限，聚焦 kernel-hardening、kernel-modules、kernel-tuning 三类配置；关键看 [SUGGESTION] 条目对应合规条款，修复后比对 JSON 报告中 KRNL-* 条目 status 是否变为 "ok"。</p>
直接用 Lynis 扫描内核安全，关键不是“能不能”，而是“怎么扫才准、怎么读才对”。它不测漏洞利用，而是查你有没有按安全标准配好内核参数、模块和运行时行为——这才是合规审计和加固落地的核心。
确保扫描权限和环境基础
普通用户能跑 Lynis，但内核级检查几乎全部依赖 root 权限。没加 sudo 就执行，你会看到大量类似 Warning: Skipping test [KRNL-5789] (requires root) 的提示，报告里内核相关项基本为空。
- 必须用 sudo lynis audit system 启动，否则 sysctl 设置、/proc/config、加载模块、kptr_restrict 等全不可见
- 确认基础工具就位：bash ≥ 3.2、awk、sed、sysctl、lsmod、zcat（用于读取 /proc/config.gz）
- ArchWSL 或其他 WSL 环境也适用，但注意 WSL2 内核由 Windows 管理，部分参数（如 kernel.kptr_restrict）可能无法修改，Lynis 会如实标出“not writable”
聚焦内核相关测试组与关键参数
Lynis 把内核检查分散在多个测试 ID 组里，不是靠关键词搜索，而是靠分组逻辑定位。日常重点关注以下三类：
- kernel-hardening：ASLR（kernel.randomize_va_space）、ptrace 限制（kernel.yama.ptrace_scope）、符号隐藏（kernel.kptr_restrict）、core dump 控制（fs.suid_dumpable）
- kernel-modules：检查是否加载了高风险模块（如 ip_tables 而非 nftables）、有无可疑第三方模块、是否禁用未签名模块加载（CONFIG_MODULE_SIG）
- kernel-tuning：网络层防护（net.ipv4.tcp_syncookies、net.ipv4.conf.all.accept_redirects）、内存映射保护（vm.mmap_min_addr）、IPv6 路由通告控制（net.ipv6.conf.all.accept_ra）
执行时可单独触发： sudo lynis audit system --tests-from-group kernel-hardening
从报告中识别真实加固缺口
别只盯 [WARNING]，内核安全得分主要看 [SUGGESTION] 条目——它们对应 CIS、PCI DSS 等标准的具体条款编号（如 [KRNL-6320]），是合规评估的计分依据。
- 例如报告出现 [SUGGESTION] Enable kernel address space layout randomization (ASLR) — current: 0，说明 kernel.randomize_va_space=0，必须设为 2
- 遇到 [SUGGESTION] Restrict access to kernel symbols — current: 0，就该立即执行 sudo sysctl -w kernel.kptr_restrict=2 并写入 /etc/sysctl.conf
- 若提示 [WARNING] Kernel config not found (/boot/config-$(uname -r) or /proc/config.gz)，说明内核未启用 CONFIG_IKCONFIG_PROC，Lynis 就没法验证编译期安全选项（如 CONFIG_HARDENED_USERCOPY）
生成可追溯的加固证据
生产环境做一次扫描，不能只看终端输出。要留档、比对、闭环：
- 加 --json --report-file /var/log/lynis-kernel-$(date +%F).json 输出结构化报告，方便脚本解析或导入 SIEM
- 用 --pentest 模式（纯读取，不发包、不写临时文件）保证扫描过程本身不扰动生产状态
- 修复后重扫，对比两次 JSON 中 "test_results" 下 KRNL-* 类条目的 status 变化，status 从 "warning" 或 "suggestion" 变为 "ok" 才算真正闭环
