2014年5月29日 星期四

台大醫院遭駭 竟揪出內賊

台大醫院遭駭 竟揪出內賊
竄改程式碼 未損及病患隱私


台大醫院電腦主機伺服器驚傳遭駭客入侵!原被派駐台大醫院擔任電腦系統維修員的工程師陳怡誠,涉嫌於去年底到今年初,兩度更動系統程式碼,雖未涉及病患隱私資料,但院方懷疑遭駭報案,台北地檢署昨指揮刑事局搜索、約談陳男,訊後以妨害電腦使用罪,諭令五萬元交保。

尷尬微笑拒受訪
台大醫院昨發聲明強調,遭異動的程式碼僅與伺服器主機系統有關,可能影響日後醫院資料備援系統啟動,未涉及更動、竄改病患個資、病歷,也未影響醫療與行政運作。而陳男被移送北檢複訊時,僅對記者尷尬地微笑搖搖手,拒絕說明更動程式碼的動機。

陳男原為台大電腦系統包商派駐的維修員,但他在去年底到今年初,兩度在台大醫院主機伺服器的程式碼中加入簡短的程式碼,導致某部分指令無效。因台大醫院於維修合約到期,進行例行性交接盤點時,在主機伺服器中發現不尋常異動資料,台大醫院委請第三方公正單位查驗後,懷疑遭植入為惡意程式,為維護醫院資安,報案尋求司法協助。

堅稱有正當目的
檢警受理後,初步研判陳男可能是檢查維修時不小心輸入程式碼,才被誤認為竄改,但也不排除陳男是因不滿維修合約到期,恐影響工作,因此惡意竄改。據了解,陳男向檢警坦承兩度加入程式碼,但堅稱有正當目的,非惡意程式,且他在合約期限內有權修改程式,否認違法。

轉載自《蘋果日報

Avast遭駭:40萬會員資料可能外洩,緊急關閉技術論壇

Avast遭駭:40萬會員資料可能外洩,緊急關閉技術論壇

駭客如何入侵網站目前尚不得而知,但該公司相信入侵基本上立刻就被發現。不過Avast已將支援論壇網站撤下,並表示將重建網站,且轉移到其他平台。等恢復上線後,所有用戶都必須修改密碼。


資安業者Avast執行長Vince Steckler周一在公司部落格發出公告,表示公司技術支援論壇本周末遭駭,包括使用者名稱、暱稱、email及單向加密密碼皆遭到存取,為此Avast目前已關閉論壇網站。

Avast表示,其總用戶數有2億人,不到0.2%受害。由於網站代管於第三方平台,和用戶的付款、授權,及財務相關資料庫是分開的,因此用戶的機密資料並未外洩。

Steckler指出,駭客如何入侵網站目前尚不得而知,但該公司相信入侵基本上立刻就被發現。不過Avast已將支援論壇網站撤下,並表示將重建網站,且轉移到其他平台。等恢復上線後,所有用戶都必須修改密碼。該公司也呼籲若其他網站採用相同帳密者應儘速修改密碼。

上周, eBay才傳出網站資料庫於2、3月間遭駭,導致1.4億名用戶姓名、加密過的密碼、實體住址、電話和生日等個資外洩,目前美國已有多州政府展開調查。

轉載自《iThome》

2014年5月28日 星期三

Android嚴重漏洞!可以入侵他人手機偷拍!(含影片示範)

Android嚴重漏洞!可以入侵他人手機偷拍!(含影片示範)

Android 裝置中有一個漏洞,駭客可以利用惡意程式在使用者不知道的情況下利用手機控制鏡頭進行偷拍甚至是錄影。得到的相片甚至是影片更可以自動上載到其他伺服器而使用者毫不知情!

原始資料:
Exploring limits of covert data collection on Android: apps can take photos with your phone without you knowing

暫時避免方法:
1. 確保安裝APP時沒有過份的要求。
2. 保護好 Google Account。
3. 刪除不再使用的APP。
4. 在設定中檢查可疑的高電量及高流量使用的App 。
5. 檢查可疑的背景程式。


轉載自《網路攻防戰》

2014年5月25日 星期日

DNS安全驚爆危機



DNS安全驚爆危機

近年來,DNS安全事件頻傳,去年在垃圾郵件黑名單組織Spamhaus面臨史上最大規模的DDoS攻擊,即是利用這個網路服務發動,今年Google公開DNS服務8.8.8.8也發生網路流量遭到綁架的事件,導致許多查詢網址的流量被有心人士操弄,導到委內瑞拉境內網路,時間長達22分鐘之久。經過這幾次事件發生後,連Google都中招,你仍然覺得DNS還安全嗎?

安全性嚴重不足 DNS已然成為網路攻擊鎖定的主要目標
想瀏覽網站、用各種雲端服務,背後需搭配DNS查詢網址,才能讓你順利連至伺服器,若有人癱瘓或劫持了這項服務,後果不堪設想,目前破壞DNS服務的攻擊頻頻發生,情況愈來愈嚴重?

DNS DDoS攻擊的類型
主要根據各種不同協定或手法的攻擊模式而區分,方式五花八門,但現在也有人進一步歸納,提出較精簡的分法。

為達高速查詢犧牲安全性 DNS成為駭客最愛的攻擊標的
若DNS服務被癱瘓,網路服務可能就因而停擺;DNS服務如果被綁架,你就只能到駭客要你去的地方

不要讓你的網路輕易被別人斬首了
DNS伺服器被駭、資料庫外洩,比個別網站停擺還要嚴重,因為有心人士能透過這種方式,不僅收集到所有相關網站的網域名稱,還可能透過一些更精緻的攻擊手法,快速且更大規模地影響所有存取DNS服務的電腦與伺服器

文 /李宗翰
轉載自《iThome》

為達高速查詢犧牲安全性 DNS成為駭客最愛的攻擊標的

為達高速查詢犧牲安全性 DNS成為駭客最愛的攻擊標的

若DNS服務被癱瘓,網路服務可能就因而停擺;DNS服務如果被綁架,你就只能到駭客要你去的地方


在目前的網路基礎設施當中,DNS是最不可或缺的服務之一,少了它,我們就必須設法記住一堆難以記憶的IP位址,才能連到提供各種應用服務的後端伺服器,如果DNS無法正常運作、提供服務,許多IT應用甚至可能會因此停擺,因為,許多原本能連到目的地的連線請求,全部都會迷路。

或者當這樣的網路服務被入侵,相關資源設定也遭到竄改時,甚至使用者有可能會因此誤連到惡意偽造的網站,結果導致帳號、密碼、信用卡號等重要個資被竊取,損失慘重。

DNS的存在這麼重要,那麼,它本身夠安全嗎?事實上,要建立DNS伺服器很容易,幾乎所有的Unix和Linux作業系統,以及Windows Server作業系統都內建這樣的伺服器功能,取得方式幾近於免費。當中發展歷史最悠久,也最為普及的是BIND(Berkeley Internet Name Domain),這些DNS伺服器都是在作業系統上以應用軟體的方式執行,既然如此,所有軟體可能發生的安全性問題,它們都會面臨到,包括錯誤的設定、作業系統與DNS軟體本身的漏洞、伺服器管理者帳號與密碼被破解。

DNS採用的通訊協定有許多可供濫用的地方

除了這些天下所有軟體都會遇到的狀況,DNS自己的安全性問題也很大。

UDP協定與53埠的使用

首先,DNS基本上是透過UDP協定傳輸封包,並且是利用53埠來服務所有的請求。每一次DNS的網址域名查詢會包含來自用戶端的一個UDP請求,然後伺服器端回覆查詢結果時,也是透過UDP來傳輸。

若回覆的資料超過512 bytes時,或者是執行轄區傳送(Zone Transfer)這類任務時,才能會採用TCP協定來傳輸,你也可以強制用TCP來傳輸DNS的查詢請求與回覆。

一般來說,使用UDP的DNS服務,都是透過單向的方式傳輸封包,而且,所有的網路防火牆也都會允許這樣的連線從53埠進出,不會也無法特別採取管制措施。F5 Networks臺灣暨香港區技術總監莊龍源表示,駭客之所以喜歡攻擊DNS,原因即在此。他說,UDP的封包和協定根本沒辦法讓用戶或主機去確認對方發過來的封包身分,所以很容易可以做到DNS洪水攻擊,或是其他類型的攻擊。

由於UDP只是一個單方向的網路協定,只管發出去,可以不管伺服器是否有所回應,在這種情況下,就有機可乘了,他們可以設法用DNS的這項特性做出攻擊。

防火牆、路由器不會去檢測DNS封包裡面的資訊

除了UDP的特性,以及防火牆一定會放行DNS所用的網路埠等因素,莊龍源提到,在DNS的封包裡面動手腳,要「騙過」防火牆和路由器也很容易。

因為DNS封包裡面的格式有很多種,比方一般使用者要上網會查詢A記錄,透過郵件伺服器發電子郵件會查詢MX記錄,去查詢一個IP位址的域名,則會用到Reverse-lookup記錄。但對網路防火牆來說,處理這些封包時,並不會特別檢查裡面包含的訊息,當它看到是從UDP、53埠進來,就把流量放進去了。

而且,任何接受到的查詢網域名稱請求,DNS服務都要照單全收,並且逐一回應,而不是基於一定的條件或政策判斷後,再決定是否答覆。

因此,如果DNS伺服器接到一個正常格式的DNS查詢請求,但裡面需要查詢的資料量非常大時,不論這個提出請求的來源IP位址是否真實存在,或是以亂數方式大量產生,它還是會乖乖回應,換言之,如果有人趁機濫用這樣的服務,將可能會導致DNS伺服器上傳頻寬大塞車,而無法順利地回應正常的DNS查詢請求。

另一種則是表面上就可以看出的異常情況。當有人提出奇怪的查詢請求時,而DNS又沒有妥善設定,結果也就等於照對方的指示辦事了。像是有人在查詢時要求提供「Any」或「.」的記錄、「Chaos」或「Hesiod」的類別,以及根本不存在的域名、以亂數方式查詢轄區內的域名。

這些攻擊方式更加狡猾,因為對方可以透過其他方式來進行正常或異常的域名查詢。例如,有人提供DNS服務給我使用,我可以任意地查詢很多根本不存在的域名,這臺DNS伺服器就會一直忙著執行查詢的程序,這樣一來,DNS伺服器反應速度很快就會下降,但實際上這並不是真正的忙碌,而是一連串無意義的動作,瞎忙一場。

從上面的討論來看,我們可以知道DNS是很容易被攻擊的。因為在網路層並沒有能夠特別針對DNS傳輸特性加以管制的防火牆,並讓它去過濾DNS伺服器所接受到的流量和訊息。

現行防護DNS攻擊方法的局限

對於DNS在網路傳輸時可能引發的安全性問題,過去已經有人提出幾種解法來因應,但仍無法全面而徹底地改善DNS安全性。因為,最主要的問題是,這些方法實作上,對網路傳輸速度與DNS伺服器本身的效能,都有很大的衝擊,就目前而言,有些作法引發的副作用是無法克服的,例如,DNS採用的通訊協定很難由UDP改變為TCP,以及防火牆、路由器無法全面檢測封包來源,有些則已經有進一步的搭配方式,可突破原有的限制,例如DNSSEC。

改用TCP來傳輸

DNS也支援用TCP協定來傳輸,這麼做的好處是可以提升安全性,因為TCP會要求三向交握(three-way handshake),而能夠查詢到來源IP位址、確認對方使用的是真實存在的IP位址,可預防有人利用假冒IP位址發送封包。

但是大多數DNS並不使用TCP,而用UDP的協定來傳輸,為什麼?

這主要是為了傳輸效能上的考量。因為在整個應用系統執行的流程裡面,透過UDP這種方式傳輸查詢網域名稱的請求與回覆,可把DNS查詢的延遲程度減到最低,使網路連線的效果保持流暢,快到幾乎讓你沒感覺到背後正在進行這項工作。

若改用TCP來執行DNS服務,會因為需確認三向交握,導致網路存取的延遲程度增加很多,而且幾乎每個連到一個網站或應用程式時,都要查詢DNS,若此時又堅持用TCP來傳輸,也會耗用許多DNS伺服器本身的執行效能,而且不容易執行DNS Caching的演算。

也因此,DNS不得不用UDP,但這又衍生出資安漏洞──別人可以用偽造的IP位址、假冒其他合法的用戶端電腦去發動很多攻擊。

因為UDP本身就是一個無狀態(Stateless)的協定,當DNS封包廣播進來時,傳輸上可允許不回應給來源IP位址,所以,管理者與網路資安設備自然也沒辦法查詢這個連線階段,造成很多漏洞,為人所濫用的機會非常大。比方說DNS的快取下毒(DNS Cache Poisoning)或DNS綁架(DNS Hijacking)等攻擊,都是利用DNS的特性所做成的。而且,這種攻擊影響的不只是DNS伺服器,也影響用戶端。

運用防火牆和路由器的連線來源管制

若要防堵假冒的DNS封包,透過這些網路設備來進行,可行性有限。理論上,在防火牆和路由器處理進出的網路流量時,是可以設定成只允許來自特定來源的封包才能通過,同時阻擋那些假冒IP位址的封包;但實際上,當所有封包進出時,要一一檢查它們的來源,會增加這些設備的負載,而且不是每一臺防火牆和路由器都會連到網際網路,它們也會經常連到子網路內,所以這樣子的管制不是很有效益,並未普遍採用。

啟用DNSSEC強化安全驗證

