Hướng dẫn chống tấn công DDoS bằng Nginx với kỹ thuật phân tích Signature

Chống tấn công DDoS bằng Nginx là việc xây dựng bộ lọc nhận diện signature tấn công ngay trên Nginx giúp loại bỏ chính xác truy vấn từ botnet, bảo vệ toàn vẹn dịch vụ cho người dùng thật. Trong bài viết này, mình sẽ hướng dẫn bạn các bước chống tấn công DDoS bằng Nginx nhanh chóng, chi tiết và hiệu quả.

Những điểm chính

• Phân tích sự cố: Xác định được nguyên nhân gốc rễ của sự cố (sập CSDL) là do tấn công DDoS tầng ứng dụng, không phải lỗi hệ thống thông thường.
• Hướng dẫn chống tấn công DDoS bằng Nginx: Nắm vững quy trình từng bước, từ phân tích đặc điểm tấn công (signature) đến xây dựng và kiểm thử một bộ quy tắc Nginx hoàn chỉnh để chặn truy cập độc hại.
• Đánh giá và các hướng mở rộng: Hiểu rõ ưu, nhược điểm của phương pháp lọc signature và biết cách xây dựng hệ thống phòng thủ đa lớp, bền vững hơn với Rate Limiting và WAF.
• Giải đáp thắc mắc (FAQ): Có được câu trả lời cho các câu hỏi quan trọng, giúp bạn tự tin triển khai giải pháp mà không lo chặn nhầm người dùng thật hay giảm hiệu quả khi bot thay đổi.

Phân tích sự cố

Trước đó, sự cố “Error establishing a database connection” trên WordPress đã được xác định không phải do lỗi nội tại của MySQL mà là hệ quả của việc tiến trình MySQL bị chấm dứt bởi cơ chế OOM Killer của hệ điều hành.

Nguyên nhân gốc rễ được truy vết đến một cuộc tấn công từ chối dịch vụ phân tán (DDoS) ở tầng ứng dụng (Layer 7), nhắm mục tiêu vào các tính năng tiêu tốn nhiều tài nguyên, gây ra tình trạng cạn kiệt bộ nhớ máy chủ.

Sau khi đã xác định được nguyên nhân, mục tiêu tiếp theo là xây dựng một bộ quy tắc giảm thiểu tấn công (mitigation ruleset) hiệu quả trên Nginx. Phương pháp được lựa chọn không phải là chặn IP hàng loạt, mà là xây dựng một cơ chế lọc với độ chính xác cao để vô hiệu hóa lưu lượng tấn công từ botnet mà không ảnh hưởng đến người dùng hợp lệ.

Bước 1: Phân tích Signature (Đặc điểm nhận dạng) của tấn công

Việc phân tích tệp nhật ký truy cập (access log) đã cho phép xác định một signature (đặc điểm nhận dạng) tấn công rất rõ ràng. Một yêu cầu (request) được phân loại là độc hại khi có đủ các điều kiện sau:

1. Mục tiêu cụ thể: Chỉ tấn công vào trang chủ (/) với một tham số (/?add_to_wishlist=xxxx), một chức năng đòi hỏi xử lý backend nặng.
2. Danh tính giả mạo: Sử dụng cùng một chuỗi User-Agent duy nhất, đây là một dấu hiệu kinh điển của bot.
3. Công cụ lỗi thời: Sử dụng giao thức HTTP/1.0, một phiên bản cũ và không còn được các trình duyệt hiện đại sử dụng cho các kết nối thông thường.
4. Phương thức tấn công: Sử dụng phương thức GET.

Mục tiêu của chúng ta là viết một quy tắc Nginx có khả năng nhận dạng chính xác signature này và từ chối xử lý các yêu cầu tương ứng.

Bước 2: Xây dựng và kiểm thử các lớp phòng thủ

Nguyên tắc cốt lõi khi xây dựng các cấu hình phức tạp là triển khai và kiểm thử từng thành phần logic một cách độc lập trước khi kết hợp chúng.

Điều kiện 1: Lọc theo URI và tham số truy vấn

• Mục tiêu: Chỉ áp dụng cho trang chủ (/) và có chứa tham số add_to_wishlist.
• Cấu hình Nginx:

# location = / { ... } đảm bảo quy tắc chỉ áp dụng cho chính xác URL trang chủ
location = / {
    # Biến $arg_add_to_wishlist sẽ chứa giá trị của tham số.
    # Ta kiểm tra xem nó có tồn tại và chỉ chứa các con số hay không.
    if ($arg_add_to_wishlist ~ "[0-9]+") {
        # Tạm thời trả về 406 để kiểm tra
        return 406;
    }
    # ... các quy tắc khác cho người dùng hợp lệ
}

• Kiểm thử:

# Request tấn công -> phải trả về 406 curl 'https://nguyenhung.io/?add_to_wishlist=123' -I 
# Request hợp lệ -> phải trả về 200 curl 'https://nguyenhung.io/' -I

Điều kiện 2: Lọc theo User-Agent

• Mục tiêu: Chặn các yêu cầu có User-Agent trùng khớp với signature của bot.
• Cấu hình Nginx:

location = / {
    if ($http_user_agent = "Mozilla/5.0 (Windows NT 6.1; WOW64)...") {
        return 406;
    }
}

