分類: 其他

結論寫在前面：2026 年 9 月 11 日凌晨往前算大約三到四個月左右，這個 blog 可能會不定時封鎖某些浮動 IP 的訪客，然後可能又會忽然恢復。原因：我的防火牆設定寫錯了……

不小心被封的人應該會看到，我這個 blog 有安裝 Wordfence 這個外掛來幫我做一些基本的攻擊防護；用的是免費版，所以一些功能相對陽春，但防那些想要亂試的登入者應該是綽綽有餘了：我這個 blog 只有一個發文帳號，帳號名也不是顯示在上面作者欄的那個名字，而且我還開了 Wordfence 提供的 2FA 驗證，就算猜中帳號也不會有 2FA 驗證碼可以打。

由於 Wordfence 對於一些攻擊會將其 IP 封鎖一段時間，我時不時會上來巡一下看最近有沒有擋到誰，看到有點過份的我會整理一下之後永封。就是這個整理動作出了問題：前一次整理 (大約是五、六月左右的事) 有把一些 IP 相近的攻擊者寫成 CIDR mask 的範圍 (畢竟這看起來要嘛是 botnet 感染了一票附近的電腦，要嘛是攻擊者本身是浮動 IP，那擋掉一小塊應該沒差)，但我記錯斜線後面的數字是數哪邊了：如果我要封 10.10.10.0 到 10.10.10.255 這個範圍的話，我應該要寫成 10.10.10.0/24，表示前面這個 IP 從左邊數過來 24 個 bit 要對，但是我寫成 10.10.10.0/8，以為是指定從右邊數過來 8 個 bit 可以任意；後一種的封鎖實際上封掉了 10.0.0.0 到 10.255.255.255 這一大塊區域，也就是誤封到了許多沒有要封的人。

然後就是在今天 (9 月 11 日) 我要上來看個東西時突然跳了封鎖頁面出來，嚇了一跳的我趕快進後台看有沒有什麼事發生 (這個 blog 是放在 google 雲上面，我可以直接登入機器看狀況)，但在資料庫裡翻了半天也沒有什麼特別的發現；回頭重新整理時可能是碰到正好跳到沒封的 IP 了所以讓我登了進來 (我還怕說是不是有什麼別的地方把我這個網址隨便導向，就藉著我在後台機器上弄了個簡單的小測試證明了這個網域沒被導走)，然後在看防火牆永封設定的時候才突然驚覺：欸這個 CIDR mask 好像怪怪的，仔細看了看才發現我寫錯邊……而且果不其然，有在這個時間附近觸發的規則都是原本該寫 /24 但被我寫成 /8 導致誤封一大票的項目。嘛，本來這個整理只是我不想在 log 裡看到一大票同樣的東西而已，所以就把那一波整理的名單裡 mask 寫錯邊的項目通通刪掉了。

不知道是幸運還是不幸，今年因為各種原因沒在這裡發文章，在這之前唯一發文日期是今年的是六月底左右時我把我的 GNOSIA 心得文翻譯成英文發在這裡 (那篇從動畫在播時就開始翻，林林總總大概有半年左右的零碎時間吧)，所以其他文章的觸及可能沒有太多影響，但那篇英文心得文可能今天開始才能開始累積觸及……我後面其實還積了兩篇心得文要發，但目前都才寫了個三成左右 (因為各種原因……) 所以這個問題一直到今天撞到了才發現。唉～

喔對了，因為那篇翻譯的心得文的關係，這篇會有英文版放在下面。

---

[English Version] False Alarm…

Let me get straight to the point: In a period of time about 3 to 4 months until September 10th, 2026, this blog may randomly block visitors that are otherwise legit. The reason: I made a mistake in setting up the firewall block rule.

As those who got blocked may observe, this blog uses Wordfence plugin to do some basic attack mitigation. I’m using the free version, so there are some functions lacking, but for protecting random attacks it should suffice: there is only one post account in this WordPress installation, which is not the name shown above; and I also uses the 2FA TOTP authentication provided by Wordfence, so even if someone accidentally “guessed” the account they still don’t have the 2FA code.

