On Sun, Jan 5, 2025 at 6:39 AM Philipp <phil...@bureaucracy.de> wrote:
> > > Just a question: shal such event to be triggered by failed AUTH request > on > > listener which doesn't support auth? > > Yes, this was the idea. Here is a list of reasons auth is rejected: > > 1. The client hasn't send helo/ehlo yet > > 2. The client is already authenticated > > 3. Auth isn't advertised > > 3.1 Auth is not enabled on this listener > > 3.2 The connection is still in plaintext (before starttls) > > 4. A plain "AUTH" without parameter is send > > 5. The auth method is not supported > > In theory all this cases could be encoded in the event. A simpler > approach would be to only differentiate between smtp_check_auth failed > and method not implemented. To clarify a bit on "security relevance", since as was pointed out, in cases where auth isn't advertised or isn't supported, an auth attempt can't succeed (is mitigated). From one standpoint, that's entirely true. The standpoint in the context I raised this in however is: to basically enable OpenSMTPD to generate some signal that a remote client had attempted the action at all - and that awareness awareness is very beneficial. These points come to mind: * Authentication attempted when it is not supported by the server configuration is an anomaly, and notifying an admin of that can help with troubleshooting in a non-security context, or greater awareness of attack in a security context. If a remote client is an authorized user, perhaps they've misconfigured their client, and seeing this in the system logs is helpful. If the remote client is an unauthorized user, you can uncover that by showing attempts to authenticate when they should not, and exposing the details of those auth attempts can inform a proper response by the admin. * Authentication attempted when it is supported by the server configuration, but not supported in the current context (e.g. before STARTTLS) is unexpected, and the same benefits apply. * Credential attacks in this space are incredibly common and very relevant today, with credential stuffing, password spraying, distributed brute force and other attempts to gain access to mail servers for data access or resource abuse being very widespread and relevant now. With this viewpoint, it's understandable that users may want exposed services to be able to generate signals that can help identify these attempts and equip admins to take action against clients that show bad behavior. With the above in mind, the thinking is that it would be helpful for an event to be emitted that also clearly identifies not only the authentication attempt, but also the reason for the failure. -- Darren Spruell phatbuck...@gmail.com
