网站被恶意扫描怎么办？AI Agent 从访问日志识别敏感路径扫描

VPS 只要一暴露 IP，恶意扫描立马就到。主机选经常收到站长反馈，说网站后台被暴力破解，或者奇怪的后缀名请求刷爆带宽。其实这些大多是自动化脚本在“广撒网”。与其手动盯着 Nginx 访问日志一行行查，不如教一个 AI Agent 帮你盯着。本文带你实战用 AI 分析 Nginx 日志，自动识别敏感路径扫描，并结合 Docker 实现自动化防御。

Nginx 日志规范与恶意扫描特征

在让 AI 接手之前，得先把“饲料”准备好。Nginx 默认日志格式可能不够详细，我们需要确保能提取出攻击者的 IP、请求路径、User-Agent 和状态码。

检查日志格式与常见攻击路径

先看下你的 Nginx 配置，通常在 `/etc/nginx/nginx.conf` 或 `vhost` 配置文件里。我们需要确认 `log_format` 包含了 `$request` 和 `$status`。

cat /etc/nginx/nginx.conf | grep log_format

常见的敏感路径扫描特征非常明显，比如请求 `/wp-login.php`、`/admin`、`/phpmyadmin`、`/.env`、`/config.php` 等。这些请求通常会返回 404（页面不存在）或 405（方法不允许），但同一个 IP 会在短时间内发起大量此类请求。传统的正则匹配能解决一部分，但攻击者变种太多，AI 擅长处理这种模糊语义的判断。

编写 AI Agent 分析脚本

我们要构建一个简单的 AI Agent，它的任务是读取 Nginx 日志片段，判断是否存在敏感路径探测行为，并输出恶意 IP。这里用 Python 配合大模型 API（如 OpenAI 或 DeepSeek）来实现。

调用大模型 API 识别攻击意图

创建一个 `analyze_log.py`。脚本逻辑是：先截取最近 1 分钟的日志，用正则粗筛出包含敏感关键词的行，然后扔给 AI 让它做最终裁决。

python
import re
import os
from openai import OpenAI

client = OpenAI(
api_key="你的_API_KEY",
base_url="https://api.deepseek.com" # 替换为你用的模型地址
)

def extract_suspicious_logs(log_file):
patterns = [r'admin', r'wp-login', r'\.env', r'config', r'sql', r'phpmyadmin']
suspicious_lines = []
try:
with open(log_file, 'r', encoding='utf-8', errors='ignore') as f:
for line in f:
if any(p in line.lower() for p in patterns):
suspicious_lines.append(line.strip())
except FileNotFoundError:
return []
return suspicious_lines[-50:] # 只取最近50行分析

def ask_agent_to_ban(logs):
if not logs:
return []

prompt = f"""
你是一个安全运维专家。以下是 Nginx 访问日志片段，请分析是否存在恶意扫描行为。
如果某个 IP 频繁访问敏感路径（如后台、数据库配置文件、非公开接口），请判定为恶意。
只返回需要封禁的 IP 列表，用逗号分隔，不要输出其他内容。

日志内容：
{chr(10).join(logs)}
"""

try:
response = client.chat.completions.create(
model="deepseek-chat", # 指定模型
messages=[
{"role": "system", "content": "你是一个严厉的防火墙安全助手。"},
{"role": "user", "content": prompt}
],
temperature=0
)
content = response.choices[0].message.content.strip()
return [ip.strip() for ip in content.split(',') if ip.strip()]
except Exception as e:
print(f"API 调用失败: {e}")
return []

if __name__ == "__main__":
log_path = "/var/log/nginx/access.log"
logs = extract_suspicious_logs(log_path)
bad_ips = ask_agent_to_ban(logs)
print("建议封禁的 IP:", bad_ips)

Docker 容器化运行环境

为了保证环境隔离，我们将这个脚本打包进 Docker。

创建 `Dockerfile`：

dockerfile
FROM python:3.9-slim

WORKDIR /app

