#cofacts

2026-05-02
mrorz 16:51:28
由於 RightsCon 取消了,我們下週二會開會唷~
chewei 哲瑋 2026-05-03 02:25:12
這裡有一串討論
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中

https://g0v-tw.slack.com/archives/C092S5VUP6Z/p1777725088733109
mrorz 16:51:28
由於 RightsCon 取消了,我們下週二會開會唷~
  • 👍2
  • 😮1
chewei 哲瑋 2026-05-03 02:25:12
這裡有一串討論
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中

https://g0v-tw.slack.com/archives/C092S5VUP6Z/p1777725088733109
2026-05-03
chewei 哲瑋 02:25:12
Replied to a thread: 2026-05-02 16:51:28
這裡有一串討論
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中

https://g0v-tw.slack.com/archives/C092S5VUP6Z/p1777725088733109
coldplay5566
大家!應該都有看到RightsCon 取消舉辦的消息!!
事出臨時,而且也已經很靠近Summit,但我想我們或許可以做點什麼~也想問問大家意見:face_holding_back_tears:
稍早在臉書跟 @mglee 討論,提到或許可以協助接受 RightsCon 已經錄取的議程之類的(利用目前還空著的午休時段?)~
或是大家有什麼想做的事嗎!!
  • 🙏2
2026-05-04
mrorz 15:14:56
*【DDoS 攻擊事後報告】2026-05-04*

*發生了什麼*
4/30 起陸續有攻擊流量,5/4 13:15 達到高峰。攻擊者使用 11 個 hosting 網路(Datacamp、M247、GTT 等)的大量 IP,對我們的 /article/ 和 /reply/ 頁面發動廣撒爬取,造成 API 過載、GCE swap 爆滿(99%),網站大量 504。

*攻擊手法*
直接打網站頁面 → 觸發 SSR → 每個 SSR 都呼叫 API → ~800 個 concurrent 連線同時打 Elasticsearch → ES 撐不住,所有 query 超時形成正回饋。攻擊者並沒有直接打 API,而是利用 SSR 當放大器。

*為什麼 rate limiting 沒用*
攻擊分散在數百個 IP,每個 IP 每分鐘只打 1–2 次,遠低於 rate limit 門檻。Per-IP rate limiting 對分散式低速爬取無效。

*已處理*
- Cloudflare WAF 封鎖 11 個攻擊 ASN
- 重啟 API 與 site-en/ja 容器,swap 緩慢釋放中

待辦
- 修正 WAF rule(目前只封 /graphql,需補上 /article/ /reply/ /user/)
- 開 Cloudflare Bot Fight Mode
- 中期:SSR fetch 加 10 秒 timeout、研究 article/reply 頁面快取
  • 😮4
  • 1
  • 🎯1
主力採用 GCP asia-east1 租用 VM 的話,是不是有機會報警告妨害電腦使用,然後讓警察局去跟 Google 發公文要出該時間的該 IP 使用帳號,看有沒有機會抓出兇手本人?
欸我發現那個 IP 是 server 自己的 ephemeral IP lol
XDDDDD 差點報警殺了 127.0.0.1
還好 AI 沒有自動報警
我要來重開機器囉,釋放一下 swap
Done
跟我們遇到的有點像,所幸對方只打一下下

駭客發動長達5小時慢而低調的DDoS攻擊以規避偵測 | iThome https://share.google/4bAlHp0vYxSyCsZPU
mrorz 15:14:56
【資安事件報告・已緩解】5/4 api.cofacts.tw GraphQL DDoS 攻擊

*事件時間軸*
• 4/30 起:Cloudflare threats 從 ~10k/day 暴增至 113k/day,GCE swap 從 5/1 開始逐漸被壓滿
• 5/4 13:15:攻擊出現最大尖峰,POST `/graphql` 達 **2,130 req/min**,API 大量回傳 524 timeout
• 5/4 13:36:攻擊自然衰退,14:00 前流量恢復正常水位
• 5/4 14:41:部署 Cloudflare WAF 規則封鎖攻擊來源
• 5/4 14:55:重啟 API 與 URL resolver,機器恢復正常

*攻擊手法*
攻擊者從 rumors-line-bot open source code 找到 `ListArticlesInInitState`(`moreLikeThis` Elasticsearch 查詢),此 query 每次執行需 116 秒。主力攻擊 IP `34.81.219.20`(GCP asia-east1 租用 VM)以 *626 req/min* 併發送出,同時搭配 Datacamp、M247、GTT、Oxylabs 等 11 個 hosting ASN 大量 flooding,讓 server queue 與記憶體耗盡。

*攻擊影響(尖峰)*
• Load average:*15.26*(正常應 < 4)
• RAM:25GB / 31GB、Swap:3.9GB / 4.0GB(幾乎全滿)
• API process 記憶體暴增至 *4.4GB*(正常 ~150MB)

