Home » Computer » Archive by category "Network" (Page 3)

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

HiNet 對於 DNS flag day 的公告

先前提到了各大 Public DNS 服務將會在二月正式關閉對 EDNS 的 workaround,也就是 DNS flag day:「從二月開始不回應 EDNS 的 DNS server 將會無法查詢」,而 HiNet 也發出對應的公告了:「(DNS flag day) 部分Public DNS業者將於2019年2月1日執行EDNS符合性驗證」。

說明:一、 因應部分Public DNS服務(如Cloudflare 1.1.1.1、Google 8.8.8.8、IBM 9.9.9.9等)將於2019年2月1日執行EDNS符合性驗證(Extension mechanisms for DNS, DNS延伸機制),屆時如不支援EDNS協定之域名將造成Public DNS無法順利解析或解析反應變慢。 ( 參閱TWNIC 2019-01-23最新消息 https://blog.twnic.net.tw/2019/01/23/2286/ ) 二、 使用HiNet DNS服務(168.95.1.1與168.95.192.1)及HiNet代管DNS服務,皆可正常解析不受影響。 三、 若使用上述Public DNS服務,發生有部分域名無法解析情況,可改使用HiNet DNS服務,即可恢復正常解析。

一方面說明他們有處理他們自己的 DNS hosting,另外一方面順便推廣一下自家本來的 168.95.1.1168.95.192.1,但目前沒打算拿掉 DNS flag day 的 workaround XDDD

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外,在「Preload Scripts」這邊看到的技巧,可以跟 browser 說明哪些資源比較重要,請儘快先下載:

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法,這個技巧應該用在會卡住頁面呈現的部分,確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面,理論上會更快:

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助,建議可以跑 A/B test 看看效果:

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明:「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護,但會使得維護的複雜度變高很多。

首先是被竄改的問題,APT 本身就有簽名機制 (參考「SecureApt」),即使 mirror site 被打下來也無法成功竄改內容,反而比起單純的 HTTPS 保護還好。

而對於隱私問題,由於內容是可以公開取得的,這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法),加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高),所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack),APT 降低風險的解法是把時間簽進去,當用戶端發現太久沒更新時,就當作過期失效而提出警告。

就以上來看,把所有的 APT 伺服器都加上 HTTPS 的工程太浩大,而得到的效益太小。所以願意提供 HTTPS 的站台就提供,但主要的保護還是從本來的 SecureApt 機制上提供。

從二月開始不回應 EDNS 的 DNS server 將會無法查詢

在「DNS flag day」這邊看到 EDNS 的 workaround。

目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。

而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

往下可以看到會做出改變的廠商包括了 GoogleCloudflare,可以預期 8.8.8.8 (8.8.4.4) 與 1.1.1.1(1.0.0.1) 都會進行更新。

網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw 看起來會掛掉,不知道二月前會不會修正這個問題... XD

AWS 的備份服務 AWS Backup

AWS 把備份拉出來成為一個服務,AWS Backup:「AWS Backup – Automate and Centrally Manage Your Backups」。

常見的 AWS 的服務 (有資料的) 都可以放進去,包括雲端裡的 EFSRDSDynamoDBEBS,以及本地端的 Storage Gateway

在頁面上沒看到價錢,但登入 console 後可以看到說明,只有使用的 storage 費用:

With AWS Backup, you pay only for the amount of backup storage you use and the amount of backup data you restore in the month. There is no minimum fee and there are no set-up charges.

前員工監控公司網路的抓包過程...

看到「The curious case of the Raspberry Pi in the network closet」這篇有趣的過程,先從開頭與最後面開始看。首先是他們在辦公室裡面發現有個奇怪的設備:

追查後發現不是公司的人放的,最後發現是前員工放的,後來轉給法務部門處理了:

I checked the DNS logs and found the exact date and time when the Pi was first seen in the network. I checked the RADIUS logs to see which employee was at the premises at that time and I saw multiple error messages that a deactivated account tried to connect to wifi.

That deactivated account belongs to an ex employee who (for some reason) made a deal with management that he could still have a key for a few months until he moved all his stuff out of the building (don't ask..).

中間的過程還蠻有趣的,包括研究是什麼擴充卡 (以及用途),然後從 SD card 上面挖資料,配合 Google 找線索,還有透過 WiGLE 定位,以及透過內部系統交叉比對,最後找到兇手...

然後發現是離職員工以搬東西當作理由,讓他在離職後還有辦公室鑰匙而導致的 XDDD

Secondary DNS Service

看到有人想要找個 secondary DNS service,列出了不少商家:「Comparing secondary authoritative DNS service providers」。

這種通常是已經有習慣的管理模式 (像是用 Git 管 zone file 已經習慣了),不方便或是不想要轉移到雲服務上面 (像是「
StackOverflow 對於多 DNS 商的同步方式...」或是「
GitHub 也自己搞了一套管理多家 DNS 的程式...」這樣的方式),所以想要找 secondary DNS service 提供服務。

雖然作者主要是針對 DNSSEC 相關的情境在評估,但也因此列了不少 provider 在上面,之後有需要用到的時候可以研究看看...

Archives