#cofacts
2026-05-02
mrorz
16:51:28
由於 RightsCon 取消了,我們下週二會開會唷~
chewei 哲瑋
2026-05-03 02:25:12
這裡有一串討論
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中
https://g0v-tw.slack.com/archives/C092S5VUP6Z/p1777725088733109
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中
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
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中
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
是否有台灣與會者,有想要於台灣這邊分享議程或推廣方式,目前還在交流想法中
https://g0v-tw.slack.com/archives/C092S5VUP6Z/p1777725088733109
coldplay5566
大家!應該都有看到RightsCon 取消舉辦的消息!!
事出臨時,而且也已經很靠近Summit,但我想我們或許可以做點什麼~也想問問大家意見:face_holding_back_tears:
稍早在臉書跟 @mglee 討論,提到或許可以協助接受 RightsCon 已經錄取的議程之類的(利用目前還空著的午休時段?)~
或是大家有什麼想做的事嗎!!
- Forwarded from #summit-2026
- 2026-05-02 20:31:28
- 🙏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/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
ronnywang
2026-05-04 16:24:16
主力採用 GCP asia-east1 租用 VM 的話,是不是有機會報警告妨害電腦使用,然後讓警察局去跟 Google 發公文要出該時間的該 IP 使用帳號,看有沒有機會抓出兇手本人?
mrorz
2026-05-04 16:58:39
欸我發現那個 IP 是 server 自己的 ephemeral IP lol
ronnywang
2026-05-04 16:59:00
XDDDDD 差點報警殺了 127.0.0.1
ronnywang
2026-05-04 17:02:40
還好 AI 沒有自動報警
mrorz
2026-05-05 01:54:57
我要來重開機器囉,釋放一下 swap
mrorz
2026-05-05 02:04:20
Done
mrorz
2026-05-09 19:53:01
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 釋放積累的記憶體
*事件時間軸*
• 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 釋放積累的記憶體
ronnywang
2026-05-04 16:24:16
主力採用 GCP asia-east1 租用 VM 的話,是不是有機會報警告妨害電腦使用,然後讓警察局去跟 Google 發公文要出該時間的該 IP 使用帳號,看有沒有機會抓出兇手本人?
mrorz
2026-05-04 16:58:39
欸我發現那個 IP 是 server 自己的 ephemeral IP lol
ronnywang
2026-05-04 16:59:00
XDDDDD 差點報警殺了 127.0.0.1
ronnywang
2026-05-04 17:02:40
還好 AI 沒有自動報警
mrorz
2026-05-05 01:54:57
我要來重開機器囉,釋放一下 swap
mrorz
2026-05-05 02:04:20
Done
mrorz
2026-05-09 19:53:01
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
02:04:20
Done
mrorz
15:25:03
Replied to a thread: 2026-05-04 15:14:56
原本報告方向錯誤,昨晚修正為此報告
https://g0v.hackmd.io/4kQ9ihNOQfmtYvGcBkrKJg#2026-05-04-DDoS-%E6%94%BB%E6%93%8A%E8%AA%BF%E6%9F%A5%E5%A0%B1%E5%91%8A
https://g0v.hackmd.io/4kQ9ihNOQfmtYvGcBkrKJg#2026-05-04-DDoS-%E6%94%BB%E6%93%8A%E8%AA%BF%E6%9F%A5%E5%A0%B1%E5%91%8A
- 💡1
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:
*事件起因*
為應對 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:
*事件起因*
為應對 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 來升級他唷
理論上因為我們系統裡面有一台 elasticsearch 他應該要是 pd-balanced 比較好,而且也沒有很貴(100GB 一個月 10USD 而已)。如果沒有什麼其他想法,那我今天凌晨大概停幾個 15min 來升級他唷
mrorz
2026-05-07 02:06:01
現在要準備把 instance 關閉,全系統會下線 15min 左右唷
mrorz
2026-05-07 02:17:45
系統重啟完成,檢查中
mrorz
2026-05-07 02:31:09
[維護完成] 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 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
今晚將 `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 而已)>
理論上因為我們系統裡面有一台 elasticsearch 他應該要是 pd-balanced 比較好,而且也沒有很貴(100GB 一個月 10USD 而已)>
mrorz
2026-05-07 02:06:01
現在要準備把 instance 關閉,全系統會下線 15min 左右唷
mrorz
2026-05-07 02:17:45
系統重啟完成,檢查中
mrorz
2026-05-07 02:31:09
[維護完成] 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 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
今晚將 `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: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 剩餘(較寬鬆)
- 所有服務已確認恢復正常運作
今晚將 `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
2026-05-10
mrorz
14:51:25
下週會議移動到 5/15 (五) 8:00pm 唷
- 👍1
mrorz
2026-05-12 18:26:31
@bil 我們週五是線上嗎?應該不會有人在 NPO Hub?
線上喔
mrorz
14:51:25
下週會議移動到 5/15 (五) 8:00pm 唷
mrorz
2026-05-12 18:26:31
@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 -