Giới thiệu dự án

Trong bối cảnh chuyển dịch mạnh mẽ từ các ứng dụng truyền thống sang nền tảng web và điện toán đám mây, các ứng dụng web đã trở thành kênh giao tiếp và giao dịch trọng yếu của mọi tổ chức. Theo báo cáo thường niên từ Gartner, hơn 75% các cuộc tấn công an ninh mạng nhắm trực tiếp vào tầng ứng dụng (Application Layer - Layer 7 trong mô hình OSI), biến các máy chủ web (Web Server) thành mục tiêu hàng đầu của tin tặc. Động cơ chính xuất phát từ việc cơ sở dữ liệu web lưu trữ hàng triệu bản ghi thông tin định danh cá nhân (PII), thẻ tín dụng và dữ liệu kinh doanh nhạy cảm, hoặc máy chủ có thể bị lợi dụng làm bàn đạp phát tán mã độc.

+-----------------------------------------------------------------------------+
|                            THỰC TRẠNG AN NINH TẦNG ỨNG DỤNG                  |
|  - 75% cuộc tấn công an ninh mạng nhắm vào Tầng Ứng Dụng (Layer 7 - OSI)    |
|  - Các lỗ hổng hàng đầu: SQL Injection (SQLi), Cross-Site Scripting (XSS),  |
|    Local File Inclusion (LFI), Remote Code Execution (RCE)                  |
|  - Hạn chế: WAF truyền thống bỏ lọt các biến thể payload bị obfuscate/bypass |
+-----------------------------------------------------------------------------+

Vấn đề nghiên cứu (Problem Statement)

Các giải pháp Tường lửa Ứng dụng Web (Web Application Firewall - WAF) truyền thống điển hình như ModSecurity kết hợp bộ quy tắc OWASP Core Rule Set (CRS) chủ yếu dựa trên kỹ thuật khớp mẫu biểu thức chính quy (Regex-based Signature Matching). Phương pháp này bộc lộ nhiều điểm nghẽn nghiêm trọng:

  • Không có khả năng phòng thủ Zero-day: Bất lực trước các vector tấn công chưa có chữ ký định danh trong cơ sở dữ liệu.
  • Dễ bị vượt mặt (Bypass): Tin tặc có thể áp dụng các kỹ thuật làm mờ mã (payload obfuscation), lồng ghép ký tự đặc biệt, URL encoding nhiều lớp hoặc thay đổi cú pháp để vượt qua bộ lọc signature.
  • Chi phí vận hành và cập nhật cao: Đòi hỏi đội ngũ kỹ sư bảo mật phải liên tục viết và bảo trì hàng nghìn rules thủ công, dễ dẫn đến xung đột chính sách và làm suy giảm hiệu năng xử lý HTTP.

Mục tiêu của đề tài

  1. Nghiên cứu và triển khai WAF ModSecurity trên nền tảng máy chủ NGINX theo mô hình Reverse Proxy để thiết lập lớp lọc ban đầu theo chữ ký đã biết.
  2. Xây dựng giải pháp tiền xử lý và chuẩn hóa dữ liệu URL (URL Normalization) nhằm chuyển đổi các payload phức tạp về dạng biểu diễn ngữ nghĩa thống nhất.
  3. Phát triển và huấn luyện mô hình Deep Learning (Bidirectional-LSTM kết hợp Word2Vec CBOW) có khả năng phân loại chính xác các yêu cầu HTTP độc hại và nhận diện các vector tấn công biến thể mới.
  4. Phát triển mô-đun C động (NGINX Dynamic Module) tích hợp trực tiếp thư viện TensorFlow C API vào quy trình xử lý luồng (Event Loop) của NGINX, đảm bảo khả năng kiểm tra thời gian thực với độ trễ tối thiểu.
  5. Thực nghiệm toàn diện trên các tập dữ liệu tiêu chuẩn (CSIC 2010, FWAF, HttpParams) và các kịch bản tấn công thực tế (SQLi, XSS, Command Injection).

Phương pháp tiếp cận (Solution Approach)

Đề tài đề xuất mô hình Hybrid WAF Architecture: Kết hợp sức mạnh sàng lọc nhanh của WAF truyền thống (ModSecurity CRS v3) ở tầng đầu với độ chính xác và khả năng tổng quát hóa của mạng học sâu Bidirectional-LSTM ở tầng thứ hai. Sự kết hợp này mang lại cơ chế phòng thủ chuyên sâu (Defense-in-Depth), vừa giữ được thông lượng cao vừa phát hiện triệt để các hành vi bất thường.

