幹壞事是進步最大的原動力
Twitter 上看到 Vultr 可以帶自己的 IP 使用：
If you have your own IP space, we can provide Border Gateway Protocol (BGP) sessions. There is no additional cost for running BGP with Vultr.
— Vultr (@Vultr) October 1, 2021
翻了一下發現是 2015 年就提供的功能：「Announce IP Space on the Cloud with Vultr」，而旁邊的 Linode 與 DigitalOcean 似乎都沒翻到...
在文件「Configuring BGP on Vultr」這邊可以看到需要先驗證 IP 是你的，算是業界常見的作法，跟當初申請 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 看了一下應該沒錯...
公司在菲律賓的辦公室因為常常會需要連到 AWS 傳輸影音資料 (新加坡，ap-southeast-1)，但發現偶而會很不順，傳輸的時候會很卡，所以後來決定租了一條專線用 AWS Direct Connect 接進去。
不過因為跑在 AWS 上面的服務是掛在 public network 上，而不是 private ip 的網段，所以就不能用 IPsec site-to-site 打通收工，而需要搞 BGP routing，然後就卡關卡的亂七八糟 XD
首先是文書作業的部份，因為 AWS 對於 public network peering 需要證明你要交換的 IP address 是你自己的 (或是有被授權)，這部份在 web console 上建立完 Public VIF 後會進入審核階段，接下來就要開 support ticket 提供 LOA-CFA 文件後才能繼續設定，我們這邊是從 ISP 申請 AWS Direct Connect 線路時拿到這份 PDF 文件。
這邊比較有趣的是，如果你沒有買 support plan 的話無法開 technical support，但官方有跟你說這邊可以 workaround 開 General Info and Getting Started 這個類別：「My public virtual interface is stuck in the "Verifying" state. How can I get it approved?」。
過了審核後接下來是設定 pfSense 的部份，因為是要接通 public network 的部份，所以你要收 AWS 提供的 BGP routing，這部份在 pfSense 上會透過 OpenBGPD 解決，但主要還是因為對 BGP 不熟悉，所以花了不少時間跟 AWS 原廠與台灣的 Partner 一起找問題，不然現在事後來看，自己 tcpdump 應該就有能力找到問題了...
主要的盲點是在我們的 AWS Direct Connect 裡面 BGP 需要走 TCP MD5 Signature Option。
這是一個 TCP extension，連線雙方有一把 shared secret 可以驗證每個 TCP packet 沒有被竄改：「Protection of BGP Sessions via the TCP MD5 Signature Option」。
要注意的是這個協定不是 application level，而是在 TCP 層本身就保護起來，包括 3-way handshake 的部份，所以從一開始 SYN 封包過去就要有 md5sig 的資訊。
這也表示用 telnet 不會通是正常的，這點讓我找問題找錯方向好久...
另外一點是 pfSense 的預設值不支援 TCP MD5 Signature Option (完全沒想過這個可能性 XDDD)，這點在 pfSense 的「md5 bgp sessions fail in 2.4.0」這邊有提到：
Do you have "BSD Crypto Device" selected under System > Advanced, Misc tab, for Cryptographic Hardware? If not, select it there and try again.
That module is required for TCP_SIGNATURE to function.
If that works I can either add some warning text to Quagga and FRR or force it to load when that is enabled.
到了對應的選項那邊要選擇，因為我們的 pfSense 機器比較低階，沒有那堆硬體加速度的東西，所以選「BSD Crypto Device (cryptodev)」讓底層的 FreeBSD 去處理。
設定完後新的連線也還是不會有效果，後來想了一下還是整台重開機，然後就通了就通了就通了就通了就通了...
果然弄很久的問題都會是蠢問題，純粹就是不熟悉這些東西造成的。
前幾天 (12 號) BGPmon 發現有很多知名的網段被導去俄羅斯：「Popular Destinations rerouted to Russia」。
Early this morning (UTC) our systems detected a suspicious event where many prefixes for high profile destinations were being announced by an unused Russian Autonomous System.
可以看到相當多知名的網段都被導走：
Starting at 04:43 (UTC) 80 prefixes normally announced by organizations such Google, Apple, Facebook, Microsoft, Twitch, NTT Communications and Riot Games were now detected in the global BGP routing tables with an Origin AS of 39523 (DV-LINK-AS), out of Russia.
從圖中也可以看出來 AS39523 透過 AS31133 發出這些 routing，然後主要是透過 AS6939 (Hurricane Electric) 擴散：
這幾年俄羅斯在網路上的動作多很多...
Dyn (之前被 DDoS 打爆，過一陣子被 Oracle 買去的那個 Dyn) 的這篇「Iran Leaks Censorship via BGP Hijacks」講到他們偵測到伊朗透過 BGP hijack 管制網站的問題。
前陣子伊朗透過 private ASN 放了 99.192.226.0/24 出來，影響到其他國家：
Last week, Iranian state telecom announced a BGP hijack of address space (99.192.226.0/24) hosting numerous pornographic websites.
由於這段 IP address 在 internet 上是以 99.192.128.0/17 在放，就因為 /24 優先權比較高而被蓋過去影響到全世界...
然後過了幾天，開始攻擊蘋果的 iTunes 服務，不過這次是以 /32 放出來。由於大多數收的最小單位是 /24，這次的影響沒有上次大：
In addition, TIC announced BGP hijacks for 20 individual IPs associated with Apple’s iTunes service. These too were carried by Omantel to the outside world, albeit with a smaller footprint due to the fact that BGP routes for /32’s typically don’t propagate very far.
這看得出來 routing 在 internet 上還是非常脆弱...
前幾天 BGPmon 偵測到大規模的 routing-hijacking 事件：「Large hijack affects reachability of high traffic destinations」，範圍應該是最近最大的：
Our initial investigation shows that the scope of this incident is widespread and affected 576 Autonomous systems and 3431 prefixes. Amongst the networks affected are high traffic prefixes including those of Google, Amazon, Twitter, Apple, Akamai, Time Warner Cable Internet and more.
在「[outages] HTTP access to www.amazon.com is down for us」這邊也看得到當時有人發現問題。
前幾天因為流感而睡太多，來消化一些文章。
上個星期 Google 放出一套用 Go 寫的 Load balancer，叫 Seesaw：「Seesaw: scalable and robust load balancing」。
比較有趣的是 BGP 與 anycast VIP 的能力：
Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.
Google 這個規模玩的是不同 scale 的花樣...
也是兩個禮拜前的新聞，在「OpenDNS BGP Stream Twitter Feed」這邊提到了 BGPmon 將會推出 BGP Stream 服務，將偵測到的 BGP 異常變化發到 Twitter 上。
其中 BGPmon 在幾個月前被 OpenDNS 併購 (2015 年 3 月)，而 Cisco 則在上上個月底併購了 OpenDNS (2015 年 6 月)。而在過幾天的 DefCon 23 上將會透露更多細節。
前陣子 Hacking Team 洩漏的資料中就用到了 BGP hijack 來取回控制權：
That nugget that emerged from the 400 Gb of stolen Hacking Team data posted online where Italian law enforcement used Hacking Team’s Remote Control System monitoring software to regain control over a number IP addresses it was watching that were already infected with Hacking Team software by hijacking BGP routes in order to redirect traffic and regain control over a target’s machines.
除了示警外，另外一方面 BGP 上的簽名技術也愈來愈重要了，只是不知道最終會怎麼做...
Hacking Team 的事情告訴我們，只能是能做的，都有人會包成 Total Solution 賣。
洩漏出來的資料說明了 Hacking Team 在 2013 年幹的 BGP Routing Hijack：「How Hacking Team Helped Italian Special Operations Group with BGP Routing Hijack」。
The Wikileaks document described how the Italian ROS reached out to Hacking Team to work together on recovering the VPS server that ran on 46.166.163.175. In ROS terminology, the server was called “Anonymizer”. The emails also revealed that this server relays updates to another back end server called “Collector” from which ROS presumably recovers the targets’ data.
然後：
When we look at historical BGP data we can confirm that AS31034 (Aruba S.p.A) indeed started to announce the prefix 46.166.163.0/24 starting on Friday, 16 Aug at 2013 07:32 UTC. The Wikileaks emails outline how ROS complained to Hacking Team that the IP was reachable only via Fastweb but not yet through Telecom Italia, concluding not all RCS clients were able to connect back to the server immediately, since the prefix was not seen globally. BGP data further confirms this per the visualization below.
這些主要的 ISP 分別是：
AS12874 Fastweb
AS6939 Hurricane Electric, Inc.
AS49605 Reteivo.IT
AS4589 Easynet
AS5396 MC-link Spa
時間線：
這也證明了「鎖 IP」的方法其實還是很危險的。