Netflow-Based Malware Detection and Data Visualization System

Repo này là phần implementation dựa trên bài báo Netflow-Based Malware Detection and Data Visualization System Rafal Kozik, Robert Mlodzikowski, và Michal Choraś (2017) cùng một vài cải tiến thêm.

💡 Tại sao dùng Netflow

Trong bức tranh toàn cảnh của An toàn thông tin hiện đại:

Malware ngày càng tinh vi: Các mã độc (như botnet) thường ẩn mình và liên tục thay đổi mã (bằng các phương pháp đa hình/làm rối), khiến các hệ thống phòng thủ dựa trên chữ ký (như Anti-virus hay Snort) hoạt động kém hiệu quả.
Hạn chế về dữ liệu: Việc thu thập dữ liệu mạng gốc (như các file .pcapng) để nghiên cứu phát hiện tấn công rất khó khăn do liên quan đến quyền riêng tư người dùng, các rào cản hành chính và pháp lý.

Để giải quyết vấn đề thiếu hụt dữ liệu trên, NetFlow được chọn làm giải pháp thay thế tối ưu vì 2 lý do chính:

Tính riêng tư: NetFlow chỉ chứa thông tin về luồng lưu lượng (ai gửi cho ai, bao nhiêu bytes...) mà không chứa nội dung về payload của gói tin, do đó không chứa dữ liệu nhạy cảm.
Tính sẵn có: Dữ liệu này được các nhà cung cấp dịch vụ Internet (ISP) thu thập rộng rãi cho mục đích giám sát hiệu năng, kiểm thử nên nguồn dữ liệu rất dồi dào và dễ tiếp cận hơn so với dữ liệu mạng gốc.

→ NetFlow là sự đánh đổi chấp nhận được – hy sinh chi tiết nội dung gói tin để đổi lấy khả năng mở rộng và tuân thủ quyền riêng tư khi nghiên cứu phát hiện malware.

🎯 Mục tiêu:

Phân tích NetFlow data để phát hiện malware
Triển khai 2 phương pháp trích xuất đặc trưng
Sử dụng machine learning để phân loại traffic bất thường
Visualize dữ liệu NetFlow
Cải thiện so với bài báo
Xây dựng hệ thống xử lý dữ liệu stream

Tip

TL;DR: Các phần từ 1 đến 4 chỉ đơn giản là làm lại giống hệt trong bài báo: notebook NetFlow_Detection.ipynb cho bước 1, 2, 3 và NetFlow_Visualization.ipynb cho bước 4. Phần 5 xem trong CICFlowMeter_Feature_Selection.ipynb. Phần 6 xem trong folder Realtime_system. Báo cáo và slide trong thư mục docs/.

5.1 Trích xuất đặc trưng với CICFlowMeter
5.2 Lựa chọn đặc trưng
5.3 Xử lý dataset
5.4 Thử nghiệm thêm các thuật toán học máy và học sâu khác và đánh giá kết quả
5.5 Đề xuất các bộ dữ liệu khác

Xây dựng hệ thống xử lý dữ liệu stream với Kafka

Cách chạy 🏃 dự án

git clone https://github.com/chutrunganh/Netflow-Based-Malware-Detection-and-Data-Visualization-System-IT4630E.git

cd Netflow-Based-Malware-Detection-and-Data-Visualization-System-IT4630E

# Cài đặt các dependencies trong uv.lock
# Có thể điều chỉnh phiên bản Python trong pyproject.toml
uv sync

Note

Dự án yêu cầu tối thiểu Python 3.12 để chạy

Các bước thực hiện chi tiết của dự án được mô tả như dưới đây.

1. Dataset

Bài báo sử dụng dataset CTU-13 để huấn luyện mô hình phát hiện malware. Dataset này chứa 13 scenarios khác nhau của botnet traffic. Mỗi scenario là do một loại botnet khác nhau: Neris, Rbot, Virut, Menti, Sogou, Murlo, NSIS tạo nên. Thông tin về các Scenario:

Id	Duration(hrs)	# Packets	#NetFlows	Size	Bot	#Bots
1	6.15	71,971,482	2,824,637	52GB	Neris	1
2	4.21	71,851,300	1,808,123	60GB	Neris	1
3	66.85	167,730,395	4,710,639	121GB	Rbot	1
4	4.21	62,089,135	1,121,077	53GB	Rbot	1
5	11.63	4,481,167	129,833	37.6GB	Virut	1
6	2.18	38,764,357	558,920	30GB	Menti	1
7	0.38	7,467,139	114,078	5.8GB	Sogou	1
8	19.5	155,207,799	2,954,231	123GB	Murlo	1
9	5.18	115,415,321	2,753,885	94GB	Neris	10
10	4.75	90,389,782	1,309,792	73GB	Rbot	10
11	0.26	6,337,202	107,252	5.2GB	Rbot	3
12	1.21	13,212,268	325,472	8.3GB	NSIS.ay	3
13	16.36	50,888,256	1,925,150	34GB	Virut	1

Trong mỗi Scenario trên trang chủ về sẽ bao gồm các file chính:

Neris.exe: executable file của botnet đó
botnet-capture-20110810-neris.pcap: chứa toàn bộ lưu lượng mạng trên máy bị nhiễm botnet này
capture20110810.pcap.netflow.labeled : Chứa các bản ghi NetFlow unidirectional đã được gán nhãn từ file PCAP
detailed-bidirectional-flow-labels/capture20110810.binetflow: Chứa các bản ghi NetFlow bidirectional đã được gán nhãn từ file PCAP, được khuyến nghị dùng cho việc phân tích malware detection. Trong notebook sẽ chỉ cần làm việc với loại file này, do đó không cần tải toàn bộ dataset.

Sử dụng wget để tải về các file .binetflow, lưu trong thư mục NetFlow_Project/data/ của dự án. Do theo như bài báo nói:

"The proposed methods have been evaluated on the scenario concerning the Rbot malware. According to the scenario description, the malware realises ICMP DDoS attack."

nên chúng tôi giả sử rằng bài báo chỉ thử nghiệm với Scenario Rbot ICMP DDoS (tức scenario thứ 4) nên chỉ cần tải file này về:

wget https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-45/detailed-bidirectional-flow-labels/capture20110815.binetflow

# Hoặc tải Scenario 11 có size nhỏ nhất để thử nghiệm nhanh trước
wget https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-52/detailed-bidirectional-flow-labels/capture20110818-2.binetflow

