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:



Đoạn cuối bảng "help" hiện ra mồn một:
Code:



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:


và:
Code:



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:



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:


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:



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.