在哪里找到Nginx和Apache访问日志

在哪里找到Nginx和Apache访问日志

SOC Prime Team
SOC Prime Team linkedin icon 关注

在 Debian 和 Ubuntu 上,Nginx 的日志记录在 /var/log/nginx/access.log 和 error.log,Apache 的日志记录在 /var/log/apache2/access.log 和 error.log。在 RHEL、Rocky 和 Alma 上,Apache 使用 /var/log/httpd/access_log 和 error_log,使用下划线且无扩展名。在从官方 Nginx 镜像构建的容器中,根本没有日志文件:所有内容都输出到 stdout 和 stderr,因此 docker logs 是你的导出工具。

Web 服务器日志通常是入侵留下痕迹的第一个地方:扫描仪扫描 .env 文件,漏洞利用字符串,对不应存在的文件执行的 POST。Prime Core 具有 812 条针对 Web 服务器日志的检测规则,映射到 337 种 MITRE ATT&CK 技术。其中包括:对面向公众的应用程序的利用(T1190)、Web Shell(T1505.003)和漏洞扫描(T1595.002)。

免费开始

在您开始之前

找到真实的路径。 虚拟主机通常会在自定义位置记录。询问服务器本身:

# Nginx: 导出完整有效配置并挑选日志指令

sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'


# Apache

sudo apachectl -S

sudo grep -Ri -E 'CustomLog|ErrorLog' /etc/apache2/ /etc/httpd/ 2>/dev/null

在基于 Debian 的 Apache 上,没有自己的 CustomLog 的虚拟主机最终会记录在 other_vhosts_access.log 中。人们总是会漏掉这个。

检查你记录的是谁的 IP。 在负载均衡器、CDN 或反向代理之后,每个请求都可能显示为来自代理。除非服务器设置为记录真实客户端:在 Nginx 中的 set_real_ip_from 和 real_ip_header,在 Apache 中的 mod_remoteip。如果每一行都显示相同的几个内部 IP,攻击者的地址仅在 X-Forwarded-For 中,如果您记录它,或者在代理自己的日志中。

检查格式。 两个服务器默认使用“combined”格式,但许多设置会进行自定义(Nginx 中的 log_format,Apache 中的 LogFormat)。上传之前注意你的格式。

权限。 在 Debian 和 Ubuntu 这些日志仅 root 和 adm 组可读;其他地方需要计划使用 sudo。

从日志文件导出

日志每日日志或周日志轮换,因此包含旋转文件。zcat -f 可同时读取普通和压缩文件:

# Nginx,当前和旋转,最旧先

sudo zcat -f $(ls -tr /var/log/nginx/access.log*) > web-03_nginx_access.log



# RHEL 上的 Apache

sudo zcat -f $(ls -tr /var/log/httpd/access_log*) > web-03_httpd_access.lo

对于单日,组合格式的时间戳使 grep 就足够:

grep '19/Oct/2026' web-03_nginx_access.log > web-03_access_1019.log

也将错误日志导出。上游故障、PHP 错误和一些漏洞利用企图只会在那里显示。

从容器导出

# Docker: stdout 是访问日志,stderr 是错误日志

docker logs --since 2026-10-19T00:00:00 --until 2026-10-20T00:00:00 nginx > nginx_access.log 2> nginx_error.log


# Kubernetes

kubectl logs deploy/nginx --since=24h > nginx.log

除非有东西收集它们,否则容器日志会随容器一起消失。如果 pod 被替换,检查你的集群的日志收集器。

寻找什么

模式通常意味着什么
对 /.env、/.git/config、/wp-login.php、/phpmyadmin 的 404 爆发自动扫描
../, ${jndi:, union select, <script> 在 URL 中漏洞利用企图:遍历、Log4Shell、SQL 注入、XSS
对上传目录下奇怪文件的 POST 返回 200可能的 Web Shell;看看该 IP 还请求了什么
用户代理如 sqlmap、nikto、nuclei没有隐藏的工具
在奇怪请求之后的 5xx 峰值出错了,可能因为已经有利用攻击

上传、清理并在 LogTotal 中审查

  1. 上传。 打开 logtotal.com 并将文件拖放到其中。
  2. 清理。 [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
  3. 审查。

当出现问题时

症状可能的原因Fix
没有 /var/log/nginx自定义路径,或它在容器中运行nginx -T,或 docker logs
access.log 存在但为空日志记录到 stdout,或 access_log 被关闭检查配置和容器
每个请求都来自相同的 IP前面有代理或负载均衡器;真实 IP 未配置使用 X-Forwarded-For 或代理的日志
只有最后几天旋转文件被遗漏使用带* glob的 zcat -f 命令
权限被拒绝不是 root,不在 adm 中sudo

FAQ

哪个更重要,访问日志还是错误日志?

访问日志告诉你请求了什么。错误日志告诉你哪里出错了。在利用攻击情况下,你需要两个都了解,一起查看。

IIS 怎么办?

IIS 默认将 W3C 日志写入 C:inetpublogsLogFiles。那需要另一个指南。

加入 SOC Prime 的 Detection as Code 平台 以提高对与您的业务最相关的威胁的可见性。为了帮助您开始并带来即时价值,现在与 SOC Prime 专家预约会议。