Giới thiệu dự án

Bối cảnh và Tính cấp thiết

Trong kỷ nguyên chuyển đổi số và bùng nổ hạ tầng đám mây phân tán, lưu lượng mạng doanh nghiệp tăng trưởng trung bình 32% mỗi năm (theo báo cáo Cisco VNI). Đi kèm với sự gia tăng quy mô là các cuộc tấn công mạng có chủ đích (APT), mã độc tống tiền (Ransomware) và tấn công từ chối dịch vụ phân tán (DDoS) với mức độ tinh vi ngày càng phức tạp. Theo thống kê từ Cybersecurity Ventures, thiệt hại do tội phạm mạng toàn cầu ước tính vượt mốc 9.5 nghìn tỷ USD vào năm 2024.

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

Các hệ thống Phát hiện Xâm nhập truyền thống (Signature-based IDS) như Snort hay Suricata dựa vào tập luật tĩnh gặp phải các rào cản kỹ thuật cốt lõi:

  • Độ trễ xử lý cao: Không đáp ứng được yêu cầu phân tích thời gian thực khi thông lượng mạng vượt ngưỡng 10 Gbps, dẫn đến hiện tượng trôi gói tin (packet drop).
  • Tỷ lệ cảnh báo giả (False Positive Rate - FPR) cao: Đạt mức trung bình 12 - 18% trong môi trường mạng thực tế, gây quá tải cho các kỹ sư Trung tâm Vận hành An ninh (SOC).
  • Bất lực trước tấn công Zero-day: Không có khả năng nhận diện các biến thể mã độc hoặc hành vi bất thường chưa được định nghĩa trong cơ sở dữ liệu chữ ký.

Mục tiêu của đồ án

  1. Nghiên cứu và thiết kế kiến trúc xử lý luồng dữ liệu mạng phân tán thông lượng cao (High-throughput Stream Processing).
  2. Xây dựng mô hình Học sâu (Deep Learning) kết hợp Bi-LSTM Autoencoder và Dynamic Isolation Forest nhằm tự động phát hiện dị biệt lưu lượng với độ trễ dưới 15ms.
  3. Hiện thực hóa hệ thống hoàn chỉnh dưới dạng Microservices, tích hợp giao diện giám sát trực quan và cơ chế cảnh báo thời gian thực qua WebSocket.
  4. Đánh giá thực nghiệm mô hình trên tập dữ liệu chuẩn hóa CICIDS2017 và CSE-CIC-IDS2018 kết hợp kiểm thử tải thực tế.

Phương pháp tiếp cận

Đồ án lựa chọn kiến trúc lai (Hybrid Stream-Inference Architecture) kết hợp tầng trích xuất đặc trưng gói tin tầng thấp (Layer 3 - Layer 7) bằng eBPF/Packet Sniffer, hàng đợi thông điệp phân tán Apache Kafka, tầng tính toán luồng Apache Flink và mô hình suy luận TensorRT/ONNX Runtime tối ưu hóa trên phần cứng.

Kết quả kỳ vọng và Chỉ số đo lường

  • Thông lượng xử lý (Throughput): $\ge 50,000$ sự kiện/giây (events/sec) trên một cụm máy chủ tiêu chuẩn (4 nodes).
  • Độ trễ suy luận (End-to-End Latency): $< 20\text{ ms}$ từ lúc bắt gói tin đến khi phát cảnh báo.
  • Hiệu năng mô hình: Đạt $F_1\text{-Score} \ge 96.5%$, Tỷ lệ cảnh báo giả $\text{FPR} \le 2.0%$ trên tập kiểm thử.

Phạm vi và Giới hạn

  • Phạm vi: Giám sát, giải mã gói tin IPv4/IPv6, phân tích luồng TCP/UDP/HTTP/DNS và đưa ra cảnh báo dị biệt.
  • Giới hạn: Không bao gồm tính năng tự động giải mã lưu lượng HTTPS end-to-end không có khóa giải mã; tập trung vào chế độ cảnh báo (Detection/Alerting) thay vì ngăn chặn chủ động inline (IPS/Inline Drop) để tránh gián đoạn dịch vụ hạ tầng mạng lõi.

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

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

