Fwd: Undelivered Mail Returned to Sender
Please folks, this is exactly the reason why you should NOT send bounces in reply to virusses. I'm very disappointed that SuSE is still not aware of the implications of this annoying behaviour. To summarize, only send warnings to authenticated senders otherwise you might be sending it to a spoofed sender address. At the same time it is a perfect example of the type of message (and the user) I wrote about just over an hour ago. Obviously he is still connected to this list, so I think it would be worthwile to run a scan who it is and to unsubscribe him. As can be seen from the bounce message, the message originated from pD951F606.dip.t-dialin.net [217.81.246.6] too. This system is NOT supposed to send mail on behalf of the 'de-korte.org' domain. And I doubt the HELO 'suse.com' is valid either. As a side note, it is easy to drop this particular virus by using the Postfix 'smtpd_helo_restrictions' to drop all hosts claiming to be from within your own domain, which you know, are not. ---------- Forwarded Message ---------- Subject: Undelivered Mail Returned to Sender Date: Friday 04 June 2004 10:20 From: MAILER-DAEMON@suse.de (Mail Delivery System) To: suse-security@de-korte.org This is the Postfix program at host hermes.suse.de. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to <postmaster> If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <25866@suse.de>: unknown user: "25866" ------------------------------------------------------- Encapsulated message Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) by hermes.suse.de (Postfix) with ESMTP id 85C238C9D for <25866@suse.de>; Fri, 4 Jun 2004 10:20:20 +0200 (CEST) Received: by scanhost.suse.de (Postfix, from userid 0) id 7B27951E5F; Fri, 4 Jun 2004 10:20:20 +0200 (CEST) Delivered-To: virus-quarantine X-Quarantine-id: <virus-20040604-101415-03775-17> Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by hermes.suse.de (Postfix) with ESMTP id 953E669115 for <25866@suse.de>; Fri, 4 Jun 2004 10:13:46 +0200 (CEST) Received: from suse.de (pD951F606.dip.t-dialin.net [217.81.246.6]) by Cantor.suse.de (Postfix) with ESMTP id 4B95668F3BE for <25866@suse.de>; Fri, 4 Jun 2004 10:13:32 +0200 (CEST) From: suse-security@de-korte.org To: 25866@suse.de Subject: Re: Your music Date: Fri, 4 Jun 2004 10:26:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20040604081332.4B95668F3BE@Cantor.suse.de> X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.Gen-1 X-Converted-To-Plain-Text: from multipart/mixed by demime 1.1d X-Converted-To-Plain-Text: Alternative section used was text/plain Please have a look at the attached file. [the SUSE virus scanner removed an attachment of type application/octet-stream which had a name of mp3music.pif] [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] End of encapsulated message
On Jun 4, Arjen de Korte <suse-security@de-korte.org> wrote:
Please folks, this is exactly the reason why you should NOT send bounces in reply to virusses. I'm very disappointed that SuSE is still not aware of the implications of this annoying behaviour. To summarize, only send warnings to authenticated senders otherwise you might be sending it to a spoofed sender address. To prevent spoofing, you can enable SPF for your domain (SuSE should do so as well, and also everybody else who reads this). See http://spf.pobox.com for more information.
Basically, SPF means that you insert a TXT record into your DNS zone that specifies which IP-addresses and MX servers are allowed to send mail with a FROM that contains your domain name. Markus
On Friday 04 June 2004 11:29, Markus Gaugusch wrote:
To prevent spoofing, you can enable SPF for your domain (SuSE should do so as well, and also everybody else who reads this). See http://spf.pobox.com for more information.
I'm well aware of what SPF might do to prevent this kind of abuse. However, I don't have access to TXT records since the webinterface of the registrar's nameservers do not allow me to configure TXT records (yet). I have not been able to convince them that allowing their users to configure TXT records has no unexpected security implications and that it would be a welcome addition to their service. Since SPF is still not widely supported (only a small percentage of domains is actually using it to block incoming traffic) I do not want to take the additional burden to operate my own nameserver for my domains (yet). Best regards, Arjen PS Since I read this list too, there is no reason to send message both to the mailing list and in private.
On Fri, 2004-06-04 at 11:41, Arjen de Korte wrote:
On Friday 04 June 2004 11:29, Markus Gaugusch wrote:
To prevent spoofing, you can enable SPF for your domain (SuSE should do so as well, and also everybody else who reads this). See http://spf.pobox.com for more information.
Also, many of us have mobile users and don't necessarily want to set up secure SMTP for them, so get them to use romaing SMTP servers. Too difficult to manage all the potential servers out there.
PS Since I read this list too, there is no reason to send message both to the mailing list and in private.
Oops, sorry ( :) )
Quoting Markus Gaugusch <markus@gaugusch.at>:
To prevent spoofing, you can enable SPF for your domain (SuSE should do so as well, and also everybody else who reads this). See http://spf.pobox.com for more information.
Basically, SPF means that you insert a TXT record into your DNS zone that specifies which IP-addresses and MX servers are allowed to send mail with a FROM that contains your domain name.
SPF breaks forwarding. My domains used to publish SPF info until my customers started complaining. If anyone from your domain sends mail to someone who uses a forwarding service (very common in virtual domain setups), your mail will be dropped. For instance, let's say I own foo.com, and have it hosted at a hosting company, having any mail sent to it forwarded to my local ISP mail account. A fairly typical setup for a domain owner of a small set. If my local ISP uses SPF, I will no longer recieve mail sent to foo.com. My friend Bob sends the mail to foo.com, which then sends it to me. The SPF for Bob's domain doesn't list foo.com. My mail gets dropped. SPF is SERIOUSLY flawed. Security is about getting the legitimate through while blocking the bad. SPF fails on this account.
Quoting Markus Gaugusch <markus@gaugusch.at>:
To prevent spoofing, you can enable SPF for your domain (SuSE should do
so
as well, and also everybody else who reads this). See http://spf.pobox.com for more information.
Basically, SPF means that you insert a TXT record into your DNS zone
It's off topic for this list and I won't post again, but there are mechanisms in SPF for your scenerio. Lyle ----- Original Message ----- From: <suse@rio.vg> To: <suse-security@suse.com> Sent: Friday, June 04, 2004 9:49 AM Subject: Re: [suse-security] Fwd: Undelivered Mail Returned to Sender that
specifies which IP-addresses and MX servers are allowed to send mail with a FROM that contains your domain name.
SPF breaks forwarding. My domains used to publish SPF info until my customers started complaining. If anyone from your domain sends mail to someone who uses a forwarding service (very common in virtual domain setups), your mail will be dropped.
For instance, let's say I own foo.com, and have it hosted at a hosting company, having any mail sent to it forwarded to my local ISP mail account. A fairly typical setup for a domain owner of a small set. If my local ISP uses SPF, I will no longer recieve mail sent to foo.com.
My friend Bob sends the mail to foo.com, which then sends it to me. The SPF for Bob's domain doesn't list foo.com. My mail gets dropped.
SPF is SERIOUSLY flawed. Security is about getting the legitimate through while blocking the bad. SPF fails on this account.
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Fri, 2004-06-04 at 11:23, Arjen de Korte wrote:
As a side note, it is easy to drop this particular virus by using the Postfix 'smtpd_helo_restrictions' to drop all hosts claiming to be from within your own domain, which you know, are not.
smtpd_delay_reject = no smtpd_sender_restrictions = hash:/etc/postfix/access,reject_unknown_sender_domain smtpd_client_restrictions = smtpd_helo_required = yes disable_vrfy_command = yes strict_rfc821_envelopes = no smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, permit smtpd_data_restrictions = reject_unauth_pipelining, permit Couple of lines out of my postfix main.cf file. These lines alone have stopped almost 60% of inbound SPAM attempts, as well as reducing virii threats by huge percentages. I tries the strict_rfc821_envelopes = yes, but found that so many MTA's are configured poorley that too much legitimate mail was bouncing :( Thats Postfix, lightweigt, simple to configure, and flexible. B
---------- Forwarded Message ----------
Subject: Undelivered Mail Returned to Sender Date: Friday 04 June 2004 10:20 From: MAILER-DAEMON@suse.de (Mail Delivery System) To: suse-security@de-korte.org
This is the Postfix program at host hermes.suse.de.
I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can delete your own text from the message returned below.
The Postfix program
<25866@suse.de>: unknown user: "25866"
-------------------------------------------------------
Encapsulated message
Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) by hermes.suse.de (Postfix) with ESMTP id 85C238C9D for <25866@suse.de>; Fri, 4 Jun 2004 10:20:20 +0200 (CEST) Received: by scanhost.suse.de (Postfix, from userid 0) id 7B27951E5F; Fri, 4 Jun 2004 10:20:20 +0200 (CEST) Delivered-To: virus-quarantine X-Quarantine-id: <virus-20040604-101415-03775-17> Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by hermes.suse.de (Postfix) with ESMTP id 953E669115 for <25866@suse.de>; Fri, 4 Jun 2004 10:13:46 +0200 (CEST) Received: from suse.de (pD951F606.dip.t-dialin.net [217.81.246.6]) by Cantor.suse.de (Postfix) with ESMTP id 4B95668F3BE for <25866@suse.de>; Fri, 4 Jun 2004 10:13:32 +0200 (CEST) From: suse-security@de-korte.org To: 25866@suse.de Subject: Re: Your music Date: Fri, 4 Jun 2004 10:26:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20040604081332.4B95668F3BE@Cantor.suse.de> X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.Gen-1 X-Converted-To-Plain-Text: from multipart/mixed by demime 1.1d X-Converted-To-Plain-Text: Alternative section used was text/plain
Please have a look at the attached file.
[the SUSE virus scanner removed an attachment of type application/octet-stream which had a name of mp3music.pif] [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses]
End of encapsulated message
On Friday 04 June 2004 11:42, b@rry.co.za wrote:
smtpd_delay_reject = no smtpd_sender_restrictions = hash:/etc/postfix/access,reject_unknown_sender_domain smtpd_client_restrictions = smtpd_helo_required = yes disable_vrfy_command = yes strict_rfc821_envelopes = no smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject
smtpd_data_restrictions = reject_unauth_pipelining, permit
Couple of lines out of my postfix main.cf file.
Your (quite minimal) configuration will not stop the virus in question, the sender host matches all criteria you listed here. I have no problems in stopping the virusses entering my system (a single RBL in smtpd_client_restrictions is sufficient in case of the 'dip.t-dialin.net' senders), it is the virus warnings from perfectly legitimate systems that are bothering me. Best regards, Arjen
On Fri, 2004-06-04 at 11:56, Arjen de Korte wrote:
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, reject
Can't remember why I stopped using smtpd_recipient_restrictions (I think I was still trying out various configurations with content filters as I use trend interscan virus wall, which connects always as localhost, have fixed this now with the content_filter=smtp[localhost]:10026 string and editing my master.cf to match this nicely)
Your (quite minimal) configuration will not stop the virus in question, the sender host matches all criteria you listed here. I have no problems in stopping the virusses entering my system (a single RBL in smtpd_client_restrictions is sufficient in case of the 'dip.t-dialin.net' senders), it is the virus warnings from perfectly legitimate systems that are bothering me.
Yup, I started a string about these some months ago (when I needed coffee and a break from users wasting my time by insiting they had a virus as user@somewhere told them so. [snip my previous] From: "Barry Gill" <b@rry.co.za> Date: Thu, 11 Mar 2004 09:40:28 +0200 Message-ID: <PMEJIAOJHLLNGELPDEEIAEJKCBAA.b@rry.co.za> Subject: [suse-security] Anti-Virus reports Hello All. As most of you are technical, you should for the most part be in control of, or have the ear of the person who is in control of your corporate anti-virus solutions. Please for the sake of the internet can you STOP your servers sending virus notifications to the originators of the message as with today's modern virii 90% of virii use spoofed "from:" addresses. So, every time some poor person out there with MY name in their address book, or contacts folder gets a virus, I get 3000 messages (as I am sure do most of you on this list at least) telling me that I sent a virus to someone I have never heard of in my life before. This form of server administration is a very very poor form of security as you are willfully informing people who have possibly never thought of you or your servers before several key steps that it may have taken them some time to figure out. Things like... Antigen for Exchange found ScanMail for Microsoft Exchange took action on the message. The message details were: Symantec AVF detected an unrepairable NAV for Microsoft Exchange etc etc etc. Sending out mass mailer responses to virii wastes as much respource as coping with the virii themselves. Stop wasting your and my bandwidth, send reports only to admin, check the headers and if you receive mail form an address or domain often and the headers check out, THEN notify the admin/postmaster of that domain. I mean please, telling Lucy in the clerks dept about the fact that she is sending virii to somebody she has never met in Luxembourg is only going to cost her tima and money as she will call out her IT people to clean her "infected machine" Sorry about the rant, this is just one of the most annoying things that for some reason no-one ever seems to consider when setting up all this AV stuff. Barry [/snip of my previous]
Am 04.06.2004 um 11:23 schrieb Arjen de Korte:
As a side note, it is easy to drop this particular virus by using the Postfix 'smtpd_helo_restrictions' to drop all hosts claiming to be from within your own domain, which you know, are not.
And you should reject mails to non-existant users right after RCPT TO: with the local_recipient_maps parameter in main.cf. That keeps your mail queue clean from your own bounces to non-existant spam and virus sender addresses and saves a lot of bandwidth (and cpu-cycles while virus-scanning).
participants (6)
-
Arjen de Korte
-
b@rry.co.za
-
Backhausen, Sven
-
Lyle Giese
-
Markus Gaugusch
-
suse@rio.vg