2009-01-21

HeartBeat+DRBD+MySQL on Debian Etch 建置/測試筆記

HeartBeat(2.1.3-6)+DRBD(2:8.3.0-1)+MySQL on Debian Etch 建置/測試筆記


一般在處裡網路服務的系統架構時,如何做到高可用性及即時備援機制一直都是一個重要課題,一般常見的架構是USER-WEB-DB,目前面向USER的WEB SERVER要做到LoadBalance/Failover已經有很多可運用且方便的手段,但後端的資料庫如果要做到Failover就稍微麻煩了些,以下就對MySQL資料庫搭配HeartBeat/DRBD的即時備援機制來作一個簡單的建置/測試紀錄.
其中相關設定是經過實測所得,若有不夠完備須修正調整之處還請各位不吝提供意見.

DRBD (Distributed Replicated Block Device) http://www.drbd.org/
是透過網路即時同步的Block Device,可視同為透過網路進行即時同步的Raid-1,架構示意圖如下(來源為DRBD網站)


DRBD搭配HeartBeat可建構高可用性(HA-high availability)的服務
如將MySQL的DATA FILE放到DRBD上,配合HeartBeat控管可作到MySQL高可用性的即時同步與Failover備援切換.
(其實還是會有down time,不過如果跟MySQL replication的Master/Slave模式在一般情況下需人工介入切換相比,可算是方便省事多了)

架構設定說明:



建置/測試環境:
OS: Debian Etch 4.0
/dev/sdb1 4GB for drbd use

NODE-A (Primary)
eth0 192.168.1.11 Real_IP(R_IP)
eth0:0 192.168.1.10 Service_IP(S_IP) 由HeartBeat控管作為主要提供服務的IP
eth1 192.168.100.11 Private_IP (P_IP) 對接供DRBD傳輸用

NODE-B (Secondary)
eth0 192.168.1.12 Real_IP(R_IP)
eth0:0 192.168.1.10 Service_IP(S_IP) 由HeartBeat控管作為主要提供服務的IP
eth1 192.168.100.12 Private_IP (P_IP) 對接供DRBD傳輸用

DRBD編譯/安裝

