Postfix and tcpwrappers?

[Karl Denninger]

This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....

Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)

Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.

A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

[Ronald Klop]

Post by Karl Denninger
This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....
Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)
Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

Don't know if postfix can handle tcp wrappers, but I use bruteblock [1]
for protecting connections via the ipfw firewall. I use this for ssh and
postfix.

Regards,
Ronald.

[1] http://www.freshports.org/security/bruteblock/

[Karl Denninger]

On Mon, 25 Jul 2016 18:48:25 +0200, Karl Denninger

Post by Karl Denninger
This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....
Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)
Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

Don't know if postfix can handle tcp wrappers, but I use bruteblock
[1] for protecting connections via the ipfw firewall. I use this for
ssh and postfix.

I recompiled sshguard to use ipfw and stuck the table lookup in my
firewall config..... works, and is software-agnostic (thus doesn't care
if something was linked against tcpwrappers or not.)

[Shawn Bakhtiar]

On Jul 25, 2016, at 10:32 AM, Karl Denninger <***@denninger.net<mailto:***@denninger.net>> wrote:

On 7/25/2016 12:04, Ronald Klop wrote:
On Mon, 25 Jul 2016 18:48:25 +0200, Karl Denninger
<***@denninger.net<mailto:***@denninger.net>> wrote:

This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....

Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)

Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.

A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?


Don't know if postfix can handle tcp wrappers, but I use bruteblock
[1] for protecting connections via the ipfw firewall. I use this for
ssh and postfix.

I recompiled sshguard to use ipfw and stuck the table lookup in my
firewall config..... works, and is software-agnostic (thus doesn't care
if something was linked against tcpwrappers or not.)


I would triple concur with the above advice. using ipfw is a much better choice (especially at high volume) as ipfw works primarily at layer 3 (and in the kernel itself), Where as tcp wrappers works at layer 7 (requiring application awareness).

Here are the handbook references:
https://www.freebsd.org/doc/handbook/tcpwrappers.html
https://www.freebsd.org/doc/handbook/firewalls-ipfw.html


--
Karl Denninger
***@denninger.net<mailto:***@denninger.net> <mailto:***@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[Tim Daneliuk]

Post by Karl Denninger
ecently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

You can more-or-less run anything from a wrapper if you don't daemonize it
and kick it off on-demand from inetd. Essentially, you have inetd.conf
configured with a stanza that - upon connection attempt - launches an
instance of your desired program (postfix in this case), if and only
if the hosts.allow rules are satisfied.

This works nicely for smaller installations, but is very slow in high
arrival rate environments because each connection attempt incurs the full
startup overhead of the program you're running.

[Karl Denninger]

Post by Tim Daneliuk

Post by Karl Denninger
ecently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

You can more-or-less run anything from a wrapper if you don't daemonize it
and kick it off on-demand from inetd. Essentially, you have inetd.conf
configured with a stanza that - upon connection attempt - launches an
instance of your desired program (postfix in this case), if and only
if the hosts.allow rules are satisfied.
This works nicely for smaller installations, but is very slow in high
arrival rate environments because each connection attempt incurs the full
startup overhead of the program you're running.

Tcpwrapper works with many persistent system services (sshd being a
notable ones) and integrates nicely, so you can use hosts.allow. The
package (or default build in ports) for sshguard uses the hosts.allow file.

But, sshguard does know (if you build it by hand or use the right
subport) how to insert into an ipfw table instead.... so I switched over
to that. I was rather curious, however, if/why postfix wasn't
integrated with the hosts.allow file as are many other system services
(or if I just missed the config option to turn it on) since it's offered
by FreeBSD as a "stock sendmail replacement" option for higher-volume
(and more-secure) sites....

[Willem Jan Withagen]

On Mon, 25 Jul 2016 18:48:25 +0200, Karl Denninger

Post by Karl Denninger
This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....
Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)
Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

Don't know if postfix can handle tcp wrappers, but I use bruteblock
[1] for protecting connections via the ipfw firewall. I use this for
ssh and postfix.

Given the fact that both tcpwrappers and postfix originate from the same
author (Wietse Venenma) I'd be very surprised it you could not do this.
http://www.postfix.org/linuxsecurity-200407.html

But grepping the binary for libwrap it does seems to be the case.
Note that you can also educate sshguard to actually use a script to do
whatever you want it to do. I'm using it to add rules to an ipfw table
that is used in a deny-rule.

