Suggestions for submission protection

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

Suggestions for submission protection

Daniel L. Miller
I have what seems to be a reasonably stable and functional filter
protecting my port 25 SMTP interface to the outside world. However, most
filters (including postscreen) state they are not intended for use
between MUAs and the MTA. Therefore my 587 submission port does not have
additional filters beyond TLS & SASL AUTH.

I'm seeing some higher levels of attempted logins from various sources.
Are there any automated filters that are suggested? Or do I simply add a
check_client_a_access and reference a manually maintained blacklist?
--
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Noel Jones-2
On 9/20/2019 4:12 PM, Daniel Miller wrote:

> I have what seems to be a reasonably stable and functional filter
> protecting my port 25 SMTP interface to the outside world. However,
> most filters (including postscreen) state they are not intended for
> use between MUAs and the MTA. Therefore my 587 submission port does
> not have additional filters beyond TLS & SASL AUTH.
>
> I'm seeing some higher levels of attempted logins from various
> sources. Are there any automated filters that are suggested? Or do I
> simply add a check_client_a_access and reference a manually
> maintained blacklist?


Depending on your user base, you may be able to limit the countries
where you offer AUTH. ipdeny.com maintains lists to use with various
firewalls, and hints on how to automate updates. These lists change
from time to time, so updates are important.

You can use fail2ban or similar to auto-block IPs that fail AUTH too
many times. Be generous, legit users do surprising things.

The various rate limits described in anvil(8) can slow down a flood
of connections.  Be generous, legit clients do surprising things.
http://www.postfix.org/TUNING_README.html#conn_limit
http://www.postfix.org/anvil.8.html

You can use postfwd to disable an account or firewall an IP if it
sends too much mail per time period. Again, be generous, legit users
do surprising things.

I'll caution that any of these methods can block legit mail when
used too aggressively, so start modest and work your way up.



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

Re: Suggestions for submission protection

Benny Pedersen-2
In reply to this post by Daniel L. Miller
Daniel Miller skrev den 2019-09-20 23:12:

> I'm seeing some higher levels of attempted logins from various
> sources. Are there any automated filters that are suggested? Or do I
> simply add a check_client_a_access and reference a manually maintained
> blacklist?

grep 'after AUTH' maillog

make this list as check client access on custommer ports, not port 25

i block big abusers with static firewalling

just not port 25

i see after AUTH on port 25, unsure what to do ?

maybe postscreen can do samme with that as pregreet ?
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Wietse Venema
Benny Pedersen:

> Daniel Miller skrev den 2019-09-20 23:12:
>
> > I'm seeing some higher levels of attempted logins from various
> > sources. Are there any automated filters that are suggested? Or do I
> > simply add a check_client_a_access and reference a manually maintained
> > blacklist?
>
> grep 'after AUTH' maillog
>
> make this list as check client access on custommer ports, not port 25
>
> i block big abusers with static firewalling
>
> just not port 25
>
> i see after AUTH on port 25, unsure what to do ?
>
> maybe postscreen can do samme with that as pregreet ?

Postscreen does not inspect every connection. That is a feature,
not a bug. It's perfectly OK to fail2ban a client that makes too
many mistakes while talking to an smtpd process.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Dominic Raferd
On Sat, 21 Sep 2019 at 01:21, Wietse Venema <[hidden email]> wrote:

>
> Benny Pedersen:
> > Daniel Miller skrev den 2019-09-20 23:12:
> >
> > > I'm seeing some higher levels of attempted logins from various
> > > sources. Are there any automated filters that are suggested? Or do I
> > > simply add a check_client_a_access and reference a manually maintained
> > > blacklist?
> >
> > grep 'after AUTH' maillog
> >
> > make this list as check client access on custommer ports, not port 25
> >
> > i block big abusers with static firewalling
> >
> > just not port 25
> >
> > i see after AUTH on port 25, unsure what to do ?
> >
> > maybe postscreen can do samme with that as pregreet ?
>
> Postscreen does not inspect every connection. That is a feature,
> not a bug. It's perfectly OK to fail2ban a client that makes too
> many mistakes while talking to an smtpd process.
>
>         Wietse

I use fail2ban with dovecot jail and a custom 'postfix-auth' jail (see
https://github.com/fail2ban/fail2ban/issues/2200), both of which block
a lot of repeated auth attempts. I also harvest attempted passwords
and relay them (filtered) to the relevant users.
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Bill Cole-3
In reply to this post by Daniel L. Miller
On 20 Sep 2019, at 17:12, Daniel Miller wrote:

> I'm seeing some higher levels of attempted logins from various
> sources. Are there any automated filters that are suggested?

The Spamhaus SBL and XBL are safe for use on submission ports, as is the
Surriel 'PSBL.' It's possible for innocent infectees to get listed on
those DNSBLs or to coincidentally get a dynamic IP formerly held by an
infected device, but that is a manageable problem. Fail2ban is also
useful against credential-stuffer attacks.

> Or do I simply add a check_client_a_access and reference a manually
> maintained blacklist?

If you do use a manual local blacklist for this (as I do on my personal
system) it is most useful to apply it at the network level: either in
your router/firewall or in a host-local packet filter (e.g. iptables,
ipfw, etc) because rejecting auth attempts at the application level is
relatively heavy compared to dropping SYNs. If your user population is
relatively small and homogeneous (e.g. a family or small business mail
system) you can block *almost* all of the Internet from port 587 and 465
with no damage. Even if you need to support "road warrior" users who
might log in from anywhere in the world, there are still some very large
networks that host lots of credential-stuffers and no legitimate mail
submission or IMAP users than can be blocked safely to good effect: AWS,
Azure, GCP, Digital Ocean, etc.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Daniel L. Miller
In reply to this post by Dominic Raferd

On 9/22/2019 8:24 AM, Dominic Raferd wrote:

> On Sat, 21 Sep 2019 at 01:21, Wietse Venema <[hidden email]> wrote:
>>
>> Benny Pedersen:
>>> Daniel Miller skrev den 2019-09-20 23:12:
>>>
>>>> I'm seeing some higher levels of attempted logins from various
>>>> sources. Are there any automated filters that are suggested? Or do I
>>>> simply add a check_client_a_access and reference a manually maintained
>>>> blacklist?
>>>[...]
>
> I use fail2ban with dovecot jail and a custom 'postfix-auth' jail (see
> https://github.com/fail2ban/fail2ban/issues/2200), both of which block
> a lot of repeated auth attempts. I also harvest attempted passwords
> and relay them (filtered) to the relevant users.
>

This was *very* helpful - thanks!

Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Daniel L. Miller
In reply to this post by Bill Cole-3
On 9/22/2019 12:59 PM, Bill Cole wrote:

> On 20 Sep 2019, at 17:12, Daniel Miller wrote:
>
>> I'm seeing some higher levels of attempted logins from various
>> sources. Are there any automated filters that are suggested?
>
> The Spamhaus SBL and XBL are safe for use on submission ports, as is the
> Surriel 'PSBL.' It's possible for innocent infectees to get listed on
> those DNSBLs or to coincidentally get a dynamic IP formerly held by an
> infected device, but that is a manageable problem. Fail2ban is also
> useful against credential-stuffer attacks.

Definitely helpful - thank you.

>
>> Or do I simply add a check_client_a_access and reference a manually
>> maintained blacklist?
>
> If you do use a manual local blacklist for this (as I do on my personal
> system) it is most useful to apply it at the network level: either in
> your router/firewall or in a host-local packet filter (e.g. iptables,
> ipfw, etc) because rejecting auth attempts at the application level is
> relatively heavy compared to dropping SYNs. If your user population is
> relatively small and homogeneous (e.g. a family or small business mail
> system) you can block *almost* all of the Internet from port 587 and 465
> with no damage. Even if you need to support "road warrior" users who
> might log in from anywhere in the world, there are still some very large
> networks that host lots of credential-stuffers and no legitimate mail
> submission or IMAP users than can be blocked safely to good effect: AWS,
> Azure, GCP, Digital Ocean, etc.
>

I totally concur that if an IP deserves blocking for one service it
generally does so for all - anyone attempting to brute-force any service
on my server has no need to ever touch it again.

Is there a "simple" table of such "credential-stuffer" network addresses
I can load on my router for blocking?

--
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for submission protection

Bill Cole-3
On 22 Sep 2019, at 18:50, Daniel Miller wrote:

> On 9/22/2019 12:59 PM, Bill Cole wrote:
[...]

>> If you do use a manual local blacklist for this (as I do on my
>> personal system) it is most useful to apply it at the network level:
>> either in your router/firewall or in a host-local packet filter (e.g.
>> iptables, ipfw, etc) because rejecting auth attempts at the
>> application level is relatively heavy compared to dropping SYNs. If
>> your user population is relatively small and homogeneous (e.g. a
>> family or small business mail system) you can block *almost* all of
>> the Internet from port 587 and 465 with no damage. Even if you need
>> to support "road warrior" users who might log in from anywhere in the
>> world, there are still some very large networks that host lots of
>> credential-stuffers and no legitimate mail submission or IMAP users
>> than can be blocked safely to good effect: AWS, Azure, GCP, Digital
>> Ocean, etc.
>>
>
> I totally concur that if an IP deserves blocking for one service it
> generally does so for all - anyone attempting to brute-force any
> service on my server has no need to ever touch it again.

I wasn't actually saying that and it's surprisingly not always true.
Often the machines that are used for high-volume auth attacks are
compromised machines with legitimate functions, such as web servers.

I was hoping to make a much narrower point: that services which are
strictly for your own users don't need to be accessible from anywhere on
the Internet, but only from the networks your users are on. The obvious
examples are geographic. For example, if your users never travel to
Russia, you can safely block port 587 & 465 traffic from Russia, even if
you still want to be able to accept email from Russia to your users
(i.e. on port 25 SMTP.)

> Is there a "simple" table of such "credential-stuffer" network
> addresses I can load on my router for blocking?

Unfortunately, no. There is an additional problem that some networks
with a substantial number of credential-stuffing machines (e.g. Comcast,
AT&T, Deutsche Telekom, Orange, etc.) are the same sorts of networks
that a mail system could have legitimate users on. So while I can block
mail client ports from a Comcast /11 network and an AT&T /8 on my
personal system, I cannot do that for the business systems I support
because they have users on those retail connection providers. On the
bright side, there's not a lot of churn in the networks that are
significant problems, so once you have identified the sources of garbage
traffic for your system, you shouldn't have much ongoing maintenance to
do.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)