Re: Blocklistd + postfix

[Brad Spencer <brad%anduin.eldar.org@localhost>]

neitzel%hackett.marshlabs.gaertner.de@localhost (Martin Neitzel) writes:

> Brook Milligan wrote:
>
> BM> Does it make sense that failed SMTP authentication should trigger
> BM> blocklistd events?
>
> Basically yes.  I don't know, though, whether the trigger should
> be implemented at the postfix level, the underlying SASL mechanism
> used, or even the PAM framework.
>
> And whether or not one makes use of it depends on the actual
> circumstances, just like Greg already wrote.
>
> I'd happily activate it on my personal mail server without any
> problems.
>
> On the mailservers we operate as an ISP for business customers,
> it's a decision which can be tricky to balance.  It will always
> happen that one user with an incorrect or outdated config will
> trigger the block for all the colleagues working from behind the
> same NAT address.  This can usually be resolved quickly enough for
> a small customer with just, say, just 5 accounts;  with 20 mail
> accounts, the odds of this happening just rise and the impact
> becomes much worse.  In the best case, the mail customer is using
> static addresses we can exempt from being blocked.
>
> What irks me about blocklistd(8) is the lack of a way of correcting
> such mishaps quickly.   blocklisctctl(8) should not just have the
> current "dump" sub-command to investigate the blocked entries;
> having some "release/cleanup" facilities would be a real bonus.
> Restoring access directly with npfctl (or whatever is used) doesn't
> feel right to me.
>
> 						Martin Neitzel

I have been following this conversation with some interest.  I don't use
blocklistd at all, as I have my own policy engine that I have used for
more than a decade which feeds NPF or IPF to do the actual blocking.
Here is my 2 cents worth....

To that last question / comment...  the use of npfctl will depend very
much on what the primary source of truth really is for the block list.
In my case, the NPF tables perform the actual blocking, but they are
backed by either Postgresql database tables which are fed by the policy
engine or an Elasticsearch index which is also fed by the policy engine.
This information is pulled out of these sources and shoved into the NPF
tables.  Be aware that the use of a technique like this does mean that
the NPF tables have to be rationalized (or a synchronization if you
like), that is, there has to be something that checks for entries that
need to be added as well as entries that need to be removed.  However,
if the policy engine does not need any sort of additional back store,
then simply using the NPF tables directly would be fine.  Nothing at all
would be wrong with adding and removing entries with npfctl.

The question of Why Something Was Blocked could also be thought of as a
separate thing from the table that indicates What to Block.  For some of
the Why question I utilize Elasticsearch which is also used for the What
Was Blocked (i.e. tcpdump against npflog0 feeding Elasticsearch) which
is also a separate concern.

As for postfix and SASL auth fails.  I have been doing that, but by
taping into syslog output for the needed information (i.e. another entry
in /etc/syslog.conf which uses a '|', pipe, into a script for email log
messages).  In my case, the policy is One-And-Done ... that is, a single
fail triggers a block of the IP address.  I very much understand that
this can be far too brutal.  I pull other log entries other than auth
fails for email and block on those too and I will say that the more of
these you do the greater the chance of nailing someone you really didn't
intend on (such as a close inlaw who has a tendency of closing down the
email client a bit too quickly and thus trips a message that looks
exactly like someone poking at the email service).  This caused my
policy engine to grow the concept of exclusions, but those really do not
scale very well.  Thankfully, in my case, the number of exclusions is
quite small and almost static.  I also have to watch the logs for
successful SASL auths as I have someone where the DHCP IP lease is
pretty short and their address changes quite a lot and I use this
success to alter the exclusion entry for them.  I really think of this
as a sidecar operation with the policy engine.






-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org