因為Debian etch內的drbd7太舊了(0.7.21-4), etch-backports上的是drbd8_8.0.14-2,乾脆直接從sid那抓最新(drbd8_8.3.0-1)的source package http://packages.debian.org/source/sid/drbd8回來重編kernel-module.
(懶得自己重編也可以直接到http://www.linbit.com/support/drbd-8.3.0/debian-etch/ 去找出搭配當前kernel版本的deb檔回來直接裝)

建立drbd8 source package重包的工作目錄.
mkdir /usr/src/drbd8_8.3.0-1
cd /usr/src/drbd8_8.3.0-1

把drbd8_8.3.0-1 的source package抓回來
wget http://ftp.de.debian.org/debian/pool/main/d/drbd8/drbd8_8.3.0-1.dsc
wget http://ftp.de.debian.org/debian/pool/main/d/drbd8/drbd8_8.3.0.orig.tar.gz
wget http://ftp.de.debian.org/debian/pool/main/d/drbd8/drbd8_8.3.0-1.diff.gz
安裝重包drbd8所需必要套件
apt-get install debhelper dh-make dpkg-dev debconf-utils gcc sp bison flex dpatch bzip2 libc6-dev docbook-utils module-assistant linux-headers-2.6-686
解開 source package
dpkg-source -x drbd8_8.3.0-1.dsc
進入解開目錄
cd /usr/src/drbd8_8.3.0-1/drbd8-8.3.0/
重新編譯包
dpkg-buildpackage
包完會產生 drbd8-source_8.3.0-1_all.deb & drbd8-utils_8.3.0-1_i386.deb
把這兩個deb裝起來
dpkg -i /usr/src/drbd8_8.3.0-1/drbd8-utils_8.3.0-1_i386.deb /usr/src/drbd8_8.3.0-1/drbd8-source_8.3.0-1_all.deb
產生drbd8 kernel module
module-assistant auto-build drbd8
可以簡化為
m-a a-b drbd8

依照目前kernel版本重編好的drbd8 kernel module 位置 /usr/src/drbd8-2.6.18-6-686_8.3.0-1+2.6.18.dfsg.1-23etch1_i386.deb
把剛編好的drbd8 module裝上
dpkg -i /usr/src/drbd8-2.6.18-6-686_8.3.0-1+2.6.18.dfsg.1-23etch1_i386.deb
(可以在其中一台作重包的動作,做完後再把 drbd8-utils_8.3.0-1_i386.deb & drbd8-2.6.18-6-686_8.3.0-1+2.6.18.dfsg.1-23etch1_i386.deb 丟到另一台安裝即可)

HeartBeat 編譯/安裝

Debian etch內的heartbeat-2 (2.0.7-2) 沒有支援dopd (DRBD outdate-peer daemon),所以也去http://packages.debian.org/source/sid/heartbeat 抓新版的2.1.4-3source package回來重包

建立heartbeat-2 source package重包的工作目錄.
mkdir /usr/src/heartbeat-2.1.3-6
cd /usr/src/heartbeat-2.1.3-6

把heartbeat_2.1.3-6 的source package抓回來
wget http://ftp.de.debian.org/debian/pool/main/h/heartbeat/heartbeat_2.1.3-6.dsc
wget http://ftp.de.debian.org/debian/pool/main/h/heartbeat/heartbeat_2.1.3.orig.tar.gz
wget http://ftp.de.debian.org/debian/pool/main/h/heartbeat/heartbeat_2.1.3-6.diff.gz

安裝重包heartbeat_2所需必要套件
apt-get install libsnmp-dev libglib2.0-dev psmisc libnet1-dev iproute libtool libcurl3-openssl-dev libxml2-dev uuid-dev lynx libbz2-dev zlib1g-dev uuid-dev libsensors-dev libltdl3-dev swig libgnutls-dev python-dev libpam0g-dev libncurses5-dev psmisc libopenhpi-dev python-central gawk libxml2-utils
解開 source package
dpkg-source -x heartbeat_2.1.3-6.dsc
進入解開目錄
cd /usr/src/heartbeat-2.1.3-6/heartbeat-2.1.3
重新編譯打包
dpkg-buildpackage
(視需求可以去改 heartbeat-2.1.3/debian/control ,像我只需要 heartbeat就只留下Package: heartbeat那段,可以省點時間)
包完後只要裝heartbeat_2.1.3-6_i386.deb即可
dpkg -i /usr/src/heartbeat-2.1.3-6/heartbeat_2.1.3-6_i386.deb
(可以在其中一台作重包的動作,做完後再把 heartbeat_2.1.3-6_i386.deb 丟到另一台安裝即可)

MySQL Server安裝

如果沒有特殊需求就直接用 apt-get install mysql-server 安裝
裝完後把開機啟動的MySQL 相關服務取消,以便之後交由HeartBeat控管 (可以裝sysv-rc-conf來處裡比較省事)
mv /etc/rc2.d/S17mysql-ndb-mgm /etc/rc2.d/K23mysql-ndb-mgm
mv /etc/rc2.d/S18mysql-ndb /etc/rc2.d/K22mysql-ndb
mv /etc/rc2.d/S19mysql /etc/rc2.d/K21mysql

DRBD設定

編輯NODE-A & NODE-B上的
/etc/drbd.conf

common {
syncer {
rate 100M;
}
}
resource r0 {
protocol C;
handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
local-io-error "echo o > /proc/sysrq-trigger ; halt -f";
outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 6";
pri-lost "echo pri-lost. Have a look at the log files. | mail -s 'DRBD Alert' root";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
}
syncer {
verify-alg md5;
}
disk {
on-io-error detach;
fencing resource-only;
}
startup {
wfc-timeout 120;
degr-wfc-timeout 120;
}
on NODE-A {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.100.11:7788;
meta-disk internal;
}
on NODE-B {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.100.12:7788;
meta-disk internal;
}
}
因為裡面用到了heartbeat的dopd(DRBD outdate-peer daemon),
所以需要針對幾個drbd管理程式作權限調整
chgrp haclient /sbin/drbdsetup
chmod o-x /sbin/drbdsetup
chmod u+s /sbin/drbdsetup
chgrp haclient /sbin/drbdmeta
chmod o-x /sbin/drbdmeta
chmod u+s /sbin/drbdmeta

初始化 resource r0
分別在NODE-A & NODE-B執行
drbdadm create-md r0


啟動DRBD service
分別在NODE-A & NODE-B執行
/etc/init.d/drbd start


檢視DRBD 狀態



=====由/proc/drbd 看到的狀態,因為尚未初始同步所以是Inconsistent/Inconsistent=====

初始化同步r0,將NODE-A設為primary
NODE-A上以它的資料為基準開始同步
drbdadm -- --overwrite-data-of-peer primary r0
初始同步進行時 NODE-A的狀態


初始同步過程中 NODE-B的 /proc/drbd 資訊


初始同步過程中 NODE-B的eth1資料傳輸統計


NODE-A的syslog中可以看到初始同步完之後的資訊

可以看到4G的資料初始化同步花了97秒,平均同步速率為 43056 K/sec

MySQL設定

分別在NODE-A & NODE-B執行 mkdir /DB 建立 /DB 作為/dev/drbd0的掛載點
此時在Primary NODE-A 上先對 /dev/drbd0 建立filesystem(XFS),並掛載於/DB
NODE-A:
mkfs.xfs /dev/drbd0

mount /dev/drbd0 /DB



NODE-A:
先將MySQL停掉(如果有在執行的話),再把MySQL的資料由 /var/lib/mysql 搬移到 /DB/mysql 上
/etc/init.d/mysql stop
mv /var/lib/mysql /DB
修改 /etc/mysql/my.cnf 中的 datadir= /DB/mysql


Debian 的MySQL-Server 有個比較特別的地方是安裝時會建立一個debian-sys-maint的DB Account並產生隨機密碼以供MySQL啟動檢查/維護用.相關資訊及密碼會記錄於 /etc/mysql/debian.cnf 內,因為配合DRBD有更改預設的datadir,
所以在 /etc/mysql/debian.cnf 內的[mysql_upgrade]設定區段中也必須加上 datadir= /DB/mysql ,

否則在啟動MySQL時在syslog中會出現下面的錯誤
/etc/mysql/debian-start[_PID_]: Can't find data directory. Please restart with --datadir=path-to-writable-data-dir

因為NODE-A & NODE-B的MySQL資料檔案是放在DRBD上面,也就是兩個NODE使用的是同一組資料,包含啟動檢查所需的debian-sys-maint帳號/密碼,
所以必須將NODE-A上面的 /etc/mysql/my.cnf & /etc/mysql/debian.cnf 複製到NODE-B上,
這樣當發生failover切換時NODE-B才能正常啟動MySQL.

HeartBeat設定

這邊使用設定上比較單純的Heartbeat R1 compatible clusters

NODE-A 上產生/etc/ha.d/authkeys
( echo -ne "auth 1\n1 sha1 "; dd if=/dev/urandom bs=512 count=1 | openssl md5 ) > /etc/ha.d/authkeys
chmod 0600 /etc/ha.d/authkeys


NODE-A 剛產出的 /etc/ha.d/authkeys 複製到HOST-B

HOST-A heartbeat主設定檔
/etc/ha.d/ha.cf
autojoin none
ucast eth0 192.168.1.12 #點對點偵測 HOST-B 的IP
ucast eth1 192.168.100.12 #點對點偵測 HOST-B 的IP
ping 192.168.1.254 #其他IP連線偵測,給個夠穩定的IP供偵測網路狀態用
respawn hacluster /usr/lib/heartbeat/ipfail
respawn hacluster /usr/lib/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster
udpport 694
warntime 5 #偵測到節點異常後的等待警告時間
deadtime 15 #偵測到節點異常後的等待切換時間
initdead 60 #初始啟動等待60秒
keepalive 2 #每兩秒偵測一次
node NODE-A
node NODE-B
auto_failback off #當Default Primary(NODE-A)掛掉再恢復之後不自動取回Primary的身分,以避免頻繁切換影響服務