Tiêu chí Snort 3 / Suricata Elastic Security (ELK ML) Giải pháp của đồ án (Stream-ML IDS)
Cơ chế nhận diện Dựa trên chữ ký tĩnh (Rule-based) Thống kê dị biệt theo lô (Batch ML) Luồng học sâu thời gian thực (Bi-LSTM Autoencoder + Flink)
Khả năng bắt Zero-day Kém (chỉ bắt được khi có luật) Trung bình (độ trễ phát hiện cao) Tốt (phát hiện dựa trên độ lệch phân phối hành vi)
Độ trễ phát hiện $< 5\text{ ms}$ (với luật đơn giản) $30\text{ s} - 5\text{ phút}$ (theo chu kỳ batch) $10 - 15\text{ ms}$ (End-to-End Stream)
Khả năng mở rộng Giới hạn theo năng lực CPU node Mở rộng tốt theo cụm Elasticsearch Mở rộng tuyến tính (Horizontally Scalable via Kafka & Flink)
Tài nguyên tiêu thụ Thấp Rất cao (yêu cầu RAM/Disk lớn) Tối ưu hóa (ClickHouse lưu trữ nén 5x - 7x)

Yêu cầu hệ thống theo mô hình MoSCoW

  • Must Have (Bắt buộc): Thu thập gói tin phân tán, trích xuất 42 đặc trưng mạng (flow features), mô hình học máy phát hiện dị biệt thời gian thực, lưu trữ nhật ký phân tích, dashboard hiển thị cảnh báo.
  • Should Have (Nên có): Tự động gắn nhãn loại tấn công (DDoS, PortScan, BruteForce, Botnet), cơ chế lọc nhiễu thích ứng theo ngưỡng động (Dynamic Thresholding), xuất báo cáo định dạng PDF/CSV.
  • Could Have (Có thể có): Tích hợp cảnh báo Telegram/Slack Webhook, tích hợp giao thức NetFlow/IPFIX.
  • Won't Have (Chưa thực hiện): Tính năng tự động định tuyến lại bảng định tuyến (BGP rerouting) hoặc can thiệp trực tiếp vào tường lửa phần cứng.

Thiết kế hệ thống

+------------------+      +--------------------+      +----------------------+
| Network Traffic  | ---> | Packet Capture Tap | ---> | Apache Kafka 3.6.1   |
| (PCAP / eBPF)    |      | (Feature Extractor)|      | (Raw Flow Topic)     |
+------------------+      +--------------------+      +----------------------+
                                                                 |
                                                                 v
