VIETNAMNET - Vài Góp ý Nhỏ Trong Việc Chống DDoS - .__ HVAOnline _

11/15/13 VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS - .:: HVAOnline ::.

www.hvaonline.net/hvaonline/posts/list/37393.hva 1/24

PXMMRF

Administrator

Joined: 26/09/2002 07:17:55Bài gởi: 945Offline

English | Vietnamese

Nội Quy Diễn đàn Portal Danh sách thành viên Thống kê Tìm kiếm Phòng đọc

Đăng ký Đăng nhập [ http | https ]

Diễn đàn chính Những thảo luận khác VIETNAMNET - Vài góp ý nhỏ trong việcchống DDoS

Chuyển đến trang: 1 2 3 4

[Phân tích] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS 21/01/2011 09:51:49 (+0700) | #1 | 229978

Tôi mở ra một topic mới liên quan đến việc góp ý cho Vietnamnet trong việc phòng chống DDoS.

Chủ đề này để Vietnamnet có thể tham khảo và áp dụng những biện pháp mà họ thấy phù hợp, cũng như hữu ích

cho các tổ chức điều hành dịch vụ IT khác. Đây cũng là một trong các tiêu chí, mục đích hoạt động của HVA .

Nhân đây tôi cũng xin nhắc các thành viên HVA lưu ý không mở các topic để "hỏi đáp" về một số vấn đề kỹ

thuật trong box "Những thảo luận khác" này. Những câu hỏi thông thường hay câu hỏi kỹ thuật cần được post

vào các box liên quan vốn sẵn có trong forum. Xin cám ơn

========================

Theo tôi cách tốt nhất đối với Vietnamnet trong việc chống đỡ các cuộc tấn công DDoS thời gian vừa qua và kéo

dài đến nay, là có thể thưc hiện các biện pháp sau:

1- Kiểm tra lại topology của toàn bộ hệ thống ( Vietnamnet có trên dưới 10 server sử dụng cho các dịch vụ khác

nhau và giữa chúng có những mối liên hệ khá phức tạp) và xây dựng lai một topology hợp lý nhất (optimal).

Để làm được việc này Vietnamnet phải chịu khó thống kê trong một thời gian đủ dài và phân loại riêng số lương

trung bình các kết nối (của từng loại khách hàng-client) đến từng dịch vụ.

2- Bố trí các server riêng cho từng loại dịch vụ. Có thể bố trí một cụm server (cluster) cho những dịch vụ nhiều

ngưởi truy cập. Server riêng hay cụm server riêng ở đây đươc hiểu là có tên miền riêng và static IP riêng. Khắc

phục ngay tình trang tất cả mọi ngưởi khi truy cập đến Vietnamnet thì chỉ biết (hay chỉ cần truy cập đến) một

domain Vietnamnet.vn mà thôi. Điều đó có nghĩa là loại bớt hay hết các redirect link (đền các dịch vụ khác) hiện

đang đặt nhiều trên (một) webserver "chủ đạo" hiện nay.

Tất nhiên điều này có khó khăn là nhất thời các khách hàng, user thời gian đầu chưa thuộc tên domain của

webserver dịch vụ mà mình muốn truy cập (thí dụ dịch vụ game, media....)

3- Sử dung kỹ thuật Dynamic domain system (với vài Premium domain) để hỗ trợ cho sự hiện diện cùa

Vietnamnet trên mạng (kèm các thông báo cần thiết cho khách hàng) khi các webserver của Vietnamnet bị

DDoS nặng nề và hầu như đã dropped.

Đây là cách giữ uy tín cho Vietnamnet vì luôn cập nhật thông báo cho khách hàng biết tình hình các webserver

của mình đang thế nào (hay đang bị thế nào)

Việt nam ta có một điều rất dở là thường không tìm mọi cách thông báo (từng giờ) tình trạng dịch vụ Web của tổ

chức, công ty mình đang ra sao. Khách hàng không truy cập đươc website, rất khó chịu vì mù tịt thông tin, không

http://www.hvaonline.net/hvaonline/user/profile/1706.hva


http://www.hvaonline.net/hvaonline/pm/sendTo/1706.hva

http://www.hvaonline.net/hvaonline/jforum.hva?module=forums&action=setLang&lang=en_US

http://www.hvaonline.net/

http://www.hvaonline.net/hvaonline/forums/rule.hva

http://www.hvaonline.net/hvaonline/forums/rule.hva

http://www.hvaonline.net/hvaonline/forums/list.hva


http://www.hvaonline.net/hvaonline/portal/list.hva

http://www.hvaonline.net/hvaonline/portal/list.hva

http://www.hvaonline.net/hvaonline/user/list.hva

http://www.hvaonline.net/hvaonline/user/list.hva

http://www.hvaonline.net/hvaonline/forums/stats.hva

http://www.hvaonline.net/hvaonline/forums/stats.hva

http://www.hvaonline.net/hvaonline/search/filters.hva

http://www.hvaonline.net/hvaonline/search/filters.hva

http://www.hvaonline.net/book/

http://www.hvaonline.net/hvaonline/readingRoom/list.hva

http://www.hvaonline.net/hvaonline/user/insert.hva

http://www.hvaonline.net/hvaonline/user/login.hva

https://www.hvaonline.net/hvaonline/user/logins.hva


http://www.hvaonline.net/hvaonline/forums/show/19.hva

http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://www.hvaonline.net/hvaonline/rss/topicPosts/37393.hva

http://www.hvaonline.net/hvaonline/posts/list/30/37393.hva





http://www.hvaonline.net/hvaonline/posts/list/0/37393.hva#229978



No. 47

Member 0

Joined: 26/08/2009 02:44:01Bài gởi: 32Đến từ: ••••••••••Offline

chức, công ty mình đang ra sao. Khách hàng không truy cập đươc website, rất khó chịu vì mù tịt thông tin, không

biết lý do gì, tá hoả điện thoại hỏi nhau.

Có khi phải bố trí một webserver riêng để làm chỉ mỗi việc này hay một vài việc tương tự.

4- Trang bị thêm các Router mạnh ( connection flowrate cao) và nâng cấp kết cấu hạ tâng mảng Front-end.

Chú ý sử dụng các Router có lồng ghép (bên trong) các trình diệt virus và IPS device...

5- Cuối cùng thì nếu có thể mới áp dụng kỹ thuật "Nginx constellation" (Nginx đọc là "engine X"). (Bây giờ ta

thấy trên mạng quảng cáo hết các kỹ thuật "đám mây" rồi đến "chùm sao"...Hì hì)

Kỹ thuật "Nginx constellation" thưc ra chỉ là kỹ thuật sử dụng các cache proxy server đặt phía trước webserver

dịch vụ để giảm tải và phân tải cho webserver chính. Có thể dùng các VM hay VPS (thuê của các ISP khác nhau)

làm cache proxy server, cũng như áp dụng kỹ thuật "Round Robin" trong việc phân giải Record A trên hệ thống

DNS (của các Cache proxy server nói trên).

Tuy nhiên biện pháp này có không ít nhược điểm: tốn tiền thuê VM hay VPS và tốn nhiều thời gian kiểm tra quản

lý chúng, hệ thông cache proxy server sẽ dễ trục trặc khi hacker set TTL cho các DDoS packet đủ ngắn, cache

proxy server không "phục vụ" user đúng URL mà user muốn xem, khi mà một vài data trên URL đã đươc update

(như tôi có dịp đã viết ở một vài post trong HVA forum này)

Nhưng việc "cần phải làm ngay" là phải nhanh chóng tìm ra nguồn phân tán DDoS tool (tức là virus) và sau đó là

các master điều khiển các zoombies (các máy tính bị nhiễm DDoS virus [DDoS tool] trên mạng).

Cần xác định kỹ lại (nhờ CMC infosec) là website đặt ở Đức (.....com) là nguồn phân tán virus (tôi gọi là Virus

containing website- VCW) hay là Master hay là cả hai?.

Vietnamnet cần tài trợ cho CMC Infosec thiết lập một công cụ quét trên mạng để chủ động phát hiện các máy

tính bị nhiễm DDoS tool trên mạng và thông báo cho chủ máy tính diệt trừ chúng, như là cách các nước hiện đại

đã làm. Việc này cần có sự hỗ trợ của một số ISP (Viettel, VNPT, FPT...)

Chủ động diệt trừ (bằng mọi cách có thể) nguồn phá hoại tạo ra DDoS là cách bảo vệ hệ thống của ta một cách

hữu hiệu nhất và triệt để nhất.

The absence of disagreement is not harmony, it's apathy. (Socrates) Honest disagreement is often a good sign of progress. (Mahatma Gandhi)


Đường lối hoạt động của HVA được đặc ra từ trước ngày càng thể hiện rõ - rất cụ thể qua hành động. HVA không

những là nơi thảo luận, trao đổi các vấn đề liên quan kỹ thuật của các anh em, mà còn là nơi sẵn sàn đưa tay

giúp đỡ người khác khi họ gặp khó khăn. Hành động của BQT HVA tiêu biểu là Quản trị viên PXMMRF thật đẹp.

Rất đáng khâm phục!

"Sự vô tâm rất gần vô cảm, sự vô cảm rất gần sự độc ác"







conmale

Administrator

Joined: 07/05/2004 23:43:15Bài gởi: 9340Đến từ: down underOffline


Anh PXMMRF tách chủ đề VNN ra thành một chủ đề phân tích mới nên tớ xin tạo 2 cái link đến 2 bài phân tích

của tớ trong chủ đề cũ đề tiện tham khảo:



Ghi chú: Tôi copy luôn hai bài viết của anh conmale ghi ở trên vào luôn đây cho các bạn dễ đọc. Ấy là chiếu cố

một số bạn thường ngai tô (highlight)-copy-dán (paste)- Vì bài viết khá hay, có nhiều điểm đáng tham khảo.

PXMMRF

======================

Bài viết của anh conmale ngày 19/01/2011 16:11:37 (+0700) | #50 | 229823

Theo một bài viết đăng trên tờ "Lao Động" ở http://laodong.com.vn/Tin-Tuc/Bat-luc-truoc-quai-thu-DDOS/28847

có đoạn:

Theo thông tin từ báo điện tử này, có ít nhất 300 nghìn địa chỉ mạng (IP) phân bố rải rác khắp nơi và từ tất cả các

nhà cung cấp dịch vụ Internet (ISP) ở Việt Nam tấn công vào VietnamNet. Chưa hết, số lượng IP tại mỗi thời điểm tấn

công không lặp lại.

và

Ở lúc cao điểm, chúng tôi chuyển 1/8 lưu lượng tấn công sang một hệ thống khác nhờ xử lý giúp, nhưng băng thông

2Gbps của hệ thống này lập tức bị nghẽn” – một chuyên gia bảo mật tham gia ứng cứu cùng VietnamNet cho biết

(băng thông của VietnamNet được coi là “khủng” cũng mới lên đến 1Gbps – PV).

Hãy thử tính vài con số xem sao.

Cứ cho rằng mỗi packet đập vô thẳng vnn có kích thước tối đa là 1500 bytes và băng thông là 2Gbps thì với

băng thông này ngay tại mỗi thời điểm có thể có: 268435456 / 1500 = 178957 gói tin. Bởi vậy, với "ít nhất" 300

ngàn IP cùng dội thì tất nhiên băng thông sẽ hoàn toàn bị bão hoà. Tất nhiên, trên thực tế thì 300 ngàn IP đó

gởi trước, gởi sau, gởi gói SYN, gởi gói FIN, gởi gói ACK... thì có giá trị thật sự xê dịch. Cho dù vậy, tối đa băng

thông 2Gbps chỉ có thể chịu nổi cùng lắm là 200 ngàn IP đập vô 1 lượt.

Có hai vấn đề cần xét đó là băng thông và sức chịu đựng của cơ chế bảo vệ + hệ thống máy chủ.

Trước mắt, theo tính toán tổng quát ở trên thì rõ ràng băng thông đã bị hoàn toàn bảo hoà. Để có thể khắc

phục tình trạng này, trước tiên phải gia tăng ít nhất gấp 3 lần băng thông, có nghĩa là khoảng 6Gbps. Tuy vậy,

việc này chắc chắn sẽ gây "phản ứng phụ" vì lúc này cổng chính mở càng rộng ra thì "lũ" càng tràn vô nhanh.

Tiếp theo, cơ chế bảo vệ có những biện pháp cản lọc và triệt tiêu như thế nào? Giả sử nếu các gói tin dùng để







Tiếp theo, cơ chế bảo vệ có những biện pháp cản lọc và triệt tiêu như thế nào? Giả sử nếu các gói tin dùng để

DDoS ở đây hoàn toàn hợp lệ và chẳng có dấu hiệu gì đặc thù để cản lọc thì ít nhất vnn phải có một cluster

khổng lồ để "giơ lưng chịu đòn". Tuy vậy, nếu xét ở góc độ cấp số khi tình trạng ngập lụt dâng lên cao thì một

cluster như thế nào được xem là khả dĩ để đón nhận? Đó là một bài toán được giải quyết từ những thông số thu

thập được từ mỗi request đi đến sẽ cần bao nhiêu thời gian, bao nhiêu CPU, bao nhiêu memory và bao nhiêu

I/O.

Trên thực tế, ngay trong tình trạng "slashdot" (có nghĩa là có số lượng người dùng hoàn toàn hợp lệ) cùng

duyệt vnn quá nhiều đi chăng nữa, không thể có tình trạng 300 ngàn IP cùng ập vô 1 lượt bởi vì người dùng

bình thường duyệt và đọc. Bởi vậy, request rate (cho mỗi giây hoặc mỗi phút) đi từ mỗi IP rất thấp (ví dụ, không

thể có chuyện người đọc bài báo nhanh đến độ cứ mỗi 5 giây đọc hết 1 trang được). Từ logic này mới hình thành

ra cái gọi là: packet rate. Packet rate này là thước đo gần như trung thực cho nhu cầu đọc báo của những độc

giả (là con người) và những gì đi quá packet rate thì tạm coi là bất hợp lệ. Nếu vậy, giả sử packet rate được xem

hợp lý là 5 giây / 1 request (chẳng hạn) và mỗi IP trong 300 ngàn IP có người bấm, có người đọc, có người

không bấm trong 10 phút...v...v... thì tính ra 300000 / 5 giây cũng chỉ mới có 60 ngàn IP cùng gởi request 1 lúc.

Số còn lại (240 ngàn IP) có thể thuộc dạng zombie và có thể được triệt tiêu. Nói một cách khác, bất cứ IP nào

gởi quá 1 packet trong 5 giây và tình trạng này kéo dài liên tục trong 60 giây thì đó chính là "chàng DDoS" chớ

không chạy đi đâu được hết.

Triệt tiêu như thế nào? Câu trả lời xác thực cho câu hỏi này không dễ vì tuỳ thiết bị, tuỳ hệ thống, tuỳ topology

nữa nhưng tựu trung, biện pháp hữu hiệu nhất là cho những packets đi từ những IP được xem là quá "packet

rate" ở trên đi thẳng vô /dev/null. Không cản, không xét, không lọc.... vì những thao tác này sẽ hao tổn tài

nguyên không nhỏ và sẽ gây trì trệ theo cấp số. Các thiết bị Cisco, PIX, ngay cả trên BSD, Linux đều có thể có

nhiều biện pháp tạo hoặc dùng /dev/null để chuyển hướng các packets "vi phạm" kia một cách nhanh chóng và

gọn gàng.

Nếu botnet "thông minh" đủ để hạ thấp packet rates nhằm len lỏi chui vô chung với những request bình thường

và hợp lệ của độc giả thông thường thì tác hại của DDoS không còn nữa mà chỉ dừng lại ở mức "slashdot". Ở cấp

độ này thì tất nhiên phải trang bị một hệ thống "khủng" cả băng thông lẫn chuỗi máy chủ thôi.

============================

Bài viết của anh conmale ngày 20/01/2011 08:01:03 (+0700) | #57 | 229865

Tối hôm qua tớ ngồi thử nghiệm thêm VNN ở một góc độ khác nhằm phản biện khía cạnh băng thông bị bão hoà

thì thấy có vài điểm lý thú sau:

- Thử traceroute từ máy của tớ đến vietnamnet.vn thì thấy:

Code:

conmale$ traceroute vietnamnet.vn

traceroute: Warning: vietnamnet.vn has multiple addresses; using 117.103.197.249

traceroute to vietnamnet.vn (117.103.197.249), 64 hops max, 52 byte packets

1 172.16.1.99 (172.16.1.99) 3.256 ms 2.376 ms 2.266 ms

2 10.64.0.1 (10.64.0.1) 9.551 ms 12.110 ms 8.239 ms

3 riv3-ge1-2.gw.optusnet.com.au (198.142.192.161) 8.504 ms 7.963 ms 7.733 ms

4 mas1-ge13-0-0-905.gw.optusnet.com.au (211.29.125.21) 18.982 ms 9.850 ms 11.522 ms

5 mas3-ge2-0.gw.optusnet.com.au (211.29.125.237) 9.214 ms 9.339 ms 10.057 ms

6 203.208.192.169 (203.208.192.169) 169.115 ms 179.886 ms 182.649 ms

7 ge-0-0-0-0.laxow-dr1.ix.singtel.com (203.208.171.65) 178.756 ms

203.208.149.33 (203.208.149.33) 169.686 ms

ge-0-0-0-0.laxow-dr1.ix.singtel.com (203.208.171.65) 168.359 ms

8 xe-0-1-0-0.laxow-dr3.ix.singtel.com (203.208.149.117) 174.514 ms

203.208.152.202 (203.208.152.202) 614.025 ms



203.208.152.202 (203.208.152.202) 614.025 ms

xe-0-1-0-0.laxow-dr3.ix.singtel.com (203.208.149.117) 175.219 ms

