We’ve have been getting a lot of calls from businesses looking to shift Out-of-Band Management (OOBM) capabilities from traditional network-based communication methods to wirelessly enabled devices. Given the proper focus on priorities, the move can make a lot of sense. Since the typical OOBM session utilizes a secondary network connection, and is rarely used, the network asset often sits idle. Cellular networks are only billed for data usage at a very economical rate. This slack-time represents a potential efficiency improvement, often in the form of a wireless Out-of-Band Management tool, but here’s where things get tricky.
Many of the devices that are being “shoe-horned” for wireless OOBM are wireless routers with some sort of cabling adaptation that that provides serial port access. The advantage to such an arrangement is that the devices are being used for back-up network access in addition to the “shoe-horned” OOBM. Albeit conceptually beneficial, the wireless backup may leave some things to be desired. If the backup plan is to run a network from a 4G wireless connection (essentially a mobile phone), there may be some frustrated users. From a backup perspective, the wireless router may (or may not) be a good option for customers, but from the standpoint of Out-of-Band management, it is not the proper device to bring to the party.
OOBM for the network is most often deployed when a piece of equipment requires access because it is not functioning properly. Take for example a firewall that loses configuration. In this example, an engineer would open a session to access the devices’, radio from a remote site, to the location of the “sick” firewall, and reconfigure the unit; pretty simple. The capability eliminates the need to send personnel to a remote site; it’s a convenience, time, and money saver.
The issue from a security standpoint comes in the form of user authentication. This session I am describing above is occurring at the Network Layer, I am describing the configuration of a firewall – security needs to be a serious consideration. Most wireless units that are being deployed today are capable of offering simple password protection or utilize port forwarding to create security rules. This type of security is simply not robust enough to support our example of reconfiguration of a firewall. It should be argued that the “back door” to the network should carry the same security credentials as the primary network path “front door”.
If you are a customer who deploys a solution for OOBM that relies on network-based authentication methods such as a RADIUS or TACACS+ server, you too should consider the implications. If the network engineer is radioing into the remote site to gain Out-of-Band access to a piece of “sick” hardware, then ostensibly the network is not functioning properly. If the network is not working, network-based security protocols will also be rendered useless. The concept looks good on product specification sheets, but should be logically thought out, as to the security implications. Another consideration is the remote gear is on another “remote” network, therefore another RADIUS server. You would need to have credentials on every remote network you are servicing. Not practical.
CDI has solved the Out-of-Band Management security argument for cellular access. The devices are designed for secure access to remote sites for serial console port access of switches, firewalls, and routers. CDI devices can authenticate an RSA token on-board the device, and create an AES 256 encrypted session; both authentications performed without the use of RADIUS or TACACS+ servers. This is a critical and unique security feature is only native to CDI devices. Additional features include multi-port, multi port power-cycling, and full management/auditing functionality.
Cellular Out-of-Band Management is a great story; it’s a use case that was perfectly scripted for wireless adoption; just keep in mind the security implications of the solution you seek to employ.