mailing list archives
Re: question on securing out-of-band management
From: Kevin <kkadow () gmail com>
Date: Tue, 7 Feb 2006 12:35:22 -0600
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?
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