mailing list archives
Re: question on securing out-of-band management
From: "golovast" <golovast () yandex ru>
Date: Tue, 7 Feb 2006 22:11:40 +0300 (MSK)
For the sake of tradition, I would recommend duct-taping the
dongles in place. ;)
Where I learned the trade, hot melt glue is the tradition (no joke).
On 2/3/06, golovast <golovast () yandex ru> wrote:
Thank's for all the replies. See inline.
Unfortunately it won't be on a completely separate switch.
For a variety of reasons, our management network is going to be used to
manage both the perimeter and the internal servers, so on the back end it
will be connected to the internal core switch. We'll probably run IOS with
firewall services there, so the users should be restricted from accessing
IMHO, this design is basically one bad IOS command away from compromise,
and is risky on multiple fronts:
1) Relying on router/switch security to isolate the management VLAN.
2) Connecting the OOB management VLAN to the internal core switch.
3) Using the same management IP network for perimeter and internal servers.
Do you trust Cisco VLANs and "IOS with firewall services" to this degree?
I certainly see the risks with this approach and my perfect world preference would be to have separate management
systems for the perimeter and internal networks.
I have two problems. First, is the cost of deploying two systems. Second, and probably more important, is the amount of
resources that we have to look at these systems. In a way it's a compromise. I'd rather be aware of the areas of
vulnerability and focus attention there, then spread the resources too thin across many areas.
Also, it won't be just the VLANs and firewall services. Possibly HIDS on the servers as well.
As far the example that you describe below (pretty bad...=])), I am hoping to avoid the issue by requiring everyone
(including server admins) to go through the VPN in order to manage the management servers. I can have pretty granular
access control at the VPN box.
Still, you make a good point and it's something I've thought about extensively. Maybe I am missing some alternatives?
What are my other options outside of having separate management systems for inside and perimeter?
A real-world example, the perils of mixing OOB data into the production network:
At my employer, the server admin team petitioned the network team to deploy a
new "tape backup" subnet which was supposed to be it's own isolated unrouted
subnet, connecting the tape backup server to Windows and Unix servers.
All was well, backups happened quickly.
Then more servers were added, and the isolated segment became an
unrouted VLAN across multiple switch fabrics, and things were still okay.
Then the server admins decided they needed to manage the backup server
(which "couldn't" be multihomed) from their desk, so the "unrouted" subnet
became a routed segment, and things started to get messy, backups took
longer and longer to complete.
Fast forward a couple of years. One day I'm running windump on a user
workstation (not a server, not backed up to tape), and notice WINS packets
from the desktop to an IP address on the "isolated" backup segment.
I think to myself "WTF?!?".
As it turns out, the primary domain controller automagically decided to
return, as it's primary IP, the address for the PDC's interface on the
backup segment. And to this day we have not successfully be able to
re-isolate the "isolated" backup segment.
firewall-wizards mailing list
firewall-wizards () honor icsalabs com