configuration postscreen

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

configuration postscreen

Claus R. Wickinghoff
Hello,

a few days ago I discovered postscreen and I started to use it for my
private e-mail.

Now I run into an issue, for which I didn't find anything useful on the
Internet. I'll try to explain it with a log excerpt:

root@mole:/etc/postfix# grep 45.146.203.135 /var/log/syslog

Dec 13 09:06:21 mole postfix/postscreen[1729]: CONNECT from
[45.146.203.135]:60433 to [83.223.64.89]:25
Dec 13 09:06:22 mole postfix/dnsblog[1732]: addr 45.146.203.135 listed
by domain b.barracudacentral.org as 127.0.0.2

The system 45.146.203.135 connects and from all configured blacklists I
only got 1 hit. As I've set up a treshold this hit is not sufficient for
blocking.

Dec 13 09:06:27 mole postfix/postscreen[1729]: NOQUEUE: reject: RCPT
from [45.146.203.135]:60433: 450 4.3.2 Service currently unavailable;
from=<[hidden email]>, to=<xxx>, proto=ESMTP,
helo=<tremble.mgooir.com>
Dec 13 09:06:27 mole postfix/postscreen[1729]: PASS NEW
[45.146.203.135]:60433
Dec 13 09:06:27 mole postfix/postscreen[1729]: DISCONNECT
[45.146.203.135]:60433

I've also activated the after-220-checks so it is rejected with a 450,
but "PASS NEW" tells me, the ip went into the cache (of proper systems).

Dec 13 09:16:27 mole postfix/postscreen[1771]: CONNECT from
[45.146.203.135]:49121 to [83.223.64.89]:25
Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD
[45.146.203.135]:49121

Now it reconnects and with the cache entry it's calssified as "PASS OLD"
and got redirected to smtpd...

Dec 13 09:16:27 mole postfix/smtpd[1839]: connect from
tremble.sckenz.com[45.146.203.135]
Dec 13 09:16:27 mole postfix/smtpd[1839]: 369B040088:
client=tremble.sckenz.com[45.146.203.135]
Dec 13 09:16:27 mole postfix/cleanup[1843]: 369B040088: info: header
Subject:
=?UTF-8?Q?Es_kann_bei_schlechten_Sichtverh=C3=A4ltnissen_zur_Trag=C3=B6die_f=C3=BChren_-_eine_Sehhilfe_L=C3=B6sung?=
from tremble.sckenz.com[45.146.203.135];
from=<[hidden email]> to=<cxxx> proto=ESMTP
helo=<tremble.mgooir.com>
Dec 13 09:16:27 mole postfix/smtpd[1839]: disconnect from
tremble.sckenz.com[45.146.203.135] ehlo=1 mail=1 rcpt=1 data=1 quit=1
commands=5

...and delivers its spam. (The German subject is obviously spammy.)

If I check some blacklists now, I got hits:

Blacklist Reason TTL ResponseTime
  LISTED Abusix Mail Intelligence Blacklist 45.146.203.135 was listed
60 16 Ignore
  LISTED Anonmails DNSBL 45.146.203.135 was listed   1800 203 Ignore
  LISTED BARRACUDA 45.146.203.135 was listed   900 31 Ignore
  LISTED BLOCKLIST.DE 45.146.203.135 was listed   2100 0 Ignore
  LISTED ivmSIP 45.146.203.135 was listed   2100 0 Ignore
  LISTED ivmSIP24 45.146.203.135 was listed   2100 0 Ignore
  LISTED MAILSPIKE BL 45.146.203.135 was listed   60 141 Ignore
  LISTED NIXSPAM 45.146.203.135 was listed   60 205 Ignore
  LISTED Spamhaus ZEN 45.146.203.135 was listed   60 0 Ignore
  LISTED TRUNCATE 45.146.203.135 was listed   7200 47 Ignore
  LISTED UCEPROTECTL2 45.146.203.135 was listed   2100 0 Ignore
  LISTED UCEPROTECTL3 45.146.203.135 was listed   2100 0 Ignore


The problem is: The system starts delivering spam and in the moment it
connects to my server for the first time, only one blacklist has it on
the radar. But due to the cache (PASS OLD) it can now deliver as much
spam as it likes to my server.

With the actual state of blacklisting it would be rejected. Nixspam only
would reach the threshold.


Has anybody her dealt with the same issue already?

I found these two configuration options (and decided to set these values):

