TCP wrappers and Postfix

[Eugene Podshivalov]

Hi all,

Are there any reasons not to have Postfix compiled with TCP wrappers?

Regards,

Eugene

[Viktor Dukhovni]

On Mon, Feb 08, 2021 at 02:17:46AM +0300, Eugene Podshivalov wrote:

> Are there any reasons not to have Postfix compiled with TCP wrappers?

Because that would likely be entirely redundant.  Postfix already has
IP-based access controls (local tables, RBL lookups, postscreen(8), ...
and can also log additional message envelope details before rejecting
connections.

As Wietse is the author of both TCP wrappers and Postfix, if there were
any cause to build TCP wrappers into Postfix, he'd probably have done
it long ago.

--
    Viktor.

[Eugene Podshivalov]

There are a bunch of spiders and spammers nowadays which are knocking the service every hour or so every day. Postfix has a really powerful access control system to protect itself but it becomes a bit hard to read the log file flooded by the connection attempts. I'm currently trying to filter those out by UFW but dynamic addresses make it quite inefficient.

Regards,

Eugene

пн, 8 февр. 2021 г. в 04:01, Viktor Dukhovni <[hidden email]>:

On Mon, Feb 08, 2021 at 02:17:46AM +0300, Eugene Podshivalov wrote:

> Are there any reasons not to have Postfix compiled with TCP wrappers?

Because that would likely be entirely redundant.  Postfix already has
IP-based access controls (local tables, RBL lookups, postscreen(8), ...
and can also log additional message envelope details before rejecting
connections.

As Wietse is the author of both TCP wrappers and Postfix, if there were
any cause to build TCP wrappers into Postfix, he'd probably have done
it long ago.

--
    Viktor.

[Dominic Raferd]

On 08/02/2021 08:04, Eugene Podshivalov wrote:
> There are a bunch of spiders and spammers nowadays which are knocking
> the service every hour or so every day. Postfix has a really powerful
> access control system to protect itself but it becomes a bit hard to
> read the log file flooded by the connection attempts. I'm currently
> trying to filter those out by UFW but dynamic addresses make it quite
> inefficient.

My 2p (I also use ufw but as a last-resort):

Postscreen of course

Fail2ban 0.10+ with its postfix (and recidive) jails

If you run postfix's dnsblog you could remove it to reduce the number of
log entries

If you allow incoming emails by IPv6 you might turn it off

[Eugene Podshivalov]

I'm new to postscreen and it's what I was looking for. Thanks a lot for the answers!

пн, 8 февр. 2021 г. в 11:22, Dominic Raferd <[hidden email]>:

On 08/02/2021 08:04, Eugene Podshivalov wrote:
> There are a bunch of spiders and spammers nowadays which are knocking
> the service every hour or so every day. Postfix has a really powerful
> access control system to protect itself but it becomes a bit hard to
> read the log file flooded by the connection attempts. I'm currently
> trying to filter those out by UFW but dynamic addresses make it quite
> inefficient.

My 2p (I also use ufw but as a last-resort):

Postscreen of course

Fail2ban 0.10+ with its postfix (and recidive) jails

If you run postfix's dnsblog you could remove it to reduce the number of
log entries

If you allow incoming emails by IPv6 you might turn it off

[Eugene Podshivalov]

Have read through the postscreen documentation closely and got it setup and running already, but could not find the three major possibilities provided by the tcp wrappers:

1. block by hostname

2. block clients with unknown hostname

3. block clients with invalid address<->name mapping

The last two produce the major bulk of spambot connections.

Are there any other means to achieve these?

пн, 8 февр. 2021 г. в 12:14, Eugene Podshivalov <[hidden email]>:

I'm new to postscreen and it's what I was looking for. Thanks a lot for the answers!

пн, 8 февр. 2021 г. в 11:22, Dominic Raferd <[hidden email]>:

On 08/02/2021 08:04, Eugene Podshivalov wrote:
> There are a bunch of spiders and spammers nowadays which are knocking
> the service every hour or so every day. Postfix has a really powerful
> access control system to protect itself but it becomes a bit hard to
> read the log file flooded by the connection attempts. I'm currently
> trying to filter those out by UFW but dynamic addresses make it quite
> inefficient.

My 2p (I also use ufw but as a last-resort):

Postscreen of course

Fail2ban 0.10+ with its postfix (and recidive) jails

If you run postfix's dnsblog you could remove it to reduce the number of
log entries

If you allow incoming emails by IPv6 you might turn it off

[Matus UHLAR - fantomas]

On 08.02.21 16:27, Eugene Podshivalov wrote:
>Have read through the postscreen documentation closely and got it setup and
>running already, but could not find the three major possibilities provided
>by the tcp wrappers:
>1. block by hostname
>2. block clients with unknown hostname
>3. block clients with invalid address<->name mapping
>
>The last two produce the major bulk of spambot connections.

>Are there any other means to achieve these?

you can block these at smtpd level.
Postscreen doesn't (and won't) check for reverse hostname.

--
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.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".

[Eugene Podshivalov]

Do you mean with the help of reject_unknown_client_hostname and check_sender_access params?

пн, 8 февр. 2021 г. в 16:37, Matus UHLAR - fantomas <[hidden email]>:

On 08.02.21 16:27, Eugene Podshivalov wrote:
>Have read through the postscreen documentation closely and got it setup and
>running already, but could not find the three major possibilities provided
>by the tcp wrappers:
>1. block by hostname
>2. block clients with unknown hostname
>3. block clients with invalid address<->name mapping
>
>The last two produce the major bulk of spambot connections.

>Are there any other means to achieve these?

you can block these at smtpd level.
Postscreen doesn't (and won't) check for reverse hostname.

