Design Article
Basics of embedded firewalls - Part 2: True security for the Internet of Things
Alan Grau
2/27/2012 11:28 AM EST
[Part 1 discusses Internet-based threats for embedded devices and why embedded devices need a firewall.]
The purpose of an embedded firewall is to filter the packets received by the device, blocking unwanted packets before they are processed by the device. By blocking unwanted packets, it is possible for the firewall to block packet floods, login attempts by hackers, denial of service attacks, and other cyber-attacks.
Before implementing a firewall, the embedded developer must answer a number of important questions:
- What types of filtering should be supported?
- What filtering rules should the firewall support and how are the rules configured?
- How is the firewall integrated with the IP stack?
- Are there any special considerations for implementing a firewall for an embedded device?
- Should I build a firewall from scratch, license an embedded firewall, or use an open-source solution?
Filtering options
There are three main types of filtering a firewall can perform.
- Static filtering or rules-based filtering: Compares each packet to a set of rules to determine if the packet should be blocked or allowed. All decisions are made based on the information in the packet.
- Stateful packet inspection or dynamic filtering: Maintains information on the state of each connection (dynamic information) and uses the information to make filtering decisions.
- Threshold-based filtering: Keeps statistics on packets received and monitors for threshold crossings to detect packet floods and Denial of Service (DoS) attacks.
Selecting a filtering option
Embedded devices can be categorized as open or closed. A closed device only communicates with a known set of trusted IP addresses while an open device communicates with any IP address. Many embedded devices are a mix; they are open for certain protocols and closed for others. A printer, for example, will accept print commands from any IP address, but will only accept configuration or firmware updates from a known list of trusted servers.
Rules-based filtering provides a simple and effective tool to enforce closed communication and is generally the only filtering needed for closed devices. Any communication from a non-trusted IP address will be blocked, isolating the device from attack.

For open or mixed systems, rules-based filtering still provides an important layer of defense. Since virtually all embedded devices are closed for at least some protocols, rules should be configured to enforce any communication not allowed with the device.
If rules-based filtering does not provide sufficient protection, then Stateful Packet Inspection (SPI) or threshold-based filtering may be added for additional protection.
Stateful packet inspection provides protection against packets received with invalid TCP state information, a common Internet-based attack. SPI can also be used to create a "lockdown mode" in which connections must originate from the embedded device.
Threshold-based filtering is complex and requires significant system processing time and memory, but provides a powerful tool for detecting packet floods and DoS attacks.
Static Filtering
Static filtering works by allowing a set of rules to be configured specifying the filtering field (IP address, protocol number, port value, etc.), the filtering type (whitelist vs. blacklist), and the values to be matched. A whitelist is a list of allowed values. If a packet is received and the value is on the list, it is allowed. If not, it is blocked. A blacklist is the opposite, any values on the list are blocked and all other values are allowed.
For example, a rule set could look like the following:
Rule 1, WHITELIST, IP source address, {192.168.0.0 - 192.168.0.255}
Rule 2, WHITELIST, IP protocol, {1,2,6,17}
Rule 3, BLACKLIST, UDP destination port, {700-799}
Static filtering requires the ability to specify the rules set and a filtering engine to evaluate each packet against the configured rules. With the rules show in this example, the filtering engine first checks the IP address of each packet. If the IP source address is not in the range of 192.168.0.1 - 192.168.0.255, the packet will be blocked. Otherwise the filtering engine will proceed to the next rule.
The second rule specifies that the IP protocols of ICMP, IGMP, TCP and UDP (protocol numbers 1, 2, 6 and 17) are allowed. Packets received with any other protocol value will be blocked, even if it is from a whitelisted IP address. The third rule specifies that UDP ports 700-799 are blacklisted. Any UDP packets received for these ports are blocked.
Stateful Packet Inspection (SPI)
SPI maintains information on the state of each connection and uses it to make filtering decisions. Connection oriented protocols such as TCP use the protocol connection state.
In contrast, for connectionless protocols such as UDP, the connection state is either CLOSED or ESTABLISHED based on how recently a packet was sent or received for a given IP address and UDP port. This requires a state table which is updated as connections are established, proceed through the connection states, and closed. As packets are received the firewall validates them based on the current state of the connection and then updates the state table as needed. SPI is protocol specific and therefore the SPI engine must implement a state transition and state validation routine for each supported protocol.
Threshold-based filtering
Threshold-based filtering works by keeping statistics on the packets received and monitors for threshold crossings based on configured time intervals and threshold levels. If the number of packets received from a specific IP address during any time interval exceeds the configured high-water threshold, future packets from that IP address will be blocked.
Once the traffic from that IP address falls below the configured low-water threshold, the filter is disabled and packets from that IP address are again allowed. Implementing threshold-based filtering requires a database to maintain packet counts and a monitoring module to detect and enforce threshold crossings.


Horaira
2/28/2012 5:50 AM EST
Good article
Sign in to Reply