用 pfSense 接 AWS Direct Connect (Public VIF) 的方式

公司在菲律賓的辦公室因為常常會需要連到 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 去處理。

設定完後新的連線也還是不會有效果,後來想了一下還是整台重開機,然後就通了就通了就通了就通了就通了...

果然弄很久的問題都會是蠢問題,純粹就是不熟悉這些東西造成的。

處理很久前用 OpenSSL 加密的備份資料

因為想要翻一些舊的文章 (小說),想把以前 BBS 的備份拉出來看看裡面有沒有,結果發現 OpenSSL 解半天都解不開,還跑去玩了 bruteforce-salted-openssl 這個專案:

Try to find the password of a file that was encrypted with the 'openssl' command.

後來也是因為這個專案提醒,發現 openssl enc 指令在 OpenSSL 1.0.x (以及之前) 預設是用 MD5 當 digest algorithm,而 1.1.x 換成了 SHA-256,而我的備份資料應該是在 0.9.x 的年代就生出來了...

指定 -md md5 後就正常解出來了:

openssl enc -bf -d -md md5 -in ooxx.tar.gz.bf -out ooxx.tar.gz

另外一個收穫是 CPU 溫度降了不少:因為跑 bruteforce-salted-openssl 的時候 CPU 到 80 度,感覺撞到安全值卡在 4.0Ghz,所以就把 CPU 電壓降了 0.1V,看起來溫度低了不少 (少了五度),但跑起來還是 4.0Ghz...

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...

HiNet 與 DigitalOcean、Linode、Vultr 的封包情況

先說結論,綜合網路與 CPU 的情況,我剛好跟下面提到的文章給出相反的選擇 (i.e. 完全不會選 DigitalOcean)。如果是需要 latency 低的品質我會選 Linode 的東京新機房 Tokyo 2,如果不需要 latency 的我會選 Vultr 的 USD$2.5/month 方案 (目前只在邁阿密與紐約有)。

看到「2018/06 台灣 5USD 虛擬主機網路延遲測試」這篇就來推廣一下 SmokePing 這個工具。這個工具可以做很多事情,但最常看到的用途還是做網路品質監控,先前在 K 社的時候就有個做個公開的站台可以看,後來接手的人也繼續維護著 (畢竟看這些圖有種治癒感?):「smokeping.kkbox.com.tw」。

不過 K 社的 SmokePing 裡面大多數是從固網機房端監控,而固網機房端的 Internet 品質一般來說都會比家用型的好很多,尤其是國際頻寬的部份。所以我也在我家裡用 PPPoE 版本的固定 IP 做了一份:「https://home.gslin.org/smokeping/」,這邊的設定檔放在 GitHub 上的 gslin/smokeping-config.d 上。

而我剛好有把這三家 VPS 的 SmokePing 都做起來:「SmokePing Latency Page for DigitalOcean」、「SmokePing Latency Page for Linode」、「SmokePing Latency Page for Vultr」。

我這邊看到的情況是這樣。以各家離台灣最近的點來看:

  • 第一張圖的 DigitalOcean 沒有東京的點,而新加坡的 latency 在這幾個月其實變差不少,現在大約要 90ms (扣掉光世代的 10ms)。
  • 第二跟第三張圖的 Linode (分別是 Tokyo 1 與 Tokyo 2) 其實可以看到新機房 Tokyo 2 的 latency 比舊機房 Tokyo 1 還好。
  • 第四張圖的 Vultr 則是狀況變化很多,但不管怎麼走,latency 大致上都還是比新加坡好。

另外第五張的 Vultr 則是紐約的點,latency 超高 (畢竟繞了半個地球),但 packet loss 不高,品質還算穩定。

speedtest-sgp1.digitalocean.com (DigitalOcean Singapore 1)

speedtest.tokyo.linode.com (Linode Tokyo)

speedtest.tokyo2.linode.com (Linode Tokyo 2)

hnd-jp-ping.vultr.com

nj-us-ping.vultr.com

另外是之前有痛到的部份,先前因為需求而需要在 PHP 5.6 上跑 WordPress,真的實際跑起來後發現超慢 (畢竟這兩個要快得想不少辦法),去找問題後發現 DigitalOcean 機器的 CPU 真的太慢,後來把這組需求搬去 Linode (在 CPU 與網路之間取個合理的平衡點)。

在各家 VPS 上用 Ubuntu 16.04 跑 openssl speed md5 可以看出一些資料:

DigitalOcean:

Doing md5 for 3s on 16 size blocks: 5465798 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3761125 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 1835218 md5's in 2.99s
Doing md5 for 3s on 1024 size blocks: 582162 md5's in 2.96s
Doing md5 for 3s on 8192 size blocks: 102995 md5's in 2.97s
Doing md5 for 3s on 16384 size blocks: 47177 md5's in 2.99s

Linode:

Doing md5 for 3s on 16 size blocks: 11510700 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 8361353 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 3751929 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1169457 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 157678 md5's in 2.99s
Doing md5 for 3s on 16384 size blocks: 78874 md5's in 3.00s

Vultr (這是 USD$2.5/month 的方案):

Doing md5 for 3s on 16 size blocks: 14929209 md5's in 2.97s
Doing md5 for 3s on 64 size blocks: 9479563 md5's in 2.97s
Doing md5 for 3s on 256 size blocks: 4237907 md5's in 2.98s
Doing md5 for 3s on 1024 size blocks: 1320548 md5's in 2.98s
Doing md5 for 3s on 8192 size blocks: 161940 md5's in 2.96s
Doing md5 for 3s on 16384 size blocks: 86592 md5's in 2.98s

然後補一個 AWS 的 t2.nano (在還有 CPU credit 可以全速跑的情況下),不過這不公平,參考用而已:

Doing md5 for 3s on 16 size blocks: 19257426 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 11168752 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 4959879 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1518690 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 203910 md5's in 3.00s
Doing md5 for 3s on 16384 size blocks: 102321 md5's in 2.99s

Yahoo! 的資料外洩數量超過之前公佈的十億筆,上升到三十億筆

Oath (Y! 的新東家,Verizon 持股) 發表了新的通報,外洩數量直接上升到 3 billion 了:「Yahoo provides notice to additional users affected by previously disclosed 2013 data theft」。

也就是當時所有的使用者都受到影響:

Subsequent to Yahoo's acquisition by Verizon, and during integration, the company recently obtained new intelligence and now believes, following an investigation with the assistance of outside forensic experts, that all Yahoo user accounts were affected by the August 2013 theft.

在「Yahoo says all 3 billion user accounts were impacted by 2013 security breach」這邊的報導則是寫的比較清楚,把當時的使用者數字翻出來:

Yahoo today announced that the huge data breach in August 2013 affected every user on its service — that’s all three billion user accounts and up from the initial one billion figure Yahoo initially reported.

2013 這包用的是 MD5 hash,以現在的運算能力來看,可以當作沒有 hash...:

The stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.

已經是 "all" 了,接下來要更大包只能是其他主題了...

歡樂的 md5crypt 密碼...

作者寫了一篇關於以前在 WHOIS 記錄上看到一串 $1$ 開頭的 md5crypt 密碼 XDDD:「I mean, why not tell everyone our password hashes?」。

Now the fields are filtered but this is a reasonably recent change. Prior to July 2015 the hashed passwords were shown to anyone who whois’d the maintainer object and used md5 passwords. Which was nearly all of them in my experience.

Mntner:         DTAG-NIC
Descr:          Deutsche Telekom Internet Services NIC
Admin-c:        KK281-RIPE
Tech-c:         HI56-RIPE
Auth:           MD5-PW $1$KQ3NSRfS$/bcvLAz2BKyf5HF4VkPMh/
Mnt-by:         DTAG-NIC
Referral-by:    RIPE-DBM-MNT

不知道有沒有人去跑看看... XD

話說 md5crypt 已經被認為不安全 (當初的發明人 phk 也有出來建議大家換掉了:「Md5crypt Password scrambler is no longer considered safe by author」),從目前 Hashcat 的攻擊速度就可以看出來... 找個最近的例子來說,可以參考「8x Nvidia GTX 1080 Hashcat Benchmarks」這篇。

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5

Speed.Dev.#1.:  9918.1 kH/s (97.10ms)
Speed.Dev.#2.:  9830.1 kH/s (97.70ms)
Speed.Dev.#3.: 10017.4 kH/s (97.36ms)
Speed.Dev.#4.:  9986.5 kH/s (96.92ms)
Speed.Dev.#5.:  9976.8 kH/s (97.74ms)
Speed.Dev.#6.:  9889.2 kH/s (97.29ms)
Speed.Dev.#7.: 10010.5 kH/s (97.40ms)
Speed.Dev.#8.: 10083.0 kH/s (96.94ms)
Speed.Dev.#*.: 79711.6 kH/s

而隔壁的 bcrypt 對 Hashcat 的防禦性完全在不同等級:

Hashtype: bcrypt, Blowfish(OpenBSD)

Speed.Dev.#1.:    13094 H/s (47.51ms)
Speed.Dev.#2.:    13076 H/s (47.63ms)
Speed.Dev.#3.:    13292 H/s (46.88ms)
Speed.Dev.#4.:    13250 H/s (47.17ms)
Speed.Dev.#5.:    13296 H/s (46.86ms)
Speed.Dev.#6.:    13160 H/s (47.30ms)
Speed.Dev.#7.:    13260 H/s (46.98ms)
Speed.Dev.#8.:    13280 H/s (46.80ms)
Speed.Dev.#*.:   105.7 kH/s

直接相除是 754 倍左右。

以 85 個字元的組合計算 ([0-9A-Za-z] 62 個,特殊字元 22 個,加上空白 1 個),抗性多了 1.5 個字 (log85(754) 大約是 1.49)?如果以 62 個字元來看也有 1.6 個字,強了不少...

用 Amazon EC2 的 GPU instance 計算 MD5 collision

在「Create your own MD5 collisions」這篇教你用 Amazon EC2 的 GPU instance 計算 MD5 collision。

由於不是什麼正式的服務,文章裡介紹你用 Spot instance 開機器,會便宜不少。可以看到最後的結果:

在文後也把兩張圖都附上來讓大家確認,抓下來後也可以確認:

gslin@GSLIN-DESKTOP [~/tmp] [13:16/W3] md5sum *.jpg
253dd04e87492e4fc3471de5e776bc3d  plane.jpg
253dd04e87492e4fc3471de5e776bc3d  ship.jpg

屬於 chosen prefix collision 的攻擊。

htpasswd 的 SHA 不會帶 salt (seed)...

剛剛發現 htpasswd (Apache.htpasswd 檔案產生程式) 提供的 SHA-1 不會使用 salt,不過 MD5 格式會...

以密碼「test」測試:

gslin@colo-p [~] [17:44/W7] touch test.txt
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test1 test
Adding password for user test1
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test2 test
Adding password for user test2
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test3 test
Adding password for user test3
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test4 test
Adding password for user test4

結果是:

test1:$apr1$GU6SyO0y$I.Ng9o4H8Tcje.M2A6ECb0
test2:$apr1$uqoX9b/x$7zGMAKqRjvoi6HHSKtaRO.
test3:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=
test4:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=

依照說明,htpasswd 使用的 SHA 是移植自 Netscape server 的 LDAP Directory Interchange Format (ldif):

Use SHA encryption for passwords. Facilitates migration from/to Netscape servers using the LDAP Directory Interchange Format (ldif).

在安全疑慮 (Security Considerations) 上也有註明 htpasswd 使用的 SHA 是不帶 salt:

The SHA encryption format does not use salting: for a given password, there is only one encrypted representation.

現在密碼儲存應該是朝 bcryptPBKDF2 發展,參考依林姊姊的「請愛用 bcrypt 和 PBKDF2」,後者 PBKDF2 被用在 WPA2 上。

FreeBSD Ports System 拿掉 MD5 檢查了...

在「MD5 for distinfo has been deprecated」這邊看到 FreeBSD Ports System 拿掉 MD5 檢查了 (會被忽略而不檢查)。

PR (Problem Report) 可以在「ports/149657: [bsd.port.mk] deprecate MD5 checksums in distinfo」查到。

翻了 cvs log,SHA256 是五年前 (2005) 加到 bsd.ports.mk 的:「Diff for /ports/Mk/bsd.port.mk between versions 1.517 and 1.518」,總算在今天把 MD5 取代了:「Diff for /ports/Mk/bsd.port.mk between versions 1.651 and 1.652」。