最近不少運維和安全群在討論一種現(xiàn)象服務(wù)器訪問日志里突然出現(xiàn)大量 User-Agent 寫為 ClaudeBot、GPTBot 之類的請求但實際訪問路徑并不是頁面采集而是/.env、/.git/config、wp-login.php這類敏感文件探測。這不是官方 AI 爬蟲的正常行為而是有人故意偽造 AI Bot 的 User-Agent進行大規(guī)模漏洞掃描。偽造者利用 AI 爬蟲名稱看起來合法、近兩年又頻繁出現(xiàn)在日志里的特點把掃描流量混在正常 Bot 流量中。對運維和開發(fā)來說真正重要的是學(xué)會從 User-Agent 之外的信息確認請求身份并在日志、WAF、封禁策略三層完成識別、驗證和處置。如果你也在自己的 Nginx 或云安全產(chǎn)品里看到類似日志不要急著把所有 ClaudeBot 請求封掉也不要簡單放行。這篇文章會從攻擊者為什么這樣做開始再給出一套從日志到封禁的最小落地流程。1. 為什么有人要偽造 ClaudeBot 這類 AI Bot 的 User-Agent1.1 偽裝掃描日志到底長什么樣先看一段常見但很可疑的訪問日志203.0.113.7 - - [06/Feb/2025:03:11:22 0800] GET /.env HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.23 - - [06/Feb/2025:03:11:24 0800] GET /.git/config HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.24 - - [06/Feb/2025:03:11:27 0800] GET /wp-login.php HTTP/1.1 404 153 - Mozilla/5.0 (compatible; ClaudeBot/1.0)如果只看 User-Agent前幾行確實像某個 AI 爬蟲在正常抓取。但請求路徑暴露了問題/.env環(huán)境變量文件、/.git/config源碼倉庫配置、wp-login.phpWordPress 登錄入口這些都是漏洞掃描器最常探測的敏感路徑。攻擊者不在意返回 200 還是 404他們關(guān)心的是哪些路徑存在、哪些服務(wù)會響應(yīng)以及能否從響應(yīng)內(nèi)容中提取到價值信息。這類日志的特點是一條請求一個路徑來源 IP 可能分散UA 只在字面上“看起來像官方”但訪問規(guī)律和正常 AI 爬蟲完全不同。1.2 偽造 AI Bot 身份能帶來哪些好處攻擊者偽造 ClaudeBot 這類 AI 爬蟲名稱不是隨手寫的主要有幾個現(xiàn)實原因。第一個原因是繞過依賴 UA 的訪問控制。有些站點為了配合 AI 搜索收錄會在 Nginx 或 CDN 上專門放行ClaudeBot、GPTBot這類 UA有些團隊還會把它們加入白名單認為它們不會帶來威脅。攻擊者偽造這個 UA相當于直接借用了白名單身份。第二個原因是規(guī)避基于惡意 UA 的基礎(chǔ)封禁。像 sqlmap、Nikto、wpscan 這些掃描工具的 UA 特征非常明顯很多 IPS、WAF 有現(xiàn)成規(guī)則可以直接攔截。把 UA 改成 ClaudeBot 之后傳統(tǒng)規(guī)則失效流量更容易到達業(yè)務(wù)服務(wù)器。第三個原因是降低人工分析時的警惕性。安全告警每天會產(chǎn)生大量日志看到 ClaudeBot、GPTBot 這類名稱很多分析師第一反應(yīng)是“正常 AI 爬蟲”不會第一時間深入排查。攻擊者利用的正是這種思維慣性。1.3 User-Agent 是自述身份不能作為唯一依據(jù)需要注意HTTP 協(xié)議中的 User-Agent 是請求方自己聲明的“身份”客戶端可以隨意修改。用一行命令就能演示curl -A ClaudeBot/1.0 https://example.com/robots.txt服務(wù)器端收到這個請求后只能看到User-Agent: ClaudeBot/1.0無法判斷發(fā)請求的到底是 ClaudeBot 官方爬蟲還是某個掃描器?；谕瑯拥脑砉粽咄耆梢栽趻呙枘_本里偽造任意 UA。所以對 User-Agent 的正確態(tài)度是它只能作為第一層分流標識不能作為信任依據(jù)。真正要判斷一個流量是否可信必須組合來源 IP、請求行為、訪問頻率和路徑特征來判斷。2. 三層識別法從身份、來源、行為判斷真假2.1 第一層身份核對 UA 字符串本身雖然 UA 可以偽造但它仍然是第一道過濾條件。這里要做的是“精確匹配”而不是“模糊包含”。以 ClaudeBot 為例官方爬蟲的 UA 命名通常有固定格式一般形如ClaudeBot/1.0或Mozilla/5.0 (compatible; ClaudeBot/1.0; 官方說明頁)。如果日志里出現(xiàn)ClaudeBot/1.0后面還拼接了.net、.php、scanner、test等字符或者大小寫、空格明顯異常就需要懷疑是偽造樣本。更嚴謹?shù)淖龇ㄊ蔷S護一個“已知 AI Bot UA 樣本庫”。這個樣本庫包括三部分官方公開文檔中聲明的 UA 格式。線上訪問日志中確認為官方爬蟲的 UA。社區(qū)報告確認過存在偽造的 UA 變體。判斷原則很簡單字符串完全匹配可能有風險需要繼續(xù)看下一層字符串不匹配但行為像抓取器可能是普通爬蟲也可能是掃描器同樣要繼續(xù)看來源和行為。2.2 第二層來源IP 段、ASN 與反向 DNS來源驗證是識別偽造 AI Bot 最重要的手段。User-Agent 可以隨便改但正常情況下一個 TCP 連接必須有真實的源 IP攻擊者可以使用大量 IP 發(fā)起掃描但很難讓自己的一臺掃描機同時出現(xiàn)在正確的云廠商網(wǎng)段里。先看 IP 歸屬whois 203.0.113.7查詢結(jié)果會顯示 IP 所在網(wǎng)段、運營商和組織名稱。比如查詢到Organization: Example Cloud、CIDR: 203.0.113.0/24這時再看這個組織是否與官方 AI 爬蟲公開的網(wǎng)段一致。再看反向 DNSdig -x 203.0.113.7官方爬蟲的 IP 通常會配置反解反解域名會包含明顯標識比如某個爬蟲名稱或官方域名后綴。如果源 IP 反解結(jié)果為空或者反解域名是一串隨機數(shù)字甚至指向一個與 AI 爬蟲完全無關(guān)的 IDC 機房那么即使 UA 寫得再像官方也要提高警惕。這里的難點是官方 AI 爬蟲不一定會公開完整的 IP 清單部分云廠商 IP 還會動態(tài)變化。所以來源信息不能作為絕對判斷要結(jié)合行為一起看。2.3 第三層行為請求路徑、頻率和抓取順序正常 AI 爬蟲的工作方式通常有清晰的抓取順序先請求robots.txt再根據(jù) sitemap 或頁面里的鏈接去抓取頁面內(nèi)容請求的路徑大多是可訪問的業(yè)務(wù) URL頻率相對可控。漏洞掃描器不是這樣工作的。掃描器通常攜帶一份路徑字典按字典順序挨個發(fā)起請求比如/.env /.git/HEAD /.git/config /wp-login.php /wp-admin/ /api/v1/ /actuator/env /backup.sql它們不會先看 robots.txt也不會在意頁面結(jié)構(gòu)和鏈接關(guān)系只關(guān)心路徑是否存在、響應(yīng)狀態(tài)碼是什么、返回內(nèi)容里有沒有敏感信息。如果一個“ClaudeBot”在同一個 IP 下十秒內(nèi)連續(xù)請求這些路徑那基本可以確定不是官方 AI Bot而是偽造 UA 的掃描行為。還可以觀察請求頻率是否規(guī)律。正常抓取會有一定間隔掃描器為了趕時間常常高并發(fā)。如果同一個 UA 在凌晨兩三點對同一臺服務(wù)器發(fā)起幾百個不同路徑的請求而且大部分是 404攻擊的可能性很高。2.4 三層組合判斷不要只看單一條件維度正常 AI Bot 常見表現(xiàn)偽造 AI Bot 常見表現(xiàn)UA 匹配UA 與官方公開字符串一致格式穩(wěn)定UA 相似但夾雜異常字符或版本不一致來源 IP來自官方或合作云廠商網(wǎng)段可能有固定 ASN來源分散在多個 IDCASN 與官方聲明不一致反查 DNS反解域名包含可識別標識無反解或反解指向無關(guān)域名訪問路徑先請求 robots.txt再抓取業(yè)務(wù)鏈接直接路徑枚舉/.env、/.git/config等抓取頻率有間隔并發(fā)受控短時間高頻請求規(guī)律不明顯參考鏈接一般帶正常 Referer請求頭完整缺少 RefererHeader 不自然單條請求命中某一項不能說明什么比如正常業(yè)務(wù)方也可能偶爾訪問/.env路徑。但如果“UA 匹配 來源可疑 敏感路徑 高頻”這四件事同時出現(xiàn)基本可以進入攔截流程。3. 落地檢測從 Nginx 訪問日志找出可疑 Bot 流量3.1 先統(tǒng)一日志格式保證能取到關(guān)鍵字段在排查之前要確保 Nginx 訪問日志記錄了足夠信息。推薦使用包含客戶端 IP、時間、請求、狀態(tài)碼和 UA 的格式log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent; access_log /var/log/nginx/access.log main;如果業(yè)務(wù)部署在 CDN 或七層負載均衡后面$remote_addr可能是 CDN 節(jié)點 IP而不是真實客戶端 IP。這種情況要使用X-Forwarded-For或 CDN 平臺提供的真實客戶端 IP 變量但同時要注意這些 Header 可以被偽造。生產(chǎn)環(huán)境必須先驗證源站是否只信任來自 CDN 的請求避免攻擊者直接偽造 Header 繞過記錄。3.2 用 Python 腳本按特征聚合可疑請求先統(tǒng)計 UA 里出現(xiàn) ClaudeBot、GPTBot、Bytespider 等關(guān)鍵詞的 IP找出最活躍的來源from collections import Counter from pathlib import Path log_file Path(/var/log/nginx/access.log) fake_ua_keywords (ClaudeBot, GPTBot, Bytespider) sensitive_path (/.env, .git/config, wp-login.php, actuator, .bak, .sql) ip_counter Counter() sensitive_counter Counter() lines log_file.read_text(encodingutf-8, errorsignore).splitlines() for line in lines: if not any(keyword in line for keyword in fake_ua_keywords): continue fields line.split() if not fields: continue ip fields[0] ip_counter[ip] 1 if any(path in line for path in sensitive_path): sensitive_counter[ip] 1 print(出現(xiàn)偽造 AI UA 關(guān)鍵詞的 Top 20 IP) for ip, count in ip_counter.most_common(20): print(f{count:8d} {ip}) print(命中敏感路徑的 Top 20 IP) for ip, count in sensitive_counter.most_common(20): print(f{count:8d} {ip})這個腳本的思路是先篩選 UA再篩選路徑最后按 IP 聚合。實際生產(chǎn)環(huán)境不需要硬編碼在腳本里可以把日志接入 ELK、ClickHouse 或云原生日志服務(wù)用同樣的邏輯做可視化統(tǒng)計。這里要注意一個坑不要直接在整個日志文件上一次性過濾。生產(chǎn)環(huán)境日志量很大建議先tail -100000或按時間窗口切分日志再進行分析。3.3 時間維度瞬時突增是更可靠的信號IP 數(shù)量和路徑命中只是其中一個維度。偽造 UA 的掃描器往往會在短時間內(nèi)集中爆發(fā)所以把時間維度加進來判斷更準確。統(tǒng)計指定時間內(nèi)每分鐘請求量tail -100000 /var/log/nginx/access.log \ | grep ClaudeBot \ | cut -d[ -f2 | cut -d] -f1 | cut -d: -f1-3 \ | sort | uniq -c | sort -rn | head -20輸出結(jié)果類似147 06/Feb/2025:03:11 98 06/Feb/2025:03:12 12 06/Feb/2025:03:13如果同一個來源 IP 在某一分鐘內(nèi)連續(xù)產(chǎn)生幾十條到上百條請求而且請求路徑全是/.env、/.git/config、wp-login.php這類路徑說明這不是正常 AI Bot 的抓取節(jié)奏而是掃描器正在跑字典。時間窗口聚合的價值在于它能把“少量誤報”和“批量掃描”區(qū)分開。正常抓取也會請求多個路徑但不會在幾秒內(nèi)密集命中大量敏感路徑。建議把“單位時間內(nèi)同一個 IP 命中敏感路徑次數(shù)”作為告警條件而不是單純看 UA。這樣即使對方換個 UA 名稱只要行為仍然是掃描一樣能觸發(fā)。4. 自動處置從 Fail2ban 到 WAF 策略4.1 Fail2ban 攔截“敏感路徑 偽 AI UA”在單臺 Linux 服務(wù)器上快速落地時Fail2ban 是成本最低的方案。思路是在 Nginx 訪問日志中匹配特定 UA 和敏感路徑超過閾值后自動封禁源 IP。先創(chuàng)建過濾器比如/etc/fail2ban/filter.d/fake-ai-bot.conf[Definition] failregex ^HOST .*(?:GET|POST|HEAD) \/(?:\.env|\.git\/config|wp-login\.php|\.\.\/\.\.\/).* 404 .*ClaudeBot/1\.0$ ignoreregex 再在/etc/fail2ban/jail.local中啟用[fake-ai-bot] enabled true port http,https filter fake-ai-bot logpath /var/log/nginx/access.log findtime 60 maxretry 5 bantime 3600參數(shù)含義參數(shù)說明示例值findtime統(tǒng)計時間窗口單位秒60maxretry時間窗口內(nèi)匹配的最大次數(shù)5bantime封禁時長單位秒3600logpath日志文件路徑/var/log/nginx/access.log配置完成后先測試正則是否匹配真實日志fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/fake-ai-bot.conf這個工具會顯示匹配次數(shù)。如果正則不匹配需要檢查日志格式與正則中的字段順序。4.2 WAF 的挑戰(zhàn)與限流思路Fail2ban 適合單機和簡單場景但對于多節(jié)點、分布式掃描和 CDN 場景更推薦在 WAF 層處理。WAF 通常提供三種能力Bot 管理識別常見爬蟲和工具 UA并支持自定義 Bot 特征。JS Challenge對可疑請求下發(fā)一段 JavaScript 挑戰(zhàn)正常瀏覽器能通過大多數(shù)命令行掃描工具無法完成。速率限制按 IP、Session、UA 組合限流。實際策略不要直接對 ClaudeBot 返回 403而是先分級正常且可驗證的官方 AI Bot - 放行并限速 可疑 UA 但來源未知 - JS Challenge 或 429 疑似掃描 命中敏感路徑 - 403 或封禁這樣的好處是減少誤傷。有些站點希望被 AI 搜索索引如果把所有 ClaudeBot 都封掉可能會造成收錄異常。進入挑戰(zhàn)流程后官方 Bot 即使無法完成 JS 挑戰(zhàn)也有機會通過后續(xù) IP 驗證流程放行。4.3 封禁、觀察、復(fù)核的完整處理流程任何自動封禁都可能誤傷尤其涉及到 AI Bot 名稱時。建議按下面順序執(zhí)行自動發(fā)現(xiàn)日志或 WAF 識別到“UA 疑似 AI Bot 敏感路徑 高頻”。臨時限速先對該 IP 啟用較慢的限速策略而不是直接 403。人工復(fù)核查看 IP 歸屬、ASN、反向 DNS 和該 IP 的完整請求序列。確認封禁如果確認為掃描再封禁 IP 或 IP 段并設(shè)置合理時長。定期復(fù)查每天檢查被誤殺的請求調(diào)整規(guī)則。保留證據(jù)把原始日志、請求頭和響應(yīng)狀態(tài)保存下來便于后續(xù)調(diào)整規(guī)則。這里重點強調(diào)第六步。很多團隊封完就不管了后來才發(fā)現(xiàn)某個正常爬蟲 IP 被規(guī)則誤傷。保留日志和規(guī)則快照可以讓誤傷恢復(fù)變得可操作而不是只能靠“感覺”。5. 避免誤傷官方 AI Bot 和偽造掃描器怎么區(qū)分處理5.1 官方 AI Bot 通常會有哪些可驗證特征雖然不同 AI 爬蟲的實現(xiàn)細節(jié)不同但公開服務(wù)通常有相對穩(wěn)定的特征會遵守robots.txt并且很多官方文檔會說明爬蟲用途和聯(lián)系頁面。會使用固定 UA并且 UA 中可能包含官方說明頁地址。來源 IP 有較明確的云廠商或自有網(wǎng)段部分會公布 IP 范圍。抓取行為以采集頁面內(nèi)容為主不會高頻請求/.git、/.env這類路徑。官方 AI Bot 也不一定永遠表現(xiàn)完美比如某些海外云廠商的爬蟲會訪問不支持的地域、頻繁請求動態(tài)接口但這不能作為直接封禁理由。更好的做法是建立“正常樣本”和“可疑樣本”兩個隊列持續(xù)觀察。5.2 參考分級處理策略情況建議處理UA 匹配IP 歸屬正常訪問路徑正常放行并設(shè)置每秒請求數(shù)上限UA 匹配IP 歸屬未知但路徑正常臨時放行記錄日志并持續(xù)觀察UA 匹配IP 歸屬未知命中敏感路徑限速觀察后續(xù)行為UA 匹配IP 歸屬可疑高頻命中敏感路徑直接封禁至少封禁 24 小時UA 不匹配但行為與官方 AI Bot 一致按普通爬蟲處理不做特殊放行在生產(chǎn)環(huán)境里建議把“UA 匹配”和“行為匹配”分開記分而不是用布爾判斷。例如UA 匹配官方格式1 IP 歸屬在官方網(wǎng)段3 先請求 robots.txt2 命中敏感路徑-3 短時間高頻請求-2 缺少 Referer-1最終分越高越可信越低越可疑。這樣即使攻擊者不斷更換 UA只要行為特征不變分數(shù)依然會偏低。提醒最好不要在規(guī)則里寫死“只要 UA 等于 ClaudeBot 就放行”。AI 爬蟲名稱會不斷增加和變化要把判斷重點放在“來源和行為”上。6. 生產(chǎn)環(huán)境排錯與預(yù)防清單6.1 接到告警后的排查順序如果線上已經(jīng)出現(xiàn)大量偽造 AI Bot 掃描建議按下面的順序排查而不是先找封禁命令。第一步看告警信息和時間窗口確認是哪臺服務(wù)器、哪個域名、什么時間段開始異常。第二步提取原始日志不要只看聚合結(jié)果。先從日志里復(fù)制幾條最可疑的完整請求行看 UA、路徑、狀態(tài)碼、Referer 和來源 IP。第三步驗證來源 IP。使用 whois、ASN 查詢和反向 DNS 解析判斷該 IP 是否在 AI Bot 官方網(wǎng)段范圍內(nèi)。這里要注意很多攻擊者會使用云主機IP 歸屬看起來也是正常云廠商所以不能只看“是不是云廠商”要看“是不是官方公告中使用的云廠商和網(wǎng)段”。第四步確認 CDN 場景下是否拿到真實 IP。如果源站只信任 CDN 轉(zhuǎn)發(fā)請求日志里出現(xiàn)的客戶端 IP 才可信如果攻擊者直接訪問源站入口日志里記錄的 IP 可能不是真實攻擊源。第五步再決定處置動作。如果是少量誤報先限速后觀察如果是大規(guī)模掃描就加入 WAF 規(guī)則或臨時封禁。6.2 上線前和日常防護檢查清單很多服務(wù)器既沒有統(tǒng)一的訪問日志格式也沒有 WAF 規(guī)則出了問題只能臨時翻日志。下面這份清單可以用于新服務(wù)上線前檢查也適合作為日常巡檢項訪問日志是否記錄了完整 UA、Referer、狀態(tài)碼和響應(yīng)時間。是否有/.env、/.git、/wp-login.php、/actuator等敏感路徑的訪問告警。是否對源站入口做了訪問控制避免 CDN 后的真實 IP 泄露。是否配置了限速策略尤其是 UA 為常見 AI Bot 的請求。是否維護了已知 AI Bot IP 段和 UA 樣本庫并定期更新。是否有誤報回滾機制封禁后如何快速放行正常爬蟲。是否對封禁規(guī)則做每日或每周復(fù)盤。其中“源站真實 IP 泄露”經(jīng)常被忽略。攻擊者可以直接掃描源站 IP繞過云 WAF即使你把 WAF 規(guī)則寫得再好也會失去意義。所以生產(chǎn)環(huán)境要確保源站只允許 CDN 節(jié)點、負載均衡器或白名單網(wǎng)段訪問。6.3 從“封 UA”升級到“行為基線”長期來看只靠 UA 關(guān)鍵詞做防御是不夠的。攻擊者會不斷學(xué)習新的 UA 名稱今天偽裝 ClaudeBot明天就可能偽裝其它 AI 爬蟲。真正有效的方式是建立流量行為基線正常業(yè)務(wù)接口的 識別偽造AI Bot的User-Agent掃描與封禁實踐
最近不少運維和安全群在討論一種現(xiàn)象服務(wù)器訪問日志里突然出現(xiàn)大量 User-Agent 寫為 ClaudeBot、GPTBot 之類的請求但實際訪問路徑并不是頁面采集而是/.env、/.git/config、wp-login.php這類敏感文件探測。這不是官方 AI 爬蟲的正常行為而是有人故意偽造 AI Bot 的 User-Agent進行大規(guī)模漏洞掃描。偽造者利用 AI 爬蟲名稱看起來合法、近兩年又頻繁出現(xiàn)在日志里的特點把掃描流量混在正常 Bot 流量中。對運維和開發(fā)來說真正重要的是學(xué)會從 User-Agent 之外的信息確認請求身份并在日志、WAF、封禁策略三層完成識別、驗證和處置。如果你也在自己的 Nginx 或云安全產(chǎn)品里看到類似日志不要急著把所有 ClaudeBot 請求封掉也不要簡單放行。這篇文章會從攻擊者為什么這樣做開始再給出一套從日志到封禁的最小落地流程。1. 為什么有人要偽造 ClaudeBot 這類 AI Bot 的 User-Agent1.1 偽裝掃描日志到底長什么樣先看一段常見但很可疑的訪問日志203.0.113.7 - - [06/Feb/2025:03:11:22 0800] GET /.env HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.23 - - [06/Feb/2025:03:11:24 0800] GET /.git/config HTTP/1.1 404 153 - ClaudeBot/1.0 198.51.100.24 - - [06/Feb/2025:03:11:27 0800] GET /wp-login.php HTTP/1.1 404 153 - Mozilla/5.0 (compatible; ClaudeBot/1.0)如果只看 User-Agent前幾行確實像某個 AI 爬蟲在正常抓取。但請求路徑暴露了問題/.env環(huán)境變量文件、/.git/config源碼倉庫配置、wp-login.phpWordPress 登錄入口這些都是漏洞掃描器最常探測的敏感路徑。攻擊者不在意返回 200 還是 404他們關(guān)心的是哪些路徑存在、哪些服務(wù)會響應(yīng)以及能否從響應(yīng)內(nèi)容中提取到價值信息。這類日志的特點是一條請求一個路徑來源 IP 可能分散UA 只在字面上“看起來像官方”但訪問規(guī)律和正常 AI 爬蟲完全不同。1.2 偽造 AI Bot 身份能帶來哪些好處攻擊者偽造 ClaudeBot 這類 AI 爬蟲名稱不是隨手寫的主要有幾個現(xiàn)實原因。第一個原因是繞過依賴 UA 的訪問控制。有些站點為了配合 AI 搜索收錄會在 Nginx 或 CDN 上專門放行ClaudeBot、GPTBot這類 UA有些團隊還會把它們加入白名單認為它們不會帶來威脅。攻擊者偽造這個 UA相當于直接借用了白名單身份。第二個原因是規(guī)避基于惡意 UA 的基礎(chǔ)封禁。像 sqlmap、Nikto、wpscan 這些掃描工具的 UA 特征非常明顯很多 IPS、WAF 有現(xiàn)成規(guī)則可以直接攔截。把 UA 改成 ClaudeBot 之后傳統(tǒng)規(guī)則失效流量更容易到達業(yè)務(wù)服務(wù)器。第三個原因是降低人工分析時的警惕性。安全告警每天會產(chǎn)生大量日志看到 ClaudeBot、GPTBot 這類名稱很多分析師第一反應(yīng)是“正常 AI 爬蟲”不會第一時間深入排查。攻擊者利用的正是這種思維慣性。1.3 User-Agent 是自述身份不能作為唯一依據(jù)需要注意HTTP 協(xié)議中的 User-Agent 是請求方自己聲明的“身份”客戶端可以隨意修改。用一行命令就能演示curl -A ClaudeBot/1.0 https://example.com/robots.txt服務(wù)器端收到這個請求后只能看到User-Agent: ClaudeBot/1.0無法判斷發(fā)請求的到底是 ClaudeBot 官方爬蟲還是某個掃描器?；谕瑯拥脑砉粽咄耆梢栽趻呙枘_本里偽造任意 UA。所以對 User-Agent 的正確態(tài)度是它只能作為第一層分流標識不能作為信任依據(jù)。真正要判斷一個流量是否可信必須組合來源 IP、請求行為、訪問頻率和路徑特征來判斷。2. 三層識別法從身份、來源、行為判斷真假2.1 第一層身份核對 UA 字符串本身雖然 UA 可以偽造但它仍然是第一道過濾條件。這里要做的是“精確匹配”而不是“模糊包含”。以 ClaudeBot 為例官方爬蟲的 UA 命名通常有固定格式一般形如ClaudeBot/1.0或Mozilla/5.0 (compatible; ClaudeBot/1.0; 官方說明頁)。如果日志里出現(xiàn)ClaudeBot/1.0后面還拼接了.net、.php、scanner、test等字符或者大小寫、空格明顯異常就需要懷疑是偽造樣本。更嚴謹?shù)淖龇ㄊ蔷S護一個“已知 AI Bot UA 樣本庫”。這個樣本庫包括三部分官方公開文檔中聲明的 UA 格式。線上訪問日志中確認為官方爬蟲的 UA。社區(qū)報告確認過存在偽造的 UA 變體。判斷原則很簡單字符串完全匹配可能有風險需要繼續(xù)看下一層字符串不匹配但行為像抓取器可能是普通爬蟲也可能是掃描器同樣要繼續(xù)看來源和行為。2.2 第二層來源IP 段、ASN 與反向 DNS來源驗證是識別偽造 AI Bot 最重要的手段。User-Agent 可以隨便改但正常情況下一個 TCP 連接必須有真實的源 IP攻擊者可以使用大量 IP 發(fā)起掃描但很難讓自己的一臺掃描機同時出現(xiàn)在正確的云廠商網(wǎng)段里。先看 IP 歸屬whois 203.0.113.7查詢結(jié)果會顯示 IP 所在網(wǎng)段、運營商和組織名稱。比如查詢到Organization: Example Cloud、CIDR: 203.0.113.0/24這時再看這個組織是否與官方 AI 爬蟲公開的網(wǎng)段一致。再看反向 DNSdig -x 203.0.113.7官方爬蟲的 IP 通常會配置反解反解域名會包含明顯標識比如某個爬蟲名稱或官方域名后綴。如果源 IP 反解結(jié)果為空或者反解域名是一串隨機數(shù)字甚至指向一個與 AI 爬蟲完全無關(guān)的 IDC 機房那么即使 UA 寫得再像官方也要提高警惕。這里的難點是官方 AI 爬蟲不一定會公開完整的 IP 清單部分云廠商 IP 還會動態(tài)變化。所以來源信息不能作為絕對判斷要結(jié)合行為一起看。2.3 第三層行為請求路徑、頻率和抓取順序正常 AI 爬蟲的工作方式通常有清晰的抓取順序先請求robots.txt再根據(jù) sitemap 或頁面里的鏈接去抓取頁面內(nèi)容請求的路徑大多是可訪問的業(yè)務(wù) URL頻率相對可控。漏洞掃描器不是這樣工作的。掃描器通常攜帶一份路徑字典按字典順序挨個發(fā)起請求比如/.env /.git/HEAD /.git/config /wp-login.php /wp-admin/ /api/v1/ /actuator/env /backup.sql它們不會先看 robots.txt也不會在意頁面結(jié)構(gòu)和鏈接關(guān)系只關(guān)心路徑是否存在、響應(yīng)狀態(tài)碼是什么、返回內(nèi)容里有沒有敏感信息。如果一個“ClaudeBot”在同一個 IP 下十秒內(nèi)連續(xù)請求這些路徑那基本可以確定不是官方 AI Bot而是偽造 UA 的掃描行為。還可以觀察請求頻率是否規(guī)律。正常抓取會有一定間隔掃描器為了趕時間常常高并發(fā)。如果同一個 UA 在凌晨兩三點對同一臺服務(wù)器發(fā)起幾百個不同路徑的請求而且大部分是 404攻擊的可能性很高。2.4 三層組合判斷不要只看單一條件維度正常 AI Bot 常見表現(xiàn)偽造 AI Bot 常見表現(xiàn)UA 匹配UA 與官方公開字符串一致格式穩(wěn)定UA 相似但夾雜異常字符或版本不一致來源 IP來自官方或合作云廠商網(wǎng)段可能有固定 ASN來源分散在多個 IDCASN 與官方聲明不一致反查 DNS反解域名包含可識別標識無反解或反解指向無關(guān)域名訪問路徑先請求 robots.txt再抓取業(yè)務(wù)鏈接直接路徑枚舉/.env、/.git/config等抓取頻率有間隔并發(fā)受控短時間高頻請求規(guī)律不明顯參考鏈接一般帶正常 Referer請求頭完整缺少 RefererHeader 不自然單條請求命中某一項不能說明什么比如正常業(yè)務(wù)方也可能偶爾訪問/.env路徑。但如果“UA 匹配 來源可疑 敏感路徑 高頻”這四件事同時出現(xiàn)基本可以進入攔截流程。3. 落地檢測從 Nginx 訪問日志找出可疑 Bot 流量3.1 先統(tǒng)一日志格式保證能取到關(guān)鍵字段在排查之前要確保 Nginx 訪問日志記錄了足夠信息。推薦使用包含客戶端 IP、時間、請求、狀態(tài)碼和 UA 的格式log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent; access_log /var/log/nginx/access.log main;如果業(yè)務(wù)部署在 CDN 或七層負載均衡后面$remote_addr可能是 CDN 節(jié)點 IP而不是真實客戶端 IP。這種情況要使用X-Forwarded-For或 CDN 平臺提供的真實客戶端 IP 變量但同時要注意這些 Header 可以被偽造。生產(chǎn)環(huán)境必須先驗證源站是否只信任來自 CDN 的請求避免攻擊者直接偽造 Header 繞過記錄。3.2 用 Python 腳本按特征聚合可疑請求先統(tǒng)計 UA 里出現(xiàn) ClaudeBot、GPTBot、Bytespider 等關(guān)鍵詞的 IP找出最活躍的來源from collections import Counter from pathlib import Path log_file Path(/var/log/nginx/access.log) fake_ua_keywords (ClaudeBot, GPTBot, Bytespider) sensitive_path (/.env, .git/config, wp-login.php, actuator, .bak, .sql) ip_counter Counter() sensitive_counter Counter() lines log_file.read_text(encodingutf-8, errorsignore).splitlines() for line in lines: if not any(keyword in line for keyword in fake_ua_keywords): continue fields line.split() if not fields: continue ip fields[0] ip_counter[ip] 1 if any(path in line for path in sensitive_path): sensitive_counter[ip] 1 print(出現(xiàn)偽造 AI UA 關(guān)鍵詞的 Top 20 IP) for ip, count in ip_counter.most_common(20): print(f{count:8d} {ip}) print(命中敏感路徑的 Top 20 IP) for ip, count in sensitive_counter.most_common(20): print(f{count:8d} {ip})這個腳本的思路是先篩選 UA再篩選路徑最后按 IP 聚合。實際生產(chǎn)環(huán)境不需要硬編碼在腳本里可以把日志接入 ELK、ClickHouse 或云原生日志服務(wù)用同樣的邏輯做可視化統(tǒng)計。這里要注意一個坑不要直接在整個日志文件上一次性過濾。生產(chǎn)環(huán)境日志量很大建議先tail -100000或按時間窗口切分日志再進行分析。3.3 時間維度瞬時突增是更可靠的信號IP 數(shù)量和路徑命中只是其中一個維度。偽造 UA 的掃描器往往會在短時間內(nèi)集中爆發(fā)所以把時間維度加進來判斷更準確。統(tǒng)計指定時間內(nèi)每分鐘請求量tail -100000 /var/log/nginx/access.log \ | grep ClaudeBot \ | cut -d[ -f2 | cut -d] -f1 | cut -d: -f1-3 \ | sort | uniq -c | sort -rn | head -20輸出結(jié)果類似147 06/Feb/2025:03:11 98 06/Feb/2025:03:12 12 06/Feb/2025:03:13如果同一個來源 IP 在某一分鐘內(nèi)連續(xù)產(chǎn)生幾十條到上百條請求而且請求路徑全是/.env、/.git/config、wp-login.php這類路徑說明這不是正常 AI Bot 的抓取節(jié)奏而是掃描器正在跑字典。時間窗口聚合的價值在于它能把“少量誤報”和“批量掃描”區(qū)分開。正常抓取也會請求多個路徑但不會在幾秒內(nèi)密集命中大量敏感路徑。建議把“單位時間內(nèi)同一個 IP 命中敏感路徑次數(shù)”作為告警條件而不是單純看 UA。這樣即使對方換個 UA 名稱只要行為仍然是掃描一樣能觸發(fā)。4. 自動處置從 Fail2ban 到 WAF 策略4.1 Fail2ban 攔截“敏感路徑 偽 AI UA”在單臺 Linux 服務(wù)器上快速落地時Fail2ban 是成本最低的方案。思路是在 Nginx 訪問日志中匹配特定 UA 和敏感路徑超過閾值后自動封禁源 IP。先創(chuàng)建過濾器比如/etc/fail2ban/filter.d/fake-ai-bot.conf[Definition] failregex ^HOST .*(?:GET|POST|HEAD) \/(?:\.env|\.git\/config|wp-login\.php|\.\.\/\.\.\/).* 404 .*ClaudeBot/1\.0$ ignoreregex 再在/etc/fail2ban/jail.local中啟用[fake-ai-bot] enabled true port http,https filter fake-ai-bot logpath /var/log/nginx/access.log findtime 60 maxretry 5 bantime 3600參數(shù)含義參數(shù)說明示例值findtime統(tǒng)計時間窗口單位秒60maxretry時間窗口內(nèi)匹配的最大次數(shù)5bantime封禁時長單位秒3600logpath日志文件路徑/var/log/nginx/access.log配置完成后先測試正則是否匹配真實日志fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/fake-ai-bot.conf這個工具會顯示匹配次數(shù)。如果正則不匹配需要檢查日志格式與正則中的字段順序。4.2 WAF 的挑戰(zhàn)與限流思路Fail2ban 適合單機和簡單場景但對于多節(jié)點、分布式掃描和 CDN 場景更推薦在 WAF 層處理。WAF 通常提供三種能力Bot 管理識別常見爬蟲和工具 UA并支持自定義 Bot 特征。JS Challenge對可疑請求下發(fā)一段 JavaScript 挑戰(zhàn)正常瀏覽器能通過大多數(shù)命令行掃描工具無法完成。速率限制按 IP、Session、UA 組合限流。實際策略不要直接對 ClaudeBot 返回 403而是先分級正常且可驗證的官方 AI Bot - 放行并限速 可疑 UA 但來源未知 - JS Challenge 或 429 疑似掃描 命中敏感路徑 - 403 或封禁這樣的好處是減少誤傷。有些站點希望被 AI 搜索索引如果把所有 ClaudeBot 都封掉可能會造成收錄異常。進入挑戰(zhàn)流程后官方 Bot 即使無法完成 JS 挑戰(zhàn)也有機會通過后續(xù) IP 驗證流程放行。4.3 封禁、觀察、復(fù)核的完整處理流程任何自動封禁都可能誤傷尤其涉及到 AI Bot 名稱時。建議按下面順序執(zhí)行自動發(fā)現(xiàn)日志或 WAF 識別到“UA 疑似 AI Bot 敏感路徑 高頻”。臨時限速先對該 IP 啟用較慢的限速策略而不是直接 403。人工復(fù)核查看 IP 歸屬、ASN、反向 DNS 和該 IP 的完整請求序列。確認封禁如果確認為掃描再封禁 IP 或 IP 段并設(shè)置合理時長。定期復(fù)查每天檢查被誤殺的請求調(diào)整規(guī)則。保留證據(jù)把原始日志、請求頭和響應(yīng)狀態(tài)保存下來便于后續(xù)調(diào)整規(guī)則。這里重點強調(diào)第六步。很多團隊封完就不管了后來才發(fā)現(xiàn)某個正常爬蟲 IP 被規(guī)則誤傷。保留日志和規(guī)則快照可以讓誤傷恢復(fù)變得可操作而不是只能靠“感覺”。5. 避免誤傷官方 AI Bot 和偽造掃描器怎么區(qū)分處理5.1 官方 AI Bot 通常會有哪些可驗證特征雖然不同 AI 爬蟲的實現(xiàn)細節(jié)不同但公開服務(wù)通常有相對穩(wěn)定的特征會遵守robots.txt并且很多官方文檔會說明爬蟲用途和聯(lián)系頁面。會使用固定 UA并且 UA 中可能包含官方說明頁地址。來源 IP 有較明確的云廠商或自有網(wǎng)段部分會公布 IP 范圍。抓取行為以采集頁面內(nèi)容為主不會高頻請求/.git、/.env這類路徑。官方 AI Bot 也不一定永遠表現(xiàn)完美比如某些海外云廠商的爬蟲會訪問不支持的地域、頻繁請求動態(tài)接口但這不能作為直接封禁理由。更好的做法是建立“正常樣本”和“可疑樣本”兩個隊列持續(xù)觀察。5.2 參考分級處理策略情況建議處理UA 匹配IP 歸屬正常訪問路徑正常放行并設(shè)置每秒請求數(shù)上限UA 匹配IP 歸屬未知但路徑正常臨時放行記錄日志并持續(xù)觀察UA 匹配IP 歸屬未知命中敏感路徑限速觀察后續(xù)行為UA 匹配IP 歸屬可疑高頻命中敏感路徑直接封禁至少封禁 24 小時UA 不匹配但行為與官方 AI Bot 一致按普通爬蟲處理不做特殊放行在生產(chǎn)環(huán)境里建議把“UA 匹配”和“行為匹配”分開記分而不是用布爾判斷。例如UA 匹配官方格式1 IP 歸屬在官方網(wǎng)段3 先請求 robots.txt2 命中敏感路徑-3 短時間高頻請求-2 缺少 Referer-1最終分越高越可信越低越可疑。這樣即使攻擊者不斷更換 UA只要行為特征不變分數(shù)依然會偏低。提醒最好不要在規(guī)則里寫死“只要 UA 等于 ClaudeBot 就放行”。AI 爬蟲名稱會不斷增加和變化要把判斷重點放在“來源和行為”上。6. 生產(chǎn)環(huán)境排錯與預(yù)防清單6.1 接到告警后的排查順序如果線上已經(jīng)出現(xiàn)大量偽造 AI Bot 掃描建議按下面的順序排查而不是先找封禁命令。第一步看告警信息和時間窗口確認是哪臺服務(wù)器、哪個域名、什么時間段開始異常。第二步提取原始日志不要只看聚合結(jié)果。先從日志里復(fù)制幾條最可疑的完整請求行看 UA、路徑、狀態(tài)碼、Referer 和來源 IP。第三步驗證來源 IP。使用 whois、ASN 查詢和反向 DNS 解析判斷該 IP 是否在 AI Bot 官方網(wǎng)段范圍內(nèi)。這里要注意很多攻擊者會使用云主機IP 歸屬看起來也是正常云廠商所以不能只看“是不是云廠商”要看“是不是官方公告中使用的云廠商和網(wǎng)段”。第四步確認 CDN 場景下是否拿到真實 IP。如果源站只信任 CDN 轉(zhuǎn)發(fā)請求日志里出現(xiàn)的客戶端 IP 才可信如果攻擊者直接訪問源站入口日志里記錄的 IP 可能不是真實攻擊源。第五步再決定處置動作。如果是少量誤報先限速后觀察如果是大規(guī)模掃描就加入 WAF 規(guī)則或臨時封禁。6.2 上線前和日常防護檢查清單很多服務(wù)器既沒有統(tǒng)一的訪問日志格式也沒有 WAF 規(guī)則出了問題只能臨時翻日志。下面這份清單可以用于新服務(wù)上線前檢查也適合作為日常巡檢項訪問日志是否記錄了完整 UA、Referer、狀態(tài)碼和響應(yīng)時間。是否有/.env、/.git、/wp-login.php、/actuator等敏感路徑的訪問告警。是否對源站入口做了訪問控制避免 CDN 后的真實 IP 泄露。是否配置了限速策略尤其是 UA 為常見 AI Bot 的請求。是否維護了已知 AI Bot IP 段和 UA 樣本庫并定期更新。是否有誤報回滾機制封禁后如何快速放行正常爬蟲。是否對封禁規(guī)則做每日或每周復(fù)盤。其中“源站真實 IP 泄露”經(jīng)常被忽略。攻擊者可以直接掃描源站 IP繞過云 WAF即使你把 WAF 規(guī)則寫得再好也會失去意義。所以生產(chǎn)環(huán)境要確保源站只允許 CDN 節(jié)點、負載均衡器或白名單網(wǎng)段訪問。6.3 從“封 UA”升級到“行為基線”長期來看只靠 UA 關(guān)鍵詞做防御是不夠的。攻擊者會不斷學(xué)習新的 UA 名稱今天偽裝 ClaudeBot明天就可能偽裝其它 AI 爬蟲。真正有效的方式是建立流量行為基線正常業(yè)務(wù)接口的