Post

Network segmentation with OpenWrt for better smart TV security

Posted Updated
By Robin W. Hunter
16 min read

Motivation

I recently bought a smart TV, and in order to make full use of, I would like to connect to the Internet. However, connecting the TV directly to my router, to gain Internet access, would by the same occasion, give it the ability to communicate with every other device connected to my local network. I would like to prohibit that, and isolate the TV so that it can only reach the Internet, and cannot see any other device connected locally. This would be very helpful In the case the TV ever becomes compromised in the future (which, admittedly, is very probable1234) or in case its software gets too nosy, and tries to snoop around on my network (as so many TVs regularly do567).

In my last article, I walked you through the installation, and initial configuration of OpenWrt on a Fritz!Box 7430. In this article, I will be explaining how I used a few of the many features offered by OpenWrt in order to segment my network in the way described above. I will also make a short showcase of how I made use of Pi-hole’s DNS filtering, to limit some of the ads, and tracking which my TV is sure to attempt during its regular operation when connected to the Internet.

Layer 2 segmentation using VLANs

The first step in segmenting the TV is to do so at layer 2 of the networking stack. This can be achieved by creating a VLAN to be exclusively used by the TV. I have touched more on OpenWrt’s VLAN configuration in the relevant section of my last article. Previously, I had set a WAN VLAN in order to isolate one of the LAN ports on my router to use for WAN access. We will be following the same two step-configuration as we did then.

Step 1: Setting up the TV VLAN

The first step consists on creating a VLAN for the TV. As the router only has three available ports (four, but one is used for WAN in my configuration), I opted to use a single port for the new TV VLAN (port LAN 4). I don’t see myself connecting any other device to the same LAN as the TV, and if I ever need to do that, a switch will be more than enough for that.

As explained in my previous article, the required settings for the different ports in regards to the new TV VLAN are as follows:

  • LAN 4 needs to be set as “untagged”.
  • CPU (eth0) port is set as “tagged”.
  • The remaining ports (LAN 1to LAN 3) are set to be “off”. I am using VLAN ID 3 for the TV VLAN, and using the descriptive “TV” for better readability. Figure 1 shows the Switch configuration page with the new settings.

Figure 1: OpenWrt switch configuration for a separate TV VLAN Figure 1: OpenWrt switch configuration for a separate TV VLAN

Step 2: Creating a TV network interface

Having created the VLAN to be used for the TV, we now need to configure a corresponding network interface. The TV LAN network will be its own independent LAN, as such we will be using a similar configuration as we used previously for the LAN interface. Following is a summary of what needs to be configured in the new TV_LAN interface.

  • Device: eth0.3, our newly created VLAN with ID 3.
  • Protocol: Static IP (since we will not be connecting to another DHCP server).
  • IPv4 address and mask: 192.168.2.1/24, important to note that this subnet needs to be different from those used previously (192.168.0.1/24 is already used upstream of the OpenWrt router by my ISP router, and I am using 192.168.1.1/24 on the LAN network used for the other two ports of OpenWrt). Using a /24 subnet mask is overkill as I do not plan to connect other devices on this interface other than the TV, still, I like the clear separation of subnets, and if I ever run out of addresses I can always come back and change this.
  • Firewall zone: I created a new firewall zone labeled TV. We will configure this zone in the next section.
  • DHCP server: Enabled.

Layer 3 segmentation using a firewall

As it stands right now, the TV is correctly segregated within its own VLAN. This means that as far as Layer 2 is concerned, the TV is separated from other devices on the network. More concretely, the TV will not be able to send any Layer 2 frames, addressed to devices out of its VLAN. However, anything happening above layer 2 in the network stack, is out of control of the OpenWrt switch, and will go over the VLAN setting we have configured. Specifically, devices from the TV VLAN will be able to reach devices out of their VLAN as long as they know and use their IP address. In this case, the switch will simply relay Layer 3 packets up the chain to the onboard router, at which point VLAN tagging is irrelevant. The router will then happily route these packets to the corresponding destination network. This routing takes place unless the router has firewall rules forbidding it from doing so.

OpenWrt uses fw3 for firewall management, which itself uses iptables8. The way iptables functions is as follows:

  1. Rules are defined for different interfaces. Each rule defines pre-conditions which a packet must fulfill in order for the rule to apply to it (e.g. interface, IP address, and/or port used for the source and/or destination). Each rule also defines an action which shall be taken on any packet which fulfills its preconditions (e.g. reject, accept, drop, etc).
  2. Firewall rules are maintained in a table, and when a packet reaches the router, this table is examined from the top down. The first rule for which the packet fulfills the preconditions applies.
  3. Once a rule which applies is found, the rule table is exited. The action defined by the rule is then applied to the packet, and the router moves to handling the next packet.

Iptables uses its own syntax which isn’t the easiest to understand, and with which I am not very familiar at the moment. Thankfully, we do not need to dive deep into the formatting of iptables configuration files, nor do we even have to deal with fw3. Firewall configuration can be achieved through OpenWrt’s web interface, under Network > Firewall.

The first thing to do is to set the default policy for our newly created TV firewall zone, this can be achieved in the General Settings tab of the Firewall configuration page. These policies shall apply to all packets entering or leaving the zone, but only if no other rule is found to be applicable beforehand. As such, these default policy translate into rules, which are tacked at the end of the section of the rules table relevant to the corresponding zone. This way, when the rules are examined, these policy take effect only if no other rule applies. The default policies we will be setting are:

  • Input: This policy controls traffic emanating from the router and entering the TV zone. Although I am currently not planning on using any such traffic, I will leave this policy set to “Accept”.
  • Output: This controls traffic leaving the TV zone end entering the router. Setting this policy to “Accept” is needed to allow entry of requests sent from the TV towards the router.
    Additionally, I will need to define an additional rule later on, to allow such traffic to be forwarded to the WAN zone after it was allowed into the router. This is required for the Internet to be reachable from the TV zone (we will learn how to do that in the following paragraph).
    Moreover, because I do not want devices from the TV zone to be able to discover other devices on my LAN, I will need to add rules which would apply before this default policy. The rules we will add later will reject all traffic destined to addresses present on the local network. That way, only traffic addressed to non-local destinations (i.e. to the Internet) will be let through.
  • Forwarding: This controls the forwarding of packets between different networks belonging to the same firewall zone. As such, this setting controls intra-zone forwarding. I currently only have a single network in the TV firewall zone (TV_LAN), so this policy is not relevant to me. However, if in the future I decide to connect another network to this zone, I think I still would not want devices from those networks to be reachable by the TV. As such I set the default forwarding policy to be “Reject”.

In addition to the intra-zone forwarding policies defined above, an option to control inter-zone forwarding policies also exists in the General Settings tab. In our case, we will need to define one additional inter-zone forwarding policy. Namely, we need to allow forwarding from TVto the WANzone in order for the TV to be able to reach the Internet.

Finally, Masquerading is one more available firewall setting. Without getting into it, masquerading relates to how routers handle translating non-unique internal/local IP addresses to unique external/public IP addresses, this process is known as Network Address Translation (NAT)9. This is not something we need our router to do when forwarding traffic between different zones, so we will not be setting this option in our configuration.

Figure 2 shows what the firewall configuration section looks like after our modifications. The last line in the zones table summarizes our newly added settings.

Figure 2: OpenWrt used firewall policies Figure 2: OpenWrt used firewall policies

As mentioned earlier, the configuration defined above will act as a default policy to handle traffic as it reaches and traverses the router. However, as our default policies are currently defined, no filtering will occur between the TV zone and the other zones. As such, we need to add additional firewall rules which will apply to the different packets as they are handled by the router, before the default policies are applied. The list of additional rules resides under the Traffic Rules tab in the firewall settings page. As mentioned before, the rules defined here will be traversed from top to bottom, we will be adding our rules at the end the already existing rules, thus, ensuring our rules will be examined after all other rules have been traversed and before the default policies are examined.

Figure 3 shows the rules we will be adding, they are as follows:

  1. Reject-TV-to-Local: Here I instruct the firewall to reject all packets originating from the TV zone, with a destination address within the range 192.168.0.1/16. This should cover all IP addresses used locally. This rule, in combination with the default policy of accepting traffic coming in from the TV zone, and allowing forwarding of traffic from the TV to the WAN zone, should be enough to guarantee internet access and disallow any device on the TV network to reach other local devices.
  2. Allow-TV-DNS and Allow-TV-DHCP: Here I explicitly allow DHCP and DNS requests emanating from the TV zone, and destined for the router itself. To achieve this, I am using the port numbers reserved for these protocols. This rule is required because of the following and last rule.
  3. Reject-TV-to-Device: Thanks to the first rule above, all other local devices on my home network are hidden from the TV zone. However, the router itself to which the TV is connected still needs to be reachable for packets to be routed to and from the Internet. In the previous rule, I made sure that only the necessary traffic from the TV zone is accepted into the router (in this case DNS and DHCP traffic). In this rule, I make sure everything else is rejected by the firewall. This allows, among other things, to forbid access to the router’s web-interface from the TV zone.

One last important reminder here: The order in which these firewall rules are defined is not trivial. As an example, had I put the rule Reject-TV-to-Device before rules Allow-TV-DNS and Allow-TV-DHCP, it would have resulted in all packets emanating from the TV zone and destined to the OpenWrt router being rejected by the firewall regardless of their nature. This is because preconditions for the rule Reject-TV-to-Device would be fulfilled for all such packets, thus causing them to be rejected before the router ever reaches the point where the packets are examined against preconditions of rules Allow-TV-DNS and Allow-TV-DHCP.

Figure 3: OpenWrt TV firewall rules Figure 3: OpenWrt TV firewall rules

And that should do the trick! The TV (and all devices connected to the TV zone for that matter) can now reach the Internet, and will be able to do so without being able to see what other devices are also present on my home network.

Bonus: DNS filtering for better privacy

Figure 4: Pi-hole logo Figure 4: Pi-hole logo

Pi-Hole, is a DNS-level ad-blocking application10. When set as a DNS server, Pi-Hole can act as a DNS-sinkhole and deny DNS-requests to specific domain names which can be set in configurable black-lists. The project maintains multiple black-lists of known trackers and domain names used for advertisement distribution. Additionally, these black-lists can be customized and improved locally, either by adding explicit domains to be blocked, or by using regular expressions-based filters. Additionally, Pi-Hole boasts an extremely rich web-interface which includes a dashboard that nicely summarizes the requests logged by the app, and showcases a nice breakdown of which requests were allowed and which were blocked. Pi-Hole was originally designed for light and low-powered embedded systems, such as the Raspberry Pi (hence the name). However, it can be installed on any machine running the Linux operating system.

The Pi-Hole installation process is pretty straight forward, and I will not be getting into it here. In my case, I opted to install the app on a Raspberry Pi I had just sitting around from a previous project. After installation, one needs to change the network configuration of all devices intended to make use of Pi-Hole, so that they use it as their DNS server. This is achieved by simply using the local IP address of Pi-Hole in the configuration of the respective devices. Another solution is to set the routers used on the network to forward all DNS requests they receive from other devices on the network to Pi-Hole. This alternative solution is easily feasible on the OpenWrt router. However, my ISP’s router does not allow to change its used DNS server, meaning that in my case, all devices not connected to the OpenWrt router will have to be configured separately.

Figure 5 shows the network architecture I have settled on (for now). The different zones highlighted with different colors, correspond to the different VLANs and matching firewall zones as defined in the OpenWrt configuration. As you can see, I have opted to connect the Pi-Hole to the ISP’s router using the static IP address 192.168.0.3. Now all that remains, is to instruct OpenWrt to use this IP address for all its DNS requests. This can be achieved in the Network > Interfaces section of OpenWrt’s web-interface. For both the LAN and TV_LAN interfaces which we previously set up, we will set the “Use custom DNS servers” setting to the value 192.168.0.3.

That is all what needs to be done! There is no need to modify any previous firewall settings. As explained in the “Layer 3 segmentation using a firewall” section, our firewall rules allow for DNS traffic from the TV zone to the router. As DNS requests reach OpenWrt, the router itself will issue requests to the DNS server it is set to use (i.e. Pi-Hole). These requests are allowed through the firewall, since as seen in Figure 2 the default policy for traffic going out of the router and into the WANzone is “Accept”.

Figure 5: Current network architecture Figure 5: Current network architecture

Figure 6 is a screenshot from the Pi-Hole dashboard, taken after a couple days of use. The Figure shows the list of the top-blocked domains by Pi-Hole during my short testing period. As can be seen, the blocked domains are all used for either telemetry, analytics, metrics-reporting, or plain advertisement. All of these requests have been blocked and denied by Pi-Hole.

Figure 6: Top blocked domains by Pi-Hole Figure 6: Top blocked domains by Pi-Hole

Conclusions

This experience has been a nice first test-run for my OpenWrt router, and a great learning-experience for me. I have had the above-mentioned smart-TV for months now and was only using it as a “dumb-monitor” as I didn’t trust it enough to connect it to my network in order to make use of its complete feature-set.

Thanks to OpenWrt, I believe I now have a minimal setup which would allow me to use the TV without sacrificing much of my network’s security and my own privacy. I have thus bought myself some time, until I can learn more about network architecture and can optimize my home-network even further for better security and privacy.

I truly hope I did not forget any aspect in segmenting the TV from the rest of my local devices, I am planning on spending more time learning about the theoretical aspect of firewalls and looking under the hood of OpenWrt to see how my configuration translates into iptables rules. For now though, I am very happy with what I have accomplished, and will be taking some much deserved rest…probably watching something on my newly Internet-enabled TV :).

References

  1. BleepingComputer.com - Samsung Smart TV Can Be Hacked via Wi-Fi Direct Feature ↩︎

  2. ArsTechnica - Smart TV hack embeds attack code into broadcast signal—no access required ↩︎

  3. BleepingComputer - Android Ransomware Infects LG Smart TV ↩︎

  4. ArsTechnica - Man-in-the-middle attack on Vizio TVs coughs up owners’ viewing habits ↩︎

  5. The New York Times: How Smart TVs in Millions of U.S. Homes Track More Than What’s On Tonight ↩︎

  6. ArsTechnica - Vizio smart TVs tracked viewers around the clock without consent ↩︎

  7. ArsTechnica - LG smart TV snooping extends to home networks, second blogger says ↩︎

  8. OpenWrt - Firewall overview ↩︎

  9. Wikipedia - Network address translation ↩︎

  10. Wikipedia - Pi-Hole ↩︎

Network organization
networks openwrt router firewalls vlans dns pihole
This post is licensed under CC BY 4.0 by the author.