如同前面提到的,DNS的網路服務為了達到低延遲的連線需求,而採用UDP協定傳輸,對於偽冒IP位址的傳輸行為無法防範,因此如果有人發動相關的網路攻擊,例如DNS快取下毒、透過偽裝DNS伺服器發動中間人攻擊(Men in the middle attack)都是很有可能的。

為了解決這項嚴重危害網路安全的問題,2001年起,IETF組織開始制定了一套新的標準,稱為DNSSEC(Domain Name System Security Extensions)。

不過DNSSEC只能解決一部分安全問題,例如可透過數位簽章的驗證,確保封包的正確性,是能防範一部分網路攻擊,但無法徹底杜絕。

而且,如果在DNS伺服器導入DNSSEC,這些加密的處理與驗證金鑰的程序,也會大大增加DNS伺服器本身處理的負載。因此要達到這樣的要求,不只是所有網際網路的既有DNS伺服器、用戶端,都要支援DNSSEC,同時,需要架設更多臺DNS伺服器做負載平衡,以免無法承擔龐大運算需求。

針對這樣的高負載處理需求,有些DNS伺服器平臺後續的改版也提出強化自身效能的解法。例如BIND 10裡面,對於轄區資料的存取,開始支援用記憶體內處理(in-memory)或用後端資料庫的方式。

另外,市面上有些專門提供DNS伺服器硬體設備的產品,像是Infoblox的Trinzic DDI和Advanced DNS Protection,也都支援DNSSEC,該廠牌產品的代理商達友科技資深產品經理黃繼民表示,Infoblox在硬體設備的作業系統NIOS中,對於處理器與記憶體的資源運用是有所管制的,採取先進先出的作法,不會出現系統記憶體完全被過多連線佔滿,而導致動彈不得的狀況。

而另一家提供負載平衡設備的廠商F5,在Application Delivery Firewall的解決方案下,當中可透過Big-IP Global Traffic Manager(GTM)來提供DNS加密運作工作的卸載作業(Offload DNS crypto),以及用數位簽章驗證的DNS快速回應(Signed DNS responses)。

面對更精密、複雜的DNS攻擊

這一兩年以來,DNS攻擊事件之所以受到很大的重視,主要拜2013年首度出現300Gbps流量的DDoS攻擊所賜,苦主是反垃圾郵件組織SpamHaus,而當時這個DDoS事件所採用的手法,就是透過折射攻擊(Reflection Attack)、放大攻擊(Amplification Attack),甚至將兩者混合使用,才得以產生這麼巨大的流量,攻向所針對的目標。

折射攻擊

事實上,想要發動DNS的DDoS,方法有很多種,不只是用UDP打掛對方的DNS伺服器,駭客還可以透過其他DNS伺服器來發動折射攻擊,也就是對不同的DNS伺服器發出大量的DNS查詢請求,而且是用合法的IP位址(但並不是真正的來源IP位址,而是受害者的IP位址),然後,再透過這些DNS伺服器所回覆的查詢請求,去攻擊其實根本沒提出任何查詢請求的受害者。同時,在這種手法下,駭客可以透過這種曲折的方式,更徹底地隱藏自己的身分,因此,這是更複雜的DNS攻擊。

放大攻擊

基本上,放大攻擊和折射攻擊經常是焦不離孟,甚至也有人將兩者畫上等號,而對駭客來說,必須先成立了折射攻擊的架構,作為基礎,接下來,才有可能進一步達到將網路流量放大的攻擊效果。

就運作原理而言,每一個DNS封包可容納的資料量,最大可延伸到4096 bytes,因此攻擊者只需送出少量的域名查詢請求,DNS伺服器就可以回覆非常大量的資料,而這就達到了資料量放大的目的;而在折射攻擊的模式下,因為發出查詢域名請求的來源IP位址已經偽造成受害者伺服器所在的IP位址,所以,這麼大量的資料並不會回到攻擊者身上,而是報復到受害者,為了要接收與處理這麼大規模的網路流量,受害者的伺服器資源會全部耗盡而無法提供任何服務。

上述是一般的DNS查詢請求,有些類型的查詢動作會有不同的放大效果。例如,基於DNSSEC的域名查詢,可能引發的是10倍的回應量;若是用Any Record的方式來查詢facebook.com這樣的域名,再加上DNS伺服器本身配置不當,此時,DNS伺服器就會把所有記錄都傳送出來,也可以達到放大的效果。









想要提升DNS防護DDoS攻擊的能力,強化DNS伺服器本身的處理性能是一種方法,因此架設更多臺DNS伺服器或購買一些廠商所開發的DNS硬體設備,都是解法之一,此外,有些負載平衡產品的廠商,也能支援這樣的應用。例如圖中的F5是以Advanced Firewall Manager這套產品來防禦DNS攻擊。

轉載自《iThome》

DNS DDoS攻擊的類型

DNS DDoS攻擊的類型

主要根據各種不同協定或手法的攻擊模式而區分,方式五花八門,但現在也有人進一步歸納,提出較精簡的分法。


一般而言,DDoS攻擊的類型,主要根據各種不同協定或手法的攻擊模式而區分,方式五花八門,但現在也有人進一步歸納,提出較精簡的分法。

例如,Arbor Networks就這些威脅,簡單分成下列三大類:

1. 體積型的攻擊(Volumetric Attacks):對於大量佔用目標物或服務端網路頻寬的DDoS攻擊,他們稱為體積型的攻擊。

2. TCP狀態窮盡攻擊(TCP State-Exhaustion Attacks):針對一些以大量耗用網路基礎設施連線狀態為主要手法的DDoS攻擊,Arbor Networks稱為TCP狀態窮盡攻擊。

3. 應用層的攻擊(Application-Layer Attacks):針對網路第7層的DDoS攻擊,也就是應用層的攻擊,手法較為複雜、精緻,並且行蹤很隱匿,以傳統的流量監控較難以做到主動、即時偵測,更別說遇到這類攻擊,還能做到即時反應。

Radware在DNS攻擊分類歸納上,則是根據濫用DNS的方式區隔,他們提出下列4種:

1. 基本洪水攻擊:這種攻擊會送出許多DNS請求到DNS伺服器上,企圖耗盡這些伺服器的網域名稱解析器,以及快取資料庫資源。

2. 遞迴式洪水攻擊(Reflective DNS Flood):攻擊者會對DNS伺服器,送出並不存在DNS快取資料的網域名稱解析請求,增加DNS伺服器與網路頻寬的負擔。

3. 折射式洪水攻擊(Reflective DNS Flood):許多攻擊者都很喜愛的攻擊方式之一,也是當前最受矚目的攻擊類型。折射式DNS洪水攻擊單靠有限的資源,而且不需自行架設的DNS伺服器,就足以產生巨大的網路流量,同時因為當中運用了偽冒的IP位址,因此受害者難以追蹤那些發動這類攻擊的人。

4. 垃圾洪水攻擊(Garbage Flood):這種攻擊會利用53埠,對DNS伺服器發出大量封包,進而塞暴伺服器對外的網路連線,並且讓DNS名稱解析器疲於奔命,也就無法服務正常查詢請求。

