[unisog] Network security police no hubs/switches/routers?

Robert Maxwell UMD OITSecurity rmaxwell at umd.edu
Mon May 23 21:39:11 GMT 2005


While all of these technical, security- and availability-related are quite valid and important, please remember that the network is designed for users to use (hence the nomenclature) -- if it doesn't serve their needs, then it is yseless to them. Universities tend to have either tremendously over- or under-utilized networks, depending on where they are in their financial and life-cycles. Telling someone that they cannot use a hub/switch/router to connect their new devices without offering useful alternatives is neither helpful nor conducive to security since you invite attempts at circumvention. In such an environment, there must be some functional alternative -- that's what makes such a policy effective in this case. 

Rob


-----Original Message-----
From: Matt McBride <Matt.McBride at utah.edu>
Date: Mon, 23 May 2005 12:29:26 
To:UNIversity Security Operations Group <unisog at lists.sans.org>
Subject: Re: [unisog] Network security police no hubs/switches/routers?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vijay S Sarvepalli VSSARVEP wrote:
> We have just spelled out some policies that no hubs/routers are to be 
> connected to the network.  There seems to be  a lot of
> resistance for this policy.  I know the technical reasons for not allowing 
> this, but anybody have a lay man explanation in their policy 
> about "Why hubs/routers are not allowed on the campus network?"
> 
> If you have one please do share.  If you have a strong network security 
> that limits what type of devices attach to the network, again 
> in non technical terms please do share this as well.

Most reasons for not allowing end-users to randomly plug network
equipment into a supported administrative system are purely technical in
nature. Of those mentioned already, one of the big reasons some may over
look is the potential for L2 spanning-tree loops. This threat will
undermine any stable network rendering it unavailable if the STP fails
to place a port in block state. And, at a minimum, the network will see
problems at least until the STP timers have expired. Granted Rapid STP
may decrease the time you experience problems but they still pose a
threat to the availability of a network. This is one reason why manually
placing your root bridge for each vlan is so important.

- -Matt

- --
+-----------------------------------------------+
Matt McBride / University of Utah
Network Engineer / CCNP CCDP CISSP
585 Komas Dr Ste 202, Salt Lake City, UT 84108
Contact: 801.585.1043 / Alt: 801.232.8007
Reply To: matt/dot/mcbride<at>utah/dot/edu
+-----------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkiEGJhacTAgux9URAgStAJ9ypPUSX0pJ6kZpsiFjY76hZRFJVwCeO4va
np0ClAu343g0aSPIPR4Ipss=
=0YIh
-----END PGP SIGNATURE-----
_______________________________________________
unisog mailing list
unisog at lists.sans.org
http://www.dshield.org/mailman/listinfo/unisog

Robert Maxwell, CISSP
Lead Incident Response Handler
OIT Security, University of Maryland
rmaxwell at umd dot edu


More information about the unisog mailing list