「SMS 認證」被電信商 (以及第三方) 拿來套利的市場

Hacker News 上看到「Twitter Lost $60M a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS (commsrisk.com)」這篇,內文報導是這裡:「Elon Musk Says Twitter Lost $60mn a Year Because 390 Telcos Used Bot Accounts to Pump A2P SMS」。

簡訊的實際成本極低,但利潤超級高,發送方與接收方都有極大的獲利空間。

而這邊提到的 SMS pumping 的方式就是電信商自己做,或是電信商與第三方合作,利用各種發簡訊的方式 (內容不重要),讓 app 端要付出大量的簡訊成本,進而產生出大量的利潤。

Twilio 的「SMS Traffic Pumping Fraud」這頁就有這張圖:

簡訊的特點是很好 scale,你無法同時間接大量的電話,但可以同時間收大量的簡訊。在「SMS Fraud is costing you more than you realize」這邊也有提到這個問題。

這個問題在去年年底在我們自家的服務上就有看到跡象 (東南亞市場頗明顯),當時搜尋有一些討論,而現在看起來 Elon Musk 這次吵應該又會有更多熱度...

話說這樣演化下去,SMS 認證的退場又多了一個理由,除了 SS7 在資安上的安全問題外,看起來成本問題也會跑進來。

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的,但的確是漏掉這個消息,早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式:「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (LinodeDigitalOcean) 的算法了,先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算):

Data ingress will now be free.

再來是 traffic pool 的概念,現在每個帳號的流量會統一計算,而非每台機器自己計算:

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic,這點有點放送的感覺:

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了,不管什麼地區都是 $0.01/GB:

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點:依照他的收費標準,超量 1TB 的流量需要付 $10 的費用,但你可以多租一台 $5/mo 的機器,這個方式提供了 1TB 的流量到 traffic pool 裡面。

AWS 在同一區不同 AZ 頻寬費用的特別地方

剛好在處理 AWS 同一個 region 下不同 AZ 之間的傳輸費用,跟帳單互相比對,查了以後才發現跟想像中不一樣,這邊以 EC2 為例子,可以參考「Amazon EC2 On-Demand Pricing」這頁裡面的說明。

從 Internet 端進 AWS 的流量是不計費的:

Data Transfer IN To Amazon EC2 From Internet
All data transfer in $0.00 per GB

但從 AZ 進到另外一個 AZ 時,in 與 out 都要收費:

Data transferred "in" to and "out" from Amazon EC2, Amazon RDS, Amazon Redshift, Amazon DynamoDB Accelerator (DAX), and Amazon ElastiCache instances, Elastic Network Interfaces or VPC Peering connections across Availability Zones in the same AWS Region is charged at $0.01/GB in each direction.

所以直接用 US$0.01/GB 的計算是不夠的,得用 US$0.02/GB 來計算。

同樣的,如果是 Public IP 與 Elastic IP 也都是雙向收費,跨 VPC 也是雙向收費,所以都要用 US$0.02/GB 來算:

IPv4: Data transferred “in” to and “out” from public or Elastic IPv4 address is charged at $0.01/GB in each direction.
IPv6: Data transferred “in” to and “out” from an IPv6 address in a different VPC is charged at $0.01/GB in each direction.

這個月 GitHub 的不穩問題,都是 mysql1 這個 cluster 的鍋...

GitHub 針對了這個月的四次 downtime 說明,大致上都跟 mysql1 這組 cluster 有關:「An update on recent service disruptions」,這是 Keith Ballinger 發的文章,找了一下掛的頭銜是 SVP of Engineering at GitHub。

文章裡提到的 mysql1 在「Partitioning GitHub’s relational databases to handle scale」這邊可以看到一些資訊 (我在「GitHub 的 MySQL 架構與數字」這邊也有提到),基本上有 ProxySQL + Vitess 兩套方案在 scale,但可以看出來主資料庫本身還是有很大的 loading 在上面跑。

這次的問題是 mysql1 看起來這次遇到了效能上的瓶頸,不過還是沒找到原因,這可以從這幾次的說明看出來,從第一次的 outage:

The incident appeared to be related to peak load combined with poor query performance for specific sets of circumstances.

第二次的:

The following day, we saw the same peak traffic pattern and load on mysql1. We were not able to pinpoint and address the query performance issues before this peak, and we decided to proactively failover before the issue escalated.

第三次的:

While we had reduced load seen in the previous incidents, we were not fully confident in the mitigations.

In this third incident, we enabled memory profiling on our database proxy in order to look more closely at the performance characteristics during peak load.

到最近第四次的:

In order to reduce load, we throttled webhook traffic and will continue to use that as a mitigation to prevent future recurrence during peak load times as we continue to investigate further mitigations.

可以看到基本上還沒完,之後再遇到問題時應該還是會把 webhook traffic 拿出來開刀...

截聽本機的 HTTPS 內容

Hacker News 上看到「Decrypting your own HTTPS traffic with Wireshark」這篇,就是用 SSLKEYLOGFILE 請 library 把 TLS 相關的 key 與 random number 寫到檔案裡面讓 Wireshark 可以解讀拿來用。對應的討論在「Decrypting your own HTTPS traffic with Wireshark (trickster.dev)」這邊。

看起 OpenSSL 系列的 library 都有支援這個變數,另外 NSS 也支援這個變數,所以常見的程式應該都包含在內了...

比起 MITMA 類的方式 (像是 mitmproxy),這個方式會更接近真實的情境,不另外產生 CA 與 key,不過缺點就是使用的情境就再受限一些,算是除了 MITMA 類方式的另外一個方案...

Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-southeast-1 (Singapore) 的 EC2 測試,直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令,其他的是出自我自己 wiki 上的 Ubuntu 這頁),然後再重開機:

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s,另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上,這樣可以捲回去看每一秒的傳輸速度,就可以看出來變化了,不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline):

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間,但這跟你機器吃的網路資源有關,我就決定只用 baseline 來做決策了,這樣可能會多花一點錢,但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead,所以就順便查了一下資料:

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候):「OpenVPN performance」。
  • SSH 也有些 overhead,大約是 6% (把來回的封包都算進去):「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead,但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的,會有 10% packet loss,改用預設的 CUBIC 會好很多,大約 1% 到 2% 左右。

綜合這些測試,我自己抓了 35% 的 overhead 來推估,最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量,大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠,有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多,應該是不需要降...

英國的 ISP 開始記錄使用者的連線資訊

從「Two UK Broadband ISPs Trial New Internet Snooping System」這邊看到英國的 ISP 開始記錄使用者的連線資訊,簡化後的 log 樣子像是這樣:

Two unnamed broadband or mobile ISPs are reportedly helping the UK Home Office and the National Crime Agency (NCA) to trial a new internet snooping system on their customers, which is being conducted as part of the controversial 2016 UK Investigatory Powers Act (aka – snoopers charter).

加上「T-Mobile US 打算要賣使用者的瀏覽記錄了」這篇,繼續推廣 DNS over HTTPDNS over TLS,以及 ECH (Encrypted Client Hello)。

Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD

OpenBGPD 接 AWS Direct Connect 時只讓單區路由的方法

算是繼上篇「用 pfSense 接 AWS Direct Connect (Public VIF) 的方式」的改善,上篇的方法設定完後預設會是全部都會 routing 進來。也就是說,如果你接到新加坡區,美東 routing 也會進來。

這可能是你要的,但也可能不是你要的,所以找了一下方法,在 AWS 的文件裡面有提到可以透過 BGP community 控制這些 routing:「Routing policies and BGP communities」。

第一個方向是從 pfSense 送出去的封包,這個要過濾從 BGP 送進來的 routing table:

AWS Direct Connect applies the following BGP communities to its advertised routes[.]

把:

allow from 1.2.3.4

改成:

allow from 1.2.3.4 community 7224:8100

另外一個是讓 AWS 不要把我們的 network 送到其他區,這是在 network 上加上 BGP community tag:

You can apply BGP community tags on the public prefixes that you advertise to Amazon to indicate how far to propagate your prefixes in the Amazon network, for the local AWS Region only, all Regions within a continent, or all public Regions.

把本來的:

network 1.2.3.4/30

變成:

network 1.2.3.4/30 set community 7224:9100

先這樣搞,用 mtr 看了一下應該沒錯...

Fastly 觀察到因 COVID-19 產生的流量上升資料

因為 COVID-19 的關係,可以預期網路的流量一定會大幅提昇,但實際上是多少總是需要一些數據才能想像...

剛剛看到 Fastly 放出了他們觀察到因為 COVID-19 而產生的流量變化:「How COVID-19 is affecting internet performance」。

從 2020 年二月與三月相比,可以看到許多區域的流量都有大幅成長,尤其是重災區的義大利與英國,不過這邊沒有給與 2019 三月的比較 (YoY):

另外是這些流量成長的種類,可以看到 streaming、數位媒體與教育類的流量大幅成長:

在網路速度的部份,可以看到大多數的地區是下降的,但加州沒什麼影響,而日本反而是上升的,應該可以解讀為這兩個地區平常就有夠多的容量,所以真的有爆量而用到的時候反而不會是瓶頸?

接下來幾個月應該會更嚴峻...