DevOps in Action, DevOps 日常/OpsDev 日常 – F5 DataSafe

起因來自於最近我常掛在嘴邊的一句話:誰上了雲端之後還用 F5 Load balancer 啊?上 Google Cloud 用的當然是 Google Cloud Load Balancing,上了 AWS 之後用的就當然是 Elastic Load Balancing,沒想到一句我看是理所當然的事情,同事間因為不同的角度,不同的專業背景,而有了不同的看法,也難怪有人說 DevOps 是一種文化轉變、是一種變革。由於我們公司的歷史說長不長,說短也有個十來年了,當初一開始經營時並沒有遇到雲崛起(AWS 崛起)的年代,所以僥倖的至今還幫客戶維運了不算小的自有機房,所以我們公司和一般使用純公有雲的公司不太一樣,我們有網路工程師、系統工程師甚至於值班工程師的配置。

這個故事開始於一位資深的網路工程師,何謂網路工程師?簡單的說就是那種有 CCNA, CCNP 甚至於有 CCIE 認證的專業人士,他們的日常工作項目就是在管各種硬體式的 Network Switch, Router, Firewall, ISP 線路, 流量一般來說,Load Balancer 由於功能或操作上也比較偏向於網路設備,所以在我碰到的公司裡,這設備一般也是歸網路工程師來管。

最近有天就產生了下面這個對話:我覺得 Clouding 上的 Load Balancer (Google or AWS) 固然便宜又方便,但是我不覺得 F5 比較差,而且看起來 AWS 就有提供 F5 的雲機器,也許我們可以考慮採用 AWS 上的 F5 雲機器服務,上次我去聽了 F5 的研討會,他們有個功能超神的,啟用之後就可以防 bot (機器人, 大概專指惡意的 bot, 例如來猜帳密的那種),還可以防中間人攻擊讓使用者帳密外洩之類的,最重要的是應用程式都不用改,F5 會自動地把 Javascript 插入在你的應用程式裡就可以作用了。

這位網工的伙伴講的很興奮,我聽了卻滿腦子黑人問號。我個人常習慣會把 IT 類的工作畫一條光譜線,一端是純開發端,也就是寫程式的啦,另一端就是純業務端,簡單來說就是不寫程式但懂客戶需求的,IT 相關的工程師,不管是管系統或管網路的,大抵來說可以算是在中間,意思就是網路工程師對於程式方面算是一知半解,知其然但不知其所以然,對於需求方面所知也是半桶水,當然這麼說是有點難聽了,事情總是可以從各種面像來看的,正面來說網路工程師是兼具兩者所長,所以可以遊走於自行開發和廠商解決方案之間,糅和出一個比較好的解決方案出來。

1

但是以這個例子而言,我們對於 F5 的這個 Advanced WAF 產品該如何取捨?我相信在傳統的分工情境下,大概不外乎就是網路工程師找廠商來 POC (Prove of Concept,概念驗證),以這個例子來說,我猜驗證的方式可能就是廠商去準備個攻擊的方法(當然這方法不會是廠商自己發明的,也許是來自於知名白帽駭客,也許是來自於某著名安全機構的概念性攻擊方法),然後測試看看裝載 Advanced WAF 前、後的差別,稍微大一點的組織,這件事情大概就很難邀請開發單位一起加入驗證了,一來也許是開發單位的人、產品或部門很多,不太可能都抓來一起驗證,一來可能是這公司的系統這邊也外包、那邊也外包,一般的公司就會認為這是網管自己的工作,不太可能邀請太多的關係者進來。

但是今天我們要打破這種傳統,單純從技術性的角度來分析這個產品,當然之所以能做到這件事,也是和我一向非常喜歡的 F5 的開放性有關,F5 大概是我看過文件和技術最開放的網路產品吧?文件整個豐富到不行,最重要的是這一大堆文件都還有人在維護的,有新版本時每個文件都會被重新檢視它的適用性,所以以下就開始我的技術分析。

DataSafe 算是 F5 Advanced WAF 裡的一個功能,Advanced WAF BIG-IP 13.1.0.2 開始提供,DataSafe 這功能就一併上市了。在以往的 Web Application 裡,瀏覽器端(或稱為 Client ) 其實是沒有任何保護的,既使是用了 SSL ,一旦使用者終端(PC, NB, 手機, 平版…) 被駭客入侵了,駭客就可以從瀏覽器端、從 OS 上側錄鍵盤或畫面等方式來劫持使用者的敏感資訊,以下是 F5 官方介紹關於 DataSafe 的影片及資料:

F5 DataSafe 介紹影片

F5 DataSafe 介紹文件

DataSafe 這個功能看起來是個執行在瀏覽器端的程式 (Javascript ?) ,藉由主動的置入 F5 所謂的 DataSafe Javascript 程式碼,幫你把敏感欄位在瀏覽器端就加密的方式,可以避免當前常見的 1)瀏覽器 plugin 問題 2) 中間人功能(有一些藏在本機把你信賴憑證偷換掉來偷聽的),然後在 F5 上就解密掉,所以讓你的 Web Application 不用修改就可以加上這個功能。

但是老實說,不管從文件上或 Youtube 影片上看來,這個機制不外乎是 1) 把程式上的 input box ID 給換給怪名字(F5說這個叫 Obfuscation) 2) 把敏感欄位資料 scramble 一下,我們可以想像的是,既使是入侵者,大概也不想要每天叮著你的網路流量去抽絲剝繭的找出敏感訊息,更何況是那種大量入侵一堆電腦的駭客,他們更不可能去分析那麼大的流量,所以可以做的就是去篩選出一些關鍵欄位或頁面來「偷聽」,這時候把欄位名稱亂取名或資料加密後,對於這類非針對性的駭客而言,應該會有一定的效果,這個道理就像是以前大家都會為自己的愛車加個方向盤鎖,偷車賊看到一排車子,為了怕麻煩就會懶得對有方向盤鎖的車子動手。

聽不懂嗎?這份 F5 文件對於 HTML Field Obfuscation 講得更仔細了,文中的兩張圖更是 清晰:

2.jpg
3.jpg

F5 這個機制做的好的地方是,他不用你自己動手去改程式,從影片看起來,你只要在他的管理介面上操作一下,這個機制的程式碼就會自動的插入在你的網站中,我想這對於許多的網管人員來說真是一大利器,因為我相信絕大多數的網管人員如果不是不會寫程式,就是程式和他不熟,至少那種有能力去寫出一個稍具規模網站的網管人員我是沒見過,能靠著 F5 這個產品就把網站漏洞給 patch 掉的這種外掛,相信在許多網管人員眼中都是神器了。

4.png

但實際上這件事有這麼難嗎?這不就也是支程式?人家文件裡也表明了這就是個把 Client 端欄位名稱加密然後配合 F5 server 上的解密行為,在這裡先讓我們看看 F5 自己的網站:

5.png

F5 似乎很顯然的沒有在他這個網站放入 DataSafe 的技術,因為我這個「中間人」利用 Developer tool 來觀察時可以很輕易的看到我自己的帳號和密碼,連帶的帳密的欄位名稱也很明顯,不符合 F5 文件裡的敘述

6.png

F5 網站自己沒有使用的原因我們難以得知,但從開發者的角度來看,既然知道了這種機制,那自己來實做會是困難的嗎?

讓我用 HTML Obfuscate 這個關鍵字來 google ,其實可以發現有很多網站在「教」大家怎麼做,例如這個,你可以把想要「Obfuscate 」的 HTML 語法貼上去,這網站就會幫你產生出攪亂後的語法:

7

當然如果你稍微比對一下 F5 的文件之後,會發現此 Obfuscate 並非彼 Obfuscate F5 的機制可不是這種單純把 HTML 語法攪亂丟到 client 端這麼簡單的,F5 提供的 Obfuscate 機制基本上應該是種非對稱式加密機制的「攪亂」,也就是被 F5 「攪亂」的 HTML 語法經由下一次 HTTP Post ( HTTP Get) F5 時,F5 會自己反解密回來,而且每一次「攪亂」出來的值都不會一樣(請參考這篇文章,這文章還提到可以抵禦的實際場景IP慢速攻擊猜帳碼)

所以說相較於一般網路上可以查到的 Obfuscate 方法,F5  DataSafe 的作法還是挺先進的。我們在網路上看到的都是屬於入門級的,這種入門級僅利用 client javascript HTML 語法攪亂的方法,對於 Client OS 的入侵可能有點混淆效果,但是對於 Man-in-the-browser 的攻擊效果就有限了,由於這類入門級的 Obfuscate 方法只對 Client 端攪亂,實際上要往 Server 上送 HTTP Post HTTP Get 時,還是得恢復原有的內容,這對於 Man-in-the-browser 的的攻擊就完全無效了。

所以我的結論是要說 F5 DataSafe 真的很神嗎?說難不難,說簡單嘛… 就我初步的 google 結果,網路上要找到現成類似 F5 做法的範例的確不太容易,但這並不是沒辦法自己撰寫的,只要開發人員願意,把幾個欄位名稱做個加解密機制基本上是一片小蛋糕來著,只是看你願不願意做這件事而已。

