Some random thoughts along with what's a cause and what's an effect.
On Mon, 26 Dec 2022, mats wrote:
[...] The Challenge I want to be able to run my own "idp" type script
when someone tries to connect to my mailserver. Basically I want to
refuse them even a tcp connection to smtpd if the connecting ip is in
our internal blacklist.
Did you bother running a public search on the TLA "IDP" before using it
here? If I'm supposed to guess correctly what it's supposed to mean in
this context that's a fail.
So what you do state is:
* run a script when somebody tries to connect to my mailserver
* internal list
* refuse them... a connection
I'm doing it today with an old HMailserver and it's very effective so I
would like to port that functionality
"Port" in my world in this context means you're gonna write software.
Before someone says fail2ban so no, fail2ban is way to late since it
requires log entries from smtpd. I want to kill them before they even
get a chance to try and log on
* (doesn't require) log entries; therefore fail2ban is too late
* kill (this is a unix command folks, relax)
* before... something
If you refuse them a connection, then what source of truth exists as a
prior for you to take action, or in other words for them to end up in your
list? This is my basic beef with what you're saying although you're
generally lacking the rigor I need in order to understand your
constraints.
I'm not sure how Windows does it (isn't the OS some fork of DEC VMS?) but
a TCP connection requires an exchange of packets; and the exchange
typically occurs in a subsecond timeframe. If it doesn't packets get
resent. So you're going to run a script (EBPF? what do you have in mind?)
before that occurs; and if your script isn't fast enough then packets will
be resent and you'll have double the work to complete in the same amount
of time. Plus, if an adversary can trivially send you a packet in order to
cause you to run a script, I suggest that you've created a footgun and I
wouldn't tell the world about it. So I propose that in fact maybe some
software is lying to you and is accepting the handshake prior (or in
unordered simultanaety) to running the script. It's therefore difficult
for me to take this claim at face value, you need to get out wireshark,
and the equivalent of strace perhaps, and verify this claim.
"Kill" and "before": I really don't think killing processes is required
here. Typically such an action would be taken if other safeguards have
been breached, and I'm concerned if some packet, which according to priors
established here hasn't even completed a handshake, arriving on an
interface is sufficient to trigger such drastic action (lucky for you, if
you move this to u*ix the process model is much more lightweight). If you
remember when a removable 10Meg drive was as big as a washing machine (of
the same era) you recall the phrase "garbage in garbage out" and I think
that's what's going on here.
Generally speaking, there are database backends for DNS. There are also
databases such as Redis which are optimized for the "write many read once"
scenario; and you can proxy it to DNS with for example RKVDNS
(https://github.com/m3047/rkvdns). The reason I keep mentioning DNS here
is blatantly hammer + nail, as several DNS checks are involved in the
typical mail delivery scenario... including while running e.g. spam
filtering scripts.
As a final thought since you mentioned fail2ban, fail2ban doesn't take an
immediate action to deny somebody a connection. What fail2ban does is
establish a prior (a firewall rule or rules) such that other actions will
be taken when that condition occurs subsequently to its establishment.
What that prior is or does can be adjusted; for instance maybe the prior
routes the traffic to a honeypot; but it's not fail2ban doing the blocking
or the routing, again it just sets the prior conditions: fail2ban
(typically) establishes firewall rules based on packet characteristics and
the firewall takes the specified actions when the characteristics
specified by the rule(s) are encountered. If SMTP logs are too late then,
again: what conditions are you using as a prior informing your packet
pogrom? Use that as the log that fail2ban (or its ilk) monitors instead;
if necessary write the log yourself!
You need a chain of priors to establish an action to be taken when a
condition occurs. You need to be able to identify prior conditions to
inform subsequent actions or even to claim that their occurrence is
related to anything. I believe the phrase "logs or it didn't happen" arose
subsequently to the invention of punch cards, but it's a good one.
--
Fred Morris, internet plumber