+-----------------------------------------------------------------------------+
|                           MỤC TIÊU VÀ KẾT QUẢ KỲ VỌNG                        |
|  - Tỷ lệ phát hiện (Accuracy): Đạt > 98% trên các tập dữ liệu benchmark      |
|  - Độ trễ xử lý (Latency Overhead): < 5ms cho mỗi HTTP Request              |
|  - Tỷ lệ cảnh báo sai (False Positive Rate): < 1.5%                         |
|  - Khả năng tương thích: Chạy trực tiếp dưới dạng NGINX Native Module       |
+-----------------------------------------------------------------------------+

Phạm vi và giới hạn đề tài

  • Phạm vi: Tập trung xử lý và phân tích các yêu cầu HTTP/HTTPS đi qua NGINX Reverse Proxy, nhắm vào các vector tấn công phổ biến nhất: SQL Injection, XSS, Command Injection và Path Traversal.
  • Giới hạn: Tập trung phân tích thành phần URI/URL và Query Parameters; chưa tích hợp giải mã phân tích toàn bộ Multipart POST Body dung lượng lớn trong giai đoạn chạy mô hình Deep Learning thời gian thực.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí so sánh Standalone ModSecurity (CRS) Cloud WAF (Cloudflare/AWS) Machine Learning Proxy (Python) Đề xuất: NGINX Dynamic ML-WAF
Cơ chế phát hiện Regex / Signature-based Hybrid (Rules + Cloud AI) Deep Learning / NLP Hybrid (CRS + Native Bi-LSTM)
Phát hiện Zero-day Kém (Phụ thuộc rules) Khá (Cập nhật từ Cloud) Tốt (Nhận diện ngữ cảnh) Xuất sắc (Deep Bi-LSTM Context)
Độ trễ xử lý (Latency) Rất thấp (< 1ms) Phụ thuộc mạng trung gian Cao (15 - 50ms qua IPC/HTTP) Cực thấp (1 - 3ms qua C API)
Tính riêng tư dữ liệu Hoàn toàn On-premise Dữ liệu đi qua bên thứ 3 Nội bộ Hoàn toàn On-premise / Edge
Chi phí bản quyền Mã nguồn mở (Miễn phí) Chi phí định kỳ cao Mã nguồn mở Mã nguồn mở, tối ưu chi phí

Đánh giá yêu cầu theo phương pháp MoSCoW

  • Must have (Bắt buộc): Chặn các cuộc tấn công đã biết qua ModSecurity; pipeline chuẩn hóa URL; mô hình phân loại Deep Learning đạt F1-Score > 95%; mô-đun biên dịch động tích hợp vào NGINX qua C API.
  • Should have (Nên có): Cơ chế bỏ qua kiểm tra ML đối với các đường dẫn tĩnh (Static Assets); bộ đệm cache kết quả phân loại; hỗ trợ HTTP/2.
  • Could have (Có thể có): Giao diện Dashboard hiển thị metrics tấn công thời gian thực; cơ chế tự động huấn luyện lại (Auto-retraining pipeline).
  • Won't have (Chưa thực hiện): Tăng tốc phần cứng bằng GPU chuyên dụng trực tiếp trong NGINX Worker; phân tích lưu lượng Websocket nhị phân.

Thiết kế hệ thống

Kiến trúc hệ thống được xây dựng theo mô hình Pipeline 2 lớp bảo vệ đặt bên trong NGINX Reverse Proxy.

flowchart TD
    Client[Client / Attacker] -->|HTTP/HTTPS Request| NGINX[NGINX Reverse Proxy]
    
    subgraph "NGINX Pipeline Inspection"
        NGINX --> Step1[Lớp 1: ModSecurity WAF Engine]
        Step1 -->|Khớp Signature Tấn công| Block1[HTTP 403 Forbidden / Drop]
        Step1 -->|Clean / Unknown Traffic| Step2[Lớp 2: Native ML Module Handler]
        
        subgraph "ML Deep Inspection Module"
            Step2 --> Norm[Chuẩn hóa URL: Rule & Mapping Engine]
            Norm --> Embed[Vector Hóa: Word2Vec CBOW Embedding]
            Embed --> Infer[Inference Engine: TensorFlow C API]
            Infer --> Predict{Dự đoán Bi-LSTM}
        end
        
        Predict -->|Xác suất Độc hại > Threshold| Block2[HTTP 403 / Log Threat]
        Predict -->|Hợp lệ - Benign| Forward[Chuyển tiếp Yêu cầu]
    end
    
    Forward -->|HTTP Forward| WebServer[Backend Upstream Web Server]
    WebServer -->|HTTP Response| NGINX
    NGINX -->|HTTP Response| Client

Technology Stack & Versioning

  • Web Server / Reverse Proxy: NGINX 1.22.x (Hỗ trợ Dynamic Modules --with-compat).
  • WAF Engine: ModSecurity v3.0.8 (libmodsecurity) + OWASP ModSecurity Core Rule Set (CRS) v3.3.x.
  • Inference Runtime Engine: TensorFlow C API v2.9.x (libtensorflow.so, c_api.h).
  • AI/ML Training Stack: Python 3.9+, Keras 2.9+, TensorFlow 2.9+, Gensim 4.2+ (Word2Vec CBOW), Scikit-Learn 1.1+.
  • Hệ điều hành triển khai: Ubuntu Server 20.04 LTS / 22.04 LTS x86_64.

Kiến trúc mô hình phân loại Deep Learning: Bidirectional-LSTM

Mô hình xử lý chuỗi URL đã chuẩn hóa thông qua các tầng chuyên biệt nhằm trích xuất đặc trưng không gian và thời gian của payload:

  1. Input Layer: Nhận vector chuỗi độ dài cố định $N = 556$ tokens.
  2. Embedding Layer: Ma trận nhúng từ Word2Vec (CBOW) chiều $300$ ($556 \times 300$).
  3. SpatialDropout1D (Rate = 0.2): Giảm thiểu hiện tượng over-fitting bằng cách loại bỏ ngẫu nhiên toàn bộ các kênh đặc trưng 1D.
  4. Bidirectional(LSTM - Units = 128): Đọc chuỗi theo cả hai chiều (Forward và Backward), trích xuất ngữ cảnh dài hạn với đầu ra kích thước $(None, 556, 256)$.
  5. Conv1D (Filters = 64, Kernel Size = 3): Trích xuất các mẫu n-gram đặc trưng cục bộ của payload.
  6. Pooling Layer: Kết hợp song song GlobalAveragePooling1D (64 chiều) và GlobalMaxPooling1D (64 chiều) $\rightarrow$ Nối qua tầng Concatenate (128 chiều).
  7. Dense Output Layer (Units = 2, Softmax): Tính toán phân phối xác suất nhị phân: [Benign, Malicious].
classDiagram
    class InputLayer {
        +Tensor shape: (None, 556)
    }
    class Embedding {
        +Vocabulary: 3000
        +Output_dim: 300
    }
    class SpatialDropout1D {
        +Rate: 0.2
    }
    class Bidirectional_LSTM {
        +Units: 128
        +Output: (None, 556, 256)
    }
    class Conv1D {
        +Filters: 64
        +Kernel_size: 3
    }
    class GlobalAvgPool1D {
        +Output: (None, 64)
    }
    class GlobalMaxPool1D {
        +Output: (None, 64)
    }
    class Concatenate {
        +Output: (None, 128)
    }
    class Dense_Softmax {
        +Units: 2
        +Activation: Softmax
    }

    InputLayer --> Embedding
    Embedding --> SpatialDropout1D
    SpatialDropout1D --> Bidirectional_LSTM
    Bidirectional_LSTM --> Conv1D
    Conv1D --> GlobalAvgPool1D
    Conv1D --> GlobalMaxPool1D
    GlobalAvgPool1D --> Concatenate
    GlobalMaxPool1D --> Concatenate
    Concatenate --> Dense_Softmax

Methodology

Quy trình phát triển được triển khai theo mô hình lặp (Iterative Engineering Pipeline) chia làm 5 giai đoạn:

+-----------------------------------------------------------------------------------+
|                           LỘ TRÌNH TRIỂN KHAI DỰ ÁN                               |
|                                                                                   |
|  [Giai đoạn 1] Nghiên cứu NGINX, ModSecurity v3 & Cấu hình Reverse Proxy         |
|  [Giai đoạn 2] Xây dựng Thuật toán Chuẩn hóa URL & Huấn luyện Word2Vec / Deep ML |
|  [Giai đoạn 3] Lập trình NGINX Dynamic C Module & Tích hợp TensorFlow C API      |
|  [Giai đoạn 4] Thử nghiệm tấn công mô phỏng, đo lường Latency & Benchmark         |
|  [Giai đoạn 5] Tối ưu hóa bộ nhớ, đóng gói tài liệu và triển khai thực tế        |
+-----------------------------------------------------------------------------------+

Đánh giá và giảm thiểu rủi ro (Risk Assessment)

  • Rủi ro Memory Leak trong NGINX Worker: NGINX sử dụng cơ chế Memory Pool (ngx_pool_t). Việc cấp phát bộ nhớ tùy tiện trong C module có thể làm cạn kiệt RAM.
    Giải pháp: Toàn bộ các tensor trung gian và buffer chuẩn hóa chuỗi đều được cấp phát và giải phóng qua ngx_pcalloc gắn liền với vòng đời của ngx_http_request_t.
  • Rủi ro Blocking Event Loop: Tác vụ inference của deep learning nếu tốn nhiều thời gian CPU sẽ làm nghẽn Event-driven Loop của NGINX.
    Giải pháp: Tối ưu hóa kích thước mô hình (Model Pruning/Quantization) và chỉ chuyển dữ liệu qua ML khi ModSecurity chưa xác định được rủi ro rõ ràng.

Implementation và kết quả

Development process

1. Thuật toán chuẩn hóa dữ liệu URL (Data Normalization Algorithm)

Kẻ tấn công thường xuyên thay đổi tên biến, mã hóa hex, chèn unicode để làm biến dạng payload. Nhóm tác giả xây dựng thuật toán chuẩn hóa ánh xạ các token về dạng danh từ định danh ngữ nghĩa trừu tượng:

def normalize_url(url_string, keywords_k1, extensions_e1, punctuations_p1):
    """
    Thuật toán chuẩn hóa URL cho mô hình ML-WAF
    Input: url_string (str), keywords (K1), extensions (E1), punctuations (P1)
    Output: Chuỗi URL đã được chuẩn hóa ngữ nghĩa
    """
    import urllib.parse
    import re
    
    # 1. URL Decode đa tầng để giải mã payload bị obfuscate
    decoded_url = urllib.parse.unquote(url_string).lower()
    
    # 2. Tách chuỗi theo ranh giới ký tự đặc biệt
    tokens = re.findall(r"[\w']+|[.,!?;/&=?+\-%<>()\[\]:\'\"]", decoded_url)
    transformed_query = []
    
    for e in tokens:
        if e in extensions_e1:        # Giữ nguyên đuôi tệp (.jsp, .php, .asp, ...)
            transformed_query.append(e)
        elif e in punctuations_p1:    # Giữ nguyên dấu câu đặc trưng cú pháp
            transformed_query.append(e)
        elif e in keywords_k1:        # Giữ nguyên từ khóa tấn công (select, alert, ...)
            transformed_query.append(e)
        elif e.isdigit():              # Thay thế số
            transformed_query.append('Numbers')
        elif re.match(r'^[a-z\-]+$', e): # Thay thế chuỗi chữ thường thuần túy
            transformed_query.append('PureString')
        elif re.match(r'^[0-9a-fA-F]+$', e) and len(e) > 4: # Chuỗi Hex
            transformed_query.append('HexString')
        elif any(ord(char) > 127 for char in e): # Ký tự Unicode
            transformed_query.append('UniString')
        else:                         # Chuỗi out-of-vocabulary không xác định
            transformed_query.append('MixString')
            
    return ' '.join(transformed_query)

Ví dụ thực tế chuyển đổi payload XSS:

  • URL Gốc: /tienda1/publico/registro.jsp?modo=registro&login=bob%40%3CSCRipt%3Ealert%281%29%3C%2FscrIPT%3E
  • URL Chuẩn hóa: / PathString / PathString / PathString . jsp ? PureString = PureString & PureString = PureString @ < script > alert ( Numbers ) < / script >

2. Cấu trúc Mô-đun NGINX C và Tích hợp TensorFlow C API

