RE: virus handling

["Rainer Gerhards" <rgerhards () hq adiscon com>]

I agree with most in this post, but not with 3), the ISP actions.

This is not doable for an ISP, not from a ressource (manpower) point of
view and even hardly from a contractual basis. And, no, I am not with an
ISP.

Other than that, I really think the AV vendors should do this. Also, I
hardly can see a point in including the original bounced mail in any
bounce - the orginal headers should be enough. After all, if the senser
is really the sender, shouldn't he know what he sent? ;)

Rainer 

> -----Original Message-----
> From: Thomas Zehetbauer [mailto:thomasz () hostmaster org] 
> Sent: Wednesday, January 28, 2004 4:46 PM
> To: bugtraq () securityfocus com
> Subject: RFC: virus handling
>
> 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 () provider com) 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 () hostmaster org
>
> Experience is what you get when you expected something else.