sasser virus (was Re: [unisog] student fees for cleaning.)

Peter Van Epp vanepp at
Sat May 8 23:25:09 GMT 2004

On Sat, May 08, 2004 at 01:23:22PM -0400, Gary Flynn wrote:
> John Kristoff wrote:
> >This stuff is all great and many institutions are moving to an automated
> >scan on attachment/authentication system.  This will help a lot, but as
> >something like the XP firewall gets enabled by default it will be harder
> >to tell if a system is in fact compromised.
> >
> This is true but an agent based system on the client, whether a domain
> login or something else, can still detect problems. NIDS in general will
> go the way of the dodo as more and more things get encrypted and use
> HTTP. Everything will be host based or need a common SSL termination
> point. We'll be back to securing the hosts instead of trying to secure the
> perimeter. :)
	I'll comment on the last couple of posts in this thread all at once.
I agree the signature based NIDS is likely to become not useful (of course I
don't think it is particularly useful now either, argus does better :-)).
	As John alluded to what that space needs to move towards is trend based
detection. Encrypting the data, and running over port 80 doesn't necessarly
help if it becomes obvious that a machine is suddenly doing signifigant amounts
of traffic to somewhere new (or many somewhere news). While its possible (and
perhaps obvious because of where the traffic is going) that it is legit, much
of the undesirable stuff (such as MP3 and movie repositories) have a 
characteristic signature: abnormally large numbers of remote hosts, many in 
Cable or ADSL netblocks. The P2P stuff has much the same property (along with
viruses :-)) of lots of hosts contacted and many of them failing because there
is no machine there. With a record of everything that went in or out (but the
headers only, not the packet data which helps address the privacy issue that
John raised, but only somewhat, you still need to make sure that your managment
and community are OK with this) you can (and I do regularly) at least ask if 
the traffic observed meets the acceptable use policy. If the volume is very 
large and on the charged commodity Internet link (rather than CA*net4/I2 link 
which doesn't attract traffic charges) there may be a need to supply funding 
from the department to cover the unequal usage of a centrally funded resource. 
I don't know of a case yet, all those I know of have been breakins to transfer 
movies, mp3s, or warez and have been whacked as a compromise. I've never had
a complaint about such a query either, most of our machine owners are pleased 
that we have detected a compromise of their machine that they hadn't detected 
(they of course aren't pleased about the compromise, but they would rather 
know of it than not :-)) or are happy to state that the traffic is for a legit
purpose even though it looks unusual.
	As to scanning the entire net, should we have a serious problem I expect
that such scanning will get approved (whether the manpower is available to do 
it or deal with the results is another question however :-)). Management is 
religiously against it, they would just prefer not to if there is some other
choice available. So far the noise level has been kept to an acceptable level 
at a semi acceptable cost without resorting to network wide scans.
	I say semi acceptable cost because my boss firmly believes there is a
"commercial AI driven IDS device" out there that will do everything at much
less staff cost (and sometimes he has the vendor foils and the overhead 
projector that is their preferred hardware platform to prove it :-)), and I'm 
not looking for it hard enough. I expect I'm going to have another round in 
this battle sometime fairly soon as another commercial miracle gets installed 
beside argus and we see what it finds (although lately that wouldn't be much 
of anything, there isn't much exciting going on). The last several times we've 
tried this argus happily detected a compromise, and given the IPs, time and 
port numbers of the compromise the commercial stuff either couldn't see it 
(because detection depended on knowing how much traffic a host had done in the 
last 24 hours, versus what it did in the 24 hours before that), or detected it 
just fine along with 40 other false positives but with no indication which one 
you should pay attention to. Its possible someone will manage to suprise me, 
but they haven't yet :-). 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

More information about the unisog mailing list