Despite the fact that there are upwards of 120,000 new malwaresignatures identified every week, and that attacks on embedded systemsare rapidly increasing, many developers incorrectly believe that theirdevices are safe.
Using decade-old rationales, they assume that their devices areimmune from malware because of the device's unique physical andarchitectural characteristics, such as the use of flash storage andnon-x86-based processors. The truth is, however, most embedded systemslack at least several of five essential operating system securityfeatures:
- Application-kernel separation,
- Memory protection domains,
- Restricted code execution on the system stack,
- File system access protection, and
- Randomization of process information.
These shortcomings actually make most embedded systems more vulnerable to attack than desktop systems. Additionally, standardfeatures of embedded OSes, such as the availability of debug shells inproduction builds, open source models used to share rogue technology,and fuzzy testing tools that enable detailed code analysis, combine tomake it rather simple to exploit embedded devices.
Despite these facts, some developers are lulled into a false senseof security, believing that embedded systems simply aren't attractivetargets for hackers and therefore don't need protection. While it'strue that current attacks on embedded systems are fewer-roughlycomparable to the level of attacks on desktop systems 10 years ago—thegap is quickly closing.
Headless embedded systems (systemswithout displays,keyboards, or a mouse) are truly ubiquitous, from printers, wirelessequipment, and networking infrastructure, to automobiles, defense, andaerospace—and increasingly, these systems share common OS or CPUplatforms. It's easy, then, for a single hacker to find a vulnerabilityin the common platform and exploit it to take down hundreds ofdifferent devices of a given class or type, simultaneously.
Interestingly, there is a simple tool that can effectively safeguardembedded devices. It's cheap, easy to implement, and well-understood…but almost never found in embedded systems. What is it? The firewall.
At its most basic level, a firewall is anything that preventsunauthorized access to a computer. The firewall can be hardware orsoftware, and the protected computer can be a typical PC, networkequipment, or embedded device. When properly configured, firewalls canblock problematic services, drop unauthorized traffic, and serve as auseful security audit point. In all cases, the firewall controlscommunications to and from devices.
Failing to integrate firewalls into embedded devices is akin toleaving your front door unlocked: It's easy for anyone to walk rightin. Even if the attack is confined to simply taking over the device (asopposed to using the device as a zombie or bot to attack othersystems), the consequences are still highly visible to consumers as theattacker deletes data or bricks the device (damages it to thepoint of inoperability, essentially turning it into a brick). And evenmore alarming, if a compromised device is networked, the attacker canuse the device to access and take down all the network's connecteddevices, and even the network itself. The subsequent effect on businesscan be serious indeed: expensive technical support floods, branddamage, product returns, and ultimately a loss of future sales.
Despite the fact that firewalls have been an accepted and virtuallymandatory feature of networked desktop systems for over a decade, mostembedded devices still do not incorporate even the most basic offirewalls, leaving them, and any system into which they areincorporated, wide open to Internet-based attacks.
The few embedded firewalls that are available are largely limited tothose provided by a few specific embedded operating systems, and evenin these cases, they are rarely activated. These implementations tiethe firewall to the device's IP stack (for example, Linux uses IPtablesto provide firewall functionality), making them non-portable andunusable on other devices.
Before integrating a firewall into an embedded device, it'simportant to understand the types of firewalls and their advantages anddisadvantages.
Firewalls are classified according to where the device-to-networkcommunication occurs, where the communications traffic is intercepted,and the communications state that is traced.
Also known as network layer firewalls, packet filters (Figure 1, below ) operate at alow level (layer 3) of the TCP/IP protocol stack, examining everypacket's header. Packets are not allowed to pass through the firewallunless 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 aretwo subcategories of packet filters:
- Stateful. Stateful filters perform stateful packetinspection (SPI) to maintain context about active connections,including source and destination IP address, port numbers, and thecurrent state of a connection's lifetime (including session initiation,handshaking, data transfer, and completion connection). Policies can beconfigured to increase the packet processing efficiency by allowing allpackets that match an existing connection to pass without furtherprocessing. Only packets that do not match an existing connection basedon comparison with the firewall's state table need to be evaluatedagainst the policies for new connections.
- Stateless. Stateless filters do not maintain anyinformation about a device's active connections, and therefore requireless memory, possibly less time than stateful filters require to lookup stored session information, and can operate with stateless networkprotocols (such as UDP and ICMP) that do not use the session concept.On the downside, however, stateless filters cannot make any decisionsbased on what stage of communications has been reached between peers.
Also known as proxy-based firewalls, application layer firewalls(Figure 2, below ) operate atthe application level (layer 7) of the TCP/IP protocolstack. Such firewalls can intercept all packets (such as browser,traffic, or telnet traffic) sent to or from an application, whileblocking all other packets (those that are not application-related). Asingle 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 spreadof networked computer worms and Trojans by inspecting all packets forimproper content. However, given the variety of applications and thediversity of content allowed, firewalls do not generally attempt tosubstitute for Intrusion Prevention Systems or anti-virus programs.
Unfortunately, application-layer firewalls are CPU-intensive, makingthem a poor choice for embedded devices.
Not to be confused with a proxy-based (application-layer) firewall,a proxy device, whether a dedicated piece of hardware or software on ageneral-purpose machine, acts as a firewall by responding to inputpackets (such as connection requests) the same way an applicationwould, while blocking all other packets.
On the pro side, proxies make it difficult to disrupt internalsystems from outside their network, and misuse of one internal systemwould not necessarily cause a security breach that could be exploitedfrom outside the firewall. On the con side, however, publicly-reachablesystems can be taken over by intruders who then use the system as aproxy for their own purposes, with internal machines remaining unawarethat the publicly-reachable system has been hijacked.
Marrying Firewalls and theEmbedded Environment
While there are tried-and-true approaches to writing securityapplications such as firewalls for desktop systems, the resultantsoftware is often not well-suited to embedded devices. Embedded devicesoften do not have the battery life, memory storage, or processingcapacity to effectively use applications originally designed fordesktop (or rack-mounted) systems, nor the necessary CPU headroom forrunning background applications in addition to accomplishing theirprimary tasks.
Compared to desktop or rack-mounted systems, embedded systems areseverely constrained in processing power, available memory, and supportfor multiple operating systems. To keep unit costs down, embeddedsystems are often designed with just enough processor and memory to getthe job at hand done—and little else. These factors must be taken in toaccount when building firewalls for such devices.
- Non-CPU-intensive operations. The performance of aproduct's security components is one of the biggest factors affectingoverall product behavior. (For example, on desktop systems it's usuallyvery obvious when a scheduled antivirus scan begins.) A sluggishsecurity implementation—especially in comparatively low horsepowerdevices—will become a processing bottleneck. That means that packetfilter firewalls and proxy devices are better choices thanapplication-layer firewalls for embedded devices.
- Small memory footprint. As mentioned, memory is typicallyat a premium in embedded devices. Therefore it's important that yourfirewall, just like all an embedded device's applications, have assmall a memory footprint as possible.
- Portable. Embedded devices are rapidly evolving.Therefore, firewalls designed for embedded systems need to be easilyportable so that the code can be quickly migrated when the CPU platformchanges. By selecting a firewall that supports a range of embeddedoperating systems, you lessen the development efforts required forfuture ports.
- Distributable processing. To address the resourceconstraints of embedded devices, it is helpful to be able todistribute/offload the firewall rules (policies) to a separate server,which can be any gateway type of device, such as a DSL/cable router.The embedded device then acts as the client in this model.
- Real-time processor model. Embedded devices run onreal-time operating systems. To ensure smooth integration, firewallsfor embedded systems should be ROM-able (code can run in ROM, not justRAM), reentrant, and use an asynchronous event driven architecture.
Unattendedinstallation, Configuration, Updates and Operations
In addition to the core characteristics of virtually any embeddedenvironment just described, many embedded devices have nouser-accessible interfaces (Figure 3,below ).
|Figure3. Firewalls on embedded devices, such as routers, smartphones,printers and serverss must support unattended installation,configuration updates and operations.|
Other devices (such as smartphones) do haveinterfaces, but users are generally unwilling or unprepared to dealwith annoying pop-ups, erroneously blocked communications to or from alegitimate peer, or a training period to “teach” the device whatcommunications it should allow.
Therefore, firewalls for embeddedsystems need to provide for unattended installation, remote policyconfiguration/re-configuration, automatic updates, and be able tooperate without any user interaction.
FlexibleTie-In and Plug-in to IP Stacks
Finally, it's often desirable to port an existing application from anon-embedded environment to an embedded device. To enable such porting,it's vital that your firewall not be tied to a particular OS's IPstack, such as firewalls built for Windows and Linux. Be sure to selecta firewall that already supports your required OS or that is largely IPstack-independent.
In addition to basic IP stack support, how a firewall plugs into theIP stack affects overall performance, policy configuration complexity,and whether different rules can be maintained for multiplecommunications protocols. For optimal performance and flexibility, besure that your firewall can plug into multiple points in the stack(ingress, egress, and points in-between).
Building Embedded DeviceFirewalls:Best Practices
You might be thinking, “Ok. I'm convinced that I need an embeddedfirewall. But now what?”
Basically, you have two options:
- Build it yourself. Although simple in theory, writing arobust, full-featured firewall for embedded devices requires a greatdeal of research, design, and testing (some guidelines follow).
- Purchase a commercial implementation. There are vendorswho have developed firewalls that offer valuable benefits for embeddedand mobile devices: high performance, small footprint, assemblyoptimizations, and ongoing development, maintenance, and support.
In the interest of full disclosure, yes, the authors work for Mocana, avendor that sells a suite of full-featured security products, includinga firewall, that seamlessly integrate into embedded environments. Butthe truth is, it's usually cheaper and faster to license a commerciallysupported firewall implementation than to build you own from scratch.
Whether you are building a firewall yourself or evaluatingcommercial implementations, you'll need to consider the followingdesign topics:
- Processing model. For smooth operation and integration, besure that your firewall's processing model, encompassing architecturaldetails such as how threads are managed and which thread performspacket processing, matches your OS context.
- Messaging model. As an early design decision, considerwhether your firewall's rule processing needs synchronous operation(for software firewalls), asynchronous operation (for hardwareaccelerators), or both.
- System communications. To properly implement the maincomponents of your firewall—its policy engine and state machine—youmust know which communications protocols your system will be using, andbe sure that your code conforms to all applicable RFCs.
- Policy engine. A firewall's policy engine translates thedesired set of rules (typically by reading a text file that has beenexternally created), parses communications packets, and looks formatches between them.To be properly flexible, the policy engine should be flexible enough sothat it's easy to create, deploy, and modify policies, should allowboth simple and complex regular-type expressions, and be able to parselayer 2 to layer 7 packets.
- Packet flow. To avoid looking at any rule twice for agiven communications packet, which degrades overall performance, besure to implement (or make use of existing) flows in which a packet canbe easily followed through its communications states.
- Stack plug-in. By applying different policies at differentstack points, you increase packet management efficiency, be veryspecific about what traffic (packets) you allow to pass through yoursystem, and even differentiate between packets that are received from”outside the network” and those that are generated “internally” withinyour network or application.Therefore, make sure you enabled your firewall to plug in at any stackpoint, as well as multiple points: ingress, prerouting, postrouting,forwarding, and egress.
- Resource constraints. As described earlier, embeddedsystems present a unique set of challenges. To help meet theperformance and memory requirements, firewalls developed for embeddedsystems should not include any extra, unused utility routines,redundant error checking, unused data structures, and so on. Use yourmost efficient coding style.
Firewall configuration actually begins with your systemdesign.Consider whether you want to allow traffic on a default-deny basis(deny all connections and traffic unless they are specificallyidentified and allowed) or a default-allow basis (all traffic isallowed unless specifically blocked).
Additionally, the actual rules themselves should be easy to write,in human- readable form. Typical policy syntax follows a simplifiedform of regular expressions, while the rules themselves are usuallywritten off-line in a text file or generated by a firewall's graphicaluser interface (if there is one).
To ensure that your firewall can correctly parse packet headers, itsrules engine must be aware of any expected protocols' packet formats,as defined by their Request for Comments (RFCs ). Since firewalls are sofundamental tonetworking, the list of applicable RFCs is almost infinite, buthere in Figure 4 below area few RFCs that you might especiallly useful..
|Figure4. Firewall-related RFCs.|
Once you've considered the overall design of the firewall, it'simportant to plan how to test it.
Traditional firewall testing focuses on specific protocols, traffic,or ports, with performance testing limited to determining throughputand forwarding rates for packets sent at a predefined rate and packetsize. Unfortunately, this measures best case performance, which israrely representative of embedded production environments' traffic, andfails to test many features now commonly included in today's firewalls.
Modern embedded firewall testing includes a great variety of tests.Those tests that are performance-related should be performed twice:first to determine baseline measures when the firewall receives onlygood traffic with an “Allow All” policy,” and a second time with anapplication's traffic managed by the desired policies so as to validatethat the firewall's rules engine is efficient enough to not degradebaseline performance.
Your embedded firewall test suite should include the following typesof tests:
- Performance tests. Measure the firewall's maximumconnections per second (CPS), maximum concurrent connections, and CPSperformance at 80% of maximum concurrent connections.
- SYN flood test. Determines firewall's ability to detectand mitigate a SYN flood (a denial of service attack caused byan attacker sending a SYN request but no ACK responses). The testshould monitor and report the number of attempted sessions for the SYNflood that are detected, and the number blocked.
- Malicious traffic test. Evaluates the firewall's abilityto detect and mitigate traffic attempting to exploit vulnerabilities orback doors, or introduce worms. The test should monitor the number ofattacks blocked and the number allowed through by the firewall.
- Jumbo frames test. Combines normal application trafficwith jumbo frames (Ethernet frames with greater than 1,500bytes of payload) to determine if the firewall performed better, worse,or the same as without jumbo frames traffic.
- IP, UDP, and TCP fuzzing tests. Tests the ability of thefirewall to keep operating, with no affect to application trafficmanagement or the firewall's attack detection and mitigationcapabilities, when traffic contains malformed IP, UDP, TCP, andEthernet packets. Fuzzing is used to modify any portion of the packet(such as its checksum), thereby generating corrupt data.
- Leak tests. Tests that attempt to bypass the firewall'ssecurity. There are many commercial tools designed to test for flawssuch as unauthorized outbound data transmission, illegal applicationlaunches, failure to protect against packets sent to the device'slow-level network interface, and process injection.
- Combinations of tests. To more closely mimic real-worldscenarios, it is useful to run multiple tests concurrently,particularly performance tests alongside tests that deliberatelypresent the firewall with invalid or malicious traffic.
Surprisingly, although embedded devices are increasingly beingtargeted by malware, it is not yet routine to include firewalls inembedded systems designs. And indeed, there are only a few commerciallyavailable firewalls for embedded devices, whose verycharacteristics—resource constraints, diverse OSes, lack of traditionaluser interfaces—make it difficult to simply integrate a port of anexisting desktop firewall. Likewise, writing a robust, full-featuredfirewall for embedded devices requires much research, design, andtesting.
But by following the best practices outlined in this article, youcan make informed technical decisions about the type of firewall youneed, the required architecture, and how to properly test an integratedembedded firewall.
Kurt Stammberger is the Vice President of Strategy Development for Mocana. . Kurtjoined cryptography startup RSA Securityas employee #7, where he led their marketing organization for eightyears, helped launch spin-off company VeriSign. He founded and stillserves on the Board of the annual RSA Conference, and served as VP ofContent & Services for consumer healthcare startup Vimo.com. He canbe reached at
Monique Semp is atechnical writer for Mocana Corporation andPrincipal at Write Quick, Inc., which provides technical writing andpublications management to a variety of software engineering clients.She has a BS in EE from VA Tech. Before focusing her career ontechnical writing, she was a software engineer in the transportationand automation industries. She may be reached at .