MrHói's Blog

Kiểm tra header để tìm ra nguyên nhân cụ thể của các vụ tấn công.

Phân tích (tiếp theo)

Tối 11/10

Tôi gởi PM cho lão JAL để “hít” thêm ít gói tin, lần này tôi nắm chắc phải có vài megabytes packets để nghịch. Không lâu sau đó, tôi nhận được hồi đáp từ JAL thông báo các mảnh packets đã có sẵn trên server. Tôi log vào HVA server và tải chúng xuống. Hăm hở mở đoạn “hit” thứ nhất, tôi rà xuyên qua trọn bộ các gói tin bắt được trong nhóm thứ nhất để tìm một dấu hiệu nổi bật và những dấu hiệu nào có liên quan đến đoạn payload của HTTP POST ở trên. Quá nhiều! có quá nhiều “stream” -7-

Code:

-8- HTTP trong đó. Sở dĩ chúng ta có 2 mảnh “continuation” vì content-length có chiều dài đến 2205 bytes, quá lớn để khít vào một MTU -9- và nó phải gói trong gói tin tcp ACK,PSH vì nó muốn 2 mảng thông tin này đến HVA server càng nhanh càng tốt (càng nhanh thì HVA server càng mau chết). Sau cùng là cái đuôi RST (hiển thị trên hình là [TCP ZeroWindow].

Nhìn xuyên qua thì mọi sự có vẻ như hợp lệ nhưng xét cho kỹ thì tại sao cái “stream” này lại kết thúc bằng RST thay vì FIN? Hơn nữa, sau khi hoàn tất mảng “continuation” thứ nhì thuộc sequence 240 (xem cột trong cùng bên tay trái), mãi đến sequence thứ 1154 mới gởi RST packet đến HVA server? Điều này có nghĩa HVA server phải “ngóng chờ” cho đến khi nguồn tin từ IP này tiếp tục ra hiệu, nếu không thì server sẽ đợi cho đến khi “time out”. Đợi đến lúc “time out” hay đợi đến sau gần 1000 sequence khác rồi mới gởi 1 cái RST thì cũng không khác gì nhiều cho lắm (đặc biệt kernel trên HVA server được chỉnh sẵn TCP time out khá ngắn). Đây có thể là ứng dụng flash “chuối chiên” vì tôi không tin rằng người tạo flash có thể ấn định khi nào nên gởi FIN hay nên khởi RST? Cũng có thể nguồn nguyên thủy (máy nào đó) chạy cái flash này xuyên qua đường dẫn khá tệ nên các TCP sequences cách nhau khá xa? Có thể kẻ đã tạo ra mấy cái flash này cũng chẳng thèm để ý đến những “phương hại” tinh vi thế này, miễn sao dội HVA server càng nhiều, càng tốt thôi.

Sau khi xem xét hàng loạt các stream có lồng mảng “HTTP POST” và hình thành các số liệu thống kê, tôi ghi lại các giá trị HEX -10- của một số chi tiết nổi bật, bất biến và vị trí offset (khung màu đỏ trên hình) của chúng từ TCP “stream” ở trên để dành cho bước ngăn chặn sau này. Tôi không dành quá nhiều thời gian để tẳn mẳng nội dung của các POST payload ở trên nhưng nhìn sơ qua thì thấy “chủ nhân” của mớ x-flash này để lộ quá nhiều chi tiết có thể giúp truy danh tánh. Đây lại là một chuyện khác, tôi thật sự không hứng thú tìm hiểu “chủ nhân” mớ x-flash này là ai.

Tôi log vào HVA server lần nữa và “grep” -11- xuyên qua vài cái log cũ của web server chạy trên HVA. Ái chà, “bệnh” x-flash này đã xảy ra cũng đã nhiều ngày nhưng HVA không “chết” nổi, chỉ chậm lại ở những lúc cao điểm, chứng tỏ chiến thuật x-flash này không mấy hữu hiệu? Hay vì “chủ nhân” của mớ x-flash này chỉ cài chúng đâu đó rồi…. “sống chết mặc bây”? Tôi tiếp tục đào sâu trong mớ log đã cũ của HVA để hình thành vài con số thống kê. Sau hơn một giờ “chọc ngoáy” các log files và ghi chú thành một trang notepad chi chít chi tiết, tôi hình thành được khá nhiều thông tin hết sức lý thú, Những thông tin này khá phức tạp và tế nhị nên không thể công bố rộng rãi cho độc giả. Tôi đành phải tạm tóm lược như sau:

– căn bệnh x-flash này đã xảy ra nhiều tháng.

– trung bình mỗi ngày có khoảng +- 15,000 requests dùng x-flash vào HVA forum.

– các request này thường tập trung từ khoảng 6 giờ chiều cho đến khuya giờ VN.

– cao điểm các request này “đụng” vào HVA là khoảng 9 giờ tối.

Có thể rút tỉa được điều gì thuộc phương diện kỹ thuật từ những thông tin trên nhỉ?

– đám “x-flash” này có thể được xếp loại vào dạng DDoS vì chúng đến từ nhiều nguồn (IP) khác nhau cùng một lúc.

– chúng có cùng đặc tính (nói về mặt giao thức, kích thước và thái độ).

– có một số “stream” đi vào có cùng tính chất như các x-flash phá hoại này nhưng không hề mang “x-flash” trong header của HTTP POST, có lẽ chúng được một proxy server nào đó “lột” mất cái header?

– chúng hoàn toàn hợp lệ về mặt giao thức cho nên cấu hình server của HVA tiếp nhận chúng với “vòng tay rộng mở”.

– và dường như chúng được gởi đến từ các máy con trong thời điểm duyệt Internet cao độ trong ngày.

Với những nhận định trên, tôi tin rằng các “con” x-flash kia không được chủ nhân điều tác theo kiểu master / zombies thông thường mà đây có thể là cách cài các “x-flash” trên những diễn đàn tương tự như HVA. Khi người dùng duyệt đúng trang web nào đó có gắn những “x-flash” này, chúng được dùng làm phương tiện để gởi request đến HVA server. Số lượng người truy cập các diễn đàn ấy càng nhiều thì số lượng request gởi đến HVA càng cao. Vậy, HVA phải đối phó ra sao?

– cản? cản ai? cản những gì? nếu phải cản thì chỉ có thể cản một mớ IP của các gateway hoặc các proxy server đi từ VN (là chủ yếu) và nếu vậy thì chuyện gì xảy ra? Đúng vậy! “x-flash” đã “deny service” thành công vì nó buộc HVA phải cản luôn những “kẻ vô can” trong cuộc chơi quái dị này.

– không cản? thì “căn bệnh” này cứ đeo đuổi mãi sao? và nếu cứ để như vậy thì chuyện gì xảy ra? tất nhiên là HVA server không thể “chết” nổi nhưng ảnh hưởng đến các thành viên (và khách) truy cập đến diễn đàn HVA là ảnh hưởng tiêu cực (chậm, đứt quãng, phí tài nguyên, phí băng thông…).

Có khá đầy đủ các dữ kiện cần thiết, tôi bắt đầu hình thành chiến thuật “trị” nhưng “trị” thế nào thì xin độc giả đón xem phần kế tiếp.

Các bạn có thể theo dõi tiếp phần 3 tại http://hvaonline.net/hvaonline/posts/list/177.hva

Chú thích:

-7- stream là một chuỗi tin khởi đầu từ SYN và kết thúc ở FIN theo đúng quy trình. Một stream chứa các gói tin ra / vào từ khi mở connection đến khi connection được tắt bỏ (vì lý do gì đó).

-8- encapsulated là “lồng” gói tin thuộc tầng trên vào gói tin thuộc tầng dưới (HTTP là giao thức tầng application và được lồng vào TCP là giao thức tầng transport)

-9- MTU là Maximum Transmission Unit, giá trị quy định tối đa có bao nhiêu bytes được chứa trong một mảng tin bao gồm header, thông tin trải từ link layer trở lên. Nếu gói tin quá giới hạn MTU thì nó phải được bẻ nhỏ ra thành nhiều mảng (fragmentation). Ethernet có MTU là 1500 bytes tối đa cho mỗi mảng, IEEE 802.2/802.3 có MTU là 1492 tối đa cho mỗi mảng, FDDI (optic fibre) có MTU là 4352 và tối đa MTU có thể đạt được là 65535 cho Hyperchannel. Xem thêm chi tiết từ một cuốn sách chuyên về TCP/IP.

-10- HEX là viết tắt của hexadecimal.

-11- grep là một lệnh hết sức phổ biến trên *nix dùng để tìm một đoạn chữ có dạng mẫu nào đó trong một hồ sơ nào đó (chú thích này dành cho những ai chưa hề dùng *nix).