在上述的DNS折射式洪水攻擊當中,還可以同時運用放大攻擊(Amplification Attack)的手法來推波助瀾。

1. 正常型DNS回覆:通常每次域名查詢所回覆的資料量,會是提出請求時資料的3到4倍。

2. 研究型DNS回覆:駭客會研究DNS伺服器,並且找尋哪些合法查詢能夠導致大量回覆。有些時候,資料量放大的效果可達到原始查詢請求的10倍。

3. 精緻型DNS回覆:攻擊者會破壞一臺較不安全的DNS伺服器,並確保他提出的請求所得到的回覆資料量,可達到DNS封包的上限──4096 bytes。在這種方法下,資料量放大的效果可達到100倍。

轉載自《iThome》

安全性嚴重不足 DNS已然成為網路攻擊鎖定的主要目標

安全性嚴重不足 DNS已然成為網路攻擊鎖定的主要目標

想瀏覽網站、用各種雲端服務,背後需搭配DNS查詢網址,才能讓你順利連至伺服器,若有人癱瘓或劫持了這項服務,後果不堪設想,目前破壞DNS服務的攻擊頻頻發生,情況愈來愈嚴重?


資訊安全威脅的面向相當廣泛,受到有心人士侵入、伺服器或員工電腦遭惡意程式感染、機敏資料被竊,只是其中幾種常見的方式,然而,當前企業IT在日常維運的工作上,更恐懼卻也可能經常面臨的威脅是分散式服務阻斷攻擊(DDoS),因為一旦你的對外網路、應用伺服器遭受到這樣的攻擊時,將無法正常運作。

DDoS攻擊並不是這幾年才出現的威脅,但過去鎖定的目標除了是癱瘓目標的網路基礎設施之外,在應用層的攻擊對象大多是網站伺服器,近年來針對網域名稱系統(DNS)的攻擊比例也開始顯著提升,並且躍居第二大攻擊目標。

利用DNS的特性,駭客即能以低成本發動巨大流量癱瘓目標網路

要理解DDoS的攻擊原理其實不難,有人提出相當貼切的比喻:當你想要癱瘓一家公司的客服專線服務時,只需要號召一定規模的人數撥打電話過去搗蛋,就可能有機會徹底占據對方的通訊線路,並使客服專線處於忙碌到無法服務到其他正常使用者來電的狀態。

最近,全臺灣的民眾對這種攻擊也有更深刻的理解。因為現實生活中,3月中由於兩岸服務貿易協議的爭端,許多大學生與社運人士發動攻佔立法院的大規模抗議行動,來自全臺各地的民眾前往立法院附近區域靜坐,包圍立法院要求實質審查協議內容的示威,長達22天之久,而這樣的舉動也癱瘓了國會正常的議事程序,企圖阻撓服貿協議過關。

一般而言,DDoS攻擊所針對的目標,主要是網路基礎架構,最常見的攻擊方式包括:以利用TCP連線三向交握通訊模式的漏洞來發動TCP SYN洪水攻擊,以及利用不需三向交握就能傳送的UDP封包洪水攻擊,還有以偽造來源IP位址發送大量ICMP封包給目的IP位址的ICMP洪水攻擊,這些都是屬於針對網路第三層的攻擊;另外,針對網路第7層的應用服務,駭客也經常針對網站伺服器的存取,來發動大量下載行為的HTTP GET洪水攻擊。透過這些方式,攻擊者可消耗殆盡對方的網路頻寬或處理器資源,癱瘓對方提供的網路服務。

這種情況至今仍然繼續,但值得注意的是,從2012年第三季開始,運用DNS的洪水攻擊開始逐漸增加,根據DDoS防護產品的廠商Prolexic的年度DDoS攻擊報告來看,DNS攻擊的比例在去年第4季達到史上最顛峰,達到9.58%。在另一家DDoS防護產品廠商Arbor Networks的全球2013年度基礎架構安全報告中,也有類似的觀察,他們發現有10%的DDoS大量攻擊是來自UDP 53埠。而且,DNS這項網路服務所運用的通訊埠,僅次於最常被攻擊的HTTP網站服務所採用的80埠(29%)。

在負載平衡與網路設備商Radware提出的全球應用系統與網路安全2013年度報告中,呼應了這樣的趨勢,從2012年開始到2013年,將DNS作為攻擊目標的比例逐漸超越了SMTP,成為應用層DoS/DDoS攻擊的第二大面向(2011年兩者的比例平分秋色,都是9%,SMTP到2013年才略微提升到11%),而且領先幅度越來越大,在2013年升高到21%,與網站受到這類攻擊的比例越來越接近(27%)。

而在Arbor Networks對於應用層DDoS攻擊的統計分析中,也看到DNS以77%的高比例,贏過HTTPS(54%)成為第二大目標,而且僅次於HTTP(82%),至於SMTP只有25%,擠不上前三名。

針對DNS網路服務的DDoS攻擊能在幾年內快速崛起,跟採用特定DNS攻擊手法有很大的關係,其中,最主要的就是利用放大(Amplification)或折射(Reflection)方式所產生的巨量DDoS攻擊,最廣為人知。例如去年3月發生震撼全球的巨量DDoS攻擊事件,產生高達300Gbps的網路攻擊流量,針對的目標是反垃圾郵件組織Spamhaus,當時就是利用這種方式,發動了折射式的分散阻斷服務攻擊(Distributed Reflection Denial of Service,DRDoS)。

值得一提的是,這種放大∕折射攻擊的手法在今年有新的呈現。有人利用NTP網路校時協定發動了DDoS的放大攻擊,所產生的網路流量高達400Gbps,在相隔近一年的短暫時間內,居然又打破了先前攻擊Spamhaus所創下的歷史紀錄。

DNS攻擊綁架大量使用者網路連線,Google也是受害者之一

DNS這個網路服務上,除了以「量」為主體的攻擊模式,還有針對DNS權威伺服器(Authoritative DNS Servers)、DNS伺服器遞迴查詢(Recursive DNS Servers)的攻擊方式,以及設法在DNS快取資料內下毒(DNS Cache-Poisoning Attacks)的手法。以DNS快取下毒這種攻擊模式來說,駭客所攻擊的是負責提供DNS快取服務的中繼伺服器,入侵裡面的系統,並且偽造了特定域名的IP位址記錄,結果讓使用者連到攻擊者所設立的伺服器,以達到竊取機密的目的,這實現了中間人攻擊。而在Arbor Network的報告中,有2到3成比例的使用單位表示在2013年經歷過上述的DNS攻擊。

