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 功能似乎也常被來拿宣傳,只是目前沒時間研究,有接會再來研究下了
廣告

讓你的 SSL 更安全 – 移除弱 SSL 加密方式 (Cipher)

SSL安全性如何強化,含括了當前流行的各種伺服器的設定方式,包括IIS, Apache, F5 Load balancer, A10 等

SSL 通訊協定下,一開始 Client 與 Server 進行 Handshake 時,彼此會「溝通」有哪些加密方式是彼此都支援的,然後約定好稍後傳輸資料的加密方式。會使用哪一種加密方式和我們買的 SSL 憑證的價格並沒有絕對直接的關係,既使你買的是一年價值 TWD 35,000 的 VeriSign Secure Site with EV,也可能因為設定的緣故而導致於只用到 40 bits 的加密方式。

由於硬體的處理能力逐年的提升,舊加密方式的安全性會相對的變得容易破解,所以新的及更高規格的加密方式就不斷的被開發出來。但是一來是因為新的加密方式推出之後不一定所有的廠商都支援,另外有些舊規格的硬體也許無法負擔較高規格加密方式的運算需求,既使是沒有以上兩種限制,但光從實務面上,我們也很難要求世界上所有 Client 與 Server 都可以隨時更新到最新的版本。所以一般來說,就只會建議禁用那些特別弱或已經證實可被破解的加密方式。而一個好的系統管理員,或有在重視網站安全性的公司,就會定期去檢驗所管理網站上的弱安全性加密方式是否已經被禁用了,畢竟一旦當客戶上了我們的網站,若因為 SSL 加密方式太弱而讓客戶的機密資訊外洩,損失的也是我們自己。不過很可惜的是,台灣有許多的網站並不太注重這件事情,我不太清楚原因為何?不過老實說,就算是我們用了這些所謂的弱 SSL 加密方式,想要側錄並進行破解還是得有一定的配合條件,一般的駭客或木馬想來應該寧願把功夫先花在那些未加密的連線或是 Key strokes 的側錄,而非花功夫去破解這些已經加密過後的東西。

只是身為一個知名網站的管理者,為了避免駭客針對性的攻擊,我們還是得用 100 分的標準來看待這件事情,以台灣的網站來看,我們利用 Qualys Labs 所提供的免費檢測工具,檢查了幾個國內的知名網站:

知名遊戲網站 1:
01

知名遊戲網站 2:
02

知名電信公司 1:
03

知名電信公司 2:
04

知名網購:
05

若以該網站的統計數據來看,拿到 B 的網站是最大宗的,第二名反倒是拿到 F 的網站,由於這是個英文網站,測試的標的應該來自於全世界各地,可見得就算是把這個標準放在全世界來看,拿到 A 級分的網站比例也是不高的。 (2016/11/28 更新,截至目前為止,拿到 A 的比例已經是最高的了,SSL Labs 測試的樣本中,有 48.3% 的網站都可以拿到 A 以上)

06

其實拿到 B 也不表示這個網站不夠安全,讓我們來看看這個分數的組成定義,首先是 Certificate ,從以上的例子來看,這個項目的分數大家都是拿 100,表示大家的 SSL 憑證都沒有過期,而且是和網址相符的,也沒有 Chain certificate 的問題。表示上述每一個網站的 SSL 憑證都有被正常的申請及安裝。

第二個項目是 Protocol Support ,由該網站的定義中可以發現,他是用 SSL 2.0, 3.0 和 TLS 1.0, 1.1, 1.2 的支援程度來做加權平均的,而且自 2014 年 1 月起,不支援 TLS 1.2 的就會被打到 B 去,可見得這個網站也是越來越嚴格。我看很多台灣人還是在使用 Windows XP ,這些人既使安裝了 XP 能支援到的 IE8,其 TLS 也只支援到 TLS 1.0 的版本,連 TLS 1.1 都不支援,更遑論 TLS 1.2 了。而 Windows 7 上的 IE 則是需要到 IE 11 才支援 TLS 1.2,若你的 Windows 7 上安裝的是 IE 10 ,那也只支援到 TLS 1.1。那表示既使是伺服器已經可以支援到 TLS 1.2 ,瀏覽器沒有支援到位的話,他們之間還是會以較低的加密方式來處理 SSL。所以你說可不可以從伺服器端把 TLS 1.0 禁用?那表示你不打算讓 Windows XP 的 IE 使用者連上來了。

