7.E 邊緣安全事件的判讀與監控 on Tarragonhttps://tarrragon.github.io/blog/backend/07-security-data-protection/edge-events/Recent content in 7.E 邊緣安全事件的判讀與監控 on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Mon, 26 Oct 2026 00:00:00 +0800邊緣安全事件的判讀與監控：處理層與事件欄位、背景流量的分類、處置留下的紀錄、監控分級、從事件回寫規則https://tarrragon.github.io/blog/backend/07-security-data-protection/edge-events/edge-security-event-series-scope/Tue, 27 Oct 2026 00:00:00 +0800https://tarrragon.github.io/blog/backend/07-security-data-protection/edge-events/edge-security-event-series-scope/<blockquote> <p><strong>待更新</strong>：這組文章的概念篇與 Cloudflare 的實測紀錄都還在撰寫中。本篇先寫出整組文章的判讀機制與各篇要交付的判斷；各篇發佈之後，下面的內容表會換成連到那一篇的連結。</p></blockquote> <p>這篇說明一組關於邊緣安全事件的文章：網站放在 CDN 或 WAF 後面之後，請求在邊緣經過哪幾層處理、每一層的決定在事件紀錄裡留下哪些欄位、邊緣紀錄與源站 access log 怎麼分工、事件頁上的背景流量怎麼分類、各種處置（Block、Challenge、Log、Skip、限流）在紀錄裡代表什麼、哪些事件要即時告警而哪些定期翻閱，以及發現新的請求模式之後怎麼回寫成規則。判讀方法不綁定業者，Cloudflare 是貫穿各篇的實例，AWS WAF 與 Fastly 的對應欄位在各篇並列。</p> <h2 id="這組文章設定的讀者">這組文章設定的讀者</h2> <p>讀者是替一個對外網站負責的工程師：網站已經放在 CDN 或 WAF 後面（或正在決定要不要放），手上有一個事件頁或一份匯出的紀錄，身邊沒有資安團隊替他判讀。他熟悉 HTTP、DNS 與自己網站的技術堆疊，缺的是判斷事件頁上幾百筆紀錄裡哪些跟自己的網站有關的經驗。典型的情境是有會員資料與訂單的小型電商或會員制網站，網站公開運作一段時間之後，負責的工程師定期翻閱事件頁。</p> <h2 id="請求在邊緣依序經過的處理層">請求在邊緣依序經過的處理層</h2> <p>各篇的判斷都建立在同一個機制上：請求在邊緣依序經過幾層處理，每一層各自做一個決定（放行、擋下、要求驗證、只記錄、跳過後面的層），被擋下或被攔住的請求不會到達源站。由這個機制推出三件事：</p> <ul> <li><strong>邊緣紀錄與源站紀錄的分工</strong>：被擋下的請求只留在邊緣的事件紀錄裡，源站的 access log 沒有它們；被放行的請求兩邊都有紀錄。兩份紀錄各自涵蓋哪些請求，由請求在哪一層被處置決定，跟用哪一套記錄工具無關。</li> <li><strong>事件的 Action 欄位</strong>：這個欄位記的是哪一層做了什麼決定，所以判讀一筆事件之前，要先知道它是哪一層留下的。</li> <li><strong>事件頁上量最大的那一類</strong>：背景流量多半在最前面的幾層就被處置，所以事件頁上筆數最多的那一類，多半是對這個網站威脅最小的那一類；針對這個網站的請求，要從被放行或只被記錄的事件裡找。</li> </ul> <p>讓流量一定先經過邊緣的前提，也就是源站主機只接受 CDN 來源的連線，寫在 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/origin-host-firewall/" data-link-title="CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖" data-link-desc="網站放在 CDN（例如 Cloudflare）後面時，源站主機的入站與出站限制：請求避開 CDN 直連源站的成因、來源限制放在雲端防火牆、主機防火牆或 CDN 端驗證的差別、只放行 CDN 位址的套用時機、Docker 發佈的連接埠繞過 ufw 與 firewalld 的路徑與各種限制寫法、CDN 位址送來的請求為什麼不等於 CDN 替自己的網域轉送、出站 DNS 限制的效果與漏洞、地理封鎖放在 CDN 邊緣的理由">CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖</a>；這組文章從流量進了邊緣之後寫起。</p> <h2 id="各篇交付的判斷與目前的狀態">各篇交付的判斷與目前的狀態</h2> <table> <thead> <tr> <th>文章（暫定標題）</th> <th>交付的判斷</th> <th>狀態</th> </tr> </thead> <tbody> <tr> <td>邊緣事件的處理層與紀錄欄位</td> <td>請求依序經過的處理層（DDoS 防護、託管規則、自訂規則、限流、bot 判定、AI 爬蟲控制）、每一層留下的事件欄位、邊緣紀錄與源站紀錄的分工</td> <td>撰寫中</td> </tr> <tr> <td>背景流量的組成與分類</td> <td>漏洞掃描、撞庫登入、搜尋引擎爬蟲、經過驗證的 bot、AI 爬蟲；用自己的技術堆疊判斷哪些請求不可能命中這個網站；針對這個網站的訊號（命中真實路徑、集中在登入或結帳端點）</td> <td>撰寫中</td> </tr> <tr> <td>處置的種類與它們留下的紀錄</td> <td>Block、Managed Challenge、JS Challenge、Log、Skip、限流，以及不阻斷請求的處置（AI Labyrinth）；不擋下請求的處置換到什麼；從驗證的通過率判讀誤擋</td> <td>撰寫中</td> </tr> <tr> <td>邊緣事件的監控分級</td> <td>即時告警、定期翻閱、只留存三種處理的分界；有會員與訂單資料時要多看的訊號；各方案的保留期限與匯出方式；邊緣紀錄、源站紀錄與應用程式稽核紀錄的對照</td> <td>撰寫中</td> </tr> <tr> <td>從事件回寫規則</td> <td>發現新的請求模式之後，先用 Log 處置觀察再改成擋下；規則放進版本控制；規則的退場；<a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/blue-team/detection-engineering-lifecycle/" data-link-title="7.B5 Detection Engineering Lifecycle" data-link-desc="把偵測規則視為可維護資產，建立從來源、測試、調校到退場的完整生命週期">偵測規則的生命週期</a>在邊緣這一層的做法</td> <td>撰寫中</td> </tr> <tr> <td>Cloudflare 的實測紀錄</td> <td>測試網域經 Cloudflare proxy 指到一台雲端主機、收集數天的自然流量、事件頁的篩選、bot 功能與 AI Labyrinth 的開關、用 API 取出事件、通知設定</td> <td>撰寫中</td> </tr> </tbody> </table> <p>Cloudflare 的實測紀錄發佈之後放在 <a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/vendors/cloudflare-waf/" data-link-title="Cloudflare WAF" data-link-desc="Edge WAF &#43; DDoS &#43; Bot management 整合套件、global anycast 網路、控制面信任邊界跟客戶側補強的對照">Cloudflare WAF</a> 的資料夾底下，因為那一篇操作的對象是 Cloudflare 這個業者。防護控制本身怎麼選、怎麼配置（流量清洗、速率規則、挑戰驗證、搶購機器人）不在這組文章的範圍；這組文章寫的是那些控制動作留下的紀錄怎麼讀、怎麼排進監控。</p>

