[unisog] Cisco 2950 protected ports in residential halls

Craig Kleen ckleen at csulb.edu
Mon Nov 28 17:15:36 GMT 2005


Hey all,

Just wanted to put up some comments on this one too, as I just got through 
researching this in conjunction with our plan to use Private VLANs on our 
4500 and 6500 model switches.

Our goal was not really to use this in the Residence Halls, since I have 
them behind a TippingPoint and FWSM and they tend to be easier to 
"locate", but rather to find a more elegant solution to the rest of the 
campus in our "wireless" or "general use" VLAN(s) (classrooms, laptop 
stations, etc.).  This VLAN has a Network Access Control of a Cisco Clean 
Access box.  I can't use 802.1X yet, because we don't have a single 
database for authentication data still (love campus politics).  So, the 
web auth portal that CCA gives lets users pick their login database.  But, 
I have this worry that some user is going to bring in a laptop that is 
virulent and since all users are essentially on the same VLAN, that laptop 
could infect a lot of others really fast.  In the past, I've used tricks 
with Vernier and now CCA to give each client a /30 subnet, which 
essentially isolates the "good behaving" laptops at layer 3.  Works OK, 
but I'm running into some major performance problems with CCA doing this 
(seems to max out around 250 simultaneous users, and never did get Vernier 
that high).  So, some layer 2 isolation would be beneficial.

I setup a test lab, and managed to get PVLANs to work between our 6500 and 
4500 switches (CatOS on both, MSFC in 6500) by migrating to VTP version 3 
so that the PVLAN information propogated.  In PVLANs, if someone hasn't 
read up on these, there's 2 modes (that I care about).  First is the 
"promiscuous VLAN", where all ports set to that VLAN operate normally, 
passing broadcast information.  Second is the "isolated VLAN", where the 
switch will not forward a broadcast packet out any other port set this 
way, but it will send out these broadcasts to the promiscuous ports (and 
vice versa, a promiscuous port device will send broadcasts to all isolated 
ports).  You pair them up, and in my testing, it works quite nicely.  The 
router/MSFC is on the promisuous side, while all my clients connect to 
isolated ports.  But, 2950s don't do this.  Well, they do, but the concept 
is completely local to the switch with "protected".  On a 2950, you have 
to set all protected ports to the promicuous VLAN so they can communicate 
with the router upstream somewhere.  The side effect is that devices 
connected to these protected ports is that they will be able to 
communicate to devices on other 2950s because the other switches 
upstream/downstream don't know any better.  One workaround is to set 
different VLANs for every 2950 switch.  I have 95 of this model switch, 
which would have required another 95 MSFC/CCA interfaces too.

After some hints from our local Cisco SE, I found an alternative that I 
like better.  Mac access-lists are nice little tools.  But, you should be 
running IOS 12.1(21) or better (bugfix to make a literal "deny any any" at 
the end work right, had to open a TAC case to find this one out).  What I 
will use is an acl like:

mac access-list extended routeronly
 permit any host ffff.ffff.ffff
 permit any host 000b.45xx.xxxx
 deny   any any

And applying it to every interface that I have set to my general-use VLAN. 
 Mac access-lists only work on ingress to the port, so the source is 
allowed to be anyone.  The destination they talk to, however, I have 
control over.  I allow the all 1's so that the router can hear the ARP 
request, and I allow them to talk to the router (will eventually be CCA, 
and/or some other server, maybe I'll even put my laptop in the ACL to 
allow it to hit destination any).  With Alterpoint to manage ACLs, this is 
going to be easy.

Other settings mentioned by John such as dhcp snooping, bpdu guard, storm 
control, etc., should be considered as well, of course.  But, this trick 
is what's going to be our key.

If anyone has any questions, specificially about PVLANs, I'd be happy to 
help out too.

Regards,

Craig
--
Craig Kleen
Network Engineering Manager, Network Services
Information Technology Services
California State University, Long Beach
1250 Bellflower Blvd, Long Beach, CA 90840-0101
(562) 985-8706



"John C. Gale" <jcgale at uncg.edu> 
Sent by: unisog-bounces at lists.sans.org
11/22/2005 09:58 AM
Please respond to
UNIversity Security Operations Group <unisog at lists.sans.org>


To
UNIversity Security Operations Group <unisog at lists.sans.org>
cc

Subject
Re: [unisog] Cisco 2950 protected ports in residential halls






Royston

UNCG implemented this in new replacement switch fabric in several 
buildings during an upgrade earlier this year.  Overall, it was a large 
success.  As some will point out, it will prevent some legitimate 
computing use.  However, the main use of the residential network on our 
campus is Internet access.  Anything that impedes the use of email, 
instant messangers, and a web browser use is far worse to our users 
(from their point of view) than intra building connections.  The 
reduction of noise and general pollution is seen as a large positive. 
When the next big outbreak hits, I'm sure we'll enjoy the benefits even 
more.  It is harder to measure success in the lack of complaints 
admittedly, but our users seem to not notice the difference.

We enabled other security features (1 mac per port, dhcp snooping, bpdu 
guard, strom control, etc) at the same time and the only real fallout 
was we did not have the errdisable recovery set initially.  I would 
remind you to set that up or you will have to manually chase them down 
(if you are using any of these features).  Once enabled, even these 
features presented very few incidents while improving stability greatly.

Cheers.

John
_______________________________________________
unisog mailing list
unisog at lists.sans.org
http://www.dshield.org/mailman/listinfo/unisog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dshield.org/pipermail/unisog/attachments/20051128/a4e1875f/attachment.htm


More information about the unisog mailing list