Home > Articles > Network Security for Small Systems

Network Security for Small Systems

Jan Axelson

This article was originally published in Circuit Cellar.

Network security isn't just for desktop computers and large servers. Even the smallest embedded systems can benefit from measures that protect data and code from unauthorized viewing and malicious or unintended changes.
On a system with a network connection, anything that is stored in writable memory or needs to remain private can be at risk. Data may be erased or overwritten. Changes to configuration settings can keep a device from operating properly or at all. Firmware stored in Flash memory or battery-backed RAM may be erased, altered, or replaced by another program. Damage can be the result of innocent mistakes or malicious intent.

Not every system needs every protection. If the device firmware is in masked ROM or EPROM, you don't need to worry that incoming communications might overwrite the firmware. A device that wants to make its data available to any interested party doesn't need to restrict viewing of the data. Small systems that don't use Windows are immune to the scores of viruses, worms, and other security threats targeted at Windows-specific software. And devices that access the Internet via occasional, brief dial-up sessions are in less danger than devices that are on line 24/7.

Where protection is needed, small systems can use many of the same security measures that larger systems use, including firewalls, passwords, validating user data, and encrypting. The challenge is to provide the needed protection without placing too high a burden on the system's limited resources.

Defending with a Firewall

For most networked computers, a firewall is the first line of defense. The firewall protects by screening all communications from outside the local network and blocking anything that might be harmful.

An embedded system can obtain firewall protection from its own firmware, from a PC that protects the local network, or from a dedicated firewall device. Even when an embedded system doesn't need a firewall to protect itself, many systems are behind firewalls because they're in local networks that use firewalls.

The firewall's configuration settings determine which local resources are available to computers outside the firewall. A firewall can also defend against denial-of-service attacks, where one or more computers try to overwhelm a server by bombarding it with requests that have forged source addresses.

A basic rule for implementing a firewall is to block all communications except those you explicitly want to allow. Many embedded systems use the network only for limited functions, such as responding to requests for Web pages on a specific port or using a single e-mail account to send and receive messages. For these systems, device firmware that ignores communications to unsupported ports may be the only firewall protection needed.

A dedicated firewall device can protect multiple computers in a local network and also frees the device firmware from the burden of implementing a firewall. Firewall devices are available from Linksys and others for under $100.
A firewall device typically has multiple LAN ports and a single WAN port:

The LAN ports connect to the local computers protected by the firewall. The WAN port connects to the Internet or another external network outside the firewall. In smaller networks, the WAN port often connects to a cable modem or DSL modem that connects to an Internet Service Provider (ISP). Every communication to or from a computer outside the firewall must pass through the firewall.

Many firewalls have additional capabilities. Linksys's BEFSX41 is an example of a firewall device that also performs the functions of a router with network address translation (NAT) and a Dynamic Host Configuration Protocol (DHCP) client and server. NAT enables multiple computers to share a single public Internet Protocol (IP) address and increases security by hiding the local computers' IP addresses from the Internet. A DHCP client can receive an IP address assigned by an ISP, eliminating the need to enter an address manually. A DHCP server can assign IP addresses to computers in the local network.

Most firewall devices enable you to configure the firewall via password-protected Web pages. In a common default setup, the firewall assumes that local computers will access the Internet only as clients, which request resources from remote computers but don't need to accept incoming requests from unknown sources. A computer functioning as a client can request Web pages, send and receive e-mail, exchange files with FTP servers, and send and request information for any purpose.

The firewall protects the local network by examining each IP datagram received from outside the firewall. Internet communications typically use the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Internet Control Message Protocol (ICMP). The protocols define standard formats for messages and supplementary information such as a destination ports, error-checking values, and flow-control data.

For TCP communications, a firewall may block incoming requests to open connections by allowing only those segments whose ACK or RST bit is set. For UDP and ICMP datagrams, a firewall may limit traffic by specifying allowed source IP addresses and destination ports for incoming UDP and ICMP datagrams.

For more sophisticated filtering, a firewall can determine whether the information in the headers shows that the source and destination addresses match those of a valid, currently active connection. To help in deciding whether a connection is active, the firewall can maintain and consult a table that contains an entry for each connection.

When a local computer sends a an IP datagram containing a TCP segment or a UDP datagram, the firewall can create a table entry that allows incoming traffic from that datagram's destination IP address and port.

