Cellular security best practices

Unlike traditional dial-up out-of-band, your Opengear device's internal cellular modem provides a wireless broadband IP connection for efficient, high-speed access to your remote sites.

The first key point is that the cellular IP address may be exposed to the public Internet so utmost care must be taken to secure it as you would any other public IP endpoint.

In addition, cellular data usage is metered by your carrier so we recommend specific measures to monitor  data usage to mitigate the risk of data overage charges.

Step 1: Is your cellular IP accessible?

A public IP address is the most convenient way to access your remote site, allowing you to SSH in directly from any remote location.  The trade-off is that this convenient remote access is also available to an attacker.

Secondly, cellular carriers typically meter both inbound and outbound network traffic as it traverses their network.  That means even when an access attempt is blocked by the Opengear device's firewall, the data used still counts against your quota.

For these reasons, many carriers employ "carrier grade NAT" and assign a private address to block inbound remote access.

To determine whether you have a public IP:

• Ensure System -> IP -> Network Interface -> Failover Interface is set to None, this is the default
• Configure System -> Dial -> Internal Cellular Modem -> Enable Dial-Out as per your carrier settings and Apply
• Click Status -> Statistics -> Interfaces and note the address of wwan0 (4G models) or dialout0 (3G models)

If this address begins with 192.168.x.x, 10.x.x.x or between 172.16.x.x and 172.31.x.x, it is not accessible from the public Internet.  If so, please refer to this article for how to enable inbound access, then skip to Step 6: Monitor data usage.

Otherwise, your cellular IP is likely accessible from the public Internet – so please continue to read this guide with care.

Step 2: Consider mandating VPN

A comprehensive way to secure remote access is to restrict inbound connections to VPN client only.  This means the precondition of remote access is establishing in an authenticated and encrypted network tunnel, that if configured with strong keys and ciphers will be virtually uncrackable.

The trade off is that that you lose the convenience and minimal configuration of direct SSH, and that a VPN client, or route via a shared VPN tunnel, must be configured at each remote access location.

Please refer to this article to evaluate the pros and cons of using VPN for your use cases.

Even more comprehensive is restricting VPN to an outbound tunnel only, e.g. to your central NOC, as you might do if you had a private IP address.

If you have mandated and configured VPN, ensure the System -> Services -> Service Access -> Dialout/Cellular column is entirely unchecked, then skip to Step 6: Monitor data usage.

Step 3: Lock down the firewall

If you are allowing direct inbound connections, the following steps will help restrict network access.

Disable ping responses, this may help thwart ping sweeps of public address space by attackers looking for larget systems:

• Click System -> Services -> Service Access
• In the Dialout/Cellular column, uncheck Respond to ICMP echoes
• Click Apply

Disable unencrypted/insecure services (this is the default) and limit listening ports:

• Click System -> Services -> Service Access
• In the Dialout/Cellular column, ensure at a maximum, only SSH command shell and HTTPS Web Management are checked
• Click Apply

Consider running services on alternate ports, to provide some degree of "security by obscurity" against attacks specifically targeting ports 22 and 443:

• Click System -> Services -> Service Settings
• Set HTTPS and SSH Port to non-standard ports of your choosing
• Click Apply

Note: This will also affect the ports used for access from internal networks – advanced users may instead use System -> Firewall -> Port/Protocol Forwarding to forward the non-standard port on the Dialout/Cellular Interface to the standard port at the internal Destination Address.

Finally, it is recommended that where possible you restrict access to trusted source networks only.  If you have a known range of addresses, you may block all connections originating from other networks.  Please refer to this article for configurations steps.

Step 4: Lock down authentication

Configure at least one admin group account, then disable the root account:

• Click Serial & Network -> Users & Groups
• Scroll down to Users -> root
• Click Disable

Ensure all of your users are using strong and regularly updated passwords, and that there are no "zombie accounts", e.g. ex-employees who have not had access revoked.  The most convenient way to enforce this is using a remote AAA service under:

• Serial & Network -> Authentication

For all other local users, consider mandating SSH public key authentication.  SSH keys of appropriate type and length (e.g. RSA 2048 bit or longer) are are not susceptible to brute force cracking like passwords are, however the private part of the key must be kept secure.

• Click Serial & Network -> Users & Groups -> Users -> Edit
• Add SSH Authorized Keys (the user's public key)
• Check Disable Password Authentication
• Click Apply

Enable Brute Force Protection (fail2ban) to limit the number of authentication attempts that can be made before a temporary ban is put in place:

• Click System -> Services -> Brute Force Protection
• Check Protection Enabled for all services listening on the cellular IP
• Click Apply

Step 5: Reduce the attack surface using failover

One of the most effective way to secure a public cellular connection is to disable it when it's not required.  Your Opengear device can do this automatically using failover:

• Click System -> IP -> Network Interface
• Scroll down to Failover
• Set Failover Interface to Internal Cellular Modem
• Enter a Primary and Secondary Probe Address
• Click Apply

Note: The trade-off on using failover is that it introduces a significant "moving part" into your network configuration.  Therefore it is critical that you take measures to ensure the cellular connection will become available when it's needed:

• Choose appropriate probe addresses that indicate that primary inbound access has become unavailable
• Test thoroughly by simulating failover scenarios, e.g. shutdown upstream interfaces, block pings to the probe addresses
• Perform or automate regular maintenance tests to ensure your cellular connection is operating as expected

If your cellular SIM supports SMS, as a backup consider using SMS commands to manually start and stop the cellular connection.

Refer to this article for details on available failover modes.

Step 6: Monitor data usage

As mentioned earlier, blocking inbound connections is not sufficient to avoid carrier data charges.  It is also possible that a misconfiguration on the Opengear device or a connected network hosts may cause runaway data usage – therefore is it critical to monitor data usage in as many ways possible.

Your cellular carrier may provide a portal or automated reports on data usage for your SIM or SIM estate.  SIMs are often identified by their unique International Mobile Subscriber Identity (IMSI) number, which is displayed under Status -> Statistics -> Cellular -> SIM IMSI/MSID.  When deploying an Opengear device, note the IMSI and IMEI in your inventory system for future reference.

The Opengear device itself can monitor data usage, based on the traffic it transmits and receives, and alert you when it hits a given threshold:

• Click Alerts & Logging -> Auto-Response -> New Auto-Response
• Set Name to e.g. Cellular data monitor
• Under Check Conditions click Cellular Data
• Set Cellular Modem to Internal Cellular Modem
• Enter a maximum Data Limit and rolling Time Period

We recommend setting these to small values relative to your your tariff quota and period, e.g. if your plan allows 500MB data cap per month, you may choose to alert if data exceeds 15MB in a day.  During initial configuration, set a very low threshold in order to test the alert.

• Click Save Auto-Response
• Under Trigger Actions click, configure and Save one or more of Send Email, Send SMS or Send SNMP Trap
• Click Return to Auto-Response List

Refer to this article for how to consider SMTP and SMS alert delivery, and this article for SNMP alert delivery.

Note: Advanced users can view data usage logged every 30 minutes from the command line by running:

devlog -l -i wwan0

Or for 3G models:

devlog -l -i dialout0