OpenSMTPD 7.6.0
OpenBSD 7.6 amd64
I'm following a thread on the SSHGuard mailing list [1] as we're looking
for a way of tracking credential attacks against OpenSMTPD. The switch to
smtpd-filters(7) hasn't yet been caught up, and so there is discussion
about how to handle that logging to identify the various authentication
based attacks (password spraying, brute force, etc.). The outcome we're
looking for is this: ensure that all authentication attempts against
smtpd(8) can be found in the logs for monitoring by various agents like
SSHGuard.
Since the proper approach to integrating against OpenSMTPD logging appears
to be using the smtpd-filters(7) API to get report events, vs. using the
smtpd(8) syslog stream, I've checked to see what events are currently sent
to the report filter when authentication attempts occur. I think I'm seeing
that some failed authentication attempts that are logged by smtpd(8) in
syslog are not currently sent to smtpd-filters(7). These are a few
examples, with the smtpd(8) syslog events followed by associated
smtpd-filters(7) events:
2024-12-26T10:40:25.834Z mailserver smtpd[7134]: c326c2035a3936ca smtp
connected address=94.156.177.116 host=94-156-177-116.virtualine.org
2024-12-26T10:40:26.030Z mailserver smtpd[1975]: senderscore: link-connect
addr=94.156.177.116 score=127
2024-12-26T10:40:26.528Z mailserver smtpd[7134]: c326c2035a3936ca smtp
failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command:
Command not supported"
2024-12-26T10:40:26.791Z mailserver smtpd[7134]: c326c2035a3936ca smtp
disconnected reason=quit
report|0.7|1735209625.834172|smtp-in|link-connect|c326c2035a3936ca|
94-156-177-116.virtualine.org|fail|94.156.177.116:55291|x.x.97.55:25
report|0.7|1735209626.042628|smtp-in|link-identify|c326c2035a3936ca|EHLO|User
report|0.7|1735209626.791303|smtp-in|link-disconnect|c326c2035a3936ca
-----
2024-12-28T07:15:07.659Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp
connected address=44.220.185.247 host=
ec2-44-220-185-247.compute-1.amazonaws.com
2024-12-28T07:15:07.829Z mailserver smtpd[1975]: senderscore: link-connect
addr=44.220.185.247 score=127
2024-12-28T07:15:13.645Z mailserver smtpd[1975]: dnsbl: c326ce9baeaf2b15
not listed
2024-12-28T07:15:13.772Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp
failed-command command="AUTH NTLM" result="503 5.5.1 Invalid command:
Command not supported"
2024-12-28T07:15:13.835Z mailserver smtpd[7134]: c326ce9baeaf2b15 smtp
disconnected reason=disconnect
report|0.7|1735370107.659126|smtp-in|link-connect|c326ce9baeaf2b15|
ec2-44-220-185-247.compute-1.amazonaws.com|pass|44.220.185.247:46964
|x.x.97.55:25
report|0.7|1735370113.709076|smtp-in|link-identify|c326ce9baeaf2b15|EHLO|localhost
report|0.7|1735370113.835095|smtp-in|link-disconnect|c326ce9baeaf2b15
-----
2024-12-30T01:03:13.570Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp
connected address=154.203.197.53 host=<unknown>
2024-12-30T01:03:13.696Z mailserver smtpd[28705]: senderscore: link-connect
addr=154.203.197.53 score=127
2024-12-30T01:03:13.859Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp
failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command:
Command not supported"
2024-12-30T01:03:14.004Z mailserver smtpd[74910]: 1f37facfcf1e594d smtp
disconnected reason=quit
report|0.7|1735520593.570254|smtp-in|link-connect|1f37facfcf1e594d|<unknown>|fail|154.203.197.53:55934
|x.x.97.55:25
report|0.7|1735520593.715930|smtp-in|link-identify|1f37facfcf1e594d|EHLO|User
report|0.7|1735520594.004235|smtp-in|link-disconnect|1f37facfcf1e594d
In the above cases, the filter was registered as follows:
register|report|smtp-in|link-connect
register|report|smtp-in|link-identify
register|report|smtp-in|link-disconnect
register|report|smtp-in|link-auth
register|report|smtp-in|timeout
register|ready
Looking at the documentation for the link-auth event, it seems like it
should include the failed authentication events:
link-auth: result username
This event is generated upon an authentication attempt by the
client.
result contains the string "pass", "fail" or "error" depending on
the result of the authentication attempt.
username contains the username used for the authentication attempt.
I'm guessing the reason it may not is because the AUTH line is a
failed-command, maybe because the client attempted to authenticate before
issuing STARTTLS. I also wonder if there would be issues generating those
link-auth events when the listener is not configured for `auth`.
There is also the the following report event, although I suspect this is
overkill and due to being raw, may be more free-form and complicate parsing
by agents as well as being too verbose (logging more than just AUTH
activity):
protocol-client: command
This event is generated for every command submitted by the client.
It contains the raw command as received by the server.
command contains the command emitted by the client to the server.
Also as an aside, filter requests (as opposed to report events) document
the following event, but I figure this is irrelevant as we're focused on
report events only:
auth: auth
This request is emitted after the client has requested "AUTH".
I'm wondering the best path forward here. Given the security relevance, it
seems like we should be able to see link-auth events for successful or
failed authentication attempts at all points; before and after STARTTLS,
and in cases whether `auth` is enabled on a listener or not. Is this a case
where the smtpd-filters(7) event logging should be improved in OpenSMTPD,
or am I thinking about this wrong?
[1]
https://sourceforge.net/p/sshguard/mailman/sshguard-users/thread/3e33398b-3e0c-359d-6a34-a081452b5e97%40tcp80.org/#msg37798632
--
Darren Spruell
phatbuck...@gmail.com