Định dạng .binetflow chỉ là dạng file CSV mở rộng, chuyên dùng để lưu NetFlow data

2. Feature Extraction

Bài báo đề xuất 2 phương pháp:

Method 1: aggregate NetFlows trong time window dài 1 phút. Với mỗi time window, tính các statistics:
- Số lượng NetFlows
- Tổng số bytes được truyền
- Trung bình bytes mỗi NetFlow
- Số lượng unique destination IP addresses

Ưu điểm: Số lượng feature vectors = số time windows → dataset nhỏ, training nhanh

Nhược điểm: Không thể xác định được IP cụ thể nào bị nhiễm (chỉ biết time window nào bất thường)

Method 2: cũng aggregate NetFlows trong time window, nhưng thêm bước nhóm theo IP source address trong mỗi time window. Với mỗi nhóm (time window, source IP), tính:
- Số lượng NetFlows
- Tổng số bytes được truyền
- Trung bình bytes mỗi NetFlow
- Trung bình thời gian giao tiếp giữa các IP unique
- Số lượng unique IP addresses
- Số lượng unique destination ports
- Giao thức được sử dụng nhiều nhất (vd TCP, UDP) bởi IP source cụ thể

Ưu điểm: Có thể xác định được IP cụ thể nào bị nhiễm malware, cung cấp thông tin chi tiết hơn về behavior của từng host

Nhược điểm: tạo ra nhiều feature vectors hơn làm tăng kích thước bộ dữ liệu huấn luyện

2.1 Create labels

Trong bài báo không đề cập đến việc xử lý label. Do đó trong dự án này chúng tôi tự đề xuất phương án xử lý.

Trong dataset ban đầu có 3 loại label: Background, Normal, Botnet. Mỗi loại này lại được đánh nhãn cụ thể dưới nhiều dạng khác nhau. Ví dụ:

Background có thể được ghi label dưới dạng: Background-UDP-CVUT-DNS-Server, Background-UDP-Established, Background-TCP-Established, ...
Normal có thể được ghi label dưới dạng: From-Normal-V52-MatLab-Server, From-Normal-V52-Grill, ...
Botnet có thể được ghi label dưới dạng: From-Botnet-V52-3-UDP-DNS, From-Botnet-V52-1-ICMP,....

Chúng tôi giả thuyết rằng bài báo sử dụng phân loại nhị phân (Binary Classification). Một dòng (một bản ghi Netflow) trong dataset gốc nếu có nhãn có chứa từ khóa Botnet sẽ được đánh nhãn là 1, các nhãn còn lại đều là 0. Trong một time window 1 phút được gộp từ các bản ghi Netflow:

Nếu có bất kỳ bản ghi NetFlow nào trong đó có nhãn là 1 thì cả time window đó có nhãn là 1.
Nếu không có chứa bất kỳ bản ghi NetFlow nào có nhãn là 1 thì time window đó có nhãn là 0.

3. Machine-Learning Models

Các feature vectors được extract theo 2 phương pháp trên sẽ được dùng để huấn luyện các mô hình Machine Learning bao gồm:

NaiveBayes
Logistic
Multilayer Perceptron
SimpleLogist
IBk
CVR
Logit Boost
RandomCommitte
JRip
PART
J48
RandomForest
RandomTree

Kết quả huấn luyện được đánh giá theo các metrics: True Positive Rate (TPR) và False Positive Rate (FPR) dựa trên phương pháp stratified 10-fold cross-validation của cả 2 phương pháp

Tuy nhiên, bài báo:

Sử dụng các model trong Weka, một phần mềm GUI để xử lý dữ liệu và huấn luyện các thuật toán ML. Trong dự án này, chúng tôi sử dụng các thuật toán tương tự nhưng được lấy từ thư viện scikit-learn. Do đó có thể có sự khác biệt trong cách triển khai các thuật toán giữa 2 thư viện này.
Không cung cấp các tham số (Hyper parameters) của các thuật toán được sử dụng: "During the experiments, we have used different configurations of the algorithms in order to obtain optimal results".
Không cung cấp cách tạo ra label để đưa vào huấn luyện như phần trên đã đề cập.

Do đó, các kết quả trong dự án có thể khác biệt so với bài báo. Kết quả hiện tại:

Algorithms	Method 1 - TPR	Method 1 - FPR	Method 2 - TPR	Method 2 - FPR
Naive Bayes	65.6%	35.2%	44.4%	2.4%
Logistic Regression	62.2%	41.3%	68.9%	4.9%
Multilayer Perceptron	27.8%	10.8%	40.5%	10.8%
SimpleLogistic (Approx)	55.6%	41.4%	67.8%	4.9%
IBk (KNN)	41.1%	31.3%	56.7%	0.0%
Logit Boost	34.4%	25.3%	26.7%	0.0%
Random Committee	37.8%	23.8%	51.1%	0.0%
J48 (Decision Tree)	54.4%	40.9%	77.8%	0.0%
Random Forest	31.1%	19.9%	62.2%	0.0%
Random Tree	37.8%	30.6%	64.4%	0.0%

So sánh với kết quả trong bài báo:

Algorithms	Method 1 - TPR	Method 1 - FPR	Method 2 - TPR	Method 2 - FPR
NaiveBayes	60,0%	33,3%	50,0%	0,2%
Logistic	40,0%	50,0%	33,3%	0,0%
Multilayer Perceptron	40,0%	25,0%	33,3%	0,0%
SimpleLogist	0,0%	0,0%	25,0%	0,0%
IBk	20,0%	41,7%	58,3%	0,0%
CVR	40,0%	25,0%	33,3%	0,0%
Logit Boost	40,0%	16,7%	33,3%	0,0%
Random Committe	20,0%	33,3%	66,7%	0,0%
JRip	0,0%	16,7%	50,0%	0,0%
PART	60,0%	50,0%	50,0%	0,0%
J48	60,0%	50,0%	50,0%	0,0%
RandomForest	40,0%	25,0%	66,7%	0,0%
RandomTree	20,0%	16,7%	58,3%	0,0%

4. Data Visualization

Từ dữ liệu NetFlow, hiển thị trực quan các thông tin về lưu lượng mạng theo như bài báo đề xuất như:

Số lượng NetFlows theo các time windows khác nhau

Lượng bytes được truyền theo các tiêu chí tìm kiếm cụ thể

Mức độ sử dụng các cổng đích

