According to a survey by security firm Extreme Networks, almost 70% of organizations suffered attacks against their IoT devices. And many of those attacks resulted in a breach. That staggering number makes it clear why IoT network security is such an essential aspect of maintaining a strong overall security posture. 

Firewalls — which restrict inbound and outbound network traffic based on user-defined rules — are staples of network security, and IoT devices are no exception. In fact, firewalling is particularly important for IoT. With an IoT firewall, administrators can limit their attack surface and reduce the risk of an attack leading to a breach. 

For example, a wireless camera shouldn’t accept scans for open SSH ports from across the globe. An IoT firewall can restrict access to prevent those scans and reduce the chances an attacker even discovers a device. 

This article will explore what an IoT firewall is, how it works, and provide a practical step-by-step example of IoT firewall configuration.

IoT devices differ from traditional network firewall appliances. Before we jump into the specifics let’s start with a high-level overview of traditional vs. IoT firewalls. 

IoT firewalls deal with devices whose traffic patterns are significantly different than devices in a traditional client/server architecture. With client/server architecture models, clients send a diverse set of servers and receive responses, usually using a subset of common ports like 80 (HTTP) and 443 (HTTPS). 

This traffic pattern provides a foundation for creating firewall rules. For example, we know that unsolicited incoming requests to a client have no place in this architecture. We also know that certain network activity is unlikely to originate from a legitimate user, like network scans.

However, overall network traffic is diverse enough that creating effective firewall rules that balance security and usability can be challenging. 

IoT is different. Most IoT devices make a predefined set of requests to specific destinations and should only receive inbound connections from a few well-known network locations. Thus, firewalls can assume a more assertive posture in regulating this traffic. For example, an IoT firewall can disallow non-HTTPS traffic to a smart fridge because other traffic shouldn’t occur on such a device.

However, most modern organizations will benefit from using Infrastructure as Code (IaC) for IoT firewall configuration. This section will guide you through deploying a cloud-based IoT web application firewall (WAF) for a geographically dispersed fleet of devices.

Mapping the infrastructure

A firewall, in a sense, mirrors the intended functionality of the network. Thus, a good WAF should reflect the intended network flow of your application.

Imagine a network of ESP32 devices that measure volcanic activity in hotspots across the globe. The devices connect to a high-powered G1 WiFi Gateway, which links to a nearby geology monitoring station’s router. The geologists rely on this router for their personal and professional devices. The router then connects to a modem and which connects to the internet. The IoT devices thus connect via the internet to the API backend for logging, commands, etc.

In the backend API that the volcanic measuring devices connect to, the developers include a simple echo endpoint that devices can call to ensure the API responds. We’re going to use a WAF to protect this endpoint.

import { Application } from "https://deno.land/x/oak/mod.ts";
import { h, renderSSR } from "https://deno.land/x/[email protected]/mod.ts";

const app = new Application();

function App({echo}) {
   return (
     
echo: {echo}
   );
}

app.use((ctx: any) => {
   ctx.response.headers.set("Content-Type", "text/html")
   const { searchParams: query } = new URL(ctx.request.url);
   ctx.response.body = renderSSR();;
});

await app.listen({ port: 8000 });

There’s a lot we could do to improve the code above, but ignore that for now. We only want to focus on how a firewall could contribute to the safety of the above code.

Deploying our web application firewall

As developers, we should strive for excellent security. For example, the echo endpoint above is vulnerable to a reflected cross-site scripting (XSS) attack. An attacker can execute arbitrary code in a browser visiting that endpoint by supplying an echo parameter containing HTML code with a JS payload.

Let’s deploy a WAF to prevent any XSS against this endpoint by adding the following code to our application:

import waf from 'https://deno.land/x/waf/waf.tsx';

//Forbid HTML in the echo parameter
app.use(waf({
 parameters: [{
   name: 'echo',
   disallowTags: true
 }]
}));

Additionally, we want our code to run in a real cloud environment. For the example below, we use Deno Deploy, but because the firewall is at the application level, it should work seamlessly with any cloud provider.

Let’s try the same XSS exploit as before against our cloud-deployed, WAF-protected application.