For TCP connections, the firewall can delete the entry when the TCP connection is closed, as indicated by the FIN or RST flag in a TCP segment. Because UDP doesn't use formal connections, the firewall can use a timeout to decide when to delete the entry. TCP connections can also use a timeout as a backup in case a connection doesn't close properly.

For ICMP messages, which typically provide status and control information, a firewall may block specific requests, such as Echo (PING).

One client application that can have problems communicating through a firewall is file transfers that use the File Transfer Protocol (FTP). Each FTP transfer requires two TCP connections: a control channel for exchanging status and control information and a data channel for the file being transferred. The client requests to establish the control channel, but the server by default requests to open the data channel.

Many firewalls will block the incoming request to open the connection for the data channel. To get around this limitation without reconfiguring the firewall, the client can send a PASV or EPSV command to request the server to use passive or extended passive mode. These modes enable the client to request to open the data channel's connection using a port number provided by the server.

Most FTP servers support passive mode. Extended passive mode (defined in RFC 2428) can use 128-bit IPv6 addresses, rather than 32-bit IPv4 addresses, but isn't widely supported yet. (This and other RFC documents mentioned are available from www.rfc-editor.org.)

Firewall Configurations for Servers

Some systems must function as servers that accept requests to communicate from outside the local network. Most firewalls allow several options that enable a server to receive these requests.

In a common scenario, an embedded system might host a Web server on port 80, the default port for HTTP communications. A variety of firewall configurations will allow the server to receive incoming HTTP requests.

The most secure option is to forward incoming IP datagrams that don't belong to an established connection only if the datagram contains a TCP segment that in turn contains an HTTP request directed to port 80. Not all firewall devices are capable of filtering in this much detail. Also, additional fragments in a fragmented datagram won't have a TCP or HTTP header to examine, so the firewall may need a mechanism that allows additional fragments to pass through the firewall.

Another option is to forward an incoming IP datagram that doesn't belong to an established connection only if the datagram contains a TCP segment directed to port 80. The device firmware can check for the HTTP request and ignore the segment if the request isn't present.

A third option forwards to a specific host all incoming IP datagrams that don't belong to an established connection. This option leaves all of the burden of further filtering to the device firmware.

A firewall may support other configuration options as well.

Many firewalls enable you to specify which remote IP addresses a local computer can receive traffic from. This option is useful if your embedded system communicates only with a specific IP address or series of IP addresses.

Other options may allow only specified computers to communicate with computers outside the firewall or may block specified computers from communicating with computers outside the firewall. This way, you can enable an embedded system to communicate on the Internet while protecting other local computers that don't need Internet access. The firewall may enable you to identify the local computers by IP address or Ethernet hardware (MAC) address. Using hardware addresses can be useful if the IP addresses are assigned dynamically and thus can change.

A firewall may enable you to block any outgoing communication where the source address of the datagram isn't a local address. This option can prevent some malicious software from using local computers to access the Internet. Embedded systems that don't use popular operating systems are less likely to run into this hazard, however.

A firewall may also allow a computer behind the firewall to communicate without firewall protection at all. The computer is said to reside in a "demilitarized zone" (DMZ). The computer must have its own public IP address and is responsible for providing its own firewall protection.

Another option for protecting local computers, including embedded systems, is a PC running firewall software. To function as a firewall that protects a local network, a PC must have two network interfaces. An Ethernet interface connects the PC to the local network protected by the firewall. A second Ethernet interface or a modem interface connects the PC to the world outside the firewall. To use Windows XP's firewall, the PC must be configured to use Internet Connection Sharing (ICS) with the Internet Connection Firewall enabled.

Restricting Access with User Names and Passwords

A firewall can control which local resources are available on the Internet. But firewalls filter only on the information in headers. They can't identify specific, authorized users who may be using IP addresses the firewall doesn't know about ahead of time.

A solution is to provide authorized users with passwords and to require users to enter a password before accessing a resource. A user name tied to the password provides additional security and can identify who is accessing a resource. Different user names can have different access privileges.

The authorized passwords and user names may be hard-coded into the firmware, or the firmware may authorize one or more users to add new users. For some applications, a device may allow any user to obtain access to a resource by filling out a Web form with a user name and password.

Two words you'll encounter relating to password protection are authentication and authorization. A user who wants to access a protected resource must provide authentication, or proof that the user has permission to access the resource. On receiving a valid user name and password, the server grants authorization, or permission, to access the resource.

A system can use authentication to limit access to any type of resource. A Web server can require a password before returning a Web page. An FTP server can identify users who can access specific files and which users, if any, can delete files or send files to the server. An embedded system that uses e-mail will almost certainly need to provide a user name and password to access the e-mail account on the server.

For Web pages, there are three common options for password protection.

A very basic option is the password box on an HTML form. A password box is like an HTML text box except that the TYPE attribute of the input tag is "password". Here is example HTML code for a password box:

The name attribute identifies the password box to the server. The maxlength attribute specifies how many characters the user can enter. Browsers display a dot or asterisk for each character the user types in the box.
When a user clicks the form's Submit button, the browser sends an HTTP POST request with the name and password in the data area of the TCP segment. For example, if the name is userpassword and the password is circuitcellar, the data area contains the text userpassword=circuitcellar.

The password is sent without encryption, so it's available to anyone who can view the network traffic. The server is responsible for reading the received password and taking appropriate action.

Basic and Digest Authentication

For resources that require greater protection, a server can use Basic Authentication or Digest Authentication. Both are defined in RFC 2617. The methods require the client to provide a valid user name and password before accessing a resource, and the user name and password are encrypted when traveling on the network.
Basic Authentication is simple enough for small systems to support and will prevent most casual snooping. Decrypting the user names and passwords is trivial, however, for anyone who can view the network traffic and knows the encryption method.

When a client requests a Web page protected with Basic Authentication, the server returns a request for the client to authenticate, or prove that the client has permission to receive the resource. The server does so by returning an HTTP header with error code 401 (Unauthorized) and a WWW-Authenticate field that names the type of authentication required. Here is an example:

HTTP/1.0 401 Unauthorized\r\n
Date: Mon, 19 Jan 2004 12:05:15 GMT\r\n
WWW-Authenticate: Basic realm="Embedded Ethernet" \r\n
\r\n

The WWW-Authenticate field names two values: the authentication scheme, or method, to use (Basic in the example) and the realm the scheme applies to ("Embedded Ethernet"). On returning a valid user name and password in the format required by the named authentication scheme, a client can access resources within the named realm. A server can support multiple realms, with each allowing access to a different set of users.

On receiving a header requesting Basic Authentication, the client's browser typically displays a window that requests the user to enter a user name and password:

When the user has entered the requested information and clicks OK, the browser sends an authorization request containing the password and user name. The request travels in an HTTP GET request that includes an Authorization request line with the encrypted user name and password:

GET / HTTP/1.0\r\n
Authorization Basic ZW1iZWRkZWQ6ZXRoZXJuZXQ=/r/n
/r/n

On receiving the GET request, the server decrypts the user name and password. If both are valid for the specified realm, the server returns the Web page originally requested. If not, the server typically returns another response with error 401 and a request to authenticate. Most browsers display the authentication window again, but after receiving a third request to authenticate, some browsers give up and don't re-display the window. Opening a new browser window typically allows the user to try again, however.

To prevent a determined hacker from trying different user names and passwords, a server can limit the number of tries within a short period from a single IP address.

The encryption used in Basic Authentication is the Base64 Content-Transfer-Encoding method described in RFC 1521, except for the specified limit of 72 characters per line.

In the encrypting, the data to transmit is first divided into 24-bit chunks. Each chunk is then divided into four 6-bit values. A table provided in the standard assigns a character in the BASE64 alphabet to each 6-bit value (0 to 63).

The BASE64 alphabet includes upper- and lower-case letters, numerals, and a few additional characters.
In a request for Basic Authorization, the client converts a string in this format:

user_name:password

to BASE64. The resulting characters transmit in the Authorization field of the HTTP header.

For example, if the user name is embedded and the password is ethernet, the string to encrypt is:

embedded:ethernet

Each character is a byte, so the example above has 17 bytes, which divide into 22 6-bit values with four bits left over. To obtain an integral number of 6-bit values, pad the end with two zeroes. Encrypting the user name and password gives this 23-character string:

ZWliZWRkZWQ6ZXRoZXJuZXQ

The result must be an integral multiple of 24 bits. When needed, add one or two equal signs (=) to the end of the string to lengthen it. The example above requires one equal sign.

Networking libraries for embedded systems often include support for Basic Authentication. An example is Rabbit Semiconductor's Dynamic C language for its RabbitCore modules. An HTTP library defines structures for specifying a realm for Web pages and providing user names and passwords to gain access to a realm's resources:

/* An HttpRealm structure specifies the user name and password required to access resources in a realm. In this example, the user name is "embedded", the password is "ethernet", and the realm is "Lakeview Research". */

const HttpRealm myrealm[] = { {"embedded", "ethernet", "Lakeview Research"} };

/* An HttpSpec structure contains information about the files, variables, and structures the Web server can access.

On receiving a request for the file "index.html" or a request with no file name specified ("/"), the Web server requests a user name and password. On receiving a user name and password that match those defined for the Lakeview Research realm, the server serves the page. */

const HttpSpec http_flashspec[] = { { HTTPSPEC_FILE, "/", index_html, NULL, 0, NULL, myrealm}, { HTTPSPEC_FILE, "/index.html", index_html, NULL, 0, NULL, myrealm} };

For Java programmers, Shawn Silverman's Tynamo Web server and servlet engine support Basic Authentication on Dallas Semiconductor's TINI modules (no longer available from the manufacturer) and a variety of other Java-capable embedded systems. A getRealm() method names the realm, and an isAuthorized() method names a valid user name and password for accessing the realm's resources:

/** * Returns the name of the realm. This method is required. * * @param request the HttpServletRequest object */

public String getRealm(HttpServletRequest request) { return "Lakeview Research"; }

/** * Checks to see if the provided user name and password are * authorized for the specified realm. This method is required. * * @param realm a requested resource's realm * @param username a received user name * @param password a received password */

public boolean isAuthorized(String realm, String username, String password) { return "Lakeview Research".equals(realm) && "embedded".equals(username) && "ethernet".equals(password); }

Another option for TINIs is Smart Software Consulting's open-source TiniHttpServer, which also supports Basic Authentication.

An alternative to Basic Authentication is Digest Authentication, which is more secure but more complex to implement. To access a resource protected with Digest Authentication, the client requesting the resource must provide a message digest, which is a 32-character ASCII hex string created from information provided by both the client and the server hosting the resource. The information that goes into creating the message digest includes a nonce value that the server returns in response to a request for a protected resource, a user name, a password, a realm, and the request. The default method for obtaining the message-digest string is Message Digest Algorithm #5 (MD5), defined in RFC 1321.

The nonce value typically incorporates a time stamp and an Etag value that identifies the resource being requested. The time stamp enables the server to allow access for a specified time before requiring re-authentication. A server can use the Etag value to prevent replay attacks, where an unauthorized user requests an updated version of a resource previously returned to an authorized user.

The HTTP library for Rabbit Semiconductor's Dynamic C also supports Digest Authentication. Some older Web browsers don't support Digest Authentication.

Whatever form of password protection you use, be sure to limit access to areas that store authorized user names and passwords, or the protection may be in vain. Also be aware that password protection only limits who can request a resource. The resource itself isn't encrypted when traveling on the network.

Change default passwords that allow root or administrative access. Disable "guest" or similar accounts that have easily guessed user names and allow access to system resources you want to keep private.

Small systems that use e-mail or FTP may also need to take precautions to secure passwords and limit access. User names and passwords for accessing e-mail and FTP servers often travel unencrypted on the network and thus are available to anyone spying on network traffic.

A small system that receives e-mail should have a user name spammers aren't likely to guess (don't use info or webmaster, for example). And don't publish the e-mail address on a Web page where spammers can harvest it, or your system may find itself spending all of its time discarding received spam.

Validating User Data

Another way a device's resources can be at risk is via data received from a client, such as data submitted on an HTML form on a Web page.

When a device enables users to provide values to configure or control the device, it's a good idea to limit valid inputs to a reasonable range. (This is true whether the values travel on a network or not.) For example, in a system that controls heating and cooling, you may want to allow inputs only between, 50 and 72. Then if someone mistakenly enters 6 instead of 60, the system can return an error message instead of attempting to implement the setting.

On an HTML form, input tags that enable users to enter text should always have a maxlength attribute that limits the number of characters a user can enter. This line of HTML creates an input box called temperature and allows the user to enter up to three characters:

Limiting the length helps to ensure that the received text doesn't extend beyond the memory reserved for the value on the server.

Some Web pages contain Server Side Include (SSI) directives, which request the server to perform an action before serving a page. The directives use the same delimiters as HTML comments (). Before serving a page that contains a directive, the server executes the directive and replaces the delimiters and everything between them with the result of the directive.

A malicious user may enter an SSI directive in a form field on a Web page. If the server returns a page that contains the entered data, the server may attempt to execute the directive.

A couple of the directives can have unwanted consequences. The #exec directive requests the server to execute program code, and the #include directive requests the contents of a file to be included in the requested resource.
If your server supports these directives but they're unneeded by applications, it's best to disable the directives if possible. Another protection is to limit which pages the server parses for SSI directives. Typically, pages that contain SSI directives have the extension .shtml, and the server ignores SSI directives on other pages.

In any case, to guard against unauthorized execution of program code or release of data, anything that should remain private should be in an area limited to authorized users.

Encrypting Private Data

Basic and Digest Authentication enable you to encrypt user names and passwords. Some applications also need to encrypt the data that travels on the network. Encrypting and decrypting large amounts of data can require more resources than a small system can spare. Two options suitable for small systems are the encryption method described in the Advanced Encryption Standard (AES) and firewall devices that support Virtual Private Networks (VPNs).

AES is the result of a search launched by the U.S. National Institute of Standards and Technology (NIST) in 1997. The goal was to find an encryption method that was royalty-free, easy to implement even on small embedded systems, and able to withstand attack.

In 2001, Federal Information Processing Standard (FIPS) 197 announced the Rijndael algorithm as the winner of the search and dubbed the algorithm the Advanced Encryption Standard. The U.S. Government uses AES for sensitive but unclassified information, and other entities are welcome to use the algorithm as well.

AES defines a symmetric block cipher that can encrypt blocks of 128 bits using keys of 128, 192, and 256 bits. (A cipher is symmetric if the keys for encrypting and decrypting are the same or easily obtained from each other.) Rabbit Semiconductor's Dynamic C has an optional library module that supports the AES cipher.

To implement authentication and encryption without placing a burden on the device firmware, you can use a firewall device with support for virtual private networks. The computers in a VPN can be in the same local network or anywhere on the Internet.

Desktop computers that communicate with embedded systems can also use VPNs. Windows XP includes an IPSec Security Manager that enables communicating over a VPN.

VPNs use IP Security (IPsec) protocols for encryption and authentication. A variety of RFC documents cover the protocols. A good place to start is the roadmap in RFC 2411.

A firewall device that supports VPNs typically has a variety of configuration options. At the local network, you can enable a single IP address, an entire subnet, or a range of addresses in a subnet to access the VPN. You can specify that the local network will accept VPN communications from a specified IP address or domain name, or from any requesting host.

To use encryption, both ends of the VPN must agree on the type of authentication and encryption and both must share a key that enables each end to encrypt and decrypt network traffic. Encryption options include AES and the older methods Data Encryption Standard (DES) and Triple DES (3DES). Authentication options include the 128-bit MD5 and the more secure 160-bit Secure Hash Algorithm (SHA).

When both ends have been configured, the devices can communicate and attempt to establish the VPN. When the VPN has been established, the two devices can transfer encrypted data.

Another encryption option is the Secure Sockets Layer (SSL) protocol for encrypting data such as the credit-card numbers customers send to on-line retailers. SSL uses public-key cryptography, which requires separate keys for encrypting and decrypting. The computer requesting the encrypted data generates a public key for encrypting and a private key for decrypting. The sender of the data uses the public key in encrypting the data. Decrypting requires the private key, which only the receiving computer has access to.

SSL encryption is very secure but requires more resources than many small embedded systems have available. Netburner offers SSL support for its MOD5282 Development Kit, which uses Motorola's 32-bit ColdFire processor.

Preventing Local Snooping

If preventing eavesdropping within a local network is important, a couple of additional steps can increase security.
An eavesdropper can monitor signals in copper wire by tapping directly into the cable or by coupling to the magnetic field induced by the current in the wires. Neither of these methods works if the network uses fiber-optic cable.

If your device communicates over a wireless network, be sure to implement the recommended security practices for wireless networks. These include changing the default administrative password, using encryption, and if possible, controlling which Ethernet addresses can access the wireless network. For encryption, Wi-Fi Protected Access (WPA) is more secure than Wired Equivalent Privacy (WEP).

All in all, embedded systems have plenty of options for keeping their code and data secure. Taking time to implement the appropriate security measures for your devices can save you time and trouble in the end.