Kết quả của quá trình phân loại

Phân tích các phụ thuộc giữa các host có khả năng bị nhiễm và các host khác

Số lượng flows theo thời gian

Số lượng unique destination IP addresses theo thời gian

5. Improvement compare to the paper

Sau khi được phản hồi tại project checkpoint, nhóm được yêu cầu cần cải thiện:

Sử dụng dữ liệu pcap để trích xuất lại đặc trưng sử dụng CICFlowmeter. Do trong bài báo sử dụng file binetflow có sẵn chỉ trích xuất rất giới hạn số lượng đặc trưng (với Method 1 là 4 đặc trưng, Method 2 là 7 đặc trưng). Trong khi CICFlowmeter có thể trích xuất lên đến 80+ đặc trưng từ file pcap. Việc này giúp cung cấp nhiều thông tin hơn cho việc phân loại để cải thiện độ chính xác.
Lựa chọn các đặc trưng trích xuất được để phân loại. Do CICFlowMeter trích xuất tới 80+ đặc trưng, không phải tất cả đều hữu ích cho việc phân loại. Nhóm đề xuất và thử nghiệm phương pháp chọn lọc đặc trưng sử dụng Correlation và Features Importance từ RandomForest để chọn ra các đặc trưng quan trọng nhất. Chú ý không sử dụng đặc trưng liên quan đến địa chỉ IP và port do các thông tin này có thể thay đổi theo từng môi trường mạng khác nhau.
Cần chạy thêm một số thuật toán học máy hoặc học sâu khác. So với bài báo, chúng tôi đã thử nghiệm thêm các thuật toán Machine Learning: XGBoost, LightGBM, CatBoost và các thuật toán Deep Learning: LSTM, CNN, CNN-LSTM với cấu trúc mạng theo như Repo này
Tìm thêm các bộ dữ liệu về lưu lượng mạng khác về mã độc: IoT-23, CSE-CIC-IDS2018.
Xây dựng luồng xử lý dữ liệu stream hoàn chỉnh sử dụng Kafka.

Quy trình tổng quan sẽ là:

flowchart TD
    A[File PCAP gốc] --CICFlowMeter--> B[NetFlow CSV]
    B --Tạo label dựa trên IP--> C[Labeled NetFlow CSV]
    C--Feature Selection--> D[Features vectors]
    D --Xử lý imbalance--> E[Dataset cho huấn luyện]
    E --Stratify 8:2--> F[AL/DL models]
    F --Metrics--> G[Đánh giá kết quả]
    G --> H[Lưu lại các model tốt nhất]

5.1 Trích xuất đặc trưng với CICFlowMeter

Để trích xuất từ file PCAP sang file NetFlow CSV, chúng ta sử dụng công cụ CICFlowMeter, một công cụ mã nguồn mở dùng để trích xuất các đặc trưng mạng từ các file PCAP thành định dạng NetFlow CSV. CICFLowMeter có hai phiên bản:

CICFlowMeter Java: Phiên bản viết bằng Java và có hỗ trợ GUI, sử dụng jnetpcap để xử lý gói tin. Tuy nhiên cài đặt phức tạp và có vẻ không còn được maintain (tại thời điểm viết là được update lần gần nhất 4 năm trước). Chúng tôi đã thử cài đặt và chạy bằng phiên bản Java mà ứng dụng tương thích (Java 8), ứng dụng hiển thị được GUI tuy nhiên không hoạt động.

Cài đặt:
```
git clone https://github.com/ahlashkari/CICFlowMeter
cd CICFlowMeter
sudo bash
cd jnetpcap/linux/jnetpcap-1.4.r1425/
mvn install:install-file -Dfile=jnetpcap.jar -DgroupId=org.jnetpcap -DartifactId=jnetpcap -Dversion=1.4.1 -Dpackaging=jar
cd ../../..
chmod +777 ./gradlew
./gradlew execute
```
CICFlowMeter Python: Phiên bản được viết bằng Python. Bản này sử dụng thư viện Scapy để phân tích gói tin. Scapy rất mạnh nhưng cực kỳ chậm khi xử lý file lớn vì nó load từng gói tin thành object Python. Tuy nhiên phiên bản này dễ dàng hơn trong việc cài đặt và được maintain gần đây (tại thời điểm viết là được update lần gần nhất 2 tháng trước). Trong dự án chúng tôi sẽ dùng phiên bản này.

Cài đặt:
```
git clone https://github.com/hieulw/cicflowmeter
cd cicflowmeter
uv sync
source .venv/bin/activate
```

Để có file PCAP, sử dụng wget để tải về từ trang chủ CTU-13. Trên trang chủ, với mỗi một Scenario có 3 file PCAP:

Scenario 11

botnet-capture-YYYYMMDD.pcap: Chứa toàn bộ lưu lượng mạng trên máy bị nhiễm botnet này
captureYYYYMMDD.pcap : Chứa toàn bộ lưu lượng mạng (background, normal and botnet) được thu thập trên Router của trường đại học. Tuy nhiên file này không được công bố public, theo bài báo.
captureYYYYMMDD.truncated.pcap.bz2: là file trên nhưng được truncated đi để loại bỏ payload chính của mỗi gói tin, chỉ giữ lại một số byte bắt đầu:
- TCP: 54 bytes
- UDP: 42 bytes
- ICMP: 66 bytes
Trong dự án này chúng tôi sử dụng các file PCAP captureYYYYMMDD.truncated.pcap.bz2.

Để tải các file PCAP:

# Lấy ví dụ với Scenario 11 vì đây là Scenario có kích thước các file nhỏ nhất
# Nên thử nghiệm notebook với Scenario này trước vì nó sẽ chạy nhanh hơn
wget https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-52/capture20110818-2.truncated.pcap.bz2

# Sau khi chạy thử nghiệm thành công với Scenario 11, tải và đánh giá lại kết quả dựa trên Scenario 4 vì bài báo dùng Scenario này.
wget https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-45/capture20110815.truncated.pcap.bz2

# Sau đó giải nén file, rồi dùng CICFlowMeter, nó sẽ chuyển toàn bộ file PCAP trong thư mục data rồi merge vào thành một file CSV
cicflowmeter -d "YOUR_PATH/NetFlow_Project/data/" -c "YOUR_PATH/NetFlow_Project/data/extracted_by_CIC" --merge

Chạy CICFlowMeter trên file PCAP của Scenario 11:

(cicflowmeter) chutrunganh@ThinkPad-CTA:~/.../cicflowmeter$ cicflowmeter -d ".../NetFlow_Project/data/" -c ".../NetFlow_Project/data/extracted_by_CIC" 

Found 1 pcap file(s) to process
Processing capture20110818-2.truncated.pcap -> capture20110818-2.truncated.csv
reading from file .../NetFlow_Project/data/capture20110818-2.truncated.pcap, link-type EN10MB (Ethernet), snapshot length 262144
Completed capture20110818-2.truncated.pcap

All done! Output files saved to: .../NetFlow_Project/data/extracted_by_CIC

Với Scenario 11, file nén capture20110818-2.truncated.pcap.bz2 có kích ~80MB -> sau giải nén được capture20110818-2.truncated.pcap ~ 830MB -> Sau khi extract bởi CICFlowMeter được capture20110818-2.truncated.csv ~45MB, thời gian chạy ~25 phút.

Kiểm tra các cột trong file CSV trích xuất được từ CICFlowMeter:

Data columns (total 82 columns):
 #   Column             Non-Null Count   Dtype  
---  ------             --------------   -----  
 0   src_ip             120880 non-null  object 
 1   dst_ip             120880 non-null  object 
 2   src_port           120880 non-null  int64  
 3   dst_port           120880 non-null  int64  
 4   protocol           120880 non-null  int64  
 5   timestamp          120880 non-null  object 
 6   flow_duration      120880 non-null  float64
 7   flow_byts_s        120880 non-null  float64
 8   flow_pkts_s        120880 non-null  float64
 9   fwd_pkts_s         120880 non-null  float64
 10  bwd_pkts_s         120880 non-null  float64
...
 80  subflow_fwd_byts   120880 non-null  int64  
 81  subflow_bwd_byts   120880 non-null  int64

Các đặc trưng này có thể chia thành các nhóm hành vi chính:

Đặc trưng cơ bản của luồng (Basic connection features) mô tả trực tiếp về phiên kết nối, như:
- Flow ID: định danh luồng
- Source IP, Source Port: địa chỉ và cổng nguồn
- Destination IP, Destination Port: địa chỉ và cổng đích
- Protocol: giao thức sử dụng (TCP, UDP, ICMP)
- Timestamp: thời điểm bắt đầu và kết thúc luồng
- Flow Duration: độ dài phiên kết nối (micro giây)
Đặc trưng thống kê lưu lượng (Time-based and Byte-based statistics) mô tả các chỉ số tổng hợp về gói tin và byte trong luồng, bao gồm:
- Total Fwd Packets, Total Backward Packets: tổng số gói tin gửi và nhận
- Total Length of Fwd Packets, Total Length of Bwd Packets: tổng số byte gửi và nhận
- Fwd Packet Length Min/Max/Mean/Std: thống kê độ dài gói tin chiều đi
- Bwd Packet Length Min/Max/Mean/Std: thống kê độ dài gói tin chiều về
- Flow Bytes/s, Flow Packets/s: tốc độ truyền byte và gói tin
- Flow IAT Mean/Std/Min/Max: khoảng cách thời gian giữa các gói trong luồng
- Fwd IAT Total/Mean/Std/Min/Max: khoảng cách gói trong chiều đi
- Bwd IAT Total/Mean/Std/Min/Max: khoảng cách gói trong chiều về
Đặc trưng liên quan đến header và cờ điều khiển (Header and Flag features) phản ánh hành vi của giao thức TCP/UDP/ICMP thông qua các cờ và trường header
- Fwd PSH Flags, Bwd PSH Flags: số gói có cờ PSH
- Fwd URG Flags, Bwd URG Flags: số gói có cờ URG
- FIN Flag Count, SYN Flag Count, RST Flag Count, PSH Flag Count, ACK Flag Count, URG Flag Count, CWE Flag Count, ECE Flag Count
- Fwd Header Length, Bwd Header Length: độ dài phần header trong chiều đi và chiều về
Đặc trưng thống kê nâng cao về hành vi luồng (Advanced flow behavior features) tập trung vào các mẫu hành vi phức tạp của luồng, như:
- Average Packet Size: kích thước trung bình gói tin
- Avg Fwd Segment Size, Avg Bwd Segment Size: kích thước trung bình segment
- Subflow Fwd Packets/Bytes, Subflow Bwd Packets/Bytes: đặc trưng phụ về lưu lượng theo chiều
- Init_Win_bytes_forward, Init_Win_bytes_backward: kích thước cửa sổ TCP khởi tạo
Đặc trưng dựa trên tần suất và nhịp truyền (Frequency and active features) phản ánh sự phân bổ hoạt động trong luồng:
- Active Mean/Std/Min/Max: thống kê về các khoảng thời gian luồng hoạt động
- Idle Mean/Std/Min/Max: thống kê về các khoảng thời gian luồng không hoạt động

Refer BÀI GIẢNG HỌC PHẦN PHÒNG CHỐNG TẤN CÔNG MẠNG - ĐẠI HỌC BÁCH KHOA HÀ NỘI -Bùi Trọng Tùng, Tống Văn Vạn, Lê Xuân Thành

Sau khi có file CSV trích xuất từ CICFlowMeter, ta cần tạo Label cho từng bản ghi NetFlow trong file CSV này do trích xuất từ file PCAP gốc chưa có nhãn. Để tạo label, ta dựa vào địa chỉ Infected IP của mỗi Scenario. Trên trang chủ của CTU-13 mỗi Scenario đều cung cấp Infected IP tương ứng. Ví dụ với Scenario 11:

Infected hosts:

147.32.84.165: Windows XP English version Name: SARUMAN. Label: Botnet. Amount of bidirectional flows: 4151
147.32.84.191: Windows XP English version Name: SARUMAN1. Label: Botnet. Amount of bidirectional flows: 4006
147.32.84.192: Windows XP English version Name: SARUMAN2. Label: Botnet. Amount of bidirectional flows: 7

Với mỗi bản ghi NetFlow nếu src_ip hoặc dst_ip trùng với một trong các địa chỉ IP trên thì gán nhãn là 1 (Botnet), ngược lại là 0 (Normal/Background).

5.2 Lựa chọn đặc trưng

Loại bỏ các đặc trưng liên quan đến địa chỉ IP và port: src_ip, dst_ip, src_port, dst_port do các thông tin này có thể thay đổi theo từng môi trường mạng khác nhau. Việc đưa chúng vào huấn luyện có thể dẫn đến hiện tượng overfitting do mô hình học thuộc các địa chỉ IP/port cụ thể thay vì học các hành vi mạng chung của mã độc.
Sử dụng phương pháp Correlation để loại bỏ bớt các features có độ tương quan cao với nhau (>0.95):

Correlation Matrix sau khi đã loại bỏ các features có phương sai = 0. Với các cặp có correlation cao, loại bỏ một trong hai features đó có phương sai thấp hơn

Sau bước này trích xuất được các features:

features = [
    "ack_flag_cnt", "bwd_iat_max", "bwd_iat_mean", "bwd_iat_min", "bwd_iat_std",
    "bwd_iat_tot", "bwd_pkt_len_max", "bwd_pkts_s", "bwd_psh_flags","down_up_ratio",
    "ece_flag_cnt", "fin_flag_cnt", "flow_byts_s", "flow_duration", "fwd_iat_max",
    "fwd_psh_flags", "init_bwd_win_byts", "init_fwd_win_byts", "pkt_len_var", "pkt_size_avg",
    "psh_flag_cnt", "rst_flag_cnt", "syn_flag_cnt", "totlen_bwd_pkts", "totlen_fwd_pkts",
]

Còn nếu sử dụng RandomForest để đánh giá độ quan trọng của các đặc trưng (Feature Importance):

Từ đó chúng tôi chọn ra các đặc trưng có Features Importance đáng kể:

features =[
    'ack_flag_cnt', 'flow_duration', 'flow_iat_mean', 'flow_iat_max', 'init_fwd_win_byts','flow_pkts_s',
    'fwd_pkts_s', 'bwd_pkts_s', 'flow_byts_s', 'flow_iat_std', 'syn_flag_cnt', 'rst_flag_cnt', 'init_bwd_win_byts', 'fwd_iat_mean',
    'fwd_iat_std', 'tot_fwd_pkts', 'fwd_iat_tot', 'fwd_iat_max', 'subflow_fwd_byts', 'psh_flag_cnt', 'totlen_fwd_pkts', 'subflow_bwd_byts', 'fin_flag_cnt',
    'bwd_iat_min', 'subflow_fwd_pkts', 'bwd_iat_mean', 'totlen_bwd_pkts', 'bwd_iat_tot','subflow_bwd_pkts', 'bwd_pkt_len_mean', 'bwd_pkt_len_min', 'down_up_ratio',
    'bwd_iat_std', 'bwd_iat_max', 'bwd_seg_size_avg', 'fwd_pkt_len_mean', 'pkt_len_min','pkt_len_max', 'pkt_size_avg', 'bwd_pkt_len_mean',
]

Qua các feature selections được chọn từ cả 2 phương pháp trên, chúng tôi nhận thấy có sự overlap khá lớn giữa 2 tập đặc trưng được chọn. Do đó trong quá trình huấn luyện mô hình, chúng tôi sẽ lấy giao của 2 tập đặc trưng này:

Vậy các đặc trưng cuối cùng được lựa chọn là:

ack_flag_cnt
bwd_iat_max
bwd_iat_mean
bwd_iat_min
bwd_iat_std
bwd_iat_tot
bwd_pkts_s
down_up_ratio
fin_flag_cnt
flow_byts_s
flow_duration
fwd_iat_max
init_bwd_win_byts
init_fwd_win_byts
pkt_size_avg
psh_flag_cnt
rst_flag_cnt
syn_flag_cnt
totlen_bwd_pkts
totlen_fwd_pkts

5.3 Xử lý dataset

Với Scenario 11 của CTU-13 xảy ra hiện tượng mất cân bằng nghiêm trọng với tỷ lệ phân bố Normal: 120,642 (99.80%), Botnet: 238 (0.20%). Đây là thách thức rất lớn cho các mô hình vì chỉ cần một tỷ lệ nhỏ báo động nhầm (FPR) cũng có thể tạo ra hàng ngàn cảnh báo giả.

Để giải quyết, chúng tôi sử dụng Oversampling SMOTE + Tomek Links để cân bằng lại dữ liệu train trước khi đưa vào huấn luyện mô hình.

Dữ liệu train và test được chia stratify theo tỷ lệ 80:20.

SMOTE (Synthetic Minority Over-sampling Technique) là một kỹ thuật tạo mẫu mới bằng cách nội suy giữa các mẫu thiểu số hiện có để tạo ra các mẫu tổng hợp mới, thay vì chỉ sao chép các mẫu thiểu số hiện có. Tomek Links là một kỹ thuật làm sạch dữ liệu được sử dụng để loại bỏ các mẫu nhiễu và làm giảm sự chồng chéo giữa các lớp trong bộ dữ liệu bằng cách xác định và loại bỏ các cặp mẫu gần nhau từ các lớp khác nhau.

5.4 Kết quả huấn luyện

Kết quả train các model:

Model	TPR	FPR	Precision	F1-Score
Naive Bayes	100.0%	7.3%	2.7%	5.2%
Logistic Regression	97.9%	2.0%	9.0%	16.5%
Multilayer Perceptron	95.8%	0.0%	97.9%	96.8%
SimpleLogistic (Approx)	97.9%	2.1%	8.3%	15.4%
IBk (KNN)	97.9%	0.1%	64.4%	77.7%
Logit Boost	95.8%	0.0%	79.3%	86.8%
Random Committee	97.9%	0.1%	77.0%	86.2%
J48 (Decision Tree)	97.9%	0.1%	73.4%	83.9%
Random Forest	93.8%	0.0%	81.8%	87.4%
Random Tree	97.9%	0.1%	62.7%	76.4%
XGBoost	97.9%	1.8%	10.0%	18.1%
LightGBM	97.9%	0.1%	78.3%	87.0%
CatBoost	95.8%	0.1%	62.2%	75.4%
LSTM	95.8%	0.1%	67.6%	79.3%
CNN	95.8%	0.0%	100.0%	97.9%
CNN-LSTM	95.8%	0.0%	85.2%	90.2%

Top 3 model theo F1-Score

Quan sát Confusion matrix của CNN, MLP và CNN-LSTM cho thấy cả 3 mô hình đều xử lý tốt nhãn Normal (chỉ nhầm lẫn từ 0 đến 8 mẫu trên tổng số hơn 24.000 mẫu). Đối với nhãn Botnet, cả 3 mô hình đều bắt được khoảng 46/48 trường hợp tấn công. Điều này khẳng định độ tin cậy rất cao khi triển khai vào thực tế để bảo vệ hệ thống.

