很多 JavaScript 应用跑在 Ubuntu 上时，真正能留下攻击痕迹的，往往不是单次扫描结果，而是系统、认证、Web 服务和应用本身持续写下的日志。要把这些信息变成可用的审计线索，关键不在“看了多少日志”，而在于日志是否记录到位、筛查是否有重点、异常是否能被持续追踪，下面就按这个顺序梳理一套更适合日常落地的方法。
先把关键日志补齐，避免审计时只看到半截线索
日志审计的前提不是工具，而是记录粒度足够完整。若系统或应用只留下模糊的错误信息，后续再强的分析平台也很难还原真实行为。因此，先确认 Ubuntu 主机、认证链路、Web 服务和 Node.js 应用都在持续输出可用日志。
Ubuntu 系统侧至少要关注这三类日志
/var/log/syslog：记录系统级事件，适合追踪服务重启、进程异常退出和整体运行状态变化。/var/log/auth.log：用于查看登录失败、sudo操作和其他认证行为，是排查暴力破解和越权操作的第一入口。/var/log/kern.log：保存内核相关日志，适合补充定位更底层的异常行为。
应用与 Web 服务日志不能只记“报错”
如果目标是审计 JavaScript 应用，单靠系统日志远远不够。Node.js 应用最好使用 winston、morgan 这类日志库，把请求、错误、异常和关键业务动作记录下来。对于 Apache 或 Nginx，也应开启访问日志与错误日志；如果条件允许，还应尽量保留请求体和参数信息，否则很多注入与探测行为只会留下不完整的痕迹。
日志量一大，优先用工具和命令做筛查
原始日志文件一旦积累起来，人工逐行翻阅几乎不可行。这时需要根据场景选择合适工具：要么上完整分析链路，要么先用命令行工具快速缩小范围。
适合持续分析的平台型工具
- ELK Stack（Elasticsearch, Logstash, Kibana）：适合把日志集中采集、检索和可视化，便于实时监控和持续追踪。
- Splunk：检索和报表能力更强，适合日志规模更大、审计流程更规范的企业环境。
适合快速定位问题的命令行工具
并不是所有场景都需要复杂平台。很多时候，grep、awk、sed 就足以完成第一次排查，尤其适合从大批文本日志中快速提取关键字、异常字段和可疑模式。对于临时审计、应急分析或规则验证，这类工具往往更直接。
重点检查三类高频安全信号
日志审计最怕“什么都看”，结果什么都抓不住。更有效的方式，是围绕几类最常见的攻击痕迹建立筛查重点：未授权访问、注入攻击和跨站脚本行为通常都能在日志里留下明显线索。
未授权访问：先看认证失败，再看接口访问模式
- 检查
/var/log/auth.log中是否存在连续失败登录、异常时间段认证请求，或来自陌生 IP 的高频尝试。 - 同时回看应用日志，重点关注敏感接口的高频访问、异常参数组合和不符合正常用户行为的请求节奏。
注入攻击：从危险关键字和模式入手
SQL 注入、命令注入等攻击通常会在日志中留下可识别的字符串，例如 SELECT、DROP、; rm -rf。这些痕迹未必意味着攻击已经成功，但往往代表有人正在探测或尝试利用漏洞。实际审计时，可以用正则表达式或关键字检索先做第一轮筛选。
grep -r "SELECT" /var/log/apache2/access.log
grep -r "DROP TABLE" /var/log/mysql/error.logXSS：留意被编码后的脚本片段
- 检查 Web 服务器日志中是否出现编码后的