連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm (第7頁)

Libraene
個人積分：0分
文章編號：10678214

0分

61樓

2009-03-05 11:40

事實上根據眾多安全專家的追查，這應該是台灣地區的DNS遭到污染，導致這些網站被轉址。

各位可以參考網路資訊網站的這篇新聞

http://news.networkmagazine.com.tw/secrutiy/2009/03/05/11128/
DNS遭攻陷，多家知名網站慘被攔截轉址

不過目前國內的資安單位還沒有站出來有個確切說法。

最糟糕的是那個綁架轉址目的網頁已經種入木馬程式，最好要趕緊中斷讀取網頁，別等到讀完再說，

powerpcer

powerpcer
個人積分：1分
文章編號：10678788

1分

62樓

2009-03-05 12:10

tomtzeng wrote:
那為什麼tw.msn...(恕刪)

想知道什麼, 請自行調出你想了解的網站的header
在這問我沒用, 我沒有必要幫你去了解其它網站為什麼會這樣.
我跟你用相同的DNS, 我連tw.yahoo.com 就從未被redirect 過.
所以你為何連tw.yahoo.com 都會, 就請自行查明原因.

powerpcer

powerpcer
個人積分：1分
文章編號：10678932

1分

63樓

2009-03-05 12:18

Libraene wrote:
事實上根據眾多安全專...(恕刪)

果然是安全專家? 一點邏輯都沒有.
不是直接打ip 去連CNET 也會被轉走了嗎? 還會經過DNS?

Libraene

Libraene
個人積分：0分
文章編號：10679465

0分

64樓

2009-03-05 12:48

後續還有追蹤報導，因為災情包括zdnet taiwan、cnet taiwan、msn taiwan、yahoo taiwan，甚至連hinet.net都聽說有被轉址的現象。

這並非單純可解釋為網站端的系統問題。

問題應該是出在基礎建設上，過去24小時的全球測試，初步已將問題縮小到亞洲區。

這也是為何編輯部改設定為opendns後，就不會發生轉址現象的主要原因。

不知道有沒有其他人改設定為opendns後，仍然遭遇到網址綁架的狀況？

tomtzeng

tomtzeng
個人積分：0分
文章編號：10680605

0分

65樓

2009-03-05 13:50

powerpcer wrote:
想知道什麼, 請自行...(恕刪)

好吧不管他了
看來是在封包傳送過程
中間隨機被塞了一個不正常封包過來
該封包帶有轉址訊息

你說你不會就多試幾次吧
不一定每次都會的的

powerpcer

powerpcer
個人積分：1分
文章編號：10680668

1分

66樓

2009-03-05 13:54

tomtzeng wrote:
唉唉唉報導都出來了...(恕刪)

報導?
prove it!!
你來prove 吧, 我從作天中午就完全沒有連tw.msn.com 有redirect 了. 更別說進tw.yahoo.com 從未被轉址過.
報導呢!!

powerpcer

powerpcer
個人積分：1分
文章編號：10680841

1分

67樓

2009-03-05 14:03

tomtzeng wrote:
好吧不管他了看來是...(恕刪)

packet 這麼好亂加減, 我早發財了, 還用在這跟你講些有的沒的嗎?
有點TCP/IP 的觀念好不好.

tomtzeng

tomtzeng
個人積分：0分
文章編號：10680903

0分

68樓

2009-03-05 14:06

powerpcer wrote:
報導?prove i...(恕刪)

你沒有不代表就沒這件事 OK?
你沒有是你運氣好
報導？
先不管報導說的對不對，至少有出來請看
http://news.networkmagazine.com.tw/secruity/2009/03/05/11128/

tomtzeng

tomtzeng
個人積分：0分
文章編號：10681119

0分

69樓

2009-03-05 14:17

powerpcer wrote:
packet 這麼好...(恕刪)

是是是你最懂你最厲害
我不會什麼都不懂
我只會見一個影生個小孩出來

pb7319

pb7319
個人積分：0分
文章編號：10681145

0分

70樓

2009-03-05 14:19

powerpcer wrote:
packet 這麼好...(恕刪)

你自己sniffer的pcap file裡的第12 packet與第15 packet的seq與ack是一樣的
但一個header是HTTP/1.1 200 IIS 6 ,另一個是HTTP/1.1 301 apache,
除此之外第12個那個packet是FIN/ACK,在第14個 packet client (125.232.140.195) 也response FIN/ACK 給server了.

這樣的行為是滿像tcp hijacking attack