必须用--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 是无效的——它会卡在交互提示、不归档、无法跨天对比。真正可用的定时任务必须用 --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 记录；除非确认目标 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），这不是随机编号，而是官方测试项唯一标识，直接搜它才能看到原始检查逻辑和合规出处。
- 别靠关键词猜：
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。工具只是镜子，照出问题不等于解决问题。