RUN pip install openai

COPY analyze_log.py .

VOLUME ["/var/log/nginx"]

CMD python -c "import time; import os; exec(open('analyze_log.py').read())"

构建镜像：

docker build -t log-agent .

运行容器（注意要把宿主机的日志目录挂载进去，并赋予读取权限，通常涉及处理 `journalctl` 或调整 `rsyslog`，这里假设直接读取文件）：

docker run -d \
–name security-agent \
-v /var/log/nginx:/var/log/nginx:ro \
-e API_KEY="你的_API_KEY" \
log-agent

自动化防御与封禁策略

AI 分析出了 IP，如果不联动防火墙，那只是纸上谈兵。我们需要拿到 AI 输出的 IP 列表，直接喂给 iptables 或 fail2ban。

脚本联动 iptables 自动封禁

修改 Python 脚本，在拿到 `bad_ips` 后，执行系统命令封禁。因为容器内权限有限，通常建议在宿主机运行脚本，或者给容器极高的特权（不推荐）。更稳妥的方式是脚本运行在宿主机，仅用 Docker 管理环境依赖。

在 Python 脚本末尾追加封禁逻辑：

python
def ban_ip(ip_list):
for ip in ip_list:
check_cmd = f"iptables -C INPUT -s {ip} -j DROP"
ban_cmd = f"iptables -A INPUT -s {ip} -j DROP"

print(f"执行封禁: {ban_cmd}")

ban_ip(bad_ips)

配置 Cron 定时巡检

不要让脚本 24 小时死循环跑，既浪费 API 配额也没必要。用 Cron 每隔 10 分钟检查一次即可。

编辑 crontab：

crontab -e

添加一行：

*/10 * * * * /usr/bin/python3 /root/analyze_log.py >> /var/log/security_agent.log 2>&1

这样，AI Agent 就会每隔 10 分钟醒过来，看看最近有没有人在乱翻你的网站，有就一脚踢出去。

老鸟叮嘱

1.API Key 别泄露：脚本里硬编码 Key 是大忌，一定要用环境变量 `os.environ.get('API_KEY')`，并且把配置文件权限设为 `600`。
2.别误杀爬虫：AI 有时候会“杀红了眼”。在 Prompt 里要强调“排除百度、谷歌等知名爬虫 UA”，或者在封禁前先检查 IP 的归属地，如果是国内大厂的机房 IP，先观察别急着封。
3.日志轮转要小心：Nginx 日志默认会轮转（rotate），脚本读取文件时要记得处理文件被截断的情况，或者每次只读取最新的 N 行。
4.Token 消耗：别把几万行日志直接塞给 LLM，钱包受不了。一定要用正则做“粗筛”，只把“看起来像坏蛋”的记录发给 AI 做“精审”。

FAQ

Q1：AI Agent 分析日志会不会很慢，影响防御实时性？
A：会有延迟。对于高频攻击，建议先配合传统的 Fail2ban 做第一层拦截，AI Agent 作为第二层分析复杂变种和生成报告。

Q2：能不能用本地模型（如 Ollama）代替 API？
A：完全可以。只要修改 `base_url` 和 `model` 参数指向你的 Ollama 服务即可，适合不想泄露日志数据的场景，但对服务器内存要求较高。

Q3：Nginx 日志权限问题怎么解决？
A：普通用户通常无法读取 `/var/log/nginx/access.log`。可以建立一个日志管道，或者将日志复制到一个普通用户可读的目录，再给 Agent 分析。

Q4：如果 AI 误封了正常用户 IP 怎么办？
A：保留一份手动解封的脚本 `unban.sh`，里面写 `iptables -D INPUT -s IP -j DROP`。同时查看 Agent 的运行日志，优化 Prompt，告诉 AI 这种行为不算攻击。

通过这套组合拳，你的 VPS 就不再是只会被动挨打的靶子，而是多了一个带脑子的小保安。主机选建议大家在测试环境先跑通流程，再应用到生产服务器。