[email protected] (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 - [email protected] - KC8VKS - http://anduin.eldar.org
