Kevin,
Thanks for the quick turn around. I've taken a closer look at the filter
API, and I'm unsure about how exactly y'alls might want to proceed
there. sshguard is fundamentally a "pull" type service gathering data
from sources, whereas the smtpd filter API is a "push" type, where smtpd
executes a long-running filter executable and pushes data to it,
potentially expecting a response.
At a minimum, a plug will be needed that smtpd can execute, which would
then place that data into a logfile or fifo that sshguard can read. (I
think a fifo would be perfect for this, since no retention is needed for
the data we want, as it would already be logged in maillog).
Since we have to have a separate plug executable, we come to the
question of where one actually wants to do the parsing. It seems to me
that it would be simpler to have the plug do the primary parsing via
something like libopensmtpd rather than implement the full parser in
sshguard. The plug would just output a simplified format added to the
sshguard parser, e.g. "timestamp smtpd found-attack hostname.hostdomain
127.0.0.1".
As for the actual API events in which sshguard would be interested, the
following would seem to be the most likely candidates:
- link-connect: this contains among other information, a pass/fail
variable on forward-confirmed reverse DNS. It is recommended by most to
require FCrDNS to allow the connection to an MX to proceed, so it is
reasonable to see a failure here as an attack indicator.
-link-auth: this event contains two variables, the username used for an
authentication attempt, and a pass/fail/error. pass and error to be
ignored, but fail should be seen as a possible attack.
In theory, one could also use filter-report/filter-response to monitor
output from other filters, such-as filter-rspamd, so you could handle
spam messages as an indicator as well, but that seems more than a little
ambitious for the moment.
Overall, I don't see this as being particularly difficult to get
working, but it certainly raises the complexity. Instead of allowing
sshguard to simply do its job, this requires the user to also configure
smtpd to assist in that matter. Having looked at the requirements for
this, I'm not entirely convinced that it's something that should be
done; the prudent action may simply be to update the documentation to
say "OpenSMTPd support for version <=x.x", and move on.
Hope this helps,
B
|