HOST-B
heartbeat主設定檔
/etc/ha.d/ha.cf
autojoin none
ucast eth0 192.168.1.11 #點對點偵測 HOST-A 的IP
ucast eth1 192.168.100.11 #點對點偵測 HOST-A 的IP
ping 192.168.1.254 #其他IP連線偵測,給個夠穩定的IP供偵測網路狀態用
respawn hacluster /usr/lib/heartbeat/ipfail
respawn hacluster /usr/lib/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster
udpport 694
warntime 5
deadtime 15
initdead 60
keepalive 2
node NODE-A
node NODE-B
auto_failback off

NODE-A
& NODE-B heartbeat資源設定檔
/etc/ha.d/haresources

NODE-A  \
192.168.1.10/24 \
drbddisk::r0 \
Filesystem::/dev/drbd0::/DB::xfs::noatime \
mysql
裡面指定NODE-A為Default Primary,綁定IP為192.168.1.10,使用DRBD resource r0 , 將/dev/drbd0 掛載於 /DB ,指定為xfs,使用noatime參數,最後啟動mysql

HeartBeat failover測試

正常情況

NODE-A為Primary ,DRBD resource r0在NODE-A上為Primary, /dev/drbd0 掛載於 /DB ,MySQL在NODE-A上運作,eth0:0 綁定 192.168.1.10 以提供服務 ,
此時WEB或是其他APP對 192.168.1.10 進行MySQL的資料連線,由NODE-A進行處裡.
NODE-A & NODE-B的heartbeat相互偵測,同時也對額外的PingNode 192.168.1.254進行偵測, NODE-B待命, DRBD resource r0在NODE-B上是屬於Secondary,NODE-A的 /dev/drbd0資料異動會及時寫到NODE-B上

網路發生異常時

NODE-A的網路出現異常(網線中斷或網卡故障)時, NODE-A 在偵測到此狀況後會先將MySQL停止,卸載 /DB 目錄,將DRBD resource r0 /dev/drbd0設為 Secondary.
而後NODE-B 接手將DRBD resource r0 設為Primary, /dev/drbd0 掛載於 /DB , 再將MySQL 啟動, eth0:0 綁定 192.168.1.10 以提供服務 ,
FailOver過程中WEB或是其他APP對DB IP:192.168.1.10的連線會中斷,但當FailOver動作完成之後重連便由NODE-B進行處裡.

主節點死掉時

NODE-B偵測到主節點(NODE-A)死掉的時候,會主動將DRBD resource r0 設為Primary, /dev/drbd0 掛載於 /DB , 再將MySQL 啟動, eth0:0 綁定 192.168.1.10 以提供服務

MySQL with DRBD效能測試

使用MySQL附帶的 sql-bench (/usr/share/mysql/sql-bench) 中的 test-create & test-insert來分別針對 MySQL DATAFILE在一般磁碟分區與DRBD上進行測試比較.以下擷取幾個比較明顯的測試數據,主要差距發生寫入動作上,select讀取並沒有太大差異 .
N代表MySQL DATAFILE放在一般硬碟分區上,D代表MySQL DATAFILE放在DRBD上,檔案系統使用XFS,DB格式為MyISAM
test-create
N Time for create_MANY_tables (10000): 27 wallclock secs ( 0.11 usr 0.09 sys + 0.00 cusr 0.00 csys = 0.20 CPU)
D Time for create_MANY_tables (10000): 67 wallclock secs ( 0.31 usr 0.18 sys + 0.00 cusr 0.00 csys = 0.49 CPU)
N Time for drop_table_when_MANY_tables (10000): 7 wallclock secs ( 0.13 usr 0.48 sys + 0.00 cusr 0.00 csys = 0.61 CPU)
D Time for drop_table_when_MANY_tables (10000): 35 wallclock secs ( 0.19 usr 0.75 sys + 0.00 cusr 0.00 csys = 0.94 CPU)
N Time for create+drop (10000): 22 wallclock secs ( 0.20 usr 0.23 sys + 0.00 cusr 0.00 csys = 0.43 CPU)
D Time for create+drop (10000): 57 wallclock secs ( 0.83 usr 1.29 sys + 0.00 cusr 0.00 csys = 2.12 CPU)
N Time for create_key+drop (10000): 25 wallclock secs ( 0.26 usr 1.05 sys + 0.00 cusr 0.00 csys = 1.31 CPU)
D Time for create_key+drop (10000): 48 wallclock secs ( 0.43 usr 0.55 sys + 0.00 cusr 0.00 csys = 0.98 CPU)
N Total time: 84 wallclock secs ( 0.84 usr 2.11 sys + 0.00 cusr 0.00 csys = 2.95 CPU)
D Total time: 210 wallclock secs ( 1.86 usr 3.10 sys + 0.00 cusr 0.00 csys = 4.96 CPU)
test-insert
N Time for insert (300000): 34 wallclock secs ( 1.35 usr 9.09 sys + 0.00 cusr 0.00 csys = 10.44 CPU)
D Time for insert (300000): 39 wallclock secs ( 2.46 usr 26.74 sys + 0.00 cusr 0.00 csys = 29.20 CPU)
N Time for insert_duplicates (100000): 9 wallclock secs ( 0.42 usr 3.08 sys + 0.00 cusr 0.00 csys = 3.50 CPU)
D Time for insert_duplicates (100000): 12 wallclock secs ( 1.29 usr 2.22 sys + 0.00 cusr 0.00 csys = 3.51 CPU)
N Total time: 610 wallclock secs (85.82 usr 184.06 sys + 0.00 cusr 0.00 csys = 269.88 CPU)
D Total time: 623 wallclock secs (111.64 usr 116.01 sys + 0.00 cusr 0.00 csys = 227.65 CPU)

由上面比較可以看出在進行 test-create 做大量的create table動作時,因為MyISAM每個table都有三個實體檔案(.frm .MYI .MYD)的特性,所造成大量的建檔動作對DRBD的負擔較重,效能下降的幅度高達 250%.
而在進行test-insert時只是單一table進行資料寫入,效能下降幅度較輕微(寫入動作效能約降1/4~1/5).
一般情況下MySQL並不會有大量的create table動作,所以搭配DRBD原則上是在資料異動寫入時耗損約1/4~1/5的效能,所以進行評估時就看在即時備援的考量之下是否可接受這個效能降低的代價了.

參考資料
The DRBD User's Guide : Chapter 8. Integrating DRBD with Heartbeat clusters: http://www.drbd.org/users-guide/ch-heartbeat.html
MySQL 5.0 Reference Manual :: 14.2 Using Linux HA Heartbeat: http://dev.mysql.com/doc/refman/5.0/en/ha-heartbeat.html

相關資源
MySQL: http://www.mysql.com
Linux-HA: http://linux-ha.org/
DRBD: http://www.drbd.org/
Heartbeat: http://linux-ha.org/Heartbeat

2009-01-14

2009年1月 客戶訂單資料外洩事件相關報導/討論蒐集

以下是此次個資外洩事件的相關報導及評論匯整 [懶人包] (2009-01-20 22:30)

Blog/論壇 相關評論

2009-01-09 小歪碎碎念: 資訊鐵胃消化不良???客戶訂單全都露!!
2009-01-09【重灌狂人】:「戰國策」虛擬主機客戶資料嚴重外洩!…共約 4,270 筆!
2009-01-09 台灣FTP聯盟: [轉貼]資訊鐵胃消化不良???客戶訂單全都露!!
2009-01-09 生 魚片的Blog : 客戶資料外洩又一遭~
2009-01-09 roamer - Yahoo!奇摩部落格: (劣劣劣)資訊鐵胃客戶訂單全都露
2009-01-10 單純、幸福 - 戰XX、XX策...客戶資料外洩...共約 4,270 筆!
2009-01-10 大砲開講:「戰國X」客戶資料嚴重外洩?
2009-01-10 受害者揭露往來信件: 戰國策只有客服人員運作
2009-01-11 小歪碎碎念: 鐵胃我真的不想補刀,可是你把病毒放網站放半年太超過了啦~~
2009-01-11 Yiwei's Blog : 資安大漏洞! 資訊鐵胃吐給你看!
2009-01-12 The Will Will Web :從戰國策資訊外洩事件說明 robots.txt 定義檔與資安常識
2009-01-12 高登工作室:用Robots.txt來和搜尋機器人打交道
2009-01-12 roamer - Yahoo!奇摩部落格: (新聞)戰國策4,270筆資料外洩 Google全都露
2009-01-12 PCZONE 討論區:【轉貼】資訊鐵胃消化不良???客戶訂單全都露!!
2009-01-13 資安論壇 • 檢視主題: 戰國策爆發客戶資料外洩事件(2009-01-12)
2009-01-13 AVPClub Security Forums: 名網站管理公司 洩4千個資 - 網路安全討論區
2009-01-13 PCZONE 討論區: 【新聞】名網站管理公司 洩4千個資
2009-01-14 roamer - Yahoo!奇摩部落格: (蘋果)名網站管理公司 洩4千個資
2009-01-14 ZDNet Taiwan - 名家專欄 - 蔡宜秀 - [戰國策事件]為何資料外洩事件像極了不可解的X檔案?
2009-01-14 Rising☆Star 行銷人看世界 ::[新聞分享]行銷企劃滿分的資安公司,卻捅出要命的資安意外...
2009-01-14 都已經事發五天了,在這Plurk討論中還有無辜受害者完全不知道自己個資已被洩漏了
2009-01-14 PTT Gossiping 這樣的危機處理方式 備份圖檔 絕口不提資料外洩的事
2009-01-15 就是資安: 戰國策有錯,那你沒錯嗎?
2009-01-16 這則 Plurk討論中有受害者貼出了最新的通知信件 圖檔備份
 個人看法:雖然晚了點,但是願意正面面對此問題還是值得鼓勵的;只是裡面提到的"竊取"這定義就很模糊了,Google/有道 算是竊取嗎?還是我們這些去Google/有道看到資料的人算"竊取"?
2009-01-20 Rising☆Star 行銷人看世界 ::慢了一步,不過還算是補救了

平面/電子 媒體報導
2009-01-12 Information Security 資安人科技網: 戰國策4,270筆資料外洩 Google全都露
2009-01-12 iThome online : 戰國策爆發客戶資料外洩事件
2009-01-13 壹蘋果網絡: 名網站管理公司 洩4千個資 上網輸入統編就可查到「太誇張」
2009-01-13 iThome online : 戰國策資料全都露 用戶毫不知情
2009-01-14 數位時代 Beta2.0:【今日網摘】主機代管 你的個資安全嗎?
2009-01-17 戰國策Google Cache事件聲明稿

個人感想: 希望這次事件能喚醒部分輕忽資訊安全的網路服務供應商及一般大眾對於資訊安全的重視.

2009-01-11

鐵胃我真的不想補刀,可是你把病毒放網站放半年太超過了啦~~

前情提要請參閱:資訊鐵胃消化不良???客戶訂單全都露!!

2009-01-11 22:50
剛剛在GOOGLE上又逛到一個跟資訊鐵胃相關非常有意思的網頁..
McAfee SiteAdvisor分析報告
http://www.siteadvisor.pl/sites/hotels.com.tw/downloads/9154311/

W32/Pate.a virus

  • 下載發行者的 URL: http://hotels.com.tw/0725ec.htm
  • 下載的 URL: http://hotels.com.tw/hosting.exe
  • 檔案名稱: hosting.exe
  • 檔案大小: 807676
  • 完整總和檢查 (MD5): 29dfa283dd244536d29b9fc2733c6382
  • SiteAdvisor 程式 ID: 9154311
  • SiteAdvisor 上次測試這個下載的日期: 2008 七月
  • SiteAdvisor 上次確認了此連結: 2008 七月
我還特別多事的跑去了 http://hotels.com.tw/0725ec.htm 去看了下..
(放心,這頁面沒毒,不過很有歷史了,這可是2007年當時挑起兩間主機商戰火的導火線..由瀏覽器看到的檔案最後修改時間是 2007年2月6日 上午 10:30:26 )

瀏覽畫面*其中有把滑鼠移到下載聯結上所顯示的位置特別標出 完整頁面備份
發現有問題的檔案是在該頁面的 免費下載虛擬主機選購手冊 那裡的連結
http://hotels.com.tw/hosting.exe !!!小心,此檔有毒!!!
手賤抓下來以後馬上防毒軟體就警告我了..
我把防毒軟體關掉後把檔案抓回來丟到virustotal檢查..我的媽媽啊...
Virustotal報告 http://www.virustotal.com/analisis/68064adae15be057dca3b6e508a754d3
圖檔備份
丟到ThreatExpert的分析結果 http://www.threatexpert.com/report.aspx?md5=29dfa283dd244536d29b9fc2733c6382
圖檔備份

由上傳檢測日期
VirusTotal File
hosting.exe received on 01.11.2009 15:30:59 (CET)
ThreadExpert
Submission received: 12 January 2009, 06:22:09
可以證明這是現抓下來丟上去的.
檔案大小 807676

及MD5值 29dfa283dd244536d29b9fc2733c6382
可以證明那個hosting.exe是完全一樣的檔案.

注:
1.W32/Parite 是個老病毒了,但是感染能力極強
注:2.用wget把那個病毒檔hosting.exe抓下來,他的檔案時間是 2007-02-06 10:28 還真是歷史悠久~

這也太扯了吧,病毒檔放在官網根目錄底下,而且在2008 七月 就被McAfee SiteAdvisor檢測出來,到今天距離被發現已經半年了那個毒檔還在那~還真是好個虛擬主機選購手冊啊~~
鐵胃哩碼幫幫忙好不好~~~~~

2009-01-12 12:10 update:
早上再去抓下那個 http://hotels.com.tw/hosting.exe ,看來有毒的檔案是換掉了.
目前的 http://hotels.com.tw/hosting.exe 已經無毒,大小為629470 bytes.
MD5SUM為 edf2850b834a3870d081e2de264259a8

2009-01-12 12:15 update:
目前該檔案已移除了.

2009-01-12 13:55 update:
昨天夜裡又有網友發現了這個 a.php 截圖放在http://www.badongo.com/pic/5054675?size=original ,看的懂得人就知道那是啥了, 囧rz..

2009-01-09

資訊鐵胃消化不良???客戶訂單全都露!!

今天(2009-01-09)吃飽撐著在用某個統一編號去GOOGLE搜資料時
(過程請參閱這份懶人包的最後部份)
突然發現居然可以在GOOGLE上搜到某號稱資訊鐵胃的公司客戶詳細訂單資料.



簡直就是一整個誇張.

而且用該CHCHE頁面上看到的URL http://www.hotels.com.tw/admin/order/order_detail.php
去GOOGLE使用 site:www.hotels.com.tw/admin/order/order_detail.php 查詢


居然有4270筆資料.
雖然查出來的資料都沒辦法直接點入,但是從 "頁庫存檔" 點進去就一覽無疑了.


受害者 ....族繁不及備載
這些資料我是懶得蒐集,可是應該早就已經有人全抓出來了吧...
趕緊用GOOGLE的網站管理員工具去清吧....

號稱鐵胃結果客戶隱私資料原封不動沒消化就屙出來,還被GOOGLE大神蒐集到..
.這.這....太超過了吧~~~~

後記:
2009-01-09 22:00
為避免對無辜的個資外洩受害者造成二度傷害,我把文中受害者的直接連結拿掉了~~如果有受害者發現自己的資料可以被查到(可以試著拿自己的身分證字號/公 司統編之類的去GOOGLE搜尋),請趕緊用GOOGLE的網頁移除要求工具提交 具體作法請參考 重灌狂人的 如何移除Google搜尋結果中「危害隱私」的Cache暫存資料?