Wonderful - our firewall prevented the corrupted echo parameter from exploiting our vulnerable application code. This is exactly how firewalls should work: making you safer by providing an additional layer of protection between your infrastructure and attackers.

We’ve looked at what an IoT firewall is and how to use it. Now let’s review some best practices that will help you keep your firewall secure and easy to maintain.

Document all firewall rules

Imagine an engineer is trying to deploy a new API feature that connects to a certain resource, but the firewall is blocking the connection. 

So you check a blacklist of forbidden IPs within your firewall settings and see that the destination is listed there.

$ firewall -ipv4 -list blacklist
103.251.167.20
61.177.173.51
164.92.218.139
171.251.29.152
185.246.188.95
45.153.160.131
185.129.63.2
61.177.173.35
61.177.173.39
89.234.157.254
23.129.64.130

You could get the IP of the domain and confirm that it’s in the list, but do you really want to remove an IP from the blacklist? After all, it was probably put there for a reason.

This is why it’s crucial to document your decisions when adding a rule to the firewall. Suppose you add the IP address used by a known IoT botnet to a blacklist, and someone’s device gets infected and stops working because malware on their device can’t phone home correctly. Another IT admin might just assume the blacklist is the problem and remove the rule. 

Whether it’s simply using iptables -c to add a comment in the firewall’s config file or maintaining a full spreadsheet explaining different rules, have something in place that other administrators can consult when they need to modify your work.

Use the right tool for your infrastructure.

AWS customers, for example, will find it easy to integrate AWS Network Firewall with other AWS services like Lambda, EC2, and so on.

Don’t worry about finding the “perfect” solution. Instead, look for solid integration with the rest of your infrastructure. Find the “typical” firewall solution for your specific tech stack and see if it meets your needs. 

Restrict everything except necessary traffic

Firewalls should follow the principle of least privilege. For IoT firewalls, that means aggressively blocking any ingress or egress traffic that doesn’t match expected patterns. 

What does this look like in practice? Imagine you have a device that occasionally sends stats to a monitoring API but never receives incoming traffic. You should configure your firewall to:

• Allow the device to send monitoring requests only on the correct port and to the correct destination. 
• Block all other outbound destinations. 
• Block incoming traffic completely.

Scan your network for “forgotten” devices

IoT devices like CCTV cameras, retail kiosks, and smartphones are often “forgotten” nodes in a network. These devices are prone to neglect because they may not even appear in inventory lists.

Hunting down rogue devices sounds intimidating, but it starts with a simple Linux command. Then, you make sure the results all make sense. Here’s an example of a full local area network scan using nmap in a network with both IoT and conventional devices.

$ nmap -sP 192.168.0.0/24
Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2010-06-22 22:27 CEST
Host ROUTER 192.168.0.0 appears to be up.
Host MODEM appears to be up.
Host DAVE’S IPHONE (192.168.0.2) appears to be up.
Host HDV Smart Fridge (192.168.0.9) appears to be up.
Host [email protected] (192.168.0.10) appears to be up.
Host [email protected] (192.168.0.11) appears to be up.
Host Thermostat (192.168.0.16) appears to be up.
Host 192.168.0.17 appears to be up.
Host 192.168.0.18 appears to be up.
Host testapi.org.example.dev (192.168.0.19) appears to be up.
[...]
Nmap finished: 256 IP addresses (211 hosts up) scanned in 7.491 seconds.

Tracking down and inventorying those devices can be tedious. However, it’s worth the effort to gain visibility into the devices across your network and eliminate unnecessary attack surfaces.

Whether you simply configure iptables on a legacy Linux system or protect your IoT app’s web backend with an AWS WAF, firewalls provide a significant network security benefit with a relatively small upfront investment in time and money.

With the information we’ve reviewed here, you have a baseline to decide what IoT firewall solution is appropriate for your infrastructure and how to get it running. By following the principle of least privilege with your firewall rules and taking the time to discover all the IoT devices on your network, you can drastically improve your overall security posture. 

Learn more about how Macrometa integrates with your IoT environment seamlessly and gives you effortless, scalable, and reliable access to your data from a variety of popular frameworks.