Giám sát lưu lượng mạng: So sánh các phương pháp tiếp cận
Các bộ đếm interface tiêu chuẩn và biểu đồ SNMP chỉ cho biết bạn đang sử dụng bao nhiêu băng thông, nhưng không bao giờ cho biết ứng dụng nào đang sử dụng lượng băng thông đó. Khi đường truyền upstream bị nghẽn lúc 2 giờ sáng, các đội ngũ kỹ sư thường dựa vào một trong ba chiến lược giám sát sau:
- Công cụ phân tích luồng Layer 3/4 (NetFlow / sFlow / IPFIX): Phù hợp cho các core router xử lý đường truyền từ 40Gbps trở lên. Router sẽ lấy mẫu header của gói tin (thường là 1 trên 1.000 gói) và tóm tắt kết nối theo địa chỉ IP cùng cổng (port). Vấn đề là gì? Số hiệu cổng không còn phản ánh đúng thực tế. Một tác vụ sao lưu 80GB trái phép, cuộc gọi video qua Zoom hay tiến trình đồng bộ cơ sở dữ liệu hợp lệ đều có thể chạy qua cổng 443. Việc lấy mẫu luồng sẽ coi chúng hoàn toàn giống nhau.
- Bắt gói tin thô (tcpdump / Wireshark): Thu thập từng byte truyền qua đường truyền. Đây là tiêu chuẩn vàng để phân tích sâu các lỗi giao thức phức tạp. Tuy nhiên, việc bắt gói trên đường truyền 1Gbps đang bão hòa sẽ tạo ra khoảng 450GB dữ liệu PCAP thô mỗi giờ. Việc lưu trữ, lập chỉ mục và truy vấn khối lượng dữ liệu khổng lồ đó sẽ nhanh chóng trở nên bất khả thi khi cần xử lý sự cố trực tiếp.
- Kiểm tra sâu gói tin theo thời gian thực (ntopng + nDPI): Kết hợp tốc độ theo dõi luồng với khả năng kiểm tra giao thức. Bằng cách chỉ phân tích 10 đến 15 gói tin đầu tiên của mỗi phiên, thư viện nDPI tích hợp sẽ kiểm tra TLS SNI header, truy vấn DNS và siêu dữ liệu HTTP. Phương pháp này phân loại lưu lượng mà không cần lưu toàn bộ payload, giúp kiểm soát tốt mức sử dụng CPU và ổ đĩa.
Ưu và nhược điểm của Layer 7 DPI với ntopng
Mọi kiến trúc giám sát đều có sự đánh đổi. Dưới đây là những yếu tố cần cân nhắc trước khi triển khai ntopng vào môi trường của bạn.
Ưu điểm
- Nhận diện giao thức chính xác: Xác định lưu lượng dựa trên hành vi và siêu dữ liệu bắt tay (handshake) thay vì số hiệu cổng. Hệ thống nhận diện đáng tin cậy BitTorrent, Zoom, các lệnh gọi GitHub API và lưu lượng cơ sở dữ liệu ngay cả khi chúng được ẩn sau các cổng tiêu chuẩn.
- Chỉ số sức khỏe TCP trực tiếp: Theo dõi thời gian trễ khứ hồi (RTT), tỷ lệ truyền lại gói tin (retransmission) và các gói tin sai thứ tự theo từng máy chủ trong thời gian thực.
- Tối ưu Disk I/O: Tránh ghi các file PCAP dung lượng lớn vào ổ đĩa. Trạng thái luồng hoạt động được lưu trực tiếp trong bộ nhớ RAM và các key Redis cục bộ, chỉ ghi lại các dữ liệu tổng hợp nhẹ để phục vụ theo dõi xu hướng dài hạn.
- Giám sát không cần agent: Hoạt động hoàn toàn theo cơ chế out-of-band qua cổng network TAP hoặc switch mirror (SPAN). Bạn không cần can thiệp hay cài đặt bất kỳ agent nào trên các máy chủ production.
Nhược điểm
- Yêu cầu dung lượng bộ nhớ lớn: Việc theo dõi trạng thái (stateful tracking) đòi hỏi dung lượng RAM chuyên dụng. Cần chuẩn bị khoảng 1GB đến 2GB RAM cho mỗi 100.000 luồng đồng thời đang hoạt động. Nếu xảy ra đợt tấn công SYN flood đột ngột làm đầy bảng trạng thái, ntopng sẽ bỏ qua các bản ghi luồng mới.
- Chi phí xử lý của Kernel trên đường truyền tốc độ cao: Cơ chế bắt gói qua socket tiêu chuẩn của Linux bắt đầu rớt gói khi lưu lượng vượt quá 3Gbps đến 5Gbps. Các đường truyền 10Gbps trở lên bị bão hòa sẽ yêu cầu các driver zero-copy bypass kernel như PF_RING ZC hoặc AF_XDP.
- Không giải mã payload: nDPI chỉ phân tích các bước bắt tay ban đầu, thỏa thuận bộ mã hóa (cipher negotiation) và tên miền từ TLS Client Hello. Công cụ không thể kiểm tra phần thân request đã mã hóa hoặc dữ liệu ứng dụng được mã hóa.
Kiến trúc đề xuất cho môi trường Production
Một máy chủ thu thập lưu lượng (tapping instance) chuyên dụng sẽ cung cấp câu trả lời tức thì khi xảy ra sự cố băng thông mà không làm quá tải đội ngũ kỹ sư với các file dump dữ liệu thô.
Để bắt gói tin ổn định trên đường truyền từ 1Gbps đến 10Gbps, hãy thiết lập một máy chủ Linux chuyên dụng với hai giao diện mạng (network interface) vật lý:
eth0: Interface quản trị. Gán một địa chỉ IP nội bộ cô lập để truy cập SSH và giao diện web UI.eth1: Interface thu thập gói tin chuyên dụng. Chạy interface này ở chế độ promiscuous và không gán địa chỉ IP, kết nối trực tiếp đến cổng network TAP hoặc switch SPAN.- Redis: Lắng nghe cục bộ tại
127.0.0.1:6379để duy trì các bộ đếm luồng và bảng máy chủ (host table) tốc độ cao trong bộ nhớ.
Hướng dẫn triển khai từng bước
Hướng dẫn triển khai này áp dụng cho Ubuntu 22.04 và Debian 12 LTS, sử dụng các bản build chính thức từ repository của ntop để cập nhật chữ ký giao thức mới nhất.
Bước 1: Cài đặt Redis và các gói phụ thuộc cơ bản
Cài đặt các gói phụ thuộc và khởi động Redis:
sudo apt update && sudo apt install -y software-properties-common wget curl lsb-release gnupg redis-server
# Bật và kiểm tra Redis
sudo systemctl enable --now redis-server
sudo redis-cli ping
# Kết quả mong đợi: PONGThêm gói repository chính thức của ntop:
# Tải xuống và cài đặt gói định nghĩa repository
wget https://packages.ntop.org/apt/22.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
# Cập nhật lại danh sách gói từ repository
sudo apt updateBước 2: Cài đặt ntopng và nDPI
Cài đặt ntopng cùng với thư viện giao thức nDPI và mô-đun kernel PF_RING (tùy chọn):
sudo apt install -y ntopng pfring-dkmsBước 3: Cấu hình ntopng
ntopng đọc các tham số khởi động từ file /etc/ntopng/ntopng.conf. Mở file cấu hình:
sudo nano /etc/ntopng/ntopng.confThay thế nội dung file bằng cấu hình bên dưới. Cập nhật eth1 tương ứng với capture interface của bạn và điều chỉnh dải mạng CIDR cho phù hợp với môi trường hệ thống:
# File PID của tiến trình daemon
-G=/var/run/ntopng.pid
# Cổng lắng nghe HTTP
-w=3000
# Interface bắt gói chuyên dụng (chế độ promiscuous, không có IP)
-i=eth1
# Định nghĩa dải mạng nội bộ để phân biệt lưu lượng vào và ra
-m=192.168.1.0/24,10.0.0.0/8
# Endpoint kết nối đến Redis
-r=127.0.0.1:6379
# Vô hiệu hóa phân giải DNS chủ động để giảm tải CPU khi lưu lượng cao
-n=1
# Chế độ bản quyền Community
--communityBước 4: Cấu hình Interface thu thập dữ liệu
Interface giám sát phải hoạt động ở chế độ promiscuous để bắt các frame không gửi trực tiếp đến địa chỉ MAC của nó:
sudo ip link set dev eth1 promisc on
sudo ip link set dev eth1 upTạo một systemd unit để duy trì chế độ promiscuous sau khi khởi động lại máy chủ:
sudo tee /etc/systemd/system/promisc-interface.service << 'EOF'
[Unit]
Description=Bật chế độ Promiscuous trên Capture Interface
After=network.target
[Service]
Type=oneshot
ExecStart=/sbin/ip link set dev eth1 promisc on
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable promisc-interface.serviceBước 5: Khởi động ntopng và đăng nhập
Khởi động dịch vụ và theo dõi nhật ký systemd journal để kiểm tra các lỗi khởi tạo:
sudo systemctl restart ntopng
sudo systemctl enable ntopng
sudo journalctl -u ntopng -fMở trình duyệt và truy cập http://<server-management-ip>:3000.
- Tên đăng nhập mặc định:
admin - Mật khẩu mặc định:
admin
ntopng sẽ yêu cầu bạn đổi mật khẩu mặc định ngay lập tức trước khi cấp quyền truy cập vào dashboard.
Bước 6: Quy trình xử lý sự cố thực tế
Khi lưu lượng đã đi vào capture interface, hãy tập trung vào các giao diện sau để chẩn đoán sự cố vận hành:
- Xác định chính xác đối tượng tiêu tốn nhiều băng thông: Truy cập Flows > Active Flows. Sắp xếp theo Throughput. Kiểm tra cột Application để xem lưu lượng tăng đột biến là do đồng bộ cơ sở dữ liệu (
PostgreSQL), truyền dữ liệu lưu trữ đám mây dung lượng lớn (AmazonAWS.S3) hay các bản cập nhật hệ thống chạy nền. - Chẩn đoán mất gói và độ trễ mạng: Vào Hosts > Local Hosts, chọn máy chủ có lưu lượng cao và mở mục TCP / Metrics. Tỷ lệ truyền lại gói tin TCP (retransmission) trên 1,5% hoặc giá trị RTT từ client đến server vượt quá 100ms thường là dấu hiệu của cáp mạng hỏng, xung đột duplex hoặc nghẽn hàng đợi (buffer) trên switch.
- Phát hiện các hoạt động gửi ra bất thường: Mở bảng Alerts để kiểm tra các cảnh báo bảo mật thời gian thực. Chú ý các mức tăng đột biến bất thường về số lượng truy vấn DNS mỗi giây, kết nối SSH chiều ra bất ngờ từ các web server hoặc các phiên bắt tay TLS dị thường trỏ tới các dải IP không đáng tin cậy.
