<![CDATA[Latest posts for the topic "Ký sự các vụ DDoS đến HVA - Phần 23"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net Ký sự các vụ DDoS đến HVA - Phần 23 Tối 28/8/2008 Cả ngày hôm trước và hôm nay tôi phải đi công tác bên ngoài và lu bù công việc nên không có chút thời gian để mó vào hệ thống HVA. Trong hai ngày này, tôi nhận được một số e-mail từ JAL cho biết tình trạng HVA bị "tê" vào ban đêm vẫn tiếp diễn. JAL vẫn tiếp tục sniff các gói tin vào lúc tình trạng "tê" này xảy ra. Mãi đến buổi tối, khi về đến nhà, tôi mới có thể log vào HVA để tải các gói tin được sniff này về để phân tích. Mở mấy gói tin này ra xem, tôi chẳng thấy có dấu hiệu gì chứng tỏ HVA bị DDoS cả. Kéo thanh trượt lên, kéo thanh trượt xuống, sắp xếp theo Protocol, sắp xếp theo Info, lọc lựa (trên WireShark)... tôi chẳng thấy có gì khả nghi. Vậy HVA bị cái gì? Tôi thoáng nghĩ: "hay là chẳng có ai 'chơi' HVA cả mà có thể là một công tác tự động chạy theo định kỳ nào đó trên web server bị sự cố?". Tôi log vào máy chủ HVA và rà soát từng giá trị trong cái crontab -68-. Chẳng thấy có gì đáng ngờ. Tôi quyết định tạm thời tắt bỏ một số "cron job" không quan trọng trên crontab và gán thêm thông tin logging để bảo đảm các "cron job" này không phải là nguyên nhân khiến cho HVA bị.... "tê". Tôi xếp máy đi ngủ vì quá mệt. Trằn trọc một tí, trong đầu tôi chợt loé ra một điểm quan trọng: mớ packets mà JAL sniff hoàn toàn chỉ có thông tin về các TCP packets chớ không có tí gì đụng đến UDP. Tôi thiếp đi. Tối 29/8/2008 Cả ngày 29/8 tôi lại bận rộn. Chiều 29 tháng 8 2008, tôi login firewall của HVA và đồng thời kiểm tra mail xem có gì cần giải quyết ngay không. Tôi nhận được một loạt mail của JAL thông báo tình hình diễn đàn bị "đơ" mỗi tối mặc dù hệ thống phòng thủ (ngay thời điểm ấy) đâu vào đấy. Vào diễn đàn, trong mớ PM tôi nhận được, có một PM (private message) rất lý thú. Đại loại chủ nhân của PM đó đề nghị tôi 'add' Yahoo nick của anh chàng ấy để chúng tôi tiện thảo luận và "thử nghiệm" về DDoS. Anh ta còn cho biết rằng, chính anh ta là chủ nhân của mấy trận DDoS vài hôm vừa qua. Tôi trả lời, cho anh chàng ấy nick của tôi và hẹn sau vài giờ nữa tôi sẽ vào YIM (Yahoo instant messenger) -69-. Tôi xếp máy, lên tàu lửa về nhà. Trên tàu, tôi mở laptop ra và xem lại những đoạn packets tôi sniff được và một số JAL sniff rồi gởi cho tôi để phân tích và tìm xem có chi tiết nào cần chú ý hơn không. Như bức hình minh hoạ của bài trước, tôi nhận ra ngay một loạt UDP packets không hề có source port và destination port -70-. Hơn nữa, chúng lại cực kỳ dồn dập (chỉ trong vòng 1 giây có đến trên 200 UDP packets như thế đi đến từ một IP cá biệt). Tiếc thay, đoạn packet sniff kia không dài hơn, có lẽ JAL đã gián đoạn nó vì sợ kích thước quá lớn để tôi tải về. Với hai đặc điểm trên, tôi ghi chú xuống một mảnh "notepad" để lưu ý về sau. Trong đầu tôi nghĩ ngay đến biện pháp dùng netfilter để drop các packets bất hợp lệ như thế (ai lại không nghĩ như thế nhỉ?). Tối hôm ấy, sau bữa cơm tối, tôi lại login firewall của HVA, đồng thời mở "pidgin" lên để vào "thảo luận và thử nghiệm DDoS" với chủ nhân của cái PM hồi chiều. Thú thật, trong lòng tôi hết sức chủ quan và không mấy lo ngại bởi vì phương án "drop các packets bất hợp lệ" xem như là giải pháp tốt nhất. Vào firewall, tôi hình dung ngay một dòng luật có tác dụng đại khái: "những gói tin UDP nào có source port là null và destination port là null thì drop nó", đơn giản! Tôi hăm hở mở ngay hồ sơ cấu hình của firewall và bắt đầu gõ.... nhưng, ngay lúc đó, tôi khựng lại, vò đầu và lẩm nhẩm: "Chết mồ rồi! Netfilter làm gì có chuyện null source port và null destination port trời?" Tôi tin tưởng trí nhớ mình không tồi và mình đã "vọc" mấy cái netfilter / iptables này nhẵn ra rồi thì làm sao mà nhớ sai được. Tuy nhiên, tôi vẫn kiểm nghiệm lại: Code:
[conmale@hva]# iptables -p udp -h
Đoạn cuối bảng "help" hiện ra mồn một: Code:
UDP v1.4.0 options:
 --source-port [!] port[:port]
 --sport ...
				match source port(s)
 --destination-port [!] port[:port]
 --dport ...
				match destination port(s)
Tôi gãi đầu, thừ người ra. Giá trị "port" phải hiện hữu! Chẳng lẽ bây giờ phải 'hack' cả đống netfilter code để thoả mãn nhu cầu của mình? Vả lại còn bao nhiêu thứ liên quan nữa. Lỡ bị sự cố tùm lum thì càng thê thảm. Thời gian đâu mà test cho hết và fix cho hết? Tôi quyết định mở mới source code của netfilter và iptables ra ngâm cứu. Càng xem, càng thấy phương án 'hack code' này không khả thi vì có quá nhiều modules liên quan và phụ thuộc vào cái "core" của netfilter cho phần source port và destination port. Nghĩ cũng phải, làm sao một gói TCP hay UDP mang tính hợp lệ mà không có giá trị "port"? Thôi vậy! Thử nghĩ cách nào khác xem sao. Vào lúc ấy, anh chàng "chủ nhân" cái PM xuất hiện. Anh chàng chào hỏi rất nhã nhặn và tỏ vẻ nôn nóng muốn "thử nghiệm" ngay. Tôi triển hạn, bảo anh chàng đợi tôi thêm một tí. Ngồi chống cằm, tôi suy nghĩ thêm về giải pháp lọc UDP mặc dù ngay lúc đó tôi không chắc có phải anh chàng dùng UDP để "chơi" hay thứ gì khác. Tôi tự nhủ: "ngay cả firewall không drop mấy packets bất hợp lệ này thì chúng cũng tự động bị triệt tiêu vì chúng chẳng đi về đâu cả. Thôi, cứ thử nghiệm để xem thêm thế nào." Thế là tôi gởi thông điệp bảo anh chàng bắt đầu "gõ" HVA đi. Tôi nhanh chóng mở ra thêm một console và trên mỗi console tôi phóng một cái tcpdump như sau: Code:
[conmale@hva]# tcpdump -i eth0 tcp port 80
và: Code:
[conmale@hva]# tcpdump -i eth0 udp
Cái ở trên là để theo dõi các gói tin TCP đi ra / vào cổng 80 (web) và cái ở dưới là để theo dõi trọn bộ các gói tin UDP ra / vào bất cứ cổng nào. Trong nháy mắt, hàng loạt các gói tin có vẻ hợp lệ ra vào liên tục trên console theo dõi TCP nhưng vẫn chưa thấy có động tĩnh gì trên console theo dõi UDP. Trong khi chờ đợi anh chàng khởi động, tôi mở tiếp console thứ ba ra và xem lại nội dung cấu hình của firewall. Tôi chợt nghĩ, nếu mình 'ra lệnh' cho netfilter drop hết các UDP packets thay vì để kernel tự động xử lý (triệt tiêu chúng vì chúng chẳng đi về đâu) thì sao? Có một điểm lợi với phương pháp này là mình có thể log (lưu tường trình) -71- để nắm tổng quát biên độ, trường độ và cường độ của dạng tấn công này. Thế nên, tôi tiến hành áp dụng luật này: "hễ có gói tin UDP nào đến firewall, drop nó". Khi tôi chưa kịp hoàn thành dòng lệnh thì đột nhiên trên console thứ nhì dùng để theo dõi UDP packets hiện ra những dòng thông tin vi vút, cực nhanh và cực mạnh. Mỗi gói tin có chiều dài 4000 bytes, gởi đến cổng http (80) bằng giao thức UDP (?) như sau: Code:
10:04:56.067408 IP 83.142.226.77.4233 > www.hvaonline.net.http: UDP, length 4000
10:04:56.067542 IP 78.129.227.6.2123 > www.hvaonline.net.http: UDP, length 4000
10:04:56.067895 IP 83.142.226.78.4650 > www.hvaonline.net.http: UDP, length 4000
10:04:56.068036 IP 78.129.227.6.2117 > www.hvaonline.net.http: UDP, length 4000
10:04:56.069218 IP 83.142.226.78.4661 > www.hvaonline.net.http: UDP, length 4000
10:04:56.069350 IP 83.142.226.77.4231 > www.hvaonline.net.http: UDP, length 4000
10:04:56.069740 IP 78.129.227.6.2125 > www.hvaonline.net.http: UDP, length 4000
Thoạt đầu, chỉ có chừng một chục IP cá biệt "dội" vào HVA nhưng chưa đến một phút sau, có đến khoảng 100 IP cùng tấn công. Mỗi IP này "dội" khoảng trên dưới 100 gói UDP trong một giây. Tôi chỉ kịp lưu nội dung cấu hình firewall và restart nó để ứng hiệu mẩu luật "drop UDP" như đã hình thành ở trên. Ở giai đoạn này, truy cập vào HVA firewall (xuyên qua SSH) bắt đầu trì trệ. Tôi phóng một cái tail để theo dõi firewall log: Code:
[conmale@hva]# tail -f /var/logs/fw.log
và thấy netfilter / iptables đã ứng hiệu. Các UDP packets kia đã bị drop và được lưu trong hồ sơ log. Điều kỳ lạ là tình hình trì trệ không hề thuyên giảm mà gia tăng từ từ. Trong khi đó server load rất thấp với chỉ số dưới 1 -72-. Ngay lập tức, tôi hình dung tình hình khá phức tạp bởi vì đây chính là lối đánh nhằm "saturate" băng thông chớ không phải đánh để gia tăng server load và làm tê liệt hệ thống máy chủ. Vài phút tiếp theo, vận tốc truy cập càng lúc càng tệ. Theo anh chàng chủ bots cho biết thì chỉ có mấy chục con "bots" đang tấn công nhưng theo thống kê trên máy chủ mà tôi nhanh chóng thu thập thì lúc này số IP cá biệt dùng để dội các gói UDP với kích thước 4000 bytes kia lên tới xấp xỉ 200 IP. Đa số, chúng là những IP ở nước ngoài, đặc biệt ở từ Âu châu. Có những IP gởi các gói tin cực nhanh (khoảng 200 UDP packets trong 1 giây); những IP có lẽ có băng thông rất lớn và gần "xa lộ thông tin" nên chúng ập vào cực kỳ dồn dập. Tôi thử tính toán phỏng chừng: 4 (k) x 200 (ip) x 200 (udp) ~ 160Mb 10 (minutes) x 160Mb = 1.6Gb Thử xem: iptables -L -v -n | grep udpdrop Code:
Chain udpdrop(1 references)
 pkts bytes target     prot opt in     out     source               destination
   700156   2.8G LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `UDPDROP: '
Tôi rú lên: "mẹ ơi!" Mới chưa đầy 15 phút (kể từ lúc tôi tái khởi động firewall) mà đã có đến 2.8Gb data đi vào. Tôi gởi thông điệp cho anh chàng chủ nhân "bots" và bảo tạm ngưng để tôi nghiên cứu thêm. Anh chàng đồng ý ngưng nhưng vì lý do gì đó, các gói UDP vẫn hối hả kéo vào. Tôi gởi JAL một e-mail và nói JAL đề nghị đám ISP filter các gói UDP ở router bìa vì không có lý do gì mà UDP lại đến cổng 80 cả. Vài tiếng sau, JAL hồi báo và cho tôi biết rằng đám ISP rất lừng khừng vụ này vì họ ngại cản như thế sẽ ảnh hưởng đến những dịch vụ có thể có những người dùng khác cần. JAL còn bảo rằng, đám ISP doạ họ sẽ.... "nghỉ chơi" nếu tình trạng này kéo dài vì nó tạo ảnh hưởng nặng nề đến những người dùng khác :(. Tôi bóp trán suy nghĩ, cố tìm một giải pháp nào đó cho ổn thoả. Rõ ràng firewall đã drop các UDP packets kia nhưng... drop xong, chúng đi đâu? chúng cần bao lâu để triệt tiêu? chúng còn tồn tại ở chỗ nào khiến cho tình hình cực kỳ trì trệ như thế? UDP là "stateless" protocol, có nghĩa là chúng được gởi đi xong là xong. Gói tin có đến được đích hay không, người gởi không cần biết. Bởi thế, dẫu có cản các gói tin UDP kia, dẫu có block luôn các IP kia, những gói tin vẫn đi vào, xuyên qua router bìa của ISP và đi thẳng đến firewall của HVA mặc dù không đi vào sâu hơn nữa. Ở vị trí này, tình trạng các gói tin UDP thế nào chưa rõ nhưng một chuyện rất rõ là chúng làm trọn bộ đường dẫn bị bão hoà gần như tuyệt đối. Xuất SSH từ máy của tôi với băng thông 10Mbit đến firewall của HVA có băng thông trên 50Mbit (upload) nhưng bị drop liên tục. Ngay cả điều chỉnh QoS -73- trên firewall của HVA cũng không tác dụng mấy. Lúc này, JAL đã SSH vào firewall của HVA và chúng tôi "chat" xuyên qua talk daemon -74-. Tôi bảo JAL rằng tình hình xem ra căng thẳng chớ chẳng đơn giản. Hai anh em trao đổi khá nhiều về tình trạng ứ nghẽn do dạng UDP DDoS mới mẻ này. JAL buộc miệng hỏi: "Sao mình không thử cho chúng vào 'black hole' anh?" Tôi lẩm bẩm: "Black hole, black hole, /dev/null..... " và chợt nhớ ra tôi đã từng thiết lập một cơ chế "/dev/null" này cho firewall của HVA trước đây -75-. Tôi bảo JAL: "Được rồi, để anh. Bây giờ anh đi ngủ, anh quá mệt rồi." Chú thích: -68-: crontab là phương tiện sắp xếp các công tác tự động thực thi theo định kỳ trên *nix. Bản thân crontab là một phương tiện rất tiện lợi nhưng đây cũng là cái "nôi" phát sinh cho sự cố của máy chủ nếu như các giá trị trong crontab không được thiết lập hợp lý (ví dụ có quá nhiều công tác nặng nề cùng xảy ra một lúc, có lỗi trong các scripts thực thi các công tác này nhưng không được tường trình và điều chỉnh đúng mức....). -69-: YIM có lẽ là chat client thông dụng nhất ở VN mặc dù nó có rất nhiều lỗi bảo mật và đã từng làm điêu đứng cộng đồng chatters vì viruses và những "tai nạn" bị mất password... Cá nhân tôi dùng "Pidgin" chạy trên Linux. -70-: source port và destination port là hai giá trị không thể thiếu cho một TCP hoặc UDP packet. Nên tìm đọc cuốn TCP/IP Illustrated để nắm rõ hơn lý do. -71-: cơ chế logging của netfilter / iptables rất chi tiết; nó có thể 'match' bất cứ packet nào mình muốn cản và đồng thời ghi nhận sự xuất hiện của packet ấy với chi tiết thời gian và tính chất của packet. Đây là một tính năng rất quan trọng của netfilter / iptables. Tuy nhiên, nếu sử dụng cơ chế log không hợp lý (log quá nhiều, log quá chi tiết, log quá nhanh....) thì sẽ có khả năng tự tạo "denial of service" cho chính mình. -72-: chỉ số server load đã được đề cập vài lần trong loạt ký sự này. Trên *nix, bạn có thể xem chỉ số tức thời với lệnh w hoặc chỉ số biến đổi bằng top (hoặc topas trên một số hệ điều hành UNIX). -73-: QoS là chữ viết tắt của Quality of Service. Firewall của HVA có ứng dụng một phần cơ chế QoS dựa trên tài liệu "Advanced Linux Routing" ở http://lartc.org/. QoS chủ yếu ấn định ưu tiên cho các loại packets ra vào. Trong đó, SSH được ưu tiên cao nhất. -74-: dịch vụ "talk" trên *nix là một dịch vụ chat xuyên qua console (command line). Nó gọn nhẹ và tiện dụng cho những ai cũng vào một máy chủ và muốn liên lạc với nhau để trao đổi. Dịch vụ này ngày nay hiếm thấy trên các máy chủ. -75-: Bài viết số 4 trong "Ký sự các vụ DDoS vào HVA", tôi đã đề cập đến /dev/null.]]>
/hvaonline/posts/list/25623.html#155387 /hvaonline/posts/list/25623.html#155387 GMT
Ký sự các vụ DDoS đến HVA - Phần 23

conmale wrote:
... Lúc này, JAL đã SSH vào firewall của HVA và chúng tôi "chat" xuyên qua talk daemon -74-. Tôi bảo JAL rằng tình hình xem ra căng thẳng chớ chẳng đơn giản. Hai anh em trao đổi khá nhiều về tình trạng ứ nghẽn do dạng UDP DDoS mới mẻ này. JAL buộc miệng hỏi: "Sao mình không thử cho chúng vào 'black hole' anh?" Tôi lẩm bẩm: "Black hole, black hole, /dev/null..... " và chợt nhớ ra tôi đã từng thiết lập một cơ chế "/dev/null" này cho firewall của HVA trước đây -75-. Tôi bảo JAL: "Được rồi, để anh. Bây giờ anh đi ngủ, anh quá mệt rồi."  
Thế này được không anh? Code:
# iptables -A INPUT -p udp -j DROP > /dev/null 2>&1
]]>
/hvaonline/posts/list/25623.html#155391 /hvaonline/posts/list/25623.html#155391 GMT
Ký sự các vụ DDoS đến HVA - Phần 23

quanta wrote:

conmale wrote:
... Lúc này, JAL đã SSH vào firewall của HVA và chúng tôi "chat" xuyên qua talk daemon -74-. Tôi bảo JAL rằng tình hình xem ra căng thẳng chớ chẳng đơn giản. Hai anh em trao đổi khá nhiều về tình trạng ứ nghẽn do dạng UDP DDoS mới mẻ này. JAL buộc miệng hỏi: "Sao mình không thử cho chúng vào 'black hole' anh?" Tôi lẩm bẩm: "Black hole, black hole, /dev/null..... " và chợt nhớ ra tôi đã từng thiết lập một cơ chế "/dev/null" này cho firewall của HVA trước đây -75-. Tôi bảo JAL: "Được rồi, để anh. Bây giờ anh đi ngủ, anh quá mệt rồi."  
Thế này được không anh? Code:
# iptables -A INPUT -p udp -j DROP > /dev/null 2>&1
 
Hì hì, em nghĩ sao? Được không? Cái > đó sẽ đưa cái gì vào /dev/null? :)]]>
/hvaonline/posts/list/25623.html#155395 /hvaonline/posts/list/25623.html#155395 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155403 /hvaonline/posts/list/25623.html#155403 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155413 /hvaonline/posts/list/25623.html#155413 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155421 /hvaonline/posts/list/25623.html#155421 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 -73-: QoS là chữ viết tắc của Quality of Service. Firewall của HVA có ứng dụng một phần cơ chế QoS dựa trên tài liệu "Advanced Linux Routing" ở http://lartc.org/. QoS chủ yếu ấn định ưu tiên cho các loại packets ra vào. Trong đó, SSH được ưu tiên cao nhất.   Vậy trong trường hợp áp dụng cơ chế QoS, và Server đang trong tình trạng không thể kết nối, hoặc kết nối chậm chạp bằng http, SSH được ưu tiên cao nhất thì ta có thể ssh đến server được không anh? Vì nếu đường dẫn đã bị bão hòa thì ưu tiên hay không có còn là quan trọng nữa không?
Hì hì, em nghĩ sao? Được không? Cái > đó sẽ đưa cái gì vào /dev/null? 
Nó đưa logs vào /dev/null :D, nó sẽ không đưa các UDP packets vào blackhole nữa vì các packets này đã bị drop rồi, tuy bị drop nhưng vẫn làm đường dẫn bị bão hòa, nó không đến được server HVA do bị chặn, nhưng các packets khác vẫn ào ạt đi tới và chờ tới lượt firewall chém mình :D Em đoán giải pháp của anh là không Drop mà cho nó đi thẳng vào, nhưng như thế khác nào mở cổng đón địch? Ngoài ra em cũng giống anh Xnohat thắc mắc làm cách nào mà cu cậu tạo ra được các gói UDP không đầu không đuôi đó, và gởi chúng đi bằng cách nào? ]]>
/hvaonline/posts/list/25623.html#155422 /hvaonline/posts/list/25623.html#155422 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

xnohat wrote:
Cho phép em hỏi một tẹo. Một socket được khởi tạo thì nó cần có tham số là source hay destination port kèm với tham số giao thức cũng như IP, vậy anh bạn kia hẳn phải viết lại cả socket library của trình biên dịch (compiler) thì mới có thể thực hiện một kết nối và gửi một packet đi khi mà không hề tồn tại tham số port đích ( packet đó không biết nó sẽ chạm tới đâu ,tới port nào ). P/s: Nếu có sai chỗ nào thì mọi người góp ý dùm vì mình lâu rồi không còn nguyên cứu chuyên sâu về kĩ thuật nữa, kiến thức cũng rớt dần. 
SOCK_RAW thì chẳng có gì sất. Điều khó hiểu ở đây là tại sao ISP lại có thái độ như vậy về vấn nạn DDoS khi mà lỗi không phải ở phía HVA server? Nói chung nếu mục tiêu của attacker là saturate bandwidth thì khó có thể làm gì nhiều từ phía server, vì ngay cả load ở server có thể cũng không cao nếu drop hết UDP.]]>
/hvaonline/posts/list/25623.html#155423 /hvaonline/posts/list/25623.html#155423 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

xnohat wrote:
Cho phép em hỏi một tẹo. Một socket được khởi tạo thì nó cần có tham số là source hay destination port kèm với tham số giao thức cũng như IP, vậy anh bạn kia hẳn phải viết lại cả socket library của trình biên dịch (compiler) thì mới có thể thực hiện một kết nối và gửi một packet đi khi mà không hề tồn tại tham số port đích ( packet đó không biết nó sẽ chạm tới đâu ,tới port nào ).  
1. Một socket được khởi tạo không cần phải có dst port, src port hay địa chỉ IP. 2. Để gửi raw socket thì không cần phải viết lại gì cả. Tất cả hệ điều hành đều hỗ trợ khả năng này, miễn là bạn có đủ quyền. 3. Các hàm liên quan đến socket không nằm trong trình biên dịch. Nó là một phần của hệ điều hành, có thể ở dạng các syscall hay nằm trong các library đi kèm với hệ điều hành. 4. ICMP là một dạng packet không hề có các tham số port đích. 5. Nếu gửi packet trong cùng một broadcast domain, thì chỉ cần có đúng địa chỉ dst MAC là có thể gửi packet đi đến nơi. Nếu vượt qua ngoài phạm vi broadcast domain, thì cần thêm dst IP là có thể gửi packet đến nơi. Những thông tin khác đều là optional. Trong trường hợp này, kẻ DDoS HVA do chỉ muốn làm ngập lụt đường truyền, nên hắn chỉ cần đưa đúng thông tin dst IP của HVA là xong, chẳng cần quan tâm gì nữa. --m ]]>
/hvaonline/posts/list/25623.html#155427 /hvaonline/posts/list/25623.html#155427 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

BachDuongTM wrote:
em có vài điều băn khoăn ở đây với thiết kế của HVA mình phần firewall, sao lại thực hiện cản lọc chi tiết vậy anh. Điều này có gì đó trái với suy nghĩ của anh về việc thiết kế firewall chỉ cho phép các ứng dụng hợp lệ và loại trừ mọi phần còn lại. vd với UDP, ngoại trừ cho phép kếi nối UDP đến một IP dns nào đó mà ta tin cậy, mọi udp khác cần bị drop. Suy nghĩ của anh về một rule drop null port sẽ mang tính là ứng dụng với tình huống hiện tại chứ chưa phải là cho phép loại trừ tổng quát <sry vì hơi khó diễn đạt >  
ANh nghĩ em đọc bài viết trên chưa kỹ rồi :P . Đây, anh viết:
Tôi tự nhủ: "ngay cả firewall không drop mấy packets bất hợp lệ này thì chúng cũng tự động bị triệt tiêu vì chúng chẳng đi về đâu cả. Thôi, cứ thử nghiệm để xem thêm thế nào." 
và:
Có một điểm lợi với phương pháp này là mình có thể log (lưu tường trình) -71- để nắm tổng quát biên độ, trường độ và cường độ của dạng tấn công này 
Thực tế, FW của HVA drop hết tất cả theo mặc định và sau đó mới cho phép packets vào nếu chúng thỏa mãn những điều kiện ấn định sẵn. Phương pháp loại trừ tổng quát vẫn hiện hữu. Trong tình huống bị DDoS bằng các UDP packets ở đây, nó không còn đơn thuần nằm ở chỗ cản lọc các gói tin nữa. Cũng như anh đã đề cập trong bài viết, phản ứng đầu tiên là nghĩ đến chuyện cản lọc (anh cũng đã nghĩ thế) nhưng điểm lý thú nằm ở đây là việc cản lọc trong trường hợp này không còn tác dụng nữa :).

BachDuongTM wrote:
Em có check thử thấy hva open 3 port là 80 25 và 5555,em nghĩ với các cổng này, chỉ giao thức TCP là được phép truy cập với trạng thái thông thường nhất <đủ port, đủ IP, state hợp lý và rate trong hạn>, mọi giao thức khác cần xóa bỏ.  
Đúng vậy.

BachDuongTM wrote:
More: với một server thường, bảo mật được như HVA là tốt rồi, tuy nhiên em băn khoăn về khả năng HVA chống chịu tấn công phá hoại. Với ví dụ trên ,sao HVA chưa tích hợp thêm firewall phần cứng hoạt động chế độ tranfarent lọc cản các gói tin không hợp lệ trước khi đi vào HVA server với firewall iptables. Cụ thể anh đã phải nhờ vào can thiệp của ISP để cản lọc ở phần router và hầu hết các tác vụ cản loại thực hiện ở OS <và cho dù như vậy, hva vẫn hoạt động thật tuyệt vời.> 
Firewall phần cứng đã từng được thử nhưng chịu không thấu khi bị DDoS nên đã bỏ ra. Anh phải nhờ vào sự can thiệp của ISP để lọc các gói UDP trên router bìa của họ nhưng thực tế, chuyện này không xảy ra vì họ không muốn làm như thế. Giả sử mình có thêm 1 firewall nằm bên ngoài nữa, liệu mình có khắc phục được tình trạng bị DDoS như trên, thuần túy do cản lọc hay không? Em đọc lại bài viết thật kỹ để tìm thấy cái hướng anh đang khai triển ra cho bài kế tiếp. Nhắc lại: cản lọc không có hiệu quả gì cả trong trường hợp này.]]>
/hvaonline/posts/list/25623.html#155437 /hvaonline/posts/list/25623.html#155437 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

mrro wrote:
2. Để gửi raw socket thì không cần phải viết lại gì cả. Tất cả hệ điều hành đều hỗ trợ khả năng này, miễn là bạn có đủ quyền.  
Có lẽ bác cần xem lại điểm này. Windows XP SP2 và các hệ điều hành mới hơn của MS không còn cho phép tạo và gửi raw socket nữa.]]>
/hvaonline/posts/list/25623.html#155443 /hvaonline/posts/list/25623.html#155443 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 trình biên dịch. tớ biết ở đây có vài bạn đã viết hẳn một device driver cho Windows để tự gửi raw socket mà không cần thông qua các hàm mà hệ điều hành cung cấp. -m PS: tớ chưa sử dụng nên chưa biết nhưng có vẻ WinPCAP có thể gửi raw socket mà không bị giới hạn gì cả.]]> /hvaonline/posts/list/25623.html#155446 /hvaonline/posts/list/25623.html#155446 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

conmale wrote:
Giả sử mình có thêm 1 firewall nằm bên ngoài nữa, liệu mình có khắc phục được tình trạng bị DDoS như trên, thuần túy do cản lọc hay không? Em đọc lại bài viết thật kỹ để tìm thấy cái hướng anh đang khai triển ra cho bài kế tiếp. Nhắc lại: cản lọc không có hiệu quả gì cả trong trường hợp này. 
Thật lý thú. Nếu vấn đề không phải do cản lọc thì có thêm firewall nữa cũng vô ích. Đang tò mò giải pháp /dev/null của bác conmale. Nếu chủ đích của kẻ tấn công là làm bão hòa đường truyền của bác conmale thì giải pháp này có được hiệu quả gì vì dầu sao packet cũng phải đến được server rồi mới bị xử lý.]]>
/hvaonline/posts/list/25623.html#155463 /hvaonline/posts/list/25623.html#155463 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 bất hợp lệ đi vào, và đi qua thật nhanh. Các gói UDP đó không có ảnh hưởng gì cho hệ thống mà mình lại phải tốn thời gian filter -> input queue có thể bị đầy. Nếu có thể (sử dụng blackhole như anh nói) đưa các gói tin bất hợp lệ đi qua thật nhanh mà không cần process nó thì có thể free một chút băng thông làm việc khác. khoai]]> /hvaonline/posts/list/25623.html#155552 /hvaonline/posts/list/25623.html#155552 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

Mr.Khoai wrote:
Anh conmale, Vẫn đang tò mò chờ xem anh implement cái blackhole bằng iptables như thế nào. Em chưa có dịp thử, nhưng đoán là anh dùng PREROUTE để đưa các gói không hợp lệ vào localhost port nào đó có /dev/null ? Em nghĩ giải pháp cho tình trạng này là thay vì filter traffic thì nên để mấy gói tin bất hợp lệ đi vào, và đi qua thật nhanh. Các gói UDP đó không có ảnh hưởng gì cho hệ thống mà mình lại phải tốn thời gian filter -> input queue có thể bị đầy. Nếu có thể (sử dụng blackhole như anh nói) đưa các gói tin bất hợp lệ đi qua thật nhanh mà không cần process nó thì có thể free một chút băng thông làm việc khác. khoai 
Hì hì, em đoán đúng đó. Em có thể phân tích thêm lý do tại sao em nghĩ rằng mình phải "đưa các gói không hợp lệ vào localhost port nào đó" mà không phải là /dev/null (như một device bình thường)?]]>
/hvaonline/posts/list/25623.html#155580 /hvaonline/posts/list/25623.html#155580 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 The difference between iptables DROP and null-routing http://www.tummy.com/journals/entries/jafo_20060727_140652 Trong bài viết, tác giả cũng viết khá rõ ràng, rằng nếu sử dụng iptables thì hệ thống ít nhất cần so sánh các tham số như ip gói tin, loại gói tin, port ,.... trong khi nếu sử dụng route null thì chỉ cần thông số duy nhất là IP mà thôi. Nhưng có 2 vấn đề trở ngại là : - phải biết đích xách IP nguồn gửi, vấn đề này tưởng dễ mà không dễ nếu như chúng ta bị 1000 host tấn công một lúc - gói tin cần qua iptables trước khi được route, phải chăng cần stop iptables để xuống thẳng firewall ?? hoặc tệ hơn chút là iptables chỉ check ip và accept ngay khi có IP nguồn hợp lệ <trùng với ip block> để cho nó xuống thẳng route và nhét vô route null. Cho dù vậy, xét thấy nó vẫn cứ thế nào ấy, ít nhất vẫn cần iptables check IP nguồn rồi route lại check tiếp ip nguồn, 2 lần check. Thực ra kỹ thuật này không có cái gọi là /dev/null để redict gói tin đâu. ;) ]]> /hvaonline/posts/list/25623.html#155691 /hvaonline/posts/list/25623.html#155691 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

BachDuongTM wrote:
Em có đọc qua tài liệu về route null, cụ thể có link minh họa ở đây The difference between iptables DROP and null-routing http://www.tummy.com/journals/entries/jafo_20060727_140652 Trong bài viết, tác giả cũng viết khá rõ ràng, rằng nếu sử dụng iptables thì hệ thống ít nhất cần so sánh các tham số như ip gói tin, loại gói tin, port ,.... trong khi nếu sử dụng route null thì chỉ cần thông số duy nhất là IP mà thôi. Nhưng có 2 vấn đề trở ngại là : - phải biết đích xách IP nguồn gửi, vấn đề này tưởng dễ mà không dễ nếu như chúng ta bị 1000 host tấn công một lúc - gói tin cần qua iptables trước khi được route, phải chăng cần stop iptables để xuống thẳng firewall ?? hoặc tệ hơn chút là iptables chỉ check ip và accept ngay khi có IP nguồn hợp lệ <trùng với ip block> để cho nó xuống thẳng route và nhét vô route null. Cho dù vậy, xét thấy nó vẫn cứ thế nào ấy, ít nhất vẫn cần iptables check IP nguồn rồi route lại check tiếp ip nguồn, 2 lần check. Thực ra kỹ thuật này không có cái gọi là /dev/null để redict gói tin đâu. ;)  
:). Tài liệu em cho ở trên có vài điểm khá lý thú. Nó có điểm tương đồng với cách khai triển của mình ở đây là ở chỗ: nó nhận ra được "over head" quá lớn cho iptables / netfilters phải đối diện với hoàn cảnh đang bị DDoS nên phải dùng một giải pháp nào đó để đưa đến việc triệt tiêu các packets ở mức hiệu suất nhất và giảm nhẹ gánh nặng của hệ thống phòng thủ nhất (kể cả firewall, routing, IDS....). Tuy nhiên có một điểm tối quan trọng trong giải pháp trên ở: Code:
ip route add $REMOTEADDRESS via 127.0.0.1
nó không thật sự gởi gói tin vào "black hole" mà nó chỉ định tuyến gói tin đi vào loopback. Bởi vì các gói tin trong bài viết trên là TCP chớ không phải UDP nên nó có thể vô hiệu hóa được một phần dung hại bằng cách định tuyến gói tin vào loopback và không trả lời gì cả cho nên TCP connection không thể hình thành (3-way handshake thông thường). Tuy nhiên, đối với UDP, cách này không giải quyết được vấn nạn bởi vì các gói UDP có kích thước lớn cứ tiếp tục ào ạt đi vào, chúng sẽ về đâu? :). Chưa kể là đòi hỏi khá "tricky" là phải biết source IP đang tấn công thì mới thực thi được ip route. Hơn nữa, 4000, 5000 IP tấn công liên tục thì làm sao theo dõi mà thêm, bớt trong routing table? và routing table có đến mấy ngàn route thì.... chết giấc :P Thân.]]>
/hvaonline/posts/list/25623.html#155695 /hvaonline/posts/list/25623.html#155695 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

conmale wrote:
Hì hì, em đoán đúng đó. Em có thể phân tích thêm lý do tại sao em nghĩ rằng mình phải "đưa các gói không hợp lệ vào localhost port nào đó" mà không phải là /dev/null (như một device bình thường)? 
Em chỉ không nghĩ ra cách gì wwwect dữ liệu đi vào network device sang một device khác (ở đây là /dev/null). Nhưng iptables có thể wwwect traffic sang một interface khác nhờ cơ chế NAT. Do đó em nghĩ mình có thể tạo một process nào đó, lắng nghe trên localhost port 12345 udp. Sau đó dùng iptables rules, match các udp rules hợp lệ. Còn các gói udp khác thì cứ đưa nó vào localhost:12345. Cái process đang LISTEN trên localhost:12345 có thể đưa dữ liệu vào /dev/null. Ví dụ Code:
$ nc -l -p 12345 -u -e /dev/null
khoai]]>
/hvaonline/posts/list/25623.html#155707 /hvaonline/posts/list/25623.html#155707 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

Mr.Khoai wrote:

conmale wrote:
Hì hì, em đoán đúng đó. Em có thể phân tích thêm lý do tại sao em nghĩ rằng mình phải "đưa các gói không hợp lệ vào localhost port nào đó" mà không phải là /dev/null (như một device bình thường)? 
Em chỉ không nghĩ ra cách gì wwwect dữ liệu đi vào network device sang một device khác (ở đây là /dev/null). Nhưng iptables có thể wwwect traffic sang một interface khác nhờ cơ chế NAT. Do đó em nghĩ mình có thể tọa một process nào đó, lắng nghe trên localhost port 12345 udp. Sau đó dùng iptables rules, match các udp rules hợp lệ. Còn các gói udp khác thì cứ đưa nó vào localhost:12345. Cái process đang LISTEN trên localhost:12345 có thể đưa dữ liệu vào /dev/null. Ví dụ Code:
$ nc -l -p 12345 -u -e /dev/null
khoai 
Hay lắm. Dùng netcat để tạo một listening service và cho nội dung (netcat nhận) vào /dev/null cũng là một cách rất hay :). Dùng netfilter / iptables để wwwect packets đến một socket (mà netcat tạo ra) để rồi packet đó đi vào /dev/null là hoàn toàn khả thi. Cách anh làm gần giống nhưng... more resilient (bền hơn) ở chỗ, anh dùng một service có sẵn và nó được xinet daemon điều tác :P Hì hì, bàn một hồi sẽ lộ ra những điều có trong bài viết tới mất :P Thân.]]>
/hvaonline/posts/list/25623.html#155710 /hvaonline/posts/list/25623.html#155710 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155711 /hvaonline/posts/list/25623.html#155711 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

BachDuongTM wrote:
hi hi Xem ra Mr Khoai gần tìm được ra đáp án rồi. Rõ ràng các làm này tối ưu hơn nhiều so với route null rồi. Em chỉ còn chút thắc mắc về việc xử lý với 1000 IP 1 lúc, rõ ràng để lập nên list các ip là một việc khó,lưu lại và kiểm tra list IP này với delay nhỏ nhất chắc còn nhiều việc để phải suy nghĩ sâu nữa.Không biết anh commale có thể gợi ý chút xíu gì không Em đề nghị dừng thảo luận về giải pháp ở đây, để có anh commale còn vốn viết tiếp hồi sau nhỉ :P :P  
Điều lý thú (và hy vọng ích lợi) nằm ở chỗ suy gẫm, phân tích và thảo luận sau khi đọc một bài viết nào đó :). Bởi thế, càng thảo luận nhiều (sau khi suy gẫm và phân tích) càng tốt. Mr. Khoai "đẩy" đến chỗ dùng netcat để đưa packet vào /dev/null theo dạng đã đưa ra ở trên là một gặt hái rất lớn trong việc thảo luận. Tiếc là Mr. Khoai chưa giải thích tại sao một packet đi vào xuyên qua một socket không thể wwwect vào một device như /dev/null :P . Khai triển ngọn ngành điểm này thì mức độ lãnh hội về internet socket, unix socket, devices và filesystem sẽ đi đến chỗ chín mùi.]]>
/hvaonline/posts/list/25623.html#155722 /hvaonline/posts/list/25623.html#155722 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155748 /hvaonline/posts/list/25623.html#155748 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#155752 /hvaonline/posts/list/25623.html#155752 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

Ky0shir0 wrote:
Có một điều làm em thắc mắc: tại sao bác admin lại mang vấn đề này ra thảo luận và lại mong muốn mọi người hiểu rõ bản chất của vấn đề nhỉ? Có lợi gì và có hại gì cho chính bác và cho actker? 
Nhiều chứ. Mọi người có kiến thức, bác conmale viết lại để về sau có gì "lú lẫn" còn có cái case study mà nhớ chứ. :D. Cái này gọi là win-win mà :P]]>
/hvaonline/posts/list/25623.html#155754 /hvaonline/posts/list/25623.html#155754 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

anh conmale wrote:
Mr. Khoai "đẩy" đến chỗ dùng netcat để đưa packet vào /dev/null theo dạng đã đưa ra ở trên là một gặt hái rất lớn trong việc thảo luận. Tiếc là Mr. Khoai chưa giải thích tại sao một packet đi vào xuyên qua một socket không thể wwwect vào một device như /dev/null smilie . Khai triển ngọn ngành điểm này thì mức độ lãnh hội về internet socket, unix socket, devices và filesystem sẽ đi đến chỗ chín mùi. 
Hix, khổ ghê, lần nào thảo luận gì đó với anh đều tìm ra cả đống thứ phải học. Em vẫn không thể giải thích tại sao không thể wwwect network traffic vào /dev/null, mà phải wwwect đến một socket. Theo em nghĩ, netfilter được iptables điều khiển. Tuy nhiên iptables và netfilter không cung cấp một công cụ nào đó để mình wwwect dữ liệu sang một device khác. Netfilter có thể wwwect network traffic sang một socket khác (một IP : PORT khác) nên em nghĩ đến cách đó. Hy vọng trong bài tiếp theo, hoặc một bài nào đó, anh sẽ giới thiệu hoặc giải thích phần trên một cách rõ ràng. Ky0shir0, Điểm quan trọng ở đây khoai nghĩ là anh conmale muốn phổ biến kiến thức và tạo môi trường thảo luận trên diễn đàn. Không thể dựa vào điểm các attacker không biết mình implement cơ chế bảo mật thế nào để rồi nghĩ là mình sẽ không bị tấn công. Đọc mấy bài này y như coi phim/đọc truyện kiếm hiệp :D khoai]]>
/hvaonline/posts/list/25623.html#155796 /hvaonline/posts/list/25623.html#155796 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

Mr.Khoai wrote:
Hix, khổ ghê, lần nào thảo luận gì đó với anh đều tìm ra cả đống thứ phải học. Em vẫn không thể giải thích tại sao không thể wwwect network traffic vào /dev/null, mà phải wwwect đến một socket. Theo em nghĩ, netfilter được iptables điều khiển. Tuy nhiên iptables và netfilter không cung cấp một công cụ nào đó để mình wwwect dữ liệu sang một device khác. Netfilter có thể wwwect network traffic sang một socket khác (một IP : PORT khác) nên em nghĩ đến cách đó. Hy vọng trong bài tiếp theo, hoặc một bài nào đó, anh sẽ giới thiệu hoặc giải thích phần trên một cách rõ ràng.  
Khỏi cần đợi bài nào khác, tán thêm một tí về internet socket, unix domain socket và /dev/null ở đây luôn cho tiện :P. - /dev/null là gì? nó là một thứ "device" trên *nix. "Device" này đặc biệt ở chỗ những thông tin nào ra vào từ stdin và stdout đều có thể được wwwect đến nó và sẽ.... ra đi vĩnh viễn. Data từ stdin và stdout là các chuỗi (stream) thông tin gởi và chuyển từ một hoặc nhiều process (tiến trình) đi vào /dev/null này sẽ chấm dứt tại đây. Ví dụ, lệnh: Code:
ls -a > /dev/null
cho ta: ls -a: là stdin (được gõ trên console), sau khi nhấn "enter", stdin này được tiến trình "ls" xử lý và liệt kê tất cả những gì có trên thự mục hiện tại. Những gì được hiển thị là những thứ thuộc về stdout. >: là "wwwection" hoặc "chuyển đến". /dev/null: là device đặc biệt trên. Bởi thế những gì xảy ra trên console giữa các tiến trình đều có thể được > vào /dev/null. - internet socket là gì? nó là một thứ "ổ cắm" trên hầu hết các hệ điều hành hiện đại có ứng dụng TCP/IP. Nó hình thành bởi vì việc gởi và chuyển data từ stdin và stdout xuyên qua các tiến trình giữa các máy ở xa nhau (không phải là máy cục bộ) là việc không thể thực hiện được. Internet socket được tạo ra để chuyên chở thông tin từ điểm này sang điểm kia, xuyên qua những cái ống (socket connections). Khi data đi đến đầu nhận được, tiến trình chịu trách nhiệm tạo ống (socket) mới nhận dữ liệu và chuyển chúng đến các tiến trình khác hoặc các tiến trình con để... làm gì thì làm. Ví dụ, data của một UDP packet đi từ host A đến host B được "gói" lại ở dạng: Host A -- > stdin --> tiến trình --> stdout --> gói tin --> socket --> Host B --> socket --> gói tin --> stdin --> tiến trình --> stdout. Bởi thế, thông tin đi từ host A đến host B không thể ở dạng thuần túy "chuỗi data" như giữa các stdin và stdout mà được "encapsulated" thành các "gói" rồi mới gởi xuyên qua socket. Đầu nhận phải "mở gói" ra, phải lấy cái gì trong gói ra thì mới có được data. - unix domain socket là gì? là một thứ "ổ cắm" ảo chỉ xảy ra trên máy cục bộ. Các chuỗi data được gởi nhận xuyên qua bộ phận memory của kernel. Chúng là data ở dạng chuỗi có thể được đưa vào /dev/null như data trên stdin và stdout. Tương tự như trên nhưng nó không "encapsulated" gói và không đi xuyên qua internet socket và chỉ xảy xa trên máy cục bộ.

Mr.Khoai wrote:
Ky0shir0, Điểm quan trọng ở đây khoai nghĩ là anh conmale muốn phổ biến kiến thức và tạo môi trường thảo luận trên diễn đàn. Không thể dựa vào điểm các attacker không biết mình implement cơ chế bảo mật thế nào để rồi nghĩ là mình sẽ không bị tấn công. Đọc mấy bài này y như coi phim/đọc truyện kiếm hiệp :D khoai 
Những kiến thức căn bản về stdin, stdout, /dev/null, internet socket, unix domain socket..... nếu đọc sách một lần không nắm thì đọc vài lần cũng nắm. Tuy nhiên, điểm quan trọng nhất là ứng dụng chúng như thế nào cho ích lợi. Trong trường hợp HVA đang bị UDP flood và được biết rằng cản lọc chúng theo dạng -j DROP trên iptables không đủ để giải tỏa tình trạng trì trệ nên mới dẫn đến suy nghĩ làm sao giải tỏa chúng nhanh hơn và ít tốn tài nguyên hơn. Từ đó mới nảy ra chuyện cho chúng vào /dev/null. Ích lợi của sự ứng dụng ở đây đi từ suy luận và vận dụng kiến thức căn bản ở trên. Ví dụ: 1. UDP packet đi vào quá nhiều, quá nhanh, làm trì trệ đường truyền. 1.1 Cản --> không hiệu quả vì vẫn trì trệ. 1.2 Cho vào /dev/null? 2. Cho vào /dev/null thế nào? 2.1 Một UDP packet đi vào sẽ có diễn tiến như phần màu đỏ ở trên, vậy, /dev/null nó ở đâu? 2.2 Cần một tiến trình để "mở gói" UDP này thành data như stdout trước khi cho vào /dev/null? Tại sao? Tại sao không? 2.3 Không cần một tiến trình để "mở gói" UDP này nữa mà cho nó vào một cái gì đó tương tự như /dev/null? Tại sao? Tại sao không? 3. Ứng dụng thế nào trong hoàn cảnh đang chạy trên Linux, đang dùng netfilter, đang có thể sử dụng iproute, đang có thể sử dụng netcat, đang có thể sử dụng vài network sockets khác để thực hiện ý muốn? Mỗi điểm trên cần suy xét và cân nhắc để đưa đến quyết định cuối, quyết đinh này có thể chưa hẳn là quyết định tốt nhất trong mọi tình huống nhưng có thể tốt nhất với tình huống hiện tại. Nói về mặt "mở rộng" thảo luận khiến cho attacker lợi dụng tiếp tục tấn công thì việc này đã và đang xảy ra với HVA. Cái khó nằm ở chỗ không giấu, vẫn chia sẻ, vẫn mở rộng, vẫn ứng dụng được mà kẻ tấn công không thể lợi dụng để làm gì khác. Đây cũng là một trong những điểm phải... "hy sinh" để rộng đường thảo luận vậy :P .]]>
/hvaonline/posts/list/25623.html#155908 /hvaonline/posts/list/25623.html#155908 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

Mr.Khoai wrote:
Đọc mấy bài này y như coi phim/đọc truyện kiếm hiệp :D khoai 
Nói mà cứ như là đúng rồi đấy -:|- . Bản thân em thì cũng rất thích 'Truyện' của anh commale.

commale wrote:
Nói về mặt "mở rộng" thảo luận khiến cho attacker lợi dụng tiếp tục tấn công thì việc này đã và đang xảy ra với HVA. Cái khó nằm ở chỗ không giấu, vẫn chia sẻ, vẫn mở rộng, vẫn ứng dụng được mà kẻ tấn công không thể lợi dụng để làm gì khác. Đây cũng là một trong những điểm phải... "hy sinh" để rộng đường thảo luận vậy :P . 
Câu này hay quá ;) . Mỗi dòng của anh là một 'cục' tài liệu em chưa biết :-( .]]>
/hvaonline/posts/list/25623.html#155924 /hvaonline/posts/list/25623.html#155924 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 tcpdump khi bị tấn công đem về nhà phân tích thì quá tốt :) ]]> /hvaonline/posts/list/25623.html#155985 /hvaonline/posts/list/25623.html#155985 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

Giang Hồ Mạng wrote:
Trong các ký sự của đại ca con ma le lé (đừng lấy dép chọi u đầu em) :D nếu anh trai cho đám nhỏ, đàn em như em file tcpdump khi bị tấn công đem về nhà phân tích thì quá tốt :)  
Hi nếu như có file đó rùi, cần chi nữa không ? file config firewall nha ? Thực ra mình kô nghĩ điều đó là cần thiết, vì Mr Commale cũng miêu tả rõ ràng rồi mà. Hơn nữa, sao bạn không thử chơi cờ tưởng nhỉ, hacker là mình thì sẽ DDOS nè, rồi mình sẽ chống thế này nè -:-) -:-) Ask for more hay Deep thinking ]]>
/hvaonline/posts/list/25623.html#155999 /hvaonline/posts/list/25623.html#155999 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 Giang Hồ Mạng, Dump file chắc là không cho được đâu. Những thông tin trong dump file quá nhiều, filter ra hết các thông tin quan trọng và cá nhân là rất mất thời gian. Anh conmale, Xin phép nói thêm để phân biệt unix và internet socket. Chúng giống nhau ở điểm đều thuộc vào loại socket. Nghĩa là dữ liệu đi vào/ra không phải dạng raw, mà đã qua các công đoạn chế biến (encapsulation). Unix socket được ứng dụng để các process khác nhau trên cùng một máy có thể nói chuyện với nhau--tương tự như khi hai process nằm trên hai máy khác nhau vậy. Khi process nhận dữ liệu từ các sockets, nó không hề quan tâm việc làm sao chuyển raw bits/bytes từ đầu này qua đầu kia socket. Lợi dụng điểm đó, Unix socket giúp cho việc implement Inter-Process Communication được thuận tiện hơn--y chang như khi đọc hoặc ghi dữ liệu vào một socket thông thường. Về việc vì sao iptables không thể trực tiếp wwwect input stream vào /dev/null, em hiểu như sau: Bình thường, khi ta dùng issue một "lệnh" trong shell (ví dụ là bash) thì chính bash sẽ làm việc quản lý process đó. Việc quản lý đó bào gồm open các file chính: stdin, stdout và stderr cho process đó. Với stdin, bash sẽ open device là keyboard, stdout và stderr là màn hình chẳn hạn. Bản thân process đó không trực tiếp động đến các device này mà chỉ tương tác với chúng thông qua các discriptors 0, 1, 2 mà thôi. Việc open device và "gắn" device vào file discriptors của process xảy ra trước khi process con được tạo và được chạy. Khi ta có wwwection, chính bash không open monitor, mà lại open /dev/null rồi mới wwwect dữ liệu vào đây. Điều này xảy ra tương tự như khi wwwect vào file, hay vào một process khác. Vì sao iptables không thể "wwwect" input stream vào /dev/null bằng các cách như >, hoặc pipe vân vân? Lý do là iptables không cung cấp cho mình một interface để tương tác với /dev/null, và, input stream không thể ra vào trực tiếp trên các file stdin, stdout và stderr. Mình có thể chạy iptables bằng bash (script), và khi sử dụng các ký tự đặc biệt này thì chính bash sẽ open stdin, stdout, và stderr, rồi chính bash sẽ lo vụ wwwect. iptables khi nhận một gói tin sẽ open các files khác (socket, cho wwwect, hoặc /dev/eth1 nếu đang làm gateway chẳng hạn) và "wwwect" gói tin đến file đó. Giả sử iptables có một target là -j NULL, ta có thể wwwect input stream trực tiếp từ socket vào /dev/null. Lúc này, chính iptables sẽ open /dev/null và tiến hành write dữ liệu vào đó. Việc hack netfilter và iptables để làm việc này thì không phải không làm được. Nhưng mình có thể sử dụng một cách khác để đạt kết quả tương tự. khoai]]> /hvaonline/posts/list/25623.html#156003 /hvaonline/posts/list/25623.html#156003 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

BachDuongTM wrote:
Hi nếu như có file đó rùi, cần chi nữa không ? file config firewall nha ? Thực ra mình kô nghĩ điều đó là cần thiết, vì Mr Commale cũng miêu tả rõ ràng rồi mà. Hơn nữa, sao bạn không thử chơi cờ tưởng nhỉ, hacker là mình thì sẽ DDOS nè, rồi mình sẽ chống thế này nè -:-) -:-) Ask for more hay Deep thinking  
Giang hồ có nói 1 câu thế này “Biết thì nói , không biết thì dựa cột mà nghe đừng phát biểu linh tinh” :) ]]>
/hvaonline/posts/list/25623.html#156004 /hvaonline/posts/list/25623.html#156004 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

Mr.Khoai wrote:
... Vì sao iptables không thể "wwwect" input stream vào /dev/null bằng các cách như >, hoặc pipe vân vân? Lý do là iptables không cung cấp cho mình một interface để tương tác với /dev/null, và, input stream không thể ra vào trực tiếp trên các file stdin, stdout và stderr. Mình có thể chạy iptables bằng bash (script), và khi sử dụng các ký tự đặc biệt này thì chính bash sẽ open stdin, stdout, và stderr, rồi chính bash sẽ lo vụ wwwect. iptables khi nhận một gói tin sẽ open các files khác (socket, cho wwwect, hoặc /dev/eth1 nếu đang làm gateway chẳng hạn) và "wwwect" gói tin đến file đó.  
Đúng vậy. Hay nói một cách khác, iptables / netfilter chỉ làm việc với IP (internet socket) và cho đến lúc này, hoàn toàn không có cách gì để đưa một packet mà iptables có thể kiểm soát từ socket sang một unix device được.

Mr.Khoai wrote:
Giả sử iptables có một target là -j NULL, ta có thể wwwect input stream trực tiếp từ socket vào /dev/null. Lúc này, chính iptables sẽ open /dev/null và tiến hành write dữ liệu vào đó. Việc hack netfilter và iptables để làm việc này thì không phải không làm được. Nhưng mình có thể sử dụng một cách khác để đạt kết quả tương tự. khoai 
Lúc trước có một tay đã thử viết NULL module cho netfilter nhưng đám netfilter chính thức không tiếp nhận vì lý do gì đó nên vụ này chìm luôn. Nếu anh nhớ không lầm, cách ứng dụng NULL module đó không wwwect vào /dev/null mà nó chỉ đơn giản tiếp nhận và xóa packet đó cũng tương tự như /dev/null nhưng thuần túy xử lý ngay trên netfilter. Có một số bàn cãi về sự giống và khác nhau giữa -j DROP và -j NULL trước đây nhưng chưa ngã ngũ. Có lẽ trọng tâm của netfilter hoàn toàn xoáy vào IP chớ không đi ra ngoài khuôn khổ ấy. Không biết về sau sẽ như thế nào. to Giang Hồ Mạng: những thông tin cần thiết và trọng tâm nhất thì anh đã trình bày rồi nên nếu có mấy cái dump file đó cũng không để làm gì đâu em. Vả lại, những dump file này có thể có những thông tin nhạy cảm nên anh không thể "share" một cách rộng rãi được. Thân.]]>
/hvaonline/posts/list/25623.html#156022 /hvaonline/posts/list/25623.html#156022 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 Code:
ip route x.x.x.x x.x.x.x null0
]]>
/hvaonline/posts/list/25623.html#157352 /hvaonline/posts/list/25623.html#157352 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

dabu wrote:
Cho em chen ngang chút : Trong router cisco có phải dủng câu lệnh này phải kô ạ: Code:
ip route x.x.x.x x.x.x.x null0
 
Để làm chi em?]]>
/hvaonline/posts/list/25623.html#157370 /hvaonline/posts/list/25623.html#157370 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23

conmale wrote:

dabu wrote:
Cho em chen ngang chút : Trong router cisco có phải dủng câu lệnh này phải kô ạ: Code:
ip route x.x.x.x x.x.x.x null0
 
Để làm chi em? 
Để chuyển tất cả traffic từ một IP nào đó hoặc một range ip nào đó [range ip này hoặc ip này đang DoS đến HVA bằng những gói UDP], vào một interface ảo null để làm giảm độ xử lý[performance] của router đến mức tối đa. p/s : Còn vấn đề anh đang bàn với Mr.Khoai là để wwwect vào "device" /dev/null dựa trên tầng mấy của mô hỉnh OSI, iptables làm việc ở tầng nào ? dạng dữ liệu stream/ socket khác nhau thế nào? tiếp nhận dòng dữ liệu stream này phải làm gì? :) Đó là mớ "kiến thức" em lụm được qua topic này. :) ]]>
/hvaonline/posts/list/25623.html#157375 /hvaonline/posts/list/25623.html#157375 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#157625 /hvaonline/posts/list/25623.html#157625 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#157690 /hvaonline/posts/list/25623.html#157690 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23

lQ wrote:
hi anh conmale, ngoài việc bị flood đường truyền, hình như công đoạn log của iptables cũng làm cho server load cao. Phải vậy ko anh? 
Đúng vậy em. Log càng chi tiết, càng nhanh thì càng "mệt" cho server. Đây là tình trạng còn gọi là "tự từ chối dịch vụ" (self denial of service). Chẳng những thế, nếu kích thước gia tăng quá nhanh và quá nhiều thì có thể dẫn đến tình trạng hết chỗ chứa (hầu hết các *nix server được tạo mount point / chung cho mọi thứ) và dẫn đến chỗ server tê liệt.]]>
/hvaonline/posts/list/25623.html#157741 /hvaonline/posts/list/25623.html#157741 GMT
Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#157953 /hvaonline/posts/list/25623.html#157953 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#158144 /hvaonline/posts/list/25623.html#158144 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 tranhuuphuoc: Logs trên HVA hoàn toàn dùng cơ chế logrotation. Có lẽ em sẽ không tin rằng việc "process logs / check logs" hoàn toàn làm bằng... tay :P . Mỗi tuần anh kiểm tra logs 3 lần và ghi chú những điểm cần quan tâm. Công cụ chỉ là sed, awk, cat, grep :P . lQ: HVA đã trải qua một.. "kinh nghiệm đau thương" hồi 2006. Khi đó, do bị DDoS liên tục và do cần phải logs đầy đủ để theo dõi và khắc phục, HVA bị lâm vào tình trạng... hết chỗ chứa vì logs quá nhiều và quá nhanh. Điều này gây nên một hậu hoạn kinh khủng đó là không còn chỗ để backup DB. Khi đó anh mắc dọn nhà nên không thể truy cập HVA mấy ngày, còn ku JAL thì về VN làm đám hỏi, đám dạm gì đó. Các backup cũ của DB bị xóa theo tuần tự (cũ hơn thì xóa), trong khi đó các backup mới tự động tạo ra thì không tạo được vì không còn chỗ trên disk. Rút kinh nghiệm, backup của DB giờ đây nằm trên một disk hoàn toàn riêng biệt và được copy offline theo định kỳ. Riêng chuyện điều chỉnh FW để chống cự với DDoS là chuyện không thể tránh khỏi được. Mỗi dạng DDoS đặc biệt đều cần phải phân tích và tìm giải pháp thích hợp; không hề có chuyện "set and forget" cho bảo mật, đặc biệt đối với DDoS :). Thân.]]> /hvaonline/posts/list/25623.html#158601 /hvaonline/posts/list/25623.html#158601 GMT Re: Ký sự các vụ DDoS đến HVA - Phần 23 /hvaonline/posts/list/25623.html#160106 /hvaonline/posts/list/25623.html#160106 GMT