DEV Community

ZeroTrust Architect
ZeroTrust Architect

Posted on • Originally published at cacheguard.com

IoT Network Isolation: Zone Segmentation, Egress Filtering, and Why Your Smart TV Needs Its Own VLAN

#networking #security #devops #linux

IoT devices cannot protect themselves. They cannot run endpoint security software, enforce their own firewall policies, or detect behavioral anomalies. The only security layer that reliably covers them is one that operates at the network level, independently of what the device can do. Here is how to implement that technically.

IoT Network Isolation

The threat model for IoT devices

IoT compromise typically follows one of two paths: exploitation of a known vulnerability in the device's firmware (often never patched by the manufacturer), or brute-force of default or weak credentials via internet-exposed management interfaces.

Once compromised, the device is typically used for:

  • Botnet participation (DDoS, port scanning, spam relay)
  • Lateral movement to other devices on the same network segment
  • Data exfiltration if the device has access to sensitive internal resources
  • Persistent backdoor installation for long-term access

The key insight: the damage from a compromised IoT device is almost entirely determined by what else it can reach on the network. A compromised camera that can only reach its manufacturer's cloud service causes minimal harm. The same camera with unrestricted access to your file server is a serious breach.

Step 1: VLAN segmentation for IoT isolation

Place IoT devices on a dedicated VLAN, isolated from the internal LAN. The gateway enforces zone policy between VLANs.

# Create IoT VLAN (ID 20) on Linux gateway
ip link add link eth1 name eth1.20 type vlan id 20
ip addr add 192.168.20.1/24 dev eth1.20
ip link set eth1.20 up

# Internal LAN on eth1 (untagged, 192.168.1.0/24)
# IoT VLAN on eth1.20 (tagged, 192.168.20.0/24)
Enter fullscreen mode Exit fullscreen mode

On your managed switch, configure ports connected to IoT devices as access ports on VLAN 20. Ports connected to computers and servers remain on the native VLAN.

Step 2: Default-deny between IoT zone and internal LAN

By default, block all traffic from the IoT VLAN to the internal LAN:

# Drop all forwarded traffic from IoT VLAN to internal LAN
iptables -I FORWARD -i eth1.20 -o eth1 -j DROP

# Allow IoT to reach internet (via external interface eth0)
iptables -A FORWARD -i eth1.20 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -o eth1.20 -j ACCEPT
Enter fullscreen mode Exit fullscreen mode

If specific IoT devices need to reach specific internal resources (e.g., a printer that the internal network needs to reach), add explicit permit rules:

# Allow internal LAN to initiate connections to IoT printer only
iptables -A FORWARD -i eth1 -o eth1.20 -d 192.168.20.10 -p tcp --dport 9100 -j ACCEPT
iptables -A FORWARD -i eth1.20 -s 192.168.20.10 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
Enter fullscreen mode Exit fullscreen mode

Step 3: Egress filtering — restrict outbound destinations

Even within the IoT zone, restrict what external destinations each device type can reach. A smart TV should reach streaming service CDNs and its manufacturer's cloud — nothing else.

# Allow specific destination ranges for smart TV (192.168.20.5)
# Block everything else from that device
iptables -A FORWARD -i eth1.20 -s 192.168.20.5 -d 0.0.0.0/0 -j DROP
iptables -I FORWARD -i eth1.20 -s 192.168.20.5 -d 52.0.0.0/8 -j ACCEPT   # AWS (streaming CDNs)
iptables -I FORWARD -i eth1.20 -s 192.168.20.5 -d 17.0.0.0/8 -j ACCEPT   # Apple
Enter fullscreen mode Exit fullscreen mode

For broader category-based egress filtering (blocking known malicious IPs, C2 infrastructure, anonymizers) across the entire IoT VLAN, a URL filtering proxy in the traffic path is more maintainable than per-IP iptables rules.

Step 4: Gateway antivirus via ICAP

To scan traffic from IoT devices for malware (particularly relevant for devices that download firmware updates), route IoT web traffic through a Squid proxy with ICAP-based ClamAV scanning:

# squid.conf — transparent proxy for IoT VLAN
http_port 3128 intercept

# ICAP antivirus
icap_enable on
icap_service av_service reqmod_precache bypass=1 icap://127.0.0.1:1344/squid_clamav
adaptation_service_set av_service_set av_service
adaptation_access av_service_set allow all
Enter fullscreen mode Exit fullscreen mode

Redirect IoT VLAN HTTP traffic to the proxy:

iptables -t nat -A PREROUTING -i eth1.20 -p tcp --dport 80 -j REDIRECT --to-port 3128
Enter fullscreen mode Exit fullscreen mode

For HTTPS (dominant in modern IoT), transparent interception requires SSL inspection (ssl-bump). Without it, HTTPS traffic from IoT devices is tunneled uninspected.

Step 5: Traffic logging for anomaly detection

Log connection attempts from the IoT VLAN to destinations outside permitted ranges:

# Log dropped IoT traffic for anomaly detection
iptables -A FORWARD -i eth1.20 -j LOG --log-prefix "IoT-FORWARD-DROP: " --log-level 4
iptables -A FORWARD -i eth1.20 -j DROP
Enter fullscreen mode Exit fullscreen mode

Unusual patterns — a camera suddenly connecting to dozens of external IPs it has never contacted before, or an IoT device attempting connections to internal LAN ranges — are detectable in these logs before they escalate.

CacheGuard as a pre-integrated implementation

CacheGuard ships all of the above pre-integrated: zone-based firewall (external, internal/web with rweb VLAN, auxiliary/IoT zones), Squid transparent proxy with ICAP-based ClamAV, URL category filtering for egress control, and traffic logging — without manual iptables, Squid, and c-icap assembly.

→ https://www.cacheguard.com/secure-iot-devices-on-your-network/

Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.

Top comments (0)