--
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.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".

[Wietse Venema]

Eugene Podshivalov:
> Have read through the postscreen documentation closely and got it setup and
> running already, but could not find the three major possibilities provided
> by the tcp wrappers:
> 1. block by hostname
> 2. block clients with unknown hostname
> 3. block clients with invalid address<->name mapping

Those are implemented by http://www.postfix.org/smtpd.8.html

Postscreen does not look up or verify the client hostname.
It is the FIRST line of defense; the more expensive checks
are done in other programs. In increasing order of cost, that's
postscreen, smtpd_mumble_restrictions, header/body_checks, and
content inspection with Milter, smtpd_proxy_filter, or FILTER.

        Wietse

[Eugene Podshivalov]

Thanks for the explanation, Wietse.

Probably the issue is just with the logging levels.

My current configuration already has

smtpd_client_restrictions=reject_unknown_client_hostname

and the log file is flooded with message like this

connect from unknown[ x.x.x.x]
NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 Client host rejected: cannot find your hostname

which makes it hard to analyse.

For comparison, the postscreen_*_action params let you `enforce` reject a delivery attempt and log it, or just 'drop' the connection silently.

Eugene

 

пн, 8 февр. 2021 г. в 19:39, Wietse Venema <[hidden email]>:

Eugene Podshivalov:
> Have read through the postscreen documentation closely and got it setup and
> running already, but could not find the three major possibilities provided
> by the tcp wrappers:
> 1. block by hostname
> 2. block clients with unknown hostname
> 3. block clients with invalid address<->name mapping

Those are implemented by http://www.postfix.org/smtpd.8.html

Postscreen does not look up or verify the client hostname.
It is the FIRST line of defense; the more expensive checks
are done in other programs. In increasing order of cost, that's
postscreen, smtpd_mumble_restrictions, header/body_checks, and
content inspection with Milter, smtpd_proxy_filter, or FILTER.

        Wietse

[Wietse Venema]

Eugene Podshivalov:

> Thanks for the explanation, Wietse.
>
> Probably the issue is just with the logging levels.
> My current configuration already has
>
> > smtpd_client_restrictions=reject_unknown_client_hostname
>
> and the log file is flooded with message like this
>
> > connect from unknown[ x.x.x.x]
> > NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25 Client host
> > rejected: cannot find your hostname
>
> which makes it hard to analyse.
>
> For comparison, the postscreen_*_action params let you `enforce` reject a
> delivery attempt and log it, or just 'drop' the connection silently.

Here is an idea

open a shell window

type: man 1 grep
type: man 1 less

[Noel Jones-2]

On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:

> Thanks for the explanation, Wietse.
>
> Probably the issue is just with the logging levels.
> My current configuration already has
>
>     smtpd_client_restrictions=reject_unknown_client_hostname
>
> and the log file is flooded with message like this
>
>     connect from unknown[ x.x.x.x]
>     NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25
>     Client host rejected: cannot find your hostname

That's a 450 temporary reject, so if it's a (semi-)legit mail server
it will likely try again and again. Bots tend to not come back.

Try changing unknown_client_reject_code=550 to signal a permanent
reject.

Also note that reject_unknown_client_hostname is a very strict test
and is known to reject some legit mail from slightly misconfigured
hosts, sometimes even major providers will fail this test. I'm not
telling you to not use this setting, but be aware that it will
eventually reject something you want.
It's safer to use reject_unknown_reverse_client_hostname.

>
> which makes it hard to analyse.

I fail to see how that makes analysis any harder. If your logs are
for more than a trivial amount of mail use "grep" to find the
interesting bits, and "less" to view. The "interesting bits" will
vary depending on what you're investigating.

Or use a log summary tool such as pflogsumm or one of the others
listed at http://www.postfix.org/addon.html#logfile

Make sure you don't have debug logs turned on, with a -D flag in
master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater
than 1 in main.cf.


>
> For comparison, the postscreen_*_action params let you `enforce`
> reject a delivery attempt and log it, or just 'drop' the connection
> silently.

postscreen's drop action _does_not_ eliminate logging. The
connect/drop/disconnect is always logged. Drop does eliminate
logging of the sender and recipient, which is often useful.

I respectfully suggest you don't waste your valuable time trying to
eliminate logging. Postfix logs what is necessary in order to trace
where mail came from and what happened to it.

If you want to get rid of the logging (not recommended) use a log
filter such as rsyslogd or block the client IP in your firewall, or
use fail2ban to automatically block clients that make too many errors.



   -- Noel Jones

[Eugene Podshivalov]

Thanks, Noel! Your comments are helpful indeed.

пн, 8 февр. 2021 г. в 22:37, Noel Jones <[hidden email]>:

On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
> Thanks for the explanation, Wietse.
>
> Probably the issue is just with the logging levels.
> My current configuration already has
>
>     smtpd_client_restrictions=reject_unknown_client_hostname
>
> and the log file is flooded with message like this
>
>     connect from unknown[ x.x.x.x]
>     NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25
>     Client host rejected: cannot find your hostname

That's a 450 temporary reject, so if it's a (semi-)legit mail server
it will likely try again and again. Bots tend to not come back.

Try changing unknown_client_reject_code=550 to signal a permanent
reject.

Also note that reject_unknown_client_hostname is a very strict test
and is known to reject some legit mail from slightly misconfigured
hosts, sometimes even major providers will fail this test. I'm not
telling you to not use this setting, but be aware that it will
eventually reject something you want.
It's safer to use reject_unknown_reverse_client_hostname.

>
> which makes it hard to analyse.

I fail to see how that makes analysis any harder. If your logs are
for more than a trivial amount of mail use "grep" to find the
interesting bits, and "less" to view. The "interesting bits" will
vary depending on what you're investigating.

Or use a log summary tool such as pflogsumm or one of the others
listed at http://www.postfix.org/addon.html#logfile

Make sure you don't have debug logs turned on, with a -D flag in
master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater
than 1 in main.cf.


>
> For comparison, the postscreen_*_action params let you `enforce`
> reject a delivery attempt and log it, or just 'drop' the connection
> silently.

postscreen's drop action _does_not_ eliminate logging. The
connect/drop/disconnect is always logged. Drop does eliminate
logging of the sender and recipient, which is often useful.

I respectfully suggest you don't waste your valuable time trying to
eliminate logging. Postfix logs what is necessary in order to trace
where mail came from and what happened to it.

If you want to get rid of the logging (not recommended) use a log
filter such as rsyslogd or block the client IP in your firewall, or
use fail2ban to automatically block clients that make too many errors.



   -- Noel Jones

[Eugene Podshivalov]

Is it by chance possible that tcp wrappers will be supported in future at least as an optionally compiled feature?

пн, 8 февр. 2021 г. в 23:00, Eugene Podshivalov <[hidden email]>:

Thanks, Noel! Your comments are helpful indeed.

пн, 8 февр. 2021 г. в 22:37, Noel Jones <[hidden email]>:

On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
> Thanks for the explanation, Wietse.
>
> Probably the issue is just with the logging levels.
> My current configuration already has
>
>     smtpd_client_restrictions=reject_unknown_client_hostname
>
> and the log file is flooded with message like this
>
>     connect from unknown[ x.x.x.x]
>     NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25
>     Client host rejected: cannot find your hostname

That's a 450 temporary reject, so if it's a (semi-)legit mail server
it will likely try again and again. Bots tend to not come back.

Try changing unknown_client_reject_code=550 to signal a permanent
reject.

Also note that reject_unknown_client_hostname is a very strict test
and is known to reject some legit mail from slightly misconfigured
hosts, sometimes even major providers will fail this test. I'm not
telling you to not use this setting, but be aware that it will
eventually reject something you want.
It's safer to use reject_unknown_reverse_client_hostname.

>
> which makes it hard to analyse.

I fail to see how that makes analysis any harder. If your logs are
for more than a trivial amount of mail use "grep" to find the
interesting bits, and "less" to view. The "interesting bits" will
vary depending on what you're investigating.

Or use a log summary tool such as pflogsumm or one of the others
listed at http://www.postfix.org/addon.html#logfile

Make sure you don't have debug logs turned on, with a -D flag in
master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater
than 1 in main.cf.


>
> For comparison, the postscreen_*_action params let you `enforce`
> reject a delivery attempt and log it, or just 'drop' the connection
> silently.

postscreen's drop action _does_not_ eliminate logging. The
connect/drop/disconnect is always logged. Drop does eliminate
logging of the sender and recipient, which is often useful.

I respectfully suggest you don't waste your valuable time trying to
eliminate logging. Postfix logs what is necessary in order to trace
where mail came from and what happened to it.

If you want to get rid of the logging (not recommended) use a log
filter such as rsyslogd or block the client IP in your firewall, or
use fail2ban to automatically block clients that make too many errors.



   -- Noel Jones

[Bob Proulx]

Eugene Podshivalov wrote:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?

One can't say something will never happen.  But why would it be
needed?

As others have said Postfix already supports all of the same feature
set but in better ways.  So why would Postfix want to add something
which does less than what it already does?  Therefore the likelihood
is no because that would not be as good as what is already there.

If you really, really, really, want tcp wrappers support then you
would need to give a good reason why the current features are not
working for you.

Bob

[Eugene Podshivalov]

Generic approach to system administration and access control reconfiguration at runtime (without service reload).

вт, 16 февр. 2021 г. в 01:24, Bob Proulx <[hidden email]>:

Eugene Podshivalov wrote:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?

One can't say something will never happen.  But why would it be
needed?

As others have said Postfix already supports all of the same feature
set but in better ways.  So why would Postfix want to add something
which does less than what it already does?  Therefore the likelihood
is no because that would not be as good as what is already there.

If you really, really, really, want tcp wrappers support then you
would need to give a good reason why the current features are not
working for you.

Bob

[Wietse Venema]

Eugene Podshivalov:
> Is it by chance possible that tcp wrappers will be supported in future at
> least as an optionally compiled feature?

If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
under TCP Wrappers from inetd.

I prefer to spend my limited development cycles on things that
benefit more people.

        Wietse