去年有哪些重大資安事件,跟這些DNS攻擊方式有關?8月底,發生紐約時報和Twitter受到敘利亞電子軍(Syrian Electronic Army,SEA)所發動的DNS攻擊,但對方是先侵入DNS服務供應商Melbourne IT──這樣的公司也就是所謂的域名注册商(registrars),並竄改了DNS伺服器的NS記錄(這是一個將域名解析由特定DNS伺服器執行的設定),將權威DNS伺服器改為敘利亞電子軍的DNS伺服器,隨後,各地存取這兩個網站的流量就被導向到敘利亞電子軍設立的惡意網站。

更早幾年,Twitter在2009年12月也曾遭到伊朗網軍(Iranian Cyber Army)發動的DNS攻擊,對方是透過竄改DNS記錄,以便將使用者存取該網站的網路流量,能重新導向到他們控制的伺服器,也就是攻下DNS權威伺服器(Authoritative DNS takeovers)。

今年1月,中國境內也出現大規模網站無法存取的事件,原因是DNS被劫持。當地用戶連到許多以.com與.net為網域名稱的網站時,會被導引到美國Dynamic Internet Technologies公司的IP位址。

3月初,全球網路巨擘Google也面臨重大的DNS攻擊。他們提供給大眾的公用DNS伺服器8.8.8.8,遭到DNS劫持(DNS Hijacking)的狀況長達22分鐘,當時所有使用該DNS服務的網路流量都被綁架,傳到巴西和委內瑞拉境內。

隔沒多久,3月底、4月初Google DNS服務又發生遭到土耳其網路供應商的攔截事件。對方設立了DNS伺服器假裝是Google DNS,挾持當地人民的網路連線使用假冒的Google DNS。

整體而言,DNS攻擊事件未來仍將不斷發生,而且遭遇的頻率將越來越頻繁,又很難預防與即時反應。因為大部分現行的許多網路存取行為,像是網頁瀏覽、行動裝置的App運作、雲端服務的協同運作,背後都需仰賴DNS來查詢不同網址所代表的IP位址,進而連至後端伺服器執行系統的操作。

Google軟體工程師Steven Carstensen表示,DNS就像是一本電話簿或通訊錄,能夠讓你找到聯絡人的號碼一樣,如果有人用另一本電話簿偷偷取代原有那一本,而且看起來一模一樣,但裡面的內容已經變造,你可能就因此無法跟朋友聯絡。

這顯示了DNS這項網路服務相當脆弱,似乎要操控、挾持的難度並不高,而且,不論你是中國這樣的世界級強國,或是身為Twitter、Google這樣擁有頂尖技術能力和人才的網路公司,都無法在這樣的威脅下倖免於難。

歷年來全球發生重大DNS攻擊事件簿
●2009年   12月,Twitter因為域名注冊商的DNS記錄被駭客竄改,而受到挾持,網站受到影響1小時。
●2010年   中國百度網站出現無法存取的狀況,主要是因為DNS記錄被竄改,該站所用的網域名稱baidu.com在美國域名註冊商處,遭到伊朗網軍非法篡改,癱瘓時間約11個小時。
●2011年   巴西幾個主要的網路服務業者發生大規模DNS快取下毒攻擊,影響高達7300萬臺電腦,以及3、4百萬用戶。
●2012年   Go Daddy遭DDoS攻擊,該業者在美國地區的DNS伺服器受到影響。
●2013年   紐約時報和Twitter因為DNS服務商Melbourne IT遭敘利亞電子軍入侵,所屬域名記錄被竄改,存取該網站的流量重新導引到攻擊者設計的網站。
●2014年   Google DNS遭到DNS綁架攻擊,部分流量被重導至巴西和委內瑞拉。土耳其網路供應商攔截流量,並設立伺服器假冒Google DNS,管制言論自由。





轉載自《iThome》

IE 8 出現 7個月未修補的漏洞!

IE 8 出現 7個月未修補的漏洞!


TippingPoint 旗下的「零時差計畫」公布了一個IE8漏洞,此一允許遠端攻擊的漏洞早在去年10月就提交給微軟,但遲遲未被修補,使得ZDI依據其揭露政策公開了該漏洞。由於IE 8是已經退役的 Windows XP所能安裝的最高IE版本,因此XP使用者受到的可能影響將會最大。

TippingPoint旗下的「零時差計畫」(Zero Day Initiative, ZDI)本周三(5/21)公布了一個IE8漏洞,此一允許遠端攻擊的微軟瀏覽器漏洞早在去年10月就提交給微軟,但遲遲未被修補,使得ZDI依據其揭露政策於本周公開了該漏洞。

ZDI為一鼓勵研究人員提交漏洞的獎勵計畫,當研究人員發現軟體漏洞時,ZDI會給予獎金,然後將漏洞提交給軟體製造商,並會在180天後公布漏洞細節。ZDI表示,他們在去年10月把漏洞資訊提交給微軟,微軟於今年2月證實了此漏洞,在今年4月屆滿180天後,ZDI即通知微軟,並於本周公布漏洞。

根據該漏洞的說明,當使用者以IE8造訪惡意網站或開啟惡意檔案時,駭客便有機會攻擊該漏洞,於遠端執行任意程式。雖然IE版本已進展到IE11,但Net Applications的數據顯示,IE8是目前最受歡迎的IE版本,今年4月的市佔率為20.85%,比IE 11的16.61%與IE9的8.89%還高。

IE8也是已退役的XP作業系統所能使用的最高IE版本。自IE 9之後就不支援XP,換句話說,XP電腦若安裝的是IE 8,並無法再往上升級更新的IE版本。反觀Vista及Windows 7等PC可能也安裝IE 8,但都有更高的IE版本可以升級。

微軟回應了媒體的詢問,表示他們知道ZDI要公布IE8的漏洞,但迄今尚未發現任何客戶受到該漏洞的影響;微軟儘可能全面測試每一個安全修補程式,有些修補程式較為複雜,必須在不同的程式、應用與配置下進行測試,微軟仍在努力解決此一問題,會在適當的時機釋出更新。另一方面,微軟仍然鼓勵使用者升級作業系統與IE版本。

對於外界批評微軟忽視此漏洞,發現該漏洞的安全研究人員Peter Van Eeckhoutte則替微軟緩頰,認為180天雖然是修補大多數漏洞的合理時程,但他不相信微軟沒有修補是因忽視或不在乎安全,只是也只有微軟自己知道原因。

轉載自《iThome》

2014年5月22日 星期四

eBay用戶帳密資料庫遭駭 1億4千萬用戶個資恐外洩

eBay用戶帳密資料庫遭駭 1億4千萬用戶個資恐外洩


eBay遭駭資料庫內儲存了顧客姓名、加密過密碼、實體住址、電話、生日資訊,但不包括金融相關資訊。若影響eBay現有1.48億活躍用戶,災情將超越Target事件,恐成美國史上最大資料外洩案

eBay於5月21日在官方部落格緊急發布公告坦言,今年2月底到3月初時,用戶資料庫遭駭,這個資料庫內有eBay顧客姓名、加密過的密碼、實體住址、電話和生日等個資,以及其他非金融相關的資訊(不含信用卡等金融資訊),也沒有機密性個資。

