Onderwerp: RFC: virus handling

--=-8t+9gk5k1J22gODjJtFk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

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

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

Experience is what you get when you expected something else.



--=-8t+9gk5k1J22gODjJtFk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iQEVAwUAQBfZGGD1OYqW/8uJAQLkVwf/S/EqlV5NNS1njJu380fQQX0p+oI7tZeU
oC24XZF9bCFieVioqUWYWls4u1z9Aobg82dWUIE0LrEdnCihdC XlgPLVG4jTWknK
SxGmloxzF8JpVvmpDYiz2yjjg5TiqtyiKUNZ8ABelAealfAGVC BBKqPwsiT8AyaB
mrIkaDiMwDaR4/wesj3tYiRdh8pyYakX3JjaQnmxxImCAa+4/PYqYgCo31RurtmN
YCf7PgGZEcYb3E11X8NrlZqhsz7ns3Lqclb2eUqErI1yX4K31y v5/EJSjFjLOSXD
TA9HX1GwN8LN5zVNibpNcgVYVkSFPEIOiFaj9AJvT7qdawgb/R6kWg==
=dCCL
-----END PGP SIGNATURE-----

--=-8t+9gk5k1J22gODjJtFk--

Dear Thomas Zehetbauer,


--Wednesday, January 28, 2004, 6:45:39 PM, you wrote to bugtraq@securityfocus.com:

TZ> Looking at the current outbreak of the Mydoom.A worm I would like to
TZ> share and discuss some thoughts:

Most of your ideas are already covered by RFC1892/RFC3462. The only
problem is antiviral developers won't learn.


--
~/ZARAZA
Áðîñüòå ñòàðàòüñÿ - íè÷åãî èç ýòîãî íå âûéäåò. (Òâåí)

--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

* Thomas Zehetbauer <thomasz@hostmaster.org>
> 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).

I prefer the term 'malware' instead, to avoid the various worm/virus/
trojan horse/Microsoft Windows distinctions that can be made.

The 'possible virus found' statement might actually work for some
English speakers where the malware in question was not forged from some
other system not under the control of the recipient in question.

Personally, I prefer discarding all malware, and would love to see e-
mail forwarding break in favor of Sender Permitted From (SPF):

http://spf.pobox.com/

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

Without even the full message headers to figure out where the message
originated from?

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

Some sites configure their e-mail systems this way to prevent 'RCPT TO'
scans from revealing all valid e-mail addresses. Others may use
forwarding services, where the forwarding service has no means of
guessing what addresses the site in question allows.

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

What, instead of a quick 'EHLO, MAIL FROM, RCPT TO, User unknown' a site
instead has to accept every message, scan it for known malware, and then
figure out what to do? I do hope this is not what you are recommending.

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

Which name of the malware? Worm.SCO.A? MyDoom? Other? What if the IP
address turns out to be a e-mail relay? Where does one find the original
infected Microsoft system without the full message headers? What if the
mailing list stripped out the previous headers? What if the malware
starts forging the received headers?

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

Expensive and hard if not impossible to implement at larger sites. Would
be prone to spamming, and false notifications about e-mail relays that
are not yet catching the latest in malware. And downright useless if the
user does not know or care what their Windows system is doing, is on
vacation, or whose open wireless network is letting someone else release
malware to the Internet.

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

Others null route infected hosts first (thereby stopping the flow of
malware) instead of waiting. This allows one to close off any open
wireless networks one does not otherwise have the policital clout to
properly disable:

1. Install Microsoft Windows on a laptop.
2. Infect said system with various malware.
3. Connect to open wireless network.
4. Wait for Network Operations to close wireless network port down.

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

-----BEGIN PGP SIGNATURE-----
Comment: https://www.sial.org/jmates.key

iD8DBQFAF/pwqEafhhHD1igRAkqVAKCfJWK3jdKxNWEn31NsvWMYeked2QCg hYXd
woIjxjnRHMkA7va7CzUW/Dw=
=JKmw
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

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]=20
> 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
> share and discuss some thoughts:
>=20
> 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.
>=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
> notification messages unless the administrator has been warned that
> these notification messages may not reach the intended=20
> recipient and has
> still enabled this feature.
>=20
> 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.
>=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=20
> the name 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
> test conducted (eg. forbidden file type).
>=20
> 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.
>=20
> 1.2.) Notification
> Regarding wasted time and storage capacity the false=20
> 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=20
> do so should
> tell these people to fix their badly configured e-mail scanners.
>=20
> 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.
>=20
> 2.1.) Avoid
> Virus filters should therefore be designed and implemented before
> checking the legitimacy of the intended recipient. This would=20
> also 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
> commercial provider have been affected by this worm.=20
>=20
> 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=20
> knowing their
> IP address.
>=20
> 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=20
> date of 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 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
> 3.2.) Disconnect
> Providers should grant their customers some grace period to=20
> 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=20
> 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

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

On Wed, Jan 28, 2004 at 04:45:39PM +0100, Thomas Zehetbauer wrote:

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

I would prefer to use "X-" Extension Fields in the Mail header for
this. This could be made more flexible and without messing with the
Subject line, which might be localized or used to provide more
speific Information like "mail-worm badthing.C found".

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

I think this wouldn't work, and it wouldn't be a good idea in general.
Thirst of all, most privat customers use dynamic IPs, so the address
wouldn't belong to one specific user. Furthermore these addresses
would be easy to guess (in most cases even _known_) and a great target
for spamers and worms, and finaly the average customer isn't captable
of distinguishing a false virus-warning from a real one -- there are
many hoax out there, and some worms already spread using faked
virus-warnings, so I think sending Virus-Warnings via eMail to
end-users isn't a good idea at all.
=20
> 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.

Hard measurements like that may be usefull in some cases, but the reasons
must be verified very carefully -- otherwise it would be a easy to
abuse bases for DOS attacs, just by sending complains to the ISP.

yust my two cent
cheers
--=20
Sascha Wilde
We're Germans and we use Unix. That's a combination of two=20
demographic groups known to have no sense of humour whatsoever.
-- Hanno Mueller in de.comp.os.unix.programming

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQFAGPoRqL6urpPh1/wRAiQ4AJ9n1Mb+2fvrSZGi9Hvxy0RyB4soHwCdFHqp
LA4f/bZ7eYqQsp7UJXn6rTw=
=7XdL
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--

And since I missed the Reply all.. For the list at large:

Thomas Zehetbauer wrote:

> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:

Glad to oblige..

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

Shut off notifications.

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

Shut off notifications.

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

Shut off notifications.

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

Shut off notifications.

> 1.2.2.) Virus Information
> The message should always include the name of the virus found or the
> test conducted (eg. forbidden file type).

Shut off notifications. (Is there a trend appearing here?)

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

Shut off notifications.

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

Fire the admins..

Shut off notifications.

>
> 2.) Non Delivery Notifications

[much snippage]

Just about everything you have stated to this point can be covered by
shutting off notifications. As we have all seen over the past 3 years,
the notifications are useless and only serve to clog up bandwidth and
bring systems down.

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

Excuse me?

I need to hear more about how this could be implemented and _maintained_
easily.

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

Any admin worth their salt is already doing this. If they aren't, they
need to find a new job.

>
> Regards
> Tom
>


--
Craig Morrison

http://www.mtsprofessional.com/
A Win32 email server that works for You.

On Wed January 28 2004 10:45, Thomas Zehetbauer wrote:

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

This would vastly simplify dictionary-attack spamming.

> or a web interface with similiar functionality.

Better, but still might be easily abused by scripting.

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

Grace, shmace! Viri can do their dirty work in a matter of seconds.
How about the ISP *immediately* blocks just the port(s) in question?
(Recognizing that that could be *all* ports.) It could unblock after
some time period with no outbound virus infection (or phone home for
orders, etc.) attempts, and of course reblock when any new such
activity is detected.

--
Dave Aronson, Senior Software Engineer, Secure Software Inc.
(Opinions above NOT those of securesw.com unless so stated!)
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
Web: http://destined.to/program http://listen.to/davearonson

> 3.1.1.) Abuse Role Account
> Providers should provide an adequately stuffed abuse role account

Typo: "stuffed" > "staffed"

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


I would disagree with 3.1.2. Otherwise you could end up with direct
marketing companies such as Doubleclick harvesting the IP addresses
accessing their banner ads and then sending UCE to those people. Or for
that matter, it could lead to a mass attack with someone sending UCE to
every IP address allocated to an ISP. *Someone* probably will be using
that IP and spammers clearly don't care who sees their spam.

Otherwise I entirely agree with this. Bouncing a virus-infected email is
worse than useless. It is active participation in the distribution of
the worm and the damage to networks it is causing.

Regards,

Mike Healan
Editor
www.spywareinfo.com

----- Original Message -----
From: "Thomas Zehetbauer" <thomasz@hostmaster.org>
To: <bugtraq@securityfocus.com>
Sent: Wednesday, January 28, 2004 10:45 AM
Subject: RFC: virus handling

Hello, Thomas!
You wrote to <bugtraq@securityfocus.com> on Wed, 28 Jan 2004 16:45:39 +0100:

TZ> 1.1.) Configuration
TZ> Unless the virus scanner provides special handling for worms and virii
TZ> which knowingly use a faked sender address it should not send out
TZ> notification messages unless the administrator has been warned that
TZ> these notification messages may not reach the intended recipient and
TZ> has still enabled this feature.

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 know many administrators who do not care of a few thousands antivirus
reports per day. No "warnings" are accepted. I would like to have some RFC
which disallows such behaviour, so I could send them all to RFC-ignorant BL.

TZ> 1.2.1.) Standardization
TZ> To allow filtering of these messages they should always carry the text
TZ> 'possible virus found' in the subject optionally extended by the name
TZ> of the virus or the test conducted (eg. heuristics).

It is unfair in relation to other languages. Many users do not read in
English, and Subject is supposed to be human-readable field. This
information could have standard form in other header.

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 reached
TZ> via 127.0.0.1@provider.com) or a web interface with similiar
TZ> functionality. The latter should be provided when dynamically assigned
TZ> IP addresses are used for which an additional timestamp is required.

It tends to be non-standard interface, which is very hard to find and use.


With best regards, Pavel Levshin. E-mail: flicker@mariinsky.ru

Thomas Zehetbauer wrote:
>
> 1.1.) Configuration
> Unless the virus scanner provides special handling for worms and virii
> which knowingly use a faked sender address

I think that virus scanners SHOULD provide some sort of information on
the reliability of headers and SMTP envelope of the virus e-mail and act
accordingly.

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.

This is a major problem, since the administrators are often (an with
good reason) not responsive enought with the rapid floods like the one
we saw recently.

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

I would say that a virus scanner SHOULD NOT send notifications unless it
has informations on the reliability of the sender's e-mail address.

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

They could be formatted with a message/delivery-status part but the
problem wouldn't exist at all if all the notifications are sent to the
real infected recipient.

Bye.

--
Daniele Orlandi

On Wed, Jan 28, 2004 at 04:45:39PM +0100, Thomas Zehetbauer wrote:
> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:

I guess you missed Internet Draft about almost exactly what you want:
http://www.ietf.org/internet-drafts/...viruses-00.txt

Also more general I-D could be helpful:
http://www.ietf.org/internet-drafts/...esponse-04.txt

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów

On Wed, 28 Jan 2004, Thomas Zehetbauer wrote:

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

Delivery Status Notification (RFC 1894) has many disadvantages but IMHO it
is still better than Yet Another Idiosyncratic Ad-hoc Format.

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

Notifications, if they are sent at all, should always include at least the
headers of the original message.

(Anyway, people removing a piece of malware from their computer without
taking any steps to prevent future infections (at least reinfections by
the same kind of malware) *deserve* to be reinfected.)

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

Infected hosts should be blocked/disconnected immediately. A filter set up
several hours after the fact (I suppose any reasonable "grace period"
would have to be at least several hours long) is pointless because a
typical 21st century fast spreading worm has already had enough time to
attack everyone in its vicinity.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

On 28 janv. 2004, at 16:45, Thomas Zehetbauer wrote:

> Looking at the current outbreak of the Mydoom.A worm I would like to
> share and discuss some thoughts:


You bring some definitely interesting points here.

I agree with your 1) and 2), but 3) rises some technical concern

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


could be a really good idea, if not so easy to use for spammers or even
for virii. The moment you setup such a service, spammers/virus coder
will write a script that can reach every single user with an active
connexion. It's a really major drawback I think.


patpro
--
je cherche un poste d'admin-sys Mac/UNIX
(ou une jeune et jolie femme riche)
http://patpro.net/cv.php

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.

In terms of the general traffic levels that email virus filters generate, it
strikes me as moronic that anti-virus vendors do not implement a flag to
indicate whether a particular virus signature relates to a virus that is
likely to have come from a forged address, (in which case the mail should
simply be dropped, or stored for administrative review). <rant> Given that
they can't even manage that much, it's little surprise that they don't
understand the value in standardizing the bounce or reading a few RFCs.
</rant>

John Fitzgibbon.


On Wednesday 28 January 2004 07:45 am, Thomas Zehetbauer wrote:
> 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

Craig Morrison wrote Wednesday, January 28, 2004 4:26 PM

> Shut off notifications.

Yup.

Standardizing notifications according to some new RFC would accomplish:
1. Providing another standard message format for socially engineering virus
deliveries.
2. Adding yet another format for notifications - no such RFC would be
universally adopted.
3. Feeding us geeks more useless esoterica to discuss indignantly on the
lists - should noncompliant notifications be a new classification for
rfc-ignorant blacklisting?
4. Continuing bombardment by enough mistaken and virus-faked notifications
to make all notifications worse than useless.
5. Continuing possibilities for using MTA event-handling automation as a
virus distribution vehicle. Possibilities would be more limited, but they
would not be eliminated.
6. It would make it easier to filter the notifications, as the original
poster intended. But I would rather not get them at all when most of them
are mistaken automated notifications.

Dealing with misaddressed mail and incoming infections is boring and costly.
But automated NDRs and virus notifications just spread a larger cost out
across a mail system. They eat the time of the system, the users, their
correspondents, and possibly someone else's admin. They are a selfish way to
push the costs onto others, and probably cost an organization more than they
save in the mail admin's time.

My opinion is you should drop what bad mail you can, and deal with the rest.
Notifications are only useful when they are actionable - they have to be
well-analyzed, and they have to be sent only to people who understand them
and who have the motivation and ability to deal with them. That is a tall
order, which means there should only be a few manually reviewed
notifications.