Blocking a MAC address at the router

AFAIK, MAC access-lists 700-799 and 1100-1199 on routers work only on BVI interfaces (with "bridge irb" configured). How about using 802.1x authentication and forcing the switchport into "force-unauthorised" state or changing password on RADIUS and then requesting client to reauthenticate? You have to know the switchport, though. Another way of doing that is to change 802.1x reauthentication timeout to be really short (5 mins?) and then You don't have to force client to reauthenticate. All You need then is to change password on RADIUS and in 5 mins max the client will be off-air. HTH Cheers Alex

Small correction to my previous post: MAC access-lists 700-799 and 1100-1199 on routers work only on bridge-groups, not BVI interfaces (with "bridge irb" configured). One has to have BVI interfaces to route IP, though. regards Alex

Some switches are able to get MAC security information via RADIUS. This is not exactly the same mechanism as the 802.1x that the other poster suggested -- this generally predates 802.1x.

At the IP level, you could use 'shun' on the PIX you have mentioned in other postings. But as you point out, that doesn't work well if the IP address changes.

When the IP address changes, probably the PCs are DHCP'ing for an IP address. Your DHCP server could be managing a block table, since the DHCP server is given the MAC address.

If your routers have firewall support, you might be able to work something at the MAC level using NBAR.

I dealing with a campus of 10-20,000 users so anything that must be "implemented" is year-long planning and discussion. We have over 100 VLANs, 10-12 major routers, and 225 switches.

Our switches range across 5 years of purchasing (as will always be true in large enterprises) so not all switches have the necessary capabilities to support certain technological solutions. 802.1x is under consideration, but I believe some of our switches aren't capable for the solution we are considering.

DiGiTAL_ViNYL (no email)

Actually these PCs attack internal networks as well as the Internet, so we need protection at internal routing points as well.

Users moving laptops around between buildings will get differnet addresss. Because of our size and layout there are at least 12 DHCP servers. So blocking them on all would be administratively painful. Also the DHCP are not within our full control, so that puts work onto a different group. We're looking to keep the solution within the network group and desktop support.

No. The only thing I've come up with, which looks like a reaosnable soltuion is mac-address-table static drops.

"To block all traffic to or from the configured MAC address in the specified VLAN. "

Router(config)# mac-address-table static mac_address vlan vlan_ID drop

There is a subset of equal rights VLANs that we could predict a laptop would move to. We could set DROPs on a few vlans and cover most of the networks a MAC might reappear. We could could install these drops on

5 routers and cover most of our main location. I also like that these are not INTERFACE context commands. So when you do a SHOW CONF all the blocks would be displayed together. That makes it easy to audit. And it only involves our routers and relies on no other technologies or devices.

DiGiTAL_ViNYL (no email)

My 2 cents about this solution:

1) it is currently supported on 2600, 3600, 3700 and 6000 series only: about support for new 2800/3800 series. 3600s are pretty much EOL. 2) Clever users could change laptop MAC address as well. If You are not using dynamic VLANs (based on source MAC address) then no amount of policy could prevent them from doing that. HTH Cheers Alex

Thanks, I didn't even think about the fact that the feature wouldn't be supported on other hardwares. 4 of the 5 target routers are 6509s. The fifth is a 5509--have to see about that. Every problem machine on the internal network has been infected, and not a real hacker doing port/ip scanning. Most users don't even know what a MAC is, nevermind that changing it will get around this block.

We're looking to turn our honeypot report around more regularly and block all infected PCs from generating so much useless traffic. If they did change their MAC they would show up in the honeypot again and could be blocked repeatedly.

Thanks.

DiGiTAL_ViNYL (no email)

?

B.R. Igor

I guess I need to stress SIMPLEST. NAC is very interesting but at our size this is a $200k-300k implementation at minimum wiith a year+ long implementation planning period. We are already talking with Cisco about these initiatives. for a 2006-2008 implementation.

DiGiTAL_ViNYL (no email)

another 2 cents :

given that :

- blocking in the switches is not an option

- manipulating MAC ACLs in the router is not practicable

- you need a simple, platform independent solution

then AFAICS the only place where the router really uses the MAC address is in the ARP table. Now you cannot easily block a specific MAC address from arriving there, but you could insert a static entry for a known IP address pointing to a fake MAC address. This should spoil life for that IP address and is only a light touch of the router config.

It also may lead to some flooding in case the router tries to send a packet to the specific IP address while the switches do not know the fake MAC address, but that could perhaps be eased by always using the same fake MAC and making a static entry (once) in selected switches sending packets for it down a black hole.

luck,

Frans

Router uses ARP table to send outgoing packets to laptops. How about incoming (laptop to router)? Some forms of attacks/viruses don't need a return channel, these nasties are spitting packets as fast as they could and don't care if the target is sending anything back. These attacks cannot be blocked by static ARP entries. As original poster already mentioned that users are not the brightest people in the world, I won't elaborate on how easy is to change the IP address... HTH Cheers Alex