postscreen_cache_cleanup_interval = 4h
postscreen_dnsbl_max_ttl = 1h

cache_cleanup should expire an entry from cache. Does anybody know, when
the interval starts? With adding to the cache or with the last access to
the address in cache?

dnsbl_max_ttl is probably the time, when the blacklists will be asked
again? Regardless of an existing cache entry? Is there any proposal for
a good working value? Something with a couple of minutes would cause
lots of dns queries?


What about a code change, that systems getting a score below
postscreen_dnsbl_threshold but between two new parameters
postscreen_cache_min_unreliable and postscreen_cache_max_unreliable are
marked in the cache as not really trustworthy? So for systems with a
score in between this range the pre-220-checks are performed (especially
blacklist queries) but after-220-checks are skipped (so those can be
redirected to smtpd). With the min value also systems in a whitelist
would be skipped from the tests, too.

That would probably solve my issue described above. Or is this something
of no practical relevance? And can be fixed with some other settings? :-)


Groetjes
    Claus



--
Claus R. Wickinghoff, Dipl.-Ing.
using Linux since 1994 and still happy... :-)
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Wietse Venema
Claus R. Wickinghoff:
> Dec 13 09:06:27 mole postfix/postscreen[1729]: PASS NEW
> [45.146.203.135]:60433
[client gets 450 from after-220 tests]
> Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD
> [45.146.203.135]:49121
...
> The problem is: The system starts delivering spam and in the moment it
> connects to my server for the first time, only one blacklist has it on
> the radar. But due to the cache (PASS OLD) it can now deliver as much
> spam as it likes to my server.

Obviously, postscreen cannot predict the future, that is why all
its cached results have a configurable expiration time.

postscreen_bare_newline_ttl = 30d
postscreen_dnsbl_max_ttl = ${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
postscreen_dnsbl_min_ttl = 60s
postscreen_greet_ttl = 1d
postscreen_non_smtp_command_ttl = 30d
postscreen_pipelining_ttl = 30d

You could try use some combination of more postscreen DNSBLs and a
shorter postscreen_dnsbl_max_ttl.  BTW many DNSBLs specify a shorter
TTL than 1H and postscreen will use their TTL instead (but
postscreen_dnsbl_min_ttl takes precedence).

None of this would "fix" your "problem" if a client reconnects in
less time than the DNSBL TTL. That is the whole point of postscreen:
it does not HAVE to stop all spambots, just most of them. It is
perfectly OK to handle the remaining spam with content-based methods.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Viktor Dukhovni
In reply to this post by Claus R. Wickinghoff
On Fri, Dec 13, 2019 at 11:03:49AM +0100, Claus R. Wickinghoff wrote:

> Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD [45.146.203.135]:49121
>
> Now it reconnects and with the cache entry it's calssified as "PASS OLD"
> and got redirected to smtpd...
>
> Dec 13 09:16:27 mole postfix/smtpd[1839]: 369B040088: client=tremble.sckenz.com[45.146.203.135]
> tremble.sckenz.com[45.146.203.135] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>
> ...and delivers its spam.
>
> If I check some blacklists now, I got hits:
>
>   LISTED Spamhaus ZEN 45.146.203.135 was listed   60 0 Ignore

My advice would be to enable zen.spamhaus.org (or similar mainstream low
FP rate RBL) on a per-message basis in smtpd(8):

    smtpd_client_restrictions =
        permit_sasl_authenticated,
        reject_rbl_client zen.spamhaus.org

The purpose of postscreen is to try to keep botnets from consuming all
your SMTP connection slots.  You should have anti-spam measures in place
for the clients that get through.

I would avoid unduly short postscreen cache times, that can lead to
legitimate clients not getting through at all.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Matus UHLAR - fantomas
>On Fri, Dec 13, 2019 at 11:03:49AM +0100, Claus R. Wickinghoff wrote:
>
>> Dec 13 09:16:27 mole postfix/postscreen[1771]: PASS OLD [45.146.203.135]:49121
>>
>> Now it reconnects and with the cache entry it's calssified as "PASS OLD"
>> and got redirected to smtpd...
>>
>> Dec 13 09:16:27 mole postfix/smtpd[1839]: 369B040088: client=tremble.sckenz.com[45.146.203.135]
>> tremble.sckenz.com[45.146.203.135] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
>>
>> ...and delivers its spam.
>>
>> If I check some blacklists now, I got hits:
>>
>>   LISTED Spamhaus ZEN 45.146.203.135 was listed   60 0 Ignore

On 13.12.19 11:30, Viktor Dukhovni wrote:

>My advice would be to enable zen.spamhaus.org (or similar mainstream low
>FP rate RBL) on a per-message basis in smtpd(8):
>
>    smtpd_client_restrictions =
>        permit_sasl_authenticated,
>        reject_rbl_client zen.spamhaus.org
>
>The purpose of postscreen is to try to keep botnets from consuming all
>your SMTP connection slots.  You should have anti-spam measures in place
>for the clients that get through.
>
>I would avoid unduly short postscreen cache times, that can lead to
>legitimate clients not getting through at all.

I'm not sure if that would help. Apparently, both postscreen and smtpd will
use the same nameserver for dnsbl lookup, and if it's cached from previous
postscreen lookup, it will probably give the same result.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Viktor Dukhovni
On Fri, Dec 13, 2019 at 05:40:33PM +0100, Matus UHLAR - fantomas wrote:

> >I would avoid unduly short postscreen cache times, that can lead to
> >legitimate clients not getting through at all.
>
> I'm not sure if that would help. Apparently, both postscreen and smtpd will
> use the same nameserver for dnsbl lookup, and if it's cached from previous
> postscreen lookup, it will probably give the same result.

The negative TTLs on SpamHaus RBL replies are not very long:

    zen.spamhaus.org. 10 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1912132118 3600 600 432000 10

presently just 10 seconds.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Matus UHLAR - fantomas
>> >I would avoid unduly short postscreen cache times, that can lead to
>> >legitimate clients not getting through at all.

>On Fri, Dec 13, 2019 at 05:40:33PM +0100, Matus UHLAR - fantomas wrote:
>> I'm not sure if that would help. Apparently, both postscreen and smtpd will
>> use the same nameserver for dnsbl lookup, and if it's cached from previous
>> postscreen lookup, it will probably give the same result.

On 13.12.19 16:19, Viktor Dukhovni wrote:
>The negative TTLs on SpamHaus RBL replies are not very long:
>
>    zen.spamhaus.org. 10 IN SOA need.to.know.only. hostmaster.spamhaus.org. 1912132118 3600 600 432000 10
>
>presently just 10 seconds.

the time difference between postscreen blacklist check and smtpd blacklist
check should be lower than 10 seconds.

yes, with postscreen_dnsbl_min_ttl there's another ~50 seconds where
potscreen passes the IP while smtpd would blacklist it.

However, I consider postscreen's weighed black/whitelisting more safe
than whitelisting/blacklisting at smtpd level

maybe unless there's exactly one whitelist and one blacklist used.


of course, I'm willing to learn if there's something I have missed
--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Wietse Venema
In reply to this post by Claus R. Wickinghoff
Claus R. Wickinghoff:
> So for me it still makes sense to combine postscreen with postgrey, as
> postscreen works mainly on ip addresses (their reputation in fact) while
> postgrey also takes care on sender's and recipient's e-mail addresses.

By design, postscreen does not know the sender or recipient.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Wietse Venema
Wietse Venema:
> Claus R. Wickinghoff:
> > So for me it still makes sense to combine postscreen with postgrey, as
> > postscreen works mainly on ip addresses (their reputation in fact) while
> > postgrey also takes care on sender's and recipient's e-mail addresses.
>
> By design, postscreen does not know the sender or recipient.

In particular, when postscreen allows a remote SMTP client to talk
to a Postfix SMTP server process, it must make that decision before
the remote SMTP client has sent any commands.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: configuration postscreen

Claus R. Wickinghoff
Hi Wietse,

>>> So for me it still makes sense to combine postscreen with postgrey, as
>>> postscreen works mainly on ip addresses (their reputation in fact) while
>>> postgrey also takes care on sender's and recipient's e-mail addresses.
>>
>> By design, postscreen does not know the sender or recipient.
>
> In particular, when postscreen allows a remote SMTP client to talk
> to a Postfix SMTP server process, it must make that decision before
> the remote SMTP client has sent any commands.

Sure.

My point was that a combination of both seem to make sense. And I
brought an example to show it, similar to the situation that I asked a
couple of days ago.

I had another similar situation today, when the other server passed
postscreen and got greylisted in the beginning and then rejected by
postscreen due to blacklist entries. So the dns lifetime in the cache
works, too.

I'm still impressed how much spam you can get rid off just on smtp level.

Groetjes
    Claus