On banning MAC addresses

August 4, 2011

Via Hacker News I wound up reading Shenglong's Why ISPs Shouldn't Ban MAC Addresses. As it happens, I partially disagree; there are good reasons to ban MAC addresses under some circumstances. The short summary is that banning a MAC address is an ineffective way to keep a person off your network, but it is a decent way to keep a machine off your network. The question you always need to ask is where the problem is.

(There are plenty of ways for a person with a banned computers to get back on your network, ranging from simply having other devices to various levels of tricks that they can perform with their banned machine. If you want to throw someone off your network, the minimum steps are to revoke the registration of all of their other devices and block their ability to register new ones.)

Sometimes the problem is some violation of network usage policies (the typical things that people think lead to bans, like running inappropriate things like filesharing or visiting 'bad' websites). Then the problem is with the person and banning the machine is only a moderately effective way of making it stop; a determined user can still continue their activities in various ways.

(There's an argument for still doing it as a first step in dealing with this sort of problems; machine blocking may be a coarse net, but it will still catch a fair number of fish. And it's often easy and relatively low impact.)

However, sometimes the problem is actually something bad that the machine is doing, something that's most likely the result of either a compromised machine or a configuration mistake instead of deliberate, conscious user action. If the problem is with the machine you do want to quarantine the machine but you don't want to ban the person; it's a feature that they can still get on to your network through other devices, not a bug. If they're clever enough to use this to get the same machine back on the network, they're hopefully also wise enough to do this carefully.

(We've occasionally had to block machines by MAC address here for exactly this reason; the machine is clearly doing something bad, but there's no evidence that the person has become evil.)

Having said that, there are good and not so good ways to do machine blocks. As Shenglong's story shows, the problem with a plain block is that there's no indication to the person what the problem is; as far as they can tell, their machine is either malfunctioning or mysteriously banned. A better approach would be something like a registration portal, where their web browsing is redirected to a captive page that tells them that the machine's network access has been cut off because it appears to be infected. You get bonus points for having a bunch of (local) resource links for how to get disinfected and so on, and ideally something that tells them what you detected about their specific machine.

(And having written that I have to admit that we don't currently have such a setup, although when we block machines we do tell the user's Point of Contact, who will contact the user in some appropriate way.)

Sidebar: think twice before working around a block

If your machine ever gets blocked, I strongly suggest being very careful before working around the block and getting the machine back on the network. This isn't because it's against your local network usage policy (although if it is, that's another reason to think twice), it's because if your machine is behaving badly and the sysadmins can't keep it off the network without throwing you off the network entirely, sooner or later they will wind up doing so.

(And if this happens, getting back on the network will likely involve some very awkward conversations.)

Thus before deploying various workarounds to regain network access, you want to be as sure as possible that your machine is in fact not compromised and not misbehaving. Unfortunately, these days this really requires checking from some outside vantage point (as noted in a comment on Hacker News).

(This is also a good time to mention my zeroth law of compromised machines.)

Written on 04 August 2011.
« How I encode and decode the milter protocol (or, how to write a codec for a sane binary protocol)
Why sysadmins don't just notify users about compromised machines »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Aug 4 02:19:05 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.