Message-ID: <631201033.20040129150003@aernet.ru>
Date: Thu, 29 Jan 2004 15:00:03 +0300
From: "Andrey G. Sergeev (AKA Andris)" <andris@...net.ru>
To: Thomas Zehetbauer <bugtraq@...urityfocus.com>
Subject: RFC: content-filter and AV notifications (Was: Re: RFC: virus handling)


Hello!


Wed Jan 28 2004 18:45:39 Thomas Zehetbauer <thomasz@...tmaster.org> wrote:

TZ> Looking at the current outbreak of the Mydoom.A worm I would like
TZ> to share and discuss some thoughts:

[...]

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

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

Very good.

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

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

1.2.1.) Standardization
To allow filtering of these messages they MUST always contain the
header "Auto-Submitted: auto-generated (antivirus)" or (if any content
filtering engine is in place) "Auto-Submitted: auto-generated
(content-filter)" or (the last but not the best possible variant)
"Auto-Submitted: auto-generated (failure)".

The "Subject:" header SHOULD follow the generally adopted rules for
the messages originated from various software running at the mail
gateways (widely known as "Mail Delivery Subsystem") e.g. "Returned
mail: see transcript for details". The suggested subjects is "Returned
mail: possible virus found" and "Returned mail: content filter
triggering). This subject MAY be optionally extended with the IP
address from which the infected message has been received. The subject
MAY also contains the name of the virus (or content filter) in
question.

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

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

1.1.2.) Original Message
The notification MUST never include the original message body and
attachment(s) (if any) 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. The header of the original message MUST be
included in the notification's body to allow the further analysis by
the system administrators and advanced users (i.e. responsible
persons). However the original message body SHOULD be accessible by
these and only these responsible persons via some Web-interface,
queries to postmaster of the sending domain or direct access to the
mail server quarantine directory.

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

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

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

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

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

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

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

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


-- 

Yours sincerely,

Andrey G. Sergeev (AKA Andris)     http://www.andris.msk.ru/

Powered by blists - more mailing lists