Vấn đề thực tế: Kẻ xâm nhập thầm lặng và những điểm mù trên mạng
Trong một lần di chuyển dữ liệu lưu trữ định kỳ vào cuối tuần trên cụm máy chủ gia đình, một địa chỉ IP lạ đã thu hút sự chú ý của tôi: 192.168.1.184. Tra cứu nhanh địa chỉ MAC cho thấy đó là một ổ cắm thông minh Wi-Fi dùng nền tảng Tuya không tên tuổi, đang liên tục gửi ping đến các endpoint AWS ở xa mỗi bốn giây một lần.
Một người trong gia đình đã cắm nó vào ba tuần trước phía sau đèn ngủ rồi quên bẵng đi. Trong suốt hai mươi mốt ngày, một thiết bị IoT giá rẻ chạy firmware mã nguồn đóng nằm ngay trên subnet quản trị chính của tôi—chia sẻ lưu lượng broadcast Layer 2 với máy chủ ảo hóa Proxmox, các pool sao lưu TrueNAS và giao diện quản trị ngoài băng IPMI.
Hầu hết những người tự vận hành máy chủ tại gia (self-hoster) đều gặp phải điểm mù tương tự. Chúng ta chạy hypervisor, dựng lên hàng chục container, cấu hình Wi-Fi cho khách và gắn các thiết bị nhà thông minh vào switch riêng biệt. Nhưng trừ khi bạn liên tục quét mạng thủ công từ terminal, bạn sẽ không thể biết được thiết bị nào vừa kết nối vào mạng có dây hay không dây của mình lúc 2 giờ sáng. Thiết bị IoT chưa được kiểm duyệt, IP tĩnh lạ, laptop của khách ghé chơi, hoặc thậm chí là một vi điều khiển bị xâm nhập đều có thể lặng lẽ nằm trên subnet của bạn suốt nhiều tuần trước khi bị phát hiện.
Phân tích nguyên nhân gốc rễ: Tại sao router thông thường lại khiến bạn rơi vào thế bị động
Vì sao các router thương mại lại không thể lập tức phát hiện các thiết bị này? Các gateway tiêu chuẩn dành cho người dùng cá nhân và bán chuyên thường dựa vào các cơ chế thụ động vốn bỏ sót những hành vi mạng bất thường:
- Bản cấp phát DHCP thụ động, tạm thời: Hầu hết router gia đình và tường lửa phân khúc phổ thông chỉ hiển thị các lượt cấp phát DHCP đang hoạt động. Nếu một thiết bị khởi động với IP tĩnh chưa được chỉ định và nằm ngoài dải DHCP, bảng định tuyến sẽ không bao giờ ghi nhận nó. Một khi thời gian thuê IP (lease) hết hạn, dấu vết kiểm toán cũng biến mất hoàn toàn.
- Cô lập Layer 2 khỏi các Gateway Layer 3: Các thiết bị trên cùng một subnet cục bộ giao tiếp trực tiếp qua switch Ethernet ở Layer 2 thông qua giao thức phân giải địa chỉ ARP (Address Resolution Protocol). Trừ khi lưu lượng giao tiếp giữa các thiết bị này cần đi xuyên qua các subnet thông qua gateway mặc định, router sẽ không bao giờ kiểm tra các gói tin frame nội bộ đó.
- Không hỗ trợ Webhook nguyên bản: Firmware router thông thường chỉ ghi nhận sự kiện kết nối vào bộ đệm vòng (ring buffer) tạm thời trên RAM. Khi một địa chỉ MAC lạ kết nối vào điểm truy cập (access point), router chỉ âm thầm tăng một biến đếm thay vì kích hoạt webhook gửi cảnh báo về điện thoại của bạn.
So sánh các chiến lược phát hiện: Script vs Tường lửa vs NetAlertX
Những người quản trị HomeLab thường tiếp cận bài toán dò quét mạng theo một trong ba hướng:
- Viết script Cron tùy biến (Nmap / Arp-scan): Một bash script nhẹ có thể chạy
arp-scan --localnetmỗi năm phút một lần, so sánh kết quả đầu ra với file văn bản và gửi webhook qua curl khi phát hiện khác biệt. Cách này hoạt động được nhưng rất dễ lỗi. Các thiết bị di động khi vào chế độ ngủ sâu sẽ liên tục kích hoạt cảnh báo ngắt kết nối giả. Bạn cũng mất đi tính năng nhận diện nhà sản xuất qua MAC và lịch sử thời gian hoạt động (uptime). - Plugin tích hợp trên tường lửa (OPNsense / pfSense / MikroTik): Bạn có thể theo dõi bảng ARP và sự kiện DHCP bằng các script hoặc gói cài đặt sẵn trên tường lửa. Dù đáng tin cậy, giải pháp này lại gắn chặt pipeline thông báo vào phần cứng định tuyến cốt lõi. Ngoài ra, việc quét Nmap với tần suất dày đặc sẽ ngốn lượng chu kỳ CPU quý giá trên gateway biên của bạn.
- Công cụ giám sát mạng chuyên dụng (NetAlertX): NetAlertX—phiên bản kế thừa hiện đại của Pi.Alert—hoạt động dưới dạng một tiến trình nền (daemon) độc lập và gọn nhẹ. Nó kết hợp quét ARP chủ động, gửi ping ICMP và truy vấn DNS song song với việc tự động nhận diện nhà sản xuất thiết bị qua MAC. Khi một địa chỉ MAC chưa được phê duyệt phát đi gói tin broadcast đầu tiên, NetAlertX sẽ ghi lại sự kiện và đẩy thông báo tức thì về Discord, Telegram hoặc Pushover. Mức tiêu thụ RAM chỉ vào khoảng 120MB và mức sử dụng CPU duy trì dưới 2% trên mini PC trang bị chip Intel N100.
Giải pháp: Triển khai NetAlertX trên Docker
Đóng gói NetAlertX vào container mang lại khả năng lưu trữ dữ liệu bền vững và nâng cấp phiên bản dễ dàng mà không làm rác hệ điều hành máy chủ. Tuy nhiên, các công cụ dò quét mạng có một quy tắc bắt buộc: bạn phải bật chế độ mạng host (host networking).
Mạng bridge mặc định của Docker (docker0) đặt các container vào một namespace ảo tách biệt phía sau cơ chế NAT (Network Address Translation). Do các gói tin ARP request là gói broadcast Layer 2 không thể định tuyến, chúng không thể đi xuyên qua ranh giới mạng bridge đó. Việc thiết lập network_mode: "host" sẽ gắn NetAlertX trực tiếp vào card mạng vật lý của bạn (chẳng hạn như eth0 hoặc enp3s0), cung cấp cho bộ quét quyền truy cập trực tiếp vào lưu lượng broadcast trên toàn mạng nội bộ.
Bước 1: Tạo thư mục và phân quyền
SSH vào máy chủ Docker của bạn (chẳng hạn như Debian 12 hoặc Ubuntu 24.04 LTS) và tạo cấu trúc thư mục để lưu trữ trạng thái bền vững, cơ sở dữ liệu SQLite và file log:
mkdir -p ~/netalertx/config
mkdir -p ~/netalertx/db
mkdir -p ~/netalertx/log
cd ~/netalertx
Bước 2: Viết cấu hình Docker Compose
Tạo file compose của bạn:
nano docker-compose.yml
Dán cấu hình bên dưới vào. Lưu ý mục network_mode: "host", cấu hình này cho phép bộ quét bỏ qua mạng bridge ảo của Docker và nhìn thấy trực tiếp các card mạng vật lý của bạn:
services:
netalertx:
image: jokobsk/netalertx:latest
container_name: netalertx
restart: unless-stopped
network_mode: "host"
environment:
- TZ=America/New_York
- PORT=20211
- SCAN_SUBNETS=192.168.1.0/24
volumes:
- ./config:/app/config
- ./db:/app/db
- ./log:/app/log
Điều chỉnh SCAN_SUBNETS cho khớp với mạng LAN của bạn (ví dụ: 10.0.10.0/24 nếu bạn quét một subnet quản trị riêng). Đặt TZ theo chuỗi múi giờ chuẩn trong tz-database của khu vực bạn sinh sống.
Bước 3: Khởi chạy NetAlertX và kiểm tra log khởi động
Khởi chạy container ở chế độ chạy ngầm:
docker compose up -d
Theo dõi chuỗi log khởi động ban đầu để xác minh việc migration SQLite đã hoàn tất và quá trình liên kết raw socket đã thành công:
docker compose logs -f netalertx
Bạn sẽ thấy các thông báo xác nhận rằng cơ sở dữ liệu đã được khởi tạo và daemon ARP chạy nền đã bắt đầu hoạt động. Bây giờ hãy mở trình duyệt và truy cập vào:
http://<DOCKER_HOST_IP>:20211
Bước 4: Thiết lập danh sách thiết bị chuẩn và bật cảnh báo đẩy
Trong lần quét đầu tiên, NetAlertX sẽ đánh dấu mọi thiết bị tìm thấy là tài sản chưa xác định (unknown asset). Hãy dành ra hai mươi phút để rà soát lại danh sách này trước khi bật chế độ thông báo chủ động. Đặt tên rõ ràng cho từng máy chủ (ví dụ: “Living Room Apple TV 4K” hoặc “Dell R730 iDRAC”), chỉ định đúng loại thiết bị và đánh dấu phần cứng đó là Connected / Known (Đã kết nối / Đã biết).
Khi danh sách thiết bị tin cậy chuẩn đã được khóa lại, hãy cấu hình thông báo để nhận cảnh báo tức thì khi có bất kỳ thiết bị lạ nào xuất hiện trong tương lai:
- Trên giao diện web của NetAlertX, vào mục Settings > Alerting.
- Chọn nền tảng bạn muốn nhận tin (chẳng hạn như Telegram, Discord Webhook, hoặc Gotify).
- Đối với Telegram, nhập
Bot TokencùngChat IDdạng số của bạn, sau đó nhấn nút kiểm tra để xác nhận đã nhận được tin nhắn thử nghiệm. - Tích chọn vào ô
Alert on New Devices Found. - Chuyển sang mục Settings > Core và thiết lập chu kỳ quét. Chu kỳ 3 phút giúp phát hiện thiết bị lạ nhanh chóng mà vẫn giữ lưu lượng ARP broadcast ở mức dưới 15 gói tin mỗi giây trên toàn bộ subnet
/24tiêu chuẩn.
Bước 5: Kiểm thử luồng gửi cảnh báo
Kiểm tra thiết lập của bạn bằng cách đưa một thiết bị chưa có trong danh mục vào mạng. Hãy lấy một chiếc smartphone, mở cài đặt Wi-Fi, tắt tính năng “Dùng địa chỉ Wi-Fi riêng tư” (hoặc bật ngẫu nhiên hóa địa chỉ MAC) rồi kết nối lại vào mạng LAN. Bạn cũng có thể gán tạm thời một IP tĩnh chưa dùng cho một chiếc laptop phụ.
Trong vòng hai chu kỳ quét, NetAlertX sẽ gắn cờ địa chỉ MAC lạ, nhận diện tiền tố OUI của nhà sản xuất và đẩy thông báo trực tiếp về điện thoại của bạn:
[Cảnh báo NetAlertX]
Trạng thái: Phát hiện thiết bị mới
Địa chỉ IP: 192.168.1.184
Địa chỉ MAC: 4A:2B:11:89:C4:02 (Nhà sản xuất: Ngẫu nhiên / Không xác định)
Giao diện mạng: eth0
Xuất hiện lần đầu: 2026-10-14 11:15:00
Hệ thống HomeLab của bạn giờ đây đã duy trì được khả năng giám sát liên tục trên các phân đoạn mạng vật lý. Các thiết bị lạ sẽ không còn kết nối lén lút được nữa, và bạn sẽ nhận được thông báo trước khi bất kỳ thiết bị trái phép nào kịp thăm dò các dịch vụ nội bộ của mình.