Mô-đun được cấu trúc gồm hai tệp cơ bản: config (Bourne Shell script hướng dẫn trình biên dịch NGINX liên kết với libtensorflow.so) và ngx_http_waf_ml_module.c.

/* Trích đoạn mã nguồn hook xử lý HTTP request trong NGINX C Module */
#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_http.h>
#include <tensorflow/c/c_api.h>

static ngx_int_t ngx_http_waf_ml_handler(ngx_http_request_t *r) {
    if (r->main->internal) {
        return NGX_DECLINED;
    }

    /* 1. Trích xuất URI và Query String từ cấu trúc ngx_http_request_t */
    ngx_str_t uri = r->uri;
    ngx_str_t args = r->args;
    
    char raw_url[2048];
    if (args.len > 0) {
        snprintf(raw_url, sizeof(raw_url), "%.*s?%.*s", (int)uri.len, uri.data, (int)args.len, args.data);
    } else {
        snprintf(raw_url, sizeof(raw_url), "%.*s", (int)uri.len, uri.data);
    }

    /* 2. Tiền xử lý, chuẩn hóa và vector hóa chuỗi URL trong bộ nhớ */
    float input_tensor_data[556];
    preprocess_and_vectorize(raw_url, input_tensor_data, 556);

    /* 3. Khởi tạo TensorFlow Tensor và gọi C API Inference */
    int64_t dims[] = {1, 556};
    TF_Tensor* input_tensor = TF_AllocateTensor(TF_FLOAT, dims, 2, sizeof(float) * 556);
    memcpy(TF_TensorData(input_tensor), input_tensor_data, sizeof(float) * 556);

    TF_Tensor* output_tensor = NULL;
    TF_Status* status = TF_NewStatus();

    /* Thực thi Session Run */
    TF_SessionRun(tf_session, NULL,
                  &input_op, &input_tensor, 1,
                  &output_op, &output_tensor, 1,
                  NULL, 0, NULL, status);

    if (TF_GetCode(status) != TF_OK) {
        TF_DeleteStatus(status);
        TF_DeleteTensor(input_tensor);
        return NGX_DECLINED; // Fail-open an toàn
    }

    /* 4. Đọc phân phối xác suất đầu ra */
    float* probabilities = (float*)TF_TensorData(output_tensor);
    float malicious_score = probabilities[1]; // Index 1: Xác suất độc hại

    TF_DeleteStatus(status);
    TF_DeleteTensor(input_tensor);
    TF_DeleteTensor(output_tensor);

    /* 5. Chặn yêu cầu nếu vượt quá ngưỡng rủi ro */
    if (malicious_score >= 0.85f) {
        ngx_log_error(NGX_LOG_WARN, r->connection->log, 0,
                      "[ML-WAF BLOCKED] Detect Anomaly Request: %s | Score: %f", raw_url, malicious_score);
        return NGX_HTTP_FORBIDDEN; // Trả về HTTP 403 Forbidden
    }

    return NGX_DECLINED; // Chuyển tiếp request sang upstream backend
}

Testing và validation

Hệ thống được đánh giá thực nghiệm trên 3 bộ dữ liệu chuẩn quốc tế:

  1. CSIC 2010 HTTP Dataset: Bộ dữ liệu chứa hàng chục nghìn request bao gồm các mẫu tấn công SQLi, XSS, Buffer Overflow, Parameter Tampering.
  2. FWAF (French Web Application Firewall Dataset): Hàng triệu request HTTP phân tán đa dạng tham số.
  3. HttpParams Dataset: Tập trung sâu vào các biến thể tham số độc hại URL và POST parameters.
+-----------------------------------------------------------------------------+
|               HIỆU SUẤT PHÂN LOẠI CỦA CÁC KIẾN TRÚC MÔ HÌNH                  |
+---------------------+-------------+-------------+------------+--------------+
| Kiến trúc mô hình   | Accuracy(%) | Precision(%)| Recall (%) | F1-Score (%) |
+---------------------+-------------+-------------+------------+--------------+
| Simple RNN Model    |    92.14    |    91.30    |   90.85    |    91.07     |
| Text-CNN Model      |    95.40    |    94.80    |   95.10    |    94.95     |
| Standard LSTM       |    96.25    |    95.90    |   96.10    |    96.00     |
| Hybrid CNN-LSTM     |    97.80    |    97.40    |   97.60    |    97.50     |
| Bidirectional-LSTM  |    99.12    |    98.95    |   99.05    |    99.00     |
| (Đề xuất)           |             |             |            |              |
+---------------------+-------------+-------------+------------+--------------+

