FANE: A Firewall Appliance for the Smart Home
Hochschule für Telekommunikation
Gustav-Freytag-Straße 43-45, 04277 Leipzig, Germany
Hochschule für Telekommunikation
Gustav-Freytag-Straße 43-45, 04277 Leipzig, Germany
Abstract—With the advent of the Internet of Things (IoT),
many domestic devices have been equipped with information
technology. By connecting IoT devices with each other and
with the Internet, Smart Home installations exist that allow the
automation of complex household tasks. A popular example is
Google Nest that controls cooling, heating and home security.
However, Smart Home users are tempted to neglect that such IoT
devices pose IT-Security risks. Examples like the Mirai malware
have already shown that insecure IoT devices can be used for
large-scale network attacks. Thus, it is important to adapt secu-
rity approaches to Smart Home installations. In this paper, we
introduce FANE, our concept for a Firewall AppliaNcE for Smart
Home installations. FANE makes a few realistic assumptions on
the network segmentation and the communication proﬁle of IoT
devices. This allows FANE to learn ﬁrewall rules automatically.
Our prototypical implementation indicates that FANE can secure
a wide range of IoT devices without requiring network-security
expertise from the Smart Home user.
I. INT ROD UC TI ON
IN THE the last years, the proliferation of Smart Home
installations has gained momentum. Today, the consumer
market offers a huge number of different Internet-of-Things
Smart thermostats, cameras, speakers and even toothbrushes
contain information technology that connects the IoT device
over the Internet with cloud services or other IoT devices. For
example, IoT devices from the Google Nest family  provide
a straightforward, user-friendly way to control heating, cooling
and home security. Smart speakers like Amazon Alexa 
allow to control many daily activities via voice control. From
the perspective of the manufacturers, the Smart Home concept
allows new business models, e.g., to sell new product features
as digital upgrades for IoT devices.
On the other hand, consumers might be tempted to overlook
that the IoT devices pose an IT-Security risk. For example, the
lifetime of a traditional security camera ends when the device
is broken. In contrast, the lifetime of an IoT security camera
that connects over the Internet should come to an end when
its manufacturer discontinues security updates, even if the IoT
security camera is still working. Otherwise, the IoT security
camera might end up as, say, part of the Mirai bot network,
which consisted of approx. 500,000 devices in 2016 .
From the perspective of a consumer without in-depth ex-
pertise of network security, it is next to impossible to ﬁnd
out if the IoT devices present in a Smart Home installation
are subject to attacks over the Internet. In this paper, we
explore options to integrate a ﬁrewall into typical Smart Home
installation that can detect and deter such attacks. This is
challenging, since the ﬁrewall must be compliant with the
typical modes of use of a Smart Home installation, and a
consumer cannot be expected to evaluate ﬁrewall rules or
identify false alarms. On the other hand, the IoT devices used
differ from general-purpose devices such as smartphones and
desktop computers. This might allow for pre-conﬁguration to
In particular, we make the following contributions:
1) We systematically compare the lifecycle of a classical
ﬁrewall with the lifecycle of IoT devices in a typical
Smart Home installation.
2) We propose FANE, a Firewall AppliaNcE on a Wi-Fi
bridge in Smart Home installations.
3) We describe a proof-of-concept implementation of FANE
based on a Raspberry Pi, and we evaluate it with three
different IoT devices.
We show that it is possible to develop a generic IT-
Security concept for IoT devices in a Smart Home installation
by making few realistic assumptions, e.g., the IoT network
segment is only used by single-purpose IoT devices, which
do not fundamentally change their communication proﬁles.
We have implemented this security concept in FANE. Our
evaluation indicates that FANE can secure the IoT network
segment without requiring the user to possess network-security
Paper structure: In Section II, we review related work.
In Section III we provide a problem statement. We describe
FANE in Section IV, followed by a proof-of-concept imple-
mentation in Section V and an experimental evaluation in
Section VI. Section VII concludes.
II. RE LATE D WOR K
In this section we provide a brief deﬁnition of Internet
of Things and Smart Home, and we introduce related work
on ﬁrewalls, ﬁrewall management and approaches to generate
ﬁrewall rules automatically.
A. Internet of Things and Smart Homes
The "‘Internet of Things"’ (IoT) refers to physical appli-
ances, which have been equipped with information technology
in order to connect them with other devices directly or over
the Internet . IoT includes a wide range of appliances, from
Preproceedings of the Federated Conference on
Computer Science and Information Systems pp. 459–468
connected cars over smart buildings to connected machinery in
an Industry 4.0 setting. The concept "‘Smart Home"‘ narrows
down this range to devices that let end users to control, monitor
or access everyday objects of the daily routine .
B. Security Challenges
To assess the security properties of Smart Home installa-
tions, it is important consider the basic security challenges
that occur in installations of IoT devices. One study  lists
six major security issues:
Identity and Authentication: In IoT environments, numer-
ous devices need to authenticate each other in order to provide
trustable services. Thus, reliable techniques for identiﬁcation
and authentication are needed.
Access Control: To create new services it is necessary to
aggregate data from different providers. This is challenging,
because in typical IoT scenarios each provider has its own
access control policy.
Protocol and Network Security: If IoT devices commu-
nicate with each other in a distributed network architecture,
distributed schemes for key management are needed.
Privacy: The Smart Home concept means that numerous
IoT devices monitor the actions of its users in order to devise
meaningful responses. Thus, privacy very important from a
Trust and Governance: In IoT architectures there are two
dimensions of trust. The ﬁrst dimension is between users and
their IoT devices. The other dimension is between the IoT
devices. Device A needs to trust the accuracy and integrity of
the data produced by device B. Data governance goes in the
same direction, in a sense of data and access governance.
Fault Tolerance: Mechanisms for fault tolerance need to
be established to counteract faulty or tampered devices.
Other studies  list similar challenges.
C. Firewalls State of the Art
Firewalls are able to control and log the network trafﬁc
based on rules set by an administrator or security expert. In
literature different ﬁrewall generations are distinguished .
1st generation ﬁrewalls are known as packet ﬁlters which
operates on the transport layer. The ﬁltering is based on
source and destination IP addresses, ports and protocols. 2nd
generation ﬁrewalls are also operating on the transport layer
and they are known as stateful packet inspection. State tables
are used to keep track of the network trafﬁc and ﬁltering is
based on state and context of packets. 3rd generation ﬁrewalls
are operating on the application level and require different
proxies for each service. The proxy acts as a middleman
between source and destination to reestablish a new session.
Current ﬁrewall technologies are called next generation ﬁre-
walls. These next generation ﬁrewalls are looking deep into
packets and combine traditional ﬁrewall technologies with
network ﬁltering capabilities on the application level .
However, all these generations have in common that an expert
is needed to deﬁne rules or check them for correctness which
motivates our new approach.
D. Firewall Lifecycle
Traditionally, a ﬁrewall must be part of the IT-Security
process, as described by the ISO 270xx standards family ,
the German BSI Grundschutz Standard 200-2  or the ITIL
process for security Management . The IT-Security process
starts with a IT-Security policy that has been passed by the
management. Based on this policy, business objectives, the
assets to be protected and a risk classiﬁcation can be identiﬁed.
Subsequently, measures can be deﬁned and implemented that
restrict the IT-Security risks to acceptable levels. In the follow-
ing, the effectiveness of these measures needs to be monitored.
Based on this information, corrective actions can be planned
and executed . Note that all process steps require a person
with IT-Security expertise, which cooperates with various IT
experts from the operations department.
IT-Security Operations Configuration Management Information Security
Fig. 1. Traditional Firewall-Lifecycle
460 PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019
A ﬁrewall ﬁts into the IT-Security process  as shown in
Figure 1. In the Information-Security Management phase, the
management deﬁnes a security policy based on company-wide
security objectives. This policy is independent from technical
realities. Based on the security policy, an IT-Security expert
designs the architecture of the ﬁrewall system and selects
the ﬁrewall system components. In the implementation and
conﬁguration phase, the IT-Security expert adapts the ﬁrewall
system to the system architecture with its network segments,
hosts and applications. This includes a preliminary set of
ﬁrewall rules that deﬁne which network packets are allowed
to pass the ﬁrewall. In the next step, a plan-do-check-act cycle
takes place where the ﬁrewall rules are designed, implemented,
reviewed and improved in a repetitive way. Typically, this
cycle is part of IT-Security operations. It allows to adjust the
ﬁrewall rules to changes such as new business applications,
hosts moving from one network segment to another one,
or in case of detecting new attacks. Note that not only the
management of ﬁrewall rules is a cyclic process, but also
the IT-Security process. If the management observes that the
security policy is ineffective, this policy can be changed as
well, and it has an impact on all design decisions further down
the IT-Security process chain.
E. Firewall Rules
It is a labor-intensive task for a domain expert to create a
rule set for ﬁrewalls for manually. One option to obtain ﬁrewall
rules (semi-)automatically is to use data mining or machine
learning on a training set consisting of network packets. This
option is based on the assumption all user applications operate
as intended while the training set is recorded. Respective
approaches – have been proposed for Intrusion De-
tection systems, but might be adaptable to ﬁrewalls as well.
By using k-Means, C4.5 decision tree algorithms, Naive Bayes
classiﬁer, Neural Networks or Support Vector Machines, it is
possible to derive common characteristics of allowed network
connections. Those characteristics could be translated into
ﬁrewall rules. It is also possible to generate ﬁrewall rules by
mining the ﬁrewall log  instead of a dump of network
packets. However, all approaches require an IT-Security expert
to decide which generated rules are relevant to meet the
security requirements, and the quality of the generated rules
still needs further research.
A different option to generate ﬁrewall rules is to deduce
them from a formal speciﬁcation of security requirements by
using argumentation logic . This approach allows to auto-
matically obtain a detailed, comprehensive set of rules from a
high-level speciﬁcation. However, creating a speciﬁcation of
the security requirements for a certain system architecture still
requires expert knowledge in IT-Security.
III. PROB LE M STATEM EN T
In this section, we explore the differences between tradi-
tional ﬁrewalls and ﬁrewalls needed for IoT devices in a Smart
Home installation. In addition, we derive requirements for a
Smart Home ﬁrewall.
A. Does a Firewall Fit into the Smart Home Concept?
To ﬁnd out in which ways traditional ﬁrewall use cases
differ from Smart Home use cases, we consider the modes of
use, network architecture, application scenario, user roles and
information technology used.
a) Modes of Use: A ﬁrewall is an access control mech-
anism that allows or blocks network trafﬁc between two
network segments that have different security properties ,
e.g., an internal network and the Internet that is open for
anybody. The ﬁrewall enforces a set of ﬁrewall rules that allow
or prohibit network packets to travel from one segment into the
other one. The ﬁrewall rules depend on the use cases that are
executed over both network segments. For example, a business
workﬂow "‘Answer customer requests"’ might require that a
set of machines in the internal network is allowed to send
and receive email to/from the Internet. Thus, ﬁrewall rules
must be deﬁned by a network-security expert with domain
knowledge. If the workﬂows, the applications or the segment
boundaries are changed, the expert must adapt the ﬁrewall
rules as well. Traditionally, ﬁrewalls are tailored for complex
multi-purpose scenarios where the hosts execute numerous
different applications that change over time.
Smart Home use cases are fundamentally different : A
typical IoT device is a physical object that has been extended
with information technology to improve its usefulness. For
example, a smart toothbrush  can tell its user if a tooth has
gone unbrushed. Thus, IoT devices are constructed for a single
purpose that does not change over time. It only makes sense to
install a toothbrush control software on a smart toothbrush. As
a result, IoT devices are single-purpose objects. If the device
is not needed any more, it will be disposed.
b) Network Architecture: Firewalls depend on the net-
work segmentation. With traditional use cases, a network
installation might contain multiple segments protected by
multiple ﬁrewalls. A prominent example is a perimeter net-
work , which contains assets such as Web servers that
must be accessible from an external network. Two sets of
ﬁrewall rules protect the perimeter network against the external
network and the internal network against the perimeter and
the external network. However, the number and architecture
of the network segments might be individually different for
each network installation.
In contrast, a typical Smart Home installation with IoT
devices produces three network segments with different se-
curity properties: (a) the untrusted Internet, (b) the home
network with trusted devices such as the user’s laptop and
printer, and (c) an IoT network segment that contains all IoT
devices. Since the IoT device and its software comes as an
integrated package, the user has little options to inﬂuence the
security of the IoT device, e.g., by disabling unused network
protocols or by removing unused software functionality. Thus,
the IoT network segment should be separated from the home
network , which is used for sensible tasks such as online
banking or online shopping. All devices in the IoT network
segment can be expected to require an Internet connection, to
CHRISTOPH HAAR, ERIK BUCHMANN: FANE: A FIREWALL APPLIANCE FOR THE SMART HOME 461
provide a service, to obtain updates and upgrades, to allow a
remote control via smartphone app, etc.
c) Application Scenario: Firewalls follow the IT-Security
lifecycle, as explained in Section II. Based on a general
security policy that has been deﬁned from a management
perspective, a network-security expert deﬁnes the position
of the ﬁrewall(s) in the network architecture and a set of
ﬁrewall rules. By using a plan-do-check-act-cycle, the ﬁrewall
rules as well as the ﬁrewall hard- and software must be
constantly monitored, evaluated and adapted to changes in the
On the opposite side, one of the fundamental principles of
the Smart Home concept is to let IoT devices use sensors
to observe its environment, in order learn appropriate actions
with a minimum of user interaction and without requiring
the user to scrutinize the operations of the IoT device on a
regular basis. For example, the nest thermostat observes the
temperature preferences of its user and if he or she is at home,
and controls the heating system accordingly. Furthermore, the
duration of use of IoT devices is an one-dimensional process
that starts with the deployment of a device and ends with
it’s disposal, just like non-smart devices , i.e., it does not
follow a periodic lifecycle where it is constantly monitored and
improved. For example, a smart light switch never changes its
function, and it cannot be adapted to different needs.
d) User Roles: Setting up a traditional ﬁrewall typically
requires three distinct roles: The role "‘Information Security
Management"’ deﬁnes a security policy by considering the
assets and (business) objectives that are relevant for a certain
part of the IT infrastructure. Based on the policy, the role
"‘Conﬁguration Management"’ designs a ﬁrewall system, se-
lects appropriate ﬁrewall components, and provides an initial
installation and conﬁguration of the system. Finally, a role
"‘IT-Security Operation"’ constantly monitors and improves
the ﬁrewall system, both on the level of the ﬁrewall rules and
of the ﬁrewall hard- and software.
In contrast, an IoT device for a Smart Home usually is pre-
conﬁgured by the manufacturer for typical use cases. The end
user can deploy and conﬁgure the IoT device with minimal
efforts, does not need to monitor it later on and does not need
e) Information Technology: IoT devices make use of
network protocols which have been well established. They
use Linux-based operating systems, Cloud resources and Open
Source programming libraries. The network security of IoT
devices is based on mechanisms for encryption, certiﬁcation
and signatures that have been in use for years. Thus, from a
technical point of view, off-the-shelf ﬁrewalls can be directly
used to control the network trafﬁc of IoT devices.
B. Problem Deﬁnition
From a technical perspective, it would be a simple exercise
for a network security expert to set up a ﬁrewall that controls
the network trafﬁc of an IoT device. However, this procedure
conﬂicts with the general understanding how IoT devices
should operate in a Smart Home. Thus, a ﬁrewall for Smart
Homes must differ in the following properties from traditional
P1 The ﬁrewall must be usable without expert knowledge.
P2 The ﬁrewall must ﬁt to the durations of use of Smart
P3 The ﬁrewall must operate in a way that is typical for IoT
devices in the Smart Home.
P1 implies not only that the conﬁguration and installation of
a ﬁrewall in a Smart Home must not require network security
expertise. It also means that a user cannot be expected to tell
false alarms from real alarms, or to decide if a certain ﬁrewall
rule is applicable to the home network. From P2 it follows that
such a ﬁrewall must deal with IoT devices that are bought once
for a certain purpose and never change its basic properties until
disposal, and it must operate in the same way. Furthermore, the
ﬁrewall must operate in the same way. P3 means that a ﬁrewall
in a Smart Home needs to operate without permanent care
from the user, i.e., it must monitor the network trafﬁc, deduce
meaningful ﬁrewall rules and provide appropriate reactions to
forbidden network packets.
We have ruled out a cloud-based approach ,  that
externalizes the ﬁrewall to a trusted third party on the In-
ternet. Although such an approach might fulﬁl the properties
described, it requires a permanent Internet connection. In ad-
dition, a cloud-based ﬁrewall would transfer security-relevant
information into the cloud. Thus, both the Internet connection
of the ﬁrewall and the trusted third party would be a valuable
target for an attacker.
IV. FANE: A FIR EWAL L APP LI AN CE
In this section, we introduce FANE, a concept for a Firewall
AppliaNcE that is compatible with the Smart Home paradigm.
A. Network Architecture
A ﬁrewall separates network segments with different secu-
rity properties. Typical IoT devices do not allow its user to
observe security properties, and to conﬁgure security-related
aspects, such as disabling unused functions. Furthermore, an
IoT device is designed to be used like a classical, non-smart
device, i.e., its users are tempted to forget that the device might
pose IT-Security risks. For this reason, IoT devices should be
placed in network segments that are isolated from all other
network segments of the Smart Home.
Thus, FANE operates as a Wi-Fi bridge that connects the
IoT network segment to the Internet and includes a ﬁrewall,
as shown in Figure 2. The IoT network segment only contains
single-purpose IoT devices, and the Wi-Fi bridge is the only
connection of the IoT segment to other network segments and
the Internet. We observe that this allows us to specify the
security concept in advance.
B. Security Concept
From Section III it follows that a traditional ﬁrewall ap-
proach is complex, because the underlying network segmen-
tation and the processes executed over the boundaries of
these segments are complex, too, and might change from
462 PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019
NAT, DNS, DHCP
Wi-Fi Access Point
FANE IoT Network
Cloud Server IoT Device
Fig. 2. System Architecture
time to time if a new software is installed on a device in
the network. With our network architecture, we have reduced
this complexity. We only need to consider three kinds of
•An IoT device wants to communicate with a server
on the Internet. For example, a smart thermostat wants
to communicate with the user’s smartphone, which is
mediated over a cloud service.
•An IoT device wants to communicate with a device in
another network segment. For example, the user installs
a control application on a laptop to conﬁgure the smart
•An IoT device wants to communicate with another IoT
device in the same network segment. For example, our
smart thermostat wants to directly communicate with the
smart air condition.
Since FANE operates as a bridge to the Internet, only the
ﬁrst two kinds of communication have to be monitored, and the
security properties of the endpoints of the communication can
be speciﬁed at production-time of FANE: The open Internet
is insecure by default, the IoT devices are less secure, and
the devices in other network segments of the Smart Home are
trustworthy. This allows to pre-conﬁgure the security concept
of FANE in advance, i.e., it does not need a user with network-
security expertise (Property P1):
1) No device on the Internet is allowed to open a network
connection to the IoT network segment.
2) An IoT device is allowed to open a connection to the
Internet, if this is part of its normal operation.
3) An IoT device is allowed to open a connection to devices
in other (trusted) network segments of the Smart Home,
if this is part of its normal operation.
4) A device from a trusted segment is allowed to open
connections to the IoT network segment.
5) IoT devices are allowed to open connections to other
devices in the IoT network segment.
C. Smart Home Firewall Operations
FANE has to meet conﬂicting requirements: It must meet
the expectations provided by Smart Home components (P2). In
particular, this means that FANE must operate without constant
supervision (P3). At the same time, as a security component
it must not neglect the IT-Security process, including a plan-
do-check-act cycle to reﬁne ﬁrewall rules. However, this
must be possible without requiring the user to possess expert
We circumvent these conﬂicts, as shown in Figure 3):
We distinguish between pre-conﬁguration management and
Smart Home operations. Because we restrict FANE to the
network architecture described in Subsection IV-A, the policy
deﬁnition, the ﬁrewall design and a baseline conﬁguration of
ﬁrewall rules can be done at pre-conﬁguration time. Thus,
we shift the initial parts of the IT-Security process into the
responsibility of the Smart Home ﬁrewall manufacturer who
possess IT-Security expertise. Furthermore, we propose to
automate the conﬁguration and the plan-do-check-act cycle in
a way that it’s phases can be started without expert knowledge
at operation time. Finally, we deﬁne a process step in a way
that the user is informed when an IT-Security expert is needed.
CHRISTOPH HAAR, ERIK BUCHMANN: FANE: A FIREWALL APPLIANCE FOR THE SMART HOME 463
Smart Home Operations Pre-Configuration Management
Fig. 3. FANE Operations
D. User Interaction
After having deﬁned the operations of FANE, we can
deﬁne the user interactions needed. Observe that no interaction
requires expert knowledge (Property P1). FANE comes as an
IoT device that runs out-of-the-box after being connected to a
power outlet and the Internet.
When FANE is connected to the Smart Home installation
for the ﬁrst time or if new IoT devices are added, the user
can tell FANE to learn new ﬁrewall rules by observing the
network packets of the IoT devices. Assume an IoT device uses
a functionality that has not been used during the learning stage,
or the device has been updated and a new network connection
is now blocked by FANE. In this case, the user has the option
to let FANE re-evaluate the rule set. That is, FANE executes
a learning stage on a certain device with the option to discard
rules that have been learned before. The rules from the security
concept (Subsection IV-B) cannot be discarded.
If FANE blocks a large number of network packets per time-
interval, it generates an alert. The alert shows the user that
immediate action needs to be taken, i.e., something happens
that cannot be handled automatically by FANE. For example,
the IoT network segment might face a denial-of-service attack
from the Internet, or an IoT device has been taken over and
tries to connect to the attacker’s command and control server
on the Internet. In such cases, the user might decide to call
the customer support of the IoT device, or ask an IT-Security
expert for further investigations.
V. PRO OF -OF -C ON CE PT IM PL EM EN TATIO N
In this section, we describe the software and hardware
components of our FANE prototype, how FANE learns ﬁrewall
rules and in which way it interacts with the user.
A. Our FANE prototype
We have realized FANE on the basis of a Raspberry Pi,
which executes several linux shell scripts to conﬁgure and
operate an iptables packet ﬁlter (see Subsection II-C). Figure 4
illustrates our hardware conﬁguration and the main software
IP Forwarding Dnsmasq
Raspberry Pi Model B
SD Card SlotHDMI Port
Ubuntu Mate OS
Fig. 4. Our FANE prototype
a) Hardware: From Section IV it follows that FANE
must provide a Wi-Fi access point that creates a network
segment for IoT devices. The IoT devices might want to
communicate with other devices in the same segment, the
home network segment and the Internet. Thus, FANE must
be connected to the Internet, and its ﬁrewall must control all
incoming and outgoing network packets of the IoT network
We have implemented this approach on a third-generation
Raspberry Pi model B. This is a credit-card sized single board
computer containing a quad-core processor with 1.2GHz, 1 GB
main memory and various network and connection interfaces.
Because the on-board Wi-Fi chip cannot be conﬁgured as
a Wi-Fi access point, we have connected an external Wi-
Fi module via USB. We have used a 32 GB SD Card for
We would need only two switches to initiate the learning-
and re-evaluation stage of the user interface, and one LED
indicating an alert. The IT-Security expert, which might be
needed to handle serious attacks on the IoT nework segment,
would be able to obtain ﬁrewall logs and other information
by using an SSH connection. This way, our FANE prototype
464 PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019
costs less than 60 EUR. However, to ease development we
have used an external USB keyboard and a LCD monitor.
b) Software: We have used the Ubuntu Mate Linux
operating system as a basis of our software conﬁguration.
On top of a minimal OS installation, we need the following
software packages and services:
•awk (script language to edit text ﬁles)
•cron (timed execution of processes)
•dnsmasq (DHCP client and DNS cache)
•hostapd (Wi-Fi access point)
•inotify-tools (monitor changes in ﬁles)
•iptables (network address translation and ﬁrewall)
•tcpdump (record network packets)
By conﬁguring the Ethernet interface eth0 as a DHCP client,
our Raspberry Pi can be connected to any Internet router
without further conﬁguration. We have conﬁgured the wlan0
interface with a static IP address and subnet mask, and we
have conﬁgured it as a Wi-Fi access point by using hostapd.
Our Smart Home ﬁrewall must act as a bridge between eth0
(Internet) and wlan0 (Wi-Fi segment for IoT devices). Thus,
we have used iptables and sysctl to activate IP forwarding,
including network-address translation and masquerading. With
dnsmasq, we have realized a DHCP service.
B. Learning Firewall Rules
For our FANE prototype, we have used a straightforward ap-
proach to learn ﬁrewall rules. For more elaborate approaches,
see Section II. The learning stage consists of two phases, a
monitoring phase and a rule generation phase. We assume
that all network trafﬁc recorded during the monitoring phase
is allowed, i.e., we assume that no IoT device has been
manipulated or attacked before the monitoring phase ends.
When FANE is connected to power and Internet for the ﬁrst
time, or if the user wants FANE to learn new rules, it enters the
monitoring phase for a certain period of time. In this phase,
FANE waits for new IoT devices connecting to the access
point, and logs the network packets. We have implemented
this phase as follows:
At boot time, a cron task with the time preﬁx @reboot
starts a script that ﬁnds out if the set of ﬁrewall rules is the
one that has been pre-conﬁgured from the security concept
(Subsection IV-B). Alternatively, a user command starts the
monitoring phase manually. In the monitoring phase, FANE
uses the monitoring tool inotify to ﬁnd out if the dhcp.leases
ﬁle changes. This indicates new devices using the access point.
In this case, inotify executes a script that obtains the IP address
of the device from dhcp.leases. At the same time, FANE uses
tcpdump to create a log ﬁle containing all network packets
sent or received during the monitoring phase.
At the end of the monitoring phase, FANE stops tcpdump
and enters the rule generation phase. In this phase, FANE
parses the log ﬁle from tcpdump into ﬁrewall rules according
to the IP addresses of the IoT devices that have used the
access point in the monitoring phase. In particular, FANE uses
ased command to ﬁlter the log for incoming and outgoing
IP addresses and ports. This set of addresses and ports is
reduced to unique entries in a second step. The odd lines in
Figure 5 show, how the set of addresses and ports looks like
after FANE has removed surplus information and duplicats
from the log ﬁle. In a third step, a shell scripts parses the
remaining addresses and ports into ﬁrewall rules that allow
such packets for the iptables chain "‘FORWARD"’. The odd
lines in Figure 5 illustrate this step. We have used the iptables
policy "‘DROP"’, i.e., FANE drops all packets that are not
allowed by the rules generated.
115:23:18 IP 10.200.65.101.1080 > 126.96.36.199.80:
2iptables -A FORWARD -s 10.200.65.101 -sport
1024:65535 -d 188.8.131.52 -dport 80
-p tcp -j ACCEPT
315:23:22 IP 10.200.65.101.8553 > 184.108.40.206.1883:
4iptables -A FORWARD -s 10.200.65.101 -sport
1024:65535 -d 220.127.116.11 -dport 1024:65535
-p tcp -j ACCEPT
515:24:36 IP 10.200.65.101.8653 > 18.104.22.168.1883:
6iptables -A FORWARD -s 10.200.65.101 -sport
1024:65535 -d 22.214.171.124 -dport 1024:65535
-p tcp -j ACCEPT
715:25:07 IP 10.200.65.101.8554 > 126.96.36.199.80:
8iptables -A FORWARD -s 10.200.65.101 -sport
1024:65535 -d 188.8.131.52 -dport 80
-p tcp -j ACCEPT
Fig. 5. Firewall rules learned from an adjusted packet log
Note that this procedure can be extended easily to extended
ﬁrewall features, e.g., to include the iptables options for
stateful inspection. At the end of the rule generation phase,
FANE installs the rules and is ready for operation.
If an IoT device is not working properly, if a new IoT device
is added to the IoT network segment or if an existing device is
used in a way it has never been used before, the user can order
FANE to re-evaluate the rule set. In this case, the user has the
option to discard rules from preceding learning procedures,
and to re-start the monitoring- and rule-generation phase.
VI. EX PE RI ME NTAL EVAL UATION
In this section, we explore the applicability of FANE with
three different Smart Home appliances.
Figure 6 shows our experimental setup. FANE is directly
connected to the Internet router, and its integrated access
point spans a Wi-Fi network segment for IoT devices. The
Internet router creates a Wi-Fi home network that connects a
smartphone to the Internet. Different cloud services connect
the smartphone to the IoT devices. A cloud service might use
a load balancer, i.e., the IP addresses the IoT devices connect
to might change from time to time.
We have tested three different devices, which communicate
differently with a control app on the user’s smartphone:
CHRISTOPH HAAR, ERIK BUCHMANN: FANE: A FIREWALL APPLIANCE FOR THE SMART HOME 465
Fig. 6. Our experimental setup
1) An electrical IoT relay.
2) An IoT power outlet.
3) An IoT security camera.
The IoT devices do not communicate directly with each
other, but with the user’s smartphone and the Internet. Thus,
for our experiments we do not need to preconﬁgure rule 5
from our security concept (see Subsection IV-B). We have
conﬁgured each device for FANE’s IoT network segment.
We have used a monitoring phase of 40 minutes, and we
have operated each device periodically during this phase. In
the following, we brieﬂy introduce each IoT device, and we
describe what we have learned by using FANE as described.
B. IoT Relay
Our ﬁrst use case is an electrical relay "‘10A Wi-Fi
smart switch"’, sold for less than 9 EUR, manufactured by
Sonoff . The IoT relay can be turned on or off via
smartphone app, which allows a technician to integrate non-
smart electrical devices into a straightforward Smart Home
installation. Sending commands from the app to the relay
requires an Internet connection, i.e., there is no option to
directly connect the smartphone app to the IoT device. After
the relay is connected to the access point provided by FANE,
and the user has installed the smartphone app, the relay is
ready to use.
In our monitoring phase of 40 minutes, we have switched
the relay on and off frequently via smartphone app for 10
minutes. After that, we have waited for a period of 20 minutes.
Finally, we have operated the relay for further 10 minutes.
After completing the monitoring phase, FANE has written
1,800 lines in the packet log. All packets followed the TCP
protocol and were sent/received to/from one singular IP ad-
dress located at a dedicated server leased from Amazon. Thus,
the rule generation phase has generated only one rule for in-
and outgoing packets. The IoT relay was working properly
after FANE has activated the ﬁrewall rule set generated.
Figure 7 shows an example from the trafﬁc log FANE has
recorded from the IoT relay.
113:41:31.551813 IP 10.200.65.109.55147 >
184.108.40.206.443: Flags [F.], ...
213:41:31.551870 IP 10.200.65.109.55145 >
220.127.116.11.443: Flags [F.], ...
313:41:31.551914 IP 10.200.65.109.55161 >
18.104.22.168.443: Flags [.], ...
413:41:31.668878 IP 22.214.171.124.443 >
10.200.65.109.55161: Flags [.], ...
513:41:31.669239 IP 126.96.36.199.443 >
10.200.65.109.55161: Flags [P.], ...
Fig. 7. Fragment of the packet log of the IoT relay
C. IoT Power Outlet
Our second use case is an IoT power outlet "‘Smart Wi-
Fi Socket Model SWA1"’, sold for 18 EUR, produced by
Shenzhen Lingan Intelligent Technology . Similarly to
the IoT relay, the IoT power outlet can be turned on or off
via smartphone app. In addition, it can be controlled with
Amazon Alexa or Google Home, which allows to integrate
non-smart electrical devices into an elaborate Smart Home
concept without requiring a technician. Any command to the
IoT power outlet is handled by a cloud service over the
In our monitoring phase, we have used the IoT power outlet
via smartphone in the same way as the relay for 40 minutes.
At the end of the monitoring phase, FANE has collected a
packet log of approx. 2,600 lines, all of them TCP packets.
The rule generation phase has generated rules that allow ﬁve
466 PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019
different IP addresses, all of them in the address range of the
Amazon AWS cloud.
The IoT power outlet was fully operational after FANE
has started to ﬁlter network connections. We have observed
that only one of the ﬁve addresses in the ﬁrewall rule set
was actually used to operate the outlet via smartphone app.
We assume that some network connections are used only for
analyzing customer behavior or similar purposes, i.e., blocking
them would not reduce the functionality of the device.
D. IoT Security Camera
The most complex IoT device tested was a "‘720P HD IP
Wireless security camera"’, sold for 37 EUR and manufactured
by XinweiYa . The IoT security camera sends a live
video stream to the smartphone of the user. Furthermore, the
smartphone app allows to restart the IoT security camera,
and to rotate it around two axes. After connecting the IoT
security camera to a power outlet, it can be conﬁgured with a
smartphone app to use FANE’s access point.
During our monitoring phase of 40 minutes, we have
restarted the IoT security camera, we have let the IoT security
camera sent a live video stream of 10 minutes to the smart-
phone, we have waited for 20 minutes, and we have restarted it
again for another live stream of 10 minutes. After 40 minutes,
FANE has collected 8 MB packet log of approx. 27,000 lines,
most of them UDP packets.
The rule generation phase produces a rule set of 20 rules
for this device. Those rules allow services like Network Time
Protocol (NTP) or Domain Name System (DNS) as well as
cloud services hosted on Amazon AWS, the Microsoft cloud
and the Alibaba cloud.
We have observed that the IoT security camera was not
working properly, after FANE started to ﬁlter network packets.
Our investigations have shown that this due to a speciﬁc load
balancer. The IP address of the load balancer was allowed by
the ﬁrewall rule set generated. But the load balancer referred
the IoT security camera frequently to IP addresses unknown
to FANE. However, it would be possible to adapt the learning
approach to cope with such a load balancer. For example,
FANE could detect and accept IP addresses that are close by
addresses that are already allowed by the rule set.
The packet log has also shown that the IoT security camera
ﬁrst tries to reach the smartphone app in the same network
segment directly, via multicast. Thus, even if the IoT security
camera makes use of the Internet connection, it might be able
to provide its basic functionality without the Internet. From
this observation we conclude that there might be options for
FANE to distinguish between communication needed for the
normal operation of an IoT device, and other communication
needed for advertising purposes or usage analytics that can be
blocked without undesired side-effects.
Finally, we have observed that the IoT security camera
produces more network load by an order of magnitude than
the other IoT devices tested. While this has slowed down the
rule generation phase, it did not overstrain the IP forwarding
capacity of our Raspberry Pi during normal operation.
Our three use cases have provided evidence that a straight-
forward learning approach is applicable to many IoT devices
used in Smart Home scenarios. Two of our three IoT devices
remained fully operative after FANE has monitored the net-
work activities of our devices for 40 minutes, and has sub-
sequently generated and activated ﬁrewall rules. Furthermore,
our observations have shown that it would be easily possible
to extend our learning approach to consider load balancers.
As there is no communication standard for IoT devices, it is
problematic to generalize our ﬁndings to all IoT devices used
in the Smart Home. However, using a cloud service seems
to be typical for many use cases. Only network packets can
pass FANE that are allowed by a speciﬁc rule. Thus, FANE
increases the security of the Smart Home installation.
FANE operates without requiring the user to possess expert
knowledge, by making three assumptions: First, the network
segment created by FANE’s access point contains IoT devices
only. This allows to specify a security policy in advance,
before FANE is delivered to the user. Second, the IoT devices
operate as single-purpose appliances that do not fundamentally
change their communication proﬁles. Due to this assumption,
FANE can learn a rule set that remains stable over a long
period of time, which makes it compatible with the Smart
Home concept. Third, we assume that the IoT devices are
working properly during the monitoring phase. This allows
FANE to learn ﬁrewall rules unattended.
VII. CON CL US IO N
The last years have brought a plethora of Internet-of-Things
(IoT) devices dedicated to Smart Home installations. While
such IoT devices have numerous practical use cases, observa-
tions have shown that many of them come with IT-Security
risks. For example, the Mirai botnet consisted of approax.
500,000 baby-phones, security cameras and other insecure
IoT devices that were able to execute distributed denial-of-
service attacks with 1 Tbit/s network bandwidth. However,
typical Smart Home users do not possess the network-security
knowledge needed to identify and deter attacks on IoT devices.
Furthermore, the Smart Home concept encourages the users to
leave IoT devices unattended for long periods of time.
In this paper, we have introduced FANE, our concept for
a Firewall AppliaNcE for Smart Home installations. FANE
makes a few realistic assumptions on the network segmen-
tation and the communication proﬁle of IoT devices. This
allows to pre-conﬁgure FANE with a generic security concept.
It also enables FANE to learn ﬁrewall rules automatically by
observing the network trafﬁc of IoT devices.
Experiments with a prototypical implementation have pro-
vided evidence that FANE can secure ordinary IoT devices
without requiring network-security expertise from the Smart
Home user. Only one device was not working properly after
FANE has activated its ﬁrewall rules due to a speciﬁc load
balancer. However, this problem could be solved by accepting
IP addresses close to addresses that FANE already knows.
CHRISTOPH HAAR, ERIK BUCHMANN: FANE: A FIREWALL APPLIANCE FOR THE SMART HOME 467
ACK NOW LE DG ME NT
We would like to thank Eric Ilgunas for his exceptional
work on realizing and evaluating the FANE prototype.
REF ER EN CE S
 Nest Labs, Nest, https://nest.com/, Accessed: 2019-02-
 Wareable Ltd., Amazon Echo voice control, https : / /
www . the - ambient . com / guides / best - amazon - alexa -
commands-280, Accessed: 2019-02-25.
 C. Kolias, G. Kambourakis, A. Stavrou, and J. Voas,
“Ddos in the iot: Mirai and other botnets,” Computer,
vol. 50, no. 7, pp. 80–84, 2017.
 P. P. Gaikwad, J. P. Gabhane, and S. S. Golait, “A survey
based on smart homes system using internet-of-things,”
in 2015 International Conference on Computation of
Power, Energy, Information and Communication, IEEE,
2015, pp. 0330–0335.
 L. Jiang, D.-Y. Liu, and B. Yang, “Smart home re-
search,” in Proceedings of 2004 International Confer-
ence on Machine Learning and Cybernetics (IEEE Cat.
No. 04EX826), IEEE, vol. 2, 2004, pp. 659–663.
 R. Roman, J. Zhou, and J. Lopez, “On the features
and challenges of security and privacy in distributed
internet of things,” Computer Networks, vol. 57, no. 10,
pp. 2266–2279, 2013.
 T. Heer, O. Garcia-Morchon, R. Hummen, S. L. Keoh,
S. S. Kumar, and K. Wehrle, “Security challenges
in the ip-based internet of things,” Wireless Personal
Communications, vol. 61, no. 3, pp. 527–542, 2011.
 K. Neupane, R. Haddad, and L. Chen, “Next generation
