这一步一定不能省：执行时应使用 --cronjob 模式，并将日志清晰写入带日期的归档路径，例如：sudo lynis --cronjob --log-file /var/log/lynis/lynis_$(date +%Y%m%d).log。真正写入 crontab 时，必须采用绝对路径，同时补上 2>/dev/null；此外，历史日志也不能长期堆积，还需要结合 logrotate 或 find 定期清理。
怎么用 Lynis 配置每日自动基线扫描并保留可比报告
如果只是直接写 cron 去执行 sudo lynis audit system，基本是不可用的——它会停在交互提示、不会自动归档，也无法做跨日期的安全基线对比。真正适合 Linux 定时安全扫描的方式，必须使用 --cronjob 模式，并手动指定日志输出路径。
sudo lynis --cronjob --log-file /var/log/lynis/lynis_$(date +%Y%m%d).log：这是用于生成带日期后缀归档日志的标准命令，--cronjob会自动跳过颜色输出、关闭交互提示，并禁用网络校验，更适合定时任务场景- 写入 crontab 时必须使用绝对路径：
15 3 * * * root /usr/bin/lynis --cronjob --log-file /var/log/lynis/lynis_$(date +%Y%m%d).log 2>/dev/null，否则 cron 可能找不到可执行文件，或因环境变量缺失导致任务失败 - 旧日志不会自动删除，必须配合
logrotate，或者额外加一行：find /var/log/lynis -name "lynis_*.log" -mtime +7 -delete，否则时间一长磁盘空间迟早会被日志占满
nmap --script vuln 扫描前必须确认的三件事
nmap -sV --script vuln 看上去很直接，但在实际做漏洞扫描时，经常会出现报错、漏检或结果不完整的问题。根本原因通常不在命令本身，而在于本地脚本库是否完整、目标主机的响应策略，以及扫描参数的搭配是否合理。
- 先执行
sudo nmap --script-updatedb：很多 CVE 漏洞检测脚本（例如smb-vuln-ms17-010）依赖/usr/share/nmap/scripts/目录下的 .nse 文件，缺失时会被直接跳过，既不报错也不明显提示 - 不要随意对生产服务器使用
-Pn：-Pn会跳过主机发现，强制向所有 IP 发包，容易触发防火墙限速，或被 IDS/IPS 记录；除非已确认目标完全禁用 ICMP，否则建议默认先用-sn进行存活探测 [vuln]标记并不等于已经成功利用：它只表示目标响应特征匹配某个 POC 指纹，例如返回特定 HTTP header 或 SMB negotiate response，真实风险仍需结合服务版本进行人工核实（查询 CVE 数据库并在本地复现）
OpenVAS/GVM 定时任务不能直写 cron 的根本原因
在 crontab 中直接写 gvm-cli start_task --task-id xxx 几乎都会失败，问题并不在命令语法，而是由 GVM 的架构机制决定的——gvmd 和 ospd-openvas 属于分离进程，而且认证依赖 session token 与 socket 连接状态。
- 必须先验证连通性：
gvm-cli --gmp-username admin --gmp-password xxx list_tasks，只有执行成功，才说明 gvmd 已经就绪、认证凭据有效，并且 socket 连接可用 - crontab 中要增加延时：
sleep 10 && gvm-cli --gmp-username admin --gmp-password xxx start_task --task-id xxx，否则在 cron 刚触发时，gvmd 可能尚未完全加载完成 - 更稳定的方案通常是放弃直接写 cron，改为在 Web 界面中配置 recurring schedule：GVM 内部通过
gvm-manage-certs和gvm-feed-sync自动维护 token 与 feed 更新，相比 shell 脚本方式更可靠
修复建议里带测试 ID（如 ACCT-9628）时该怎么查准依据
Lynis 报告中的 [SUGGESTION] 后面，经常会跟着一串字母数字编号（如 ACCT-9628）。这并不是随机值，而是对应最新测试项的唯一标识。想准确定位修复依据，最有效的方法就是直接搜索这个测试 ID，查看原始检查逻辑与合规来源。
- 不要只靠关键词猜测：
grep -r "ACCT-9628" /usr/local/lynis/include/可以直接定位到具体 test 文件，里面会明确说明检查条件（例如是否通过passwd -l锁定空密码账户）以及对应的 CIS 合规条款 - 修复前先核实现状：
sudo awk -F: '$2 == "" {print $1}' /etc/shadow可以真实列出空密码用户，避免误删系统账户（如nobody或某些服务账户） - 涉及权限或挂载项的修改必须配合
ls -ld /tmp和mount | grep /tmp双重检查：当 Lynis 报出FILE-6310（/tmp未挂载noexec）时，需要进一步确认究竟是 fstab 配置缺失，还是 mount 选项没有实际生效
真正到了落地执行阶段，最容易被忽略的往往不是“有没有扫描出漏洞”，而是日志归档是否持续一致、修复验证是否形成闭环。扫描报告里确实会堆满大量 [SUGGESTION]，但现实是，很少有人会定期对比 /var/log/lynis/lynis_20260701.log 和 lynis_20260708.log，确认同一项到底有没有从 WARNING 变成 OK；也很少有人会手动执行一次 sysctl kernel.kptr_restrict，确认参数值是否真的已经改成了 2。归根结底，安全扫描工具只是镜子，能够把系统问题照出来，并不代表这些安全问题已经真正被修复。