根據eBay今年3月發布的資料,目前活躍的註冊用戶高達1億4千8百萬個。換句話說,這些用戶資料都有可能外洩。依此規模估算,eBay遭駭事件的影響人數,恐超過了去年12月美國第二大連鎖商店Target遭駭所影響的1.1億客戶,eBay遭駭事件將成為美國史上最大宗資料外洩事件。

eBay在公告上表示,已緊急大規模清查內部網路,並表示,目前還未發現對用戶造成任何非法活動,或是非法存取信用卡資訊,但eBay也要求用戶更換密碼。

eBay並未揭露駭客入侵細節,僅在公告中表示,駭客先竊取了少數內部員工登入憑證,並藉此入侵eBay企業內部網路。eBay表示,2周前發現這些遭駭的問題憑證,為了徹底清查問題,直到今天才公布。但距離3月初遭駭的時間,已經過了2個月。

因為PayPal用戶資料儲存於另一個不同的資料庫中,而沒有儲存於這次遭駭資料庫中,eBay表示,目前也沒有發現任何未授權存取PayPal用戶資料的記錄。

當天稍早,eBay已透過電子郵件、內部通訊機制或行銷通路要求用戶換密碼,甚至提醒用戶更換使用同樣密碼的其他網站。

eBay也在官方部落格緊急發布遭駭公告,要求用戶更換密碼。


延伸報導:傳說中1.45億的帳號密碼
full ebay user database dump with 145 312 663 unique records

轉載自《iThome》

2014年5月20日 星期二

做好PUE量測 方知機房能效優化之道

做好PUE量測 方知機房能效優化之道

有鑑於公務機關與學校機房能耗嚴重,政府已積極研礙相關創建規範,並藉由實際訪查,完成台灣首次具系統性、規模性的PUE量測。經濟部能源局在2013年曾發布一份資料,指台灣服務業資料中心年耗電量約4.1億度,約佔商業部門總用電1.4%比重,至於政府或學校的資料中心耗電量則更高,達到3億度之譜,佔相關領域總用電的6.8%。可以預見,未來隨著企業或機構對網路及通信應用需求高漲,若不及早因應控制,機房能源消耗情況恐將日益嚴重。

其實早在2012年,時任行政院政務委員的張善政,即已意識到此問題的迫切性,遂於行政院節能減碳推動會議101年度第一次委員會議中提出建議,研擬推動台灣資料中心節能之可行做法,視市場技術狀況,責成政府機關資料中心能源使用效率達於一定水準,至於具體實踐手段,一來可投入資本以改善機房設施,二來可逕行委外遷移至能效達一定水平之商用資料中心。


此言一出,後續多項措施隨之啟動。除了展開資料中心耗能量測技術建立、能源效率管理研析之先期研究,並由教育部電算中心、內政部建研所、研考會資管處等多個單位協助調查量測相關事宜,以期根據量測結果,作為今後研擬資料中心節能推動措施、訂定新建資料中心能源使用效率基準、及研擬政府機房委外招標規範等業務之參照規範。

而參與執行「資料中心耗能量測技術建立與能源效率管理研析」計畫的工研院綠能與環境研究所,亦於2012年8月至2013年10月期間,實際訪查政府機關、學校單位甚至若干民營企業的機房,以執行PUE量測工作。

而在不久前,執行單位也利用公開研討會場合,向大眾分享了此一量測計畫的施行成果,連帶點出多項值得企業機構留意的關鍵要素。

權衡量測成本與精準度  求取適當PUE計算方式

首先,由於量測方式及量測位置,以往業界尚無統一規範,導致業者或研究單位所端出的PUE量測數值,比較基準不甚一致,倘若只看數字而不明就理,恐對於受測單位的能源使用效率多所誤解,顯然有導正必要。因此透過此次計畫執行,工研院與幾家協力廠商花了頗多時間與心力,研擬討論最適用於台灣現況的量測方法。

按國際通用的PUE計算方式,通常可分為Category 0、Category 1、Category 2與Category 3四種型態,各類型對應的量測點有所不同。其中Category 0計算分母為「週期時間內UPS輸出位置之最大尖峰用電」、分子為「週期時間內資料中心總用電之最大尖峰用電」,是唯一分子分母皆取kW為單位的算法,計算基礎相對粗略,故而率先遭捨棄。

而在Category 1、Category 2及Category 3部分,量測基準各為UPS Output、PDU Output與IT Input,計算公式的分子與分母皆以kWh為單位,其中Category 3量測點數最為龐大,看似最貼近機房實際用電情況,但由於工程浩大而致量測成本負擔吃重,執行難度偏高。

至於Category 2,則考量部分機房並未採用PDU設備,就算有,亦頗多採用排插式裝置,無法作為量測點執行計算;權衡之下,工研院決定採用Category 1量測模式

然不可否認,縱使Category 1被運用的頻度最高,但結算結果的精準度,仍未必到達爐火純青,只不過機房管理人員並非數學家,僅須儘可能還原事實真相、求取相對精準數值即可,絕無必要在數字運算上斤斤計較;在此前提下,工研院即使採納Category 1,亦須顧及多數機房並非處於獨棟建築物的現實(所以機房將與整棟建物共用變壓器),若將量測點置於市電供應與變壓器之間,恐難分辨何者為機房所用、何者為其他空間所用,因此將Category 1計算方式略做修正,把原本變壓器前量測位置,改置於變壓器、UPS之間。

值得一提的,Category 1另一量測點、也就是計算式的分母部分,係設置於UPS到PDU之間,然而這段仍可能有變數產生,例如某些中小企業,當市電從變壓器進入UPS後,或從UPS到PDU之前,或許會出現分流,其中一路串接機房的機櫃與資訊設備,另一路則串聯至辦公室,支應該區域中個人電腦、印表機、投影機甚或其他設備的用電,工研院便為此詳加釐清,在公式上予以扣除,以避免辦公室耗電誤遭納入機房PUE計算,影響數值的合理性。

工研院建議,爾後用戶若欲自行量測,亦不妨採用Category 1計算方式,即是在週期時間內以總耗電量kWh作為計算,避免墊高量測成本,亦可獲取具有可信度的PUE數據;此外,用戶必須留意,電力變壓器供應範圍含括整棟建築物,而非僅止於機房本身,所以在變壓器前掛表可行性不高,必須調整到變壓器後(UPS前)的位置。

獨立空調加冷熱通道  為降低PUE必備要件

除了量測方式外,最令人關注的,無疑還是訪查41座機房後的實際結果,幾經歸納,發現政府機關與學校單位機房,具備幾項共同特徵:第一,機房皆位在建築物中的某一空間,故機房設置會受限於建築空間與結構,逾五成機房雖為獨立空間,卻出現了對外開窗的怪異場景;第二,逾七成五機房擁有獨立空調系統,雖為可喜現象,但僅不到3分之1已規劃冷熱通道,亟待改善的空間著實不小;第三,超過3分之2機房的電力系統,堪稱清楚、明確且乾淨,並未同時供應予非機房設備,有助於提高整體能源使用效率,理應繼續維持。

此次訪查的41座機房,PUE表現落差可謂不小,表現好的僅在1.6上下,表現差的甚至高於2.6,顯見不同政府機關與學校的資料中心能源使用效率,優劣差異實為可觀;剖析PUE表現較佳的機房,大致具備幾項值得其餘用戶參酌的共同特色。

針對建築空間部分,多為獨立空間、並未混雜其他用途,絕不對外開窗且有遮蔽隔絕,空間規劃適當並無過大或過小之虞,設備與佈線的空間佈局皆屬理想。

在電力系統方面,PUE表現優異的機房,電力線路至為明確,反觀PUE較差者,甚至有從地下室UPS拉線至十幾層樓的不當案例,後者光是電力線路不明所導致的耗損,就足以形成PUE下降的絆腳石,其他較佳特徵還包括擁有獨立的機房電力迴路,且多採用高效率UPS、避免過度低載。

有關資訊機房的耗電大戶、也就是空調系統部分,PUE表現優異的機房,均十分關注空調操作溫度的調整事宜,也多具備獨立空調系統,冷熱通道明確分離,並針對空機櫃加裝隔板、嚴防混風效應,也多已更換採用高效率空調設備。

據悉,參與此次計畫的單位,包括工研院、協力廠商,甚至納入專業技師、建築師,已共同組成一專案小組,刻正研擬有關資料中心耗能量測技術建立與能源效率管理的規範,預計2014年底出爐;與此同時,上述成員也共同組成台灣資料中心基礎建設技術委員會,未來除將負責持續維護上述資訊機房創建基礎設施規範外,並將討論制定相關認證機制。

另一方面,伴隨台灣大哥大綠能機房案例,已使Uptime Institute的Tier III認證,成為業界起而效尤的標竿,工研院除負責維護Uptime Institute白皮書的中文版本外,也促使Uptime機房設計師專業認證(Accredited Tier Designer;ATD)在台灣的首次教育訓練課程,將在2014年第三季起正式開辦,期盼致使台灣資料中心設計水平,與國際標準鏈結得更為扎實緊密。

轉載自《DIGITIMES中文網

2014年5月18日 星期日

使用 Kali Linux 內的 SET 來進行簡訊詐騙(含影片示範)

使用 Kali Linux 內的 SET 來進行簡訊詐騙(含影片示範)

Kali Linux 內建的工具中,社交工程工具組 Social-Engineer Toolkit (簡稱:SET)算是一個比較少被提及的工具。SET 是一個以 Python 為主的開放式原始碼工具組,主要是用來在滲透測試過程中進行社交工程(網路釣魚)的手段,提供了非常豐富的攻擊模組。

主要功能:
1.Spear-Phishing Attack Vector
2.Java Applet Attack Vector
3.Metasploit Browser Exploit Method
4.Credential Harvester Attack Method
5.Tabnabbing Attack Method
6.Man Left in the Middle Attack Method
7.Web Jacking Attack Method
8.Multi-Attack Web Vector
9.Infectious Media Generator
10.Teensy USB HID Attack Vector


轉載自《網路攻防戰》

思科年度安全報告:100%的企業都有惡意程式流量

思科年度安全報告:100%的企業都有惡意程式流量


Cisco 2014年度安全報告指出,不論規模大小的絕大多數企業網站都已被危害而不自覺。思科所分析的所有企業網路(100%)都有連至惡意程式代管網站的流量,而這種流量往往是被攻擊鎖定的前兆。報告中也強調Java所帶來的安全威脅,網路攻擊中有91%是Java感染。

思科(Cisco)於本周發表的年度安全報告(Cisco 2014 Annual Security Report)中指出,不論規模大小的絕大多數企業網站都已被危害而不自覺。思科所分析的所有企業網路(100%)都有連至惡意程式代管網站的流量,而這種流量往往是被攻擊鎖定的前兆。

思科主要是分析了從企業內部網路連出的流量,發現所有被分析的企業都有連至含有惡意程式網站的流量。思科還偵測到100%的企業都有可疑流量,有些企業是連至沒有生意往來的軍方或政府網站,或是那些美國禁止貿易往來的國家,這些可疑流量都是代表企業網路可能已遭攻擊鎖定。

另有96%的企業是連至被駭伺服器,有92%的企業連至沒有內容的網頁,這些空白網頁通常含有惡意活動。有88%的企業連至可疑的FTP網站,79%的企業連至可疑的VPN,以及有50%的企業有連至色情網站的大量流量。

思科表示,這些惡意流量被視為是已成為被駭目標的徵兆,所有的組織都應假設自己已經被駭,或至少得認知到有否成為攻擊目標已不是重點,重點是什麼時候成為攻擊目標,以及已為時多久。



報告中也強調Java所帶來的安全威脅,網路攻擊中有91%是Java感染,思科網路安全服務的客戶裡就有76%的公司還在執行已經退役不再有技術支援的Java 6版本。Java仍是網路罪犯的最愛的程式語言。在被鎖定的攻擊目標中,Java遠遠勝過Flash或是Adobe PDF



轉載自《iThome

Skype 聊天紀錄沒加密,通通在 main.db 看光光

Skype 聊天紀錄沒加密,通通在 main.db 看光光


一般使用者可能會認為刪掉資料夾內的"對話紀錄"檔,應該就不會被看見。殊不知所謂的存在資料夾內的"對話紀錄"是由 Skype 程式儲存在資料庫內的資料表中所輸出的文字檔。理論上:對話紀錄檔可以是明碼,但輸出產生對話紀錄的資料庫原始資料是應該要"加密"的。

資安研究團隊 Hackyard 在偶然情況下,發現 Skype 的目錄中的 main.db 除了儲存 Skype 使用者一些基本資料外,也可發現到下列隱私資料均是明碼儲存。

CallMembers 資料表:可發現通聯記錄。
Contacts 資料表:可發現好友列表。
Messages 資料表:可發現每個使用者傳出和接收的訊息資料。
當然還有一些"雙方視訊"的資料,就請愛好者自行搜尋!

因此可以使用 Skype 歷史記錄檢視器 (例如:SkypeHistoryViewer、 SkypeLogView) 就可達到異曲同工之妙!<--網路上有植入惡意程式的版本,請下載驗證的人謹慎!

因此,只要能都從別人的電腦、手機內"竊取"到這個檔案,極可能隱私外洩!

在官方未修正之前的解決方案:
1. 結束 Skype 後請自行刪除資料夾內的 main.db 檔案。
2. 複製一份空白的覆蓋掉。
3. 不要使用 Skype 聊天。

注意:雖然 skype server 端有備份聯絡人清單,但仍有可能意外產生資料遺失,執行前請記得備份!

