Docker Compose部署的Nginx遇未知请求，内存激增是否遭入侵？

这大概率是自动化爬虫/黑客扫描行为，结合你的描述，已经处于攻击前的探测阶段，甚至可能存在部分未授权访问的风险，具体判断依据和应对方案如下：

判断依据 #

• 非业务端点的批量请求：针对PHP、phpMyAdmin这类常见漏洞入口的请求，是黑客扫描工具的典型操作，目的是寻找服务器上的薄弱点（比如未关闭的默认管理后台、遗留的测试脚本）。
• 部分请求返回200状态码：如果这些请求的路径并非你业务部署的内容，却返回200，要警惕两种情况——要么Nginx配置有疏漏（比如默认站点未关闭、路由转发错误），导致恶意请求被错误响应；要么服务器/容器已经被植入了恶意文件（比如后门脚本）。
• 内存消耗大幅上升：大量扫描请求会占用服务器的网络、CPU和内存资源；如果同时存在后台挖矿程序或恶意进程，也会导致内存飙升，这是攻击后常见的资源占用表现。
• Django日志中的404请求：说明扫描请求已经穿透到后端服务，虽然被Django拦截，但也暴露了你的后端服务路径/端口已被扫描到。

紧急排查与应对步骤 #

1. 立即排查当前风险 #

• 检查Nginx返回200的非业务请求对应的文件：登录服务器或进入Nginx容器，查看请求路径对应的目录（比如挂载的静态资源目录），确认是否有陌生的PHP文件、phpMyAdmin目录，若有立即删除。
• 检查容器资源占用：执行docker stats查看每个容器的CPU、内存使用率，找出异常占用的容器；进入可疑容器后用top或ps aux查看是否有陌生进程。
• 检查数据库日志：查看PostgreSQL容器的日志，确认是否有异常登录尝试或未授权的数据库访问行为。

2. 加固Nginx配置 #

• 关闭默认站点：删除或注释Nginx默认的default.conf，确保只有你的业务站点配置生效。
• 拦截非业务路径请求：在Nginx配置中添加规则，直接拦截所有针对非业务路径的请求：

  location ~* (phpmyadmin|php|admin|test|backup) {
      return 444; # 直接关闭连接，不返回响应
  }
  

• 添加请求限流：防止批量扫描占用资源：

  limit_req_zone $binary_remote_addr zone=scan_limit:10m rate=10r/s;
  server {
      ...
      limit_req zone=scan_limit burst=20 nodelay;
  }
  

• 隐藏服务版本：在nginx.conf中添加server_tokens off;，避免暴露Nginx版本信息给攻击者。

3. 后端服务加固 #

• Django端：确保CSRF防护开启，给后台管理路径设置IP白名单（仅允许信任IP访问/admin），使用强密码验证。
• Docker容器：避免以root用户运行容器，在docker-compose.yml中添加资源配额限制，防止单个容器耗尽服务器资源：

  services:
    django:
      deploy:
        resources:
          limits:
            cpus: '0.5'
            memory: 512M
  

4. 后续监控 #

• 定期检查Nginx和Django日志，用grep排查异常请求（比如包含phpmyadmin、php的请求）。
• 配置服务器内存、CPU告警，一旦出现异常占用立即排查。

内容的提问来源于stack exchange，提问作者Elabbasy00