• Kiểm thử:

# Dùng đúng User-Agent của bot -> phải trả về 406
curl 'https://nguyenhung.io/' -I -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)..."
# Dùng User-Agent khác -> phải trả về 200
curl 'https://nguyenhung.io/' -I -H "User-Agent: MyLegitBrowser"

Điều kiện 3: Lọc theo phiên bản giao thức

• Mục tiêu: Chặn các yêu cầu sử dụng giao thức cũ HTTP/1.0.
• Cấu hình Nginx:

Nginx
location = / { 
    if ($server_protocol = "HTTP/1.0") {
        return 406;
    }
}

• Kiểm thử:

# Dùng cờ --http1.0 -> phải trả về 406
curl 'https://nguyenhung.io/' -I --http1.0
# Dùng HTTP/1.1 (mặc định) -> phải trả về 200
curl 'https://nguyenhung.io/' -I --http1.1

Bước 3: Tích hợp các điều kiện thành một quy tắc hoàn chỉnh

Một vấn đề trong Nginx là khối lệnh if không hỗ trợ toán tử logic AND trực tiếp để kết hợp nhiều điều kiện. Để giải quyết vấn đề này, chúng ta áp dụng một kỹ thuật phổ biến: xây dựng một chuỗi định danh (signature string) dựa trên việc nối chuỗi có điều kiện.

Cấu hình Nginx hoàn chỉnh:

location = / {
    # 1. Khởi tạo một biến trống
    set $block_request_signature "";

    # 2. Nếu điều kiện URL & Argument khớp, nối thêm ký tự "A"
    if ($arg_add_to_wishlist ~ "[0-9]+") {
        set $block_request_signature "${block_request_signature}A";
    }

    # 3. Nếu điều kiện User-Agent khớp, nối thêm "U"
    if ($http_user_agent = "Mozilla/5.0 (Windows NT 6.1; WOW64) ...") {
        set $block_request_signature "${block_request_signature}U";
    }

    # 4. Nếu điều kiện Protocol khớp, nối thêm "P"
    if ($server_protocol = "HTTP/1.0") {
        set $block_request_signature "${block_request_signature}P";
    }
    
    # 5. Nếu điều kiện Method khớp, nối thêm "M"
    if ($request_method = "GET") {
        set $block_request_signature "${block_request_signature}M";
    }

    # 6. Nếu biến chứa TẤT CẢ các ký tự -> Chặn!
    if ($block_request_signature = "AUPM") {
        # return 444; là lựa chọn tốt nhất để chống bot.
        # Nginx sẽ đóng kết nối ngay lập tức mà không gửi phản hồi.
        # Điều này tiết kiệm tài nguyên và khiến bot không biết chuyện gì đã xảy ra.
        return 444;
    }

    # Nếu không, tiếp tục xử lý request như bình thường
    proxy_pass http://backend;
    # ...
}

Kiểm thử cuối cùng:

# Mô phỏng chính xác request tấn công
curl 'https://nguyenhung.io/?add_to_wishlist=123' \
-H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)..." --http1.0

Kết quả mong muốn:

curl: (52) Empty reply from server

Lỗi (52) Empty reply from server này xác nhận rằng Nginx đã nhận dạng đúng và đóng kết nối trước khi gửi bất kỳ dữ liệu nào, chứng tỏ quy tắc đã hoạt động thành công.

Ưu và nhược điểm

Quy tắc trên cực kỳ hiệu quả đối với cuộc tấn công cụ thể này do tính đặc hiệu cao, giảm thiểu tối đa khả năng chặn nhầm (false positives). Tuy nhiên, nhược điểm là kẻ tấn công có thể dễ dàng vượt qua bằng cách thay đổi một thuộc tính duy nhất, ví dụ như User-Agent.

Các biện pháp phòng thủ bổ sung

Để xây dựng một hệ thống phòng thủ đa lớp và linh hoạt hơn, cần xem xét các giải pháp tổng quát hơn:

• Rate Limiting: Sử dụng module limit_req_zone của Nginx để giới hạn số lượng yêu cầu từ một địa chỉ IP trong một khoảng thời gian nhất định.
• Web Application Firewall (WAF): Các dịch vụ như Cloudflare hoặc các module như ModSecurity cung cấp các bộ quy tắc thông minh để phát hiện và chặn các hành vi tấn công phổ biến.

Việc áp dụng một phương pháp có quy trình, từ phân tích nhật ký đến xây dựng và kiểm thử từng bước, sẽ giúp bạn giải quyết triệt để sự cố đồng thời trang bị các kiến thức và kỹ năng cần thiết để đối phó với các thách thức bảo mật trong tương lai.

Kỹ thuật phân tích signature và xây dựng quy tắc nhận diện đa điều kiện ngay trên Nginx là giải pháp tiên tiến nhằm hạn chế triệt để tấn công DDoS tầng ứng dụng mà vẫn bảo toàn traffic hợp lệ. Bằng việc kết hợp các giải pháp mở rộng như WAF và rate limiting, doanh nghiệp có thể chủ động thích ứng với các biến thể tấn công, bảo vệ website vững chắc trong môi trường mạng không ngừng biến đổi.