Precision-Recall curve

Biểu đồ Precision-Recall cho thấy rõ sự đánh đổi giữa TPR và Precision. Khi các mô hình cố gắng đẩy Recall (TPR) lên gần 100% để không bỏ sót tấn công, độ chính xác (Precision) của đa số mô hình (trừ CNN và MLP) đều bị sụt giảm nghiêm trọng.

Area Under Precision-Recall Curve

Model	PR-AUC
Multilayer Perceptron	0.9769
CatBoost	0.9631
CNN	0.9603
Random Forest	0.8995
Naive Bayes	0.8955
LightGBM	0.8900
Random Committee	0.8819
J48 (Decision Tree)	0.8661
CNN-LSTM	0.8606
Logit Boost	0.8602
Random Tree	0.8106
IBk (KNN)	0.8093
XGBoost	0.6806
LSTM	0.5447
SimpleLogistic (Approx)	0.0520
Logistic Regression	0.0481

So với kết quả ban đầu của bài báo:

Algorithms	Method 1 - TPR	Method 1 - FPR	Method 2 - TPR	Method 2 - FPR
NaiveBayes	60,0%	33,3%	50,0%	0,2%
Logistic	40,0%	50,0%	33,3%	0,0%
Multilayer Perceptron	40,0%	25,0%	33,3%	0,0%
SimpleLogist	0,0%	0,0%	25,0%	0,0%
IBk	20,0%	41,7%	58,3%	0,0%
CVR	40,0%	25,0%	33,3%	0,0%
Logit Boost	40,0%	16,7%	33,3%	0,0%
Random Committe	20,0%	33,3%	66,7%	0,0%
JRip	0,0%	16,7%	50,0%	0,0%
PART	60,0%	50,0%	50,0%	0,0%
J48	60,0%	50,0%	50,0%	0,0%
RandomForest	40,0%	25,0%	66,7%	0,0%
RandomTree	20,0%	16,7%	58,3%	0,0%

Sự cải thiện rõ rệt về cả TPR và FPR so với kết quả ban đầu của bài báo. Ngoài ra so với bài báo, chúng tôi tập trung đánh giá thêm các metrics như Precision, F1-Score và PR-AUC do đặc tính mất cân bằng dữ liệu nghiêm trọng của bài toán. Về mặt tổng quan:

Nhóm mô hình Deep Learning (CNN, LSTM, CNN-LSTM, Multilayer Perceptron) có kết quả vượt trội nhất trên tất cả các thông số đánh giá. Ví dụ như CNN đạt điểm F1-Score cao nhất (97.9%) với độ chính xác (Precision) tuyệt đối 100.0%. Điều này chứng tỏ CNN không hề đưa ra báo động giả nào trong khi vẫn bắt được 95.8% các cuộc tấn công. Multilayer Perceptron (MLP) có chỉ số PR-AUC cao nhất (0.9769), cho thấy khả năng phân loại cực kỳ ổn định và bền bỉ trên tập dữ liệu mất cân bằng.
Nhóm mô hình Machine Learning truyền thống (Naive Bayes, Logistic Regression, ...) có tỷ lệ bắt trúng (TPR) rất cao (từ 97.9% đến 100%), nhưng chúng lại thất bại trong việc kiểm soát báo động giả (FPR từ 2.0% đến 7.3%). Dù con số FPR này là nhỏ, nhưng do số lượng mẫu Normal rất lớn (hơn rất nhiều lần mẫu Botnet) → khi nhân với phần trăm này sẽ tạo ra con số rất lớn → nhiều cảnh báo giả. Điều này dẫn đến độ chính xác (Precision) cực kỳ thấp, ví dụ như Naive Bayes có Precision chỉ đạt 2.7%. Điều này có nghĩa là trong 100 cảnh báo hệ thống đưa ra, chỉ có chưa đầy 3 cái là tấn công thật, gây ra sự nhiễu loạn thông tin nghiêm trọng cho người quản trị.
Nhóm mô hình Boosting (Random Tree, Random Forest, LightGBM, CatBoost, ... trừ XGBoost): có kết quả khá tốt, gần tương đương với các model Deep Learning về cả 4 thông số. Với kết quả như này, nếu dùng trong thực tế với lưu lượng mạng lớn, các mô hình Machine Learning này sẽ được ưu tiên hơn do việc cấu hình, thời gian huấn luyện và dự đoán nhanh hơn nhiều so với Deep Learning. Trong phần xây dựng hệ thống, chúng tôi sẽ chọn mô hình LightGBM để triển khai.

5.5 Đề xuất các bộ dữ liệu khác

Do giới hạn thời gian, nhóm chỉ có thể thực hiện thí nghiệm trên bộ dữ liệu CTU-13. Tuy nhiên nhóm đã nghiên cứu và đề xuất thêm một số bộ dữ liệu khác có thể sử dụng để xây dựng/đánh giá mô hình phát hiện mã độc dựa trên NetFlow.

IoT-23 Dataset

Trang chủ: https://www.stratosphereips.org/datasets-iot23

IoT-23 là một dataset về lưu lượng mạng của các thiết bị IoT bị nhiễm malware, được công bố bởi Stratosphere IPS (SIP). Toàn bộ dữ liệu được thu thập trực tiếp từ các thiết bị IoT thật (camera IP, router, DVR, smart devices, ...) bị lây nhiễm malware và kết nối ra Internet trong điều kiện vận hành bình thường (DNS, NTP, update, cloud communication). Lưu lượng trong dataset có đầy đủ các lớp giao thức: Ethernet, IP, TCP/UDP, DNS, HTTP, TLS, MQTT (tùy thiết bị). Các đặc điểm của dataset phản ánh rõ đặc điểm của các thiết bị IoT trong thực tế:

Kết nối định kỳ, payload nhỏ
Ít session nhưng lặp lại liên tục
Nhiều scanning và outbound C2 traffic

Nội dung của dataset bao gồm 23 scenarios (20 malicious scenarios, 3 benign scenarios):