> ??, 8 ????. 2021 ?. ? 23:00, Eugene Podshivalov <[hidden email]>:
>
> > Thanks, Noel! Your comments are helpful indeed.
> >
> > ??, 8 ????. 2021 ?. ? 22:37, Noel Jones <[hidden email]>:
> >
> >>
> >> On 2/8/2021 11:45 AM, Eugene Podshivalov wrote:
> >> > Thanks for the explanation, Wietse.
> >> >
> >> > Probably the issue is just with the logging levels.
> >> > My current configuration already has
> >> >
> >> >     smtpd_client_restrictions=reject_unknown_client_hostname
> >> >
> >> > and the log file is flooded with message like this
> >> >
> >> >     connect from unknown[ x.x.x.x]
> >> >     NOQUEUE: reject: CONNECT from unknown[ x.x.x.x]: 450 4.7.25
> >> >     Client host rejected: cannot find your hostname
> >>
> >> That's a 450 temporary reject, so if it's a (semi-)legit mail server
> >> it will likely try again and again. Bots tend to not come back.
> >>
> >> Try changing unknown_client_reject_code=550 to signal a permanent
> >> reject.
> >>
> >> Also note that reject_unknown_client_hostname is a very strict test
> >> and is known to reject some legit mail from slightly misconfigured
> >> hosts, sometimes even major providers will fail this test. I'm not
> >> telling you to not use this setting, but be aware that it will
> >> eventually reject something you want.
> >> It's safer to use reject_unknown_reverse_client_hostname.
> >>
> >> >
> >> > which makes it hard to analyse.
> >>
> >> I fail to see how that makes analysis any harder. If your logs are
> >> for more than a trivial amount of mail use "grep" to find the
> >> interesting bits, and "less" to view. The "interesting bits" will
> >> vary depending on what you're investigating.
> >>
> >> Or use a log summary tool such as pflogsumm or one of the others
> >> listed at http://www.postfix.org/addon.html#logfile
> >>
> >> Make sure you don't have debug logs turned on, with a -D flag in
> >> master.cf, or debug_peer_list, or [smtp|smtpd]_tls_loglevel greater
> >> than 1 in main.cf.
> >>
> >>
> >> >
> >> > For comparison, the postscreen_*_action params let you `enforce`
> >> > reject a delivery attempt and log it, or just 'drop' the connection
> >> > silently.
> >>
> >> postscreen's drop action _does_not_ eliminate logging. The
> >> connect/drop/disconnect is always logged. Drop does eliminate
> >> logging of the sender and recipient, which is often useful.
> >>
> >> I respectfully suggest you don't waste your valuable time trying to
> >> eliminate logging. Postfix logs what is necessary in order to trace
> >> where mail came from and what happened to it.
> >>
> >> If you want to get rid of the logging (not recommended) use a log
> >> filter such as rsyslogd or block the client IP in your firewall, or
> >> use fail2ban to automatically block clients that make too many errors.
> >>
> >>
> >>
> >>    -- Noel Jones
> >>
> >

[Viktor Dukhovni]

> On Feb 15, 2021, at 9:03 PM, Wietse Venema <[hidden email]> wrote:
>
>> Is it by chance possible that tcp wrappers will be supported in future at
>> least as an optionally compiled feature?
>
> If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
> under TCP Wrappers from inetd.

Please don't read this as an actual recommendation.

* You lose process reuse, expending one process per connection.
* You lose support for postscreen(8)
* You lose support for TLS
* Some inetd implementations have suboptimal connection rate limits.
* You lose process limits from master.cf.
* There are surely more downsides, ... Don't do this.

--
        Viktor.

[Viktor Dukhovni]

> On Feb 15, 2021, at 8:51 PM, Eugene Podshivalov <[hidden email]> wrote:
>
> Generic approach to system administration and access control reconfiguration at runtime (without service reload).

If your max_idle and max_use are not too high, Postfix does
not need to be "reloaded" to detect changes in main.cf.
Each new smtpd(8) process reads the latest configuration
when it starts up.

The "mynetworks" data can be via an external indexed table,
in which case smtpd(8) will even automatically exit before
accepting a new connection if the table has changed.

You're doggedly solving entirely the wrong problem.  One can
praise the principled perseverance, but it can probably be
better applied elsewhere.

--
        Viktor.

[Wietse Venema]

Viktor Dukhovni:

> > On Feb 15, 2021, at 9:03 PM, Wietse Venema <[hidden email]> wrote:
> >
> >> Is it by chance possible that tcp wrappers will be supported in future at
> >> least as an optionally compiled feature?
> >
> > If you must, you can run "/usr/sbin/sendmail -bs" as user "postfix"
> > under TCP Wrappers from inetd.
>
> Please don't read this as an actual recommendation.
>
> * You lose process reuse, expending one process per connection.
> * You lose support for postscreen(8)
> * You lose support for TLS

I just verified that TLS works when running "sendmail -bs" as user
'postfix' from inetd. But I agree that this mode of operation is
suitable only for extraordinary cases.

        Wietse

> * Some inetd implementations have suboptimal connection rate limits.
> * You lose process limits from master.cf.
> * There are surely more downsides, ... Don't do this.
>
> --
> Viktor.
>
>