Blog

Home / Cloud computing / Business-critical secure and manageable IoT

Business-critical secure and manageable IoT

0

Background

The Internet of Things (IoT) represents a general concept where any kind of a device or application can utilize the Internet for sharing data for different purposes.

An IoT device can be anything from a sensor, clock, camera, or handheld device to a general-purpose CPU board with an ability to send data using the Internet.
IoT use cases vary from industrial and commercial to personal and private, and from large scale to small scale.

An IoT device is usually comprised of an application (for example, a temperature measurement application) integrated with a network modem for Internet connectivity (for example, a cellular network modem).

IoT applications that connects to the internet, use standard protocols to reach a site or a centralized infrastructure located somewhere on the Internet. For example, a smartwatch with heartbeat and temperature measurement capabilities will share data it’s measured with a site on the Internet that collects the samples over time and generate graphs and aggregated data for the person who is wearing the watch.

Another example is a digital bus sign that displays relevant bus routes and schedules at a bus station. The sign periodically connects to the Internet using a cellular modem and periodically retrieves the latest information to be displayed from a centralized infrastructure maintained by the bus company on the Internet.

digital bus sign

Generally, an IoT application either collects data and shares it with a centralized infrastructure or retrieves data from a centralize infrastructure to be used by the IoT device. The IoT application typically uses a standard protocol stacks (TCP/UDP) and in most cases will use standard protocols like REST/HTTP or MQTT or others to send/receive messages.

Internet Connectivity

Most IoT devices are simple and can gain access to the internet using either personal area protocols (Bluetooth, WIFI…) or cellular network using a cellular modem. To gain internet connectivity the device itself will never be provisioned with an internet routable IP address. The device will gain access to the internet by NAT-ing it’s outgoing packets few times starting at the first modem and ending when hitting the internet provider’s internet NAT gateway. Since the device itself will never be provisioned with a routable IP inbound network access will not be possible (which is similar to how we’re accessing the internet from home or offices)

accessing the internet

For simple applications and use cases this architecture might be sufficient, an application will most likely act as a TCP/UDP client initiating a connection from the device to a known infrastructure and using an API protocol or a messaging protocol to send/receive message. This approach is friendly to NAT-ing and stateful firewalls and allows the application and protocol stack to be kept simple and agnostic to any network infrastructure (NAT devices, stateful firewalls) along its path.

Does this approach cover all use cases? probably not!

The Access Challenge

The architecture presented above ignores a set of maintenance use cases, for example, lifecycle management, firmware updates, troubleshooting, etc.

Imagine a measurement device connected to the Internet using a cellular modem located in a remote location (which is barely reachable). What if you need to upgrade the modem’s firmware or just change its configuration, reset a network interface, patch the underlaying OS with some important fixes or just upgrade the IoT application?

In non-IoT scenarios, these set of use cases are usually handled by just allowing secure inbound network access into the running system from the local LAN using a standard protocol such as SSH/RDP or HTTP for console and application access – but what if you don’t have a local LAN or no easy access to the IoT device?

Trying to solve it locally on the IoT device by configuring the modem to allow incoming traffic will probably not solve the problem since there may be NAT gateways, and stateful firewalls along the network path which will not allow inbound traffic.

In addition, opening inbound access on a modem adds a set of security vulnerabilities and subjects the device to security risks.

The general approach should be that any access solution must not force changing the IoT device architecture and/or impose having any kind of network knowledge. The solution must be able to manage NAT gateways, firewalls and ephemeral IPs that may reside along the network path, and not impose additional security risks on the device.

One option is to build an application and develop the support for various use cases. Standard communication protocol can be used to allow basic package management, firmware management and troubleshooting; but this approach increases the complexity of the IoT application and unless carefully crafted may introduce security risks.

Another option is to create a secure overlay network (VPN) between the IoT device and a well-known site to allow inbound traffic.

Using Secure Overlay Networks to Allow Inbound Access

In order to achieve such inbound access, you can setup a network VPN (like IPSec, PPTP, OpenVPN, etc.). Many network VPN protocols support client/server architecture and use standard TCP/UDP protocols. Once established, the VPN will allow bi-directional network access between a remote network and the IoT device’s private network.

VPN technologies can help gain direct network access into a LAN network located behind the cellular modem and access the cellular modem console without many changes to the architecture of the IoT device, and with minimum security risk.

Once the VPN is established, you can open an SSH/RDP session to the underlaying OS of the IoT device or use an Internet browser to access a web-based management console. With most modems, the VPN tunnel can be terminated by the modem which helps keep the IoT applications and underlying OS agnostic for how network access is established.

Network access to IOT

There are many VPN protocols, and each has numerous configuration options, nevertheless before picking one you must make sure that the VPN protocol and selected implementation support the following:
• The VPN protocol must support client/server mode when the VPN peer on the IoT device is the one that initiates tunnel establishment. The VPN protocol must run over either UDP or TCP and must be NAT and stateful firewalls friendly.
• The VPN protocol implementation must allow persisting the connection; in case the tunnel goes down, the client will be able to re-establish a connection without user intervention.
• VPN protocol and implementation must provide a “keep alive” configuration and a way to detect when the tunnel is down.
• Credentials for VPN tunnel establishment (including re-establishing and re-key use cases) must not be based on interactive input (like user name and password).
• VPN protocol and implementation must allow the client to identify itself with a unique identity that is not its public IP (since the client will never actually know its public IP and it may change in the future).
Most, if not all, VPN implementations support a mode that complies with the above requirements.

Configuration Example for Base on IPSec Protocol

The following configuration example shows how to use IPSec VPN to setup such a connection. The configuration is based on well-known opensource IPSec implementation libreswan (https://libreswan.org/).

Network setup:
• The IoT modem has a LAN network 192.168.254.0/24, on which all the IoT devices are connected
• The private network on the data center network is allocated to be used for accessing IoT device network – 10.100.0.0/24
• VPN aggregator (server side) public IP is 256.256.256.256 (this is of course a fake IP to be replace by a real one)
• IoT modem VPN identity is in FQDN format and is @fqdn.id3

VPN Aggregation (server-side) Configuration

 

Name-configuration string Description
conn IoTConnection
authby=secret
#shared secret based auth (no need for a password)
auto=start
#load the connection when stating the server
dpddelay=30
#Keep Alive configuration
dpdtimeout=120
#Keep Alive configuration
forceencaps=yes
#Force IPSec over UDP (NAT and firewall friendly)
right=%any
#accepting the connection from any IP address
rightid=@fqdn.id3
#peer will identify itself using an id and not IP address
rightsubnets=192.168.254.0/24
#IoT device LAN network
leftid=256.256.256.256
#VPN aggregator will identify using public IP
leftsubnets=10.100.0.0/24
#data center network
left=%defaultroute
#gateway route
ike=aes128-sha1
#IPSec properties (example)
pfs=no
#IPSec properties (example)
phase2alg=aes128-sha1
#IPSec properties (example)
ikelifetime=86400s
#IPSec properties (example)
salifetime=28800s
#IPSec properties (example)
type=tunnel
#IPSec properties (example)

IoT Modem-side Configuration

Name-configuration string Description
conn IoTConnection
authby=secret
#shared secret based auth (no need for a password)
auto=start
#load and establish the connection when stating the server
dpddelay=30
#Keep Alive configuration
dpdtimeout=120
#Keep Alive configuration
dpdaction=restart
#model will persist the tunnel every time it goes down
forceencaps=yes
#force IPSec over UDP (NAT and firewall friendly)
right=256.256.256.256
#aggregation point public IP
rightid=256.256.256.256
#aggregation point identification
rightsubnets= 10.100.0.0/24
10.100.0.0/24
left=%defaultroute
leftid=@fqdn.id3
leftsubnets=192.168.254.0/24
ike=aes128-sha1
#IPSec properties (example)
pfs=no
#IPSec properties (example)
phase2alg=aes128-sha1
#IPSec properties (example)
ikelifetime=86400s
#IPSec properties (example)
salifetime=28800s
#IPSec properties (example)
type=tunnel
#IPSec properties (example)
Nevertheless, while the reverse access is now achievable and secure, it is still recommended to add other layers of security inside the tunnel, for example using SSH instead of telnet, making sure console access is done using HTTPS and is protected by user name and password.

Beyond a single IoT device – How to scale?

Now, if all problems were that easy.

In most IoT deployments we need to handle a large amount of IoT devices and therefore be able to aggregate connectivity of many VPNs.
Scaling this solution introduce a set of other challenges like aggregating numerous VPN connections, handling overlapping IP addresses, granular access control and high availability to list a few obstacles.

If you’d like to see how 40Cloud can help you scale and secure your IoT deployments, join our service for free to get a glimpse of our capabilities.

We are happy to receive comments and questions on this post. You can leave them here at the Blog or by sending an email to our support team support@40cloud.com.


Subscribe to newsletter

Recommended Posts

Free Trial

Request a Demo