待更新：這組文章的概念篇與 Cloudflare 的實測紀錄都還在撰寫中。本篇先寫出整組文章的判讀機制與各篇要交付的判斷；各篇發佈之後，下面的內容表會換成連到那一篇的連結。

這篇說明一組關於邊緣安全事件的文章：網站放在 CDN 或 WAF 後面之後，請求在邊緣經過哪幾層處理、每一層的決定在事件紀錄裡留下哪些欄位、邊緣紀錄與源站 access log 怎麼分工、事件頁上的背景流量怎麼分類、各種處置（Block、Challenge、Log、Skip、限流）在紀錄裡代表什麼、哪些事件要即時告警而哪些定期翻閱，以及發現新的請求模式之後怎麼回寫成規則。判讀方法不綁定業者，Cloudflare 是貫穿各篇的實例，AWS WAF 與 Fastly 的對應欄位在各篇並列。

這組文章設定的讀者

讀者是替一個對外網站負責的工程師：網站已經放在 CDN 或 WAF 後面（或正在決定要不要放），手上有一個事件頁或一份匯出的紀錄，身邊沒有資安團隊替他判讀。他熟悉 HTTP、DNS 與自己網站的技術堆疊，缺的是判斷事件頁上幾百筆紀錄裡哪些跟自己的網站有關的經驗。典型的情境是有會員資料與訂單的小型電商或會員制網站，網站公開運作一段時間之後，負責的工程師定期翻閱事件頁。

請求在邊緣依序經過的處理層

各篇的判斷都建立在同一個機制上：請求在邊緣依序經過幾層處理，每一層各自做一個決定（放行、擋下、要求驗證、只記錄、跳過後面的層），被擋下或被攔住的請求不會到達源站。由這個機制推出三件事：

  • 邊緣紀錄與源站紀錄的分工：被擋下的請求只留在邊緣的事件紀錄裡，源站的 access log 沒有它們；被放行的請求兩邊都有紀錄。兩份紀錄各自涵蓋哪些請求，由請求在哪一層被處置決定，跟用哪一套記錄工具無關。
  • 事件的 Action 欄位：這個欄位記的是哪一層做了什麼決定，所以判讀一筆事件之前，要先知道它是哪一層留下的。
  • 事件頁上量最大的那一類：背景流量多半在最前面的幾層就被處置，所以事件頁上筆數最多的那一類，多半是對這個網站威脅最小的那一類；針對這個網站的請求，要從被放行或只被記錄的事件裡找。

讓流量一定先經過邊緣的前提，也就是源站主機只接受 CDN 來源的連線，寫在 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖；這組文章從流量進了邊緣之後寫起。

各篇交付的判斷與目前的狀態

文章（暫定標題） 交付的判斷 狀態
邊緣事件的處理層與紀錄欄位 請求依序經過的處理層（DDoS 防護、託管規則、自訂規則、限流、bot 判定、AI 爬蟲控制）、每一層留下的事件欄位、邊緣紀錄與源站紀錄的分工 撰寫中
背景流量的組成與分類 漏洞掃描、撞庫登入、搜尋引擎爬蟲、經過驗證的 bot、AI 爬蟲；用自己的技術堆疊判斷哪些請求不可能命中這個網站；針對這個網站的訊號（命中真實路徑、集中在登入或結帳端點） 撰寫中
處置的種類與它們留下的紀錄 Block、Managed Challenge、JS Challenge、Log、Skip、限流，以及不阻斷請求的處置（AI Labyrinth）；不擋下請求的處置換到什麼；從驗證的通過率判讀誤擋 撰寫中
邊緣事件的監控分級 即時告警、定期翻閱、只留存三種處理的分界；有會員與訂單資料時要多看的訊號；各方案的保留期限與匯出方式；邊緣紀錄、源站紀錄與應用程式稽核紀錄的對照 撰寫中
從事件回寫規則 發現新的請求模式之後，先用 Log 處置觀察再改成擋下；規則放進版本控制；規則的退場；偵測規則的生命週期在邊緣這一層的做法 撰寫中
Cloudflare 的實測紀錄 測試網域經 Cloudflare proxy 指到一台雲端主機、收集數天的自然流量、事件頁的篩選、bot 功能與 AI Labyrinth 的開關、用 API 取出事件、通知設定 撰寫中

Cloudflare 的實測紀錄發佈之後放在 Cloudflare WAF 的資料夾底下，因為那一篇操作的對象是 Cloudflare 這個業者。防護控制本身怎麼選、怎麼配置（流量清洗、速率規則、挑戰驗證、搶購機器人）不在這組文章的範圍；這組文章寫的是那些控制動作留下的紀錄怎麼讀、怎麼排進監控。

]]>