#	Name of Dataset	Duration (hrs)	#Packets	#ZeekFlows	Pcap Size	Name
1	CTU-IoT-Malware-Capture-34-1	24	233,000	23,146	121 MB	Mirai
2	CTU-IoT-Malware-Capture-43-1	1	82,000,000	67,321,810	6 GB	Mirai
3	CTU-IoT-Malware-Capture-44-1	2	1,309,000	238	1.7 GB	Mirai
4	CTU-IoT-Malware-Capture-49-1	8	18,000,000	5,410,562	1.3 GB	Mirai
5	CTU-IoT-Malware-Capture-52-1	24	64,000,000	19,781,379	4.6 GB	Mirai
6	CTU-IoT-Malware-Capture-20-1	24	50,000	3,210	3.9 MB	Torii
7	CTU-IoT-Malware-Capture-21-1	24	50,000	3,287	3.9 MB	Torii
8	CTU-IoT-Malware-Capture-42-1	8	24,000	4,427	2.8 MB	Trojan
9	CTU-IoT-Malware-Capture-60-1	24	271,000,000	3,581,029	21 GB	Gafgyt
10	CTU-IoT-Malware-Capture-17-1	24	109,000,000	54,659,864	7.8 GB	Kenjiro
11	CTU-IoT-Malware-Capture-36-1	24	13,000,000	13,645,107	992 MB	Okiru
12	CTU-IoT-Malware-Capture-33-1	24	54,000,000	54,454,592	3.9 GB	Kenjiro
13	CTU-IoT-Malware-Capture-8-1	24	23,000	10,404	2.1 MB	Hakai
14	CTU-IoT-Malware-Capture-35-1	24	46,000,000	10,447,796	3.6 GB	Mirai
15	CTU-IoT-Malware-Capture-48-1	24	13,000,000	3,394,347	1.2 GB	Mirai
16	CTU-IoT-Malware-Capture-39-1	7	73,000,000	73,568,982	5.3 GB	IRCBot
17	CTU-IoT-Malware-Capture-7-1	24	11,000,000	11,454,723	897 MB	Linux.Mirai
18	CTU-IoT-Malware-Capture-9-1	24	6,437,000	6,378,294	472 MB	Linux.Hajime
19	CTU-IoT-Malware-Capture-3-1	36	496,000	156,104	56 MB	Muhstik
20	CTU-IoT-Malware-Capture-1-1	112	1,686,000	1,008,749	140 MB	Hide and Seek

Bảng 1: IoT Malware Captures

#	Name of Dataset	Duration (~hrs)	#Packets	#ZeekFlows	Pcap Size	Device
21	CTU-Honeypot-Capture-7-1	1.4	8,276	139	2,094 KB	Somfy Door Lock
22	CTU-Honeypot-Capture-4-1	24	21,000	461	4,594 KB	Philips HUE
23	CTU-Honeypot-Capture-5-1	5.4	398,000	1,383	381 MB	Amazon Echo

Bảng 2: Benign IoT Captures

Mỗi scenario bao gồm:

File PCAP gốc
File flow (Zeek / NetFlow) trích xuất từ PCAP
Nhãn chi tiết ở mức flow và scenario. Nhãn không chỉ gồm Benign / Malware mà còn chỉ rõ malware family (Mirai, Hajime, Torii, Okiru, ...).

Các file flow (được trích xuất bằng Zeek hoặc NetFlow) chứa các trường thông tin hành vi, không phụ thuộc IP, bao gồm:

Thời gian: flow duration, inter-arrival time
Đặc trưng giao thức: protocol, TCP flags
Đặc trưng lưu lượng: total packets, total bytes, packet size statistics (mean, variance, ...)
Hướng kết nối (inbound / outbound)
Số lần kết nối lặp lại đến cùng dịch vụ

Những đặc trưng này giúp mô hình học hành vi botnet và malware, thay vì học thuộc địa chỉ IP.

Ưu điểm:
- Dữ liệu PCAP thực tế, phản ánh đúng hành vi IoT malware.
- Có nhãn malware family → hỗ trợ phân loại nâng cao.
-> Phù hợp nghiên cứu anomaly-based IDS và botnet detection.
Nhược điểm:
- Quy mô không lớn.
- Ít web attack phức tạp.
-> Không phù hợp để đánh giá IDS cho môi trường enterprise.

CSE-CIC-IDS2018 Dataset

Trang chủ https://www.unb.ca/cic/datasets/ids-2018.html

CICIDS 2018 là dataset được xây dựng bởi Canadian Institute for Cybersecurity (CIC) và Communications Security Establishment (CSE), mô phỏng một mạng doanh nghiệp lớn với nhiều dịch vụ, người dùng và kịch bản tấn công khác nhau. Dataset này cung cấp đầy đủ cả PCAP gốc và dữ liệu flow, nhằm phục vụ cho nhiều mục đích nghiên cứu khác nhau.

Các đặc điểm của dataset:

PCAP được capture trong môi trường testbed enterprise:
- Multiple subnets
- Web, Mail, FTP, SSH, Database servers
- User traffic song song với traffic tấn công
Traffic được sinh theo kịch bản có kiểm soát (controlled environment), nhưng:
- Công cụ tấn công là thật (Metasploit, LOIC, Slowloris, sqlmap, …)
- Giao thức và payload là thật
PCAP chứa đầy đủ:
- Normal user traffic
- Attack traffic theo từng ngày

→ PCAP không phải random synthetic traffic, mà là traffic thật trong môi trường giả lập.

Dataset được thu thập trong 10 ngày, mỗi ngày tập trung vào một hoặc vài loại attack:

Attack Type	Tools	Duration	Attacker	Victim
Bruteforce attack	FTP – Patator SSH – Patator	One day	Kali Linux	Ubuntu 16.4 (Web Server)
DoS attack	Hulk, GoldenEye, Slowloris, Slowhttptest	One day	Kali Linux	Ubuntu 16.4 (Apache)
DoS attack	Heartleech	One day	Kali Linux	Ubuntu 12.04 (OpenSSL)
Web attack	Damn Vulnerable Web App (DVWA) In-house Selenium framework (XSS, Brute-force)	Two days	Kali Linux	Ubuntu 16.4 (Web Server)
Infiltration attack	First level: Dropbox download (Windows machine) Second level: Nmap and port scan	Two days	Kali Linux	Windows Vista and Macintosh
Botnet attack	Ares (Python-based): remote shell, file upload/download, screenshots, key logging	One day	Kali Linux	Windows Vista, 7, 8.1, 10 (32-bit), and 10 (64-bit)
DDoS + Port Scan	Low Orbit Ion Canon (LOIC) – UDP, TCP, HTTP requests	Two days	Kali Linux	Windows Vista, 7, 8.1, 10 (32-bit), and 10 (64-bit)

