Open relay

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Open relay

Paul van der Vlis
Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):
----
Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
        (Authenticated sender: [hidden email])
        by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
        Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
----
As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=[hidden email]


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

RE: Open relay

angelo
So what is SASL using in Postfix ?
Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the Password?


You must follow the trail of how they got the password if you say you changed it and it does not help.
-ALF

-Angelo Fazzina
Operating Systems Programmer / Analyst
University of Connecticut,  UITS, SSG-Linux/ M&C
860-486-9075

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul van der Vlis
Sent: Friday, October 21, 2016 4:16 PM
To: [hidden email]
Subject: Open relay

Hello,

I have a big problem, someone is using my mailserver for sending spam. I
see it in de logs. I can block the IP but then they use other IP's.

So far I know my server is up-to-date and correct configured. And when I
do some open relay tests, everything is OK. Like this ones:
http://www.mailradar.com/openrelay/
http://mxtoolbox.com/diagnostic.aspx

The name of my mailserver is mail.vandervlis.nl, so far I see the
spammers are using port 587. Please feel free to do tests.

What I see in the logs and in the headers of the spam is that they are
using authentication. But the username is not correct. On my server I
use usernames like "john", and this username lookslike an e-mail
address, so with an "@" in it. The part before the @ is a correct
username on my server, but when I change the password it does not help.
All spam is recognizeble by this authenticated username.

In the headers I see this as the first "received" (I've changed the
authenticated sender for privacy):
----
Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
        (Authenticated sender: [hidden email])
        by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
        Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
----
As would my server sent it to my server...

Does somebody have a clou here?

With regards,
Paul van der Vlis.


Some settings and logs:

smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_sender_access hash:/etc/postfix/whitelist,
  reject_invalid_hostname,
  reject_non_fqdn_sender,
  reject_non_fqdn_recipient,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  check_policy_service unix:private/shadelist,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  permit

smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes

Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=[hidden email]


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
Hello Angelo and others,

Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> So what is SASL using in Postfix ?
> Is Postfix calling SASL, which calls PAM, which calls LDAP, to check the Password?

Postfix is calling saslauthd, which calls PAM, which calls unix passwords.

> You must follow the trail of how they got the password if you say you changed it and it does not help.

I don't think they have a correct username/password combination, because
the username is wrong.

Maybe it's possible to log the username/password Postfix get?

Maybe they are using some kind of trick to let Postfix think the mail
comes from localhost.

With regards,
Paul van der Vlis.


> -ALF
>
> -Angelo Fazzina
> Operating Systems Programmer / Analyst
> University of Connecticut,  UITS, SSG-Linux/ M&C
> 860-486-9075
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Paul van der Vlis
> Sent: Friday, October 21, 2016 4:16 PM
> To: [hidden email]
> Subject: Open relay
>
> Hello,
>
> I have a big problem, someone is using my mailserver for sending spam. I
> see it in de logs. I can block the IP but then they use other IP's.
>
> So far I know my server is up-to-date and correct configured. And when I
> do some open relay tests, everything is OK. Like this ones:
> http://www.mailradar.com/openrelay/
> http://mxtoolbox.com/diagnostic.aspx
>
> The name of my mailserver is mail.vandervlis.nl, so far I see the
> spammers are using port 587. Please feel free to do tests.
>
> What I see in the logs and in the headers of the spam is that they are
> using authentication. But the username is not correct. On my server I
> use usernames like "john", and this username lookslike an e-mail
> address, so with an "@" in it. The part before the @ is a correct
> username on my server, but when I change the password it does not help.
> All spam is recognizeble by this authenticated username.
>
> In the headers I see this as the first "received" (I've changed the
> authenticated sender for privacy):
> ----
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
>         (Authenticated sender: [hidden email])
>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> ----
> As would my server sent it to my server...
>
> Does somebody have a clou here?
>
> With regards,
> Paul van der Vlis.
>
>
> Some settings and logs:
>
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/etc/postfix/whitelist,
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   reject_unauth_destination,
>   check_policy_service unix:private/shadelist,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client ix.dnsbl.manitu.net,
>   permit
>
> smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> smtpd_use_tls = yes
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_exceptions_networks = $mynetworks
> smtpd_tls_loglevel = 1
> smtpd_tls_auth_only = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_tls_security_options = noanonymous
> broken_sasl_auth_clients = yes
> smtpd_sasl_authenticated_header = yes
>
> Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> client=unknown[94.26.41.188], sasl_method=PLAIN, sasl_username=[hidden email]
>
>



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

