Hi Rich,

On 08/31/2012 01:20 PM, Rich Graves wrote:
> So, the freshman horde arrives next Tuesday. Thus far, PacketFence has 
> survived contact with the early arrivals. I'm using all Cisco switches (3550, 
> 3650, and 6509) in port-security mode.
> 
> One thing for which I'm not adequately prepared is the person who brings a 
> switch or a wireless router in bridging (versus NAT) mode. If the bridge 
> chooses to participate in spanning tree, then BPDUGuard will shut them down; 
> but if they don't, then what I observe is rapid cycling among the various 
> MACs on the port.
> 
> I isolated a few by grepping the log:
> 
> egrep ' pfsetvlan.+ INFO: authorizing .+ at new location ' 
> ~pf/logs/packetfence.log|perl -pe 's/.+at new location //'|sort|uniq -c|sort 
> -rn|head -33
> 
> Then I put them in violation state. This doesn't stop the flapping, but 
> hopefully it gives them a chance to see what's going on and fix it. Is there 
> a better way to handle this?
> 

State (VLAN assigned) is driven by nodes, MAC addresses visible on
ports. We could add a feature so state (VLAN assigned) is on a
switch-port basis under certain circumstances (maintenance mode, under
attack, etc.).

However we are talking about a feature that touches critical code paths
and relevant UI components, not something done in half a day.

A feature request could be filed[1] with a basic use case and then
further discussed here.

> I don't think I want to set trap_limit because it would deny new connections 
> to any user of a switch where one user is misbehaving.
> 

trap_limit is a per switch per port thing. One user will *not* affect
other users on the [managed] switch. With trap_limit_action=shut,email
you'll be notified and no further damage until the user can be contacted
(or has contacted you).

Related to the above feature, an trap_limit_action=isolate (or
violation(#id), etc.) that would show the captive portal and prevent the
VLAN swapping problem would probably be best (instructions about no hub
policy and contact details, etc.) but we can't do that right now
unfortunately.

[1]: http://www.packetfence.org/bugs
-- 
Olivier Bilodeau
[email protected]  ::  +1.514.447.4918 *115  ::  www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to