原文出處:Hackyard Security Group
轉載自《網路攻防戰》

dSploit 在 Android 的滲透測試

dSploit 在 Android 的滲透測試

什麼是 dSploit ?
其實簡單講就是一個裝在 Android 雷同 Metasploit 的精簡版,經常會被拿來當作手機上進行滲透測試的工具。

主要功能:
WiFi Scanning & Common Router Key Cracking
Deep Inspection
Vulnerability Search
Multi Protocol Login Cracker
Packet Forging with Wake On Lan Support
HTTPS/SSL Support ( SSL Stripping + HTTPS -> Redirection )
MITM Realtime Network Stats
MITM Multi Protocol Password Sniffing
MITM HTTP/HTTPS Session Hijacking HTTP /HTTPS
MITM HTTP/HTTPS Hijacked Session File Persistance HTTP/HTTPS
MITM HTTP/HTTPS Realtime Manipulation HTTP / HTTPS

限制:Android 手機必須符合以下系統要求:
1.僅支援 ARM cpu
2.Android 2.3 以上的OS
3.已經 root
4.安裝 BusyBox


註:不當的操作及使用可能會損害 Android 系統與裝置。

轉載自《網路攻防戰》

Windows Server 2012 R2 架設iSCSI Target

Windows Server 2012 R2 架設iSCSI Target

在windows Server 2012 已經內建iSCSI目標伺服器,當然Windows Server 2012 R2 也是內建的本次介紹如何利用Windows Server 2012 R2 來架設iSCSI Target 伺服器。

啟用iscsi 方式很簡單

1.點選「伺服器管理員 > 管理 > [新增角色及功能]。

2.iSCSI 目標伺服器是屬於伺服器角色(Server Role),所以請選擇「角色型或功能型安裝」項目後按[下一步]。

3.在選取目的地伺服器頁面中,點選[從伺服器集區選取伺服器項目],再來點選要安裝 iSCSI 目標伺服器角色的主機。

4.伺服器角色頁面,勾選[檔案和存放服務]  > [檔案和 iSCSI服務]>[iSCSI 目標伺服器]

5.選取功能頁面中直接點選[下一步]。

6.在確認安裝選項頁面中,[必要時自動重新啟動目的地伺服器]選項可依需求勾選因為安裝iSCSI角色並不需要重新啟動伺服器,所以要不要勾選此選項並不會有任何影響。

7.最後確認要進行 iSCSI 目標伺服器安裝程序就可以完成安裝。



安裝完畢



設定iscsi 伺服器

在iscsi target 主機中 > 伺服器管理員 > 點選 [檔案和存放服務]



點選 [iSCSI]



點選右上方 > 工作 > [新增iSCSI虛擬磁碟]



設定iSCSI虛擬硬碟位置

可以依照需求設定,此示範將虛擬硬碟存放至D磁碟



設定虛擬硬碟名稱



設定虛擬硬碟大小及類型

建議正式環境使用固定大小類型效能較好



指定iSCSI目標

設定允許連接此iSCSI target的主機 > 點選新增[iSCSI目標]

PS:
IQN是iSCSI特有的裝置識別,命名規則為[iqn]+[日期]+[反向Domain名稱或命名授權]+[主機名稱],主機名稱必須是唯一的



自訂目標名稱



指定存取是服器 > 點選 [新增]

類型可以指定ip、IQN、DNS、MAC

此示範設定IP位址



啟用驗證部份直接點選[下一步]



確認沒有問題點選建立即可



測試iscsi 用戶端連接

預設Windows Vista 之後的作業系統已經內建 iSCSI Client (iSCSI Initiatior)

使用WS2012R2 點選 [iSCSI啟動器]



因為是第一次使用所以會提示啟動該服務,並詢問是否需要日後重新啟動電腦時,將此服務啟動 > 點選 [是]



輸入目標伺服器ip > 點選 [快速連線]



隨即出現連線成功訊息 > 點選 [完成]



最後步驟,點選[磁碟區和裝置] > 點[自動設定] 就完成連線



此時開啟磁碟管理工具,就會看到多了一個磁碟可以使用



原文出處:MIS的背影
轉載自《iThome Download

Hyper-v 3.0 (R2) VM For SMB 3.0

Hyper-v 3.0 (R2) VM For SMB 3.0

在Hyper-v 2.0之前的版本建立起來的虛擬機器一定要放在Server中的實體硬碟或是該台Server有連接ISCSI硬碟也是可以存放虛擬機器的檔案。在新版Hyper-v 3.0 (R2)中提供了一個便利的方式就是可以將虛擬機器放在檔案伺服器當中也就是UNC路徑,不過有個前提這個檔案伺服器必須是SMB3.0才可以擔任,在微軟中Windows Server 2012 & Windows Server 2012 R2 都是SMB 3.0以上的版本協定

實作環境:

DC主機一台
Hyper-v Server 2012 R2
Windows Server 2012檔案伺服器

建立Hyper-v管理群組

建立Hyper-v admins 群組=>將需要管理Hyper-v人員加入此群組
建立Hyper-v Hosts 群組 =>將網域內的Hyper-v 主機電腦帳戶加入此群組





檔案伺服器設定:

首先需要確認是否有安裝檔案伺服器角色,若沒有請先新增該角色



安裝檔案伺服器角色完畢後,接下來就是設定共享資料夾及權限

在SMB主機 >伺服器管理員,點選 [檔案和存放服務] >共用



右上方 > 工作 > 點選 [新增共用]



點選 [SMB公用-應用程式]



選取共用位置路徑,此示範設定E磁碟



設定共用名稱,示範名稱設定為VM



共用設定部分若有需求可以個別設定



點選自訂權限,這裡設定主要是讓管理者及Hyper-v主機可以存取該共享資料夾



點選 [停用繼承]  > 會跳出視窗 > 點選 [將繼承的權限轉換成此物件中的明確權限]



先在[權限]頁籤移除權限,只保留 SYSTEM 及CREATOR OWNER 權限



點選 > 新增 > 點 [選取一個主體]



此時將Hyper-v-admins 群組及Hyper-v-Hosts 群組加入並給予完全控制的權限





共享權限部分,將everyone權限移除,將Hyper-v-admins 群組及Hyper-v-Hosts 群組加入並給予完全控制的權限。



確認沒有問題後點選[建立]



建立完畢



建立VM至SMB :

因為此環境中是一台hyepr-V Server 2012 R2 主機是屬於Server Core所以在DC上安裝hyper-v 管理工具來遠端管理。

測試建立win7-vm並且將相關虛擬機器檔案放在分享路徑中\\smb\vm



在建立過程中會出現[存取被拒]的訊息



此時需要設定委派管理的動作

在AD管理工具中,開啟Hyper-v 主機電腦物件 > 委派 smb 主機 cifs 服務



委派管理設定完畢後就可以順利建立虛擬機器到SMB



原文出處:MIS的背影
轉載自《iThome Download