Ask Slashdot: Securing Systems you don't Manage

A verbose member of Clan Anonymous Coward asks this difficult question: "My university has a problem. We have lots of autonomous departments managing their own computing infrastructure, lots of autonomous users managing their own computers and a very large network population (in excess of 20k people). Of the systems which are not managed by "professionals" about 10% are linux. How should the university tackle the problem of people keeping their boxes up-to-date whenever it has little control on the box owners? Using tools to identify problems (e.g. nmap, satan, etc) is the easy part. How do we then get hundreds of different computer owners to update their systems when they didn't know what they were doing in the first place? How to we do this in a climate where the resources are not available to employ herds of new computer support staff to assist these people?"

Our anonymous submittor continues...
"Many of us recognise linux as being a good thing (tm) and indeed many of us use linux to provide high availability and robust services. Unfortunately, many of the "non-professionals" who install linux tend not to know what they are doing. They get their system installed and bring it up on the network (easy now compared to what it used to be!) and then leave the system to look after itself. All fine so far, except that most of these boxes are running the plethora of services that come enabled by default on popular linux distributions (e.g. imap, www, etc.).

The problem comes in like this: there is a high rate of publication of exploits for linux systems and, unless users are very careful to keep up-to-date with patches, they are compromising the entire computing infrastructure for everyone."

This sounds like a Network Policy Issue. Most networks have rules that state the acceptable uses for the resource and the conditions that must be satisfied for it's continued use. It seems something like this would be appropriate here. The larger problem however, is its enforcement. What do you all think?

Talk to TAMU about Drawbridge and Tiger

Talk to Texas A&M University about their tools for security. Especially their firewall Drawbridge, and Tiger security auditing scripts. They also have monitering software to moniter their internal network for cracking signatures.

Another sorce is to look at CERT [cert.org]. They have lots of links to documents and articles on security. One of their documents pointed me to the TAMA stuff.

Drawbridge is designed for blocking off site access on a machine/port by machine/port basis. Machines that pass the tiger scripts are enabled for more external access than ones that don't. As a default only SMTP is enabled from off site to a machine. Higher levels of external access can be obtained when a machine meats tighter security levels.

One of the nice things about Drawbridge is it can be run on a PC, and securly remotly updated. It also uses lookup tables so it's fast. It is a memory hog, but then that's the price for speed. I belive it will only work for Class B and C networks.

Email me at [e-mail], and I'll gather a bunch of related links from my bookmarks at home. There are some good PDFs on their experiences, and the tools they made to implement security.

I've been dealing with security alot lately as I've recently setup a firewall for my home system. I personally don't use Drawbridge as my network is small and Linux IPCHAINS is more suited to my system. I do use some of the Tiger scripts for auditing. I also use Tripwire (available from CERT).

set some policy

It sounds like there is going to have to be a policy set. "all systems will comply to the security guidelines outlined at (some URL) or they will not be allowed on the network."

Once you get the guidelines set, implement some detection measures (the easy part as you put it) and some automated notification. after some number of warnings (say 3 in as many weeks) just filter all their packets at the router (based on their MAC address).

Yes, it wouldn't take much to change your MAC address, but then they've intentionally circumvented policy & that, I'm sure, is covered in some other policy, with it's own punishment.

An authorisation ticket?!

I am sitting in the same admin seat and after having read some of the comments here I got this idea:

With a virtually endless number of systems on the network one cannot ever possibly check each and everyone computer for security problems. It is way too time consuming even for a large IT-staff group and it will probably not be appreciated by people who feel you are sniffing around in their computers.

Firewalls and blocked routers are a nice idea, but Professor A. has a friend who must be able to telnet into box 123 and Professor B wants to ... and and and - you will end up being forced to punch a million holes in the firewall, rendering it useless.

An own distribution is probably a too complex thing to go for. As soon as a distributor will update, some users will do so too. Your own distribution becomes old and you soon run into new problems.

So my idea (just an idea) is to create some kind of "ticket" which allows the users to connect their computer to your network. Assume that you write a program or a set of scripts which run a number of security checks on a computer, presenting the output in a code number, call it the ticket. This ticket is submitted to a server which grants the sending machine access to network - if the ticket shows that all tests were passed.

The idea is to limit your work to writing a - say monthly - version of the security check script. Let the program produce a ticket which is valid for a reasonable time span and place it as a complete, runable package on a public server. This way you will MAKE THE USERS CHECK THEIR OWN COMPUTERS. No valid ticket, no IP-number.

As I said it is a very raw idea, but I think it could work.