AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了,AWS 推出了 Amazon Route 53 Resolver DNS Firewall:「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver,沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段),先前一直沒有辦法解決 data leak 的問題,也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋),然後自己架設兩台 DNS resolver 過濾,現在 Route 53 Resolver 支援 DNS Firewall,提供 allowlist 與 blocklist 這兩個功能使用,總算是把這件事情解的比較乾淨了:

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用,包括了 malware 與 botnet:

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...

英國的 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)。

T-Mobile US 打算要賣使用者的瀏覽記錄了

全美第二大的 T-Mobile US 打算要賣使用者的瀏覽記錄了,除非你登入進去選擇退出:「T-Mobile to Step Up Ad Targeting of Cellphone Customers」,Hacker News 上的討論則可以看「T-Mobile to share customers' data with advertisers unless they opt out (thehill.com)」這邊。

The No. 2 U.S. carrier by subscribers said in a recent privacy-policy update that unless they opt out it will share customers’ web and mobile-app data with advertisers starting April 26.

這次的改變包括了 2020 年併購 Sprint 的使用者:

T-Mobile’s new policy will also cover Sprint customers acquired through the carriers’ 2020 merger. Sprint had previously shared similar data only from customers who opted into its third-party ad program.

所以連在美國都有 DNS over HTTPS (或是 DNS over TLS) 與 ESNI 需求了...

Wikimedia Commons 發現的印度異常流量

Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個,維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片,而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量:

由於 User-AgentReferer 都沒有資訊,可以確認這不是瀏覽器造成的流量,但也因為沒有有用的資訊,變得很難查。

接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關,因為在被 ban 後有很多使用者會去找替代的服務,而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。

所以他們把熱門的替代服務都看了一輪,也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上,所以開始交叉測試:在開 app 後就去 Hive 掃 HTTP log,然後找到一個 app。

後來為了要確認是不是這個 app,他們架了一組 DNS server 記錄查詢的網域名稱,看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱,而不出所料的確認了,而且真的就是在啟動時有抓,但是沒有顯示在畫面上。

接下來就是想辦法聯絡開發團隊,而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。

另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣,有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛,而且反應了很多次都沒用,然後他就把圖片換成「Netscape Now」,然後十五分鐘內就被解決了:

At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.

Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.

找了一下圖片,看起來應該是類似這種的圖:

要直接反擊讓人會痛... XD

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

Amazon Route 53 支援 DNSSEC

也是個大家等蠻久的功能,AWS 總算在 Amazon Route 53 上推出 DNSSEC 了:「Announcing Amazon Route 53 support for DNSSEC」。

他需要掛 AWS KMS,這部份會有一些費用在裡面,不過應該是還好...

不過 web console 目前有個明顯的缺點:透過 Route 53 註冊的網域,又用 Route 53 自家服務的情況下,設定 DNSSEC 的整合沒有做的很好,不能直接快速設定。

現在得自己設定演算法,然後複製 public key 到另外一邊,當你有一堆網域要設定的時候就會覺得很煩了...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)

如同在「升級跳板機」這邊提到的,這台跳板機是跑 Ubuntu 20.04,加上需要跑 PPPoE,我就遇到透過 PPPoE 拿到的 DNS 無法套用的系統內。

這點在「add pppoe support to systemd-networkd」這邊有被提到,而且看起來 Debian 那邊已經套用 patch 上去了,但 Ubuntu 這邊似乎還沒...

我看了看還是決定先暫時先回頭用 resolvconf,可以只用指令解決:

sudo apt install -y resolvconf
sudo systemctl disable systemd-resolved

然後重開確認後就可以收工...

抓出正在使用的 DNS Server

Hacker News 上看到的方式:「Which DNS」,另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP,像 HiNet168.95.1.1 這種 DNS server 後面都有一堆 resolver,這個方式可以知道出去的 IP 是哪個,可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務,不過查了一下沒找到之前有印象的那個,反倒是查到另外一組可以用的:「Introducing a New whoami Tool for DNS Resolver Information」。