RE: virus handling
Mmmmm,
Well to be quite honest I've had a lot of luck mitigating with an ISP to
solve any DoS issues. Now that's not to say the results have always been
successful, but if you know the means of communication and WHO to
contact within the ISP you may have some luck. I've blocked ICMP floods,
DDoS, DoS, and other propagation attempts at the ISP. The trick is to
convince the ISP that this is also their problem. X company pays X
amount of dollars per month to achieve a certain amount of bandwidth. If
X company is being adversely affected due to outside entities you can
sometimes convince an ISP that they have to do something about it.
Remember the ISP's and RPC DCOM? Almost every ISP now blocks 135/139.
I dunno, maybe I'm taking this too much in the context of enterprise
companies vs home users. Anyways... My 1/2 cent.
-----Original Message-----
From: Rainer Gerhards [mailto:rgerhards@xxxxxxxxxxxxxx]
Sent: Wednesday, January 28, 2004 12:04 PM
To: Thomas Zehetbauer; bugtraq@xxxxxxxxxxxxxxxxx
Subject: RE: virus handling
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@xxxxxxxxxxxxxx]
> Sent: Wednesday, January 28, 2004 4:46 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxx) 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@xxxxxxxxxxxxxx
>
> Experience is what you get when you expected something else.
>
>
>
DISCLAIMER:
This e-mail, including attachments, may include confidential and/or proprietary
information, and may be used only by the person or entity to which it is
addressed. If the reader of this e-mail is not the intended recipient or his or
her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.