虛擬化安全

虛擬化安全

組織面對網路安全與服務管理的挑戰性愈來愈高。為了滿足市場需求，往往需要更多的網頁應用程式、電子商務、全球Web服務、與24 X 7線上營運機制。在此趨勢的帶動下，使得Server Farms與Data Center的快速成長變得不易控制，如: 需要愈來愈多的硬體、擺設空間、線路佈建、網路設備、管理人員等。此時，虛擬化的出現成為最佳的解決方案。
虛擬化技術使人們得以在同一台主機上裝設多的虛擬伺服器、運行不同的作業系統、不同的應用程式，這讓硬體的使用效率提高、能源損秏減少、與成本降低，同時虛擬化也讓組織的網路基礎設施、災害復原機制、營運持續機制更彈性與簡單。但是，虛擬化也讓駭客存取有價值資料的流程，縮短到只需在同一台主機上作業。以下即針對虛擬化弱點問題與解決方法進行探討。

虛擬化環境
虛擬化本身的安全問題，我們可以透過網路架構的組成來了解。通常應用程式的架構組成包含了下列三個階層:
1. 後端資料庫(Back-End Database): 存放組織與客戶的重要資料，也是駭客的最終目標。
2. 中繼應用程式(Application Middleware): 接受使用者需要的動作並與後端資料庫溝通，與使用者溝通的靈魂。
3. 前端Web服務(Front-End Web Servers): 提供外部用戶存取上面兩層架構的服務介面。
通常在非虛擬化的基礎架構下，上述每一個階層都處於自有系統與所屬的網路區段，也為各別區段與系統提供安全保護，如透過Firewall與IPS(入侵防禦系統)在系統前方防護。Firewall所保護的是Web Server層次，且一定允許Web流量通過Firewall; IPS設備所做的是流量深層檢測，通常置於中繼應用程式前方，同時保護中繼應用程式與後端資料庫。
在虛擬環境的應用上，三層應用程式架構將被安裝於同一台實體主機，這是Virtual Machines所提供的好處，可以讓多個虛擬系統、多個IT環境在單一台實體伺服器上運行。在了解虛擬系統應用的方便下，有一個研究數據讓您參考，根據Nemertes研究指出，現有環境下針對虛擬化系統進行安全防護的組織不到10%，這代表虛擬化技術的快速發展，其實很少人意織到虛擬化必需考慮它的安全問題，大部份的人認為只需保持系統更新就能安全。



安全挑戰
硬體式安全解決方案上的作業系統，通常需要安裝於某種ASIC晶片才能維持運作速度的需求，這讓軟體與作業系統都必需在特定規格的硬體上才能運行，也因此無法將傳統Firewall虛擬化，這導致VM之間的威脅流量是不受管控的。
透過硬體式安全解決方案在實體Server之外監看與阻擋安全威脅，以防止威脅流量接觸實體伺服器。但這也僅限於Server外部流量保護，在各別VM之間的流量是無法保護的，特別在同一個process要跨不同VM情況下。例如我們會用硬體Firewall來保護邊界網路安全，但這是不夠的，因為並不是所有流量都來自Internet，當某個VM與其它VM進行流量溝通時就不受控制。通常外部Firewall會允許某個HTTP的連線到某個虛擬機器，但這台虛擬機器卻可以自由的連向其它虛擬伺服器的所有Protocol。
試想一個情況，當我們將多層的應用程式服務建構在同一台虛擬主機上對外提供服務，並以硬體式安全解決方案在Server前方進行防護，的確可以簡化系統與管理，但它所面臨的安全威脅一定比傳統各應用層分別在各實體主機上時來的高，因為所有虛擬伺服器間的流量是完全自由不受限制的。根據Nemertes研究報告指出，有78%的虛擬化設計，將三層應用程服務裝設在同一台虛擬主機，且直接業客戶提供服務。
現今網頁應用程式的架構愈變愈複雜，所面對的弱點威脅成長到需警愓的地步，更糟的是，當一個弱點被發現到成為Exploit的時間不斷的縮短，我們可以想像的到，原本駭客用於實體環境的Exploit也會運用到虛擬環境上。舉個例子來說，駭客的攻擊會先針對前端應用程式進行不易發覺的情報收集(Information Gathering)，再利用Zero-day Exploit進行攻擊，攻擊後駭客就能從前端應用平台利用傳統的攻擊方式去試著攻擊其它應用平台，如利用Port Scans或Exploits。這代表的是駭客可以在許多平台上取得存取權限，特別是虛擬化環境可能會一次拿下所有虛擬系統、應用程式、後端資料庫，因為虛擬化讓駭客在不同虛擬主機之間的存取更為方便與自由。
虛擬主機與虛擬主機之間的溝通是不會離開虛擬環境的，所以在主機前方進行防護的Firewall或IPS是不能看到虛擬主機間溝通的流量，這也限制了組織對抗網路威脅的能力。因為沒有東西能夠監看到虛擬主機之間的流量，組織就無法對什麼人?在什麼時間?做了什麼事?進行稽核，這也是為何許多稽核人員在進行虛擬環境稽核後，都會提出”Material Weaknesses”的稽核報告。

