Splunk 实现 Nginx 日志审计的关键是字段精准、路径清晰、响应迅速；需通过 JSON 格式日志结构化上下文，按风险分流存储，Splunk 端语义对齐，并用 SPL 快速识别探测、越权、慢请求等真实威胁。
用 Splunk 实现企业级 Nginx 日志审计，关键不在“装得全”，而在“字段准、路径清、响应快”。核心是让每条日志自带上下文：谁来的、干了什么、系统怎么判的、结果是否异常——这些信息必须结构化、可过滤、能联动。
一、日志源头：用 JSON 格式打牢审计基础
Nginx 默认的 combined 日志无法支撑细粒度安全分析。必须自定义 log_format，输出合法 JSON，并注入审计必需字段：
- 真实客户端 IP 必须用
$realip_remote_addr（配合set_real_ip_from和real_ip_header），不能只依赖$remote_addr - 敏感行为要打标，例如用
map指令标记管理路径：map "$request_method:$uri" $is_admin { ~^(GET|POST):/admin/|/api/v1/(users|roles) 1; default 0; } - 关键变量按类型规范输出：字符串字段（如
"uri"、"http_user_agent"）加双引号；数字字段（如status、request_time）不加引号 - 必含
$http_x_forwarded_for——这是 SIEM 追溯真实攻击源的唯一依据 - 启用
$request_id（需加载ngx_http_request_id_module或使用 OpenResty），支撑跨服务调用链还原
示例格式：
access_log /var/log/nginx/access.json json;
二、日志分流：按风险等级分离存储
把高危流量从海量普通请求中剥离出来，避免审计被噪音淹没：
- 管理后台单独落盘：
location ^~ /admin/ { access_log /var/log/nginx/admin.log json if=$is_admin; } - 认证失败（401）、拒绝访问（403）、后端异常（502/504）分别写入独立文件，便于快速定位策略生效情况
- 对扫描特征 UA（如 sqlmap、nmap）自动标记并隔离：
map $http_user_agent $is_scanner { ~*(sqlmap|nmap|dirbuster) "yes"; default ""; }，再配合log_if $is_scanner = "yes" - 所有审计日志文件权限设为
640，属主nginx:audit，限制非授权读取
三、Splunk 端：精准接入与语义对齐
Splunk 不是“扔进日志就能查”，必须匹配其解析逻辑：
- 若用 JSON 日志，直接配置 Monitor 监控
/var/log/nginx/*.json，Source Type 设为json，Splunk 会自动提取字段 - 若沿用文本日志（不推荐），必须严格对齐 Splunk 内置的
nginx:access源类型默认正则，否则status、clientip等字段为空 - 在 Splunk 中为关键字段设置别名和提取规则，例如将
clientip映射为src_ip，is_admin转为布尔型，方便后续 SPL 查询 - 建立索引时启用
INDEXED_EXTRACTIONS = json并关闭自动字段提取（KV_MODE = none），防止误解析
四、审计实战：用 SPL 快速发现真实威胁
日常巡检不需要复杂仪表盘，几条高效 SPL 就能暴露问题：
- 高频探测 IP（1 分钟内 404 ≥ 50 次）：
index=nginx status=404 | bucket _time span=1m | stats count by clientip,_time | where count >= 50 - 横向越权尝试（非 admin 用户访问 admin 接口但状态成功）：
index=nginx is_admin=1 status=200 NOT user="admin*" | table clientip,uri,user,_time - 慢请求+高响应体（疑似数据泄露或资源耗尽）：
index=nginx request_time>5 bytes_sent>1000000 | sort - request_time | head 20 - 关联分析：把
request_id作为枢纽，串联 Nginx 日志 + 应用日志 + 数据库慢查询日志，还原完整攻击链
