做这一步时，sudo lynis audit system --enable-tests "kernel,boot" 这条命令一定不能省。原因很直接：不把内核和引导检查打开，/proc/sys/ 和 GRUB 参数就不会被读取，结果就是一大批内核相关项目直接显示 NOT SCORED。如果用的是旧版本，还得额外加上 --no-network；而首次评估时，建议不要启用 --quick。另外，真正需要着手修复的，重点看 [SUGGESTION] 条目就行。
怎么用 Lynis 启用 kernel 和 boot 模块做基线扫描
默认 lynis audit system 不读 /proc/sys/ 和 GRUB 参数，大量内核项显示 NOT SCORED——这不是没漏洞，是根本没扫。必须加 --enable-tests "kernel,boot" 才能触发真实检测。
实操要点：
- 务必用
sudo运行，否则/proc/sys/kernel/kptr_restrict这类路径不可读 - 旧版 Lynis（≤3.0.5）建议加
--no-network，避免卡在 NTP 时间校验 - 首次基线评估禁用
--quick，它跳过 30%+ 的深度检查项 - 扫描输出里带
[SUGGESTION]的条目，才是真要改的配置点，别被 WARNING 带偏
怎么根据 Lynis 测试 ID 定位并修复权限类漏洞
Lynis 报告里的 ACCT-9628、FILE-6310 这类编号不是随机码，是最新可查的加固锚点。直接搜测试 ID，比读英文描述快得多，也更准。
常见操作路径：
ACCT-9628（空密码账户）：用sudo awk -F: '$2 == "" {print $1}' /etc/shadow列出，再sudo passwd -l username锁定FILE-6310（/tmp挂载缺noexec,nosuid,nodev）：检查mount | grep /tmp，若缺失，追加到/etc/fstab对应行末尾，再sudo mount -o remount /tmp- 所有修改后必须验证：比如改完
/etc/fstab要跑sudo findmnt -t tmpfs /tmp确认参数生效
怎么让 nmap --script vuln 真正跑出可用结果
nmap -sV --script vuln 不是“一键报 CVE”，它依赖本地 NSE 脚本库是否完整、服务版本识别是否准确。很多用户扫完只看到一堆 [vuln] 却没法判断真假，问题常出在脚本或目标识别上。
关键控制点：
- 先运行
sudo nmap --script-updatedb，否则http-shellshock.nse等脚本可能根本没加载 - 必须加
-sV，--script vuln本身不探测版本，没版本号就匹配不了漏洞规则 - 避免扫全端口：
nmap -sV -p 22,80,443,3306,6379 --script vuln target，减少误报和干扰 [vuln]输出只是特征匹配，比如smb-vuln-ms17-010出现，得再用rpcclient -U "" target手动验证 SMB 是否真开放
怎么写可靠的 OpenVAS（GVM）定时扫描脚本
直接把 gvm-cli start_task 往 crontab 里一塞，90% 会失败——不是命令错，是环境没加载、token 过期、或 gvmd 还没 ready。OpenVAS 的 cron 不是 Linux 那套逻辑。
能落地的写法：
- 先用
gvm-cli --gmp-username admin --gmp-password xxx list_tasks测试连通性，确认 token 有效 - 脚本开头加
sleep 15，等gvmd完全启动再执行任务 - 用
gvm-cli --gmp-username admin --gmp-password xxx start_task --task-id xxx触发，别用 web UI 自动生成的 UUID 命令 - 日志重定向到文件：
2>&1 >> /var/log/gvm-cron.log，否则失败时你根本看不到报错
真正麻烦的不是命令怎么写，而是每次 OpenVAS 升级后 GMP 接口可能微调，start_task 的参数顺序或字段名会变——得盯住 gvm-cli --help 输出，不能复用半年前的脚本。
