Open relay

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

Re: Open relay

/dev/rob0
On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:

> --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:
> >>    /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 point of rejection messages is in case a human comes up against
it (and even this one, it could happen.)  You need to let a novice
postmaster know what s/he has misconfigured.

There is zero evidence over 2 decades that botnet spammers even have
the capability to receive and parse their rejection messages, much
less the interest in doing so.
--
  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: SV: Open relay

/dev/rob0
In reply to this post by Sebastian Nielsen
On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
> Or even better: Accept the mail, but toss it away. Eg use, DISCARD
> instead.

Oh, ugh, definitely not.  This is terrible advice.
--
  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: SV: Open relay

Sebastian Nielsen
Yeah, in this situation it might be a bad idea as the problem is not really
HELO 127.0.0.1, but rather that a account is compromised.
I would rather limit the relay so authorized accounts can only be used from
authorized IP adresses, like the local branch.

-----Ursprungligt meddelande-----
Från: [hidden email]
[mailto:[hidden email]] För /dev/rob0
Skickat: den 22 oktober 2016 18:29
Till: [hidden email]
Ämne: Re: SV: Open relay

On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
> Or even better: Accept the mail, but toss it away. Eg use, DISCARD
> instead.

Oh, ugh, definitely not.  This is terrible advice.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul Schmehl-2
In reply to this post by /dev/rob0
--On October 22, 2016 at 11:27:56 AM -0500 "/dev/rob0" <[hidden email]>
wrote:

> On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:
>> --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:
>> >>    /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 point of rejection messages is in case a human comes up against
> it (and even this one, it could happen.)  You need to let a novice
> postmaster know what s/he has misconfigured.
>
> There is zero evidence over 2 decades that botnet spammers even have
> the capability to receive and parse their rejection messages, much
> less the interest in doing so.

I wonder how you explain, over the past two decades, how spammers keep
adjusting their tactics to get around the defenses that are put up to foil
them.  Precognition?

We've been fighting this battle for, as you say, the past two decades, and
the spammers have been successful at getting around our defenses.  I could
list the many things we've done that they've overcome, but why bother?
You're clearly experienced enough to know what they are.

"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

Paul van der Vlis
In reply to this post by /dev/rob0
Op 22-10-16 om 18:23 schreef /dev/rob0:
> On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

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

Thanks, I did oversee that hint and I will study the page.
At the moment no spam is coming in anymore.

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

Strange is, that the "Authenticated sender" account does not excist.
What does exist is an account for that mailadres and another account for
the part
for the "@", but I've changed the password of both and the spam did not
stop.

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: permit after all

Bill Cole-3
In reply to this post by /dev/rob0
On 22 Oct 2016, at 8:54, /dev/rob0 wrote:

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

Not exactly. In principle one can end a restriction list with 'reject'
if all desired 'permit' cases are covered by previous directives. In
smtpd_recipient_restrictions this implies a check_recipient_access
directive that permits local recipients (obviously AFTER anti-spam
restrictions). And of course, many master.cf files include a service
defined like this:

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

Re: permit after all

L.P.H. van Belle
In reply to this post by /dev/rob0
paul, check if there are messages still in queue. 

i had a comprimized account also and same as you it didnt stop. it did after clearing up the queue list.

the user in question has used its email and pass om a website which was  omprimized, at least thats what i think. 

i my case i allow my users only from specific countries for smtp, 
limited by firewalling. (xtables geoip)

i also use zpush (active sync) through webserver, for mobile devices for other countrie support.

not a fix, but help avoiding this problem is abuse.

and check if you landed on black lists. 

greetz 

louis

Op 22 okt. 2016 om 19:31 heeft Bill Cole <[hidden email]> het volgende geschreven:

On 22 Oct 2016, at 8:54, /dev/rob0 wrote:

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.

Not exactly. In principle one can end a restriction list with 'reject'
if all desired 'permit' cases are covered by previous directives. In
smtpd_recipient_restrictions this implies a check_recipient_access
directive that permits local recipients (obviously AFTER anti-spam
restrictions). And of course, many master.cf files include a service
defined like this:

submission inet  n       -       n       -       -       smtpd
    -o syslog_name=postfix/submit
    -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
    -o milter_macro_daemon_name=ORIGINATING

Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Bill Cole-3
In reply to this post by Paul Schmehl-2
On 22 Oct 2016, at 12:19, Paul Schmehl wrote:

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

That's a nice hypothesis but it doesn't seem to play out in reality.
I've been emitting specific (and yes, sometimes snarky) rejection
messages on a variety of systems for all sorts of access rules, in part
so I can keep track of what rules are being hit easily. I have never
seen any hint that spammers behaving in grossly fraudulent ways (like
EHLO arguments that claim to be the server they're talking to)
substantively change their behavior in response to those messages. Keep
in mind that essentially ANY idiosyncratically wrong EHLO argument seen
only from spammers has been configured intentionally by someone who has
no idea how cheap, simple, and reliable it is to reject spam on that
basis. These are cognitively impaired spammers, not smart ones. The
smart ones try very hard to look very normal and legitimate, not to
stand out as something starkly different from any legitimate mail.
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul Schmehl-2
--On October 22, 2016 at 1:51:12 PM -0400 Bill Cole
<[hidden email]> wrote:

> On 22 Oct 2016, at 12:19, Paul Schmehl wrote:
>
>> 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.
>
> That's a nice hypothesis but it doesn't seem to play out in reality. I've
> been emitting specific (and yes, sometimes snarky) rejection messages on
> a variety of systems for all sorts of access rules, in part so I can keep
> track of what rules are being hit easily. I have never seen any hint that
> spammers behaving in grossly fraudulent ways (like EHLO arguments that
> claim to be the server they're talking to) substantively change their
> behavior in response to those messages. Keep in mind that essentially ANY
> idiosyncratically wrong EHLO argument seen only from spammers has been
> configured intentionally by someone who has no idea how cheap, simple,
> and reliable it is to reject spam on that basis. These are cognitively
> impaired spammers, not smart ones. The smart ones try very hard to look
> very normal and legitimate, not to stand out as something starkly
> different from any legitimate mail.
>

And you don't think this spammer fits into the latter category?  He's
clearly doing something very clever that is not the usual brute force
cram-it-down-your-throat spam run.

"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

allenc
In reply to this post by /dev/rob0

On 22/10/16 17:27, /dev/rob0 wrote:
> On Sat, Oct 22, 2016 at 11:19:36AM -0500, Paul Schmehl wrote:
>> --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:
>>>>    /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.

I have also had  HELO statements announcing:-
my own public-facing ip address (from the outside of my NAT firewall),
spurious servers using my own domain name;
example.com (!);
and possibly more controversially, variations on localhost.

*ALL* my own machines are accepted by permit_mynetworks,  so anything
else purporting to belong to me is a demonstrable lie.

All the above are also rejected by my helo_access list.

Allen C






> The point of rejection messages is in case a human comes up against
> it (and even this one, it could happen.)  You need to let a novice
> postmaster know what s/he has misconfigured.
>
> There is zero evidence over 2 decades that botnet spammers even have
> the capability to receive and parse their rejection messages, much
> less the interest in doing so.

Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Noel Jones-2
In reply to this post by Paul Schmehl-2
On 10/22/2016 1:30 PM, Paul Schmehl wrote:

> He's clearly doing something very clever that is not the usual brute
> force cram-it-down-your-throat spam run.

No evidence has been presented that this is anything other than the
usual leaked-credentials account hijacking.  Any confusion is due to
a lack of information.

Postfix logs the sasl username presented by the spammer. Hopefully
the sasl backend logging will show why this name is unexpectedly
accepted, and is almost certainly not a bug or exploit.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Bill Cole-3
In reply to this post by Paul Schmehl-2
On 22 Oct 2016, at 12:39, Paul Schmehl wrote:

> I wonder how you explain, over the past two decades, how spammers keep
> adjusting their tactics to get around the defenses that are put up to
> foil them.

This isn't demonstrably true, although it can look that way. The tactics
that actually work to get spam delivered have changed, even without most
individual spammers substantially changing their own tactics.

It has been about 20 years since a bogus local-ish EHLO did anything
good for deliverability at a measurable number of sites and over 15
since people started openly rejecting mail on that basis, yet yesterday
and essentially every day my small personal server says some variation
of "you are not me" to a couple dozen unique bots and it would be
hundreds if I didn't have postscreen dropping PREGREET bot connections.
Oddly, that's not very scale-dependent. On a system handling about 100x
as much legit mail for 10x as many domains, there's only about twice as
many bots trying tired old tricks that haven't worked in a long time. On
both systems, that rate of clueless spam effort has remained stable
(although noisy) for many years. Meanwhile, "snowshoe" spam has exploded
over the past decade, but it isn't just a different tactic for getting
delivered from the botspam, it's a completely different class of spam in
content and strategy AND it is different spammers.
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Bill Cole-3
In reply to this post by Paul Schmehl-2
On 22 Oct 2016, at 14:30, Paul Schmehl wrote:

> --On October 22, 2016 at 1:51:12 PM -0400 Bill Cole
> <[hidden email]> wrote:
>
>> On 22 Oct 2016, at 12:19, Paul Schmehl wrote:
>>
>>> 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.
>>
>> That's a nice hypothesis but it doesn't seem to play out in reality.
>> I've
>> been emitting specific (and yes, sometimes snarky) rejection messages
>> on
>> a variety of systems for all sorts of access rules, in part so I can
>> keep
>> track of what rules are being hit easily. I have never seen any hint
>> that
>> spammers behaving in grossly fraudulent ways (like EHLO arguments
>> that
>> claim to be the server they're talking to) substantively change their
>> behavior in response to those messages. Keep in mind that essentially
>> ANY
>> idiosyncratically wrong EHLO argument seen only from spammers has
>> been
>> configured intentionally by someone who has no idea how cheap,
>> simple,
>> and reliable it is to reject spam on that basis. These are
>> cognitively
>> impaired spammers, not smart ones. The smart ones try very hard to
>> look
>> very normal and legitimate, not to stand out as something starkly
>> different from any legitimate mail.
>>
>
> And you don't think this spammer fits into the latter category?  He's
> clearly doing something very clever that is not the usual brute force
> cram-it-down-your-throat spam run.

Not so much. Spambots have been doing authenticated port 587 submission
for a dozen years. It's easier to do in volume today because there have
been huge sever-side compromises of auth credentials and uncountable
hordes of PC's infected with information-thief malware of one sort or
another. Finding a working account & password is done by brute force
now, with bots testing known pairs against a server until one matches.
For example, last week I had a bot test auth for a dozen different
"tagged" addresses against my IMAP, POP3, and submission servers on 2
IPs (primary and secondary MX records, both actually on the same host)
within less than 2 minutes. All of those addresses were given in
supposed confidence to exactly one commercial entity each, most of whom
have had publicized breaches  in recent years. They've automated
targeted account compromise.

So sure: you could put an unexpressive unique ID into each REJECT rule
instead of a clear(ish) explanation. They would make their catches
trackable in logs but keep the spammer from knowing exactly why a
rejection happened. It's just not clear that it matters. They are doing
something pointless that makes them easy to catch and they have
automated every aspect of their spamming.
Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Paul van der Vlis
In reply to this post by /dev/rob0
Op 22-10-16 om 18:23 schreef /dev/rob0:
> On Sat, Oct 22, 2016 at 04:15:41PM +0200, Paul van der Vlis wrote:

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

The problem is that somebody did send spam using port 587 with a not
excisting username, and I am interested how that is possible.

sigmund:/var/log# postconf -Mf
smtp       inet  n       -       -       -       -       smtpd -v
26         inet  n       -       -       -       -       smtpd
465        inet  n       -       -       -       -       smtpd
submission inet  n       -       -       -       -       smtpd
pickup     fifo  n       -       -       60      1       pickup
cleanup    unix  n       -       -       -       0       cleanup
qmgr       fifo  n       -       -       300     1       qmgr
rewrite    unix  -       -       -       -       -       trivial-rewrite
bounce     unix  -       -       -       -       0       bounce
defer      unix  -       -       -       -       0       bounce
trace      unix  -       -       -       -       0       bounce
verify     unix  -       -       -       -       1       verify
flush      unix  n       -       -       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
smtp       unix  -       -       -       -       -       smtp
relay      unix  -       -       -       -       -       smtp
showq      unix  n       -       -       -       -       showq
error      unix  -       -       -       -       -       error
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       n       -       -       lmtp
anvil      unix  -       -       n       -       1       anvil
maildrop   unix  -       n       n       -       -       pipe flags=DRhu
    user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp       unix  -       n       n       -       -       pipe flags=Fqhu
    user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail     unix  -       n       n       -       -       pipe flags=F
user=ftn
    argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp      unix  -       n       n       -       -       pipe flags=Fq.
    user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
scalemail-backend unix - n       n       -       2       pipe flags=R
    user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
    ${user} ${extension}
amavis     unix  -       -       n       -       2       smtp
    -o smtp_data_done_timeout=1200
    -o disable_dns_lookups=yes
127.0.0.1:10025 inet n   -       n       -       -       smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
shadelist  unix  -       n       n       -       -       spawn user=nobody
    argv=/usr/bin/perl /usr/local/bin/shadelist.pl -w
nlwhitelist.dnsbl.bit.nl
tlsmgr     unix  -       -       -       1000?   1       tlsmgr
scache     unix  -       -       -       -       1       scache
discard    unix  -       -       -       -       -       discard
retry      unix  -       -       -       -       -       error

-------------------------------------------------------------------------------------

sigmund:/var/log# saslfinger -s
saslfinger - postfix Cyrus sasl configuration zo okt 23 00:09:27 CEST 2016
version: 1.0.4
mode: server-side SMTP AUTH

-- basics --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
Postfix: 2.11.3
System: Debian GNU/Linux 8 \n \l

-- smtpd is linked to --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
        libsasl2.so.2 => /usr/lib/i386-linux-gnu/libsasl2.so.2 (0xb73d1000)

-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
smtpd_tls_loglevel = 1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_use_tls = yes
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom


-- listing of /usr/lib/sasl2 --
totaal 52
drwxr-xr-x  2 root root  4096 okt 20 02:47 .
drwxr-xr-x 88 root root 40960 okt 20 06:40 ..
-rw-r--r--  1 root root     4 okt 20 03:13 berkeley_db.active
-rw-r--r--  1 root root     4 sep 25  2015 berkeley_db.txt

-- listing of /etc/postfix/sasl --
totaal 12
drwxr-xr-x 2 root root 4096 jul 22  2009 .
drwxr-xr-x 4 root root 4096 okt 22 14:49 ..
-rw-r--r-- 1 root root   49 jul 22  2009 smtpd.conf


postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom


-- content of /etc/postfix/sasl/smtpd.conf --
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

-- content of /etc/postfix/sasl/smtpd.conf --
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN


postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
-- active services in /etc/postfix/master.cf --
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
postconf: warning: /etc/postfix/main.cf: unused parameter:
mailman_destination_recipient_limit=1
postconf: warning: /etc/postfix/main.cf: unused parameter:
tls_daemon_random_source=dev:/dev/urandom
smtp      inet  n       -       -       -       -       smtpd -v
26        inet  n       -       -       -       -       smtpd
465       inet  n       -       -       -       -       smtpd
submission inet n      -       -       -       -       smtpd
pickup    fifo  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      fifo  n       -       -       300     1       qmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       -       -       -       smtp
relay     unix  -       -       -       -       -       smtp
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender
$recipient
scalemail-backend unix - n n - 2 pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extension}


amavis unix - - n - 2 smtp
        -o smtp_data_done_timeout=1200
        -o disable_dns_lookups=yes
127.0.0.1:10025 inet n - n - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes


shadelist  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/bin/shadelist.pl -w
nlwhitelist.dnsbl.bit.nl

tlsmgr    unix  -       -       -       1000?   1       tlsmgr
scache    unix  -       -       -       -       1       scache
discard   unix  -       -       -       -       -       discard
retry     unix  -       -       -       -       -       error

-- mechanisms on localhost --

-- end of saslfinger output --

-----------------------------------------------------------------------

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

-----------------------------------------------------------------------

One of the spammer IP's in action, firewall logging:

Oct 21 20:03:37 sigmund kernel: [143870.420796] FW:IN=eth0 OUT=
MAC=52:54:00:0e:95:f1:08:81:f4:8d:d8:89:08:00 SRC=185.81.81.172
DST=91.198.178.50 LEN=5
2 TOS=0x00 PREC=0x00 TTL=56 ID=37620 DF PROTO=TCP SPT=44816 DPT=587
WINDOW=5816 RES=0x00 ACK URGP=0

------------------------------------------------------------------------

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 Noel Jones-2
Op 22-10-16 om 21:12 schreef Noel Jones:
> On 10/22/2016 1:30 PM, Paul Schmehl wrote:
>
>> He's clearly doing something very clever that is not the usual brute
>> force cram-it-down-your-throat spam run.
>
> No evidence has been presented that this is anything other than the
> usual leaked-credentials account hijacking.  Any confusion is due to
> a lack of information.

The "Authenticated sender" does not excist as a user account. It is an
correct e-mail address, but not an user account with what you can
authenticate.

> Postfix logs the sasl username presented by the spammer. Hopefully
> the sasl backend logging will show why this name is unexpectedly
> accepted, and is almost certainly not a bug or exploit.

I will look for a sasl backend logging method.

The spammers are still trying. Every time from another IP, so I cannot
log on a specific IP.

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

Noel Jones-2
On 10/22/2016 5:36 PM, Paul van der Vlis wrote:
> The "Authenticated sender" does not excist as a user account. It is an
> correct e-mail address, but not an user account with what you can
> authenticate.

And yet that's the username postfix provides to the backend.  The
only mystery here is why the backend accepts it. This is almost
certainly due to some unintentional configuration rather than a bug
or exploit.

You should concentrate your efforts on the backend. All you'll get
out of postfix is that some username and password was passed to the
backend, and the backend replied they were valid.

Further debugging in postfix is pointless.


  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: permit after all

Paul van der Vlis
In reply to this post by L.P.H. van Belle
Op 22-10-16 om 19:49 schreef L.P.H. van Belle:
> paul, check if there are messages still in queue.

I've cleaned the queue every minute using crontab, removing the mail
from that specific recipient.

> i had a comprimized account also and same as you it didnt stop. it did
> after clearing up the queue list.
>
> the user in question has used its email and pass om a website which was
>  omprimized, at least thats what i think.

No, I know the user. He is working for me.

And the "authenticated username" does not excist on the server as a user
what can authenticate. Only as an e-mail address.

> i my case i allow my users only from specific countries for smtp,
> limited by firewalling. (xtables geoip)

My customers go in holliday or work in other countries.

> i also use zpush (active sync) through webserver, for mobile devices for
> other countrie support.
>
> not a fix, but help avoiding this problem is abuse.
>
> and check if you landed on black lists.

I am. But I am not sure I can delist, because I don't know how they did
it. Maybe they start again.

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

Bill Cole-3
In reply to this post by Noel Jones-2
On 22 Oct 2016, at 18:50, Noel Jones wrote:

> On 10/22/2016 5:36 PM, Paul van der Vlis wrote:
>> The "Authenticated sender" does not excist as a user account. It is
>> an
>> correct e-mail address, but not an user account with what you can
>> authenticate.
>
> And yet that's the username postfix provides to the backend.  The
> only mystery here is why the backend accepts it. This is almost
> certainly due to some unintentional configuration rather than a bug
> or exploit.
>
> You should concentrate your efforts on the backend. All you'll get
> out of postfix is that some username and password was passed to the
> backend, and the backend replied they were valid.

This makes me ponder a question:

What does Postfix show in the Received header if authentication is
attempted and fails but the sender keeps going and is is not rejected by
a later restriction?

> Further debugging in postfix is pointless.

If the answer to the above question is "it records the attempted
authentication identity" then this is not so. We already know that the
submission service is grossly misconfigured, as it has no overrides of
any settings for the port 25 smtpd.

The OP has ignored repeated requests for postconf -nf output and
comprehensive relevant log extracts but any logging is likely to be
unclear in any case because of his failure to configure submission
wisely. We KNOW submission is using an inherently insecure config and he
asserts that this is coming though the submission service. It couldn't
hurt to fix the glaring problem with submission config, since it
provides a theoretical path for mail to be relayed without even an
attempt to authenticate: just fail to be rejected by his complex
smtp_relay_restrictions.  That list ends in 'permit' and includes a very
suspicious (especially for submission) 'check_sender_access
hash:/etc/postfix/whitelist' which presumably has 'permit' entries for
sender addresses which are not subject to any sort of authentication.

Reply | Threaded
Open this post in threaded view
|

Re: Open relay

Wietse Venema
Bill Cole:
> What does Postfix show in the Received header if authentication is
> attempted and fails but the sender keeps going and is is not rejected by
> a later restriction?

There is no username unless the user was logged in.

    /* RFC 4954 Section 6. */
    smtpd_chat_reply(state, "235 2.7.0 Authentication successful");
    if ((sasl_username = xsasl_server_get_username(state->sasl_server)) == 0)
        msg_panic("cannot look up the authenticated SASL username");
    state->sasl_username = mystrdup(sasl_username);
    printable(state->sasl_username, '?');
    state->sasl_method = mystrdup(sasl_method);
    printable(state->sasl_method, '?');

Either this, or an NGINX proxy sent the logged-in username with XCLIENT.

Note that Postfix does not look inside SASL protocol messages. It
has no idea how the protocols work and gets the username from the
Cyrus SASL library or from a Dovecot authentication server.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: SV: Open relay

John Allen
In reply to this post by /dev/rob0
Why? If it smells bad, toss it in the garbage. We work on this basis.

We are thinking about the idea of approved senders, anybody the we send to
is automatically add to an approved sender database. If you want to send to
us send an email to the PM, if you are approved you get added to the list.
I have been playing with the idea that entries would be good for n months
from of the last message sent by us.
The usual addresses (postmaster, admin...) accept all email.



On October 22, 2016 12:30:02 PM /dev/rob0 <[hidden email]> wrote:

> On Sat, Oct 22, 2016 at 06:23:30PM +0200, Sebastian Nielsen wrote:
>> Or even better: Accept the mail, but toss it away. Eg use, DISCARD
>> instead.
>
> Oh, ugh, definitely not.  This is terrible advice.
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:


123