lists@lazygranch.com
On Fri, 21 Oct 2016 22:56:45 +0200
Paul van der Vlis <[hidden email]> wrote:

> Hello Angelo and others,
>
> Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> > So what is SASL using in Postfix ?
> > Is Postfix calling SASL, which calls PAM, which calls LDAP, to
> > check the Password?
>
> Postfix is calling saslauthd, which calls PAM, which calls unix
> passwords.
>
> > You must follow the trail of how they got the password if you say
> > you changed it and it does not help.
>
> I don't think they have a correct username/password combination,
> because the username is wrong.
>
> Maybe it's possible to log the username/password Postfix get?
>
> Maybe they are using some kind of trick to let Postfix think the mail
> comes from localhost.
>
> With regards,
> Paul van der Vlis.
>
>
> > -ALF
> >
> > -Angelo Fazzina
> > Operating Systems Programmer / Analyst
> > University of Connecticut,  UITS, SSG-Linux/ M&C
> > 860-486-9075
> >
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Paul van der
> > Vlis Sent: Friday, October 21, 2016 4:16 PM To:
> > [hidden email] Subject: Open relay
> >
> > Hello,
> >
> > I have a big problem, someone is using my mailserver for sending
> > spam. I see it in de logs. I can block the IP but then they use
> > other IP's.
> >
> > So far I know my server is up-to-date and correct configured. And
> > when I do some open relay tests, everything is OK. Like this ones:
> > http://www.mailradar.com/openrelay/
> > http://mxtoolbox.com/diagnostic.aspx
> >
> > The name of my mailserver is mail.vandervlis.nl, so far I see the
> > spammers are using port 587. Please feel free to do tests.
> >
> > What I see in the logs and in the headers of the spam is that they
> > are using authentication. But the username is not correct. On my
> > server I use usernames like "john", and this username lookslike an
> > e-mail address, so with an "@" in it. The part before the @ is a
> > correct username on my server, but when I change the password it
> > does not help. All spam is recognizeble by this authenticated
> > username.
> >
> > In the headers I see this as the first "received" (I've changed the
> > authenticated sender for privacy):
> > ----
> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> > [87.92.55.206]) (Authenticated sender: [hidden email])
> >         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > ----
> > As would my server sent it to my server...
> >
> > Does somebody have a clou here?
> >
> > With regards,
> > Paul van der Vlis.
> >
> >
> > Some settings and logs:
> >
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   check_sender_access hash:/etc/postfix/whitelist,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_pipelining,
> >   reject_unauth_destination,
> >   check_policy_service unix:private/shadelist,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client zen.spamhaus.org,
> >   reject_rbl_client ix.dnsbl.manitu.net,
> >   permit
> >
> > smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> > smtpd_use_tls = yes
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_exceptions_networks = $mynetworks
> > smtpd_tls_loglevel = 1
> > smtpd_tls_auth_only = yes
> > smtpd_sasl_security_options = noanonymous
> > smtpd_sasl_tls_security_options = noanonymous
> > broken_sasl_auth_clients = yes
> > smtpd_sasl_authenticated_header = yes
> >
> > Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> > client=unknown[94.26.41.188], sasl_method=PLAIN,
> > sasl_username=[hidden email]
> >
> >
>
>
>

Perhaps I'm being a bit anal here, and given my skill level (or lack
thereof) I should stay of of this, but is this actually an open relay in
the strict sense? Maybe that is a red herring. If they are using 587,
that would be the master.cf file, not main.cf.

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
 
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Wietse Venema
In reply to this post by Paul van der Vlis
Paul van der Vlis:
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
>         (Authenticated sender: [hidden email])
>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)

That is NOT RELAYING. That is receiving mail from a process that
runs on the same machine. This can happen when the machine runs a
bad web application.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Bill Cole-3
In reply to this post by Paul van der Vlis
On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:

> Hello,
>
> I have a big problem, someone is using my mailserver for sending spam.
> I
> see it in de logs. I can block the IP but then they use other IP's.
>
> So far I know my server is up-to-date and correct configured. And when
> I
> do some open relay tests, everything is OK. Like this ones:
> http://www.mailradar.com/openrelay/
> http://mxtoolbox.com/diagnostic.aspx
>
> The name of my mailserver is mail.vandervlis.nl, so far I see the
> spammers are using port 587. Please feel free to do tests.
>
> What I see in the logs and in the headers of the spam is that they are
> using authentication. But the username is not correct. On my server I
> use usernames like "john", and this username lookslike an e-mail
> address, so with an "@" in it. The part before the @ is a correct
> username on my server, but when I change the password it does not
> help.
> All spam is recognizeble by this authenticated username.
>
> In the headers I see this as the first "received" (I've changed the
> authenticated sender for privacy):
> ----
> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> [87.92.55.206])
>         (Authenticated sender: [hidden email])
>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> ----
> As would my server sent it to my server...

Not exactly. That Received header indicates that the machine at
87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
proceeded to authenticate as the user whose name you've replaced with  
[hidden email].

As a stopgap, you could add a directive like this to
smtpd_helo_restrictions:

    check_helo_access pcre:/etc/postfix/helo_checks

And in that helo_checks file;

     /127\.0\.0\.1/ REJECT you are not me


This will catch and reject formally correct IP literals as in this case
and the more common bare IP form of claiming to be localhost. There's no
reason for any mail client ever to say "EHLO [127.0.0.1]" except to
cause a MTA to generate a confusing Received header.

> Does somebody have a clou here?
>
> With regards,
> Paul van der Vlis.
>
> Some settings and logs:

Those are inadequate to understand this problem.

See the bottom part of the Postfix DEBUG_README file, probably installed
on your machine with Postfix (maybe in both plaintext and HTML) and
always available on the Postfix website. It describes what information
is needed to effectively get help here. The welcome message you got when
you subscribed this list also referenced that document.

Paraphrasing the DEBUG_README and adapting its recommendations to this
issue, you should include:

Full 'postconf -nf' output
Full 'postconf -Mf' output
Full headers of a sample spam message, redacted only to protect *USER*
privacy. (Don't redact hostnames or IPs)
All log lines containing the Postfix queue id of the sample spam
message.
If your SASL layer logs authentication successes and failures (perhaps
in /var/log/auth.log) find the relevant log entries for the sample
message.

There is no need for verbose logging by Postfix.
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Tomoyuki Murakami
In reply to this post by Paul van der Vlis

On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis <[hidden email]> wrote:
> Hello,

> Some settings and logs:
>
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/etc/postfix/whitelist,
>   reject_invalid_hostname,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   reject_unauth_destination,
>   check_policy_service unix:private/shadelist,
>   reject_rbl_client bl.spamcop.net,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client ix.dnsbl.manitu.net,
>   permit
permit after all ?

attachment0 (314 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

permit after all WAS: Open relay

Geert Stappers
On Sat, Oct 22, 2016 at 03:18:36PM +0900, Tomoyuki Murakami wrote:

> On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis wrote:
> > Hello,
>
> > Some settings and logs:
> >
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   check_sender_access hash:/etc/postfix/whitelist,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_pipelining,
> >   reject_unauth_destination,
> >   check_policy_service unix:private/shadelist,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client zen.spamhaus.org,
> >   reject_rbl_client ix.dnsbl.manitu.net,
> >   permit
>
> permit after all ?

Hummm. In networking firewall rules it common[1] to have
a couple of deny rules with an allow rule closing such groups.


Rereading http://www.postfix.org/SMTPD_ACCESS_README.html did
not show any "closing permit".

Should "closing 'permit' lines" be removed from live configurations?


Groeten
Geert Stappers

[1] Common sense is the least common sense of all         :-(
--
Leven en laten leven
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Christian Kivalo
In reply to this post by Tomoyuki Murakami


Am 22. Oktober 2016 08:18:36 MESZ, schrieb Tomoyuki Murakami <[hidden email]>:

>
>On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis
><[hidden email]> wrote:
>> Hello,
>
>> Some settings and logs:
>>
>> smtpd_relay_restrictions =
>>   permit_mynetworks,
>>   permit_sasl_authenticated,
>>   check_sender_access hash:/etc/postfix/whitelist,
>>   reject_invalid_hostname,
>>   reject_non_fqdn_sender,
>>   reject_non_fqdn_recipient,
>>   reject_unknown_sender_domain,
>>   reject_unknown_recipient_domain,
>>   reject_unauth_pipelining,
>>   reject_unauth_destination,
>>   check_policy_service unix:private/shadelist,
>>   reject_rbl_client bl.spamcop.net,
>>   reject_rbl_client zen.spamhaus.org,
>>   reject_rbl_client ix.dnsbl.manitu.net,
>>   permit
>
>permit after all ?

Yes.

- Permit the stuff that shouldn't be rejected (mynetworks, sasl authenticated)
- Perform various checks and reject the things you don't like
- Permit everything that made it through that obstacle course

--
Christian Kivalo
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by lists@lazygranch.com
Op 22-10-16 om 01:31 schreef [hidden email]:

> Perhaps I'm being a bit anal here, and given my skill level (or lack
> thereof) I should stay of of this, but is this actually an open relay in
> the strict sense? Maybe that is a red herring. If they are using 587,
> that would be the master.cf file, not main.cf.
>
> submission inet n       -       n       -       -       smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_reject_unlisted_recipient=no
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING

This is the only thing what I have:
submission inet n      -       -       -       -       smtpd

Is this wrong?

I would like it to set rules for every port separate, but I didn't do it
till now.

With regards,
Paul van der Vlis.



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by Wietse Venema
Op 22-10-16 om 01:46 schreef Wietse Venema:
> Paul van der Vlis:
>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi [87.92.55.206])
>>         (Authenticated sender: [hidden email])
>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>
> That is NOT RELAYING. That is receiving mail from a process that
> runs on the same machine. This can happen when the machine runs a
> bad web application.

Thank you for your help!

Receiving mail from a web application is something what I have checked,
but I did not found anything in the Apache logs. And I see traffic on
port 587 from bad IP's when I log the firewall. I did also turn off
Apache for a while, and I still saw spam coming in. I will investigate
further, there are 3 web applications running on the machine.

What I did yesterday night what stopped the spam, is blocking the mail
from a specific sender ([hidden email] in my example) using
check_sender_access:

smtpd_recipient_restrictions =
    permit_mynetworks,
    check_sender_access hash:/etc/postfix/sender_access,
    permit_sasl_authenticated,
    (...)

The strange thing is that the username they use for authentication
([hidden email]) is not a correct username. So maybe they will come in some
time later with another fake-username...

With regards,
Paul van der Vlis.

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by Tomoyuki Murakami
Op 22-10-16 om 08:18 schreef Tomoyuki Murakami:

>
> On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis <[hidden email]> wrote:
>> Hello,
>
>> Some settings and logs:
>>
>> smtpd_relay_restrictions =
>>   permit_mynetworks,
>>   permit_sasl_authenticated,
>>   check_sender_access hash:/etc/postfix/whitelist,
>>   reject_invalid_hostname,
>>   reject_non_fqdn_sender,
>>   reject_non_fqdn_recipient,
>>   reject_unknown_sender_domain,
>>   reject_unknown_recipient_domain,
>>   reject_unauth_pipelining,
>>   reject_unauth_destination,
>>   check_policy_service unix:private/shadelist,
>>   reject_rbl_client bl.spamcop.net,
>>   reject_rbl_client zen.spamhaus.org,
>>   reject_rbl_client ix.dnsbl.manitu.net,
>>   permit
>
> permit after all ?
Yes, I looked at it yesterday, and I am not sure about it. But I am
using this kind of setup allready for a really long time (16 years?), so
I think it will be right.

But maybe I don't understand the logic completely, and do I have to
study more on the "firewall rules logic of Postfix".

With regards,
Paul van der Vlis.





--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by Bill Cole-3
Op 22-10-16 om 04:32 schreef Bill Cole:
> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:

>> ----
>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>> [87.92.55.206])
>>         (Authenticated sender: [hidden email])
>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>> ----
>> As would my server sent it to my server...
>
> Not exactly. That Received header indicates that the machine at
> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> proceeded to authenticate as the user whose name you've replaced with
> [hidden email].
>
> As a stopgap, you could add a directive like this to
> smtpd_helo_restrictions:
>
>    check_helo_access pcre:/etc/postfix/helo_checks
>
> And in that helo_checks file;
>
>     /127\.0\.0\.1/    REJECT you are not me

Thanks, a great idea to have standard in most cases.

> This will catch and reject formally correct IP literals as in this case
> and the more common bare IP form of claiming to be localhost. There's no
> reason for any mail client ever to say "EHLO [127.0.0.1]" except to
> cause a MTA to generate a confusing Received header.

Right.

With regards,
Paul van der Vlis.


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Wietse Venema
In reply to this post by Bill Cole-3
Bill Cole:

> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> > [87.92.55.206])
> >         (Authenticated sender: [hidden email])
> >         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > ----
> > As would my server sent it to my server...
>
> Not exactly. That Received header indicates that the machine at
> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> proceeded to authenticate as the user whose name you've replaced with  
> [hidden email].

Thanks, I missed that.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: permit after all

/dev/rob0
In reply to this post by Geert Stappers
On Sat, Oct 22, 2016 at 09:33:35AM +0200, Geert Stappers wrote:
> On Sat, Oct 22, 2016 at 03:18:36PM +0900, Tomoyuki Murakami wrote:
> > On Fri, 21 Oct 2016 22:15:32 +0200, Paul van der Vlis wrote:
> > > smtpd_relay_restrictions =

This is a strange choice for spam controls.  It's intended (as a new
feature of Postfix 2.10) only to control permission for relaying.
Typically all the spam controls should go in recipient restrictions.
I don't suppose there is anything *wrong* with doing it this way,
except that most of this has nothing to do with relaying, and it is
confusing to someone who comes after you and has to understand the
configuration you made.

> > >   permit_mynetworks,
> > >   permit_sasl_authenticated,

On port 25 one should not be allowing relay, so these don't belong.

> > >   check_sender_access hash:/etc/postfix/whitelist,
> > >   reject_invalid_hostname,
> > >   reject_non_fqdn_sender,
> > >   reject_non_fqdn_recipient,
> > >   reject_unknown_sender_domain,
> > >   reject_unknown_recipient_domain,
> > >   reject_unauth_pipelining,
> > >   reject_unauth_destination,

This is the only line that belongs here for port 25.  It should be
overridden for the submission service:

[master.cf]
submission [ ... ] smtpd
    -o smtpd_relay_restrictions=$mua_relay_restrictions
[ ... ]

[main.cf]

mua_relay_restrictions = permit_sasl_authenticated,
    reject_unauth_destination

(permit_mynetworks deliberately omitted, because it's a better
practice to always require AUTH from relaying clients, but those who
still want IP-address-based relay permission can use it.)

> > >   check_policy_service unix:private/shadelist,
> > >   reject_rbl_client bl.spamcop.net,

This is an odd choice which can lead to a lot of woe.  Spamcop is an
automated list which often is too aggressive in blocking.

> > >   reject_rbl_client zen.spamhaus.org,
> > >   reject_rbl_client ix.dnsbl.manitu.net,

I'm not personally familiar with this list so I wouldn't use it here.
I am familiar with and DO recommend using Zen, however.

> > >   permit
> >
> > permit after all ?
>
> Hummm. In networking firewall rules it common[1] to have
> a couple of deny rules with an allow rule closing such groups.
>
>
> Rereading http://www.postfix.org/SMTPD_ACCESS_README.html did
> not show any "closing permit".

Look again, the paragraph after the examples:
    http://www.postfix.org/SMTPD_ACCESS_README.html#lists
"The end of the list is equivalent to a PERMIT result."

> Should "closing 'permit' lines" be removed from live
> configurations?

Of course not.  That is how it works.  If not specified as the OP did
it, the ending value of any restriction stage is "permit".  If not,
mail would not be accepted at all.

> [1] Common sense is the least common sense of all         :-(

In this case common sense is to keep rereading the aforementioned
README until you get it. :)
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by Wietse Venema
Op 22-10-16 om 13:41 schreef Wietse Venema:

> Bill Cole:
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>>> [87.92.55.206])
>>>         (Authenticated sender: [hidden email])
>>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> ----
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
>> proceeded to authenticate as the user whose name you've replaced with  
>> [hidden email].
>
> Thanks, I missed that.

Is the conclusion now, that Postfix is relaying here?

With regards,
Paul van der Vlis.



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Geert Stappers
On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

> Op 22-10-16 om 13:41 schreef Wietse Venema:
> > Bill Cole:
> >>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> >>> [87.92.55.206])
> >>>         (Authenticated sender: [hidden email])
> >>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> >>> ----
> >>> As would my server sent it to my server...
> >>
> >> Not exactly. That Received header indicates that the machine at
> >> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
> >> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
> >> proceeded to authenticate as the user whose name you've replaced with
> >> [hidden email].
> >
> > Thanks, I missed that.
>
> Is the conclusion now, that Postfix is relaying here?
>


Reposting what was allready in this thread

| > As a stopgap, you could add a directive like this to
| > smtpd_helo_restrictions:
| >
| >    check_helo_access pcre:/etc/postfix/helo_checks
| >
| > And in that helo_checks file;
| >
| >     /127\.0\.0\.1/    REJECT you are not me
|
| Thanks, a great idea to have standard in most cases.
|
| > This will catch and reject formally correct IP literals as in this case
| > and the more common bare IP form of claiming to be localhost. There's no
| > reason for any mail client ever to say "EHLO [127.0.0.1]" except to
| > cause a MTA to generate a confusing Received header.
|
| Right.
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul Schmehl-2
In reply to this post by Paul van der Vlis
--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
<[hidden email]> wrote:

> Op 22-10-16 om 04:32 schreef Bill Cole:
>> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:
>
>>> ----
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>>> [87.92.55.206])
>>>         (Authenticated sender: [hidden email])
>>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> ----
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
>> proceeded to authenticate as the user whose name you've replaced with
>> [hidden email].
>>
>> As a stopgap, you could add a directive like this to
>> smtpd_helo_restrictions:
>>
>>    check_helo_access pcre:/etc/postfix/helo_checks
>>
>> And in that helo_checks file;
>>
>>     /127\.0\.0\.1/    REJECT you are not me
>
> Thanks, a great idea to have standard in most cases.

I would make one suggestion.  I would reject the attempt silently.  No
sense in tipping off the spammer to what he needs to do to work around it.
Just use REJECT with no explanation.

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl ([hidden email])
Independent Researcher
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

/dev/rob0
In reply to this post by Paul van der Vlis
On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

> Op 22-10-16 om 13:41 schreef Wietse Venema:
> > Bill Cole:
> >>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> >>> [87.92.55.206])
> >>>         (Authenticated sender: [hidden email])
> >>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> >>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> >>> ----
> >>> As would my server sent it to my server...
> >>
> >> Not exactly. That Received header indicates that the machine
> >> T 87.92.55.206 which is actually named
> >> 87-92-55-206.bb.dnainternet.fi introduced itself with "EHLO
> >> [127.0.0.1]" on an encrypted session and proceeded to
> >> authenticate as the user whose name you've replaced with
> >> [hidden email].
> >
> > Thanks, I missed that.
>
> Is the conclusion now, that Postfix is relaying here?

The only actual conclusion is that you have failed to put forth the
necessary information, as Bill [I think] pointed you to the
http://www.postfix.org/DEBUG_README.html#mail link.

What appears to be most likely, if we were given adequate
information, is that an account has been compromised, and a botnet
uses those credentials to relay spam through you.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

SV: Open relay

Sebastian Nielsen
In reply to this post by Paul Schmehl-2
Or even better: Accept the mail, but toss it away. Eg use, DISCARD instead.

-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För Paul Schmehl
Skickat: den 22 oktober 2016 18:20
Till: Paul van der Vlis <[hidden email]>; [hidden email]
Ämne: Re: Open relay

--On October 22, 2016 at 12:16:33 PM +0200 Paul van der Vlis
<[hidden email]> wrote:

> Op 22-10-16 om 04:32 schreef Bill Cole:
>> On 21 Oct 2016, at 16:15, Paul van der Vlis wrote:
>
>>> ----
>>> Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
>>> [87.92.55.206])
>>>         (Authenticated sender: [hidden email])
>>>         by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
>>>         Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
>>> ----
>>> As would my server sent it to my server...
>>
>> Not exactly. That Received header indicates that the machine at
>> 87.92.55.206 which is actually named 87-92-55-206.bb.dnainternet.fi
>> introduced itself with "EHLO [127.0.0.1]" on an encrypted session and
>> proceeded to authenticate as the user whose name you've replaced with
>> [hidden email].
>>
>> As a stopgap, you could add a directive like this to
>> smtpd_helo_restrictions:
>>
>>    check_helo_access pcre:/etc/postfix/helo_checks
>>
>> And in that helo_checks file;
>>
>>     /127\.0\.0\.1/    REJECT you are not me
>
> Thanks, a great idea to have standard in most cases.
I would make one suggestion.  I would reject the attempt silently.  No sense
in tipping off the spammer to what he needs to do to work around it.
Just use REJECT with no explanation.

"The man who never looks into a newspaper is better informed than he who
reads them, inasmuch as he who knows nothing is nearer the truth than he
whose mind is filled with falsehoods and errors."  -  Thomas Jefferson

Paul Schmehl ([hidden email])
Independent Researcher


smime.p7s (8K) Download Attachment
123