Since Wordfence automatically block some attack sources for some amount of time, I would occasionally login to review the block list, and made some blocks permanent if the attack crossed some line. This is where things went wrong: the last time I review the list around May or June, there are some blocks that target some similar IPs (which, I think, were either botnets from neighboring computers, or a “floating” IP that get reallocated however often), so I collected them, rewrote them into CIDR mask form, and made it permanent. But I misremembered the meaning of the number after the slash: if I want to block 10.10.10.0 to 10.10.10.255, I should write 10.10.10.0/24 indicating there are 24 bits from the left should match, but I wrote 10.10.10.0/8 thinking the 8 bits from the right could be anything. This latter rule actually blocked 10.0.0.0 through 10.255.255.255, meaning I blocked way more IPs then I intended.

Then today (September 10th) I want to login to do something, but faced with the block screen of Wordfence. Since this blog is hosted on Google Cloud, I can access the machine from there, so I logged in, rummaging through the database, but found nothing that may be the reason. When I went back to the browser, it randomly unblocked me so I logged in WordPress from the browser (after confirming that no one is redirecting the domain name to somewhere else, with a little check that I can do when I already logged into the back end machine). I then looked at the firewall block rules, and finally realized that my CIDR mask was written wrong. Adding support to this theory, the rules having last trigger time around this time are those masks that should be /24 but I wrote /8, which means the reason I got blocked is probably somehow my “floating” IP hit those too large of a range. Since the reason I rewrote the rule is simply that I don’t want those similar IPs show up, and now I cannot even know whether these bad actors are still there, I simply removed those wrong IP ranges.

Fortunately (or maybe unfortunately), because of various reasons, there is only one post in 2026 before this post: my English translation of GNOSIA review previously written in Traditional Chinese, which I’ve been worked on when the anime is still airing, working in my free time in the span of about half of a year. I think the reachability of my old posts are not that affected, but this English translation probably suffered a lot; it probably only really “shown to the public” starting today. And I have two reviews queued up that I have only written about 30% of them (which is part of the reason I found this out today). Welp.

台灣時間 7/9 晚上到 7/10 晚上，連到本站來的人可能會有連線不一定連得上的問題。這篇文章發出時應該已經解決了，放個一兩天看還有沒有什麼狀況吧。

事情是這樣的：7/7 一早我收到信說我這個域名 *.cruciferslab.net 的 wildcard HTTPS 憑證快過期了。想說我應該早在域名剛拿到那陣子就設好自動更新的 (對，看上面憑證可以看到我是用最容易拿到的 Let’s Encrypt 憑證，我收到的這信就是他們發給我的) 所以在上班前快速連進了放那個憑證的機器¹看了一下狀況。

問題其實很簡單：我這個域名當初是從 Google Domains 註冊的，不過他們前陣子被 Squarespace 買下來了，所以設定就轉到了 Squarespace 上去。Wildcard 憑證會需要進行 DNS challenge 表示你真的是這個域名的擁有者；之前好像 Google Domain 的 DNS 還能用所以還能更新，但現在似乎不行了的樣子。於是自然想說看能不能在給 Squarespace 管的狀況下來做更新，但找了半天的結論是：Squarespace 似乎因為主力在網站建置的關係，把 HTTPS 憑證這回事給綁定在你要用他們家的建置網站裡，有的話就會自動幫你弄；要手動弄不是不行，但 DNS 他們限定在你只能用網頁介面進行更新，所以如果申請效期比較久憑證的話久久做一次是不會太麻煩，但 Let’s Encrypt 基本上是兩個月更新一次²，不給我自動化這實在很討厭……

然後找到了 reddit 上另一篇在 r/nginxproxymanager 的文章，該文章的原 PO 看起來跟我的狀況很類似，也是從 Google Domain 移到 Squarespace 然後在找方法自動設定憑證更新，不過看起來他在沒找到解決方法之下搬家到 Cloudflare 了。稍微研究了一下 Cloudflare 的設定，看起來只要把 DNS 給 Cloudflare 管理，就能用這個 plugin 設定自動更新憑證了，所以就決定這兩天把 DNS 搬進 Cloudflare 了。

開頭說的這段時間就是我把 Squarespace 的 DNS 設定解除 (主要是 DNSSEC)，把 DNS 解析主機設定成 Cloudflare，等它傳播更新完成，再在 Cloudflare 這邊把 DNSSEC 開回來的時間。中間還因為在 Cloudflare 當中的設定讓站點吃了無限重導向迴圈……³ 當然在那之後憑證更新就順利完成了。