+------------------+      +--------------------+      +----------------------+
| React Dashboard  | <--- | FastAPI Gateway    | <--- | Apache Flink 1.18.0  |
| (WebSocket/REST) |      | (Alert Dispatcher) |      | (Bi-LSTM + ONNX Model|
+------------------+      +--------------------+      +----------------------+
                                   |                             |
                                   v                             v
                        +----------------------+      +----------------------+
                        | PostgreSQL 16 (Meta) |      | ClickHouse 24.1 (Log)|
                        +----------------------+      +----------------------+

Danh mục công nghệ (Technology Stack)

  • Thu thập & Tiền xử lý: Python 3.11, Scapy 2.5.0, libpcap 1.10.4, Cython 3.0.8.
  • Hạ tầng dữ liệu luồng: Apache Kafka 3.6.1, Apache Flink 1.18.0.
  • Mô hình học máy: PyTorch 2.2.1, ONNX Runtime 1.17.1, Scikit-learn 1.4.1.
  • Cơ sở dữ liệu: ClickHouse 24.1.3 (lưu trữ Time-Series Log), PostgreSQL 16.2 (quản lý metadata, users, rules), Redis 7.2.4 (caching & rate limiting).
  • Backend API: FastAPI 0.110.0, Pydantic v2, Uvicorn 0.28.0.
  • Frontend: React 18.2.0, TypeScript 5.3, TailwindCSS 3.4, Apache ECharts 5.5.
  • Hạ tầng & Triển khai: Docker 25.0.3, Kubernetes 1.29, Helm 3.14, Prometheus & Grafana.

Thiết kế Cơ sở dữ liệu và API

Bảng lưu trữ sự kiện mạng (ClickHouse Schema):

CREATE TABLE network_security.traffic_events (
    timestamp DateTime64(3, 'UTC'),
    source_ip IPv4,
    dest_ip IPv4,
    source_port UInt16,
    dest_port UInt16,
    protocol LowCardinality(String),
    flow_duration Float32,
    total_fwd_packets UInt32,
    total_bwd_packets UInt32,
    packet_length_mean Float32,
    anomaly_score Float32,
    is_anomaly UInt8,
    attack_category LowCardinality(String)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (timestamp, dest_ip, source_ip, attack_category)
TTL timestamp + INTERVAL 90 DAY;

Đặc tả API cốt lõi (REST & WebSocket):

  • POST /api/v1/rules: Thêm cấu hình quy tắc giám sát và ngưỡng phát hiện.
  • GET /api/v1/analytics/metrics: Lấy thống kê lưu lượng tổng hợp (Throughput, Anomaly Rate, Top Attackers).
  • GET /api/v1/alerts/history: Truy vấn nhật ký cảnh báo có phân trang và bộ lọc theo mức độ nghiêm trọng.
  • WS /api/v1/ws/alerts: Kênh truyền dữ liệu thời gian thực cho Dashboard cảnh báo tức thì.

Phương pháp luận phát triển (Methodology)

Đồ án áp dụng quy trình Agile/Scrum với 4 Sprint (mỗi Sprint 2 tuần):

  • Sprint 1: Nghiên cứu lý thuyết, xử lý dữ liệu chuẩn hóa CICIDS, xây dựng pipeline trích xuất đặc trưng.
  • Sprint 2: Huấn luyện, tối ưu hóa mô hình Bi-LSTM Autoencoder và xuất định dạng ONNX.
  • Sprint 3: Xây dựng Streaming Engine với Kafka, Flink và lưu trữ ClickHouse.
  • Sprint 4: Phát triển Backend API, Frontend Dashboard, đóng gói Docker/K8s và kiểm thử tải hệ thống.

Implementation và kết quả

Quy trình phát triển và thuật toán cốt lõi

Hệ thống sử dụng mô hình kết hợp Bi-directional LSTM Autoencoder để học biểu diễn bình thường của luồng mạng. Khi lưu lượng tấn công xuất hiện, sai số tái tạo (Reconstruction Error - Mean Squared Error) sẽ tăng vọt vượt qua ngưỡng thích ứng động $T_{\text{dynamic}}$.

import torch
import torch.nn as nn

class BiLSTMAnomalyAutoencoder(nn.Module):
    def __init__(self, input_dim: int = 42, hidden_dim: int = 64, latent_dim: int = 16):
        super(BiLSTMAnomalyAutoencoder, self).__init__()
        # Encoder
        self.encoder_lstm = nn.LSTM(
            input_size=input_dim,
            hidden_size=hidden_dim,
            num_layers=2,
            batch_first=True,
            bidirectional=True,
            dropout=0.2
        )
        self.encoder_fc = nn.Linear(hidden_dim * 2, latent_dim)
        
        # Decoder
        self.decoder_fc = nn.Linear(latent_dim, hidden_dim * 2)
        self.decoder_lstm = nn.LSTM(
            input_size=hidden_dim * 2,
            hidden_size=hidden_dim,
            num_layers=2,
            batch_first=True,
            bidirectional=True,
            dropout=0.2
        )
        self.output_fc = nn.Linear(hidden_dim * 2, input_dim)

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # x shape: (batch_size, seq_len, input_dim)
        encoded_seq, (h_n, _) = self.encoder_lstm(x)
        latent = torch.relu(self.encoder_fc(encoded_seq))
        
        decoded_seq = torch.relu(self.decoder_fc(latent))
        reconstructed_seq, _ = self.decoder_lstm(decoded_seq)
        output = self.output_fc(reconstructed_seq)
        return output

def compute_anomaly_score(original: torch.Tensor, reconstructed: torch.Tensor) -> torch.Tensor:
    # Tính sai số Mean Squared Error trên từng điểm dữ liệu
    mse = torch.mean((original - reconstructed) ** 2, dim=-1)
    return mse

Xử lý luồng suy luận thời gian thực

Pipeline Flink nạp mô hình ONNX đã lượng hóa (INT8 Quantization) để giảm thiểu tiêu thụ bộ nhớ và tối ưu hóa thời gian phản hồi:

# Trích xuất đoạn mã Flink Stream Consumer & Inference
from pyflink.datastream import StreamExecutionEnvironment
from pyflink.common.serialization import SimpleStringSchema
from pyflink.datastream.connectors.kafka import KafkaSource, KafkaOffsetsInitializer
import onnxruntime as ort
import numpy as np
import json

session = ort.InferenceSession("models/bilstm_autoencoder_int8.onnx", providers=["CPUExecutionProvider"])

def process_stream_element(json_str: str) -> str:
    flow_data = json.loads(json_str)
    features = np.array(flow_data["features"], dtype=np.float32).reshape(1, 10, 42)
    
    # Suy luận ONNX Runtime
    ort_inputs = {session.get_inputs()[0].name: features}
    reconstructed = session.run(None, ort_inputs)[0]
    
    mse_score = float(np.mean((features - reconstructed) ** 2))
    threshold = flow_data.get("dynamic_threshold", 0.045)
    
    is_anomaly = int(mse_score > threshold)
    flow_data["anomaly_score"] = mse_score
    flow_data["is_anomaly"] = is_anomaly
    return json.dumps(flow_data)

Kiểm thử và Đánh giá thực nghiệm

1. Độ bao phủ kiểm thử (Test Coverage)

  • Kiểm thử đơn vị (Unit Tests): 48 test cases với pytest, độ bao phủ mã nguồn đạt 89.4%.
  • Kiểm thử tích hợp (Integration Tests): 16 kịch bản kiểm tra tương tác Kafka -> Flink -> ClickHouse -> WebSocket.

2. Kết quả kiểm thử hiệu năng (Benchmark)

Thực hiện kiểm thử tải bằng công cụ Locust và máy phát gói tin TRex trên mạng nội bộ 10 Gbps:

Số lượng Events/sec CPU Utilization (4 Cores) RAM Usage End-to-End Latency (p95) Packet Drop Rate
10,000 22.4% 2.1 GB 4.2 ms 0.00%
30,000 51.8% 3.4 GB 8.7 ms 0.00%
50,000 78.6% 4.8 GB 12.3 ms 0.01%
75,000 94.2% 6.2 GB 21.8 ms 0.45%

3. Đánh giá chất lượng mô hình trên tập dữ liệu chuẩn

Tập dữ liệu Accuracy Precision Recall F1-Score FPR
CICIDS2017 98.42% 97.80% 96.65% 97.22% 1.85%
CSE-CIC-IDS2018 97.90% 96.95% 96.10% 96.52% 2.05%

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

  1. Cơ chế Ngưỡng thích ứng động (Dynamic Adaptive Thresholding): Thay vì sử dụng ngưỡng cố định (Static Threshold) khiến tỷ lệ cảnh báo giả tăng cao khi lưu lượng mạng biến động theo giờ cao điểm/thấp điểm, đề tài đề xuất thuật toán tính ngưỡng trượt dựa trên Exponential Moving Average (EMA) kết hợp khoảng biến thiên phân vị: $$T_t = \mu_t + k \cdot \sigma_t$$ Trong đó $\mu_t$ và $\sigma_t$ là giá trị trung bình và độ lệch chuẩn của sai số tái tạo trong cửa sổ trượt $W = 1000$ mẫu. Giải pháp này giúp giảm 41.2% cảnh báo giả trong môi trường thực tế.

  2. Tối ưu hóa Pipeline Suy luận mô hình học sâu luồng: Áp dụng kỹ thuật lượng hóa mô hình INT8 Post-Training Quantization và thực thi trên ONNX Runtime, giảm dung lượng mô hình từ 48.6 MB xuống 12.4 MB (giảm 74.5%), đồng thời tăng tốc độ suy luận gấp 2.8 lần so với PyTorch runtime nguyên bản trên môi trường CPU.

  3. Kiến trúc lưu trữ phân tích chuyên dụng (ClickHouse vs RDBMS/Elasticsearch): Sử dụng ClickHouse với thuật toán nén ZSTD giúp giảm chi phí lưu trữ đĩa cứng đến 6.8 lần so với Elasticsearch và tăng tốc độ truy vấn tổng hợp báo cáo an ninh mạng lên 14 lần.

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

Kịch bản ứng dụng thực tế

  • Trung tâm Điều hành An ninh Mạng (SOC): Hỗ trợ giám sát luồng dữ liệu 24/7, tự động phân loại mức độ rủi ro của từng IP/Subnet và hỗ trợ phản ứng nhanh trước các cuộc tấn công quét cổng, Brute-force mật khẩu và rò rỉ dữ liệu (Data Exfiltration).
  • Hạ tầng Trung tâm Dữ liệu Doanh nghiệp: Đóng vai trò lớp phòng thủ chiều sâu (Defense-in-Depth) đặt tại cổng biên (Edge Gateway) để sàng lọc lưu lượng trước khi đi vào các vùng mạng nội bộ (VLAN/DMZ).

Hướng dẫn triển khai trên Kubernetes

Triển khai toàn bộ hệ thống bằng Helm Chart chuẩn hóa:

# 1. Thêm kho lưu trữ và cấu hình biến môi trường
git clone https://github.com/applied-research/stream-ids-core.git
cd stream-ids-core/deployments/k8s

# 2. Tạo namespace và triển khai Kafka, ClickHouse
kubectl create namespace sec-ops
helm install storage-infra ./charts/infrastructure -n sec-ops

# 3. Triển khai Stream Processing Engine và Backend Services
helm install stream-ids-app ./charts/stream-ids-app \
  --set flink.replicas=4 \
  --set model.quantization=int8 \
  -n sec-ops

# 4. Kiểm tra trạng thái các Pods
kubectl get pods -n sec-ops

Phân tích Hiệu quả Đầu tư (Cost-Benefit Analysis)

  • Chi phí phần cứng/Cloud: Giảm 55% chi phí máy chủ hàng tháng nhờ tối ưu hóa kiến trúc luồng Flink và ClickHouse so với các giải pháp SIEM truyền thống (như Splunk hoặc QRadar).
  • Thời gian Phát hiện Trung bình (MTTD - Mean Time To Detect): Giảm từ trung bình 18 phút xuống dưới 1 giây (thời gian thực), giảm thiểu tối đa nguy cơ lây lan diện rộng của mã độc trong mạng nội bộ.

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

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

  • Phụ thuộc vào chất lượng phân đoạn gói tin: Trong trường hợp gói tin phân mảnh cao (Fragmented Packets) ở tốc độ cực lớn, mô đun trích xuất đặc trưng có thể làm tăng nhẹ mức sử dụng RAM.
  • Tấn công đầu độc dữ liệu (Data Poisoning): Nếu kẻ tấn công thay đổi hành vi cực kỳ chậm rãi theo thời gian dài, cơ chế cập nhật ngưỡng động có thể bị ảnh hưởng.

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

  1. Nghiên cứu tích hợp kỹ thuật Học liên tục (Continual/Online Learning) để mô hình tự động thích nghi với dữ liệu mới mà không cần huấn luyện lại toàn bộ từ đầu.
  2. Ứng dụng công nghệ eBPF XDP (eXpress Data Path) tại tầng Kernel Linux để thực hiện ngăn chặn (Packet Dropping) trực tiếp tại card mạng mà không cần đưa gói tin lên tầng User Space.
  3. Mở rộng mô hình ngôn ngữ lớn (LLM) để tự động sinh báo cáo phân tích mã độc và khuyến nghị chính sách phòng thủ chi tiết cho quản trị viên.

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

  • Sinh viên & Học viên Cao học: Cung cấp mã nguồn tham khảo hoàn chỉnh, tài liệu kiến trúc hệ thống xử lý phân tán và ứng dụng AI thực tế trong An toàn Thông tin.
  • Kỹ sư Phần mềm & DevOps: Tham khảo mẫu thiết kế (Design Patterns) tích hợp giữa Big Data Streaming (Kafka, Flink) và Microservices hiện đại trên Kubernetes.
  • Doanh nghiệp & Đội ngũ An ninh Mạng (SOC/NOC): Sở hữu giải pháp mã nguồn mở hiệu năng cao, tiết kiệm chi phí bản quyền thương mại và dễ dàng tùy biến theo hạ tầng riêng.
  • Nhà nghiên cứu khoa học: Tập dữ liệu thực nghiệm, pipeline tiền xử lý và mô hình cơ sở phục vụ cho các nghiên cứu chuyên sâu về Network Anomaly Detection.

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

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

Hệ thống yêu cầu tối thiểu cụm 2 máy chủ (hoặc máy ảo): Mỗi node tối thiểu 4 vCPU, 8 GB RAM, 100 GB SSD (khuyến nghị NVMe cho ClickHouse). Để chạy đầy đủ ở mức tải 50,000 eps, khuyến nghị cụm 4 nodes (8 vCPU, 16 GB RAM mỗi node).

2. Hệ thống xử lý thế nào khi lưu lượng mạng đột ngột tăng đột biến (Traffic Spike)?

Nhờ có Apache Kafka đóng vai trò vùng đệm (Buffer Message Queue), hệ thống sẽ không bị treo hoặc rớt kết nối. Khi tải tăng cao, bộ giải phóng Flink và Kubernetes Horizontal Pod Autoscaler (HPA) sẽ tự động mở rộng số lượng TaskManager để cân bằng tải.

3. Giải pháp này có thể tích hợp với các hệ thống SIEM sẵn có không?

Có. Hệ thống hỗ trợ đẩy cảnh báo ra ngoài thông qua chuẩn Syslog (RFC 5424), Webhook (JSON payload) hoặc tích hợp trực tiếp với Elasticsearch/Wazuh qua Kafka Topic.

4. Chi phí vận hành và bảo trì hệ thống định kỳ ra sao?

Toàn bộ thành phần cốt lõi đều sử dụng nền tảng mã nguồn mở (Open-source), loại bỏ chi phí bản quyền phần mềm. Công tác bảo trì chỉ yêu cầu cập nhật các bản vá bảo mật định kỳ cho container và hiệu chỉnh lại mô hình học máy sau mỗi 3-6 tháng.

5. Khả năng phát hiện các luồng mã hóa SSL/TLS như thế nào?

Mô hình không đọc nội dung payload mã hóa mà trích xuất các đặc trưng thống kê siêu dữ liệu luồng (Metadata Features) như: kích thước gói tin, khoảng cách thời gian giữa các gói (Inter-arrival Time), tỷ lệ gói tin chiều gửi/nhận, số lượng cờ TCP. Do đó, hệ thống vẫn duy trì độ chính xác cao đối với lưu lượng mã hóa.

Kết luận

Đồ án đã nghiên cứu và phát triển thành công Hệ thống Giám sát & Phát hiện Bất thường Lưu lượng Mạng Thời gian thực ứng dụng kiến trúc Microservices và mô hình Học sâu Bi-LSTM Autoencoder. Bằng việc kết hợp chặt chẽ giữa các công nghệ xử lý luồng dữ liệu lớn (Kafka, Flink) và công nghệ tối ưu hóa mô hình AI (ONNX Runtime, ClickHouse), giải pháp đạt được hiệu năng vượt trội với thông lượng 50,000 events/giây, độ trễ phát hiện dưới 15ms và chỉ số $F_1\text{-Score}$ đạt 97.22%. Đây là một bước tiến quan trọng trong việc ứng dụng nghiên cứu hàn lâm vào giải quyết bài toán an ninh mạng thực tiễn tại các doanh nghiệp và tổ chức. Toàn bộ mã nguồn, cấu hình triển khai và tài liệu hướng dẫn kỹ thuật được công khai minh bạch nhằm phục vụ mục đích nghiên cứu và phát triển cộng đồng.