安全方案
為了確保資料的完整性，虛擬網路之間的流量必需受到保護。不論是進入實體主機或虛擬主機之間的威脅流量都必需受到管控，存在於虛擬主機之間的威脅就如同實體環境一樣，如Traffic Abuse,Denial-Of-Service,P2P等溝通流量。
以下提出幾個虛擬化安全常見的解決方案，供您的組織於建置虛擬化安全時參考:
。虛擬環境之間設置實體安全設備
。使用Virtual Lan (VLAN) 標籤
。單點虛擬安全產品
。虛擬式交換器(Virtual Switch)
。軟體式虛擬安全設備

虛擬環境之間設置實體安全設備
某些組織試著將實體網路安全設備置於實體虛擬主機之間進行安全防護，通常他們會以業務營運單位、或應用程式種類來區分不同的虛擬主機，如以人事部門、業務部門、RD部門、薪資部門等。這個解決方案建置起來很容易，看起來也可以很簡單地解決問題，但其實這個方案仍有許多值得考慮的部份。
第一、 多層次的防護增加了實體佈屬，也違反虛擬技術簡化的本意。為每一台虛擬設備前方設置實體安全設備，成本的增加是一大考量點，同時也增加了空間的使用與能源秏用，而且虛擬化的營運持續與災害復原機制也因為實體設備的導入而破壞，因為實體設備不像虛擬環境可以輕易的複製，實體設備的營運持續與災害復原機制需要再增設其它功能，而虛擬化技術則內鍵此強大功能。
第二、 使用傳統Firewall與IPS設備於每個虛擬設備之間，會增加網路環境的複雜性且產生更多的安全性與可用性風險。一旦在虛擬主機前方設置實體安全設備，為了控制流量就必需設置很多Routing Table來管理，也為了讓所有流量都能經過實體安全設備，所有虛擬流量會先指向前方的硬體Firewall或IPS，之後再將流量送回虛擬主機才完成流量過濾，不僅效率較低也產生一個安全問題，要維護如此大量的Routing Table即使是資深的管理人員，也覺得容易有設定錯誤導致安全疑慮的可能性。
第三、 雖然在虛擬主機前方設置實體安全設備，但是在虛擬主機內的所有流量，置於前方的實體安全設備是無法接觸到後端主機內部的任何流量。

