ref: https://www.cncf.io/blog/2021/09/01/chaos-mesh-2-0-ga-to-a-chaos-engineering-ecology/

Chaos Mesh 2.0 於 07/23/2021 正式 GA 了，團隊期盼透過這次 2.0 的釋出能夠讓整個 Chaos Engineering 的生態性更加茁壯與蓬勃發展。

Chaos Mesh 一直以來的目標就是讓 Chaos Engineering 能夠更輕易地進入到每個管理者的 Kubernetes 叢集， 2.0 則是這個目標路上的一個重大里程碑，
歷經一年左右的開發與努力， 2.0 主要有三大改進
1. 簡化使用的困難性
Chaos Mesh 透過一套基於 Web 的管理介面 Chaos Dashboard 讓使用者可以輕易地去檢視目前所有的實驗與內容，而 2.0 更是簡化整體操作，
界面更加簡潔同時也可以觀看每個實驗的詳細資訊。
針對不同的雲端業者環境，也支援 AWSChaos/GCPChaos 等不同的環境設定，確保所有的 Kubernetes 測試都能夠更加一致。

2. 強化 Chaos 實驗的自動調度功能
實務上來說，一個單一的實驗沒辦法有效的模擬各種測試環境，因此很多時候都需要人為操作的介入，為了讓這一切更加流暢與自動，Chaos Mesh 過往整合了 Argo Workflow 來協助調度各種實驗。
不過後來團隊發現 Argo Workflow 並不是一個非常適合描述 Chaos 實驗的工具，因此 2.0 版本重新實作了 workflow 的機制，這次的機制是原生支援而不需要仰賴任何第三方解決方案。

3. 支援更多 Injection 的類型
從 2.0 開始， Chaos Mesh 開始支援如 JVMChaos, HTTPChaos 等不同的測試目標。
JVMChaos 用來針對 Java/Kotlin 等使用程式語言撰寫的應用程式，而 HTTPChaos 可以攔截 HTTP 的封包並且竄改內容

此外針對實體機器部分，Chaos Mesh 則是開發了一個名為 Chaosd 的來模擬各種環境問題，譬如砍掉 process, 模擬網路問題，模擬 Disk 問題等

對 Chaos Engineering 有興趣的可以試試看

本文延續前篇效能校正的經驗談，上篇文章探討了關於應用程式本身可以最佳化的部分，包含了應用程式以及框架兩個部分。本篇文章將繼續剩下最佳化步驟的探討。

Speculative Execution Mitigations
接下來探討這個最佳化步驟對於效能有顯著的提升，但是本身卻是一個非常具有爭議性的步驟，因為其涉及到整個系統的安全性問題。
如果大家對前幾年非常著名的安全性漏洞 Spectre/Meltdown 還有印象的話，本次這個最佳化要做的就是關閉這類型安全性漏洞的處理方法。
標題的名稱 Speculative Execution Migitations 主要跟這漏洞的執行概念與 Pipeline 有關，有興趣理解這兩種漏洞的可以自行研究。

作者提到，大部分情況下這類型的防護能力都應該打開，不應該關閉。不過作者認為開關與否應該是一個可以討論的空間，特別是如果已經確認某些特別情境下，關閉防護能力帶來的效能如果更好，其實也是一個可以考慮的方向。

舉例來說，假設今天你運行了基於 Linux 使用者權限控管與 namespaces 等機制來建立安全防護的多使用者系統，那這類型的防護能力就不能關閉，必須要打開來防護確保整體的 Security Boundary 是完整的。 但是如果今天透過 AWS EC2 運行一個單純的 API Server，假設整個機器不會運行任何不被信任的程式碼，同時使用 AWS Nitro Enclaves 來保護任何的機密資訊，那這種情況下是否有機會可以關閉這類型的檢查?

作者根據 AWS 對於安全性的一系列說明認為 AWS 本身針對記憶體的部分有很強烈的保護，包含使用者之間沒有辦法存取 Hyperviosr 或是彼此 instance 的 Memory。
總之針對這個議題，有很多的空間去討論是否要關閉，以下就單純針對關閉防護能力帶來的效能提升。

作者總共關閉針對四種攻擊相關的處理能力，分別是

Spectre V1 + SWAPGS
Spectre V2
Spectre V3/Meltdown
MDS/Zombieload, TSX Anynchronous Abort
與此同時也保留剩下四個，如 iTLB multihit, SRBDS 等
這種設定下，整體的運作效能再次提升了 28% 左右，從 347k req/s 提升到 446k req/s。

註: 任何安全性的問題都不要盲從亂遵循，都一定要評估判斷過

Syscall Auditing/Blocking
大部分的情況下，Linux/Docker 處理關於系統呼叫 Auditing/Blocking 兩方面所帶來的效能影響幾乎微乎其微，不過當系統每秒執行數百萬個系統呼叫時，這些額外的效能負擔則不能忽視，如果仔細觀看前述的火焰圖的話就會發線 audit/seccomp 等數量也不少。

Linux Kernel Audit 子系統提供了一個機制來收集與紀錄任何跟安全性有關的事件，譬如存取敏感的機密檔案或是呼叫系統呼叫。透過這些內容可以幫助使用者去除錯任何不被預期的行為。
Audit 子系統於 Amazon Linux2 的環境下預設是開啟，但是本身並沒有被設定會去紀錄系統呼叫的資訊。

即使 Audit 子系統沒有真的去紀錄系統呼叫的資訊，該子系統還是會對每次的系統呼叫產生一點點的額外處理，所以作者透過 auditctl -a never,task 這個方式來將整體關閉。

註: 根據 Redhat bugzilla issue #1117953, Fedora 預設是關閉這個行為的

Docker/Container 透過一連串 Linux Kernel 的機制來隔離與控管 Container 的執行權限，譬如 namespace, Linux capabilities., cgroups 以及 seccomp。
Seccomp 則是用來限制這些 Container 能夠執行的系統呼叫類型

大部分的容器化應用程式即使沒有開啟 Seccomp 都能夠順利的執行，執行 docker 的時候可以透過 --security-opt seccomp=unconfined 這些參數告訴系統運行 Container 的時候不要套用任何 seccomp 的 profile.

將這兩個機制關閉後，系統帶來的效能提升了 11%，從 446k req/s 提升到 495k req/s。

從火焰圖來看，關閉這兩個設定後，syscall_trace_enter 以及 syscall_slow_exit_work 這兩個系統呼叫也從火焰圖中消失，此外作者發現 Amazon Linux2 預設似乎沒有啟動 Apparmor 的防護，因為不論有沒有關閉效能都沒有特別影響。

Disabling iptables/netfilter
再來的最佳化則是跟網路有關，大名鼎鼎的 netfilter 子系統，其中非常著名的應用 iptables 可以提供如防火牆與 NAT 相關功能。根據前述的火焰圖可以觀察到，netfilter 的進入 function nf_hook_slow 佔據了大概 18% 的時間。

將 iptables 關閉相較於安全性來說比較沒有爭議，反而是功能面會不會有應用程式因為 iptables 關閉而不能使用。預設情況下 docker 會透過 iptables 來執行 SNAT與 DNAT(有-p的話)。
作者認為現在環境大部分都將 Firewall 的功能移到外部 Cloud 來處理，譬如 AWS Security Group 了，所以 Firewall 的需求已經減少，至於 SNAT/DNAT 這類型的處理可以讓容器與節點共享網路來處理，也就是運行的時候給予 “–network=host” 的模式來避免需要 SNAT/DNAT 的情境。

作者透過修改腳本讓開機不會去預設載入相關的 Kernel Module 來達到移除的效果，測試起來整體的效能提升了 22%，從 495k req/s 提升到 603k req/s

註: 這個議題需要想清楚是否真的不需要，否則可能很多應用都會壞掉

作者還特別測試了一下如果使用 iptables 的下一代框架 nftables 的效能，發現 nftables 的效能好非常多。載入 nftables 的kernel module 並且沒有規則的情況下，效能幾乎不被影響(iptables 則相反，沒有規則也是會影響速度)。作者認為採用 nftables 似乎是個更好的選擇，能夠有效能的提升同時也保有能力的處理。

