前面十五天蓋的每一樣東西，都在想辦法讓機器更安分：健康檢查、備份、告警，全是怕它出事。今天反過來，要建置一個工具，主動去打自己人——對機隊裡的機器發動一次真的滲透測試，找出哪裡有漏洞。工具叫 Strix，一個開源的 AI pentest agent（github.com/usestrix/strix）。它是一個會自己規劃、自己出手、自己判斷有沒有打進去的 agent。危險的地方也在這：它天生就是為了攻擊系統而寫的。

先講清楚，這工具的煞車在哪：

畫面最上面那條黃底的字寫著：
只能對機隊清單內的機器 IP 或 NPM 網域執行掃描，清單外的目標會被後端拒絕，這是刻意解除煞車的攻擊工具，請勿對非自有資產使用。
這句話不是免責聲明，是設計的核心。Strix 不會問你「這台是不是你的」，你給它網址它就攻擊。所以唯一的煞車不在它身上，在我這邊的一份白名單——目標必須落在機隊 Machine 表的 IP，或 NPM 上掛著的網域，兩者的聯集。連底下那個手動輸入框也一樣，打進去的字串還是要先過白名單才放行。一個會自己攻擊的東西，能不能被信任，不看它多聰明，看它攻擊的範圍有沒有被框死。

老樣子，讓 claude 先把整個 repo 讀一遍。叫 claude code 先把 repo 讀懂，再照我要的把功能接進 HQ。

ssh 連到 hq，切換到 /opt/claude-working，執行 claude code：

讀 https://github.com/usestrix/strix ，
搞懂它怎麼啟動一次掃描、掃描中途怎麼看進度、跑完的報告長什麼樣。
讀完不要在 HQ 這台跑它 —— HQ 只當控制台。

一、⛔ 掃描不可以跑在 HQ 這個行程裡。
    新建一台 VM，做為專用的 worker（192.168.0.50），Strix 裝在那台，安裝必需的套件。
    HQ 透過它自己的一個 API 派工、輪詢狀態、把報告拉回來。

二、⚠️ 目標一律走白名單：只能是機隊 Machine 表裡的 IP，
    或 NPM 上掛著的網域，兩者的聯集。⛔ 清單外的目標，後端直接拒絕。
    不要相信前端有沒有擋 —— 前端會被繞過，擋要擋在後端。

三、同一時間只准跑一個掃描。⛔ 不要讓人一次點四台就併四個 job，
    這工具很吃資源，而且兩個 job 的報告會互相蓋。

四、⚠️ headless 一律強制開，不給關 —— 這是背景 job，
    沒有人坐在那邊回它的互動問題。
    
五、在 HQ 增加安全掃描頁面，列出：左側：目標，LLM，執行；右側顯示紀錄，執行中的掃描可以取消。

頁面長什麼樣：左邊挑目標，右邊看歷史

左邊「目標」欄有兩個來源：機隊主機一個清單、每一台一個 IP，NPM 網域一個清單、每一個一條網址，各自可以勾選。底下一個手動輸入框，逗號或換行分隔，但仍要在白名單內。右邊是掃描紀錄，一列一筆，欄位很簡單：目標、模式、狀態、建立時間。狀態就三種——完成、失敗、已取消，配三個顏色，綠、紅、黑。一整頁看下來，最有資訊量的其實是右邊那排狀態，它比任何程式碼都誠實地告訴你，這功能上線的過程有多不順。

兩個參數：掃描深度，跟思考強度

掃描選項底下有兩個可以調的東西。第一個是掃描深度，對應 Strix 的 scan-mode，預設不指定，也可以指定成 quick。第二個是思考強度，也就是 reasoning effort，預設是用 worker 那邊定好的值。再往下有一個額外指示的欄位，可以塞一句話進去——例如「這輪只看商業邏輯漏洞跟越權」——它會照著把注意力收窄到你點的那個方向。兩個旋鈕加一句話，就是我能對這場攻擊下的全部指令，剩下的它自己決定。

LLM 這一格，看得到但選不動 —— 而且是故意的

LLM 引擎，寫著 GPT-5.6 Luna。它是灰的，點不動。這不是還沒做完，是故意鎖死的。
故事是這樣的：我本來想用自己養的 qwen 3.6 來跑。平常拿來翻譯、分類、當安全過濾器都很稱職。但 Strix 這種工作它做不來，而且差別不在會不會找漏洞，在收不收得了尾。我實測拿它去掃一個真的網站：它跑滿兩個小時、燒掉三千多萬個 token、找到零個洞，然後從頭到尾沒有呼叫過一次「結束掃描」。它一直在重新規劃下一步，像一個永遠覺得還沒查完的人，停不下來。這不是壞掉，是「自己判斷什麼時候該收手」這種要求，剛好踩在它最弱的地方，而這種弱你不真的拿它去跑一個會累的長任務，是看不出來的。

換成 GPT-5.6 Luna，同一個網站，十一分鐘就自己收尾。那為什麼不乾脆做成下拉選單、讓人自己選？因為如果做成可選，一定會有人選了本地那顆、以為省錢，結果掃描永遠不會結束，他還會回頭以為是系統壞了。所以頁面直接寫死：固定用 Luna，旁邊那行小字老實講清楚——備援是本地那顆，免費但收斂慢、不穩定，要切回去得改 worker 端的設定檔，不從這個頁面選。看得到、寫清楚為什麼、但不給你踩，比藏起來或做一個會害人的選單都好。

於是我們真的掃了 —— 大部分都不好看

上線那天的紀錄很誠實：十五筆裡面，一半是失敗，一半是我自己按掉的已取消，只有最後一筆是綠色的完成。那些失敗不是白名單擋的，是把 Luna 真正接通之前一路踩的坑——設定檔裡的殘留把模型偷偷指回本地那顆、環境變數的格式沒被讀對、模型跟工具一起用的時候少送一個參數就被 API 打回400。每一筆紅色，背後都是一個接線沒接好的地方。而且這種事，看紀錄比看程式碼誠實：程式碼會告訴你「應該會通」，紀錄告訴你「第幾次才真的通」。

最後終於成功了！一筆綠色的，下午三點十六分。

最後那筆完成的，建立時間下午三點十六分，目標是機隊裡一個用 Ghost 架的站（1962.iron30.com），模式 quick，引擎 Luna。它是整條鏈第一次真正從頭跑到尾。

掃描 #15 —— 第一次端到端跑通

目標          1962.iron30.com（Ghost 靜態站）
模式          quick
引擎          openai/gpt-5.6-luna
狀態          ✅ 完成（Strix 自己呼叫 finish_scan 收尾，不是被逾時砍掉、也不是我按掉的）
耗時          約 11 分鐘
報告          tar.gz 73 KB，HQ 下載回來 200 OK
花費          US$0.19 / 131 次請求
找到的洞      0

看起來不錯。可是：

仔細讀產出的那份滲透報告，結論欄寫著 Not assessable——「無法評估」。原因是：負責發動攻擊的沙箱容器被刻意斷網(air-gap)，只放行它連自架的大模型，不准它連任何外部網站。於是它替我去敲目標的每一個請求，都在半路被攔成 502，一個應用層的回應都拿不到。它不是「掃過覺得很乾淨」，是「根本沒碰到目標」。

「找到 0 個漏洞」在這裡不代表安全，只代表它連門都沒摸到。這是我這一年學到最貴的一句話：檢查回報 0，不等於沒問題，你得先確定這個檢查有找目標。

所以這個成功是假的：他成功得碰不到我們要檢查的網站，回報我們：所以他檢查不到缺點。

重來。

在容器防火牆那條「全部擋掉」的規則前面,插一條「只放行自家對外 IP 的 80/443」。測一下，OK，Strix 這台，可以順利連到 1962.iron.com。
開始執行：
這次學乖了，讓 claude 監視 1962.iron.com 那一端發生甚麼：反向代理的存取紀錄顯示：掃描期間,來自那台 Strix 的請求進來了 424 筆。回應碼是 228 個 200、75 個 404、24 個 403、還有 8 個是部落格後台 API 專屬的 422……全是真真切切的應用層回應。不再是上次那種一整片的 502。
三件事我一項一項對過:

1. 來源 IP 確實是那條 ADSL 撥接位址，是來自那台 Strix，確實是「外部的攻擊」。
2. 引擎日誌整場都寫著用的是那個 GPT-5.6 LUNA，自架的 Qwen 3.6 在同一段時間裡收到的請求數是 0，沒有偷偷換回自架引擎。
3. 掃描器最後自己收斂、正常結束。

報告摘要如下：

掃描結果：乾淨，但有幾處該要處理：
報告這次是紮實的:SQL injection、XSS、SSRF、XXE、IDOR、CSRF、認證繞過、競態條件、商業邏輯濫用，一輪測下來，確認沒有漏洞。
它給的是幾條「防禦縱深」的建議：

1. 內容安全政策(CSP)開了 unsafe-inline 和 unsafe-eval
2. 平台版本號從外面就探得到
3. 還有一個 CORS 標頭開成萬用字元。
   這是要修改的地方，但在這次的情境裡都沒被串成真正的攻擊。乾淨，但不是無懈可擊——這種結論我反而更信,因為它連我知道存在的小毛病都指出來了。

把檢查出來的建議 丟給claude 叫他去改。

一個意外的插曲：
fail2ban 的設定，同一個 IP 在十分鐘內累積十次異常請求，就會被封鎖。而這次掃描，424 筆請求裡有 117 筆是「該觸發封鎖」的錯誤碼。結果都沒有封鎖。
叫 claude 檢查這是甚麼狀況。
原來：那條檢查規則長這樣：它假設每一行日誌的「開頭」就是來源 IP。這是標準 combined 格式的樣子。但這台反向代理的日誌格式，開頭是時間戳，IP 被塞在行尾的一個 [Client x.x.x.x] 欄位裡。於是這條規則,對這個格式,一筆都對不上。

claude 用比對工具實測：舊規則掃四千多行日誌,命中 0。所以：這個 fail2ban 從裝上它那天起，就是個擺設！這是「有跑、有數字、就是不作用」，它不會報錯，不會告警，如果不是這次，真的攻擊進來、而且刻意去看「該被擋的到底有沒有被擋」，它永遠不會現形。

當然，馬上叫 claude 去改，改完驗證，收工。

這呼應我一直提醒自己的一件事：防線的門檻要用實際輸出「掃」出來，不是憑感覺「寫」出來。誤報太多的檢查，跟沒有檢查一樣糟，因為久了你會學會整批略過它。

這一集的三個教訓
第一，綠燈會集體騙人。完成、結束碼 0、找到 0 個問題。三盞燈可以都是真的，合起來卻指向相反的結論。要拆開一盞一盞問「你這盞到底在證明什麼」。
第二、「檢查回空」不等於「沒問題」，你得先證明這個檢查有能力找到目標。上次的 0 和這次的 0，數字一樣，一個是瞎、一個是真沒事。分辨它們的唯一辦法，是去被檢查的那一端找證據。
第三、最危險的防線，不是不存在的防線，是那種每天跟你說「我在」、實際上一次都沒作動的防線。安全設定的正確性，不能靠「到目前為止剛好沒出事」來背書；你要能指出，是誰、用什麼機制，在替你保證它真的有效。

結論：這個工具，Strix，有用。

到此，基礎架構及檢查，都差不多了。明天繼續開始，逐步轉向應用。