第三和第四個項目是 Key Exchange 與 Cipher Strength 這一點,基本上這個網站會告訴你,哪些 Cipher Suites 是安全的,哪些是安全性較弱,而哪些是完全不安全的,以下圖來看,那些有用到 MD5 作為演算法的加密方法都被標示為 INSECURE,由於 MD5 在 2009 年已經被證實在一般的電腦上只要花數秒的時間即可破解,所以無論是多少長度的金鑰也是無濟於事。另外那些短於 1024 bits 長度金鑰則會被歸類為 WEAK,因為長度過短,所以相對來說容易被破解,最好也是禁用掉。

07

其實不管是 Web server (IIS 或 Apache),能作為 SSL Proxy 的設備或服務 (如 Load Balancer, CDN),當推出新版本時,都會適當的在預設值中就禁用一些不安全的憑證,但是身為系統管理員,就會知道有時候因為升級版本需要新的授權預算,有時候是因為應用程式和新版本不相容等等的原因,我們並沒有辦法每一次都跟著廠商一起升級,所以瞭解你所管理的系統該怎麼禁用不安全的加密方式就顯得非常重要了。

要檢查你的網站目前支援了哪些加密方式除了可以用上述的網站之外,如果你不太希望「公開」地留下查詢的資料,或是希望在還沒有正式上線前進行檢查,也可以利用 OpenSSLSSLScan (Windows 版),來查詢或驗證。我自己是用後者,因為操作起來方便又簡單,執行出來的結果就如下圖所示,其中 Accepted 的 Cipher 已經很少了
(* 2015/07/27 更改 SSLScan 連結,原版本已經久未更新,我另外在 Github 上找了另外一個版本,用法相同,但顯示方式不同)

08

如何禁用?在 Windows 上的 IIS 會挺麻煩,根據這篇文章所示,你必須手動去更改 Registry,而且改完之後必須要重開機,由於每個加密方式在 Registry 的命名方式不太一樣,所以需要時要去找出來,或參考這篇。感覺上有點麻煩嗎?那請服用網友推薦的這個小工具,直接用選的,而且還內附 Qualys SSL Labs 的捷徑。

09

至於 Apache ,基本上就是在設定檔中把想要禁用的 Cipher string 給加入就可以了,一般我們會不太希望把所有設定都搞在 httpd.conf 中,所以大家一般都是把這樣子的禁用字串寫到 /etc/httpd/conf.d/ssl.conf 裡。語法請參考這裡。另外這裡有提供簡單的說明網頁

由於 F5 也是和 Apache 一樣使用 OpenSSL 來提供 SSL 功能,所以在 Local Traffic -> Profiles -> SSL -> Client 選單中,選擇你要修改的 clientssl profile,然後選 Advanced,就可以在 Ciphers 欄位中填入欲禁用的字串

10

如同之前有提到的,F5 每個版本都會禁用掉一些不安全的加密方式,這裡是 10.x 以前版本的啟用清單,而這裡放的就是 11.x 的啟用清單。

A10 的 SSL Cipher 支援則是比較特別一點,它是可以用「選」的,

11

Windows 2008/2012 支援的加密方式如此頁面所示,OpenSSL 則在該頁面中有列出不再支援的加密方式 (Deprecated SSL v2.0 cipher suites)。但很顯然的,Windows 或 OpenSSL 預設禁用的加密方式就不會太多,所以自己提高警覺,根據你的需要去設定要支援的加密方式,才是最佳的安全之道。

  • 至於其他 Web server ,我猜只要是使用 OpenSSL 套件的,應該可以在某個設定檔/設定畫面中找到放禁用字串的地方
  • 補充:文中所提到的 Qualys Labs 的工具網站也增加了最近熱門的 HeartBleed 偵測 (2014/04/22)
  • Qualys Labs 的工具網站也增加了最近熱門的 POODLE (SSLv3 漏洞) 偵測 (2014/10/21)
  • 2014/10/21 更新: 10/14 時有個 SSLv3 的漏洞被發佈 CVE-2014-3566 ,由於預設採用 SSLv3 的瀏覽器很少(幾乎沒有),且多半還可以走 TLS ,所以 Linode 就建議把 SSLv3 給關掉,Linode 網站 上提有供各種 Open source web server 的 SSLv3 關閉方法,請自行參閱。F5 也提供了對應措施,有趣的是,F5 早在 2014/03/03 發表的 11.5.0 版本時就把 SSLv3 給關掉了
  • 2020/04/07 更新: 沒想到從 2020/01/31 開始,TLS 1.0 和 1.1 也變成不那麼安全了,全打到 Grade B 去