Remote industrial devices need protection too
- By Michael Derby
- Feb 01, 2013
Connection of industrial network devices with a cellular modem
can be challenging. In most cases, industrial network devices
are operating backwards from how typical consumers utilize an
Internet connection over a cellular modem. Consumers usually
receive data from the Internet while industrial devices are a general
source of information to users that have knowledge of the Internet address
of the device.
To protect networked devices from unsolicited Internet probes, a firewall is used
to restrict access from external users trying to gain access to internal network devices.
A typical firewall does not restrict outbound requests to the Internet, while
incoming requests from the Internet are tightly managed or forbidden. The only
way to pass through a firewall from the Internet is to be invited by an internal user.
The firewall registers and tracks each internal user’s outbound requests with corresponding
responses from the Internet.
These matching responses from the Internet are approved by the firewall and
forwarded onto the internal network user, whereas data coming from the Internet
that doesn’t have a registered request is rejected.
A firewall’s registration process uses “port numbers” to keep track of the flow
of incoming and outgoing data requests and responses. A port is registered and
opened to a specific Internet address when an outbound request is made and the
response comes back to the same port for validation by the firewall. Only responses
from the queried Internet address are allowed through the firewall, but it is
possible to manually setup ports on a firewall to “forward” incoming data requests
from the Internet.
The firewall is programmed by its administrator to open specific ports and will
then directly forward all data that is received on that port to a specific internal
Port forwarding can be dangerous because it opens a hole in the firewall for Internet
probing and network entry. Network safeguarding is now partly the responsibility
of the device receiving the forwarded data. Devices that are receiving data
from a forwarded port on the firewall must have well-architected security features
because they will be directly visible to Internet users and hackers. Many legacy
network devices do not have adequate security provisions since they were designed
for use only by known users on safe internal networks.
Port forwarding works with traditional Internet service providers because they
don’t restrict incoming ports from the Internet and they leave management of firewall
protection to the customer. However, this is not the case with cellular-based
Internet service providers. These providers use a filter, which blocks the incoming
requests that would normally be handled by the user’s firewall. This filter does not
impact consumers who send outbound (HTTP/web) requests to the Internet, but it
does block inbound requests from hackers and, unfortunately, from well-intended
users looking to make connections with their remote devices.
To gain access to a remote device, the cellular provider’s filter needs to be turned
off. There are two challenges with this. The first is finding an authorized administrator
of the carrier’s filter and convincing the person to do this. The second is that
turning off the carrier’s filter may allow unsolicited probes to consume the user’s
usage allowance from the carrier.
Upon clearing the hurdle of ensuring the unfiltered ability to correctly forward
ports, the next challenge is to get a fixed Internet address. Cellular connections
are typically pre-configured with a non-fixed IP address, where the IP address is
assigned at the start of each connection and changes at points during the connection.
A fixed address allows users to query the assigned ports for their devices at
an unchanging location on the Internet.
An example address might be: http://184.108.40.206:8081. Adding the preestablished
port number of :8081 to the fixed Internet address of 220.127.116.11
tells the remote firewall that access is wanted to the internally networked device
that this port is forwarded to. The http:// tells the browser to expect an HTML response.
Obtaining a fixed address from a cellular carrier can be difficult and often
expensive. Once a fixed IP address is obtained and incoming ports are forwarded,
an internal network device can be successfully located and queried over the Internet
at a fixed address:port.
Due to the high cost and effort to obtain a fixed IP address, dynamic domain
name services (DDNS) can be an attractive alternative. DDNS circumvents the
non-fixed IP address ambiguity problem where a server is not at a fixed, unchanging
network location and is a variation of the more familiar DNS service. The Internet
uses domain name servers (DNS) to allow use of a human-recognizable word
combination (the URL) to be matched up with an IP address for the desired server.
An example DNS lookup would be “www.avalanwireless.com = 18.104.22.168”.
The user has the choice in their browser to type the words (and use a DNS server)
or to use the IP address numbers directly to connect to the desired Web site.
The user’s DNS server maintains lookup tables that get updated whenever a
change occurs in the IP address of any Internet server, but this happens slowly
as the information is propagated to DNS servers around the world. DDNS is a
trusted intermediary service that provides a URL that is automatically updated
by the cellular modem whenever the carrier changes the modem’s IP address. The
user can now point their browser to the intermediary DDNS server and have a
reliable “real-time” way to access the cellular modem’s IP address from anywhere
and anytime the user might need. A basic account with a DDNS service provider,
like www.dyndns.com, is free and allows the user to specify a human recognizable
string like “avalan01.dyndns.org”, that will be reliably redirected to the current IP
address of the user’s device. The port numbers that would normally be at the end
of the IP address can be specified at the end of the word string and will be ap-
pended to the IP address request sent to the remote device; for example, “avalan01.
dyndns.org:8081 = 22.214.171.124:8081.”
Because cellular modem data plans can provide blocked incoming ports and
non-fixed IP addresses, these limitations are difficult to overcome. Persistent efforts
and setup fees paid to the carrier may yield a workable solution, but there is
an easier way.
A network-to-network tunnel can be used to connect a remote device with a
corporate management network. If the corporate network presents a fixed IP address
to the Internet (most do), a carefully chosen tunneling appliance can be easy
to setup and less expensive than paying for a fixed IP address at the remote end.
The tunneling appliance consists of two small network appliance boxes with
matched encryption keys that are programmed with the basic information required
for the devices to find each other over the Internet.
One appliance is installed behind the cellular modem’s firewall and initiates a
connection by sending an outbound message to the other device that is installed
behind the firewall at management network. The outbound message from the
client creates a temporary port opening through the cellular firewalls. Once the
management-side appliance receives the message to initiate handshaking from its
remote partner, the connection is negotiated, authenticated and encrypted through
this port. The cellular firewall’s temporary port remains open to bi-directional network
traffic unless the IP address of the cellular firewall changes or the connection
is interrupted. Upon loss of connection, the remote appliance immediately begins
sending connection initiation messages to reestablish the connection.
A well-architected tunneling appliance forwards all broadcast and unicast
Ethernet traffic to ensure that devices operate transparently over the tunnel.
Tunnel-attached devices will appear to management side users to be directly on
their own network and cellular side users will appear to be directly on the management
side network. Advanced users may choose to employ additional port
forwarding at the management side to allow Internet accessibility for the tunnelattached
This management side port forwarding technique allows the tunnel-attached
devices to appear to Internet users to be at the fixed IP address: port of the management
side’s firewall. Some remote access applications may require that many
users have the simultaneous ability to request data from the tunnel-attached devices
and may benefit from buffered rebroadcasting techniques at the management
side to conserve cellular data usage. This seamless network to network connectivity
can ease the integration efforts required to enable rebroadcasting techniques.
AvaLAN Wireless Systems has recently introduced a product that implements
this type of tunneling appliance. The AW-HSNetAppliance is a small hardware
box used in pairs as described above, implementing a VPN tunnel that circumvents
the challenges posed by retrieving remote data through the cellular network.
In addition, the AW-HSNetAppliance goes further by providing fully FIPS 140-
2 Level 2 certified hardware-based encryption to protect the security of data passed
through the tunnel. Anyone in a government agency or sensitive private
industry such as health care, energy or financial with a need to
transfer sensitive but unclassified data is now required to encrypt this
data with a method that conforms to NIST Standard FIPS 140.2.
This article originally appeared in the February 2013 issue of Security Today.