gantt
    title Kế hoạch Triển khai và Kiểm thử Hệ thống (Tháng 09 - 12/2022)
    dateFormat  YYYY-MM-DD
    section Giai đoạn 1
    Khởi tạo Reverse Proxy & ModSec v3       :done, 2022-09-01, 2022-09-15
    Viết Rules & Tinh chỉnh ModSec           :done, 2022-09-15, 2022-09-30
    section Giai đoạn 2
    Nghiên cứu NLP & Word2Vec CBOW           :done, 2022-10-01, 2022-10-15
    Huấn luyện Deep Models (Bi-LSTM, CNN)   :done, 2022-10-15, 2022-10-31
    section Giai đoạn 3
    Viết C Module NGINX & TensorFlow C API  :done, 2022-11-01, 2022-11-20
    Tích hợp 2-Tier Pipeline vào NGINX       :done, 2022-11-20, 2022-11-30
    section Giai đoạn 4
    Thực nghiệm Tấn công & Đo Benchmark     :done, 2022-12-01, 2022-12-20
    Đánh giá Tổng kết & Báo cáo Khóa luận    :done, 2022-12-21, 2022-12-31

Kết quả đạt được

Kết quả thực nghiệm trên 20% dữ liệu kiểm thử độc lập cho thấy sự vượt trội rõ rệt khi tích hợp mô-đun Machine Learning so với khi chỉ sử dụng ModSecurity truyền thống:

Tập dữ liệu thử nghiệm ModSecurity Đơn lẻ (Detection Rate) NGINX + ModSec + Bi-LSTM (Detection Rate) Độ trễ gia tăng (Avg Latency Overhead)
CSIC 2010 (Bất thường) 78.45% 98.82% (+20.37%) + 1.82 ms
FWAF Dataset (Bất thường) 81.20% 99.15% (+17.95%) + 1.65 ms
HttpParams (Bất thường) 76.30% 98.60% (+22.30%) + 1.74 ms
Dữ liệu bình thường (Benign) 96.10% (Chính xác) 98.90% (False Alarm < 1.1%) + 1.50 ms

Đổi mới và đóng góp

  1. Thuật toán Chuẩn hóa URL Giảm thiểu Chiều Không gian (Generalized Token Normalization):
    • Đưa ra giải pháp phân tích từ vựng động, giữ nguyên các ký tự toán tử logic và từ khóa nhạy cảm, đồng thời khái quát hóa các chuỗi biến thiên ngẫu nhiên thành các token đại diện (PathString, PureString, MixString, Numbers).
    • Xử lý triệt để bài toán từ ngoài từ vựng (Out-Of-Vocabulary - OOV) mà các mô hình NLP truyền thống thường xuyên gặp thất bại khi đối mặt với payload mới.
  2. Kiến trúc Hybrid Hai Tầng (Two-Tier Multi-Stage Defense):
    • Không thay thế hoàn toàn WAF truyền thống mà tận dụng ModSecurity làm "bộ lọc thô" (Fast-path filtering) để ngăn chặn 80% payload phổ biến với chi phí CPU gần như bằng 0.
    • Sử dụng mô hình Deep Learning làm "bộ lọc tinh" (Deep-path inspection) cho 20% lưu lượng còn lại, giúp tối ưu hóa tài nguyên phần cứng máy chủ.
  3. Cơ chế Triển khai Native Không Độ trễ (Zero IPC Latency):
    • Loại bỏ hoàn toàn mô hình Microservices/Sidecar giao tiếp qua HTTP/gRPC thường gây thắt nút cổ chai (Bottleneck) từ 20-50ms.
    • Nhúng trực tiếp thư viện TensorFlow C API vào không gian bộ nhớ của NGINX Worker Process, duy trì thời gian phản hồi ở mức dưới 2.5ms.

Ứng dụng thực tế và triển khai

