用 VXLAN + WireGuard 保護 L2 流量的方法

在「Defend against vampires with 10 gbps network encryption (synacktiv.com)」這邊看到「Defend against vampires with 10 gbps network encryption」這篇,裡面在講怎麼保護 ethernet packet 的流量...

開頭就有提到各種從物理層面擷取流量的方式,像是現在主流的光纖要怎麼聽的方式,我記得當年 Snowden 揭露 PRISM 的時候蠻多細節被陸陸續續挖出來... 找了一下當年的報導:「NSA secretly taps Google, Yahoo data transmission worldwide」,在裡面提到:

In the case of Google, the most likely scenario is that the agencies have tapped into fibers and cables connecting the company’s privately owned or leased data centers in Chile, Ireland, Finland, Belgium, Taiwan, Hong Kong, Singapore and others.

這也是為什麼需要保護 ethernet packet 的流量,因為很有可能可以從路邊或是水溝邊直接夾光線聽到東西。

裡面有提到可以用 MACsec 保護,很久沒聽到這個技術了,以前有研究看過,不過記得當時覺得不太好用 (主要是設備支援的情況),作者在文章裡面也有提到這點。

另外作者有提到 MACsec 沒有保護 MAC address,這點會透漏出設備數量以及可能的廠牌資訊,這也是個隱患 (也就是從 MAC address 與 OUI 資訊得知)。

作者後來選擇的方案是用 VXLAN 將 ethernet packet 轉成 UDP packet,然後再用 WireGuard 傳輸,這樣就可以保護 L2 流量,是個還蠻有趣的組合,然後經過測試後確認現有的 server 在經過簡單的調教後就可以跑到接近 wire-speed 的 10Gbps。

印象中當年在處理同個園區跨辦公室的 case,有一段光纖是跑在園區管道間,好像是用 IPsec 的 site-to-site VPN 解,一方面是兩邊的 IP subnet 不同,所以可以用 L3 的方案解決;另外一方面 IPsec 這個方案在一般商用 VPN 硬體還算成熟,不用自己弄一堆東西。

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN),不使用 AWS 自己提供的串接服務,而是用 pfSense 串接。

會自己搞主要有幾個考慮:

  • 考慮到 AWS Transit Gateway 的費用,每掛一個上去就要多收一次錢,另外上面處理的流量要再收費。
  • 應用的流量不大,所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity,算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理,加上用戶端的網路本來就不怎麼穩定,AWS Transit Gateway 的 SLA 再怎麼高,我也還是得處理斷線時的後續機制,不如就不要那麼緊張...

在設定的時候要注意的事情:

  • EC2 的 Source IP/Destination IP 檢查要關掉,這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開,因為 pfSense 會丟出不屬於他自己 IP address 的封包,也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing),這些都還是會經過 Security Group 的檢查,而 Security Group 能設定的數量有限,基本上應該會全開...
  • pfSense 在設完 IPsec 後,同樣在 pfSense 上面的 firewall 需要手動加開,因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法,只是老方法還是很好用...

跨群的 Kubernetes 網路層 Submariner

Submariner 是連接兩個不同的 Kubernetes 網路層的軟體:「Cross-Cluster Network Connectivity for Kubernetes」。

目前還在 alpha 階段 (看 GitHub 也可以看出來還很新),在架構面上是使用 IPsec 保護流量:

Submariner is a tool built to connect overlay networks of different Kubernetes clusters. While most testing is performed against Kubernetes clusters that have enabled Flannel/Canal, Submariner should be compatible with any CNI-compatible cluster network provider, as it utilizes off-the-shelf components such as strongSwan/Charon to establish IPsec tunnels between each Kubernetes cluster.

這等於是試著實作 GCP 的跨區內網架構...

Cisco 與 Fortinet 防火牆的 RCE 漏洞

NSA 使用這些漏洞來大量監聽企業的流量:「Leaked Exploits are Legit and Belong to NSA: Cisco, Fortinet and Snowden Docs Confirm」。

Cisco 已經確認這個安全性漏洞了,全系列包括已經停產的 Cisco PIX、上個世代的 Cisco ASA 5500 (但還有些型號還在賣),以及目前主力的 Cisco ASA 5500-X,另外還包括了安全模組系列也中獎:「Cisco Adaptive Security Appliance SNMP Remote Code Execution Vulnerability」。

  • Cisco ASA 5500 Series Adaptive Security Appliances
  • Cisco ASA 5500-X Series Next-Generation Firewalls
  • Cisco ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Cisco ASA 1000V Cloud Firewall
  • Cisco Adaptive Security Virtual Appliance (ASAv)
  • Cisco Firepower 4100 Series
  • Cisco Firepower 9300 ASA Security Module
  • Cisco Firepower Threat Defense Software
  • Cisco Firewall Services Module (FWSM)*
  • Cisco Industrial Security Appliance 3000
  • Cisco PIX Firewalls*

標星號的是目前已經沒有在維護的產品,這次只確認受到影響,但不會更新:

Cisco Firewall Service Modules and Cisco PIX Firewalls have passed the last day of software support milestone as stated in the published End of Life (EoL) documents. Further investigations into these devices will not be performed, and fixed software will not be made available.

這次 Cisco 的安全性問題是 SNMP 的洞造成的:

Administrators are advised to allow only trusted users to have SNMP access and to monitor affected systems using the snmp-server host command.

這個洞被 NSA 用來寫 exploit 植入系統:

This flaw was included inside two NSA exploits, dubbed EPICBANANA as well as JETPLOW, which is an enhanced version of EPICBANANA, but with better persistence capabilities, Cisco's Omar Santos said in a blog post.

在 NSA 洩漏出來的文件裡可以看到 ace02468bdf13579 這個特殊辨識字串,而在受感染的樣本上也找到了這個痕跡:

而且不只是 Cisco,其他幾家也中獎了,可以參考「The NSA Leak Is Real, Snowden Documents Confirm」這邊更多的資訊 @_@

關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

VPC VPN 的新功能

Amazon VPC 的 VPN 推出新功能了:「EC2 VPC VPN Update – NAT Traversal, Additional Encryption Options, and More」。

其中「Reusable CGW IP Addresses」這個功能讓大家等超久的:(CGW 是 Customer Gateway,通常是放在自己的機房裡跟 Amazon VPC 設 site-to-site VPN 對接)

You no longer need to specify a unique IP address for each customer gateway connection that you create. Instead, you can now reuse an existing IP address. Many VPC users have been asking for this feature and I expect it to be well-used.

之前得弄一堆 IP address 來接來接去,現在總算是改善了...

在攻擊時總是挑最弱的一環:NSA 對 DH 的攻擊

在「How is NSA breaking so much crypto?」這邊提到了 2012 年有文章說明 NSA 有能力解開部份的加密通訊,而後來 Snowden 所提供的資料也證實了這點:

In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.

但在這之前一直都不清楚是怎麼解出來的,直到最近才猜測應該是 Diffie-Hellman 的強度以及實作問題:「Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice」。

而成果其實非常驚人,由於強度不夠以及實作問題,有相當可觀的數量是可被攻擊的:

We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.

作者群給的建議有三個方向,一個是把長度加長到 2048 bits,另外一個是改用 ECDH,而最差的情況 (如果還是需要使用 1024 bits DH) 則是避免使用固定的 prime number。

pfSense 2.2

pfSense 出新版了:「pfSense 2.2-RELEASE Now Available!」。

之前一直用 RC 版本,看起來可以換過去了。從維基百科更新的資料「pfSense」也可以看到許多改變。

主要是從 FreeBSD 8.3 換到 10.1,於是支援 PV on HVM

而 VPN 類的升級也是讓人心動的一點,換成 strongSwan了。所以該找時間測試效能了,不知道能不能超越 OpenVPN 的 200Mbps...

NSA 聽 Google 與 Yahoo! 跨機房的 LAN...

最近幾天揭露的文件顯示 NSA 在監聽 GoogleYahoo! 在內部機房內的通訊:「NSA infiltrates links to Yahoo, Google data centers worldwide, Snowden documents say」。

不是 Google 與 Yahoo! 之間的通訊,而是 Google 自家資料中心之間交換的資料 (以及 Yahoo! 自家資料中心交換的資料),像是這樣:

重點在右半塊的內部通訊內容未必會被加密...

Switch 與 Router 要內建 Wirespeed IPsec 的時代要來臨了嗎... 40Gbps (甚至 100Gbps) 的 IPsec 能力!XDDD

增加無線網路的安全性

在「Don’t Have a False Sense of Security: 5 Insecure Ways to Secure Your Wi-Fi」這篇文章裡面提到了五個「不安全的安全措施」:

  • 使用 WEP
  • 隱藏 SSID
  • 過濾 Mac Address。
  • 使用 Static IP。
  • 使用 WPA 或 WPA2 但仍使用短密碼或弱密碼。

無線網路不太好搞啊... 有些公司是直接限制無線網路只能連到 VPN server,利用 IPSec VPN 或是 SSLVPN 保護。