為什麼我特別要提到「願不願意」做這件事?這就得回到這種抵禦攻擊的方法是否有效了,假設一般稍有腦袋的猜帳密攻擊會用一堆IP來進行下面這類慢速動作:

8

當我們用了 F5 DataSafe 類的欄位加密機制後,攻擊者就無法很簡單的利用 ‘User’ ‘Pass’ 兩個欄位名稱來進行程式化的攻擊,因為每一次 F5 跑出來的 ‘User’ ‘Pass’ 欄位名稱都會被改變

例如由這個:

9.png

被攪亂變成這個:

10

那,把我的攻擊程式改複雜一點呢?稍微用人眼看一下這個例子,發現 username 欄位名稱都是以 <input type="username" name=" 這個 pattern 開頭,結尾於一個單引號,另一個 password 欄位以此類推,這不就也很快的破解了?

所以說到底,正所謂道高一尺,魔高一丈,這和偷車賊怕麻煩不偷有方向盤鎖的車子意思一樣,有做的可以對一般通殺型的駭客起一些阻嚇作用,但是對於那些專門特定來找你的惡意駭客,也就是所謂的針對式攻擊,不管是買 F5 來檔或是自己寫程式來檔,都很難依靠單一機制來防止入侵,那要做多少呢?我想還是回到風險/成本原則,也就是根據你所有的成本或資源,優先處理高風險的問題,我很少有看過有公司什麼資安都做到完的,就像我們不會在自己家裡弄個 108 道鎖來防小偷的意思一樣,當然這個決策只能由當事人自己做判斷,想聽 Sales 或外部顧問的意見? 你怎麼知道他們是在乎你的需求多一些還是在乎他的業績多一些?  你有看過 Sales 或顧問跑到你家好好研究你真正的需求在哪裡的經驗嗎? 就算對方肯,你敢讓他們來看嗎?!

F5 DataSafe 功能呢? 我個人認為這東西蠻適合哪種系統不是自己開發出來的公司,尤其是當你的公司有越多外包的網站越是這個樣子,由於有一些外包廠商可能根本也就沒維護合約了,或是要添加這個新的機制搞不好還比去買 F5 Advanced WAF 還更貴些,這時候就蠻適合來用 WAF 這東西,當然看是要買 F5 或其他廠牌的 WAF ,那又是另一個層次的決策了。

  • 對了 F5 Advanced WAF 還有另一個 Anti-Bot 功能似乎也常被來拿宣傳,只是目前沒時間研究,有接會再來研究下了
廣告

CloudFlare & Google Cloud CDN

大概前兩天吧,為了測試 Google Computer Engineer (以下簡稱 GCE) 到底好不好用,網速到底夠不夠快,我們小 J 弄了台 VM 出來測試,當時我們就對 Google Cloud CDN 表現出來的速度水準驚艷不已,不管是拿 KeyCDN Tool 來測試全球速度,拿 Webkaka站長工具來測大陸速度,加上了 Google CDN 的測速結果都比單純使用 Google Load Balance 或僅用 GCE 的狀況下要來得快很多,可惜當時只是把幾個測試結果排在一起比較,並沒有截圖留念做個證明。
* 後來我們才發現當時所放上的 Google Cloud CDN之所以快,主因是因為有一起啟用了 Anycast IP,所以 Anycast IP 才是關鍵點,細節再請看以下的測試

CloudFlare 是另外一個我很愛的 CDN Provider,價格便宜、防攻擊,後台簡單好用,免費 DNS,又常會發表技術文在他們自己的部落格上讓人觀摩,只可惜不管是 Free Plan、Pro Plan 或是 Business Plan,速度表現上和其它商用的 CDN 來說都是差強人意的,有時候不錯,有時候就很慢,至於 Enterprise Plan 我個人是沒試過,聽說是和其它 CDN 一樣可以提供某種程度的客制化,例如 best routing 一類的,希望將來有機會用到。

雖然說 CloudFlare 通常是差強人意,但每次看到他們在部落格上 寫了些黑科技,就忍不住想要嘗試一下,像是 ArgoRailgun,兩種都有網友提到說他們的測試結果不錯,有人說 Railgun 比 Argo 好,也有人測試之後說 Argo 不錯,所以今天就讓我們自己來證明一下。

我大致上的基本架構,也是目前跑在 Internet 上的配置都是 GCE 為主,然後依序加上 Google Load Balance with Anycast IP、Google CDN、CloudFlare CDN 與 CloudFlare Argo 上去,看看哪一種配置跑出來的結果最好,這次的測試我只用 KeyCDN Tool 來測試,畢竟我們網站主要的使用者並非中國用戶,KeyCDN Tool 也相對簡單穩定,不會有其它工具有時候開不到的問題。

