Management Networks can be seen as a continuation of Network Segmentation, as they can yield significant benefits when implemented. Effectively, you move the management of the devices away from their operations to maintain a level of control when things get a little dicey and put an extra layer of defence into the mix.
In a typical scenario, you plug your device into the network and assign it an IP address. You then use this IP address (and of course, host name if you use DNS) to access it for tasks such as configuration, updates, logging, alerting, routing, and any of several items associated with managing your network. Servers, routers, switches, firewalls, and any other devices usually end up this way. This means one device with one address for everything.
The problems start when things get a little “wonky” (a term normally reserved for trolley wheels at the local supermarket). If the network device won’t transmit application and user data, odds are it probably isn’t doing it for management either. Facebook has taken a dive, email isn’t going through, and you’re probably not getting alerts or logs.
You only find out when your phone rings and you get everyone’s favourite, “the network is down” or “the internet’s not working” or any combination things that are down, broken, busted and a variety of words not fit for print. For bonus points, if your IP phones are out of service, that’s when the same people come lean on your cubicle wall and let you know they’re not happy (because the IT Department never see them otherwise, right?)
Using a management network, you can access the devices when you can’t through the primary network connection. Sometimes called “Out-Of-Band” (OOB) management or “Lights Out Management (LOM)”, it might be the difference between quickly being notified about an issue and troubleshooting it versus the middle-of-the-night call-outs, drives to co-lo data centres, or the trek to the in-house data centre.
So, if you can access the devices when they’re supposedly misbehaving (or even off altogether), is that the only benefit? Well, imagine also that all the sensitive administrator user names and passwords don’t traverse the primary “In Band” network (especially if you’re using RADIUS or TACACS and those admin accounts are also domain or enterprise administrators of your network). You can also remove some traffic from the In-Band network as well to make your throughput just that little bit more efficient.
Now that you get the idea what a management network is and what it can do, do you need one? Well, that depends. If you have the equipment capable of supporting a management network and the infrastructure capacity, then why not? This, of course, is if you want to go full Out-Of-Band or Lights-Out, start first with an inventory assessment.
Have a look at all your network-connected equipment. Do they have “Management” ports or at least ports that can be dedicated for management? Many do, and this separate port usually has a degree of isolation from the rest of the device; the ones that can be designated by software for management may be more closely tied into the operational ports than you’d like (meaning if the device tanks, so too may the “management” port.)
Let’s say you have all or most of your equipment with available management ports, cables are cheap, so plug it all together, right? What will you plug these management ports into? Not the production ports of the nearest switches, well, you can, but I’ll get to that next. Ideally, you want to have a dedicated management switch that handles the management connections and allows you to connect to it and access all these devices. The more you can isolate the management network, the better, so staying “Out” of band.
If you plug the management port into a production switch but on a separate VLAN from network traffic, this is more of an “In Band Management” configuration. Sure, it isolates the management and can give an extra layer of defence, but you’re still at the mercy of the interconnected devices and if multiple devices go down at once, you could be making that trek to go see what’s up regardless. Without a management port, you could just put the management IP address of the device into a separate VLAN. This way it still qualifies as a management network.
Make sure you get your security engineers and network engineers involved if you plan to use a management network and figure out what works best for you and how you’ll go about it. If you have the budget and infrastructure, a full, separate management network is the way to go. If you’re like many and on a shoestring budget, then you may have to create a virtual channel through your existing networks with dedicated management IP addresses and a management VLAN.
If you are going to use In-Band management, be sure to harden these devices. Many management cards in servers and network devices have a lot of services turned on by default, assuming they’ll be isolated on management networks.
As with anything, get the right people involved from the very beginning. There can be nuances to using management ports, so if need be, involve the vendors or at least resources very knowledgeable in the vendor products. After that, it becomes a connect-and-configure exercise provided you have the infrastructure and budget. Be sure to harden this network and all the devices because this network is handling the keys to the kingdom. Administrator access to the core of the connected devices and traffic containing the administrator credentials can make a management network an attractive target. If, at any point, the management traffic traverses the production network, be sure to safeguard this connectivity.
If you choose to go with in-band management, be sure this network isn’t easily accessible from other networks – so think about inter-VLAN routing. Try to picture an end-to-end route from the device to your management point. For what it’s worth, perhaps see if you can send all management traffic such as logs and alerts over this channel as well.
So now that you have decided you can use a management network, either In-Band or Out-Of-Band, and securely configured it to be isolated (physically or virtually on its own VLAN) along with logs and alerts, be sure to test it thoroughly to make sure you can’t find a backdoor in. Management networks should be part of regular security testing. If I know one exists, I generally spend more time trying to compromise it because I know what it means if I can take control of an entire infrastructure.
It can be attractive to keep the ability to manage a device from the regular production network, maybe even just leaving the Power Shell protocol “just in case” your management network falls over. Management networks can fail, yes, especially if you’re using single points of failure (such as a single management switch in a rack) but are probably less likely to fail or encounter issues than your production network. I can’t advise you yes or no, but if you elect to keep a backup access point, such as the Power Shell protocol to the network devices, be sure it is secure. That means no TELNET or HTTP-only.
I’ve also seen management networks that use a “jump box” so you connect to it first and then it is the only device allowed to connect to the devices for management. Just be sure that the connections to and from this box as well as the box itself are secure.
Network services are like spring cleaning, if you haven’t used it or don’t trust it, get rid of it!
We shouldn’t have to have this conversation, but we will. Secure your access to management networks with appropriate passphrases and if you can, Multi-Factor Authentication. I have encountered easily-compromised management networks because the administrators figured that because only they were using it, they could just keep it open and easy. Simply plugging into the management network with a laptop, a basic scan and trying a few basic passwords was all it took to gain control. Don’t drop your guard just because you’ve isolated your precious management network from the masses.
When network devices are updated, the firmware and software is also updated. However, be wary of add-in management cards like you find in servers and some other network appliances – keep these up to date in line with your regular patching regimes.
We’re always happy to help, just let us know how we can assist.