Handling User Grown Machines on a Large Network?

matth asks: "Recently with the outbreak of the MSBLASTER worm and the startup of the college semester here in the US we've been hit by a big problem here where I work. Many students are bringing in machines from home, often times infected. The infections are so bad that they bring the whole network to a crawl. Yes, you can install ACLs on edge routers and put a router between the dorms and the rest of your network, but it still brings the dorm to a crawl. You can make sure people install the patches, but what if someone re-installs Windows, or brings in another machine, and what about NEXT year? From the Slashdot community, how have sysadmins out there dealt with this? How can you manage each machine in a network such as a college, where people are bringing their own machines in from the outside? ACLs on routers... but what about for the segmented network?"

Comments

Simple...

[woodchip]

just ban users from your network.

Ban 'em

[larien]

If you can track down where the traffic is coming from (which I believe you can with MSBLASTER, at least to the extent of IP address and from there, MAC address), block their port until they fix their machine. Once they've (a) patched up and (b) removed MSBLASTER, let them back on. Having an A4 sheet detailing where to get the patch and removal tool (possibly mirrored locally) would be a good idea too.

You could just...

[gsperling]

...tell students at registration that Windows machines are not allowed on the network, and that they must install Linux. This will not only clean up your network problems, but it will also give the students a sense of doing the right thing for their computers. Along with their free condoms, give 'em free Linux CDs.

Re:You could just...

[Jon Abbott]

Case in point -- back in 2000, even though I had about four years Linux experience by then, I managed to bring down Internet access for an entire dorm (about 900 students) for a week.

It all started when I helped a friend install Linux on his new computer. Unfortunately, in addition to installing a DHCP client on his machine, I had accidentally flagged the DHCP server to install as well. What happened was that the DHCP server software on his new Linux box was challenging the Windows DHCP server that the dorm was using, and his machine won -- even though his DHCP server wasn't properly configured to hand out IP addresses to other clients. So, all of these other 900 students would turn on their computers, which would send out a DHCP request, and they would get a response from his computer instead of the real DHCP server, thus causing their computers to give up trying to connect to the network. Ironically enough, his computer connected to the internet fine, as it was the only one connecting to the real DHCP server (I guess that explains his super-fast connection during that week).

Anyway, we had no idea that any of this was happening until we headed back to his dorm room one day, and found three network services guys looking in bewilderment at the computer (they had never used anything but Windows, so they had no idea how to fix it). They claimed that it took them a week to isolate the problem to his machine. They explained what was happening, and it then hit me that the DHCP server was also running on his machine, so I logged in, apt-get removed it, and the problem was immediately fixed. Not in their eyes though, as they made us talk to the head guy at network services... He gave us fair warning that if we did that again, our access to the network would be revoked (and rightly so!).

The obvious moral of the story is, whereas most OSes give you just enough rope to tie a knot, Linux gives you enough rope to hang about 900 people. :^)

one way.

[grub]

Ensure that home machines (ones that you haven't configured) get IPs in a VLAN group which you've bandwidth throttled on the routers/switches along the say so the rest of the VLANs don't get choked by home-grown disasters.

Machines you have control over can get IPs in another VLAN which isn't throttled, or at least not as much as your "uncontrollable" VLAN. At the router where the VLANs can meet have strong ACLs and traffic flow control.

Just because you give them access with their own machines doesn't mean you have to give them unrestrained access.

managed switches

[Feyr]

assuming your network is switched, and your switch are "manageables" (ie you can log in them remotely)

you could have an IDS (or similar) with a rule looking for specific attacks (ie blaster). when you detect such an attack, fire off a script that shuts down the user's port on the switch. they'll bitch and moan that they can't access the net but you'll know who they are now and charge them a cleanup fee (make sure to include it in the terms of use)

another solution is to require anyone bringing a computer from home to have it inspected by your techs, block access based on mac address and only give them access once they passed the test. it does require more ressources tho, and ideally you'd still need the first option (in case where someone reinstall windows)

Deny them DNS services

[eaglesnax]

I think this was one of the approaches Stanford was going to take. No DNS for your machine until you get it checked out by their IT department.

Chris

Re:forcefully

[bob670]

Then who supports them when the latest Windows update hoses thier machine? It happens less than it used to, but I have one client who lets auto updates run, and one patch in paticular (810577) has brought network browsing to a crawl. We have done literally hundreds of test and narrowed it down to this patch, but neith the knowledge base, user community nor a direct (and expensive call) to MS support can fix his issue. Now he has users screaming about slow network browses to files and folders, time outs hitting their home-brewed data base and his phone never stops ringing. Now mulitply that by the body of a college campus?

You'll need something more reliable than Windows if your plan is to mandate that sort of thing.

YES, THAT'S A GOOD IDEA

[YOU ARE SO FIRED!]

"Along with their free condoms, give 'em free Linux CDs."

"Here. You'll never use this first item if you choose to use the second item. Have fun, and welcome to college."

You are sooooo fired.

DHCP tricks

[TheSHAD0W]

You ought to be able to tweak your DHCP so you can block machines that are broadcasting this badly by telling them their default gateway is localhost.

start with the freshman handbook

[b17bmbr]

Chapter 2 Personal Computers

No personal computers will be allowed unless they are running Linux, FreeBSD, OS X, or another variety of *nix. If you are bringing a PC, please see the installtion CD in the back of the Freshman orientation handbook. For installation instructions, find the guy in your dorm with long hair, glasses, birkenstocks, and a penguin on his shirt. For payment, beer will usually do. Or, if you are under 21, and can't find someone to buy for you, perhaps a bag of Starbucks will suffice. However, if you are a female, just acknowleging him at least once during the semester, when you are with your friends will be plenty.

Post lists

[Maxwell'sSilverLART]

Assuming you can identify the port from which the infected traffic is coming, post a list of all infected rooms on the front door of the dorms, with an explanation that "these computers are causing your network to suck."

The problem will be fixed.

Re:responsibility

[gykh]

If you make them bear some financial responsibility for not checking their machines first this might help.

Are you sure about that? What are you going to fine for? Not having a secure enough computer? Everyone (i.e. /.) knows security holes appear every week, major ones every 4 months or so. Do you fine someone who just reinstalled windows and was just logging on to download patches and got hit? For getting a virus? How about we tax stupidity next?

Students go to university to learn and give back some knowledge, not to constantly maintain their tools.

Here is what we do

[Anonymous Coward]

In our residence halls, we have about 7500 people. What we have done is make a series of VLANs, centrally administered by VMPS. We have the regular VLAN for a building's users, a quarantine VLAN, and a blackhole VLAN. As we detect users that are infected, we move them to the quarantine VLAN where we have colocated a quarantine webserver via an 802.1q trunk. This server provides them with all the patches, av software and latest DATs. Once installed, the resident "signs" with their campus ID to verify that they have installed the various fixes, and they are moved back. If someone languishes in the quarantine VLAN for too long, we move them to the blackhole VLAN (which is essentially a defined VLAN that isn't trunked anywhere so VMPS can still legally place them there).

This segmentation has helped dramatically. At one point, we were blocking nearly 800,000 icmp echo requests outbound/sec across all interfaces. Now? around 1k/sec. And that's over the last week.

Now if I could just get past the residents who:
1. Don't fix themselves because it was too much to read.
2. Don't know how to use a web browser
3. Don't know what a scroll bar is (!!!)
4. Don't contact us for help, but instead go to the President and Provost's offices.

Hang in there, segmentation helps dramatically.

Re:Possible solution

[themassiah]

I was with you until this part: "drop their connection via MAC address and refuse to give them another DHCP lease". Here's a better idea. CALL THEM! If they're running Windows, send them a Messenger Service Message before you cut their connection, telling them to call IT or something. Don't just shut them off, it's bad for your department's image and it's a bad policy when dealing with people.