以下的測試結果因為 KeyCDN Tool 僅有 TTFB (Time To First Byte) 的關係,所以也就只能以這個數值為參考。

SpeedTest

 

結果… 最好的狀況就是 Google Anycast IP + GCE 的合體,由於我拿來測試的網站基本上全是動態內容,看來有沒有掛上 Google CDN 並沒有顯著的差異。以上結果就是說:全部採用 Google 的服務,其它什麼 CloudFlare + GCE ,或 CloudFlare + Argo + GCE 什麼挖貴的,全部都比不上 Google Anycast IP 的數字,拿掉了 Anycast IP 之後,速度就是上不去,跑幾次都是一樣。說實在的,這對於常常在讚嘆 CloudFlare 部落格的我來說,這實在是太打臉了,和什麼廣告都沒打,後台介面又整個陽春的 Google 比起來,在速度上 Google 實在是佔了太多優勢了。後來想一想,Google 花大錢在各地架海纜果然不是做白工的,有自有大頻寬海纜這種基礎建設大概就贏八成了。

當然 CloudFlare 有其 DDoS Mitigation 的功用在,也提供免費的 SSL 證書 (Google Cloud CDN 也有),但不管有沒有用 Argo,只要是上了 SSL 的網站,速度一律再下降一個檔次,所以我索性也就不紀錄了,放了也是難看。

最後要註明的是,我這次測試的 Argo 並非 CloudFlare 的完全版,完全版的 Argo 需要安裝一個 Argo Tunnel 的程式在 Server 端,讓 Server 可以走最好的路徑到 CloudFlare 機房,接著就看有沒有機會再去測試他了,不過我的下一個測試目標應該是號稱有機會可以節省動態網站頻寬 10 倍的 Railgun,Argo Tnnel… 再等等吧。

又一個 Wifi AP 問題

由於老闆做興趣的公司多元化發展,所以跑去外地開了間旅館,一切都完工開張之後,就開始是我們的夢魘了,說是夢魘也算一半是自己造的業,當初在幫忙審弱電規格時,想說只是間不大的旅館,看到兩家廠商都提出用 DrayTek 的 Fat AP + 中央控管解決方案後,就覺得這東西可能還可以,也傻傻的以為負責統包的「廠商」會用心的幫忙解決一切的問題,結果… 廠商也就只是裝好而已,其它的也是能推就推,加上我們自己也不熟悉這個廠牌,中間的過程這邊就不抱怨了,在一步一步的試錯之後,我們今天又遇到一個麻煩事。

老闆說:那個那個 908 號房的訊號很差,無線網路還是很不好啊,到底解決了沒有?

幸好今天我們的小銳同事今天有過去開會,趕緊拿起電話急扣:快幫我去 908 號房試試,其實也幸好那房間現在沒住人,小銳同事開了門就跑進去看訊號強度。

報告報告,訊號看起來都還不錯哩,我手機上看來都有 3 格 (其實我不太確定他是拿什麼軟體看的,我腦補滿格是 5 格)。

小銳這個人其實在技術上也是挺細心的,一下子用 LINE 打給我做走動測試,一下子跑 SpeedTest,終於給了我一個 AHA :我知道哪裡有問題了!就是這個角落,小銳說他一走到這,和我的 LINE 通話就會斷斷續續。靠,這種土炮測試竟然比那些什麼 Wifi 強度 App 要來得快速有效還自帶團隊合作感,趕快繼續土炮下去,ㄟㄟㄟ,那個小銳你就一邊重複念 1~10,一邊走動,我一有聽不到的的時候就叫你停,然後看是在幾號…

AP1

測著測著小銳就想到幾週前,由於飯店在遠方,我們靠飯店那些非 IT 專業的工作人員蒐集到的問題描述又很亂:有人說連不上網路,也有人說網路速度慢,所以我們便在不同的樓層上對 AP 做上不同的設定,希望下次再來時可以藉由這些實驗組對照出還剩下的問題。

小銳說,這個樓層就是有做 2.4G + 5G 的雙頻設定,而且開了所謂的 Band Steering 功能,AP 上對這個功能的描述是:當 5G 訊號夠強時,AP 會強迫客戶端從 2.4G 跳到 5G 去。

只是沒想到,這個 5G 訊號的穿透能力看來不甚好,既使「訊號上」看起來還可以,但實際上的傳輸就是會出問題,嗯… 至少我們打 LINE 電話就出問題了。有了這個假設之後,我們就趕緊把這層樓的 5G 實驗組給拿掉,讓他只跑 2.4G 訊號,接著再讓小銳出動進行走動式土炮 LINE 通話測試,果不其然,一切就順順利利,趕快和老闆回報問題解決。

