|
Bugtraq
mailing list archives
RE: virus handling
From: "Shaun Bertrand" <sbertrand () cbihome com>
Date: Mon, 2 Feb 2004 20:14:00 -0500
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 () hq adiscon com]
Sent: Wednesday, January 28, 2004 12:04 PM
To: Thomas Zehetbauer; bugtraq () securityfocus com
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 () 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.
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.
By Date
By Thread
Current thread:
|