ﬁrewall for network security: A survey,” in Southeast-
Con 2018, IEEE, 2018, pp. 1–6.
 J. Surana, K. Singh, N. Bairagi, N. Mehto, and N.
Jaiswal, “Survey on next generation ﬁrewall,” Interna-
tional Journal of Engineering Research and Develop-
ment, vol. 5, no. 2, pp. 984–988, 2017.
 G. Disterer, “Iso/iec 27000, 27001 and 27002 for infor-
mation security management,” 2013.
 Bundesamt für Sicherheit in der Informationstech-
nik, “BSI-Standard 200-2, IT-Grundschutz-Methodik,”
 O. of Government Commerce, Introduction to ITIL, The
key to managing IT services. Van Haren Publishing,
 S. Fenz, G. Goluch, A. Ekelhart, B. Riedl, and E.
Weippl, “Information security fortiﬁcation by ontolog-
ical mapping of the iso/iec 27001 standard,” in 13th
Paciﬁc Rim International Symposium on Dependable
Computing, IEEE, 2007, pp. 381–388.
 S. W. Lodin and C. L. Schuba, “Firewalls fend off
invasions from the net,” IEEE spectrum, vol. 35, no. 2,
pp. 26–34, 1998.
 K. Jaswal, P. Kumar, and S. Rawat, “Design and
development of a prototype application for intrusion
detection using data mining,” in 2015 4th international
conference on reliability, infocom technologies and op-
timization, IEEE, 2015, pp. 1–6.
 L. S. Parihar and A. Tiwari, “Survey on intrusion detec-
tion using data mining methods,” International Journal
for Science and Advanced Research in Technology,
vol. 3, no. 12, pp. 342–7, 2016.
 A. L. Buczak and E. Guven, “A survey of data min-
ing and machine learning methods for cyber security
intrusion detection,” IEEE Communications Surveys &
Tutorials, vol. 18, no. 2, pp. 1153–1176, 2016.
 K. Golnabi, R. K. Min, L. Khan, and E. Al-Shaer,
“Analysis of ﬁrewall policy rules using data mining
techniques,” in 2006 IEEE/IFIP Network Operations
and Management Symposium NOMS 2006, IEEE, 2006,
 A. K. Bandara, A. C. Kakas, E. C. Lupu, and A. Russo,
“Using argumentation logic for ﬁrewall conﬁguration
management,” in 2009 IFIP/IEEE International Sympo-
sium on Integrated Network Management, IEEE, 2009,
 D. B. Chapman, E. D. Zwicky, and D. Russell, Building
internet ﬁrewalls. O’Reilly & Associates, Inc., 1995.
 G. Kortuem, F. Kawsar, V. Sundramoorthy, D. Fitton,
et al., “Smart objects as building blocks for the internet
of things,” IEEE Internet Computing, vol. 14, no. 1,
pp. 44–51, 2009.
 Procter & Gamble, Oral-b genius electric toothbrushes,
https : / / www . oralb. co . uk / en - gb / products / electric -
toothbrushes/oral-b-genius, Accessed: 2019-04-25.
 N. Gupta, V. Naik, and S. Sengupta, “A ﬁrewall for
internet of things,” in 2017 9th International Conference
on Communication Systems and Networks, IEEE, 2017,
 J. Stark, “Product lifecycle management,” in Product
lifecycle management, Springer, 2015.
 A. R. Khakpour and A. X. Liu, “First step toward cloud-
based ﬁrewalling,” in 2012 IEEE 31st Symposium on
Reliable Distributed Systems, IEEE, 2012, pp. 41–50.
 C. Modi, D. Patel, B. Borisaniya, H. Patel, A. Patel,
and M. Rajarajan, “A survey of intrusion detection
techniques in cloud,” Journal of network and computer
applications, vol. 36, no. 1, pp. 42–57, 2013.
 ewelink, Sonoff relay, http : / / ewelink . coolkit . cc,
 lingansmart, Power outlet, http://www.lingansmart.com,
 XinweiYa Co.,Ltd., Security camera, http : / / www .
cctvgood.com, Accessed: 2019-04-25.
468 PREPROCEEDINGS OF THE FEDCSIS. LEIPZIG, 2019