Mỗi ngày bao gồm:

File PCAP gốc
File CSV flow trích xuất từ PCAP bằng CICFlowMeterV3

6. Xây dựng hệ thống xử lý dữ liệu stream với Kafka

Hệ thống vận hành bắt đầu từ việc thu thập lưu lượng mạng từ các máy ảo nhiễm botnet trong VMware thông qua card mạng VMNet8 ➜ Trên máy host, chạy CICNetflow để sniff ở chế độ realtime trên card mạng VMNet8 rồi trích xuất các đặc trưng netflow ➜ Dữ liệu sau trích xuất được gửi đến một service đóng vai trò producer để đẩy vào Kafka Netflow topic ➜ Một service sẽ đọc dữ liệu từ Kafka Netflow topic, đưa các dữ liệu này vào mô hình đã huấn luyện để phân loại ➜ Nếu kết quả nhận diện là Malware, một alert sẽ được sinh ra và gửi vào Kafka Alert topic ➜ Một service đọc từ Alert topic để lấy alert và gửi thông báo đến người dùng qua Telegram bot

Các thành phần chính của hệ thống:

Apache Kafka: Hệ thống message broker trung tâm kết nối các service trong hệ thống, giúp truyền tải luồng dữ liệu netflow và alert liên tục. Việc sử dụng Kafka trong hệ thống nhằm đảm bảo:
- Tính tách rời giữa các service: Mỗi service chỉ cần tập trung vào nhiệm vụ riêng của mình và có thể sử dụng các framework độc lập mà không cần quan tâm đến cách các service khác hoạt động. Các service chỉ giao tiếp với nhau thông qua Kafka. Điều này nhằm hướng đến kiến trúc microservices trong các hệ thống phức tạp.
- Xử lý dữ liệu stream: Kafka được thiết kế để xử lý luồng dữ liệu lớn với độ trễ thấp. Việc đẩy trực tiếp các bản ghi netflow vào model AI mà không thông qua Kafka có thể gây ra tắc nghẽn trong hệ thống do tốc độ trích xuất netflow từ CICFlowMeter và tốc độ xử lý của model AI có thể không đồng đều. Kafka sẽ giúp điều tiết luồng dữ liệu này, tránh tình trạng quá tải hay mất mát dữ liệu.
- Mở rộng cao và chịu lỗi: Kafka là một hệ thống phân tán, nó có thể hoạt động trên nhiều máy chủ khác nhau (Kafka cluster). Cả producer và consumer cũng có thể được triển khai trên nhiều instance (thông qua consumer group và Kafka partition), Kafka sẽ tự động điều phối tải giữa các instance này hoặc chuyển đổi khi có instance bị lỗi.
CICFlowMeter: Công cụ trích xuất đặc trưng netflow như đã đề cập ở phần trước. CICFlowMeter có thể được chạy ở chế độ realtime để liên tục trích xuất đặc trưng từ lưu lượng mạng thu thập được bằng cách:
```
# Cần chạy ở quyền root 
# Xem thêm trong runCICFlowMeter.sh
cicflowmeter -i <NETWORK_INTERFACE> -u <URL_ENDPOINT>
```
netflow producer: Service này đóng vai trò là producer trong mô hình publish-subscribe của Kafka. Nó nhận dữ liệu netflow trích xuất từ CICFlowMeter (qua HTTP POST request) và đẩy các bản ghi netflow này vào Kafka Netflow topic để các service khác có thể tiêu thụ. Service này được viết bằng Go để tối ưu hiệu năng.
netflow consumer alert producer: Service lấy dữ liệu netflow từ Kafka Netflow topic, đưa vào mô hình đã huấn luyện để phân loại. Nếu phát hiện mã độc, service sẽ sinh alert và đẩy vào Kafka Alert topic. Service này được viết bằng Python để dễ dàng tích hợp mô hình ML/DL đã huấn luyện.
alert consumer: Service này đọc alert từ Kafka Alert topic và gửi thông báo đến người dùng qua Telegram bot. Service này được viết bằng Go để tối ưu hiệu năng.

Minh họa việc triển khai hệ thống

SystemsDemo.mp4

Do một số hạn chế về môi trường và khả năng tái hiện mẫu mã độc, nhóm chưa thể tìm ra cách chạy lại botnet Rbot mà dataset CTU-13 đã sử dụng. Do đó, để mô phỏng lại lưu lượng mà botnet này sinh ra, chúng tôi gửi trực tiếp các bản ghi có nhãn botnet từ dataset vào Kafka Netflow topic để kiểm thử hệ thống. Xem trong netflow_botnet_test.py

🤝 Contributing

Supervised by: PhD. Tống Văn Vạn
Developed by: Chu Trung Anh 20225564, Bùi Duy Anh 20225563, Phạm Minh Tiến 20225555.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Netflow-Based Malware Detection and Data Visualization System

💡 Tại sao dùng Netflow

🎯 Mục tiêu:

Mục lục

Cách chạy 🏃 dự án

1. Dataset

2. Feature Extraction

2.1 Create labels

3. Machine-Learning Models

4. Data Visualization

5. Improvement compare to the paper

5.1 Trích xuất đặc trưng với CICFlowMeter

5.2 Lựa chọn đặc trưng

5.3 Xử lý dataset

5.4 Kết quả huấn luyện

5.5 Đề xuất các bộ dữ liệu khác

IoT-23 Dataset

CSE-CIC-IDS2018 Dataset

6. Xây dựng hệ thống xử lý dữ liệu stream với Kafka

🤝 Contributing

FilesExpand file tree

README.md

Latest commit

History

README.md

File metadata and controls

Netflow-Based Malware Detection and Data Visualization System

💡 Tại sao dùng Netflow

🎯 Mục tiêu:

Mục lục

Cách chạy 🏃 dự án

1. Dataset

2. Feature Extraction

2.1 Create labels

3. Machine-Learning Models

4. Data Visualization

5. Improvement compare to the paper

5.1 Trích xuất đặc trưng với CICFlowMeter

5.2 Lựa chọn đặc trưng

5.3 Xử lý dataset

5.4 Kết quả huấn luyện

5.5 Đề xuất các bộ dữ liệu khác

IoT-23 Dataset

CSE-CIC-IDS2018 Dataset

6. Xây dựng hệ thống xử lý dữ liệu stream với Kafka

🤝 Contributing