Reloading the fw keeps the deny-rules, flushing the table deletes all
blocked hosts without reloading the firewall.
Both times a bonus.

--WjW
--WjW

[Karl Denninger]

Post by Willem Jan Withagen

On Mon, 25 Jul 2016 18:48:25 +0200, Karl Denninger

Post by Karl Denninger
This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....
Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)
Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

Don't know if postfix can handle tcp wrappers, but I use bruteblock
[1] for protecting connections via the ipfw firewall. I use this for
ssh and postfix.

Given the fact that both tcpwrappers and postfix originate from the same
author (Wietse Venenma) I'd be very surprised it you could not do this.
http://www.postfix.org/linuxsecurity-200407.html
But grepping the binary for libwrap it does seems to be the case.
Note that you can also educate sshguard to actually use a script to do
whatever you want it to do. I'm using it to add rules to an ipfw table
that is used in a deny-rule.
Reloading the fw keeps the deny-rules, flushing the table deletes all
blocked hosts without reloading the firewall.
Both times a bonus.
--WjW
--WjW

That's why I was surprised too... .but it is what it is.

I just rebuilt sshguard to use an ipfw table instead of hosts.allow,
since I use ipfw anyway for firewall/routing/ipsec/etc adding one line
up near the top of my ruleset to match against the table and send back a
reset (I'm considering black-holing attempts instead as that will slow
the clowncar brigade down and thus "helps" others) and resolved the issue.

It's interesting that all of a sudden the clowncar folks figured out
that if they hit my email server with SSL they could then attempt an
auth. I have always had auth turned off for non-SSL connections for
obvious reasons (passing passwords around plain is bad news, yanno) and
until recently the clowns hadn't bothered with the overhead of setting
up SSL connections.

That appears to now have changed, so....

[Willem Jan Withagen]

Post by Karl Denninger

Post by Willem Jan Withagen

On Mon, 25 Jul 2016 18:48:25 +0200, Karl Denninger

Post by Karl Denninger
This may not belong in "stable", but since Postfix is one of the
high-performance alternatives to sendmail....
Question is this -- I have sshguard protecting connections inbound, but
Postfix appears to be ignoring it, which implies that it is not paying
attention to the hosts.allow file (and the wrapper that enables it.)
Recently a large body of clowncars have been targeting my sasl-enabled
https gateway (which I use for client machines and thus do in fact need)
and while sshguard picks up the attacks and tries to ban them, postfix
is ignoring the entries it makes which implies it is not linked with the
tcp wrappers.
A quick look at the config for postfix doesn't disclose an obvious
configuration solution....did I miss it?

Don't know if postfix can handle tcp wrappers, but I use bruteblock
[1] for protecting connections via the ipfw firewall. I use this for
ssh and postfix.

Given the fact that both tcpwrappers and postfix originate from the same
author (Wietse Venenma) I'd be very surprised it you could not do this.
http://www.postfix.org/linuxsecurity-200407.html
But grepping the binary for libwrap it does seems to be the case.
Note that you can also educate sshguard to actually use a script to do
whatever you want it to do. I'm using it to add rules to an ipfw table
that is used in a deny-rule.
Reloading the fw keeps the deny-rules, flushing the table deletes all
blocked hosts without reloading the firewall.
Both times a bonus.
--WjW
--WjW

That's why I was surprised too... .but it is what it is.
I just rebuilt sshguard to use an ipfw table instead of hosts.allow,
since I use ipfw anyway for firewall/routing/ipsec/etc adding one line
up near the top of my ruleset to match against the table and send back a
reset (I'm considering black-holing attempts instead as that will slow
the clowncar brigade down and thus "helps" others) and resolved the issue.

Right,
That facility is in there because I suggested such, and provided example
code. :)

I just drop the packet, that'll give the average uneducated spammer at
least one setup-time out to wait.

Post by Karl Denninger
It's interesting that all of a sudden the clowncar folks figured out
that if they hit my email server with SSL they could then attempt an
auth. I have always had auth turned off for non-SSL connections for
obvious reasons (passing passwords around plain is bad news, yanno) and
until recently the clowns hadn't bothered with the overhead of setting
up SSL connections.
That appears to now have changed, so....

I've seen more complaints about this on the sshguard list, and asking
for matching rules that would block on SASL auth attempts.

Dealing with spammers and hackers is always a leap-frog business. It
works until they find a new angle.

--WjW