使用Virtual Lan (VLAN) 標籤
某些組織會在虛擬環境之內利用VLAN(Virtual Local Area Networks)來區分信任區域，VLAN的起源是用來區分不同部門共用同一網路環境的技術，有點像一個網路環境內連線到router的設定。為了確保準確的監看所有流量，每個VLAN連線必需有相對應的Policy，網路管理員就肩負維護所有Policy與每個VLAN連線的吻合，在較大的虛擬佈署環境裡，可能需要手動更新數百到數千條相對應資料。
在快速成長的企業環境裡網路設定會不斷的改變與增加，手動更新VLAN標籤不只乏味、沒有效率也存在風險。比如有一條VLAN Policy沒有更新、或更新失敗，這可能導致組織的機密資料被未授權的使用者存取，從管理角度來看，這是不可接受的管理方式，而從風險角度來看，所面對的風險是深不可測的。
而且手動更新VLAN標籤會使虛擬化的營運持續與災害復原靈活性降低，因為除了日常的VLAN標籤管理之外，當組織從日常操作切換到災害復原模式時，可能還必需重新設定數百條的VLAN標籤以符合新網路或Server環境架構，這與災害復原的概念”將完整產品環境複製”是不同的，總是會有些微的不同在不同模式切換時，如不同的IP與網路設定需要在切換時做調整，這也就是為什麼在災害復原環境下需要變更不同的VLAN標籤。


單點虛擬安全產品
為了滿足虛擬安全需求，某些廠商提出在虛擬環境下運作的軟體式產品，這樣的產品可以解決虛擬主機之間溝通流量無法監看的問題，不過也因為是設計於虛擬環境之內，所以無法了解虛擬環境之外的狀況、無法將實體與虛擬狀況做結合。
一旦將實體與虛擬安全分開就無法有效的結合管理，管理者必需登入到不同系統才能觀察流經網路環境的流量，如果環境有SIEM(資訊安全事件管理)平台，雖然可以整合不同來源的事件進行分析，但是從經驗來看往往會有重要、詳細的資訊可能在處理流程中消失。
這樣的產品使用非實體環境的新式APIs與工具，這樣的問題在於它並沒有被廣泛的使用與測試過，可能會有潛在未知的弱點。而且也可能需改變現有虛擬環境設定，如需在每個虛擬系統裝設軟體元件。增加這樣的產品與整個資料中心結合，在管理上會增加複雜度、也增加威脅程度。

虛擬式交換器(Virtual Switch)
有一些組織保護虛擬環境的方式是以虛擬式交換器來做，這樣的安全技術是以ACL(Access Control Lists)提供Layer 2與Layer 3的安全防護。這樣的安全防護缺少的是應用層面的安全，特別是在面對現今多變的虛擬化威脅還境是不夠的。
也因為它是Switch，所以從管理介面裡能夠看到與了解的安全資訊是有限的，這代表的是管理人員對於虛擬環境正發生的事情會有盲點，也讓環境可能會比以往擁有更多的弱點。沒有完整的事件管理功能缺點，會使得需要即時反應的可疑攻擊速度出問題。

軟體式虛擬安全設備
軟體式虛擬安全設備其實就如同單點虛擬安全產品一樣，以軟體的方式提供虛擬環境的安全，唯一的差異是單點虛擬安全產品會需要更動虛擬系統的設定，而軟體式虛擬安全設備則不用，它就像一台真實的設備一樣，於VM前進行防護，但它是以軟體的方式安裝在虛擬環境上。
所以面對災害復原與營運持續的問題，它可以輕易的就一般的虛擬系統一樣快速更換環境沒有問題。面對管理的統合問題，由於這樣的解決方案通常是實體安全設備廠商所提供的，只需利用原有的集中管理平台，就能同時進行實體安全設備與虛擬安全設備的統合管理，不會有管理盲點的問題存在。