Kịch bản triển khai trong thực tế (Use Cases)

  • Cổng thanh toán và dịch vụ Ngân hàng / Fintech: Bảo vệ các REST API endpoints trước các cuộc tấn công SQL Injection nâng cao và chèn tham số trái phép.
  • Hệ thống Thương mại Điện tử (E-Commerce): Ngăn chặn các hành vi vét cạn dữ liệu, khai thác lỗi XSS để chiếm đoạt Session Cookie khách hàng trong các đợt Flash Sale lưu lượng truy cập cao.
  • Cổng Dịch vụ công Trực tuyến: Tăng cường an ninh mạng trước các cuộc tấn công có chủ đích (APT) khai thác lỗ hổng Zero-day.

Hướng dẫn cài đặt và cấu hình hệ thống (Deployment Guide)

Bước 1: Cài đặt thư viện phụ thuộc và TensorFlow C API

# Cài đặt công cụ biên dịch và thư viện PCRE, zlib, OpenSSL
sudo apt-get update && sudo apt-get install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev

# Tải và cài đặt TensorFlow C API v2.9.0 vào hệ thống
curl -L -O https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-linux-x86_64-2.9.0.tar.gz
sudo tar -C /usr/local -xzf libtensorflow-cpu-linux-x86_64-2.9.0.tar.gz
sudo ldconfig

Bước 2: Biên dịch NGINX với Mô-đun ML-WAF Động

# Tải mã nguồn NGINX tương ứng
wget https://nginx.org/download/nginx-1.22.1.tar.gz
tar -xzvf nginx-1.22.1.tar.gz
cd nginx-1.22.1

# Cấu hình biên dịch với cờ --add-dynamic-module
./configure --with-compat \
            --add-dynamic-module=/path/to/ngx_http_waf_ml_module \
            --with-http_ssl_module \
            --with-http_v2_module

# Biên dịch mô-đun
make modules
sudo cp objs/ngx_http_waf_ml_module.so /etc/nginx/modules/

Bước 3: Cấu hình nginx.conf

# Nạp mô-đun động tại tầng root
load_module modules/ngx_http_waf_ml_module.so;

events {
    worker_connections 4096;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    # Cấu hình Upstream Web Server
    upstream backend_cluster {
        server 10.0.0.10:8080 max_fails=3 fail_timeout=10s;
        keepalive 32;
    }

    server {
        listen 80;
        server_name secure.example.com;

        # Kích hoạt WAF ModSecurity
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/main.conf;

        # Kích hoạt Mô-đun Học máy ML-WAF
        ml_waf on;
        ml_waf_model_path "/etc/nginx/ml_models/bilstm_model.pb";
        ml_waf_vocab_path "/etc/nginx/ml_models/vocab_cbow.txt";
        ml_waf_threshold 0.85; # Ngưỡng xác suất chặn

        location / {
            proxy_pass http://backend_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        # Bỏ qua kiểm tra ML đối với các tệp tĩnh để tối ưu tài nguyên
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            proxy_pass http://backend_cluster;
            ml_waf off;
        }
    }
}

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Tiêu thụ bộ nhớ RAM: Việc nhúng trực tiếp Runtime Graph của TensorFlow vào mỗi NGINX Worker tiêu tốn khoảng 80MB - 120MB RAM cho mỗi tiến trình.
  • Phân tích Body phức tạp: Hiện tại mô hình tập trung kiểm soát tối ưu trên chuỗi URI, Header và URL Parameters; chưa tối ưu phân tích luồng dữ liệu nhị phân dung lượng lớn (như file upload).

Hướng phát triển trong tương lai

  • Chuyển đổi sang ONNX Runtime C++ / TensorRT: Tối ưu hóa mô hình sang định dạng ONNX/TensorRT để giảm thiểu 50% mức chiếm dụng RAM và đẩy nhanh tốc độ inference xuống dưới 0.8ms.
  • Triển khai Hệ sinh thái Tự học (Active Learning Feedback Loop): Tự động thu thập các mẫu có độ tin cậy thấp ($0.45 < score < 0.55$), gửi về trung tâm dữ liệu để gắn nhãn tự động và tái huấn luyện định kỳ.

Đối tượng hưởng lợi

