BugTraq
RFC: virus handling Jan 28 2004 03:45PM
Thomas Zehetbauer (thomasz hostmaster org) (13 replies)
Looking at the current outbreak of the Mydoom.A worm I would like to
share and discuss some thoughts:

1.) Virus Detected Notifications
After filtering out the messages generated by the worm itself there
remain a lot of messages generated by automated e-mail scanning
solutions.

1.1.) Configuration
Unless the virus scanner provides special handling for worms and virii
which knowingly use a faked sender address it should not send out
notification messages unless the administrator has been warned that
these notification messages may not reach the intended recipient and has
still enabled this feature.

1.2.) Format
These messages cannot be easily filtered because they come in many
different formats and do often not contain any useful information at
all.

1.2.1.) Standardization
To allow filtering of these messages they should always carry the text
'possible virus found' in the subject optionally extended by the name of
the virus or the test conducted (eg. heuristics).

1.2.2.) Virus Information
The message should always include the name of the virus found or the
test conducted (eg. forbidden file type).

1.1.2.) Original Message
The notification should never include the original message sent as
otherwise it may send the worm/virus to a previously unaffected third
party or re-infect a system that has already been cleaned.

1.2.) Notification
Regarding wasted time and storage capacity the false notifications sent
out to innocent third parties by many systems are already causing more
damage than the actual worm or virus. Given the current situation of
many unaware or ignorant administrators everyone capable to do so should
tell these people to fix their badly configured e-mail scanners.

2.) Non Delivery Notifications
It seems that this worm is trying to avoid people getting treacherous
non delivery notifications by using obviously faked but otherwise
plausible e-mail addresses. This may cause double bounce messages or
even message loops at badly configured sites.

2.1.) Avoid
Virus filters should therefore be designed and implemented before
checking the legitimacy of the intended recipient. This would also avoid
helping the virus spread by bouncing it to a previously unaffected third
party.

3.) ISPs
It is worth to note that once again primarily individuals using a
commercial provider have been affected by this worm.

3.1.) Notification
As these people do mostly not run a SMTP server on their system it is
unfortunately almost impossible to contact them when only knowing their
IP address.

3.1.1.) Abuse Role Account
Providers should provide an adequately stuffed abuse role account to
allow the affected users beeing notified. To ease efficiency messages
sent there should include the IP address, the exact time and date of the
incident and the name of the virus on the subject line.

3.1.2.) e-mail Alias and Web-Interface
Additionally providers should provide e-mail aliases for the IP
addresses of their customers (eg. customer at 127.0.0.1 can be reached
via 127.0.0.1 (at) provider (dot) com [email concealed]) or a web interface with similiar
functionality. The latter should be provided when dynamically assigned
IP addresses are used for which an additional timestamp is required.

3.2.) Disconnect
Providers should grant their customers some grace period to clean their
infection and should thereafter be disconnected entirely or filtered
based on protocol (eg. outgoing SMTP) or content (eg. transparent
smarthost with virus scanner) until they testify that they have cleaned
their system.

Regards
Tom

--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
mail pgp-key-request (at) hostmaster (dot) org [email concealed]

Experience is what you get when you expected something else.

