|
Hello! Wed Jan 28 2004 18:45:39 Thomas Zehetbauerwrote: 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@provider.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/