| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
21/01/2011 09:51:49 (+0700) | #1 | 229978 |
PXMMRF
Administrator
|
Joined: 26/09/2002 07:17:55
Messages: 946
Offline
|
|
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 wwwect 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 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)
|
|
 |
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
21/01/2011 10:09:27 (+0700) | #2 | 229981 |
![[Avatar]](/hvaonline/images/avatar/cd96b7e4524f9510644b81ae50c67c5b.png "[Avatar]")
|
No. 47
Member
![[Minus]](/hvaonline/templates/viet/images/minus.gif "[Minus]") |
0 |
![[Plus]](/hvaonline/templates/viet/images/plus.gif "[Plus]")
|
|
Joined: 26/08/2009 02:44:01
Messages: 32
Location: ••••••••••
Offline
|
|
| Đườ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" |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
21/01/2011 11:49:15 (+0700) | #3 | 229986 |
![[Avatar]](/hvaonline/images/avatar/089f41810321eefc3f4eef5d4a388e42.png "[Avatar]")
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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:
/hvaonline/posts/list/40/37203.html#229823
/hvaonline/posts/list/40/37203.html#229865
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 để 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
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:
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 wwwect đế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 wwwection 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 wwwect đến vietnamnet.vn request này lại tiếp tục được wwwect đế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ỉ wwwect đế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
;; 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 wwwect về vietnamnet.vn (117.103.197.249 và 222.255.122.157) theo dạng DNS round robin.
- Nếu thực sự wwwect 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 wwwect 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 wwwection.
- Nếu truy cập trực tiếp tới vietnamnet.vn (222.255.122.157) thì không xảy ra wwwection từ IP này sang IP khác nữa mà lại có thêm một lần wwwection đế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 wwwection. Có lẽ admin muốn wwwect đế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ự wwwection 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 wwwect 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. |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
21/01/2011 17:39:31 (+0700) | #4 | 230015 |
![[Avatar]](/hvaonline/images/avatar/3099a4ec6dc1da1e77c1b4070c7aa9b8.jpg "[Avatar]")
|
bolzano_1989
Journalist
|
|
0 |
|
|
Joined: 30/01/2007 12:49:15
Messages: 1406
Offline
|
|
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 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/m3Fb6C
http://goo.gl/EqaZt
http://goo.gl/gEF8e
Nhận mẫu virus qua FB: http://goo.gl/70Xo23
HVA Malware Response Team: kiemtravirus@gmail.com
Trợ giúp diệt virus: http://goo.gl/2bqxY |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
21/01/2011 22:27:40 (+0700) | #5 | 230025 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
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 wwwect 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? |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 01:32:44 (+0700) | #6 | 230043 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
noobeer wrote:
Việc wwwect 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 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ì?/hvaonline/posts/list/42133.html |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 09:03:06 (+0700) | #7 | 230052 |
mR.Bi
Member
|
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
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 wwwect 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 your children" |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 09:24:25 (+0700) | #8 | 230056 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
|
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 10:00:56 (+0700) | #9 | 230059 |
prof
Moderator
|
Joined: 23/11/2004 01:08:55
Messages: 205
Offline
|
|
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 wwwect 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 |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 10:24:34 (+0700) | #10 | 230060 |
mR.Bi
Member
|
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
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
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 your children" |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 10:28:53 (+0700) | #11 | 230061 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
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 |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 15:13:44 (+0700) | #12 | 230083 |
prof
Moderator
|
Joined: 23/11/2004 01:08:55
Messages: 205
Offline
|
|
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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 18:12:25 (+0700) | #13 | 230093 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
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
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 19:51:45 (+0700) | #14 | 230098 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
22/01/2011 21:46:50 (+0700) | #15 | 230103 |
LeVuHoang
HVA Friend
|
Joined: 08/03/2003 16:54:07
Messages: 1155
Offline
|
|
mrro wrote:
Việc wwwect 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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 08:55:25 (+0700) | #16 | 230119 |
lamer
Elite Member
|
|
0 |
|
|
Joined: 26/02/2008 13:28:49
Messages: 215
Offline
|
|
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?
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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 11:03:40 (+0700) | #17 | 230131 |
![[Avatar]](/hvaonline/images/avatar/110752dad9d4c7d380771c4e43f698f4.jpg "[Avatar]")
|
chube
Member
|
|
0 |
|
|
Joined: 22/10/2010 02:34:04
Messages: 105
Location: ░░▒▒▓▓██
Offline
|
|
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
/ `--' /
/ .---'
/ .'
/ |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 11:14:15 (+0700) | #18 | 230133 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
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.
* 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
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 11:55:19 (+0700) | #19 | 230137 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 12:14:47 (+0700) | #20 | 230138 |
![[Avatar]](/hvaonline/images/avatar/4dd20f1e87dfb889bc97230e2c87c6a5.png "[Avatar]")
|
xnohat
Moderator
|
Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline
|
|
|
|
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 13:44:22 (+0700) | #21 | 230142 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
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é.
Kiểm tra "topology" là kiểm tra cái gì? Làm ra sao?
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.
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. |
|
| What bringing us together is stronger than what pulling us apart. |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 13:47:01 (+0700) | #22 | 230143 |
myquartz
Member
|
|
0 |
|
|
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
|
|
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. |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 13:53:23 (+0700) | #23 | 230144 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
@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.
-m |
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 21:06:05 (+0700) | #24 | 230164 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
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  |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 21:48:32 (+0700) | #25 | 230168 |
![[Avatar]](/hvaonline/images/avatar/ad2965656853a9c15c7179f5740852cf.jpeg "[Avatar]")
|
AIO
Member
|
|
0 |
|
|
Joined: 21/02/2008 23:44:02
Messages: 127
Offline
|
|
| 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ả |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 22:42:45 (+0700) | #26 | 230173 |
LeVuHoang
HVA Friend
|
Joined: 08/03/2003 16:54:07
Messages: 1155
Offline
|
|
@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 :> |
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 22:56:15 (+0700) | #27 | 230174 |
|
xnohat
Moderator
|
Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline
|
|
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
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, |
|
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 23:00:20 (+0700) | #28 | 230175 |
myquartz
Member
|
|
0 |
|
|
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
|
|
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ự.
|
|
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 23:23:31 (+0700) | #29 | 230178 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
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
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
| [Analyzing] VIETNAMNET - Vài góp ý nhỏ trong việc chống DDoS |
23/01/2011 23:25:13 (+0700) | #30 | 230179 |
noobeer
Member
|
|
0 |
|
|
Joined: 09/01/2011 09:22:42
Messages: 0
Offline
|
|
Đồ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 |
|
|
| Users currently in here |
|
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|
![[Rule]](/hvaonline/templates/viet/images/icon_mini_rule.gif "[Rule]"){kind=icon}
![[Home]](/hvaonline/templates/viet/images/icon_mini_groups.gif "[Home]"){kind=icon}
![[Portal]](/hvaonline/templates/viet/images/icon_mini_portal.gif "[Portal]"){kind=icon}
![[Members]](/hvaonline/templates/viet/images/icon_mini_members.gif "[Members]"){kind=icon}
![[Statistics]](/hvaonline/templates/viet/images/icon_mini_stats.gif "[Statistics]"){kind=icon}
![[Search]](/hvaonline/templates/viet/images/icon_mini_search.gif "[Search]"){kind=icon}
![[Reading Room]](/hvaonline/templates/viet/images/icon_mini_book.gif "[Reading Room]"){kind=icon}
![[Register]](/hvaonline/templates/viet/images/icon_mini_register.gif "[Register]"){kind=icon}
Register![[Login]](/hvaonline/templates/viet/images/icon_mini_login.gif "[Login]"){kind=icon}
Login [
Những thảo luận khác
![[Profile]](/hvaonline/templates/viet/images/en_US/icon_profile.gif "[Profile]"){kind=icon}
![[PM]](/hvaonline/templates/viet/images/en_US/icon_pm.gif "[PM]"){kind=icon}
![[Up]](/hvaonline/templates/viet/images/en_US/icon_up.gif "[Up]"){kind=icon}
![[Print Copy]](/hvaonline/templates/viet/images/en_US/icon_print.gif "[Print Copy]"){kind=icon}
![[WWW]](/hvaonline/templates/viet/images/icon_www.gif "[www]"){kind=icon}
![[Email]](/hvaonline/templates/viet/images/icon_email.gif "[E-mai]"){kind=icon}
![[Yahoo!]](/hvaonline/templates/viet/images/icon_yim.gif "[YIM]"){kind=icon}
![[MSN]](/hvaonline/templates/viet/images/icon_msnm.gif "[MSN]"){kind=icon}
![[digg]](/hvaonline/templates/viet/images/digg.gif "[digg]")
![[delicious]](/hvaonline/templates/viet/images/delicious.gif "[delicious]")
![[google]](/hvaonline/templates/viet/images/google.gif "[google]")
![[yahoo]](/hvaonline/templates/viet/images/yahoo.gif "[yahoo]")
![[technorati]](/hvaonline/templates/viet/images/technorati.gif "[technorati]")
![[reddit]](/hvaonline/templates/viet/images/reddit.gif "[reddit]")
![[stumbleupon]](/hvaonline/templates/viet/images/stumbleupon.gif "[stumbleupon]")