Spam – Gea-Suan Lin's BLOG

Fake GitHub Star 的生意

昨天在 Hacker News 首頁上看到「Tracking the Fake GitHub Star Black Market (dagster.io)」這篇，原文在「Tracking the Fake GitHub Star Black Market with Dagster, dbt and BigQuery」這邊。

作者群想要偵測 GitHub 上面 fake star 的行為，所以就跑去找黑市買，然後找到了兩家，Baddhi Shop (1000 個 $64) 與 GitHub24 (每個 €0.85，大約是 $0.91)，價錢差異很大，「品質」差異也很大：貴的 star 在一個月後還是存在，而便宜的看起來有一些有被 GitHub 偵測到而清除掉：

A month later, all 100 GitHub24 stars still stood, but only three-quarters of the fake Baddhi Shop stars remained. We suspect the rest were purged by GitHub’s integrity teams.

接下來就是想要系統化分析，切入點是 GH Archive 這個服務，可以直接下載 GitHub 全站上的 public evnets 資料：

GH Archive is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis.

想要偵測兩種不同的 fake account，第一種是 obvious fake account，定義成這樣：

Created in 2022 or later
Followers <=1
Following <= 1
Public gists == 0
Public repos <=4
Email, hireable, bio, blog, and twitter username are empty
Star date == account creation date == account updated date

從定義就可以看出來完全就是灌水帳號，開出來就沒在動的。從 screenshot 可以看出這種帳號長的都一樣：

另外一種則是透過演算法去分析，這邊拿 unsupervised clustering 類的演算法分析出來的結果，可以看到抓到很多：

最近 NN 類的 machine learning 演算法太多，看到這些傳統的 machine learning 演算法還是覺得頗新鮮的...

關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目：「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP，加上 ISP 沒有擋 TCP port 25 就倒不是問題，整個最難的點在於怎麼送信，因為會常常被標成 spam...

最基本要設定的東西大概是 SPF，但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗，Gmail 擋信的機率低不少，微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES，沒有低消所以個人用起來不貴...

限制流量的方式 (rate limit)

在 Lobsters Daily 上看到這篇 2017 年的文章，Figma 的工程師講怎麼做 rate limit：「An alternative approach to rate limiting」，只要大一點的站台就會遇到 spammer 之類的攻擊，就會希望實做自動化的機制擋住 spammer。

文章裡面提到了三種方式，第一種 (類) 提到了經典的 Token bucket 與 Leaky bucket，這邊文章提供的演算法是讓每個使用者都會有一筆資料紀錄在 Redis 裡面 (這邊的用法可以抽換換成 Memcached)，裡面記錄了最後一次的 access time 以及還剩下多少 token 可以用，接下來就可以照時間計算 token 的補充與消耗：

但這個演算法的缺點是 race condition，需要另外設計一些機制確保操作的 atomic：

不過大多數的實做就算不管 atomic 也還行 OK，只是會比較不精確一點。

第二個方法他叫做 Fixed window counters，這個方法把時間切齊為單位 (像是 60 秒為一個 window)，所以可以把起點的時間也放到 key 裡面，然後 value 就是數量：

這個作法的好處就是簡單，而且 Redis 與 Memcached 都有提供 atomic 的 +1 操作。但缺點是可能會發生兩倍以上的 request，像是 5 reqs/min 的限制有可能會有連續的一分鐘內達到 10 reqs/min：

不過我覺得就 antispam 來說算是夠用了，當年 (大概是 2007 或是 2008 年？) 在 PIXNET 時用 C 寫 Apache module 就是把資料丟到 Memcached 裡面就是這樣實做的，然後每次學術網路的實驗室跑來掃站的就會自動被擋 XDDD

第三種方式他們稱作 Sliding window log，就是把每個 request 的 timestamp 都存起來，這個部份用 Redis 的資料結構會比用 Memcached 方便一些：

這個方式在控制上更精確，不過空間成本上就高很多... 這樣算是把常見的實做方式都提到了。

這幾天 blog 被掃，用 nginx 的 limit_req_zone 擋...

Update：這個方法問題好像還是不少，目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面，結果 CPU loading 變超高，從後台可以看到常常滿載：

看了一下是都是從 Azure 上面打過來的，有好幾組都在打，IP address 每隔一段時間就會變，所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit，搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個，就設起來暫時用這個方式擋著，大概是這樣：

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable，但這邊用 429 應該更正確，從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明：

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來，目前比較困擾的是需要 copy & paste try_files 與 FastCGI 相關的設定：

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot，至少在現階段應該還是有用的...

如果之後有遇到其他手法的話，再見招拆招看看要怎麼再加強 :o

Cloudflare 改用自己的 CAPTCHA 服務 hCaptcha

Cloudflare 從 Google 的 reCAPTCHA 改用自家的 hCaptcha：「Moving from reCAPTCHA to hCaptcha」。

看起來其實就是錢的問題，reCAPTCHA 要收費了，而以 Cloudflare 的量會太貴：

