Tuesday, August 09, 2005

Security challenges in .edu land

The Internet Storm Center from SANS has a handler diary that I read daily. For a reason. It is good stuff. Today's entry had a list of things you want to do to protect a corporate network from botnet invasion. These are basic principals, and have a lot going for them.

Unfortunately, in a .EDU environment, especially in higher ed where 'information shall be free' is rampant, these things aren't possible in a lot of cases. I'm going to take each recommendation and whine about why we can't do that. Poor us.

Centralize network egress
This we DO do. We have one pipe to the Internet, and a backup pipe in case it goes down. All of our border monitoring is done at this pipe. Such as it is.

Employ Egress filtering
We're an educational institution. God alone knows what all is going on among the faculty when they work with other faculty. We have an active Computer Science department, and that means we have weird stuff on our network all the time. By only permitting outbound traffic that we know we want, we'll block the stuff we don't know about but is critical to some class somewhere. Or something. No, we don't do Egress filtering. But we do ingress filtering! That's the same... right?

Centralize your logging
That would require having such devices. But I'm kidding. I'm not familiar what our telecom section does for these devices, but I know they do something. I've not had to look up VPN user info, so I don't know how they do that. But I have had them look up netflow data, which they've spent some time working on to make easier to use.

Deploy Intrusion Sensors
We'd like to. But that would be spying. And we can't have that. We keep trying to put up a honeynet somewhere, but we keep lacking the time.

Establish flexible routing control
That we do have, though getting Telecom to throw in strange routes like null-routes to addresses is like moving rock up hill. Much easier to block the bad IP at the border router. Happily, we've not yet had a botnet controller on our network, just drones.

DNS - Blackholes, Poisoning and Reporting
This is a new one to me. I know our primary DNS is provided by BIND, and is managed by hand by our trio of UNIX admins. We do have dDNS in some form, but I'm again not all that familiar with how it works since it is over there in UNIX land, and I don't speak that language officially. Logging DNS queries would also be spying. And we can't have that.

A lot of the problem stems from the fact that Educational networks work much closer to the ISP model than the Corporate model. I keep advocating for a firewall around our datacenter, but we run smack into performance fears whenever it comes up. Failing a firewall, getting router filters set up would do about 90% of what we'd need done on such a device.

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?