DDoS và nguyên tắc phân tích gói tin

Như đã đề cập ở bài trước (xem tại đây)

Giảm thiểu tác hại của DDoS có hai hướng chính:

1. Giảm thiểu bằng cách cản lọc những đặc điểm cụ thể.
2. Giảm thiểu bằng cách cản lọc theo ấn định số lần truy cập trong một khoản thời gian (nếu không tìm ra được đặc điểm cụ thể).

Từ những thông tin nào có thể giúp mình thực hiện việc giảm thiểu ấy? Cách khó nhất, tỉ mỉ nhất nhưng cũng chính xác nhất là lấy thông tin từ những gói tin bắt được trong lúc chúng tràn vào mục tiêu (để thực hiện việc DDoS).

Có lẽ một trong những công cụ phổ biến nhất ngày nay cho công việc bắt gói tin và phân tích gói tin đó là Wireshark (ngày xưa có tên là Ethereal). Công cụ này cho phép chúng ta sắp xếp gói tin theo:

• Thời gian gói tin đi đến.
• Theo nguồn IP của gói tin.
• Theo dạng giao thức của gói tin.
• Theo chiều dài của gói tin.
• Và đi sâu vào tính chất của từng gói tin.

Tuỳ nhu cầu, tuỳ hoàn cảnh mà sử dụng biện pháp sắp xếp để phân tích. Đôi khi cần phải đổi từ cách sắp xếp gói tin từ dạng này sang dạng khác để có thể nắm bắt tính chất được xem là “đặc điểm cụ thể”.

Tất nhiên, logs trên proxies, trên web server (như Apache, Nginx, IIS..v..v..) cũng có thể dùng để phân tích nhưng chúng thiếu hẳn những thông tin cụ thể về giao thức. Tuy vậy chúng có điểm lợi là đơn giản hơn, dễ phân tích hơn nhưng nếu muốn nắm rõ tính chất những gói tin thuộc dạng DDoS không thể không dùng Wireshark để bắt gói tin và phân tích gói tin.

Lấy một đoạn packets được dùng để tấn công một nạn nhân gần đây (5/7/2013), chúng ta có thể thấy gì?

• Các gói tin đã được sắp xếp (sort) theo nguồn (IP) ở đây đang tập trung vào phân tích nguồn 113.170.184.21.
• Nếu bấm vào dòng có giao thức là HTTP và có Info là “GET / HTTP/1.1” thì sẽ thấy có giá trị “User-Agent” hiện ra. Theo thông tin ở đây, đó là một điện thoại di động dạng Android và có địa phương (locale) là Canada (en-ca).
• Gói tin HTTP kia có chiều dài là 502 bytes (bao gồm chiều dài của gói tin TCP/IP tầng dưới).
• Nếu sử dụng tính năng “follow TCP stream” của gói tin cụ thể trên, bạn sẽ thấy một nhóm các gói tin được gởi / nhận và được ráp lại.
• Nếu xoáy sâu xuống một chút, mình có thể thấy thêm đây là một gói ACK có PSH flag và có chiều dài là 448 bytes.

Nếu tiếp tục xem xét danh sách các request đi từ 113.170.184.21, bạn sẽ thấy nhiều gói tin có tính chất y hệt xảy ra nhiều lần. Đó là chuyện bình thường nhưng sự thể sẽ bất thường khi cùng một IP lại có User-Agent khác cùng gởi request trong cùng 1 giây đó và đặc biệt, chúng gởi request đến cùng một địa chỉ lặp đi lặp lại liên tục như: http://www.abc.com/ trong một khoảng thời gian.

Những thông tin trên có vẻ rất bình thường nhưng đó là một bức ảnh mẫu để so sánh và để đặt ra những câu hỏi giúp cho việc phân tích, ví dụ:

1. Tại sao một IP thuộc Việt Nam mà lại dùng bằng điện thoại Android có ấn định địa phương là Canada?
2. Tại sao một IP như trên lại có User-Agent khác có ấn định địa phương là từ Đan Mạch gởi nhiều request cùng một lúc đến cùng một địa chỉ URL?
3. Tại sao những HTTP requests kia có cùng những nhóm “length” y hệt nhau và lặp đi lặp lại?
4. Tại sao chúng có cùng giá trị Referer, thậm chí Referer ấy không tồn tại?
5. Có bao nhiêu requests xảy ra trong một giây, một phút, 5 phút đi cùng một IP có cùng một User-Agent?
6. Có bao nhiêu User-Agents khác nhau đi từ một IP trong một khoản thời gian nào đó?
7. Liệu những IP tấn công kia có phải là IP của một proxy có nhiều người dùng chung hay không
8. v….v….v….

Nói chung, càng nhiều câu được đặt ra và trả lời càng giúp cung cấp các thông tin để hình thành những điểm đặc thù của dạng tấn công. Từ đó mới có thể hình thành biện pháp cản lọc.

1. Cản lọc trên tầng IP

Là những cản lọc thuần tuý mang tính chất thuộc về tầng IP thay vì những “string” và “text” thấy được ở tầng application (sau khi các packets đã gom lại hoàn chỉnh). Ví dụ, bạn thống kê được có 1 triệu requests đánh tới “index.php” có mấy chục User-Agents khác nhau và những requests này thuộc dạng ACK-PSH và có chiều dài chung là 488, 502, 515, 576, 590 (chẳng hạn). Trong khi đó, các requests (được xem là hợp lệ và sạch sẽ) của người dùng bình thường có chiều dài khác. Bạn có thể có hai chọn lựa:

• Cản cụ thể các packets ACK-PSH có chiều dài như trên vì bạn (biết) rằng người dùng đến trang web của bạn không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus…v.v.v.. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại.
• Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó). Lý là người dùng bình thường chẳng có ai liên tục truy cập hàng chục lần đến trang chủ trong mỗi giây hoặc vài trăm lần đến một hoặc nhiều URL trong một phút. Chẳng có ai có thể đọc nhanh như thế.

2. Cản lọc trên tầng application

Là những cản lọc cụ thể và chính xác những “string” và “text” thấy được trên logs của các web server. Ví dụ, bạn thống kê được có 1 triệu requests đánh tới “index.php” có mấy chục User-Agents khác nhau và bạn biết rằng những User-Agents ấy trước giờ ít xuất hiện vì không có mấy ai xài đổ địa phương là Canada, Đan Mạch, Belarus…v.v.v.. Bạn cũng có hai chọn lựa:

• Cản cụ thể các User-Agents lạ như đã thống kê. Chọn lựa này có thể cản nhầm một số người nhưng trong tình trạng bị đập nặng nề, đó là một chọn lựa nhằm cứu vãn số người dùng còn lại. Ngày nay, biện pháp cản lọc trên tầng application có vô số các công cụ, tiên ích, plugins, modules…v..v… giúp cho việc này.
• Cản tổng quát dựa trên số lần truy cập trong 1 giây (hoặc một phút, hoặc một khoản thời gian nào đó), y hệt với nguyên tắc phần 1.2 ở trên.

HOÀNG NGỌC DIÊU (Conmale – HVA).

Mạnh Tuấn

https://junookyo.blogspot.com/

Tôi là trưởng nhóm J2TeaM. Lĩnh vực nghiên cứu chính: Web Security, Web Application Pentest. Tôi cũng tìm hiểu về Facebook Security, Malware Analysis.