Posted inSecurity

Bảo Mật Thiết Bị IoT tại Nhà và trong HomeLab: Phân Vùng VLAN, Giám Sát Firmware và Chặn Kết Nối Đáng Ngờ

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Khi Bóng Đèn Thông Minh Trở Thành Điểm Yếu Nhất

Sau khi máy chủ của tôi bị tấn công brute-force SSH vào lúc nửa đêm, tôi bắt đầu kiểm tra lại toàn bộ mạng. Tôi nghĩ mối đe dọa đến từ bên ngoài. Nhưng nó đã ở ngay bên trong.

Mạng gia đình của tôi có một chiếc smart TV, ba camera IP, vài ổ cắm thông minh và một NAS — tất cả đều nằm trên cùng subnet với máy trạm và các máy chủ HomeLab. Mỗi thiết bị đều là một điểm có thể bị khai thác để tấn công tiếp. Chỉ cần một camera hub bị xâm nhập, kẻ tấn công quét từ bên trong có thể tiếp cận mọi thứ. Không có firewall nào ngăn cản chúng.

Nếu bạn đang chạy HomeLab hoặc chỉ có vài thiết bị nhà thông minh, đây là lỗ hổng mà bạn có thể chưa vá. Đây là cách thực sự khắc phục nó.

Tại Sao Thiết Bị IoT Dễ Bị Xâm Nhập Đến Vậy

Nguyên nhân gốc rễ thực ra rất bình thường. Thiết bị IoT được sản xuất để tiết kiệm chi phí và ra thị trường nhanh — bảo mật là thứ bị cắt bỏ đầu tiên khi lợi nhuận mỏng và thời hạn bị rút ngắn.

  • Thông tin đăng nhập mặc định mà không ai đổi: Chỉ cần tìm kiếm trên Shodan là thấy hàng chục nghìn camera vẫn đang dùng admin:admin nhiều năm sau khi mua. Một số hãng còn cứng hóa thông tin đăng nhập vào firmware.
  • Firmware không bao giờ được cập nhật: Hầu hết người dùng không bao giờ quay lại trang quản trị sau lần cài đặt đầu tiên. Bản vá tồn tại đó — nhưng không ai cài.
  • Không có lọc kết nối ra ngoài: Thiết bị bị xâm nhập có thể kết nối về máy chủ command-and-control, đánh cắp dữ liệu, hoặc quét mạng nội bộ của bạn. Cấu hình router mặc định sẽ không chặn bất kỳ điều nào trong số này.
  • Kiến trúc mạng phẳng: Khi mọi thiết bị dùng chung một subnet, di chuyển ngang (lateral movement) cực kỳ dễ dàng. Một thiết bị bị xâm nhập đồng nghĩa với toàn quyền truy cập nội bộ.

Điều tệ nhất là: bạn sẽ không biết. Botnet Mirai năm 2016 đã lặng lẽ lây nhiễm hơn 600.000 thiết bị và biến chúng thành đội quân DDoS — chủ sở hữu không hay biết gì cho đến khi ISP cảnh báo về lưu lượng bất thường. Các biến thể hiện đại cũng làm tương tự, âm thầm chạy crypto miner hoặc đánh cắp thông tin đăng nhập.

Ba Cách Tiếp Cận — Và Tại Sao Hai Cách Không Đủ

Cách 1: Chỉ Đổi Mật Khẩu Mặc Định

Cần thiết nhưng chưa đủ. Cách này chặn được các cuộc tấn công credential-stuffing cơ bản nhất. Lỗ hổng firmware, di chuyển ngang và kết nối ra ngoài trái phép vẫn hoàn toàn không được giải quyết. Bạn đang khóa cửa trước trong khi để ngỏ mọi ô cửa sổ.

Cách 2: Firewall Rules Mà Không Phân Vùng

Router tầm trung thường cho phép tạo ACL rules giữa các thiết bị trên mạng phẳng. Bạn có thể chặn smart TV truy cập trực tiếp vào NAS — tốt hơn không làm gì. Nhưng quản lý rules theo từng thiết bị trên subnet chung nhanh chóng trở nên lộn xộn. Một rule cấu hình sai sẽ âm thầm phá vỡ sự cô lập, và bạn mất hoàn toàn khả năng quan sát các mẫu lưu lượng giữa các thiết bị.

Cách 3: Phân Vùng VLAN + Lọc Kết Nối Ra Ngoài + Giám Sát Firmware

