Turning up the heat on hackers with embedded firewalls

Despite the fact that there are upwards of 120,000 new malware signatures identified every week, and that attacks on embedded systems are rapidly increasing, many developers incorrectly believe that their devices are safe.

Using decade-old rationales, they assume that their devices are immune from malware because of the device's unique physical and architectural characteristics, such as the use of flash storage and non-x86-based processors. The truth is, however, most embedded systems lack at least several of five essential operating system security features:

1. Application-kernel separation,
2. Memory protection domains,
3. Restricted code execution on the system stack,
4. File system access protection, and
5. Randomization of process information.

These shortcomings actually make most embedded systems more vulnerable to attack than desktop systems. Additionally, standard features of embedded OSes, such as the availability of debug shells in production builds, open source models used to share rogue technology, and fuzzy testing tools that enable detailed code analysis, combine to make it rather simple to exploit embedded devices.

Despite these facts, some developers are lulled into a false sense of security, believing that embedded systems simply aren't attractive targets for hackers and therefore don't need protection. While it's true that current attacks on embedded systems are fewer-roughly comparable to the level of attacks on desktop systems 10 years ago—the gap is quickly closing.

Headless embedded systems (systems without displays, keyboards, or a mouse) are truly ubiquitous, from printers, wireless equipment, and networking infrastructure, to automobiles, defense, and aerospace—and increasingly, these systems share common OS or CPU platforms. It's easy, then, for a single hacker to find a vulnerability in the common platform and exploit it to take down hundreds of different devices of a given class or type, simultaneously.

Interestingly, there is a simple tool that can effectively safeguard embedded devices. It's cheap, easy to implement, and well-understood... but almost never found in embedded systems. What is it? The firewall.

Understanding Firewalls
At its most basic level, a firewall is anything that prevents unauthorized access to a computer. The firewall can be hardware or software, and the protected computer can be a typical PC, network equipment, or embedded device. When properly configured, firewalls can block problematic services, drop unauthorized traffic, and serve as a useful security audit point. In all cases, the firewall controls communications to and from devices.

Failing to integrate firewalls into embedded devices is akin to leaving your front door unlocked: It's easy for anyone to walk right in. Even if the attack is confined to simply taking over the device (as opposed to using the device as a zombie or bot to attack other systems), the consequences are still highly visible to consumers as the attacker deletes data or bricks the device (damages it to the point of inoperability, essentially turning it into a brick). And even more alarming, if a compromised device is networked, the attacker can use the device to access and take down all the network's connected devices, and even the network itself. The subsequent effect on business can be serious indeed: expensive technical support floods, brand damage, product returns, and ultimately a loss of future sales.

Despite the fact that firewalls have been an accepted and virtually mandatory feature of networked desktop systems for over a decade, most embedded devices still do not incorporate even the most basic of firewalls, leaving them, and any system into which they are incorporated, wide open to Internet-based attacks.

The few embedded firewalls that are available are largely limited to those provided by a few specific embedded operating systems, and even in these cases, they are rarely activated. These implementations tie the firewall to the device's IP stack (for example, Linux uses IPtables to provide firewall functionality), making them non-portable and unusable on other devices.

Before integrating a firewall into an embedded device, it's important to understand the types of firewalls and their advantages and disadvantages.

Firewalls are classified according to where the device-to-network communication occurs, where the communications traffic is intercepted, and the communications state that is traced.

Packet filter firewalls
Also known as network layer firewalls, packet filters (Figure 1, below) operate at a low level (layer 3) of the TCP/IP protocol stack, examining every packet's header. Packets are not allowed to pass through the firewall unless they match an established policy (rule set).

Figure 1. Packet filters examine every packet's header and decide whether to drop or pass the packet, based on established policy

There are two subcategories of packet filters:

• Stateful. Stateful filters perform stateful packet inspection (SPI) to maintain context about active connections, including source and destination IP address, port numbers, and the current state of a connection's lifetime (including session initiation, handshaking, data transfer, and completion connection). Policies can be configured to increase the packet processing efficiency by allowing all packets that match an existing connection to pass without further processing. Only packets that do not match an existing connection based on comparison with the firewall's state table need to be evaluated against the policies for new connections.
• Stateless. Stateless filters do not maintain any information about a device's active connections, and therefore require less memory, possibly less time than stateful filters require to look up stored session information, and can operate with stateless network protocols (such as UDP and ICMP) that do not use the session concept. On the downside, however, stateless filters cannot make any decisions based on what stage of communications has been reached between peers.

Application-layer firewalls
Also known as proxy-based firewalls, application layer firewalls (Figure 2, below) operate at the application level (layer 7) of the TCP/IP protocol stack. Such firewalls can intercept all packets (such as browser, traffic, or telnet traffic) sent to or from an application, while blocking all other packets (those that are not application-related). A single firewall can support multiple application proxies.

Figure 2. Application layer firewalls allow traffic sent to and from applications to pass through, while blocksing all other packets.

Theoretically, application-layer firewalls could prevent the spread of networked computer worms and Trojans by inspecting all packets for improper content. However, given the variety of applications and the diversity of content allowed, firewalls do not generally attempt to substitute for Intrusion Prevention Systems or anti-virus programs.

Unfortunately, application-layer firewalls are CPU-intensive, making them a poor choice for embedded devices.

Proxy devices
Not to be confused with a proxy-based (application-layer) firewall, a proxy device, whether a dedicated piece of hardware or software on a general-purpose machine, acts as a firewall by responding to input packets (such as connection requests) the same way an application would, while blocking all other packets.

On the pro side, proxies make it difficult to disrupt internal systems from outside their network, and misuse of one internal system would not necessarily cause a security breach that could be exploited from outside the firewall. On the con side, however, publicly-reachable systems can be taken over by intruders who then use the system as a proxy for their own purposes, with internal machines remaining unaware that the publicly-reachable system has been hijacked.