+-------------------------------------------------------------------------------+
|                           GIÁ TRỊ MANG LẠI CHO CÁC BÊN                        |
+--------------------+----------------------------------------------------------+
| Sinh viên CNTT /   | Nguồn tài liệu tham khảo chất lượng cao về tích hợp C API|
| An toàn Thông tin  | với Machine Learning trên Web Server hiệu năng cao.      |
+--------------------+----------------------------------------------------------+
| Kỹ sư DevOps &     | Mô hình kiến trúc mẫu giải quyết triệt để bài toán độ    |
| Security (SecOps)  | trễ (Latency) khi đưa AI vào hệ thống Production thực tế.|
+--------------------+----------------------------------------------------------+
| Doanh nghiệp       | Giảm thiểu 70% chi phí bản quyền WAF thương mại đắt đỏ,  |
| và Tổ chức         | nâng cao năng lực tự vệ trước các mối đe dọa Zero-day.   |
+--------------------+----------------------------------------------------------+
| Giới nghiên cứu    | Đóng góp phương pháp chuẩn hóa dữ liệu URL mới giải quyết|
| Học thuật          | triệt để bài toán Out-of-Vocabulary trong bảo mật mạng.  |
+--------------------+----------------------------------------------------------+

Câu hỏi thường gặp

1. Yêu cầu cấu hình phần cứng tối thiểu để triển khai hệ thống là gì?

Máy chủ NGINX Reverse Proxy yêu cầu tối thiểu CPU 2 Cores (hỗ trợ tập lệnh AVX2), 4GB RAM và 10GB dung lượng ổ cứng. Khi tải cao (hơn 10,000 requests/giây), khuyến nghị máy chủ 8 Cores, 16GB RAM và sử dụng ổ lưu trữ NVMe.

2. Mô hình có làm tăng đột biến độ trễ (Latency) của trang web không?

Không. Nhờ việc ModSecurity lọc nhanh các request cơ bản trước và mã C Native gọi trực tiếp TensorFlow C API không qua trung gian mạng, độ trễ trung bình bổ sung chỉ dao động từ 1.5ms đến 2.5ms, hoàn toàn đáp ứng tốt trải nghiệm người dùng thực tế.

3. Làm thế nào để tích hợp hệ thống với hạ tầng NGINX sẵn có?

Do mô-đun được thiết kế theo chuẩn NGINX Dynamic Module (.so), quản trị viên chỉ cần nạp mô-đun qua chỉ thị load_module trong file nginx.conf mà không cần phải cài đặt lại toàn bộ hệ điều hành hay thay đổi cấu trúc mã nguồn ứng dụng web phía sau.

4. Hệ thống xử lý thế nào khi xảy ra lỗi nội bộ trong mô hình AI?

Mô-đun được lập trình với cơ chế bảo vệ an toàn (Fail-Open): Nếu TensorFlow runtime gặp sự cố không thể phân bổ bộ nhớ hoặc tính toán tensor, hàm điều khiển sẽ tự động ghi log cảnh báo (NGX_LOG_WARN) và chuyển tiếp request (NGX_DECLINED) đến backend để đảm bảo tính liên tục của dịch vụ, tránh làm sập máy chủ.

5. Chi phí đầu tư và thời gian hoàn vốn (ROI) ước tính như thế nào?

Giải pháp hoàn toàn dựa trên mã nguồn mở (NGINX, ModSecurity, TensorFlow), giúp doanh nghiệp tiết kiệm từ $15,000 - $50,000 chi phí bản quyền phần cứng/WAF thương mại hàng năm. Thời gian hoàn vốn đầu tư kỹ thuật ước tính đạt được ngay trong vòng 3 đến 6 tháng vận hành.

Kết luận

Đồ án tốt nghiệp "Phát triển mô-đun tường lửa ứng dụng web tích hợp học máy cho NGINX" của nhóm tác giả Đoàn Anh Dũng và Lê Thị Mỹ Duyên (Khoa Mạng máy tính & Truyền thông - UIT) đã giải quyết trọn vẹn bài toán nâng cao năng lực tự vệ cho máy chủ web hiện đại. Bằng việc kết hợp hài hòa giữa bộ lọc mẫu ModSecurity CRS và kiến trúc mạng học sâu Bidirectional-LSTM thông qua NGINX C Dynamic Module, hệ thống đã đạt tỷ lệ phát hiện tấn công vượt trội 99.12%, giảm thiểu tối đa các cảnh báo sai và duy trì độ trễ xử lý ở mức tối ưu < 2.5ms. Đây là một minh chứng xuất sắc cho tiềm năng ứng dụng Trí tuệ Nhân tạo vào việc giải quyết các thách thức an ninh mạng cốt lõi trong kỷ nguyên số.