Earlier this year, Google informed us that they were going to begin charging for reCAPTCHA. That is entirely within their right. Cloudflare, given our volume, no doubt imposed significant costs on the reCAPTCHA service, even for Google.

另外 hCaptcha 有提供免費版本給一般網站用，剛出來這幾天等白老鼠寫心得後，再決定要不要跳進去測試...

用 PoW 當作防機器人的方式

看到「wehatecaptchas」這個服務試著用 PoW (Proof of work) 擋機器人...

這個方式不需要像 Google 的 reCAPTCHA 那樣蒐集大量行為 (對隱私不利)，也不需要解一堆奇怪的圖片問題。

就 CAPTCHA 最常用的領域，也就是擋 spam 這件事情來說，PoW 這樣的單一方式應該是不夠，但可以當作綜合方法裡面的一種...

引用自己論文的問題...

Nature 上點出來期刊論文裡自我引用的問題 (這邊的自我引用包括了合作過的人)：「Hundreds of extreme self-citing scientists revealed in new database」。

開頭舉了一個極端的例子，Vaidyanathan 的自我引用比率高達 94%，而學界的中位數是 12.7%，感覺是有某種制度造成的行為？

Vaidyanathan, a computer scientist at the Vel Tech R&D Institute of Technology, a privately run institute, is an extreme example: he has received 94% of his citations from himself or his co-authors up to 2017, according to a study in PLoS Biology this month. He is not alone. The data set, which lists around 100,000 researchers, shows that at least 250 scientists have amassed more than 50% of their citations from themselves or their co-authors, while the median self-citation rate is 12.7%.

會想要提是因為想到當年 Google 的經典演算法 PageRank，就是在處理這個問題... 把 paper 換成 webpage 而已。

用 CleanTalk 擋論壇的廣告...

看到 Hacker News 上「You probably don’t need ReCAPTCHA (kevv.net)」這篇在討論 reCAPTCHA (原始文章在「You (probably) don’t need ReCAPTCHA」這篇)，裡面除了認為 reCAPTCHA harmful 的觀點還 ok 外，其他的觀點我覺得都無法讓人認同...

因為看到 reCAPTCHA 而想到已經用了 CleanTalk 一陣子，效果還不錯，所以寫一篇講一下...

起因是維護「FJC 華語社群」這個站台，這是一個使用 phpBB 架設的站台，為了方便，我透過 RSS + IFTTT，當論壇上有新文章時就會自動貼到 Line 群組上面...

為了避免論壇上面有 spam，我有針對註冊開 reCAPTCHA，但發現還是有不少「全人工註冊」的帳號會貼文，所以就得找更精準的服務來用... 後來在 phpBB 網站上翻到 CleanTalk 這個服務，對於在「CleanTalk Anti-Spam Installation Manuals」這頁看到支援的軟體只要 USD$8/year/site，從一月用到現在超過五個月了，就沒遇到 spam 了...

機制上他會透過 client database 分析他們自己的 spam 資料庫，另外在發文時他也會分析文章內容是不是 spam，所以裝上去之後兩關都有過濾機制...

類似的服務還有 Akismet，不過畢竟是知名品牌，費用相較起來貴不少...

用 procmail 判斷信件是否有過 DKIM Signature

這年頭自己維護 mail account 的情況比較少了，所以資料不太好找，測出來寫下來讓其他人也可以用...

這邊說的是透過 procmail 判斷信件是否符合 DKIM Signature，然後加上 header。

如果是 Ubuntu 環境，首先在要裝上 python-dkim (不是 python3-dkim)：

sudo apt install -y python-dkim

我們需要裡面的 dkimverify 程式透過 stdin 讀信件進去，然後透過 exit code 告知有沒有成功。

對應的 .procmailrc 是這樣：

# DKIM
:0
* ^DKIM-Signature:
{
    :0BHWf
    * ? /usr/bin/dkimverify
    | /usr/bin/formail -A "X-Procmail-DKIMVerify: pass"
    :0Ef
    | /usr/bin/formail -A "X-Procmail-DKIMVerify: bad"
}

裡面大多數的設定說明可以參考 procmailrc 的 manpage，這邊只就 magic keyword 說明一下。

BH 是 body 與 header 都要判斷，而 f 是把程式當作 filter，把信件從 stdin 丟進去，然後將 stdout 輸出的結果往下繼續處理，W 是看程式執行執行結果 (看 exit code) 決定要不要跑設定的指令。

E 表示上面的那格沒有跑到的話就跑自己這格，類似於 if-then-else 裡面的 else。

我發現這個需求在我的 issue tracking system 內是 2016 年 10 月開的，總算解掉他了...

批評 Medium 不適合當作 Blogging Platform...

這篇文章批評了 Medium 不適合當作 Blogging Platform：「Medium is a poor choice for blogging」。

文章裡提到的情況我之前也常遇到 (然後默默的點 X 關掉...)，我是還蠻建議把 [*.]medium.com 放到 Google Chrome 的 javascript 禁止清單裡面，這樣畫面會乾淨很多，而且也省很多 CPU 資源...

不過自訂網域的部分就沒辦法用這個方式擋了，有點可惜...