9 xe-1-0-0-0.hkgcw-cr3.ix.singtel.com (203.208.152.125) 473.260 ms 613.086 ms 616.756 ms

10 203.208.149.2 (203.208.149.2) 184.680 ms

xe-1-0-0-0.hkgcw-cr3.ix.singtel.com (203.208.152.125) 612.929 ms

203.208.149.2 (203.208.149.2) 189.302 ms

11 d1-98-230-143-118-on-nets.com (118.143.230.98) 729.025 ms

203.208.171.130 (203.208.171.130) 614.731 ms 611.874 ms

12 xe-1-0-0-0.hkgcw-cr3.ix.singtel.com (203.208.152.125) 615.272 ms

user244-0.enet.vn (125.214.0.244) 614.363 ms

xe-1-0-0-0.hkgcw-cr3.ix.singtel.com (203.208.152.125) 615.712 ms

13 117.103.228.93 (117.103.228.93) 611.763 ms

203.208.190.82 (203.208.190.82) 528.150 ms

user244-0.enet.vn (125.214.0.244) 614.636 ms

14 d1-98-230-143-118-on-nets.com (118.143.230.98) 613.326 ms

117.103.197.249 (117.103.197.249) 612.069 ms

d1-98-230-143-118-on-nets.com (118.143.230.98) 613.976 ms

Chứng tỏ packets đi xuyên qua các hops không quá chậm.

Thử traceroute từ Đức về VN:

Code:

[geek@germany ~]$ traceroute vietnamnet.vn

traceroute to vietnamnet.vn (117.103.197.249), 20 hops max, 40 byte packets

1 router144-1.muc1.mivitec.net (91.90.144.1) 2.956 ms

2 62.140.25.41 (62.140.25.41) 0.689 ms

3 ae-11-11.car1.Munich1.Level3.net (4.69.133.253) 173.829 ms

4 ae-4-4.ebr1.Frankfurt1.Level3.net (4.69.134.2) 6.415 ms

5 ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 17.151 ms

6 ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 6.898 ms

7 ae-44-44.ebr2.Washington1.Level3.net (4.69.137.62) 97.086 ms

8 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 93.577 ms

9 ae-84-84.ebr4.Washington1.Level3.net (4.69.134.185) 99.814 ms

10 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 159.520 ms

11 ae-4-90.edge3.LosAngeles1.Level3.net (4.69.144.201) 159.757 ms

12 cr1.lax1.us.packetexchange.net (4.71.136.2) 168.744 ms

13 te4-1.cr1.lax1.us.packetexchange.net (69.174.120.141) 177.229 ms

14 218.189.31.25 (218.189.31.25) 160.724 ms

15 218.189.5.138 (218.189.5.138) 160.963 ms

16 d1-1-224-143-118-on-nets.com (118.143.224.1) 314.368 ms

17 218.189.5.39 (218.189.5.39) 322.274 ms

18 d1-98-230-143-118-on-nets.com (118.143.230.98) 374.891 ms

19 user244-0.enet.vn (125.214.0.244) 366.511 ms

20 117.103.228.93 (117.103.228.93) 365.514 ms

thì thấy packets đi xuyên các hops càng nhanh nữa.

Thử httpwatch để duyệt vietnamnet.vn thì lại thấy:



Thử httpwatch để duyệt vietnamnet.vn thì lại thấy:

13:06:39.771 0.042 380 0 GET null Redirect http://www.vietnamnet.vn/

13:06:40.278 6.449 427 182 GET 302 Redirect to: http://vietnamnet.vn http://www.vietnamnet.vn/

13:06:46.732 2.143 458 406 GET 302 Redirect to: /vn/index.html http://vietnamnet.vn/

13:06:48.882 40.536 436 19 GET 200 text/html http://vietnamnet.vn/vn/index.html

13:07:29.473 0.033 357 (1406) GET (Cache) image/x-icon http://vietnamnet.vn/favicon.ico

Điều này chứng tỏ:

- Cú GET đầu tiên đi đến www.vietnamnet.vn chỉ mất có 0.042 giây thì đầu bên khia nhận request và cho

request này redirect đến vietnamnet.vn. Điều này chứng tỏ băng thông không hề bị nghẽn mà trái lại đường đi

vô www.vietnamnet.vn rất nhanh.

- Giai đoạn redirection từ www.vietnamnet.vn đến vietnamnet.vn cho đến khi response về lại trình duyệt của tớ

mất 6.449 giây. Chứng tỏ sự trễ nãi này xảy ra ở khoảng "response" (đi ra) chớ không phải nằm ở khoảng

"request" (đi vô).

- Sau khi redirect đến vietnamnet.vn request này lại tiếp tục được redirect đến /vn/index.html (thuộc

vietnamnet.vn) và mất thêm 2.143 giây nữa và tệ nhất là chỉ redirect đến một trang index.html

http://vietnamnet.vn/vn/index.html) và response về trình duyệt mất đến 40.536 giây.

Qua những biểu hiện trên tớ tin chắc vnn không bị bão hoà băng thông bằng chứng là request đi vô vẫn cực

nhanh. Chỉ có response đi ra cực chậm. Nến băng thông bị bão hoà thì ra hay vô cũng đều chậm. Dấu hiệu cho

thấy ở đây là dịch vụ web bị nghẽn và không kịp phục vụ người truy cập.

Nếu thử "dig" thì thấy vietnamnet.vn có 2 "A" records:

conmale$ dig a vietnamnet.vn

; <<>> DiG 9.6.0-myBuild <<>> a vietnamnet.vn

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7119

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;vietnamnet.vn. IN A

;; ANSWER SECTION:

vietnamnet.vn. 3600 IN A 222.255.122.157

vietnamnet.vn. 3600 IN A 117.103.197.249

;; Query time: 659 msec

;; SERVER: 139.130.4.4#53(139.130.4.4)

;; WHEN: Thu Jan 20 08:45:16 2011

;; MSG SIZE rcvd: 63

và www.vietnamnet.vn lại chỉ có 1 "A" record mà thôi:

conmale$ dig a www.vietnamnet.vn

; <<>> DiG 9.6.0-myBuild <<>> a www.vietnamnet.vn

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61465

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0



bolzano_1989

Journalist 0


;; QUESTION SECTION:

;www.vietnamnet.vn. IN A

;; ANSWER SECTION:

www.vietnamnet.vn. 3600 IN A 117.103.197.249

;; Query time: 499 msec

;; SERVER: 139.130.4.4#53(139.130.4.4)

;; WHEN: Thu Jan 20 08:45:24 2011

;; MSG SIZE rcvd: 51

117.103.197.249 thì thuộc VTC (trong mạng vnnnic), còn 222.255.122.157 thì thuộc vinagame (trong mạng

vnpt).

Xét đoạn httpwatch ở trên thì thấy:

- Nếu truy cập với www.vietnamnet.vn (117.103.197.249) thì sẽ được redirect về vietnamnet.vn

(117.103.197.249 và 222.255.122.157) theo dạng DNS round robin.

- Nếu thực sự redirect từ 117.103.197.249 về 222.255.122.157 thì hữu lý (vì cho nó đi qua một mạng khác để

share load) nhưng redirect từ 117.103.197.249 về lại chính 117.103.197.249 thì hơi phí vì dịch vụ web phải tốn

thêm tài nguyên để xử lý thêm một cái redirection.

- Nếu truy cập trực tiếp tới vietnamnet.vn (222.255.122.157) thì không xảy ra redirection từ IP này sang IP khác

nữa mà lại có thêm một lần redirection đến /vn/index.html ngay chính dịch vụ trên vietnamnet.vn, từ context "/"

sang context "/vn". Xét về mặt tài nguyên thì dịch vụ web lại tiêu tốn tài nguyên để xử lý thêm một lần

redirection. Có lẽ admin muốn redirect đến một trang static html để giảm thiểu hao tổn tài nguyên từ những

truy cập trực tiếp đến các trang động (dynamic pages) tương tác trực tiếp đến CSDL nhưng thật sự redirection

kiểu này ở tình trạng bị DDoS nặng nề thì không hữu hiệu rồi.

Tớ cũng thử "fire off" hơn 1 chục request liên tục trong 1 giây và thấy hệ thống vietnamnet responded y hệt

như nhau. Các requests của tớ vẫn đến vietnamnet.vn và vẫn được redirect y hệt như trên. Điều này chứng tỏ

hình như vietnamnet không có cơ chế "packet rating" (hoặc request rating) mà tớ đã đề cập ở bài trước. Nói một

cách khác, dường như vietnamnet chìa lưng ra cho DDoS đập thì phải .

What bringing us together is stronger than what pulling us apart.


Gửi chú PXMMRF, bolzano_1989 muốn hỏi trong hoàn cảnh Việt Nam, nếu các ISP đồng ý hợp tác và đã xác định

được các máy tính là bot rồi thì bước tiếp theo, các ISP cần và có thể làm những gì để thông báo và hỗ trợ chủ

máy tính diệt trừ virus cùng độ khả thi thực hiện những việc này như thế nào ?

Qua tìm hiểu thì bolzano_1989 thấy đã có 1 số ISP nước ngoài tích cực hợp tác trong việc làm sạch các máy







noobeer

Member 0


mrro

Administrator


Qua tìm hiểu thì bolzano_1989 thấy đã có 1 số ISP nước ngoài tích cực hợp tác trong việc làm sạch các máy

trong mạng botnet như Virgin Media (UK), Comcast (USA), không rõ ở Việt Nam thì các ISP sẽ hợp tác đến mức

độ nào ?

Kiểm tra các file bạn nghi ngờ có virus: http://goo.gl/EqaZt http://goo.gl/gEF8e http://goo.gl/4H1cn Trợ giúp diệt virus: http://goo.gl/2bqxY Hướng dẫn sử dụng máy tính an toàn, bảo mật: http://goo.gl/mF4vx Nhận mẫu virus qua FB: http://goo.gl/4Zkto


conmale wrote:

Qua những biểu hiện trên tớ tin chắc vnn không bị bão hoà băng thông bằng chứng là request đi vô vẫn cực nhanh.

Chỉ có response đi ra cực chậm. Nến băng thông bị bão hoà thì ra hay vô cũng đều chậm. Dấu hiệu cho thấy ở đây là

dịch vụ web bị nghẽn và không kịp phục vụ người truy cập.

Thời điểm bài trên báo Lao động đăng là ngày 12.1, ngày anh conmale kiểm chứng tình trạng bandwidth là

ngày 20.1, cho nên việc báo Lao động đăng tình trạng bandwidth bão hòa cũng không có gì là không đúng.

Việc redirect request theo nhận xét của anh conmale là để chuyển sang "trang static html để giảm thiểu hao

tổn tài nguyên từ những truy cập trực tiếp đến các trang động...". Liệu còn có thể có mục đích gì khác nữa

không?


noobeer wrote:

Việc redirect request theo nhận xét của anh conmale là để chuyển sang "trang static html để giảm thiểu hao tổn tài

nguyên từ những truy cập trực tiếp đến các trang động...". Liệu còn có thể có mục đích gì khác nữa không?

mình nghĩ việc chuyển hướng này chủ yếu đánh vào điểm yếu của những chú bot, vốn thường ít khi nào triển











mình nghĩ việc chuyển hướng này chủ yếu đánh vào điểm yếu của những chú bot, vốn thường ít khi nào triển

khai đầy đủ bộ giao thức HTTP cả. ví dụ như trình duyệt của người dùng bình thường thấy 301/302 thì sẽ chuyển

hướng sang địa chỉ mà máy chủ gợi ý. còn bot, do không hiểu HTTP, nên sẽ bỏ qua, không chuyển hướng tiếp.

ngoài ra mình thấy /vn/index.html còn chuyển sang một trang trung gian, /chkdd.html?vnnd=cookie trong

đó cookie là UNIX timestamp và MD5 của một cái gì đó. cái chkdd.html làm một chuyện là cài một cookie tên

vnnd với giá trị như trên, rồi chuyển hướng lại sang /vn/index.html.

mình đoán thì thủ thuật này cũng là để phân biệt giữa bot và trình duyệt của người dùng bình thường. bot thì

không hiểu javascript, nên không cài cookie, còn trình duyệt thì sẽ cài, nên VNN sẽ có dấu hiệu phân biệt giữa

chúng ở lần thứ hai chuyển hướng vào lại /vn/index.html (đương nhiên nếu mà trình duyệt của bạn không chạy

javascript, thì bạn sẽ không vào được VNN). một điểm lý thú là đoạn mã trong trang chkdd.html vừa nhỏ, vừa lại

được "minified", chứng tỏ người thiết kế chúng muốn tiết kiệm bandwidth tối đa trước khi xác định chính xác có

phải là bot hay không. nói rõ hơn là thay vì trả về nguyên trang /vn/index.html vài trăm KB, thì trả về

chkdd.html 1-2 KB, như thế đường truyền sẽ ổn hơn rất nhiều.

không có máy móc sẵn ở đây nên mình không thử crack xem cái MD5 ở trên là gì. mình đoán là cái MD5 là một

cái chữ ký được tính dựa trên cái UNIX timestamp và một khoá nào đó. hi hi hi nếu có bạn nào đang ở trong đội

của VNN thì mình có lời khuyên là nên dùng HMAC-SHA256, thay vì MD5 như vậy .

mình cũng có thử làm 2 thí nghiệm nhỏ:

1. xoá cái cookie đi. kết quả: phải quay lại /chkdd.html.

2. sửa cái cookie. kết quả: sửa phần UNIX timestamp hoặc sửa phần MD5 thì đều phải quay lại /chkdd.html.

tóm lại, VNN có kiểm tra xem cookie có đúng là do họ cài hay không, phòng ngừa trường hợp bot nó tự cài cái

cookie luôn. đương nhiên bot sẽ làm được nếu nó cứ chuyển hướng mỗi khi nhận được một cái 301/302, nhưng

như thế thì phức tạp hơn. bài toán lúc này lại là chi phí, ai phải đầu tư nhiều hơn giữa một bên tấn công và một

bên phòng thủ.

mình nghĩ VNN đã khôn khéo chỗ này, chi phí để họ cài những thủ thuật kiểm tra ở trên là thấp, do họ có lợi thế

họ có thể làm tập trung tại một nơi với các giải pháp có sẵn. ngược lại bọn làm botnet phải sửa mã nguồn, cập

nhật hàng loạt cho các con bot. nếu mà bot được thiết kế kém (như CMC nhận xét) thì việc này gần như là

không thể. có lẽ đây là tình trạng hiện tại, nên VietnamNet thời điểm này vào rất nhanh.

mình tò mò không biết là sau khi phân biệt được đâu là bot, đâu là trình duyệt bình thường, thì VNN sẽ làm gì

với những IP đã biết là thuộc botnet? có vẻ như họ không chặn lại triệt để ở những tầng thấp hơn, mà cứ cho đi

vào, rồi chỉ chặn lại bằng cơ chế như đã mô tả ở trên.

có lẽ là do có quá nhiều IP đi chung qua một vài proxy của các ISP, nên VNN không thể chặn. đây cũng là câu

hỏi mà bạn LeVuHoang có đặt ra cho mình trong chủ đề thảo luận về giải pháp chống DDoS mà mình đề nghị.

lúc đó mình có nói đại loại là cứ cho đám proxy đi vào, chặn những thằng nằm ngoài proxy thôi, ví dụ như những

thằng ở nước ngoài chẳng hạn.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva





mR.Bi

Member 0


conmale

Administrator



Tớ cũng thử "fire off" hơn 1 chục request liên tục trong 1 giây và thấy hệ thống vietnamnet responded y hệt như

nhau. Các requests của tớ vẫn đến vietnamnet.vn và vẫn được redirect y hệt như trên. Điều này chứng tỏ hình như

vietnamnet không có cơ chế "packet rating" (hoặc request rating) mà tớ đã đề cập ở bài trước. Nói một cách khác,

dường như vietnamnet chìa lưng ra cho DDoS đập thì phải .

Nếu Vietnamnet chặn bằng packet size: khi số bytes đi qua card mạng lớn hơn mức bình thường trong một thời

gian xác định mới bắt đầu drop, hoặc với tấn số lớn hơn (để không chặn nhầm những request đi qua cùng

proxy) thì hơn chục request của anh chưa đủ điểm để bị chặn, nên suy đoán của anh có phần không đúng lắm

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend yourchildren"


mR.Bi wrote:

Tớ cũng thử "fire off" hơn 1 chục request liên tục trong 1 giây và thấy hệ thống vietnamnet responded y hệt

như nhau. Các requests của tớ vẫn đến vietnamnet.vn và vẫn được redirect y hệt như trên. Điều này chứng tỏ

hình như vietnamnet không có cơ chế "packet rating" (hoặc request rating) mà tớ đã đề cập ở bài trước. Nói

một cách khác, dường như vietnamnet chìa lưng ra cho DDoS đập thì phải .

Nếu Vietnamnet chặn bằng packet size: khi số bytes đi qua card mạng lớn hơn mức bình thường trong một thời gian

xác định mới bắt đầu drop, hoặc với tấn số lớn hơn (để không chặn nhầm những request đi qua cùng proxy) thì hơn

chục request của anh chưa đủ điểm để bị chặn, nên suy đoán của anh có phần không đúng lắm

Đây là biện pháp nhận diện các packets bất hợp lệ (dùng để DDoS). Tất nhiên vẫn phải chịu đòn trước để xác

định cái nào là đồ xịn và cái nào là đồ dỏm. Nếu không sử dụng biện pháp này thì vẫn phải è lưng ra mà chịu

đấm mà thôi. Cái này cũng giống như lên đài và chịu để đối thủ ra vài chiêu trước để xác định loại đối thủ này là

gì rồi mới có cách kiềm chế vậy thôi. Còn không thì bị dập tơi tả từ đầu đến cuối . Nguyên tắc chống DDoS chỉ

