Re: question on securing out-of-band management

["golovast" <golovast () yandex ru>]

See inline

> MJR wrote:
> > 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
> > the network.
>
> 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.
>
> Kevin


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards