Low-cost flow-based security solutions for smart-home IoT devices
Abstract:
The rapid growth of Internet-of-Things (IoT) devices,such as smart-bulbs, smoke-alarms, webcams, and health-monitoring devices, is accompanied by[李杨1] escalating threats of attacks that can seriously compromise household and personal safety. Recentworks have advocated the use of network-level solutions to detect and preventattacks on smart-home IoT devices. In this paper we undertake a deeperexploration of network-level security solutions for IoT, by comparing flow-based monitoring with packet-based monitoring approaches. We conduct experiments with realattacks on real IoT devices to validate our flow-based security solution, anduse the collected traces as input to simulations to compare its processing performance against a packet-based solution. Ourresults show that flow-based monitoring can achieve most of the securitybenefits of packet-based monitoring, but at dramatically reduced processing costs. Our study informs the design offuture smart-home network-level security solutions.
Publishedin: Advanced Networks and TelecommunicationsSystems (ANTS), 2016 IEEE International Conference on
Date of Conference: 6-9 Nov. 2016
Date Added to IEEE Xplore: 15 June 2017
ISBN Information:
INSPEC Accession Number: 16963741
DOI: 10.1109/ANTS.2016.7947781
Publisher: IEEE
Conference Location: Bangalore, India
物联网设备(如智能灯泡、烟雾报警器、网络摄像头和健康监测设备)的快速增长，伴随着不断升级的攻击威胁，这些攻击可能严重危及家庭和个人安全。
最近的工作已经提倡使用网络级的解决方案来检测和防止对智能家庭IoT设备的攻击。
在本文中，我们将通过基于流程的监视和基于分组的监控方法来对IoT的网络级安全解决方案进行更深入的探索。
我们对实际的物联网设备进行了真实的攻击，以验证基于流的安全解决方案，并将收集的跟踪作为模拟的输入，以将其处理性能与基于包的解决方案进行比较。
我们的研究结果表明，基于流程的监视可以实现基于包的监视的大部分安全好处，但是可以显著降低处理成本。
我们的研究报告了未来智能家庭网络级安全解决方案的设计。
SECTION I.
Introduction
The rapid proliferation of Internet ofThings (IoT) devices is giving rise to “smart-homes” that can be monitored andcontrolled remotely over the Internet. Consumers can now controltheir lighting systems from anywhere [1], receive alerts on their mobilephone when smoke is detected in the house [2], monitor their kids from afar [3], andturn appliances on/off while driving to/from work [4]. Recentsurveys in the US have shown that many consumers are willing to pay in excessof $500 for a fully-equipped smart-home, citing personal or family safety, property [李杨2] protection,lighting/energy management, and pet monitoring as top motivators [5].
The increasingprevalence of smart-homes with Internet-connected devices creates securityconcerns at unprecedented levels. An eavesdropper can illegitimately snoop into family activities, and a malicious entity can take control of the hometo either harm the household or to use it as a launch-pad for attacks intoother domains. The vulnerabilities of existing IoT devices have been documented by severalearlier studies [6], [7], and there is evidence of anecdotal [8] as wellas large-scale attacks [9] on IoT devices.
Securing IoTdevices from attacks remains a formidable challenge. The large heterogeneity in IoT devices,each with its own hardware, firmware, and software, makes the securityvulnerabilities diverse and the attack vectors manifold. Worse, device manufacturers have been lax in embeddingsecurity in consumer IoT devices, dissuaded by low margins, time-to-marketpressures, and limited resources. One could argue that the home router, by virtue of itsNAT/firewall functionality, provides an effective protection against externalattacks by dropping unsolicited Internet traffic directed to householdIoT devices. However, our recent work in [10] has shown that eventhis perimeter defense can be bypassed via malware embedded intomobile Apps; such malware can scout the internal network for vulnerable IoT devices, anddisable the home firewall to allow Internet attacks on such devices.
We believe that a promising approach tothe above problem is to embed securitysolutions at the network-level, whereby network trafficto/from IoT devices is monitored to detect (and block) attacks, much the waytoday's intrusion detection systems (IDS) monitor enterprisenetwork traffic for security threats. Indeed, our prior work [11] hasdemonstrated the utility of traffic-flow monitoring in securing accessto devices such as light-bulbs in the smart-home; concurrently, workin [12] has developed a method for specifying IoT security policies,that are then applied to the network data-plane traffic via specializedmiddle-boxes (termed μm boxes).
While the abovemethods show promise in securing smart-homes at the network-level, it remainsunclear what their cost/benefit trade-offs are, particularly since inspection of networktraffic can involve significant costs that may be difficult to recover in aresidential market wherein profit margins are low. In this paper, we undertakean evaluation of the cost-benefit trade-offs of a flow-level approach (thatpredominantly uses information about active flows in the network) against apacket-level approach (that looks into the content of the data packets) forsecuring smart-home IoT devices. In this context, our contributions are:
- We develop an architecture and method for flow-level characterization of IoT traffic, that can effectively detect malicious IoT activity while minimizing the need to inspect content of IoT data packets;
- We validate our approach experimentally by launching internal and external attacks on real IoT devices, and analyzing the resulting traffic traces; and
- We evaluate our approach to show that our flow-based technique can achieve comparable security performance to packet-level inspection techniques, but at dramatically reduced processing cost.
The rest of this paper is organized as follows: §II describesprior work on IoT security solutions, and §III describesour solution approach that captures and evaluates flow-level information.In §IV wedescribe our experimental setup including attack emulation and tracecollection, used tso validate our solution, while in §V weevaluate the cost-benefit trade-offs via simulation. The paper is concludedin §VI.
SECTION II.
Background and Prior Work
Prior work onIoT security can be characterized as host-based or network-based.Host-basedschemes embed security in the IoT device itself, either adaptingexisting security mechanisms, or developing new ones, to suit the resourceconstraints of IoT devices. For example, the work in [13]explores the useof popular IP-based network management protocols for IoT and shows that sessionkey generation can be very costly, making SNMP more suitable in terms ofresource usage than NETCONF. An architecture for secure end-to-endcommunication for IoT is proposed in [14], that moves the expensiveauthentication and encryption operations out of the IoT device into an externalentity with abundant resources. A similar approach is taken by [15], whichpoints out that the DTLS (Datagram Transport Layer Security) handshake requiressignificant resource requirements when employing public-key cryptography forpeer authentication and key agreement-by offloading the DTLS connectionestablishment to a non-resource constrained delegation server, the authors showthat memory and computation overhead can be reduced by 64% and 97%respectively.
A lightweightsecure protocol for IoT devices called Lithe is proposed in [16]. Resourceconstrained devices are expected to use CoAP (Constrained Application Protocol)at the application layer, and DTLS (Datagram Transport Layer Security) at thetransport layer for secure communication. However, since DTLS is not wellsuited for use in resource constrained devices, Lithe proposes a novel methodto compress the DTLS protocol using the 6LoWPAN header compression mechanisms.Experiments demonstrate the suitability of Lithe for application in IoTdevices. The work in [17] identifies challenges in the handshakephase of HIP DEX (Host Identity Protocol Diet EXchange), another IP securityprotocol for use in constrained IoT devices, and proposes lightweightextensions to it. The standardization effort underway at the InternetEngineering Task Force (IETF) for securing IoT devices using CoAP and DTLS isdescribed in [18]. The work in [19]gives a perspective of howconcepts from information centric networking (ICN), which is still in itsinfancy, can be used in IoT security. A comprehensive survey of securitysolutions in IoT with a focus on key management, authentication, andconfidentiality can be found in [20].
The host-based IoT security solutions above not only have to contend withthe constrained resources on IoT devices (processing, memory, battery, andradio), but also the lack of motivation amongst vendors to implement theseschemes. In their rush to market, vendors often do not have the time, skills,resources, or financial incentives to embed security in their products. Thishas motivated recent proposals to develop network-based securitysolutions [12] that are better suited to the scale of deployment(i.e. billions of devices), nature of communication (device-to-device thanhuman initiated), diverse use cases (e.g. motion sensory triggering an alarm,temperature sensor opening the windows, etc.), and interoperability constraints(devices from different vendors unable to communicate with each other). Ourprior work in [11] also explores the potential of network-levelsecurity for specific IoT devices like the Phillips Hue light-bulb and Nestsmoke-alarm. While both proposals advocate the use of Software DefinedNetworking (SDN) in the control plane, [12] makes use of specializedmicro-middleboxes (μmboxes) in thedata plane to inspect IoT packets. Among the objectives of the present work isto compare the efficacy and cost of flow-based versus packet-based securitysolutions, as described next.
Fig. 1.
Systemarchitecture showing data and control planes
SECTION III.
Our Flow-Level Security Solution
We outline oursolution architecture that operates at the flow-level method to detectintrusions on IoT devices in the home network. The aim is to discover attackpatterns or suspicious network activity inside the home at low cost and in aprogrammatic way, so that the network resources are used as efficiently aspossible for protecting IoT devices against security attacks. Unlike otherproposals that require the use of deep packet inspection (DPI) or othervirtualized network functions (NFV) for detecting threats, we advocate the useof dynamic characterization of the traffic at the flow-level. This requires usto inspect only a tiny fraction of data-plane traffic, thereby limiting theprocessing cost and network bandwidth overheads. The type of flows that need tobe inspected are chosen dynamically and can change according to thevulnerabilities. Lastly, we manage and process flows from cloud-based software,instead of embedding the processing unit into the home gateway that isdifficult to maintain and upgrade.
A. OperationalScenario
Fig.1 shows our system architecture. Each residence has a home gateway towhich household devices connect. The home gateway offers Internet connectivityvia a (DSL, Cable, or PON) broadband link. The home gateway is SDN-enabled andmanaged by a controller hosted on the cloud. We propose an “analysis engine”that interacts with the SDN controller via northbound APIs. It issues requeststo the SDN controller on which flows are inspected. The controller thenprograms the home gateway with rule(s) to mirror selected traffic flows towardthe analysis engine. Therefore, the analysis engine will be able to activelymonitor the network activity of IoT devices by inspecting few packets to/fromIoT devices with specific headers as well as measuring the load of selectedflows. Whenever traffic analysis is concluded, then traffic mirroring can bestopped by deleting the pertinent rule(s) inside the home gateway.
B. The AnalysisEngine
When themirrored traffic comes in to the analysis engine operating in the cloud, analgorithm is run to inspect the flow, e.g. recording source and destinationentities of certain requests and responses. If needed, the analysis enginerequests the controller to install rule(s) corresponding to IoT devices thatare accessed from the Internet. This may involve setting up subsequent rulesensuring not all data-plane traffic is forwarded to the analysis engine. Inwhat follows we describe the rules in more detail and elaborate on theirspecific match and action fields.
C. The NetworkRules
A home networkis protected by NAT service from potential Internet-based attackers. However,client devices can be exposed to Internet attacks by abusing the Universal Plug-n-Play(UPnP) port forwarding capability on a typical home gateway. We have shownin [10] that a malware application running on an unsuspecting user'smobile device can discover IoT devices within the home by using a standardSimple Service Discovery Protocol (SSDP); this can be followed by a UPnP portforwarding command to the home router that allows an external attacker todirectly attack the IoT device. We note that SSDP and UPnP port forwardingmessages are common in a typical home network environment for variouspeer-to-peer applications (e.g. Skype) and multi-player games.
Sinceprotocol-specific traffic is characterized by known packet headers, we proposeto push rules into the home gateway to capture certain traffic types and andforward them to the analysis engine. Note that these rules will ensure normalforwarding of traffic, along with sending a “mirror” copy to the analysisengine. This allows the home gateway to provide standard data-plane forwardingwithout being affected by the intrusion detection process. By receivingflow-level data, the analysis engine will gain flow-level visibility intoclients (i.e. IP and MAC addresses) and their network activity within the homenetwork. For example, SSDP uses UDP transport protocol on port 1900. Thus,having rule entries that match UDP source/destination port 1900 would captureall SSDP requests and responses transferred in the home network. On the otherhand, a port forwarding request is communicated with the home gateway usingHTTP post mechanism. It consists of a sequence of data exchanges that can becharacterized by a network rule which matches the destination IP address of thehome gateway.
Fig. 2.
Testbed showingiot devices, SDN home gateway, and external attacker
Detection of SSDP and port forwarding messages are not sufficient todiscover suspicious activity or an attack. We propose to monitor Internettraffic flows to/from an IoT device to create a richer context around access ofa specific device. The remote access traffic of an IoT device inside the homenetwork can be identified by a rule that matches the source MAC of the defaultgateway as well as the destination MAC address of the device for downstreamtraffic from the Internet (and vice versa for the upstream direction towardsthe Internet). Once the analysis engine receives the first packet of such flowand extracts the IP address of the remote host, it instructs the controller toinstall a pair of new higher-priority rules into the home gateway that matchsource/destination IP of remote host and destination/source IP of the IoTdevice with action “normal” only (i.e. no more packets for this flow areforwarded to the analysis engine). This allows us to reduce the cost of our inspectionprocess.
SECTION IV.
Experimental Setup and Validation
Setup
We built a smalltestbed in our lab, depicted in Fig. 2, to emulate a typical home network.We used a standard TP-Link WR1043ND home gateway and flashed it with OpenWrtfirmware version 15.05. We also installed additional OpenWrt packages such astcpdump for capturing traffic, bash for scripting, and miniUpnp for managingthe home gateway. We connected the WAN interface of the home gateway to ouruniversity campus Internet while the IoT devices were attached to the LAN/WLANinterfaces. The IoT devices connected to the gateway include Samsung's SmartThings, D-Link DCS-5300G IP security camera, Belkin's Wemo switch and WemoMotion detector. The Samsung Smart Things kit includes a collection of IoTdevices that connect to the router through an internal hub. These IoT devicescommunicate with a mobile App when an activity is triggered such as motiondetection or a clip is removed. The D-Link DCS-5300G is a standard IP surveillancecamera that a user can control it (i.e. pan, tilt or move the preset position)and access its video/audio stream over the network. Belkin's Wemo switch is asmart switch that can be turned on/off using pertinent mobile App whileBelkin's motion detector uses an App to alert the user when someone has movednear the device. A laptop and an Android phone were also present in the networkto communicate with the IoT devices and generate user traffic on the networkrespectively. To collect traffic flowing through the home gateway, we usedtcpdump application that continuously recorded all traffic of all interfaces.We then stored the collected data into a pcap file on an external hard driveattached to the home gateway via its USB port.
Traffic
The aim is toexperiment on a smart-home environ-ment comprising real IoT devices andvalidate our approach by launching internal and external attacks to IoTdevices. Therefore, we recorded all network traffic over an 18 minute (1080second) period. During this period all the devices on the network generatedtheir usual traffic. This included the application on the smart phonecommunicating with the Samsung SmartThing hub when the multipurpose sensor wastriggered. Similarly the Belkin Wemo Motion detector was continuouslytransmitting data to the smart phone when it detected movement. The IP camerawas also accessed, and a live video stream was watched on the laptop, all ofthis was occurring on the internal network. Moreover, the android phone andlaptop were accessing popular Internet content such as Youtube and Facebook toemulate user traffic on the network. All of this traffic would signify everydaynetwork usage in a typical home environment.
Attack
While thetraffic was being captured, an attack was launched from a script running on thelaptop. We assume that the laptop was “infected” by malicious code (i.e ourscript), and carried out an attack by enabling port forwarding for selected IoTdevices. An infection can occur if a user unintentionally executes a maliciousapplication. In our case, we manually ran two python scripts to emulate thisattack. This device would already be authorized to connect to the internalnetwork and would be connected inside of the NAT. The infected host would theninstigate the attack in three different stages: (a) Discovery, (b) PortForwarding and (c) Access.
SSDP Scan
The first pythonscript (i.e. “discovery.py”) performed an SSDP broadcast. The script sends amsearch multicast packet to 239. 255. 250: 1 900. This is an assigned IPaddress set by IANA for the UPnP protocol. The IoT devices that implement UPnPwould respond with basic information about themselves and a URL which containsan XML file that describes the device functionalities. In this XML file, thereis a control URL which is then used to trigger an action in the device via aHTTP POST request. For the D-Link IP camera, this URL is the user/browserpresentation (192.168.1.124:5004) and for the Belkin Wemo switch it is the URLwhich manipulates the switch state (192.168.V. If the home gateway has UPnPenabled, then its control URL is contained under the WANIPConnection service.One of the services that WANIPConnection provides is to set up a new port mappingbetween an internal IP address/port to an external port.
Fig. 3.
SOAP message
Port-Forwarding
Setting up the port forwarding was the next step in our attack. Our script(i.e “port-forward.py”) was run which maps an external port to the control URLof the IoT device, allowing an external user to have direct access the internaldevice. The script created a specific SOAP-based HTTP POST request and sent itto the WANIPConnection control URL of the home gateway which was discoveredearlier by the first python script. The SOAP Envelope is depicted in Fig.3. It can be seen that the IoT device (i.e. Internal−Portand Interna1-Ip)is exposed to an external attacker via a direct access to port $External-Portfrom the Internet. Accessing the device is the final stage of the emulatedattack.
Attack Detection
After conducting SSDP discovery and port forwarding from an internalinfected host, we then used an external host (public IP address 129.94.8.54) tolaunch the attack. Given the information collected in previous stages, the WemoSwitch and IP Camera were successfully accessed from the external host. Thisattack has many implications; we can imagine if the SmartThings multipurposesensor was on a door, acting as a security alert when the door was opened.However, the SmartThings hub was powered through the Wemo Switch. An externalattacker would be able to use the camera and see whether the Smart Home wasoccupied. If the attacker saw that no-one was home, they could turn off theWemo Switch, disabling the SmartThings security, thereby allowing the attackerphysical access to the home. In this case the added layer of physical securityhas been bypassed due to insecurity in the network layer. The trace file aboveenacts this scenario. Using our flow-based analysis, the sequence of activity(SSDP scan followed by port-forwarding command followed by external access) islogged, and the potential malicious activity is flagged.
SECTION V.
Evaluation Via Simulation
We now evaluatethe computational cost of our solution by applying it to real trace dataobtained from our testbed. Our pcap trace file of size 327 MegaBytes covers a1080 second period and comprises 334, 088 packets. A time trace of the trafficload is shown in Fig. 4. We note that the average load on the network is301 Kbps, however it is seen that the load sometimes spikes to over 1 Mbps dueto the buffering behavior of Youtube traffic.
Fig. 4.
Total capturedload of data-plane
We wrote anative simulation in C that takes packet arrivals from the trace as input, andperforms discrete event simulation on an SDN-based home gateway along with acontroller and an analysis engine. The simulator manages a table of rules (i.e.a flow table) inside the home gateway according to the events that occur at runtime and keeps track of certain events (e.g. detection of port forwardingattack) and performance metrics (e.g. mirrored load).
As explainedearlier in III-C, the flow table of the home gateway is initialized by thecontroller module of our simulator to contain proactive rules that capture SSDPand port forwarding traffic.
SSDP SpecificRules
In oursimulation, the following proactive rules capture SSDP requests and responses:
- SSDP-Request: Priority: 1, Match:“udp_dst=1900”, Action: “normal, tunnel”
- SSDP-Response: Priority:1, Match:“udp_src=1900”, Action: “normal, tunnel”
In realpractice, a “tunnel” interface on the home gateway is needed to feed the remoteanalysis engine on the cloud. Therefore, in our simulation, a packet is deemedto be received by the analysis engine module only if the packet matches a rulethat has a “tunne1” interface in the action field.
UPnP PortForwarding Rules
The DHCP serverof our testbed provides local clients with IP addresses in the range of192.168.1.100-254/24 with a default gateway of 192.168.1.1. Therefore, thefollowing proactive rule captures all traffic sent directly to the localdefault gateway:
- Priority:1, Match:” ipv4_dst=192.168.1.1”Action: “normal, tunnel”
In the analysisengine we use a regular expression pattern match to identify the portforwarding request and extract the internal IP and port number. If a hostenables a port forwarding for an IoT device, the analysis engine flags it as suspiciousactivity that is trying to create a back-door to access the IoT device.
Remote AccessRules
Upon processingSSDP messages, the IP and MAC addresses of IoT devices inside the home arediscovered by the analysis engine at run time. Therefore, the followingreactive rules are installed to capture intial Internet traffic from/to eachIoT device in order to detect the flows:
- to-IoT: Priority: 10, Match:” eth_dst=mac-iot, eth_src=mac-gw”, Action: “normal, tunnel”
- from-IoT: Priority: 10, Match:“eth_src=mac-iot, eth_dst=mac-gw”, Action: “normal, tunnel”
We assume thatthe MAC address of the default gateway (i.e. “mac-gw”) is a known parameter bythe controller.
In order tolimit the processing cost of mirroring IoT traffic (specifically for a devicelike a camera that is sending a continuous video stream), once the first fewpackets of a flow are detected and processed by the analysis engine, theflow-level details (such as IP address of the remote host) are recorded. Theanalysis engine thereafter requests the controller to install another rule witha higher priority, the match field is updated with the IP address of the remotehost and the action field is set as “norma1” so as to stop mirroring trafficpertaining to this flow:
- to: Priority: 100, Match:” eth_dst=mac-iot, ipv4_src=remote-ip”, Action: “normal”
- from: Priority: 100, Match:“eth_src=mac-io, ipv4_dst=remote-ip”, Action: “normal”
With the aboverule inside the home gateway, the analysis engine is able to track the flowactivity by periodic reading of counters via the controller to maintainingreal-time statistics. Therefore, the load or the volume of the flow can providethe analysis engine with more information about such remote access into an IoTdevice.
Results
Our simulationkeeps track of performance metrics such as the Size of the flow table, totalnetwork load, and volume of mirrored traffic. We ran our simulation using thecollected traces from the previous section as input, and make the followingobservations. Our analysis engine was able to detect all SSDP and portforwarding messages exchanged over the emulated home network, by virtue of thepro-active SDN rules installed in the home gateway. In Fig. 5(a) weshow the processing cost of our solution: the solid blue line shows the totaldata-plane load arising to/from IoT devices, averaging around 9.65 Kbps, and isproportional to the processing cost of a packet-based solution that inspectsall data-plane IoT traffic. By contrast, the dashed red line in the figureshows the volume of traffic that is forwarded to the analysis engine in ourflow-based approach-the average load of mirrored traffic is only 0.84 Kbps,which is roughly an order of magnitude lower than required by the packet-basedmonitoring approach. This is not surprising, because our approach only needsthe first few packets of each flow to be sent to the analysis engine, whichthen inserts a reactive flow-entry to stop the packet mirroring, and usespacket/byte-counts thereafter to monitor flow activity without inspectingpacket contents. This dramatically reduces processing costs; indeed Fig.5(b) shows the traffic load pertaining to the IP camera that was accessedfrom a remote host during our simulation-in this case forwarding the videopackets to the analysis engine is wasteful, and our method only logs the flowactivity rather than the actual video content. In Fig. 6we show the volumeof IoT data plane traffic over the 18-minute duration; of the total IoT dataplane traffic volume of 10, 454KB, only 908KB, corresponding to 8% of the totalIoT traffic volume, needs to be forwarded to the analysis engine in ourapproach, making the processing cost acceptable for home users. Lastly, wewould like to point that our method does not inspect packet contents, and wouldtherefore not detect attacks (such as use of default plain-text passwords) thatrequire examining the data inside packets.
Fig. 5.
Processing cost:(a) IoT data-plane load and mirrored traffic load; and (b) traffic load of IPcamera
Fig. 6.
Pie chart oftotal and mirrored traffic volume
SECTION VI.
Conclusion
Securing IoT devices in the emerging smart-home is a critical yetchallenging problem. This paper has examined the use of network-levelmonitoring to detect and mitigate IoT security threats. Specifically, we haveinvestigated the use of SDN to monitor network traffic at flow-levelgranularity. We have shown that this is effective in detecting securitythreats, without incurring the high costs of packet-level monitoring of trafficto/from IoT devices. We have validated our solution in an experimental test-bedwith real IoT devices. We have also evaluated via simulation of gatheredtraffic traces the processing overheads of our solution, and found them to below is cost. We hope that our work will spur more research into the use of flow-levelmonitoring to mitigate security threats on the future smart-home.
[李杨1]伴随有（。。。），相伴而生
[李杨2]性质、性能、所有权