dựa trên 1 chuyện duy nhất: xác định đặc tính của gói tin để DDoS và khắc chế nó. Nếu không xác định được

đặc tính gói tin trên mặt kỹ thuật (dựa vào thông tin của header và payload của gói tin) thì phải xác định cường

độ và trường độ của gói tin tấn công. Để xác định được trường độ và cường độ thì phải chịu đưa lưng ra ăn đòn.




http://vndev.net/








prof

Moderator


mR.Bi

Member 0


Thông thường người dùng ở VN truy cập đến site ở VN không đi qua các proxies chính (để ra ngoài) như đến các

site ở nước ngoài. Bởi vậy, lượng người bị cản do dùng chung 1 proxy nào đó rất ít. Số người dùng chung các

proxies riêng (như ở các công ty) thì đành chịu vì chính các máy ở công ty ấy bị nhiễm). Tuy vậy, nếu sử dụng

application layer firewall (7-layers) vẫn có thể xác định và cản được máy nào là máy bị làm zombie, máy nào

không bị làm zombie đằng sau 1 proxy. Cách cản trở này kém hữu hiệu hơn vì phải kiểm soát dựa trên session

và ở trong tình trạng bị DDoS nặng thì không nên dùng.



Um, mình cũng đồng ý với nhận định của mrro ở điểm VNN team đã sáng tạo trong việc cấp và check cookie. Cụ

thể ở trường hợp này là áp dụng chuyển hướng sang 1 trang có kích thước đủ nhỏ và thực hiện việc xác thực

thông qua cookie. Điều này quả là 1 tên trúng 2 đích: kích thước trang nhỏ gọn (hao tổn ít băng thông, trả về

kết quả nhanh, ít tốn kém tài nguyên phục vụ), và vẫn làm được việc kiểm tra xem request là từ máy hay từ

người. Đổi lại là phải redirect vài lần. Tuy nhiên thời gian chờ (cho tới thời điểm này) là chấp nhận được.

Mình cũng thấy nginx, và F5-BigIP đã vào cuộc chơi (Nếu như team VNN ko chơi chiêu obscurity).

Anyway, việc phân tải, và áp dụng nhận diện request "độc hại" mức application có lẽ sẽ hiệu quả hơn nữa nếu

kết hợp với các kiểu kiểm soát connection ở mức networking (như đề nghị của anh conmale). Mình chưa thấy

team VNN triển khai các layer thấp hơn, theo khảo sát của bản thân, hoặc giả các triển khai này còn lỏng lẻo,

và dễ dãi.

--pr0f


Mình cũng thấy nginx, và F5-BigIP đã vào cuộc chơi (Nếu như team VNN ko chơi chiêu obscurity).

haha, nhìn thế cái này là biết có chơi obscurity hay không

Code:

---request end---

HTTP request sent, awaiting response...

---response begin---

HTTP/1.1 302 Moved Temporarily







http://vndev.net/





noobeer

Member 0


prof

Moderator


HTTP/1.1 302 Moved Temporarily

Server: nginx

Date: Sat, 22 Jan 2011 04:20:41 GMT

Content-Type: text/html

Content-Length: 154

Location: http://wwwz.vietnamnet.vn/chkdd.html?vnnd=1295670041.f3a853cbca3292cf0ca3db2538203bd8

Connection: close

Server: F5-BigIP

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend yourchildren"


mrro wrote:

mình đoán là cái MD5 là một cái chữ ký được tính dựa trên cái UNIX timestamp và một khoá nào đó. hi hi hi nếu có

bạn nào đang ở trong đội của VNN thì mình có lời khuyên là nên dùng HMAC-SHA256, thay vì MD5 như vậy

Cứ cho là có thể crack được cái chuỗi MD5 đi, nếu cái khóa bị đổi liên tục thì cookie này có được xem là đủ tốt ko

bạn mrro


Bạn mR.Bi chưa hiểu ý mình rồi. Các thông tin mà bạn nhận được không có gì đảm bảo là chính xác hay đáng tin

cậy . Dẫu vậy, mình cũng hi vọng là Vietnamnet đang làm 1 trong nhiều việc cần thiết là tăng cường tài

nguyên hệ thống.

Ngoài ra, theo mình nghĩ, nếu chỉ đối phó ở mức Application, có lẽ sẽ khá vất vả nếu như bots có khả năng thay

đổi để phù hợp và thích nghi với các phản ứng từ Vietnamnet web servers.













mrro

Administrator


noobeer

Member


nobeer wrote:

Cứ cho là có thể crack được cái chuỗi MD5 đi, nếu cái khóa bị đổi liên tục thì cookie này có được xem là đủ tốt ko bạn

mrro

mình nghĩ một cái cookie có thể xem là tốt khi máy chủ tốn rất ít chi phí để tính toán và kiểm tra cookie. MD5 thì

rất nhanh, nên có thể xem là máy chủ chẳng phải tốn CPU bao nhiêu để tính. vấn đề còn lại là bộ nhớ. chẳng

hạn như sẽ là không hiệu quả nếu mà mỗi yêu cầu đi vào, máy chủ phải lưu một cái gì đó vào bộ nhớ, rồi dùng

cái giá trị đó để kiểm tra xem cookie có hợp lệ hay không. chặng hạn như tạo ra một chuỗi ngẫu nhiên để làm

khoá, rồi lưu cái khoá đó vào bộ nhớ. dẫu vậy mình nghĩ các bạn VNN đẩy tất cả thông tin xuống client hết, khi

yêu cầu quay lại thì họ dùng chính thông tin mà client gửi tới để kiểm tra, do đó không cần phải lưu vào bộ nhớ

gì cả. đây cũng là cách làm hiệu quả nhất trong trường hợp này.

một tiêu chí nữa để đánh giá việc thiết kế một cái cookie như trên là khả năng một ai đó phá vỡ cái thiết kế và

tự tạo ra cookie hợp lệ. mình không rõ các bạn VNN làm như thế nào, nhưng mà việc sử dụng MD5 làm mình lo

ngại. giả sử bình luận "cái khoá bị đổi liên tục" của bạn nobeer là đúng, thì mình càng lo ngại không biết các

bạn ấy sử dụng khoá ra sao, và khái niệm khoá mà các bạn đó đang nói đến là gì.

hi hi ngồi nghĩ một chút mình chợt thấy có thể cái MD5 đó chỉ đơn giản là kết quả của việc băm một loạt các

thuộc tính liên quan đến cái yêu cầu đang được xử lý. ví dụ như nó có thể là MD5 của IP, mấy cái HTTP header,

UNIX timestamp, vân vân... cách làm này cũng được, nhưng nó là biểu hiện của security through obscurity.

-m

PS: có vẻ như có vài người hoặc là đang muốn thể hiện gì đó hoặc là hiểu sai dụng ý của những người đang

tham gia chủ đề này.

những người có ít thông tin về cách triển khai của VNN như các anh em trong BQT HVA chủ yếu muốn, như lời

anh conmale nói, dựa vào các dữ kiện ít ỏi và quan sát khách quan để thử làm một "case study" về cách thức

phòng thủ chống lại tấn công DDoS.

nếu như bạn biết cách mà VNN làm, thì mời bạn chia sẻ. nếu như bạn không chia sẻ được thì thôi, chứ xin đừng

đánh đố lẫn nhau.

http://tinsang.net













Member 0

LeVuHoang

HVA Friend


lamer

Elite Member 0


Mình nghĩ nên quay lại mục đích của cookie này, đó là chống DDOS.

mrro có thể phân tích xem các giá trị IP và timestamp liệu sẽ giúp ích gì cho việc chống DDoS không?

PS: mrro có vẻ như hơi định kiến khi cho rằng có ai đó đang muốn thể hiện/đánh đố .

Đối với mình, việc dẫn dắt/tìm hiểu/phân tích vấn đề trong cả thread này (của anh conmale, của chính mrro) đã

giúp cho mình rất nhiều kiến thức & kinh nghiệm bổ ích.


mrro wrote:

Việc redirect ngoài ra mình thấy /vn/index.html còn chuyển sang một trang trung gian, /chkdd.html?vnnd=cookie

trong đó cookie là UNIX timestamp và MD5 của một cái gì đó. cái chkdd.html làm một chuyện là cài một cookie tên

vnnd với giá trị như trên, rồi chuyển hướng lại sang /vn/index.html.

có lẽ là do có quá nhiều IP đi chung qua một vài proxy của các ISP, nên VNN không thể chặn. đây cũng là câu hỏi mà

bạn LeVuHoang có đặt ra cho mình trong chủ đề thảo luận về giải pháp chống DDoS mà mình đề nghị. lúc đó mình có

nói đại loại là cứ cho đám proxy đi vào, chặn những thằng nằm ngoài proxy thôi, ví dụ như những thằng ở nước ngoài

chẳng hạn.

-m

Nếu đọc kỹ lại bài cũ, thì khi đó mình đã đề xuất giải pháp cookie để phân biệt giữa người và bot thông qua

proxy .

Theo thiển ý riêng của mình thì VNN nên siết lại rule từ tầng network lên tới application mới giảm thiểu thiệt hại

đối đa. Tuy nhiên, vì mình chỉ là người quan sát phía ngoài nên cũng chưa nắm hết được thực hư thế nào.

Ngoài ra, giải pháp chia tải qua các datacenter khác nhau sử dụng DNS round-robin như trên cũng đáng để học

hỏi. 1 case study tốt

Bà con còn ý kiến nào để "tweak" cho VNN thì xin thảo luận thêm.


Qua bao nhiêu bài và chủ đề mà mình vẫn chưa thấy gì gọi là "cụ thể" cả nên ngứa mồm nhảy vào phán nhảm

ké.

Kiểm tra "topology" là kiểm tra cái gì? Làm ra sao?













chube

Member 0

Joined: 22/10/2010 02:34:04Bài gởi: 105Đến từ: ░░▒▒▓▓██Offline

mrro

Administrator



Xây dựng lại "cái đó" như thế nào?

Triển khai, siết lại các layer thấp hơn là cụ thể những layer nào? Làm sao làm?

Ai chẳng biết là phải làm cái này cái kia, nhưng bao nhiêu người biết làm ra sao. Đó mới là mấu chốt vấn đề.

Xin được tặng (biếu?) luôn chủ đề tài này (và những ai quan tâm đến kiến trúc hệ thống) một bài báo kinh điển

với đầy "lời khuyên chung"

On Designing and Deploying Internet-Scale Services --

http://www.usenix.org/event/lisa07/tech/full_papers/hamilton/hamilton_html/

Thời điểm nóng bỏng máu lửa như thế này mà cứ ngồi phán trên trời như vậy thì... quá vô nghĩa.

Mình thích LeVuHoang khi mà đưa ra được một giải pháp khá đơn giản và thực tế như vậy. Tiếp tục thảo luận

theo hướng này sẽ có ích hơn vạn lần.


mình nghĩ những giải pháp anh PXMMRF đưa ra đã chi tiết vì :

- Đối tượng : Báo VNN và các tổ chức điều hành dịch vụ IT ( @lamer : tại sao "họ" không biết phải làm ra sao?

Mình nghĩ nếu muốn biết phải làm ra sao thì họ hơi phụ thuộc)

Những giải pháp đã nêu rõ từ đầu là góp ý. Góp ý dựa trên dữ kiện,mắc xích hiện có ( thông qua các tin tức) lập

nên những giả thiết, đối chiếu chúng và loại đi những chi tiết không hợp lý và giữ lại 1 toàn cảnh những chi tiết

cơ bản. Giả sử nếu không có dữ kiện mà lập giả thiết thì việc hình thành những giải pháp trên là sai lầm. Qua

topic mình đã thu được khá nhiều kiến thức từ các anh quản trị diễn đàn, nếu là người áp dụng mình sẽ chọn lọc

những điểm chính kết hợp thêm tình hình hiện tại ( nếu mình là người của VNN) sau đó áp dụng. Cám ơn

