/run/saslauthd/mux
socket and /usr/sbin/testsaslauthd
are both available for non-privileged users.
Yes, because typically some of the services that use SASL to authenticate can also run as non-privileged users.
So when you have saslauthd started, it makes your system vulnerable.
That is quite a leap.
The saslauthd service can only be used by local users and processes, it is not a network service open to online brute force attempts. You don't really secure such a service against brute-force attempts at the service level, just like you don't secure the su
command against brute-force attempts.
As you already hint at what you could do:
- don't give access to your systems to users that can't be trusted and simply secure the actual network service(s) that call on SASL against brute-force attacks for instance by blocking the remote offenders there (fail2ban is one such implementation)
- alternatively, since saslauthd is only a gateway to the actual authentication backend, log failed login attempts at the account level and (temporarily) lock the account after a number of failed login attempts on that specific account.