The Road to Resilience webinar series kicked off with “Out-of-Band: More Than A Safety Net?” The discussion was hosted by Roy Chua, Principal at AvidThink, and featured Gary Marks, President of Opengear, and Todd Rychecky, VP Sales Americas.
The panel talked through several topics, covering the evolution of Out-of-Band management (OOB), considered OOB’s broader everyday use as the basis of a more resilient network, and finally discussed the value of implementing a coherent Network Resilience solution.
Here are some key ideas discussed in this webinar:
How Out-of-Band has Evolved.
After Roy had outlined some of the more public risks of a non-resilient network, Todd recalled the history of Out-of-Band management. He explained how it started out as simple terminal servers on point of service devices and grew to more complex console servers for admin access to serial ports. As networks grew, the drive for OOB shifted to network engineers who wanted out-of-band access to router switches and data centers. Cellular OOB adoption in the data center was another major shift. And now the movement of compute out to the network edge is driving out-of-band growth. It shouldn’t matter if it’s a mile away, a hundred miles away, or around the world. Networks need the same level of uptime, reliability, and resilience to respond to any node, including IOT devices and sensors, autonomous vehicles, or perhaps someday soon, remote surgery. Network resilience is vital.
Liberate the Management Plane
Roy then asked Gary Marks to explain the importance of the management plane. Gary described how, in the early days of telecom, there was a separation of the data plane from the control plane and the management plane. But as networking expanded, there was a shift to purpose-built appliances with vendor-controlled hardware and software which brought these planes together. Over the last few years, with the introduction of SDN there’s been an effort to separate the data plane and the control plane and to have the ability to put the control plane in the cloud. But there’s still the issue of the management plane being captive. You can’t manage the network when the network goes down.
The idea of separating, or liberating, the management plane is to have an accessible network that allows you to remediate issues when there’s an interruption in the production network.
Gary Marks summed it up. “If you’re using the network to manage the network, you’re not truly resilient. You need to separate the network management plane from the rest of your network. And to reach this level of network resilience, you need a complete platform that includes hardware and software to gain true liberation of the management plane from the production and data planes.”
Site Reliability and Network Resilience
Todd pointed out that, with more edge network points and remote data centers, truck rolls have become really expensive. These days, you might not even be able to fly somewhere to reach your remote locations. You really need to build resilience into the foundation at the very beginning, as opposed to trying to retrofit after problems occur.
Google have popularized the job role of Site Reliability Engineer (SRE), and Roy suggested that there is now potential for an equivalent role of Network Resilience Engineer as networks achieve a larger scale and more locations. Todd agreed, explaining that the SRE sits between the DevOps team and the network team, and is often the primary user of the out-of-band network. They are particularly interested in the introduction of more advanced features, such as the ability to run Docker containers and Python scripts.
Gary noted that Opengear has been following the evolution of Devops into Netops, and is reflecting that with the new NetOps Console Server and added capabilities to the Lighthouse software. The added benefit of network reliability engineering plays to this NetOps evolution.
The Road to Resilience
This was the first in the series of webinars which will feature a variety of panelists discussing the latest approaches to Network Resilience.
If you weren’t able to attend but would like to view the recording, be sure to check out the video here.
Watch the Webinar
Console servers with internal cellular modems give you a wireless broadband IP connection for high-speed access to your remote sites. And Opengear Failover to Cellular™ provides continued Internet connectivity for remote LANs and equipment over high-speed 4G LTE or 3G networks when the primary Internet link is unavailable. While cellular wireless gives you great flexibility and availability, you need to make sure that you address potential security weaknesses from the start.
Here’s a brief look at the vulnerabilities and practical steps you can take to mitigate your risks. For more detailed suggestions, download our Whitepaper, Keeping Your Cellular Modem Secure.
When your cellular IP address is publicly available, typing that IP address in a browser gives you password protected access to a remote cellular modem. While this remote access is convenient, it is also available to an attacker.
The best option is to avoid using a publicly available cellular modem IP. If you can, restrict inbound connections to a VPN client to secure remote access. Access to the IP is only available through an authenticated and encrypted network tunnel. And if the VPN is configured with strong keys and ciphers, it 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 has to be configured at each remote access location. If that’s not feasible, there are other steps you can take to decrease exposure.
You can keep your public cellular connection enabled only when you need it. Your Opengear device can automatically turn the cellular connection on when failover occurs and off when the issue is resolved. The cellular connection is completely inactive during normal operation. This keeps the interface off the Internet as much as possible to both avoid high data charges and lessen exposure of this potential target from malicious actors.
When your IP is public, the username and password is the only thing protecting it from malicious actors. Make sure you configure an admin group account and require strong passwords. Also enable brute force protection (fail2ban) for the cellular IP which limits the number of authentication attempts a user can make before a temporary ban is put in place.
Lock down the firewall. Start with more restrictions than you think you’ll need. You should disable ping responses to thwart ping sweeps of public address space by attackers seeking targets. Disable unencrypted or insecure services and limit listening ports.
Consider running services on alternate ports to provide some degree of security by obscurity against attacks specifically targeting ports 22 and 443. And whenever possible, restrict access to trusted source networks only. If you have a known range of addresses, block all connections originating from other networks.
Finally, keep an eye on your data usage. Runaway data usage may indicate, among other things, a malicious worm script, so you need to monitor data usage in as many ways possible.
Feel secure in using your cellular modem by taking a few key steps, including exposing your cellular IP only when you need to, creating an admin group and having users with strong passwords, locking down the firewall, and using a VPN to restrict access. Check out our Keeping Your Cellular Modem Secure Whitepaper for specific steps you can take to ensure a secure and reliable network.