結論
虛擬化的確可以為組織帶來很多的好處，如硬體使用效率提升、能源始用降低、資料中心同步、營運持續與災害復原機制的靈活度等，但同時我們也必需考慮虛擬化技術本身所存在的安全風險。虛擬化環境面臨的安全威脅與實體其實同樣嚴峻，但解決方案卻全然不同。簡單的說，沒有人會讓自已的企業網路在沒經過Firewall的狀況下直接連上網際網路，而虛擬環境的安全概念其實也是一樣的。文中提到的五個解決方案，都能對虛擬環境提供某種程度的安全防護，而軟體式虛擬安全設備，是目前最完整的解決方案。

英文商業信寫作參考語法

由於工作上需要跟原廠溝通，雖然原廠都是中國人，但…
都習慣用英文書寫(不是很懂Why~~中國人怎麼不愛用中文??)

而且台灣的英文環境沒那麼好，如我們原廠有香港、新加坡、連中國英文也比台灣好@@
台灣的環境沒有說英文的習慣，所以就算學校學一學，在日常生活中用不到，也就沒辦法
變成習慣的語言。

如果你跟我一樣，有著破英文，又需在工作上用英文寫商業信件，不想讓破英文在信件中太失禮，希望下面這些筆記對你有所幫助^^只要在關鍵點套進去，感覺就有一定的fu了!!
(下面文章是我從這個網站上學來的http://esl.about.com ，大部份是翻譯，英文不錯的人，建議直接看原文)

文章的開始:
1.Dear Personnel Director,(指導你的人~超尊重)
2.Dear Sir or Madam: (不知道對方是誰時，最保險的尊稱)
3.Dear Dr, Mr, Mrs, Miss or Ms Smith: (知道對方是誰也有正式關系時使用)
4.Dear Frank: (對較親近的合作伙伴或是朋友使用)
5.To Whom It May Concern:(知道有人，但不知道是誰，如寫信問某公司資訊)
6.Hi John: (親到不行時用，不建議在商業書信中出現)


參考、引用
1.With reference to your advertisement in the (之前提供的建議)
2.Times, your letter of 23 rd March,(3月23日信中提到的)
3.your phone call today, (今天電話中談到的)
4.Thank you for your letter of March 5 th . (感謝三月5日的信中的資訊)
5.Regarding your advertisement (ad) in ...(您提供的建議)

寫信原因
1.I am writing to inquire about (想尋問某事)
2.apologize for (想為某事道歉)
3.confirm (想要確認...)

要求
1. Could you possibly? (有沒有可能…某事)
2.I would be grateful if you could (如果能幫某事…會很高興的，較客氣的用法)
3.would (Could) you please send me ... (能不能請您寄給我...)

答應用求
I would be delighted to (很開心答應對方要求)

拒絕要求
1.Unfortunately (不幸的...)
2.I am afraid that (恐怕不能夠....)


附件、參考資料
1.I am enclosing (我附上…)
2.Please find enclosed (請參考附件)
3.Enclosed you will find (附件中您能找到…)
4.We are pleased to enclose ...(我們很樂意提供...)

結語提醒
1.Thank you for your help Please contact us again if we can help in any way.
(謝謝您的幫忙，有任何我們可以幫忙的地方請與我們連絡)
2.there are any problems. (有許多問題…待解決)
3.you have any questions. (如有任何問題)
4.We would also like to inform you ...(我們很意的提醒您...)
5.In answer to your question (inquiry) about ... (關於您的問題，我們的答覆是...)

期待對方回應
1.I look forward to ... (我期待…)
2.hearing from you soon. (希望盡快得到回覆)
3.meeting you next Tuesday. (下週二見)
4.seeing you next Thursday. (下週四見)
5.We look forward to ... (hearing from you / receiving your order / welcoming you as our client (customer)) (寫給客戶用的)

結尾
1.Yours faithfully, (不知對方名字時使用，像中文的"敬上")
2.Yours sincerely, (知道對方名字時使用，像中文"真誠的祝福")
3.Best wishes, (較一般的用法)
4.Best regards, (最常見用法，對較熟悉的合作伙伴、或朋友)

範例1:回應客戶的確認信
Dear Mr Flintstone: (知道對方名字，但因仍是正式書信，加上Mr)

With reference to our telephone(參考:電話中提過) conversation today, I am writing to confirm(寫信目的:confirm) your order for: 120 x Cheddar Deluxe Ref. No. 856

The order will be shipped within three days via UPS and should arrive at your store in about 10 days.

Please contact us again if we can help in any way.(結語提醒)

Yours sincerely,(知道名字時，但仍很正式用sincerely)

Kenneth Beare(先寫名字)
Director of Ken's Cheese House (再寫職稱)

範例2:寫信要產品資訊
To Whom It May Concern:(給某個會服務你的人)

With reference to your advertisement (參考:您提供的建議)in yesterday's New York Times, could you please send me (要求)a copy of your latest catalogue. I would also like to know if it is possible to make purchases online.

Yours faithfully

(Signature)

範例3: 回覆客戶要求
Dear Mr Beare

Thank you for your inquiry (感謝來函)of 12 September asking for the latest edition of our catalogue.

We are pleased to enclose (樂意附上)our latest brochure. We would also like to inform you that it is possible to make purchases online at(線上的參考資訊) http:\\jacksonbros.com.

We look forward to welcoming you as our customer.(期待對方成為客戶)

Yours sincerely

(Signature)

更多信件書寫範例:
http://www.4hb.com/letters/index.html

網路壓力測試工具Iperf

最近公司代理了Firewall產品，產品有VPN與NAT功能，特別是結合在一起時，效能問題倍受疑慮。

還好我們客戶用了一個工具來檢視之後(雖然是震憾教育)，但學到很多^^

這個工具就是Iperf，可以在這個地方下載:
http://www.noc.ucf.edu/Tools/Iperf/iperf.exe

有Linux版與Windows版，我們以Windows版本為例，簡單說明使用方式與參數。

使用方式:
這於這個工具是Server Client架構，所以需要在兩台電腦上測試，中間經過什麼東西，
就是想測試效能的設備，比如Firewall,VPN,SSL-VPN,Wireless AP...，所以先找兩台電腦，
一台當Server，一台當Client:
Step.1 下載: 到http://www.noc.ucf.edu/Tools/Iperf/iperf.exe 將程式下載，之後將程式copy到想存放的地方，比如說D:/之下。
Step.2 開啟dos視窗: 執行->cmd
Step.3 執行Server: 從comandline輸入 D:/iperf.exe -s (其它參數)
Step.4 執行Client: 從comandline輸入 D:/iperf.exe -c serverip (其它參數)

參數參考:
Client端/Server端 都可用的參數:
-f, --format [kmKM] 以什麼方式顯示: Kbits, Mbits, KBytes, MBytes
-i, --interval # 每隔多少秒顯更新頻寬資訊
-l, --len #[KM] 設定讀寫的緩衝區長度 (預設 8 KB)
-m, --print_mss 顯示TCP/IP標頭的MTU(最大segment)大小
-o, --output 將report或錯誤訊息輸出到這個檔案裡
-p, --port # 設定server與client的溝通port
-u, --udp 使用UDP代替TCP測試
-w, --window #[KM] TCP的window大小(socket buffer size)
-B, --bind bind某,結合某介面或multicast的位址用
-C, --compatibility 與舊版本比較用，不送任何封包
-M, --mss # 設定TCP最大segment大小 (MTU - 40 bytes)
-N, --nodelay 設定無TCP延遲，取消Nagle's演算法
-V, --IPv6Version 設定為IPv6格式

Server端參數:
-s, --server 執行Server模式
-D, --daemon 執行Server背景模式
-R, --remove 移除服務

Client 端參數:
-b, --bandwidth #[KM] UDP參數，以bits/sec傳送(預設 1 Mbit/sec, implies -u)
-c, --client 執行Client模式，並連線到Server的IP:
-d, --dualtest 同時執行雙向的模擬測試
-n, --num #[KM] 傳輸多少bytes封包 (取代-t)
-r, --tradeoff 單獨執行雙向的模擬測試
-t, --time # 每隔幾秒傳輸一次 (預設10 秒)
-F, --fileinput 選取某檔案傳輸測試
-I, --stdin 將鍵盤輸入的資料進行傳輸測試
-L, --listenport # 進行雙測試時，接收回應的port
-P, --parallel # 同時執行多少個Client連線
-T, --ttl # 進行Multicat的time-to-live(預設為 1)

其它參數:
-h, --help 顯示help 資訊
-v, --version 顯示版本

範例:
1. Server端:

iperf -s -u -i 1 -l 1024 -p 5001

設置Server只接收UDP封包，每隔1秒更新顯示一次，進行讀寫的緩衝區大小為1020k，進行監聽的port為5001

2.Client端:

iperf -c 192.168.4.88 -u -i 1 -l 1024 -p 5001 -t 200 -b 1m

設置Client端，連向ServerIP為192.168.4.88，以UDP傳送，每隔1秒更新顯示一次，進行寫的緩衝區大小為1020k，從5001port丟封包出去，每隔200秒丟一次1M的封包

Office 2007重新輸入序號

這陣子不小心去更新Office~使得需要重新驗證licence，
從網路上找到了重新輸入key的方法，就是把regeditkey改刪掉，
刪除路徑如下:

HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\Registration\{91120000-0011-0000-0000-0000000FF1CE}

刪除下面這兩個的值:
DigitalProductID
ProductID

再重新開啟任何一個office應用程式就ok了~
前提是你的key是合法的，不然還是不會過~~

六個步驟讓Web應用程式更安全

資料來源: OWASP

1. 建立溝通管道Build a community: Large enterprises like the Federal government are particularly prone to the silo effect; a simple intranet site that's well managed can work wonders to leverage the expertise throughout an entire Department.

2. 分享專業知識Spread the expertise: Right now the majority of what application security knowledge exists within security groups. This is a good start but ultimately the programs build and fix the applications; staff them with experts, too.

3. 在工具上思考Think beyond tools: While tools can automate certain assessment tasks, realize that they only assist with a portion of your assessments. Even then, assessments are just one portion of an assurance program.

4. 提供指引手冊Provide guidance: Developers want to build secure, compliant software; they just don't always know how. Make standards, requirements and reference models available to your programs.

5. 不斷檢測Don't wait to test: Late-cycle testing under release pressure is stressful on the program and testers alike. Start testing earlier in the cycles and involve your assessment team in the scheduling.

6. 持續觀察審視Zoom-in your continuous monitoring: A "minor" application change can fly through change control but create huge vulnerabilities. Scrutinize changes to applications carefully, particularly Internet-facing or other high-risk systems.

SSL 連線可以被當中間人

這對我們賣資安設備的人來說實在是很大的影響!!

因為我們幾乎所有的設備的管理都是透過遠端連線，如果HTTPS這種看到"金鎖頭"的連線

可以被用來Man-in-the-middle，哇~我很難很想像目前專做SSL-VPN的廠商如何因應這個消息的公佈!!?

下面是Networkword Security的文章:
http://www.networkworld.com/news/2009/110509-ssl-hole-cracks-open-secured.html

大意是說，PhoneFactor(提供手機雙因素認證的公司)的團員發現這個弱點，他們發現任何透過SSL加密的連線都存在這個弱點，目前還在進行Patche的開發中還未更新出來，這個弱點可以在已經加密的連線上輸入指令搶劫這個連線，讓駭客坐在中間，聽、看、編改兩端的通訊。

真的恐佈的漏洞呀~

在CentOS下設chkconfig

只有一沒設就會忘記~~以把apache為例:

設定Apache一開機就執行:
chkconfig --level 35 httpd on

檢示設定狀況:
chkconfig --list httpd