2009-01-10 02:00
有網友回報GOOGLE那邊的暫存資料已移除,
經查證確認GOOGLE的相關資料已經移除了
.
這些資料頁面從被發現到證據消滅歷時約11個小時,但是那些頁面不是2009-01-09 15:00我發現時才出現在網路上的,從GOOGLE的CACHE頁面上的時間紀錄可以知道那些頁庫存檔起碼存在GOOGLE有一個月了.這一個月難道就沒別人發現?? 十分令人存疑...
接下來不知道會怎麼發展? 有人說某先生的大絕是發存證信函, 然後是在官網+中央社商情/數位之牆等媒體張貼公告
拭目以待囉~~


2009-01-10 17:30
剛在大砲開講那邊的一則留言看到有人提供消息說大陸的搜尋引擎 有道 還有那些頁面的快照,去試了一下還真有

有點給他懷疑那個有道的資料是不是從GOOGLE那邊挖過去的,因為連出來的數字都一模一樣4270,不過無論如何~~~鐵胃這次真的糟糕了~~中國大陸那邊的搜尋引擎可不像GOOGLE那麼好說話的.

2009-01-10 18:30
另外讓人不解的是,就算admin/order/order_detail.php可以被google spider爬到,可是那些 order_cust_id order_id user_id 參數spider怎麼會知道呢?
個人初步的推測會不會是具有權限的人員在進入後台進行管理時browser有裝Google toolbar而且google account是登入狀態,所以被GOOGLE記錄到瀏覽的網頁記錄,
而且在他的管理頁面裡面有前一筆/後一筆的連結如下
A HREF="order_detail.php?order_cust_id=ooxxx&order_id=xxooo&user_id=ox",這樣只要抓到一頁其他也就手到擒來了吧.加上那段時間後台管理頁面沒做IP權限限制,很可能在當時只有後台登入頁面(已處理 截圖備份) 有IP/權限限制,但是進去以後的其他程式頁面並沒針對登入session/IP做控管,所以那些參數才會被GOOGLE抓到去用spider爬出來..
另外review了一下不管是GOOGLE還是youdao的那些cache資料的url,發現所有的客戶資料頁面url中的user_id參數全都是70,如果沒有猜錯的話這個user_id有可能是內部人員的編號...囧rz..

2009-01-11 15:50
GOOGLE上的客戶訂單詳細資料頁庫存檔是清掉了,不過還有別的資料沒清還留在GOOGLE上..

"經銷商電子報"??
看來處裡的人員還是不清楚事件嚴重性跟資料外洩的程度 =_="",趕緊去把所有的搜尋引擎都去找一遍吧.
舉一反三有這麼難嗎!

2009-01-11 22:50:
特別把最新發現獨立出來一篇,請參閱

鐵胃我真的不想補刀,可是你把病毒放網站放半年太超過了啦~~



2009-01-12 12:20 :
昨天發現的惡意檔案已經移除~

2009-01-12 20:00 :
其實早先還有網友發現還有別的檔案
admin/order/order_over_flow/index.php (現已處裡)
admin/order/order_excontract/ex_contract_close.php (現已處裡)
是屬於可以直接瀏覽(無登入/IP限制)而且不需其他參數的.

所以鐵胃真的要徹查user_id=70到底是誰.
因為包含根本不用此參數就能瀏覽的 admin/order/order_excontract/ex_contract_close.php & admin/order/order_over_flow/index.php ,在CACHE頁面中來源URL也是user_id=70..(請見下圖紅線標示部份)

Google spider 為什麼會知道這個user_id=70參數,就值得好好研究了...

而且其他搜尋引擎除了"有道"之外基本上都沒有cache到這些資料,
"有道"抓到的url資料跟google那邊CACHE一模一樣,這也是挺耐人尋味的一件事..這是山寨嗎?讓我聯想到 "盜亦有道". 難怪取這名..XD

2009-01-14 特別針對相關評論以及媒體報導整理了個 懶人包 .

2009-01-16 有道搜索引擎上的Cache頁面存檔已移除