說實在的,對於 Wifi 問題我還真的沒啥辦法,又不是程式、系統或資料庫可以去翻出來看,訊號的這東西我是完全沒輒,你去問所謂的專家嘛,感覺就是叫你買 Cisco, Aruba 好像一切就解決了,你一叫他保證時他也不敢掛保證。這次大概是我處理各種 Wifi 問題以來「相對」的最有科學根據的一次吧,希望這樣子的運氣可以持續下去啊,不然三不五時的要開車跑遠地去處理也是既費時又費力。

Unifi AP 的升級

先開宗明義來說,其實不是什麼很難的東西,大致上來說,對於這類 ThinAP 的管理上,你得要注意 Controller 和 AP 之間誰負責什麼東西,才會比較容易知道問題出在哪。

1

以我今天遇到的問題來說,其實就只單純的是看到 Controller 的 GUI 上顯示了有 firmware 可以升級,按下升級鍵之後,這個 Controller 的 GUI 也是煞有其事的在那裡跑了很久,最後… 版本號碼還是顯示一樣,這問題與其說是今天發現的,倒不如說是已經發現很久了,只是之前一直沒有動機去升級它,今天是因為看到有幾位 user 反應有 Wifi 的連線問題,想說目前的版號距離上一次也已經快一年了,看 Change log 裡也滿滿的都是我看不懂的 bug fix,所以選日不如撞日,就試著解解看吧。

爬了一些論壇文章,症狀雖然都是升級不上去,但是有人教你用 GUI 上的自定義升級,有人教你 ssh 進 AP 自己下指令去 Controller 抓 firmware 下來,我甚至還跑到 AP 裡頭去看 log,但是都沒用,連 log 都沒看到任何錯誤。最後我是看到有個人提醒說要在 AP 上校時,這時候心血來朝,試著去 AP 上 ping ping 看隨便一個網址… Bingo!

原來是因為我們的 AP 由於是跑單純的 bridge mode,Controller 與 AP 之間的溝通也是透過 IP 而非 Domain name,所以當初設定的同事並沒有在 AP 上設定 DNS resolver,動手加進去之後,就可以順利由 GUI 上簡單的升級了。

2

在這個案例中,有趣的是由於 Controller 上一直顯示著可以升級 firmware,以致於我從沒想過實際的升級程序是 Controller 叫 AP 自己去抓 firmware 下來升級,加上這個 Controller 的 GUI 上也沒有正確 capture 這個錯誤出來,所以自己卡關了很久。這個升級雖然只是個不起眼的小事,卻解決了我心中卡很久的一口痰,還是覺得爽。

比威而鋼還威的 TCP BBR

前一陣子從 iThome 看到了 Google 要把 TCP BBR 應用在 Google Cloud Platform 的新聞, 才發現原來這東西這麼神,2700 倍的傳輸率,佇列延遲減少 25 倍,隨手翻了下網路上的部落格,沒想到有那麼浮誇的說法證明:下載從 84K/s 變成 3.9M/s,這立刻引起我的好奇心,找到了 Google 自己的部落格說明,原來是長久以來使用的 TCP 壅塞控制演算法有點笨,遇到有 packet loss 的狀況時,就會以比較保守的方式來傳遞接下來的封包,而新的 TCP BBR 則用了比較聰明的方法來處理 packet loss 的問題,整個示意圖就如下所示:


* Source

文中也特別拿了幾個國家為例子,說明在應用了 TCP BBR 之後,YouTube 的表現情形,不看還好,一看之下,沒想到 Google 也這麼浮誇寫實,YouTube 到 ID 的 Max Round-Trip time 竟然可以改善到 50% 以上,這讓我突然想到以前公司在進行某個網路直播專案時,那個爛 4G 網路讓我們驗收時吃了很多苦頭,所以我也來做個浮誇的測試好了。不過因為一來我很懶,二來也沒那個預算搭建回當初專案的原始架構,所以以下浮誇的測試只在我的本機上實驗。

  • 實驗環境 (都在同一台機器裡):
NB: OBS Studio 19.0.3 --> NB: clumsy-0.2 --> VM: SRS 2.0.242 + CentOS 6.9 --> NB: flv.js in Chrome
  • 實驗方法:
  1. 先以 Kernel 2.6.32-696.6.3 直接測試,擷取螢幕看直播視訊延遲
  2. 以 clumsy 加上 inbound & outbound 各 50ms 的延遲,並隨機 drop 10% 的封包
  3. 等個幾秒,擷取螢幕看直播視訊延遲
  4. 停止 clumsy,等個幾秒,擷取螢幕看直播視訊延遲
  5. 升級 Kernel 為 4.13.0-0.rc1,重複步驟 1~4
    * 我拿了一個 Firefox 開時鐘來讓 OBS 擷取螢幕畫面,所以測試畫面中會看到 Firefox
  • 實驗結果:
  1. 沒 TCP BBR,不啟用 clumsy,延遲大概 3 秒
    Without BBR - normal network
  2. 沒 TCP BBR,啟用 clumsy,稍等一下,延遲變為 13 秒,實測時這個延遲會迅速擴大,最差的狀況是影像會停掉
    Without BBR - bad network
  3. 沒 TCP BBR,把 clumsy 關掉,稍等一下,延遲回到 5 秒左右
    Without BBR - normal network again
  4. 有 TCP BBR ,不啟用 clumsy,延遲大概 2-3 秒,其實和沒 BBR 時差不多,這畫面看起來延遲只有 2 秒應該只是個測試誤差
    With BBR - normal network
  5. 有 TCP BBR,啟用 clumsy,稍等一下,延遲變為 4 秒
    With BBR - bad network
  6. 不信邪,再等一等,有 TCP BBR,啟用 clumsy,延遲還是維持 4 秒左右
    With BBR - bad network-2
  7. 恢復原狀,有 TCP BBR,不啟用 clumsy,延遲還是維持 4 秒不動
    With BBR - normal network again

總結來看,這個 TCP BBR 還真的神,在高延遲且掉包的網路上,在我的測試環境 1 個 client 對 1 個 server 的情境下就能有這麼好的表現,安裝的方法我就不特別提了,網路上隨便 google 都一堆,不過還是要提醒大家一下,再好的東西還是得先測試才能上正式環境,免得哪個不小心你就踩了坑了都不知道。

BBR Summary

玩一下 Google Compute Engine 要花很多錢嗎?

雖然身為一個 IT 人,也知道這一行要與時俱進不然就被淘汰的道理,但是我個人對於「在雲端上花錢」這件事情的態度算是偏向保守的那一派,像是 LINE Pay 已經出來半年了,我是為了貪那繳稅的回饋金才去辦卡且綁定了我的 LINE 帳號,Google Play 上就算有需要綁定過信用卡,也是用完之後就移掉,不然我自己會想像被他亂收錢。

這次之所以會想要在 GCE 上花錢,是因為看了某個對岸網友的文章,發現 Google 竟然直接在他的 GCE 上提供 Anycast IP + Global Load Balancer + CDN 的服務,因為這實在是太狂了,所以我忍不住就打破了自己的的風險規則,跑去把我的信用卡放上去。

我測試的東西也就是 Anycast IP –> With CDN –> Load Balancer –> 一台台灣 VM + 一台新加坡 VM 這樣子的架構,測試之前先在我自己電腦上的 VM 跑了一次,並且把安裝與設定步驟記錄了下來,所以去 Google 上開機器時,除了幾個 Google 自己的設定需要實驗多花了點時間之外,大致上可以說是沒幾個小時就做完相關的設定工作,然後就開始測試了。之後就放那邊放了兩天,端午節之前把 Anycast IP, CDN, Load Balancer 及新加坡機器關掉,只留下台灣這台 VM 給同事測試用 (對,我實際上的需求並沒有一定得要用 Anycast IP,只是拿來試試看功能而已),這樣子我一共花了多少錢呢? 才 US$1.96

1

而且 Google 也提供了一個預算管制的功能,當所花的錢超過你設定的預算時,就會發警示信出來。因為我拿來玩 GCE 的帳號就是我平常在用的 Google 帳號,也綁了我的 Android 手機,所以這功能讓我很安心的繼續用下去。

2

前一陣子不知道是哪位臉書上的心得,說是微軟 Azure 要和 Amazon AWS 或 Google GCE 對打還是走得很辛苦的。對照一下這幾年來看到 Google 在做的事情:Google 自建海纜、GCE、Anycast IP on GCE、Google CDN (如果 Google 要把他們在世界各個 ISP 放的 Google Global Cache 也拿來做 CDN 加速的話,那就更恐怖了),可以看到 Google 要做而且已經快做到的是「世界」的 IT Infrastructure – 全世界的中華電信、全世界的 Hinet,這意思是什麼呢?如果你今天只想做台灣的網站也就算了,如果你是想搞跨國的網路應用(電子商務、遊戲、社群、直播…),以後你也不用多想了,就直接放 Google 上就好了,如同幾年前的台灣一樣,大家想搞網路、搞遊戲,機房鐵定要選中華電信、專線一定得拉 Hinet,因為全台灣的使用者幾乎都是用 Hinet,想不接 Hinet 線路就是要讓使用者 lag 爆。這種事情以後就會反過來,大家要在全球佈局的話首選就會是 Google,因為最簡單速度又最快。

