Tag: firewall

Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了，我查資料才發現我在 2021 年的時候寫過：「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去，不過先前的產品的條件很死，遇到 CNAME 或是 DNAME 的情況，你必須事先把可能後續的 record 也放進白名單才行，所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了：

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好，但因為 CNAME 的關係，你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net。

可是這是第三方的服務，你無法控制對方怎麼切換 (沒有 API contract 的概念)，像是有時候他會跳到 Fastly：

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint，對方有可能有多個不同的點做 DR 切換，有可能 CNAME 到 AWS 的 ELB 或是 GCP 的 Cloud Load balancing 上。

所以為了「保險」，這個方式通常都是開整個 CDN 的服務，但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net)，搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念，第一個啟動的 record 是被放行的，那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行，這樣算是補強了這個問題...

CI 服務的 IP 清單

目前的 CI 大多數都是跑在 cloud 上面，而且會 scaling，所以我一直以為沒有固定的 IP address (算是我的刻板印象)，不過實際查了一下，發現商用 CI 服務是有考慮到的...

Travis CI 的說明是在「ip-addresses.md」這邊，可以透過 nat.travisci.net 這個 DNS record 取得他們的 NAT 會用到的 IP address。

另外他們會在使用前 24 小時前先公佈這組資料，所以如果你設計 cron job 更新的話可以考慮進去：

We will announce changes to this set of IP addresses with a 24 hour notice period.

CircleCI 則是再「IP ranges」這邊提供類似的方式，jobs.knownips.circleci.com、core.knownips.circleci.com 以及 all.knownips.circleci.com，另外新增的提前通知會有 30 天：

30 days notice will be given before changes are made to the existing set of IP address ranges.

GitHub Actions 則是可以在「About GitHub's IP addresses」以及「REST API endpoints for meta data」這邊拿到，在 actions 這個 key 下面有 IP address 的列表，測了一下不需要帶 token 就可以取得，不過這邊好像沒看到預先通知的時間...

其實因為這些服務還是共用 IP pool，攻擊者也可以租用這些 CI 服務在上面跑程式... 所以主要的需求還是 compliance，倒不是真的會因此變得有多安全。

Hacker News 目前搬上 Cloudflare

Hacker News 前陣子似乎是因為被打而轉移到 Cloudflare 上：

;; ANSWER SECTION:
news.ycombinator.com.   1       IN      CNAME   news.ycombinator.com.cdn.cloudflare.net.
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 172.67.5.232
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 104.22.6.236
news.ycombinator.com.cdn.cloudflare.net. 300 IN A 104.22.7.236

另外可以參考「Site report for http://news.ycombinator.com」這邊的記錄，我另外備份一份放在 archive.today 上：「Site report for http://news.ycombinator.com」。

可以看到先前是指到 209.216.230.240，然後今年 (2024) 年初的時候似乎是因為 DDoS 的關係，在骨幹上被 blackhole 掉，後來就轉到 Cloudflare 上了。

一個比較意外的是看到報告說是 FreeBSD，等之後切回去再來研究看看？

Cloudflare 的 WAF 在科技類的網站容易誤判，像是「Ask HN: Does Cloudflare block HN comments if you have code blocks in a reply?」這邊就遇到了，可以在留言裡面看到大家在研究要怎麼繞 WAF XDDD

等到切回去應該就會恢復，不過還在 Cloudflare 上的這陣子應該會繼續看到抱怨...

穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇，原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景，他需要在醫院待個幾天，而醫院有免費的 WiFi 可以上網，但限制很多，基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通，另外他有行動網路可以用 (但應該不是吃到飽的？)，可以當作在現場直接設定 bypass 機制的工具：

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH，以前幹過，但就如同 comment 裡面提到的，Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性，而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS，傳輸效率會比 TCP-based 的協定好，另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了，會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來，但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用，常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案，如果常態會遇到的話應該是會架 ocserv 來繞...

玩了一下 OpenSnitch，Linux 下的 Application Firewall

這是在 Hacker News 上的討論「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」這篇看到的，裡面一開始是提到 Mac 上面的 Little Snitch，可以針對特定應用程式設定防火牆規則，而在 Linux 上對應的解決方案則是 OpenSnitch，但一直沒有嘗試，所以就試著用看看...

套件分成兩個部分，一個是 OpenSnitch 的主程式，另外一個是 GUI 的部分。

而在 Ubuntu 22.04 上裝有點麻煩，因為 Ubuntu 22.04 上預設的 grpc package 似乎是有 bug，需要裝新版解決。

不過我在找 PPA 的時候發現有人包了輔助套件：「OpenSnitch - application firewall (Xenial & newer)」。

這個套件本身是沒有包 OpenSnitch 主程式與 GUI 套件的，他只是要「補充」官方套件安裝的問題，所以需要照他的說明安裝：(我把下面指令提到的 1.5.2 換成目前新版的 1.6.0 裝，目前看起來是會動的)

sudo add-apt-repository ppa:savoury1/opensnitch
sudo apt-get update && sudo apt-get upgrade
sudo dpkg -i opensnitch_1.5.2-1_amd64.deb
sudo dpkg -i python3-opensnitch-ui_1.5.2-1_all.deb
sudo apt-get -f install

這邊用 dpkg -i 裝，而不是用 apt install 的原因是故意讓他不裝 dependency，等到後面的 apt-get -f install 時再裝 PPA 裡面提供的 dependency。

裝好後把跑 opensnitch-gui 起來後就會陸陸續續收到系統內不同的應用程式嘗試的連線，像是官網提供的 screenshot 這樣 (會跳出像左邊這樣的視窗)：