[ reply ]
Re: RFC: virus handling Jan 29 2004 08:39PM
Pavel Levshin (flicker mariinsky ru) (1 replies)
Re: RFC: virus handling Feb 03 2004 01:26AM
David F. Skoll (dfs roaringpenguin com)
Re: RFC: virus handling Jan 29 2004 12:18PM
Sascha Wilde (wilde agentur-sec de)
RFC: content-filter and AV notifications (Was: Re: RFC: virus handling) Jan 29 2004 12:00PM
Andrey G. Sergeev (AKA Andris) (andris aernet ru) (1 replies)
Re: RFC: content-filter and AV notifications (Was: Re: RFC: virus handling) Feb 03 2004 04:07PM
Peter J. Holzer (hjp wsr ac at)
Re: RFC: virus handling Jan 28 2004 11:11PM
Pavel Kankovsky (peak argo troja mff cuni cz)
Re: RFC: virus handling Jan 28 2004 10:00PM
John Fitzgibbon (fitz jfitz com) (1 replies)
Re: RFC: virus handling Feb 03 2004 05:09PM
Dave Clendenan (dave dave clendenan ca) (1 replies)
Re: RFC: virus handling Feb 03 2004 10:59PM
Volker Kuhlmann (list0570 paradise net nz)
Re: RFC: virus handling Jan 28 2004 09:26PM
Craig Morrison (craig fishpalace org) (1 replies)
Re: RFC: virus handling Feb 03 2004 11:11AM
James C. Slora Jr. (Jim Slora phra com)
Re: virus handling Jan 28 2004 08:33PM
Mike Healan (mike spywareinfo com)
Re: RFC: virus handling Jan 28 2004 08:06PM
Dave Aronson (spamtrap secfocus dja mailme org)
Re: RFC: virus handling Jan 28 2004 07:08PM
Daniele Orlandi (daniele orlandi com)
Re: RFC: virus handling Jan 28 2004 06:48PM
Piotr KUCHARSKI (chopin sgh waw pl)
Re: RFC: virus handling Jan 28 2004 06:24PM
Patrick Proniewski (patpro patpro net) (1 replies)
Re: RFC: virus handling Feb 03 2004 08:55PM
Matthew Dharm (mdharm one-eyed-alien net) (1 replies)
Re: RFC: virus handling Feb 04 2004 01:44PM
Ben Wheeler (b wheeler ulcc ac uk) (1 replies)
Re: RFC: virus handling Feb 05 2004 12:52PM
Shawn McMahon (smcmahon eiv com)
Re: RFC: virus handling Jan 28 2004 06:07PM
Jeremy Mates (jmates sial org) (1 replies)
Hysterical first technical alert from US-CERT Feb 03 2004 12:11PM
Larry Seltzer (larry larryseltzer com) (3 replies)
Re: Hysterical first technical alert from US-CERT Feb 05 2004 12:18PM
Andreas Marx (amarx gega-it de)
Re: Hysterical first technical alert from US-CERT Feb 04 2004 02:31PM
Valdis Kletnieks vt edu (2 replies)
Re: Hysterical first technical alert from US-CERT Feb 05 2004 08:33AM
Stephen Samuel (samuel bcgreen com) (1 replies)
Re: Hysterical first technical alert from US-CERT Feb 06 2004 10:07PM
Valdis Kletnieks vt edu (1 replies)
Re: Hysterical first technical alert from US-CERT Feb 08 2004 01:01PM
Shawn McMahon (smcmahon eiv com)
RE: Hysterical first technical alert from US-CERT Feb 04 2004 02:41PM
Larry Seltzer (larry larryseltzer com) (1 replies)
Re: Hysterical first technical alert from US-CERT Feb 04 2004 05:11PM
Valdis Kletnieks vt edu
Re: Hysterical first technical alert from US-CERT Feb 04 2004 12:27PM
Philip Rowlands (phr doc ic ac uk)
Re: RFC: virus handling Jan 28 2004 05:54PM
3APA3A (3APA3A SECURITY NNOV RU) (1 replies)
getting rid of outbreaks and spam (junk) [WAS: Re: RFC: virus handling] Feb 03 2004 09:11AM
Gadi Evron (ge linuxbox org) (4 replies)
Re: getting rid of outbreaks and spam (junk) Feb 04 2004 08:07PM
James Riden (j riden massey ac nz)
Re: getting rid of outbreaks and spam (junk) [WAS: Re: RFC: virus handling] Feb 04 2004 08:04PM
Georg Schwarz (geos epost de)
Re: getting rid of outbreaks and spam (junk) [WAS: Re: RFC: virus handling] Feb 04 2004 06:27AM
der Mouse (mouse Rodents Montreal QC CA)
Re: getting rid of outbreaks and spam (junk) [WAS: Re: RFC: virus handling] Feb 03 2004 11:07PM
James A. Thornton (jamest u-238 infinite1der org)


 

Privacy Statement
Copyright 2010, SecurityFocus