Cách này kết hợp cả ba biện pháp kiểm soát. Cô lập thiết bị IoT vào VLAN riêng, hạn chế lưu lượng ra ngoài chỉ ở mức thiết bị thực sự cần, và tự động hóa kiểm tra phiên bản firmware. Bạn cần một managed switch và router hỗ trợ VLAN — pfSense, OPNsense, hoặc UniFi gateway. Kết quả: bạn biết chính xác thiết bị nào đang nói chuyện với thiết bị nào, và bất cứ thứ gì vượt qua một lớp vẫn sẽ gặp lớp khác.

Cách 3 vượt trội trên mọi tiêu chí — cô lập, khả năng quan sát và khả năng mở rộng. Đây là cách xây dựng nó.

Xây Dựng Hệ Thống Bảo Vệ IoT Nhiều Lớp

Bước 1: Tạo và Cô Lập VLAN cho IoT

Dùng pfSense (hoặc OPNsense — cùng khái niệm), tạo một VLAN mới cho lưu lượng IoT. Tôi dùng VLAN tag 20 và subnet 192.168.20.0/24.

# pfSense: Interfaces → Assignments → VLANs → Add
# VLAN Tag: 20
# Parent Interface: cổng LAN của bạn (ví dụ: igb1)
# Description: IoT_VLAN

Gán interface, cấu hình DHCP cho 192.168.20.0/24, sau đó thêm firewall rules. Hai rules là đủ:

# pfSense Firewall Rules — IoT_VLAN interface
# Rule 1: Chặn IoT → LAN (mạng chính 192.168.1.0/24 của bạn)
# Action: Block | Source: IoT_VLAN net | Destination: LAN net

# Rule 2: Chỉ cho phép IoT → Internet
# Action: Pass | Source: IoT_VLAN net | Destination: !RFC1918
# Alias RFC1918 tích hợp sẵn của pfSense bao gồm 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Trên managed switch, gắn tag VLAN 20 cho các cổng kết nối thiết bị IoT:

# CLI managed switch (kiểu Cisco IOS — cú pháp có thể khác tùy hãng)
vlan database
  vlan 20 name IoT
interface range GigabitEthernet0/5-8
  switchport mode access
  switchport access vlan 20

Với Wi-Fi, tạo một SSID riêng được ánh xạ vào VLAN 20. Trên UniFi, đó là Networks → Create New Network → VLAN Only, sau đó gán vào mạng không dây mới. Thiết bị IoT kết nối vào SSID đó và không bao giờ thấy mạng LAN chính.

Bước 2: Tự Động Hóa Giám Sát Phiên Bản Firmware

Kiểm tra thủ công không hiệu quả — bạn sẽ quên trong vòng một tuần. Một script poll API của thiết bị để lấy thông tin phiên bản và cảnh báo khi có thay đổi chỉ mất một giờ để cài đặt và chạy mãi sau đó.

import requests
import smtplib
from email.mime.text import MIMEText

# Cập nhật dict này mỗi khi bạn cố ý áp dụng bản cập nhật firmware
KNOWN_VERSIONS = {
    "camera_livingroom": "2.4.1",
    "smart_tv": "1.8.0",
}

def check_firmware(device_name, device_url, known_version):
    try:
        # verify=False là cố ý — thiết bị LAN thường dùng self-signed certs
        resp = requests.get(device_url, timeout=5, verify=False)
        data = resp.json()
        live_version = data.get("firmware_version", "unknown")
        if live_version != known_version:
            return f"[CẢNH BÁO] {device_name}: {known_version} → {live_version}"
        return None
    except Exception as e:
        return f"[LỖI] {device_name}: kiểm tra thất bại ({e})"

def send_email_alert(alerts, smtp_host, smtp_port, username, password, to_addr):
    body = "\n".join(alerts)
    msg = MIMEText(body)
    msg["Subject"] = "Phát hiện thay đổi phiên bản firmware"
    msg["From"] = username
    msg["To"] = to_addr
    with smtplib.SMTP_SSL(smtp_host, smtp_port) as server:
        server.login(username, password)
        server.sendmail(username, to_addr, msg.as_string())

if __name__ == "__main__":
    # Điều chỉnh endpoints để khớp với đường dẫn API thực tế của thiết bị
    devices = [
        ("camera_livingroom", "http://192.168.20.5/api/version", KNOWN_VERSIONS["camera_livingroom"]),
        ("smart_tv", "http://192.168.20.10/status", KNOWN_VERSIONS["smart_tv"]),
    ]
    alerts = [check_firmware(n, u, v) for n, u, v in devices]
    alerts = [a for a in alerts if a]
    if alerts:
        print("\n".join(alerts))
        # Bỏ comment để bật cảnh báo qua email:
        # send_email_alert(alerts, "smtp.gmail.com", 465, "[email protected]", "app_password", "[email protected]")

Lên lịch chạy hàng ngày bằng cron job:

