Peter Van Epp
vanepp at sfu.ca
Mon Feb 24 21:12:50 GMT 2003
It certainly can be a short-sighted approach, but I'll argue (with
appropriate modifications) it can be both an effective and cost-effective
approach (although not done quite that way :-)).
As a number of others have commented despite what I would like we don't
have the resources nor the final say on policy to do what we would like. We are
lucky enough to have management support for security however.
We generally do something very like what is being suggested, i.e.
insist that a compromised machine be rebuilt and properly patched before it
will be allowed back on the network after a compromise. In addition the machine
must pass a nessus scan and an email detailing what has been done to avoid a
compromise in future has to be submitted to the Director of the computing
center (mostly for documentation purposes, a pattern of such compromises from
the same machine might get acted upon, however a series of compromises of the
same machine hasn't occurred yet to find out :-)).
We have argus recording traffic coming in/out of the Internet connection
and can and do find compromised machines which then get the above treatment.
Because of the argus logs (and other logs around the place) we can often give
at least guidance on how the user likely got hit. We can also tell if they
got hit again (or are port scanning outwards, or using an excessive amount of
network bandwith with some idea of what it is being used for and thus whether
it should be inquired about in terms of the AUP :-)). We can (and do when
needed because of pain :-)) provide a report of who and how many got hit lately
and how to management. That in turn has gotten support from the academic
community for the blocking of some ports at the border. As an example we told
them that in a 20 day period 17 Windows machines (and one Unix machine via a
different flaw) got compromised via the netbios ports (which got them blocked
at the border after years of trying unsuccessfully to get that approved). This
in turn causes some work on the part of network operations staff to remove the
machines from the network (time which wasn't being spent fixing other network
problems and thus impacting the community which is well worth pointing out to
the community :-)) which is relatively speaking small. It causes much more work
for the owner and/or local departmental administrator where the machine was
because they had to stop work and reinstall and patch the machine. This costs
the University as a whole for the lost productivity and in the case where a
shared departmental administrator did the work, he or she wasn't available to
do things for other members of that department while that work got done (again
something useful to point out to the community).
So while we usually won't do a detailed analysis of a breakin, that
isn't (at least in our view) as irresponsible as it may seem and is certainly
much less expensive than doing a full analysis.
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
> Sounds like an amazingly short-sighted, almost Microsoftian solution.
> "Oh, your machine isn't working right? Format, reinstall Windows, and
> everything is all better again."
> "Oh, your student information server was hacked? Ah well, wipe,
> reinstall, apply the patch de jour and hope it doesn't happen again."
> Mike Stanley, MCSE
> mikestanley at utk.edu
> OIT Lab Services
More information about the unisog