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. > > >