不過這讓我在考慮一件事：Cloudflare 本身也是域名註冊商，既然 Squarespace 以網站建置為主，其他相關服務為輔，那我好像把網域註冊也搬進 Cloudflare 來能做的事會更多的樣子？(順便像現在這樣直接用他們的快取服務，這樣我不用煩一堆人一直來攻擊這裡……) 只是搬家好像一般要跟著展期一年，我這次續購還剩下半年有點不太確定要不要就這樣提前展期，還是等到年底再來搬家……？

(說起來，要說需要更新的東西，最近因為 regreSSHion 檢查了一下，發現跑這個站的這台 VM 用的映像檔的作業系統 LTS 剛到期，大概需要找個時間來升級了……預期一下這個站在近期的某個週末會停機個幾個小時吧。)

註腳

1. 不是放這個站的這台：這台用的是單一域名憑證，只需要我表示 blog.cruciferslab.net 這個域名所在機器是我的，這可以用網址回應解決；這裡出問題的是另一台機器，上面預計是要放我的其他這個域名的東西，雖然現在仍然還是施工中就是了 (倒) 既然是其他 *.cruciferslab.net 的所有網域，要的憑證就需要是 wildcard 憑證了。 ↩︎
2. Let’s Encrypt 發的憑證效期是有名的短，只有 90 天，這是他們故意設計的，要讓我們這些使用者去設定 certbot 自動更新；certbot 預設在剩 30 天時會更新，所以基本上就會是兩個月要更新一次。 ↩︎
3. 原因是 Cloudflare 他們的快取服務的 SSL 設定，預設是 Flexible 會在連向來源伺服器時用未加密 HTTP 連線，但我的這兩台機器都有設定未加密 HTTP 會自動重導向到加密 HTTPS，所以就掉進無限迴圈了。把它的設定改成 Full 以上就能解決。 ↩︎

WordPress 6.3 有原生註腳了，試用了一陣子還不錯，然後一年前這篇文章發表時我換了的另一個註腳外掛現在也撤下來了，所以稍微花了點時間來把原先用 fn 標籤寫的註腳改成 WP 的原生註腳。好在我的文章量不多所以改動量也不是很大就是了。

以下是一年前（2022/12/12）的原文：

先前用的註腳外掛結果是個一兩年沒人維護的外掛，然後原開發者因為這樣所以從 WP 外掛庫裡撤下來了。雖然不是不能用啦，但過時的外掛程式碼有沒有什麼問題確實不知道，所以決定換一個最近好像有更新維護的註腳外掛。樣式我盡量做到跟先前差不多了，不過從註腳跳回來的連結從在前面的 ↑ 變成在後面的⬆️了；這個外掛好像沒有把它放到前面的選項所以就先這樣好了。¹就用一陣子看看吧。

1. 原本的預設值是↩️，我有點覺得還是上箭頭比較對。它長得像這樣→ ↩︎

總算是終於想到來把這個地方先蓋起來了。

大家好，我是 IC。在發出這篇文章的時候是個……說好聽一點叫追夢中？的米蟲。大概一年多前離開了前一個工作，名義上是要開始做遊戲設計啦，但一年多以來實際做的事大概屈指可數 (汗)。(你看連這裡都是過了一年多才架起來的)

IC (或者這篇的發文者上寫的「全名」Isatis Crucifer) 這個名字其實是最近幾年才開始比較常用的，我比較為人所知的名字是在 PTT 的 LPH66－－高中時從本名取出來的 LPH 加上註冊 PTT 時三字母 ID 早就用光了所以隨手加的 66 這樣。(所以如果猜這個 66 是某個日期的很抱歉你猜錯了 XD)

說起名字，我現在用的 IC 這個名字跟這個地方叫做 Crucifers’ Laboratory 之間確實是有些個人中二設定在裡面的，不過這就以後有機會再提吧。(提示：和右邊看到的 Isatis 這個名字有關－－對，那個 Isatis 不是我 XD)

這裡之後預計會有的內容其實不只會有遊戲設計 (畢竟那裡現在仍然一天打漁十天曬網當中 (死))，也可能會有一些比較長一點的程式設計或數學的東西，或者－－如果心血來潮的話－－ACG 心得什麼的都在可能範圍裡。不過至少都應該會有一定量的長度在啦；如果想要看我的日常廢話，可以追蹤我的噗浪 (雖然那邊有很大一部份都是撐卡馬用的廢噗就是了)。

那第一篇文章就先這樣了。