Tips for Proper Out-of-Band Network Design

Out-of-band (OOB) networking provides a separate, independent pathway in and out of systems and networks. OOB doesn’t depend on production networks to access equipment, perform management and monitoring tasks, make repairs, or access data for legal or technical reasons.
But what’s the proper way to set up an OOB network? Do you know and understand how they differ from standard networks? If not, read on.

2 Key Principles

Good OOB networks result from careful, well-established design and setup considerations and practices. These may be summed up as two key principles:

1. Make sure the OOB network is completely isolated from production and other networks
2. Test and verify to make sure the OOB network is working (and working properly)

Network Isolation

Network isolation is what makes OOB “out of band.” It means that all OOB network interfaces must connect to a network that’s separate from production networks, including separate media and separate infrastructure (switches, routers, WAN links, and so forth).
It’s best to set IP addresses on OOB networks statically, so they need not depend on DHCP to keep working (and all address assignments should be well-established and well-documented as part of OOB network setup).
Isolation also pertains to access controls. Best practice dictates that OOB networks use access control lists (ACLs) or similar mechanisms (such as role-based access control) to lock down servers, networking components, VPN users, and other elements of the OOB network.
Moreover, it’s best to use a single, isolated switch or separate router and firewall interfaces for OOBM Ethernet links. Likewise, use a single uplink to a router when Ethernet connections pass through a switch. This not only helps ensure isolation, it also makes it easy to distinguish the OOB network from other networks.
One can leave default server accounts intact, but remote access to the server (and other such devices) should be disabled if part of an OOB network. The organization should then set up OOB management accounts with their own well-protected credentials (account, password, 2FA or MFA settings, and so forth). This information should be tightly restricted to authorized administrative and security groups. Best practice dictates that to support auditability and accountability, each authorized user should have unique credentials. In addition, storage and retrieval/access tools for security information must themselves be secured and protected.
Finally, if OOBM features require additional licenses, they should be installed on OOB servers and network components to make them available when and as authorized members of the administrative and security teams need them. This ensures that OOBM can function properly, even if production servers and networks are down or otherwise unavailable.

Test and Verify Proper Operation

Once setup is complete, it’s absolutely essential to test and verify that OOBM is working properly. Test results should confirm that no access between production and OOB networks and devices is allowed, except for specifically authorized devices (typically, these will be the client devices that admins or security staff use to access all networks).
Further tests should ensure that credentials (secure, proper ACLs or other access mechanisms) are in place and enforced, and that the storage and retrieval tools used to manage credentials, configuration data, and other sensitive information is protected from unauthorized access.
Ideally, security testing should include penetration testing that uses technical attacks and social engineering to attempt to compromise or obtain unauthorized access to OOBM systems and networks.

Managing OOBM Elements

OOB management relies on a variety of communications media, usually including serial and/or USB ports. Most OOBM consoles work through RS-232, RJ-11/14/25 and USB 3.0 connections. Some also use 4G LTE or 5G wireless cellular connections, to maintain connections when wired infrastructures become completely unavailable.
In fact, OOBM also works with RJ-45 Ethernet, but such use should be conducted with care and attention. Keeping OOB networks isolated means that RJ-45 Ethernet must use physically disjoint and separate network media and infrastructure. This means separate cables, different IP addresses, different switches (when possible; otherwise, use separate switch ports), and different firewalls and routers (again, when possible; otherwise use separate interfaces within those devices).

OOBM Console and Management

For OOBM, a centralized management console consolidates its network and IT infrastructure under a single application view (aka a “single pane of glass”). This is what provides OOB network users with visibility for and access to health and status information. Of course, it’s also what ultimately supports remote access to managed devices and networks for configuration, setup, troubleshooting, and repair.
The OOBM console works through dedicated management ports that help maintain the rigorous separation between production and OOB networks. For managed/remote devices, this typically means port 1 or 2 will be for remote management access. On the OOBM console, of course, all ports will have OOB access, and there will usually be many of them available, rather than just two.
Managing an OOB network requires extensive knowledge and documentation to match. Serial and other connection ports must be recorded, along with associated device names, locations, IP addresses, and ACLs properly configured for access and use. Servers and other devices should be handled in more or less the same way. Because power (or its lack) can be an issue in establishing and maintaining OOB network access, it’s also important to manage power supplies, power connections, and even backup power sources and connections, where applicable.
When OOB networks include datacenter and/or cloud components, keeping track of the same kinds of information—virtual ports, names, IP addresses, access info, and so forth—applies equally to virtual machines (VMs) and software-defined networking (SDN) infrastructure components that belong to an OOB network.
It’s extra work, to be sure, to set up OOB networking and management. But it’s work you won’t regret the next time you can’t reach your network through normal channels. Implement these best practices to ensure peace of mind. Download the full tech brief from ZPE Systems today!
[su_box title=”Sponsored Article” box_color=”#008aab” radius=”4″]

This article is sponsored by ZPE Systems. ZPE Systems brings more than 100 years of combined experience in data center and branch networking. Using their innovative Nodegrid platform—the industry’s first open infrastructure management solution—ZPE transforms the enterprise network into a business value creator. The world’s top companies trust Nodegrid for in-depth out-of-band capabilities, Secure Access Service Edge (SASE), and SD-Branch networking. For a more flexible and future-proof network infrastructure, get started with ZPE Systems today: zpesystems.com.

[/su_box]