這樣可以控的比較細，不過剛開始用會需要花時間把系統內常態性的 request 先設定過一次，還蠻煩的 XD

用 iptables 擋特定國家的封包

這兩天發現 ubuntu-20.04.3-live-server-amd64.iso 這個 BitTorrent 的 ISO image 有大量來自 CN 的連線在狂抓，導致整個上傳頻寬都被吃滿：

沒想到第一次用 iptables 的 xt_geoip 居然是這個用途... 主要是參考「GeoIP Blocking Ubuntu 20.04LTS」這邊的方法，不過因為我的 rtorrent 是跑在 Docker 裡面的，有另外要注意的地方。

首先是安裝軟體，這邊要裝 xtables-addons-common 與 libtext-csv-xs-perl：

sudo apt install -y libtext-csv-xs-perl xtables-addons-common

再來是建立目錄，並且下載一包 GeoIP 的資料 (從 DBIP 下載) 並且轉成 xt_geoip 可以用的格式：

sudo mkdir /usr/share/xt_geoip
cd /usr/share/xt_geoip
sudo /usr/lib/xtables-addons/xt_geoip_dl
sudo /usr/bin/perl /usr/lib/xtables-addons/xt_geoip_build

然後就是加到 iptables 的條件裡面了，我加到兩個地方，一個是 INPUT chain，另外一個是 DOCKER-USER chain (參考「Docker and iptables」這邊的說明)，假設你是用 port 6991 的話就這樣加：

sudo iptables -I INPUT -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP
sudo iptables -I DOCKER-USER -p tcp -m geoip --source-country CN -m tcp --dport 6991 -j DROP

然後可以考慮每個禮拜更新一次資料庫。

另外在找資料的時候發現「Free updated GeoIP legacy databases」這邊有人放出 MaxMind 的版本，不過免費版的應該都差不多，這邊就用 xtables-addons-common 內預設的。

弄完以後就正常多了...

Google Meet 可以走 443/tcp 了

Work from home 期間開會基本上就是幾個視訊軟體換來換去，Zoom 的話公司有買，自己開免費版的時候是 40mins 限制，另外 Slack 的畫面品質不怎麼樣，而 Google Meet 在疫情期間不限制時間，拿來聊天還蠻好用的。

看到「TLS support for Google Meet」這篇，文章裡面提到先前 Google Meet 是用 443/udp 跑 SRTP，這對很多公司的 firewall 需要另外開 (看到這個 UDP port 想到 QUIC 好像也是走這個 UDP port)，在家裡的話應該還好，對於公司的電腦就會麻煩一些。

文章裡提到，這次支援了 TLS (over 443/tcp)：

Some network setups do not work with SRTP over 443 which was preventing Meet calls from connecting. Meet now encapsulates SRTP in TLS which increases overall compatibility. This change will initially be available on the web, and will be available for mobile soon. We’ll announce it on the Google Workspace Updates blog when it’s available.

可以 fallback 回 443/tcp 走 TLS 的話穿透力應該就更好了，不過不知道免費版的有沒有也一起上，這邊只題到了 G Suite 系列會上：

Available to all Google Workspace customers, as well as G Suite Basic and Business customers

上次用 Google Meet 是在雲端聚餐聊天...

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.

這樣省事多了...

AWS 推出了 AWS Network Firewall

AWS 推出了 AWS Network Firewall，可以在 VPC 層做更多細緻的設定了：「AWS Network Firewall – New Managed Firewall Service in VPC」。

本來的 Network ACLs 的設計也是對 VPC 做過濾，但就是很標準的 stateless filtering：

Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

而這次推出的 AWS Network Firewall 引入了 stateful filtering 的能力：

另外介紹裡面也提到支援 Suricata 的語法，不過太久沒碰 IDS 這塊了，我只知道 Snort：

A stateful rule group with Suricata compatible IPS rules has all settings defined within the Suricata compatible specification. For example, as following is to detect SSH protocol anomalies. For information about Suricata, see the Suricata website.

目前支援的區域很少，只有 us-east-1、us-west-2 與 eu-west-1 可以用：

AWS Network Firewall is now available in US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions. Take a look at the product page, price, and the documentation to learn more.

另外價錢上不算便宜：「AWS Network Firewall Pricing」，比較特別的是用 AWS Network Firewall 的話，包含了免費的 NAT Gateway 額度可以用...

印象中 Network ACLs 不用另外付費 (找了一下沒找到收費的標準？)，如果可以用 Network ACLs 解決就用 Network ACLs，不能的再考慮用 AWS Network Firewall 吧...

中國開始擋 ESNI 了...

這兩天陸陸續續都有一些新聞出來了，中國已經開始擋 ESNI 了：「China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI」。

ESNI (Encrypted SNI) 的重點就是在於把 TLS 裡 ClientHello 的 hostname 部分加密 (通常會需要配合 DNS-over-HTTPS 或是 DNS-over-TLS 的方式取得 key 相關的資料)，這個 hostname 的部分是目前 TLS 連線裡少數可以被看到的明文，也因此對於 GFW 過濾資料很有用，而 ESNI 等於是把這個洞補上，這次直接擋掉應該是預料中的事情...

但就算不管中國的部分，ESNI 對於 priavcy 的幫助還是很大，基本上 ISP 只剩下 IP 資訊可以分析，如果是有 CDN 之類的服務在前面擋住的就更看不出來了 (i.e. 許多網站用同一個 IP address)。