crontab -e
# Thêm dòng này:
0 8 * * * /usr/bin/python3 /home/user/scripts/check_firmware.py >> /var/log/firmware_check.log 2>&1

Không phải thiết bị nào cũng có API rõ ràng — một số cần scrape web UI, số khác phải kiểm tra thủ công trang phát hành của nhà sản xuất. Khó chịu khi cấu hình lần đầu. Nhưng tự động từ đó về sau.

Bước 3: Phát Hiện Kết Nối Ra Ngoài Bất Thường

Phân vùng VLAN ngăn di chuyển ngang, nhưng thiết bị IoT vẫn có thể kết nối ra internet. Thiết bị bị xâm nhập có thể beacon đến máy chủ C2 trên cổng 4444, đánh cắp dữ liệu lên IP cloud lạ, hoặc thực hiện các truy vấn DNS lúc 3 giờ sáng trông hoàn toàn không giống lưu lượng hợp lệ. Hai phương pháp sau sẽ bắt được điều này.

Phương pháp A — DNS sinkhole với Pi-hole: Trỏ DNS DHCP của IoT VLAN vào một Pi-hole. Bất kỳ thiết bị nào truy vấn domain độc hại đã biết sẽ bị chặn và ghi log tự động.

# Trong pfSense, cho DHCP server của IoT_VLAN:
# DNS Server 1: 192.168.20.2  (IP Pi-hole của bạn trên segment IoT)

# Trên Pi-hole, theo dõi log truy vấn theo thời gian thực từ thiết bị IoT:
pihole -t

# Hoặc mở dashboard thống kê:
pihole -c

Phương pháp B — Baseline bắt gói tin: Chạy tcpdump trên host giám sát trong 24–48 giờ sau khi thêm thiết bị mới. Điều này xây dựng bức tranh về những gì thiết bị thường kết nối. Các bất thường trong tương lai sẽ nổi bật rõ ràng so với baseline đó.

# Bắt lưu lượng IoT đi ra ngoài (bao gồm cả ba dải RFC1918)
sudo tcpdump -i eth0 -nn \
  'src net 192.168.20.0/24 and dst net not (192.168.0.0/16 or 10.0.0.0/8 or 172.16.0.0/12)' \
  -w /tmp/iot_baseline.pcap

# Sau khi bắt gói, tóm tắt IP đích theo tần suất:
# Trong output tcpdump -nn, trường thứ 5 là IP:port đích
tcpdump -r /tmp/iot_baseline.pcap -nn \
  | awk '{print $5}' | cut -d. -f1-4 \
  | sort | uniq -c | sort -rn | head -20

Một camera gửi ping đến IP lạ trên cổng 4444 lúc 3 giờ sáng không phải là đang kiểm tra cập nhật firmware. Hãy đối chiếu bất cứ thứ gì đáng ngờ với VirusTotal hoặc AbuseIPDB trước khi quyết định chặn.

Checklist Tôi Dùng cho Mỗi Thiết Bị IoT Mới

Khi cơ sở hạ tầng đã được dựng lên, việc thêm thiết bị mới chỉ mất chưa đến mười phút:

  1. Đổi thông tin đăng nhập mặc định trước khi kết nối vào bất kỳ mạng nào — offline nếu có thể.
  2. Kết nối vào SSID IoT (VLAN 20) — không bao giờ vào LAN chính.
  3. Thêm phiên bản firmware hiện tại của thiết bị vào script giám sát.
  4. Theo dõi log Pi-hole trong 24 giờ và chặn ngay bất kỳ domain đáng ngờ nào.
  5. Thắt chặt rules ra ngoài: hầu hết thiết bị chỉ cần cổng 80 và 443. Chặn mọi thứ còn lại ở cấp firewall VLAN.

Cài đặt ban đầu mất vài giờ. Sau đó, mỗi thiết bị mới chỉ tốn vài phút — công sức bỏ ra sinh lợi kép khi bộ sưu tập thiết bị của bạn ngày càng lớn.

Sau sự cố SSH lúc nửa đêm đó, tôi thà bỏ ra vài giờ từ trước còn hơn phải xử lý một vụ xâm nhập đang diễn ra lúc 2 giờ sáng.

Bài học thực sự: bảo mật IoT không phải là tin tưởng mọi thiết bị sẽ hoạt động đúng. Bạn không thể sửa các quyết định firmware của nhà sản xuất. Mấu chốt là thiết kế mạng sao cho khi một thiết bị bị xâm nhập, thiệt hại nằm gọn trong một VLAN thay vì lan rộng khắp HomeLab. Đó chính xác là thứ mà phân vùng mang lại cho bạn.

Share:
Tags: