Jordan has been hanging around the tech industry for 25 years now and was baited hook, line, and sinker by Napster. He’s been part of the Black Hills Information Security team for a decade in various capacities and has been a part of Antisyphon Training’s amazing growth trajectory as an instructor.

tl;dr 

Implement this ACL using whatever network gear, cloud ACL config, or uncomplicated firewall you use to protect your networks. Our IOT devices are on 10.99.99.0/24 for this example. Also, don’t use non-RFC 1918 addressing on your internal networks. Depending on your configuration, the following pseudo-logic in the format of <allow or deny> <IP.Source> <IP.Destination> <protocol> should work universally.

deny 10.99.99.0/24 10.0.0.0/8 any 

deny 10.99.99.0/24 172.16.0.0/12 any 

deny 10.99.99.0/24 192.168.0.0/16 any 

allow 10.99.99.0/24 0.0.0.0/0 any 

The Verbose Version 

Imagine this — you are implementing a new netblock for your Roku TVs, IOT devices, and wireless guests. They all need internet access and under no circumstances do they need access to anything else. When they get a DHCP lease from your network, you should provide them with a public DNS server or two in the lease offer. Not all resolvers were created equally, but OpenDNS and a few others may offer you a bit more privacy than the others.  

Once your hosts have been provided a public IP address or two for name resolution, the following ACL will result in your TVs being blocked from accessing anything RFC-1918 in four short and sweet lines. This specific configuration will keep these hosts from accessing anything you address on standard internal network ranges.  

deny 10.99.99.0/24 10.0.0.0/8 any 

deny 10.99.99.0/24 172.16.0.0/12 any 

deny 10.99.99.0/24 192.168.0.0/16 any 

allow 10.99.99.0/24 any any 

This will allow the segment to talk to any public IP address. That’s it, that’s all. 

Thanks for reading,  

-jd