*恢復後現況*
| 指標 | 攻擊尖峰 | 現在 |
|------|---------|------|
| Load average | 15.26 | **0.93** ✅ |
| RAM available | 6.3 GB | **13 GB** ✅ |
| Swap used | 3.9 GB (97%) | 3.8 GB(持續釋放中)|

*已採取的防禦/復原措施*
1. Cloudflare Custom Rule「20260504 attack mitigation」:封鎖 11 個攻擊 ASN 對 `/graphql` 的存取,直接 block `34.81.219.20`
2. Cloudflare Rate Limiting Rule「Prevent fast access」:對 `api.cofacts.tw` POST `/graphql` 加上頻率限制
3. 重啟 API 與 Site 釋放積累的記憶體
主力採用 GCP asia-east1 租用 VM 的話,是不是有機會報警告妨害電腦使用,然後讓警察局去跟 Google 發公文要出該時間的該 IP 使用帳號,看有沒有機會抓出兇手本人?
欸我發現那個 IP 是 server 自己的 ephemeral IP lol
XDDDDD 差點報警殺了 127.0.0.1
還好 AI 沒有自動報警
我要來重開機器囉,釋放一下 swap
Done
跟我們遇到的有點像,所幸對方只打一下下

駭客發動長達5小時慢而低調的DDoS攻擊以規避偵測 | iThome https://share.google/4bAlHp0vYxSyCsZPU
ronnywang 16:24:16
主力採用 GCP asia-east1 租用 VM 的話,是不是有機會報警告妨害電腦使用,然後讓警察局去跟 Google 發公文要出該時間的該 IP 使用帳號,看有沒有機會抓出兇手本人?
mrorz 16:58:39
欸我發現那個 IP 是 server 自己的 ephemeral IP lol
ronnywang 16:59:00
XDDDDD 差點報警殺了 127.0.0.1
ronnywang 17:02:40
還好 AI 沒有自動報警
2026-05-05
mrorz 01:54:57
Replied to a thread: 2026-05-04 15:14:56
我要來重開機器囉,釋放一下 swap
mrorz 02:04:20
Done
mrorz 17:22:55
HackMD
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -
2026-05-06
mrorz 10:04:14
*【防火牆誤擋事件說明】2026/5/4–5/6*

*事件起因*
為應對 5/4 的 DDoS 攻擊(攻擊者透過大量爬蟲打 article/reply 頁面,間接造成 SSR → API 過載),我們於 5/4 14:41 及 5/5 期間加強了 Cloudflare WAF 設定,包含:
• 封鎖已知攻擊 ASN(Datacamp、M247、GTT 等)
• 新增 api.cofacts.tw POST /graphql 的 rate limiting
• 啟用 Super Bot Fight Mode(SBFM; likely / definitely automated → managed challenge)
*誤擋影響*
上述設定過於嚴格,導致合法的程式化 API 存取也被攔截(managed challenge),影響範圍:
• *rumors-site SSR*:Cloud Run 的 server-side rendering 呼叫 API 時 UA 為 `node`,被 SBFM 判定為自動化機器人,約 135,000+ 次請求受影響
• *Rate limiting*:同一批 SSR 流量同時觸發 rate limit,約 297,000+ 次
• 第三方 chatbot(趨勢科技防詐達人、美玉姨等)的 API 呼叫也部分受影響
影響期間:*2026/5/4 下午 2:41 ~ 5/6*(視各服務而定,部分 challenge 可能被 bypass)

*修復措施*
5/6 已新增 WAF custom rule「Allow automated access for API」,針對 api.cofacts.tw, admin-api.cofacts.tw 的 POST / OPTIONS / DELETE 請求跳過 SBFM 與 rate limiting,誤擋情況已解除。

後續計劃導入 Cloudflare One token 驗證,作為 API 端點更根本的存取控制機制。

如有發現任何服務異常尚未恢復,請告知 :pray:
mrorz 10:04:14
*【防火牆誤擋事件說明】2026/5/4–5/6*

*事件起因*
為應對 5/4 的 DDoS 攻擊(攻擊者透過大量爬蟲打 article/reply 頁面,間接造成 SSR → API 過載),我們於 5/4 14:41 及 5/5 期間加強了 Cloudflare WAF 設定,包含:
• 封鎖已知攻擊 ASN(Datacamp、M247、GTT 等)
• 新增 api.cofacts.tw POST /graphql 的 rate limiting
• 啟用 Super Bot Fight Mode(SBFM; likely / definitely automated → managed challenge)
*誤擋影響*
上述設定過於嚴格,導致合法的程式化 API 存取也被攔截(managed challenge),影響範圍:
• *rumors-site SSR*:Cloud Run 的 server-side rendering 呼叫 API 時 UA 為 `node`,被 SBFM 判定為自動化機器人,約 135,000+ 次請求受影響
• *Rate limiting*:同一批 SSR 流量同時觸發 rate limit,約 297,000+ 次
• 第三方 chatbot(趨勢科技防詐達人、美玉姨等)的 API 呼叫也部分受影響
影響期間:*2026/5/4 下午 2:41 ~ 5/6*(視各服務而定,部分 challenge 可能被 bypass)

*修復措施*
5/6 已新增 WAF custom rule「Allow automated access for API」,針對 api.cofacts.tw, admin-api.cofacts.tw 的 POST / OPTIONS / DELETE 請求跳過 SBFM 與 rate limiting,誤擋情況已解除。

後續計劃導入 Cloudflare One token 驗證,作為 API 端點更根本的存取控制機制。

如有發現任何服務異常尚未恢復,請告知 :pray:
  • 👍2
  • 💡1
mrorz 21:21:49
是說我在查 disk usage 的時候發現我們 production 機器(包含 elasticsearch)的 disk type 開錯了,之前文件裡面是打算開 pd-balanced,但實際開的時候開成預設的 pd-standard。

理論上因為我們系統裡面有一台 elasticsearch 他應該要是 pd-balanced 比較好,而且也沒有很貴(100GB 一個月 10USD 而已)。如果沒有什麼其他想法,那我今天凌晨大概停幾個 15min 來升級他唷
現在要準備把 instance 關閉,全系統會下線 15min 左右唷
系統重啟完成,檢查中
[維護完成] Production disk 升級**

今晚將 `cofacts-prod` 的開機硬碟從 pd-standard (HDD) 升級至 pd-balanced (SSD),停機時間約 10 分鐘。

*變更內容*
- Disk:50 GB pd-standard → 70 GB pd-balanced
- 費用:~$2/mo → ~$7/mo

*效果*
- 讀取延遲:~67 ms → *~0.9 ms*(快約 70 倍)
- 空間:由 46 GB 可用空間增加至 30 GB 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
mrorz 21:21:49
是說我在查 disk usage 的時候發現我們 production 機器(包含 elasticsearch)的 disk type 開錯了,之前文件裡面是打算開 pd-balanced,但實際開的時候開成預設的 pd-standard。

理論上因為我們系統裡面有一台 elasticsearch 他應該要是 pd-balanced 比較好,而且也沒有很貴(100GB 一個月 10USD 而已)>
現在要準備把 instance 關閉,全系統會下線 15min 左右唷
系統重啟完成,檢查中
[維護完成] Production disk 升級**

今晚將 `cofacts-prod` 的開機硬碟從 pd-standard (HDD) 升級至 pd-balanced (SSD),停機時間約 10 分鐘。

*變更內容*
- Disk:50 GB pd-standard → 70 GB pd-balanced
- 費用:~$2/mo → ~$7/mo

*效果*
- 讀取延遲:~67 ms → *~0.9 ms*(快約 70 倍)
- 空間:由 46 GB 可用空間增加至 30 GB 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
2026-05-07
mrorz 02:06:01
Replied to a thread: 2026-05-06 21:21:49
現在要準備把 instance 關閉,全系統會下線 15min 左右唷
mrorz 02:17:45
系統重啟完成,檢查中
mrorz 02:31:09
Replied to a thread: 2026-05-06 21:21:49
[維護完成] Production disk 升級**

今晚將 `cofacts-prod` 的開機硬碟從 pd-standard (HDD) 升級至 pd-balanced (SSD),停機時間約 10 分鐘。

*變更內容*
- Disk:50 GB pd-standard → 70 GB pd-balanced
- 費用:~$2/mo → ~$7/mo

*效果*
- 讀取延遲:~67 ms → *~0.9 ms*(快約 70 倍)
- 空間:由 46 GB 可用空間增加至 30 GB 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
  • 👍2
2026-05-09
mrorz 19:53:01
Replied to a thread: 2026-05-04 15:14:56
跟我們遇到的有點像,所幸對方只打一下下

駭客發動長達5小時慢而低調的DDoS攻擊以規避偵測 | iThome https://share.google/4bAlHp0vYxSyCsZPU
iThome
資安業者DataDome揭露一波長達5小時、逾24.5億次請求的DDoS攻擊,駭客企圖以分散式低頻節奏規避單一IP限速偵測
2026-05-10
mrorz 14:51:25
下週會議移動到 5/15 (五) 8:00pm 唷
  • 👍1
@bil 我們週五是線上嗎?應該不會有人在 NPO Hub?
線上喔
mrorz 14:51:25
下週會議移動到 5/15 (五) 8:00pm 唷
@bil 我們週五是線上嗎?應該不會有人在 NPO Hub?
線上喔
2026-05-12
mrorz 18:26:31
@bil 我們週五是線上嗎?應該不會有人在 NPO Hub?
2026-05-13
bil 02:22:42
線上喔
2026-05-15
mrorz 12:55:49
HackMD
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -