Re: RFC: virus handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.




[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux