RFC: virus handling

On Wed, Jan 28, 2004 at 02:00:03PM -0800, John Fitzgibbon wrote:
> There is one standardized feature for virus and other bounce messages, (which
> isn't mentioned in the original proposal), which I believe would really help:
>
> A bounce should *always* include a MIME attachment of type
> message/rfc822-headers which contains the full headers from the original
> mail. This makes it relatively easy to check on the receiving side if the
> original "Received: from" headers are valid, and simply drop bounces that
> relate to messages that were originally sent with forged headers.
>

Outstanding idea. If you (or anyone else on the list) already have a
tested procmail recipe for this, please share. If not, let's make one
and share it around...


thanks


--
Dave Clendenan
dave@clendenan.ca

PGP fingerprint: 910E 8400 7A16 822C 9B62 209F 6CAB DEDF BF4B DF75

Subtlety is the art of saying what you think,
and getting out of the way before it is understood

> -----Original Message-----
> From: Daniele Orlandi [mailto:daniele@orlandi.com]

> I use amavisd-new which has support for listing viruses/worms
> that fake
> the sender's email address. Unfortunatelly the list is external to the
> actual virus scanner and has to be updated manually.

Given that the majority of new viruses forge the sender's email address, I
think the reverse would make more sense -- have a list of viruses that
*don't* forge, and only send notifications for those.

--5I6of5zJg18YgZEa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 28, 2004 at 07:24:52PM +0100, Patrick Proniewski wrote:
> On 28 janv. 2004, at 16:45, Thomas Zehetbauer wrote:
>=20
> >Looking at the current outbreak of the Mydoom.A worm I would like to
> >share and discuss some thoughts:
>=20
>=20
> You bring some definitely interesting points here.
>=20
> I agree with your 1) and 2), but 3) rises some technical concern
>=20
> >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.
>=20
>=20
> could be a really good idea, if not so easy to use for spammers or even=
=20
> for virii. The moment you setup such a service, spammers/virus coder=20
> will write a script that can reach every single user with an active=20
> connexion. It's a really major drawback I think.

Perhaps something with more limited functionality, then?

Consider a provider who offers the e-mail address of
virusalert@provider.com (name it what you will), to which can be fed an
e-mail consisting of a single line -- that line is the IP address and a
one-word 'name' for the problem.=20

Thus, if I find I'm getting MyDoom.A from 127.2.2.1, I can send a message
that will alert _someone_ (who is presumeably not asleep at the controls).

It also means that general e-mail cannot be sent via this interface -- no
spamming. The provider can take this information, look it up (with the
timestamp the e-mail came in at, if necessary for large dynamic pools), and
take action (the least of which, I hope, would be to notify the end-user).

This could even be done without e-mail at all. A quick HTTP GET/POST could
carry this information. Heck, this could run much like ident/auth
services to a designated machine (i.e. virusalert.provider.com).

Matt

--=20
Matthew Dharm Home: mdharm@one-eyed-alien.net=
=20
Senior Software Designer, Momentum Computer

IT KEEPS ASKING ME WHERE I WANT TO GO TODAY! I DONT WANT TO GO ANYWHERE!
-- Greg
User Friendly, 11/28/97

--5I6of5zJg18YgZEa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAIAq8IjReC7bSPZARAkSKAKCUJ3XYL3mZJ82OBHqMdp M7lpT9YACeN1S7
E2tuA++MHUvMUUBphs8kMUE=
=pq60
-----END PGP SIGNATURE-----

--5I6of5zJg18YgZEa--

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

I dunno, maybe I'm taking this too much in the context of enterprise
companies vs home users. Anyways... My 1/2 cent.=20

=20

-----Original Message-----
From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]=20
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=20

> -----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
>=20
> Looking at the current outbreak of the Mydoom.A worm I would like to=20
> share and discuss some thoughts:
>=20
> 1.) Virus Detected Notifications
> After filtering out the messages generated by the worm itself there=20
> remain a lot of messages generated by automated e-mail scanning=20
> solutions.
>=20
> 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=20
> notification messages unless the administrator has been warned that=20
> these notification messages may not reach the intended recipient and=20
> has still enabled this feature.
>=20
> 1.2.) Format
> These messages cannot be easily filtered because they come in many=20
> different formats and do often not contain any useful information at=20
> all.
>=20
> 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=20
> of the virus or the test conducted (eg. heuristics).
>=20
> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the=20
> test conducted (eg. forbidden file type).
>=20
> 1.1.2.) Original Message
> The notification should never include the original message sent as=20
> otherwise it may send the worm/virus to a previously unaffected third=20
> party or re-infect a system that has already been cleaned.
>=20
> 1.2.) Notification
> Regarding wasted time and storage capacity the false notifications=20
> 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=20
> should tell these people to fix their badly configured e-mail=20
> scanners.
>=20
> 2.) Non Delivery Notifications
> It seems that this worm is trying to avoid people getting treacherous=20
> non delivery notifications by using obviously faked but otherwise=20
> plausible e-mail addresses. This may cause double bounce messages or=20
> even message loops at badly configured sites.
>=20
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before=20
> checking the legitimacy of the intended recipient. This would also=20
> avoid helping the virus spread by bouncing it to a previously=20
> unaffected third party.
>=20
> 3.) ISPs
> It is worth to note that once again primarily individuals using a=20
> commercial provider have been affected by this worm.
>=20
> 3.1.) Notification
> As these people do mostly not run a SMTP server on their system it is=20
> unfortunately almost impossible to contact them when only knowing=20
> their IP address.
>=20
> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account to=20
> allow the affected users beeing notified. To ease efficiency messages=20
> sent there should include the IP address, the exact time and date of=20
> the incident and the name of the virus on the subject line.
>=20
> 3.1.2.) e-mail Alias and Web-Interface Additionally providers should=20
> provide e-mail aliases for the IP addresses of their customers (eg.=20
> customer at 127.0.0.1 can be reached via 127.0.0.1@provider.com) or a=20
> web interface with similiar functionality. The latter should be=20
> provided when dynamically assigned IP addresses are used for which an=20
> additional timestamp is required.
>=20
> 3.2.) Disconnect
> Providers should grant their customers some grace period to clean=20
> their infection and should thereafter be disconnected entirely or=20
> filtered based on protocol (eg. outgoing SMTP) or content (eg.=20
> transparent smarthost with virus scanner) until they testify that they

> have cleaned their system.
>=20
> Regards
> Tom
>=20
> --=20
> 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
>=20
> Experience is what you get when you expected something else.
>=20
>=20
>=20



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.

On Thu, 29 Jan 2004, Pavel Levshin wrote:

> Antivirus software MAY be configured to send notifications to local senders
> and/or recipients, i.e. to domains which are handled by this server.
> Antivirus filtering software SHOULD NOT be configured to send out
> notifications to senders or recipients other than local, unless it
> distinguishes between faked and real addresses.

I would add:

"If anti-virus filtering software sends notifications to non-local
recipients, then the sender address of the notifications MUST be an
address that can be replied to, and this reply MUST reach a human
being."

Rationale: When my filtering software bounces all these stupid notifications,
I want a person to get stuck with all the bounce messages, thereby encouraging
him/her to turn off non-local notifications.

--
David.

> > A bounce should *always* include a MIME attachment of type
> > message/rfc822-headers which contains the full headers from the original
> > mail. This makes it relatively easy to check on the receiving side if the
> > original "Received: from" headers are valid, and simply drop bounces that
> > relate to messages that were originally sent with forged headers.

> Outstanding idea. If you (or anyone else on the list) already have a
> tested procmail recipe for this, please share. If not, let's make one
> and share it around...

Done that:

http://volker.dnsalias.net/soft/proc...otification.rc

As a quick guess, the received: recipe catches 1/2 - 2/3 of all
responses from those idiots, though I'm not recording exactly which
recipe triggers because I don't care which rubbish it is.

Anything can be improved, of course.

Volker

--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.

>
>
>> -----Original Message-----
>> From: Daniele Orlandi [mailto:daniele@orlandi.com]
>
>> I use amavisd-new which has support for listing viruses/worms
>> that fake
>> the sender's email address. Unfortunatelly the list is external to the
>> actual virus scanner and has to be updated manually.
>
>Given that the majority of new viruses forge the sender's email address, I
>think the reverse would make more sense -- have a list of viruses that
>*don't* forge, and only send notifications for those.

Considering that virus scanners still operate using signatures,
it seems logical to include a flag for each specific virus so that
when it is recognized the virus software knows that they shouldn't
bother me.

(A, and yes, it is a lot of fun that those virus scanner vendors sell
*localized* versions of their software so I've now had them tell me in
more languages and character sets than I care to remember how bloody
incompetent they are.)


Casper

On Tue, Feb 03, 2004 at 12:55:24PM -0800, Matthew Dharm wrote:
> Consider a provider who offers the e-mail address of
> virusalert@provider.com (name it what you will), to which can be fed an
> e-mail consisting of a single line -- that line is the IP address and a
> one-word 'name' for the problem.
>
> Thus, if I find I'm getting MyDoom.A from 127.2.2.1, I can send a message
> that will alert _someone_ (who is presumeably not asleep at the controls).

I don't see much difference between this and the normal strategy of
just notifying abuse@ or some other address at the ISP. It is similarly
doomed to failure, because you end up with so many reports that the ISP
cannot possibly verify whether each report is legitimate or not. So they
would have a choice of either:
1. Ignore all reports. "It's not our job to protect our lusers from viruses."
or
2. Automatically take action against all reports. Thus is becomes a great
way to DoS your enemies, just report them as infected.

Since the ISP gets money from its customers, not from people who report
abuse, they will always tend towards option 1 as the number of reports
increases. Reporting abuse or infection is mostly a complete waste
of time, just like reporting spam. It might have worked a few years ago,
it generally doesn't anymore (and the exceptions get fewer all the time).

Our time would be far better invested in ways to prevent the spread of
viruses by other means rather than trying to report infections, after
it's already too late, to either ISPs who will usually do nothing, or
end users who will usually be clueless (otherwise they wouldn't have
got infected in the first place, right?)

Ben

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 04, 2004 at 01:44:30PM +0000, Ben Wheeler said:
>=20
> cannot possibly verify whether each report is legitimate or not. So they=
=20
> would have a choice of either:
> 1. Ignore all reports. "It's not our job to protect our lusers from virus=
es."
> or=20
> 2. Automatically take action against all reports. Thus is becomes a great
> way to DoS your enemies, just report them as infected.

You're forgetting a third option:

Find or develop a method of scanning their hosts for the
virus/worm/trojan/foo, and cut off access on the necessary ports when
those hosts are found.

That's what Road Runner, for instance, did in some areas in response to
Code Red and Nimda.

A more extreme position (that I favor) is to put a note in the account's
file that they are infected and causing a problem, then cut off their
access entirely. When they call tech support, they find out they're
infected.

If ISPs do this (and as I've stated, some do), then reporting infections
to them is vital, because unless they understand that it's a large
number of their users, they won't bother dealing with it.


--=20
Shawn McMahon | Let every nation know, whether it wishes us well or ill,
EIV Consulting | that we shall pay any price, bear any burden, meet any
UNIX and Linux | hardship, support any friend, oppose any foe, to assure
http://www.eiv.com| the survival and the success of liberty. - JFK

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQFAIjyIEcl9bQ0RMt0RAs0kAKCX/sZJJCLl9Wem5XE8iU9fm/WihwCffgmq
HXdLB6CBN3SptKfREEZCBQI=
=hi2Q
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--