不過 nftables 的支援相較於 iptables 來說還是比較差，不論是從 OS 本身的支援到相關第三方工具的支援都還沒有這麼完善。就作者目前的認知， Debian 10, Fedora 32 以及 RHEL 8 都已經轉換到使用 nftables 做為預設的處理機制，同時使用 iptables-nft 這一個中介層的轉換者，讓所有 user-space 的規則都會偷偷的轉換為底層的 nftables。
Ubuntu 似乎要到 20.04/20.10 的正式版本才有嘗試轉移到的動作，而 Amazon Linux 2 依然使用 iptables 來處理封包。

下篇文章會繼續從剩下的五個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

📜 [專欄新文章] Private key security and protection / 私錀的安全與保護 — Tim Hsu
✍️ 洪偉捷
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Private key security and protection / 私錀的安全與保護 — Tim Hsu

Crosslink Taipei 在10/19、10/20 台北矽谷會議中心舉辦的 區塊鏈conf。 這是Crosslink Taipei 下午的演講，主講者是擔任CYBAVO CTO的徐千洋(Tim Hsu)先生，同時也是幣托、OTCBTC的資安顧問。

2018年一月被發現的硬體漏洞meldown跟spectr，我們的硬體為了要讓執行速度更快，processor會預先執行某些指令，也因此駭客可以透過這種方式，間接檢測出我們記憶體的內容，把敏感資訊都dump出來。雖然後這之後各CPU廠商都有推出針對這個bug的軟體update，但是在這之後硬體安全的問題逐漸浮出來面，也使世人意識到硬體資安的問題。而今天我們要談的部分不僅有軟體安全，也有硬體安全跟使用者資安觀念的問題。

淺談交易所與錢包

在從交易所提幣的時候，首先Server會先將這筆交易紀錄到交易所自己的資料庫內，之後再取得交易所金庫的private key去金庫取錢，再打到使用者的錢包內。在這個過程中，如果駭客可以竄改Server或資料庫的交易金額，原本要打給使用者1 BTC，變成10BTC，或是直接取得金庫的private key，對交易所都是一大噩夢

圖(一) 從交易所提幣的流程

攻擊手法

1. 交易所的網路架構

案例一: 交易所因為怕被偷交易資料與客戶資料，所以都把這些資訊先加密後再存到資料庫，但是這些資料仍然會被偷(交易所遭到電話詐騙)，往後將這些資料加了三層密，仍無法防範資料被偷的情形，原因出在圖(二)的交易所網路架構。

圖(二) 交易所的網路架構(OA與資料庫間沒防火牆)

因為OA 與資料庫之間的網路沒有防火牆保護，所以駭客不用正面攻擊有防火牆的部分，而是攻擊OA的部分，再藉由OA連線到資料庫。一封藏有病毒的email求職信寄到HR的電腦，都有可能造成交易所資料外流。

解決方式: 就是在OA與資料庫間架個防火牆，如圖(三)所示。例如: 只有Engineer、RD 可以連線到資料庫，QA則只能連到測試環境，HR、CEO不需要、也不能連線到資料庫，依職責對連線範圍做縮限，則駭客可以攻擊的目標變少，我們也比較好做應對。講者重要的一句話: 「千萬不要輕忽駭客攻擊OA的能力」

圖(三) 好的交易所的網路架構

2. DNS Attack

透過汙染AWS 的DNS Server 將交易所網頁導向駭客的網頁，來騙取使用者個資。雖然在導向駭客頁面時，很容易發現駭客的網頁沒有使用安全憑證，或是安全憑證不是SSL核發，但使用者仍可能因資安觀念低落，而堅持連線到不安全的網站。

3. Online Paper Wallet

很多人因為覺得私鑰放電腦覺得不安全，又沒錢買硬體錢包，所以透過線上私鑰轉換器將私鑰轉換成QR code，然而再轉換時勢必要輸入自己的私鑰，容易使私鑰遭竊。

圖(四) 私鑰轉換詐騙網頁

4. 使用者對私鑰保護的意識很低

例如: 不了解私鑰的註記詞或其他相關資訊保密的重要性，而無意間通過社交軟體洩漏了這些重要資訊(硬體錢包開箱文 XD)。

5. 硬體錢包的漏洞

TREZOR 錢包是業內公認的研發最早最警慎最安全的加密儲存器，但是今年仍被發現硬體相關的漏洞。只要駭客輸入特定24碼pin碼，就可以通過硬體的側通道分析，輕易提取出未加密的私鑰，而且這個必須重新設計硬體架構才能夠防止這樣的攻擊。所以即便硬體錢包掉了，仍有被攻擊的疑慮，最好的解決辦法就是硬體錢包外再設定一個long Password，這樣就可以避免掉硬體錢包時帳戶虛擬貨幣遭竊

圖(五) 硬體錢包漏洞

題外話 — Iphone Jailbreak問題

今年在twitter，有人公布了最新攻擊iphone的方式，而問題出在手機晶片。Iphone開機時第一個執行的程序是 bootrom，而bootrom的程式碼則是位於記憶體唯獨區域，所以無法竄改。駭客可以利用bootrom上的bug來攻擊手機，而這些有問題的晶片出現在Iphone 6 ~ Iphone X。其實這攻擊方式充滿限制，不僅要取得欲攻擊的手機，而且這種攻擊方式每次重開機就會刷新。不過這也衍伸出新的問題，以後的iOS作業系統都更容易遭到入侵，因為我們可以在舊的手機上裝新的iOS系統，然後透過bootrom的漏洞來了解新的iOS系統的運作方式，因此這個問題應該被更加重視。

圖(六) axi0mX針對此bug的文章

保護方式

透過secure sharing將私鑰拆成User、Company、Vendor，分散私鑰存放風險

圖(七) 拆散私鑰，分散存放的風險

保護思維

未來除了在演算法的鑽研，也應該多多關注整個 區塊鏈產業的資安問題，從身分認證、系統安全、IT架構，都應該要從安全的角度來設計。

圖(八) 講者參考的設計架構

以上方的圖片為例，很多軟體架構在設計時都忽略了作業系統這一塊，而講者分享了他在設計時針對Server或資料庫的 OS做的處理，如下圖

圖(九) OS層級的安全防護

我們的app、網站、服務都跑在Sandbox層上，Sandbox可以限制由內到外的網路封包收送，同時在Sandbox之上還有Host-IDS(Host-based Intruction Detection System)會記錄及過濾程式在Sandbox跑的所有指令，而且有任何非法存取記憶體或網路封包的行為都會都過Host-IDS被記錄到Threat Intelligence，並且通知使用者。 我覺得這樣的好處是，使用者不僅可以在第一時間知道自己的帳號遭到駭客攻擊，也因為一切的動作都被Host-IDS過濾以及被記錄到Threat Intelligence，工程師也可以更快找到安全漏洞。

結語

近年來因網路的應用，資安越來越重要，除了軟體方面外，硬體方面也要兼顧安全，而使用者的觀念宣導更重要，否則不管我們的系統做的再怎麼嚴密，只要使用者意外連到駭客網站或是洩漏自己的私鑰，一切都是白談。演講中有一句話我覺得很值得借鏡，就是「我們一定要假設我們的系統會被駭客破解，而我們要做的就是盡可能減少被入侵後的損失」，上面提到的Host-IDS就是這樣的觀念，我們無法防止駭客進到Sandbox，但是可以記錄駭客的進到Sandbox後所有行為，這樣的架構才能在第一時間修正系統漏洞。

參考資料

Trezor錢包漏洞: https://bcsec.org/index/detail/id/585/tag/2

Iphone 漏洞: https://www.pcmarket.com.hk/2019/09/30/iphone-bootrom%E8%B6%8A%E7%8D%84%E5%B7%A5%E5%85%B7%E5%85%AC%E9%96%8B-4s%E8%87%B3x%E5%85%A8%E9%81%AD%E6%AE%83%E5%B9%B8%E5%8D%B1%E9%9A%AA%E6%80%A7%E4%BD%8E/

spectre&meldown介紹: https://www.youtube.com/watch?v=bs0xswK0eZk

Private key security and protection / 私錀的安全與保護 — Tim Hsu was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