.-/ / ) |/ / / /.' / // .---. / .--._\ Awesome Season to hack :') Dont you think so? xD / `--' / / .---' / .' /












noobeer wrote:

Mình nghĩ nên quay lại mục đích của cookie này, đó là chống DDOS.

mrro có thể phân tích xem các giá trị IP và timestamp liệu sẽ giúp ích gì cho việc chống DDoS không?

hi hi thì trong cái reply ở trên, mình có nói nếu muốn làm cookie chống DDoS thì cụ thể nên làm sao để vừa an

toàn vừa tiết kiệm chi phí mà .

mình nghĩ một cách làm tốt và đơn giản là (không biết có giống với cách VNN đang làm hay không?):

1. cách thức tạo cookie:

* cookie = expired_date || SEPARATOR || signature

* signature = HMAC-SHA256(key, auth_data || SEPARATOR || expired_date),

trong đó:

* key là một chuỗi bí mật, tối thiểu là 16 bytes, không cần phải thay đổi liên tục. chỉ cần giữ kín chuỗi này thì (nhiều

hi vọng) không ai có thể làm giả cookie được.

* expired_date là thời điểm mà cookie sẽ hết hiệu lực. đưa vào expired_date ở đây để phòng ngừa trường hợp ai đó

chép một cái cookie hợp lệ, rồi dùng mãi, dùng mãi.

* auth_data chứa thông tin định danh của cái yêu cầu hiện tại, có thể bao gồm IP, User-Agent và các HTTP header

khác. đưa vào auth_data ở đây để phòng ngừa trường hợp cookie hợp lệ của một máy bị chép và đem ra sử dụng ở

nhiều máy khác nhau.

2. cách thức kiểm tra cookie:

* expired_date, signature = cookie.split(SEPARATOR)

* trích xuất auth_data từ các thuộc tính của yêu cầu hiện tại.

* computed_signature = HMAC-SHA256(key, auth_data || SEPARATOR || expired_date)

* so sánh computed_signature và signature, nếu bằng nhau thì thực thi bước tiếp theo, không bằng nhau thì từ chối.

chú ý dùng các thuật toán so sánh chuỗi có thời gian tính toán là hằng số, để không "leak" thông tin về

computed_signature.

* so sánh expired_date với thời gian hiện tại trên máy chủ, nếu expired_date lớn hơn thì chấp nhận yêu cầu, không

thì từ chối. chú ý nếu có nhiều máy chủ thì phải đồng bộ thời gian giữa chúng với nhau.

giải pháp này, như mô tả ở reply trước, tốt vì:

* tiết kiệm bộ nhớ, do các máy chủ không cần phải lưu gì vào bộ nhớ cả.

* thời gian tính toán nhanh, do HMAC-SHA256 chạy rất nhanh và các thao tác còn lại chỉ là xử lý chuỗi ngắn.



noobeer

Member 0


xnohat

Moderator

Joined: 30/01/2005 13:59:19Bài gởi: 1196Đến từ: /dev/nullOffline

* dễ mở rộng, do các máy chủ không cần phải chia sẻ thông tin gì với nhau (shared nothing architecture), nên

muốn tăng khả năng chịu tải thì chỉ cần thêm máy chủ mới vào là được. mô hình này rất thích hợp với giải pháp

chia tải thông qua round-robin DNS mà VNN đang sử dụng.

* an toàn, do không ai có thể làm giả cookie nếu không biết được key. ngoài ra nó còn tránh được vết xe đổ

"security through obscurity", vì sự an toàn của giải pháp chỉ phụ thuộc vào key, mà không phụ thuộc vào chi tiết

của các thuật toán được sử dụng.

-m

http://tinsang.net




Vẫn chưa thấy mrro phân tích tại sao giá trị IP lại có thể giúp chống DDoS trong trường hợp của VNN

mrro wrote:

an toàn, do không ai có thể làm giả cookie nếu không biết được key. ngoài ra nó còn tránh được vết xe đổ "security

through obscurity", vì sự an toàn của giải pháp chỉ phụ thuộc vào key, mà không phụ thuộc vào chi tiết của các thuật

toán được sử dụng.

Theo mình hiểu thì ý của mrro ở đây là dùng MD5 thì sẽ bị phá giải. Tuy nhiên, như đã nói từ trước, nếu key được

chèn trong chuỗi trước khi băm MD5 được thay đổi liên tục thì liệu tốc độ giải mã của bên tấn công có đủ nhanh

để adapt theo sự thay đổi của phía bị tấn công.

Mình đề cập đến việc này vì MD5 là vừa đủ để cân bằng giữa việc an toàn và performance của server thực hiện

việc tạo & kiểm tra cookie.

Ngoài ra, việc chặn connection per IP và request per connection là bắt buộc trước khi chuyển request vào

server tạo & kiểm tra cookie.








http://www.facebook.com/xnohat

http://edit.yahoo.com/config/send_webmesg?.target=xnohat&.src=pg






conmale

Administrator


lamer wrote:

Qua bao nhiêu bài và chủ đề mà mình vẫn chưa thấy gì gọi là "cụ thể" cả nên ngứa mồm nhảy vào phán nhảm ké.





Xin được tặng (biếu?) luôn chủ đề tài này (và những ai quan tâm đến kiến trúc hệ thống) một bài báo kinh điển với

đầy "lời khuyên chung"




Mình thích LeVuHoang khi mà đưa ra được một giải pháp khá đơn giản và thực tế như vậy. Tiếp tục thảo luận theo

hướng này sẽ có ích hơn vạn lần.

Thật sự là ai cũng muốn bắt tay vào xử lý case study rất thực tế và rất khẩn cấp này lão à nhưng khổ nỗi

Vietnamnet không xì ra bất cứ thông tin kỹ thuật nào ( dù chỉ là một dòng log ) khả dĩ giúp chúng ta có cái nhìn

cụ thể về cuộc thất công, họ vẫn đang dùng obscurity để chống đỡ là nhiều, ngay cả anh conmale vẫn đang

nghiên cứu dựa trên các thông tin rất ít ỏi mà anh ấy thu thập được một cách hợp pháp.

anh em HVA đều nóng lòng muốn giúp đỡ Vietnamnet , tớ cá là các bài viết hiện nay của HVA về Vietnamnet

đều được một số (hoặc nhiều) thành viên trong nhóm đang chịu trách nhiệm chống đỡ hệ thống của Vietnamnet

theo dõi sát sao, nếu các bạn ấy chịu hợp tác hơn thì có lẽ đã có giải pháp cụ thể hơn rồi

Just clear, "What I need to do and how to do it"

Box tán gẫu dời về: http://www.facebook.com/hvaonline


lamer wrote:

Qua bao nhiêu bài và chủ đề mà mình vẫn chưa thấy gì gọi là "cụ thể" cả nên ngứa mồm nhảy vào phán nhảm ké.





Xin được tặng (biếu?) luôn chủ đề tài này (và những ai quan tâm đến kiến trúc hệ thống) một bài báo kinh điển với

đầy "lời khuyên chung"












myquartz

Member 0


mrro

Administrator





Mình thích LeVuHoang khi mà đưa ra được một giải pháp khá đơn giản và thực tế như vậy. Tiếp tục thảo luận theo

hướng này sẽ có ích hơn vạn lần.

Làm sao mà "cụ thể" khi mình chẳng nắm được cái gì "cụ thể" của đối tượng cần được khắc phục hở bồ?

Những thảo luận ở đây chỉ là những suggestions dựa trên những thông tin khá lờ mờ được đăng trên báo và

một số thông tin có thể thu thập được bằng cách thử nghiệm trực tiếp (và hợp lệ) mà thôi. Bởi vậy, dù có muốn

"cụ thể" mấy cũng không được bởi vì vietnamnet chưa bao giờ tiết lộ các thông tin kỹ thuật và chưa bao giờ ngỏ

lời cần trợ giúp (trong thời điểm nóng bỏng máu lửa) hết.



Cách chống của mrro phá sản nếu như bot nó không chạy web tự chế ở layer thấp mà dùng chính một trình

duyệt hợp lệ để tấn công. Ví dụ cứ exec iexlorer.exe <URL> ở 1 session khác, chờ 1 tí lại mở cái trang đó lại.

Hoặc nó inject vào trang trình duyệt người sử dụng đang dùng như dạng iframe chẳng hạn thì cũng như vậy.

Mặc dù cách này chậm hơn là kết nối HTTP trực tiếp nhưng cũng tạo ra tải kha khá, hơn nữa không thể phân

biệt được slashdot hay non-slashdot.

Thêm 1 í nho nhỏ cho VNN. Bên cạnh lớp App, FW, ở lớp mạng, ngoài DNS Round robin - chỉ có ích khi bot nó

thực hiện phân giải tên ra địa chỉ, chứ nếu chơi thẳng IP thì 1 con server vẫn overload - với vị thế của VNN có

thể dùng Anycast (họ có thể đã có AS Number riêng). Phân tán khoảng 2, 3 site ở HCM, HN, kết nối đồng thời

nhiều mạng FPT và mạng VNPT, Viettel tốc độ cao. Tuy cách này tốn kém nhưng bù lại, khả năng phân tải và cô

lập từng vùng cực kỳ hiệu quả. Mọi thứ từ client thấy chỉ là 1 IP của VNN.


@myquartz: mình không đề nghị cách làm đó, mà cách đó là cách mà VNN đang sử dụng, và mình chỉ gợi ý là

nếu đã làm như thế, thì nên làm sao cho nó hiệu quả.

@noobeer: mời bạn trình bày cụ thể key là gì và key được chèn trong chuỗi ra sao, y như mình vừa trình bày ở

trên, rồi mình sẽ phân tích xem cái hay cái dở của cách làm đó là như thế nào.











noobeer

Member 0


AIO

Member 0


-m

http://tinsang.net




Mình không phải là người VNN nhưng đọc cái comment của xnohat thì thấy như sau:

"anh em HVA đều nóng lòng muốn giúp đỡ Vietnamnet", "rất thực tế và rất khẩn cấp", "nếu các bạn ấy chịu hợp tác

hơn"....

Các bạn HVA đã ở đâu khi VietnamNet bị tấn công từ ngày 4/1 cho đến tận bây giờ.

HVA đã có ngỏ lời giúp đỡ VietnamNet hay chưa?

Việc phân tích chi tiết về cách phòng chống của VietnamNet cũng mới có từ ngày 19/1.

Bạn có chịu nhúng mũi vào đâu để mà Vietnamnet có thể "xì ra bất cứ thông tin kỹ thuật nào"???

Lại nữa, xnohat bảo không biết tí thông tin kỹ thuật nào từ VietnamNet nhưng lại phán là "họ vẫn đang dùng

obscurity để chống đỡ là nhiều", sao bạn dám chắc thế nhỉ?

Mình nghĩ với tư cách là một MOD như xnohat thì không nên có kiểu "phán" hay "chém gió" như thế.

Mình đọc đâu đó trong diễn đàn này là "VietnamNet phải ngỏ ý nhờ HVA" thì mới được giúp đỡ. Mình không có ý

kiến nhiều về việc này, mỗi người/tổ chức có cách làm của họ.

Nhưng mình dẫn chứng một trường hợp ngoài đời như thế này: ngoài đường, bạn gặp 1 người bị cướp, và bạn là

người đang đứng gần tên cướp nhất. Có lẽ bạn phải chờ người kia lên tiếng nhờ thì bạn mới giúp đỡ nhỉ?!?

Đôi khi, những người khác đánh giá 1 con người qua việc họ không làm, chứ không phải việc họ làm


Mình rất cảm ơn nếu mọi người tiếp tục phân tích kỹ thuật.

chẳng ai nghĩ gì về mình cả











LeVuHoang

HVA Friend


xnohat

Moderator

Joined: 30/01/2005 13:59:19Bài gởi: 1196Đến từ: /dev/nullOffline


@noobeer: Có lẽ nên xem đây là 1 case study để *nếu có* xảy ra cho lần sau đúng hơn. Thật ra cũng không

cần phải hơn thua, bắt bẻ quá làm gì. Mọi người nên tiếp tục thảo luận về mặt kỹ thuật thì hay hơn.

Trở lại với vấn đề cookie của VNN. Thay vì dùng MD5 hay SHA256 như mrro đề xuất, để tăng performance, mình

có thể đề xuất 1 giải pháp đơn giản sử dụng CRC như sau:

Generate ra cái string khoảng 256 hoặc 8192... hoặc bao nhiêu tùy thích.

Ở vị trí thứ 2, giữa, và cuối string (3 bytes hoặc có thể nhiều hơn nữa dựa vào cách sysadmin VNN muốn), luôn

là những bytes cố định.

Trên thực thế là không cần kiểm tra hết chuỗi, chỉ cần kiểm tra 1 vài bytes để biết được đoạn string này có

authen hay không, các kí tự còn lại đều là random.

Cách này hơi cổ điển, nhưng không phải là không xài lại được :>


Hì hì bồ đi chệch hướng thảo luận kỹ thuật của diễn đàn rồi đấy , cẩn trọng nhé

noobeer wrote:

Mình không phải là người VNN nhưng đọc cái comment của xnohat thì thấy như sau:

"anh em HVA đều nóng lòng muốn giúp đỡ Vietnamnet", "rất thực tế và rất khẩn cấp", "nếu các bạn ấy chịu

hợp tác hơn"....

Các bạn HVA đã ở đâu khi VietnamNet bị tấn công từ ngày 4/1 cho đến tận bây giờ.

HVA đã có ngỏ lời giúp đỡ VietnamNet hay chưa?

Việc phân tích chi tiết về cách phòng chống của VietnamNet cũng mới có từ ngày 19/1.

Ngay topic này và topic trước đây chính là lời ngỏ rất thịnh tình của HVA đối với Vietnamnet

noobeer wrote:














Bạn có chịu nhúng mũi vào đâu để mà Vietnamnet có thể "xì ra bất cứ thông tin kỹ thuật nào"???

"Nhúng mũi" theo cách nào bây giờ khi mà họ không hề có một sự chủ động nhờ giúp đỡ ? Không lẽ tôi và anh

em HVA phải hack vào hệ thống của Vietnamnet và sục xạo trong đó để coi coi họ bị khuyết điểm ở đâu để sửa

cho họ . Ngay chỉ khi nghĩ tới điều này thì bồ đã bước một chân vào vi phạm Luật công nghệ thông tin ( năm

2006 của CP nước CHXHCN Việt Nam ), mà Vietnamnet là một cơ quan trực thuộc nhà nước, thì luật là thứ càng

phải thượng tôn

noobeer wrote:

Lại nữa, xnohat bảo không biết tí thông tin kỹ thuật nào từ VietnamNet nhưng lại phán là "họ vẫn đang dùng

obscurity để chống đỡ là nhiều", sao bạn dám chắc thế nhỉ?

Mình nghĩ với tư cách là một MOD như xnohat thì không nên có kiểu "phán" hay "chém gió" như thế.

Tôi nói Vietnamnet "họ vẫn đang dùng obscurity để chống đỡ là nhiều" là có cơ sở, chính việc kín tiếng ( trong

việc nhờ trợ giúp và cung cấp các thông tin cần thiết để trợ giúp họ ) của họ cho đến lúc này cũng chính là sự

khẳng định cho kết luận trên của tôi, tôi có thực hiện lại các khảo sát mà anh conmale và mrro đã thực hiện

cùng với một số khảo sát của riêng tôi thì thấy họ vẫn đang theo hướng tạo ra 1 cái BlackBox và hy vọng rằng

càng kín càng tốt thì kẻ tấn công càng khó tấn công vì không rõ "chiêu" họ ( rất tiếc là bằng nhiều cách khác

nhau vẫn xác định được phần nào chiêu của họ). Bồ có lẽ hiểu sai điều tôi nói vì chưa rõ nghĩa của vấn đề

"Security through obscurity", trên forum có một topic rất hay cách đây 1 năm đề cập tới vấn đề này

noobeer wrote:

Mình đọc đâu đó trong diễn đàn này là "VietnamNet phải ngỏ ý nhờ HVA" thì mới được giúp đỡ. Mình không có ý kiến

nhiều về việc này, mỗi người/tổ chức có cách làm của họ.

Nhưng mình dẫn chứng một trường hợp ngoài đời như thế này: ngoài đường, bạn gặp 1 người bị cướp, và bạn là

người đang đứng gần tên cướp nhất. Có lẽ bạn phải chờ người kia lên tiếng nhờ thì bạn mới giúp đỡ nhỉ?!?

Đôi khi, những người khác đánh giá 1 con người qua việc họ không làm, chứ không phải việc họ làm

HVA vẫn đang chủ động giúp đỡ Vietnamnet trong giới hạn thông tin ít ỏi mà HVA có, mà minh chứng chính là cái

topic này.

Bồ nói thì dễ đó, nhưng một khi chính bồ là người làm bảo mật, thì bồ sẽ biết được là người làm bảo mật cần có

những dữ liệu tiên quyết nào để hình thành một cái nhìn tổng quan về vấn đề và để đề ra phương pháp, không

phải cứ khơi khơi như kiểu "ngoài đường, bạn gặp 1 người bị cướp" vì đây là 2 vấn đề khác nhau, gặp cướp bồ

hay bất kì ai đều có thể đập cho nó một cái và giúp người đi đường, vì thứ bồ cần để xử lý tên cướp chỉ là sức,

còn ở đây thứ bồ cần đề xử lý tên tấn công lại là dữ liệu cuộc tấn công, thì Vietnamnet không hề công bố

Post tôi viết ở trên thực tình là để dành cho các bạn đang đương đầu với cuộc tấn công ở Vietnamnet, thông

điệp mà tôi muốn truyền tải là HVA đã và đang luôn sẵn lòng giúp đỡ Vietnamnet nói riêng và các cơ quan tổ

chức , cá nhân gặp vấn đề về an ninh mạng nói chung, điều kiện tiên quyết là họ cần tích cực cung cấp các

thông tin về cuộc tấn công cho HVA như là một lời chủ động nhờ giúp đỡ vậy, vì chúng tôi không phải thầy bói

xem voi mà có thể đưa ra những giải pháp hiệu quả trong tình trạng cực kỳ thiếu thông tin



myquartz

Member 0


xem voi mà có thể đưa ra những giải pháp hiệu quả trong tình trạng cực kỳ thiếu thông tin

Vài lời hy vọng đã giải đáp được phần nào điều bồ noobeer thắc mắc

Tôi cũng chú ý bồ noobeer là , văn hóa giao tiếp trên diễn đàn HVA cũng cần sự từ tốn và tôn trọng lẫn nhau,

chú trọng vào chủ đề cần thảo luận thay vì chỉ trích cá nhân.

Thân mến,

Just clear, "What I need to do and how to do it"

Box tán gẫu dời về: http://www.facebook.com/hvaonline


Thật ra, các ý trong bài này mang tính chất nói góp ý cho thêm phần phong phú, sơ sơ bên ngoài, hoặc phân

tích cái đã có, chứ làm theo thì có thể không triển khai thực tế được (hoặc không đủ nguồn lực, thời gian để triển

khai).

Một hệ thống bảo mật, chịu DDoS hay chịu hack tốt thì phải "think about secure first" ngay từ khi xây dựng nó.

Nay cứu VNN chỉ là chắp vá, đưa các giải pháp tình thế hoặc sửa cho nhanh để mà thoát khỏi tình trạng bị từ

chối dịch vụ.

Topology (hay nói chung là vậy) thay đổi không dễ dàng nhanh chóng được, vì nó liên quan đến cả hệ thống

ứng dụng đang chạy và sự ổn định của hệ thống, sự rắc rối của các liên kết. Cái đang có chỉ có thể "cải tiến",

"sửa chữa" chứ không thể làm thay đổi về chất của nó được nếu không lập project tử tế. Hơn nữa thay đổi toàn

bộ cấu trúc là cái rủi ro nhất các thay đổi của hệ thống, có khi chả ai đánh tự sập ấy chứ.

Theo tớ được biết, và sự hiểu biết về VASC (chủ của VNN) từ trước - khi còn làm nhân viên của nó. Hệ thống VNN

từ trước (do tớ rời VASC cách đây 8-9 năm rồi) và có thể cả hiện tại, đã không thiết kế xây dựng với tiêu chí "bảo

mật" và "an toàn an ninh" ngay từ đầu. Kể cả tiêu chí "hiệu năng", "khả năng mở rộng" cũng chưa chắc đã được

tính đến một cách thấu đáo. Nó có lẽ chỉ nhắm được 2 cái là "chạy được" và phát triển ứng dụng "thật nhanh ra

sản phẩm". Các gót chân Asin lần lượt bị khai thác, hack đầu tiên là "bảo mật", nay DDoS là nhằm vào "hiệu

năng" và "khả năng mở rộng". Đánh đúng vào các điểm bị coi nhẹ khi xây dựng hệ thống thì nghe chừng sẽ rất

khó khăn cho VNN.

- Xin 1 phút cho quảng cáo việc làm cho HVA Mem -

Có lẽ lời khuyên cho VNN giờ là: cứ chống được chừng nào hay chừng đó với nguồn lực sẵn có, dĩ nhiên nếu

thuê/mướn chuyên gia thì có khi sẽ tốt và hiệu quả hơn.

Còn lâu dài thì nên thuê mướn các chuyên gia bảo mật kinh nghiệm (ví dụ HVA mem), đánh giá, tư vấn ngay từ

đầu việc cải tổ hoặc xây dựng mới, mua mới 1 hệ thống CMS tử tế hơn cái đang xài, để đảm bảo ổn định, bảo

mật lâu dài về sau. Cái này không chỉ dành cho VNN mà có thể nhiều báo điện tử khác, vì chắc gì CMS các vị

đang xài đã chịu nổi 1 cuộc tấn công tương tự.









mrro

Administrator


noobeer

Member 0

Joined: 09/01/2011 09:22:42Bài gởi: 0

Offline

@noobeer, xnohat: mong hai bạn không tranh luận về những vấn đề không phải kỹ thuật trong chủ đề này.

@LeVuHoang: không hiểu cách của bạn lắm? ý bạn là nhét một vài byte hằng số vào những vị trí cố định trong

một chuỗi dài, và rồi kiểm tra chuỗi gửi về xem giá trị ở những vị trí cố định đó có đúng là các hằng số ban đầu

hay không?

-m

http://tinsang.net




Đồng ý với bạn LeVuHoang là "nên xem đây là 1 case study để *nếu có* xảy ra cho lần sau".

Mình không có ý chỉ trích hay chê bai ai, nhưng cái cách diễn đạt của xnohat làm mình hiểu như mình đã hiểu. Và

mình cũng chả có gì phải cẩn trọng cho việc này cả

"Ngay topic này và topic trước đây chính là lời ngỏ rất thịnh tình của HVA đối với Vietnamnet": nếu đây là cách

ngỏ lời thịnh tình quả thực mình mới gặp lần đầu trong đời . Nhưng thôi, sẽ không bình luận gì thêm vì đó là

cách của mỗi người/tổ chức

Chuyển đến trang: 1 2 3 4

Chuyển đến: Những thảo luận khác

Các thành viên đang hiện diện ở đây

1 Khách

Powered by JForum - Extended by HVAOnline hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org

1999 - 2013 © v2012|0504|218|













http://digg.com/submit?phrase=2&url=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://del.icio.us/post?url=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://www.google.com/bookmarks/mark?op=edit&output=popup&bkmk=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://bookmarks.yahoo.com/toolbar/savebm?opener=tb&u=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://technorati.com/faves?add=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://reddit.com/submit?url=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

http://www.stumbleupon.com/submit?url=http://www.hvaonline.net/hvaonline/posts/list/37393.hva

mailto:[email protected]

Documents

VIETNAMNET - Vài Góp ý Nhỏ Trong Việc Chống DDoS - .__ HVAOnline _