[unisog] New virus - not caught by central servers (fwd)

Keith Schoenefeld schoenk at utulsa.edu
Tue Jul 27 21:20:31 GMT 2004


I'd have to disagree with the premise that email delays are not a big 
deal.  At our university the system operations folks have busted their 
butts to give us an effective, fast, and stable email system that is up 
for months at a time without interruption, or with interruptions of less 
than 5 minutes late some rare night.  The last time we had a lengthy 
downtime it was only for a couple of hours one weekend evening when 
additional disks were being added, and the RAID configuration was being 
modified.  We have way too many professors here that consider email 
service to be much more important than phone service.  The result is 
that I consider email a "mission critical" service.  I'm amazed at how 
unimportant other university systems administrators seem to think email is.

-- KS

Frank Bulk wrote:
> Do I detect some slight bias to the *nix platforms? ;)
>  
> Seriously, using attachment filtering is very effective, but in a school 
> environment it's a little more difficult to filter compressed 
> attachments.  It's a best-practices behavior to compress large 
> attachments and multiple files, and pkzip seems to be the most popular 
> format.  If the email system we used (GroupWise) supported a mechanism 
> where users could pick it up the messages themselves, that would be more 
> reasonable, but I think most end-users would end up infecting themselves 
> because they wouldn't use caution.
>  
> Although virus definitions are a reactive measure for outbreaks, they 
> are effective the longer-running ones.  A several-hour delay in email 
> processing, by my measures, is not the worst thing in the world.  It 
> happens at least monthly that one item in our email flow breaks down for 
> several hours.  I'm usually the first to notice, and it's usually been 
> 60 to 180 minutes.  So delaying email processing, perhaps for just those 
> with attachments, doesn't sound so bad in the grand scheme of things.
>  
> Regards,
>  
> Frank
> 
>  >>> stevev at darkwing.uoregon.edu Tuesday, July 27, 2004 12:05:05 PM >>>
> Frank Bulk writes:
>  > Has anyone considered a policy such that if a virus alert is medium or
>  > higher, to shut down email flow (or, at least let it queue up at the
>  > edge) until the virus definitions for the campus' email antivirus
>  > solution has been updated?
> 
> Everyone suffers enough for the Windows users who create the worm
> problem, by having to process worm emails, backscatter from failed worm
> deliveries and badly implemented antivirus products that send
> notifications back to forged senders, and the other ever-increasing
> wastes of Internet resources caused by Windows security stupidity.
> 
> And you're suggesting that people adopt a policy that users of
> everything other than Windows should give up _our_ email connectivity
> because the Windows lusers are suffering through another worm infection?
> No thank you.
> 
> Rather than use what I think is the highly misguided approach of using
> reactive virus filtering, we aggressively filter all the various Windows
> attachment types that propagate worms, which provides a substantial
> level of proactive defense. Some of the worst offenders that have
> virtually no legitimate purposes (.scr, .pif) get stripped entirely from
> incoming messages, and many other types that are legitimately used but
> capable of progagating worms (.zips being the most common example) are
> delivered with modified attachment names so Outlook can't
> oh-so-helpfully open them automatically, but it's easy enough for users
> to recover the data if it's not a worm payload.
> 
> We're using the Procmail Email Sanitizer
> (http://www.impsec.org/email-tools/procmail-security.html) for this on
> our UNIX hosts; it's highly configurable and easily customizable.
> However, unlike a virus-scanner, the interval between configuration
> tweaks is often months instead of days since it eliminates whole classes
> of potent! ial worm threats rather than just the ones whose signatures are
> already identified.
> _______________________________________________
> unisog mailing list
> _unisog at lists.sans.org <mailto:unisog at lists.sans.org>_
> _http://www.dshield.org/mailman/listinfo/unisog_
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog


-- 
Keith Schoenefeld
Manager of College Computer Services
College of Engineering and Natural Sciences
The University of Tulsa



More information about the unisog mailing list