所以,學學這些 Public Cloud 的使用經驗看來就是未來 IT 人的必備技能,而且搞不好還比去學什麼 Server 安裝或 Cisco 設備操作要來得基本且必要,要練習這些東西很花錢嗎?你要練 Server 安裝、系統管理之類的可能要去買台機器或借個環境才能操作,想練網路我看很多人會花個幾千塊去網路上買二手設備來練習,但是想練 Google Public Cloud? 以我這次的例子來說,只要 1.96 鎂就好,可能比很多人一天的通勤費用還便宜些,好東西,不買嗎?

在 Windows 上使用支援 edns client subnet 的工具 – dig 9.11

2021/4/9 更新,最近換電腦下載了新版本的 dig 9.16.13,不知道從那個版本開始,+subnet 這個參數已經不能再用比 /24 廣的查詢了,所以使用時我就是都以 /24 來查詢了,例如:

> dig www.google.com @8.8.8.8 +subnet=128.32.203.137/24

2019/1/31 更新,大概是 2/1 是 DNS flag day 的關係,這篇略有相關的文章竟然也湧入了很多遊客,所以我也是 google 了一下相關文章,更新如下:

本文所提到的 edns client subnet 功能其實只能算是使用 edns 這個延伸協定中的一個項目,由於在古早的 DNS 協定中,一次 DNS query 的回應只規範了 512 bytes 的大小,由於當時網路速度慢,機器也不快,這樣子的設計也可以理解。但隨著網路越來越快,使用的情境越來越複雜時,512 bytes 大小的回應便顯得很難用了,最典型的狀況是:你最多只能有 13 個 DNS 權威伺服器,連 root DNS 也是一樣(a 到 m 共 13 個),原因是一個回應放不下,所以現在有了 edns 之後,理論上要可以到 4096 bytes,有人說這樣子可以回應出 236 個 DNS Servers,想來不久的相來可以看到 root DNS server 變多的情景了。

那為什麼很多網路上的文章寫說支持這個 DNS flag day 是為了更好更安全的網路環境呢? 這說是對也是對,說是硬湊也是可以。由於有個 DNSSEC 的協定被設計來避免 DNS poison 的安全性問題(很常見,對岸那邊尤其多),而這個 DNSSEC 協定卻依賴 edns 才有足夠的 payload 可以放這些資料,所以呢,你可以說這個 DNS flag day 是為了 DNSSEC 鋪路,因為他只測試你的 DNS Server 是不是支援 edns ,但說有 edns 相容性之後就可以提高安全性就有點超過了。(甚至於 payload 變高搞不好還可能被用來作為 DNS 放大攻擊)

那為什麼要這麼大聲量的宣傳這個東西? 其實 DNSSEC 協定推出了很久,各大的 DNS 供應商也都有支援了,只是 DNSSEC 這協定如果沒有「從最源頭到最底層」,也就是從 root DNS server 到 DNS client (eg. 你的 Windows NB) 都支援的話,那效果就不太顯著。講個例子好了,我想大家都可以理解一件事:IPv6 從 1994 年出現到現在一直都沒成為主流,就可以知道想在 Internet 上「全面」的推行一個新標準有多困難,由於要推行 DNSSEC 不只是所有的 DNS Server 都得全面更新,連可能經過的 firewall, load balancer 之類的設備也可能需要升級 (eg. 你的 F5 GTM 版本支援 EDNS 嗎?),所以先從這著手鋪路一下是個不錯的漸進手段。

和這篇文章的關係是? 其實我覺得要驗證是不是 edns 相容最好最快的方法就是用官方網站上的測試網頁了,如果真的想要手動測試的話,請參考下文去下載 Windows 下的 dig 程式 (BIND 9.11.0 之後),然後依照這個方法來手動測試。

啥? 那為什麼 Hinet 或 TWNIC 一直廣告說讓大家用他們的 DNS Server (168.95.1.1 或 101.101.101.101) 就不會有影響? 那顯然就是她們為了「體恤」那些還來不及做好相容性升級的域名管理者(或網站),所以選擇不加入這個「為網際網路安全」的下一步

———————————-以下是原文章 ————————————

之前提到了說 BIND 會從 9.11 開始支援 EDNS client-subnet,所以若你的 BIND 已經開始使用 GeoDNS 的功能,恰好你的 end user 用的 DNS server 也支援 EDNS client-subnet 的話 (eg. Google DNS 就支援),那恭喜你,你的 GeoDNS 的效果應該會變得更加顯著。

但實際把功能丟上去之後,你就會發現有事沒事的你會遇到使用者抱怨他連你的網站速度太慢,原因是因為你的 GeoDNS 回給他的結果和你預期的不同,原本你想要 GeoDNS 丟個離日本最近的 IP 給他,但他拿到的卻是個英國的 IP。這時候我們就需要個可以快速驗證 GeoDNS 設定是否正確的工具了。

這工具其實也很簡單,因為就是隨著 BIND 9.11 一起更新的 dig 命令,只是以前我笨笨的,以為 BIND 只有出 source code,自己又沒種花時間去 Windows 下建立編譯的環境,所以都是去抓別人編譯好的執行檔,自己都覺得有點不是挺安全的,不過剛剛仔細一瞧,原來 ISC 自己的官方網站上就放了 BIND 的 Windows 版,只要下載之後安裝也就可以用了…

01

安裝的時候只要選擇「Tools Only」就好,我想大家也不想在自己的電腦裡裝個用不著的 BIND Server

02

裝好之後,如果你像我一樣對自己用的系統有一點潔癖的話,可以把目錄下的這些檔案(除 BINDInstall之外)拷貝到你喜歡的目錄,剩下的東西則可以全部移除。

03

dig + EDNS client-subnet 的使用方法也很簡單,就是

dig [domain name you want to query] @[DNS Server] +subnet=[addr]

http://www.google.com 為例,如果我是個位於美國的使用者,IP 是 128.32.203.137 (我隨便抓了個柏克萊大學的 IP 來測試),解析出來的會是 172.217.5.100

04

那如果我是個台大的學生,IP 是 140.112.8.116 的話,解析出來的會是 163.28.18.30 (左右…)

05

我自己現在用的是遠傳的網路,從 ping 的結果看來,Google 應該也是有應用 GeoDNS 來加快網站的速度(當然也用了 BGP anycast,但不在此文討論範圍)

06

最後,更笨的是,如果你什麼都不想裝,就用別人放在雲端上的服務就好了…

https://tools.keycdn.com/dig

區網電腦透過pfsense取得ISP的IPv6

首先,要先去申請IPv6,這是"完全免費的"以中華來說,可以臨櫃申請,也可以線上申請,在這邊網頁上Ctrl+F搜尋ipv6申請

IPv6_ready_logo_phase2

在這邊使用的是pfsense2.2.6版本,但設定應該大同小異 繼續閱讀「區網電腦透過pfsense取得ISP的IPv6」

Centos 路由去回不同路解決方式

不知道大家有沒有在linux伺服器上有兩張網卡,且設有多段IP,但是卻如法在同網段ping通和tracert的經驗

本人我就遇過這樣的問題

如果你有兩張網卡 eth0與eth1

eth0的網段為10.10.1.0/24

eth1的網段為10.20.1.0/24

我們假設網段10.10.1.0/24的gateway是10.10.1.1

預定要讓預設的gateway裝置eth0回的話,解決的方式如下:

1.編輯iproute的規則名稱
[root@pandacentos ~]#vi /etc/iproute2/rt_tables
10     pandaroute #10為route table的值,pandaroute為route table名稱,都可自訂,但名稱請取服務名稱,方便辨識
2.重啟網路服務
[root@pandacentos ~]#service network restart
3.增加route的rule
[root@pandacentos ~]#ip route add default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#ip rule add from 10.10.1.0/24 table pandaroute
以上的方式試一次性的解決方式,因為沒加到static route,所以在重開機後route就會消失,要如何避免這個問題,你可以在/etc/rc.d/rc.local上加上面這兩行制令,或用下面的static route 和rule的方式添加
[root@pandacentos ~]#vi /etc/sysconfig/network-script/route-eth0
default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#vi /etc/sysconfig/netwrok-script/rule-eth0
from 10.10.1.0/24 table pandaroute
4.如果是加static route的方式,請在重起一次網路服務
[root@pandacentos ~]#service network restart

提醒一下, SHA1 簽章的 SSL 憑證要不能使用了

之前的 SSL 憑證安全文已經發表兩年了,這一段時間以來 SSL 憑證的安全性儼然就是一種顯學,連我這種沒涉獵那麼深的死工程師也可以寫些文來給人看。今天心血來潮,再寫幾個字來提醒大家好了。

關於 SHA1 的問題,剛剛發現黑暗大已經寫得非常清楚了,大家就自己連過看就好了,這個問題可不是自己去 F5, Server 調一調參數就可以解決的問題,該重新申請憑證或要求補發的就趕快弄一弄,免得現在網站開起來很尷尬如下:

在 Chrome 裡面沒有綠色了
No Green

按下去還會有 Chrome 的說明說 SHA1 已經不適用了
No Green2