Croatia - Flag Croatia

All prices include duty and customs fees on select shipping methods.

Please confirm your currency selection:

Free shipping on most orders over 50 € (EUR)
All payment options available

US Dollars
Free shipping on most orders over $60 (USD)
All payment options available

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

Surface Area Management of Embedded Devices through Host and Network Based Firewalls Jeff Fellinge

Firewalls have long acted as a first line of defense for protecting network-connected computing devices and components from remote network-based attacks—much like a front door dissuades intruders from walking into your home. These network-based firewalls and routers were typically installed at choke points and acted as protective gateways between the internet and the trusted computers connected behind them. However, the proliferation of embedded devices, edge networks, and cloud applications have blurred these demarcation lines. Complex network architectures and topologies have made it more difficult to solely rely on these traditional network firewalls to protect your devices and applications. In this blog, we’ll look at understanding the network ports and protocols your devices rely upon and disabling those they do not need. I call this managing the surface area that your device presents to other networks. 

Managing the Network Surface Area

Network surface area management is an important security best practice because it reduces the opportunity of an attacker to exploit a software vulnerability on your device. Take for example a webcam. This device is a mix of hardware and software and plugs into your network to remotely share video. The hardware includes the lens and image capturing electronics which relies on software to convert the pictures to a video stream. All devices such as these have firmware or an operating system that manages these processes. The webcam might also include additional features to send the image to a network video recorder or to allow users to log onto the device itself to see what it sees in real time. Additionally, the webcam firmware might allow remote access to install new features and deploy updates. Understanding how a device functions—even at a high level—is a prerequisite to adequately protecting it.

Understanding Network Ports and Protocols

An important first step to effectively managing the service area of your devices is to understand what ports the device listens on and what network protocols it supports. Start by researching the device itself and look for supported network configurations in the manual or its technical support website. You can then expand your research by determining what firmware or operating system the device uses. For example, some embedded devices use the software BusyBox that provides common UNIX tools. Expanding your research into the device-specific operating system might also provide additional tips for how to disable unwanted services. Consider using a network scanning tool such as Network Mapper (NMAP) to remotely probe your device to discover (or validate) what ports the tool believes are open. You can search the internet for those ports unfamiliar to you and associate these ports with their host service. For example, a quick internet search of TCP Port 22 shows this port is associated with the secure shell protocol used for remote administration. These reconnaissance techniques will help define what network services your device relies upon and which of these network services are enabled and “listening” for remote connections on the network. 

Table 1 shows a simplified representation of the network ports and protocols discovered on an embedded device.

Table 1: Example of the open ports and protocols used by a webcam.






Remote administration



Remote administration



Web portal to view camera



Encrypted web portal to view camera






Automated configuration


The open ports in Table 1—TCP 22, 23, 80, 443, 554, and 5000—define the surface area of an example device that an attacker might successfully probe. Applications and services running on the device listen on these ports for inbound communication requests. For example, a person using a web browser to log onto the camera’s built-in web server to access its features. Attackers will often look for the easiest way to successfully exploit a device and start by scanning thousands of IP addresses looking for a response from a vulnerable device they can exploit. They do this by sending a specially crafted packet to an open port on a device. If the device responds in a certain way, then the attacker knows the device is vulnerable. An attacker might use a network scanner to scan all or the most popular ports and protocols of one device or an attacker might laser-focus their scan to just one specific port but target thousands of devices across the internet. Their goal is the same—probe open ports in hopes of finding a listening service that they might already have an exploit ready to use. Some malware is authored to propagate in this way. Once the malware has infected one device, it scans the network for other vulnerable systems before attacking the underlying service. The malware WannaCry is one recent example of this type of attack. A system infected with WannaCry scans its neighbors by probing Port 445 looking for a vulnerable Server Message Block (SMB) file transfer service to exploit.

Protecting the Network Surface Area Against Attacks

You can lower the risk of a successful attack by using the following techniques to reduce the network surface area exposed by the device.

First, disable all unnecessary services. For example, you might be able to log onto the device and disable the Telnet service which correspondingly reduces the surface area because the device no longer listens on TCP Port 23 (the port commonly associated with Telnet). There are other benefits to disabling unwanted services as well. For example, disabling less secure protocols like Telnet and HTTP in favor of secure shell (SSH) and HTTPS reduces the risk of attackers intercepting unencrypted communications.

Next, consider enabling a host-based firewall. All modern, full-featured operating systems include some sort of a built-in, host-based firewall. Microsoft, Apple, and most Linux distributions enable these firewalls by default and make their configuration straightforward. However, if you need more instruction or want to fine-tune or configure advanced settings, there are many internet guides that can help. Even embedded devices now include built-in, host-based firewalls, depending on the underlying operating system used by the device. As an example, Busybox provides popular UNIX tools for embedded devices and includes options to install and enable the Linux iptables firewall.

Lastly, use your data flow diagram to identify candidate locations upstream of your devices to deploy or enable network- or cloud-based firewalls. Cloud providers include abstracted security services that provide firewall functionality. Look for terms like web application firewall or network security groups to start. Making these configuration changes outside of your specific device requires administrative access to network equipment or a cloud subscription. Care must be taken to ensure that any changes do not inadvertently affect other services or devices. Use these services and features to filter and drop unwanted traffic before it even reaches your device. 


A good defense against attacks on your network-connected devices is an in-depth strategy that includes each of these techniques:

  • Turning off unwanted services
  • Enabling a host-based firewall for each device
  • Filtering unwanted network traffic at the cloud or network gateway

These techniques blend well with other security best practices such as ensuring that your underlying applications, firmware, and operating systems have the latest security updates applied and that your users are not overly provisioned privileged access. Please see my other security blog entries including Identify Anomalous Device Behavior through Logging and Alerting to learn more about some of these other techniques.

« Back

Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop. 

All Authors

Show More Show More
View Blogs by Date