Hi,
I'm running a Centos 5.1 server that uses saslauthd to allow sendmail SMTP relaying for some clients. saslauthd is configured to use method "shadow" to lookup the username / password directly from /etc/shadow. This setup has been working for several month now, but is broken since last Monday. I haven't changed anything neither on the server nor on the clients. Now whenever a client tries to relay email I see this messages in the logs:
/var/log/maillog: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed
/var/log/messages: saslauthd[3665]: do_auth : auth failure: [user=username] [service=smtp] [realm=] [mech=shadow] [reason=Unknown]
Does someone have an idea how to debug this further, esp. how to find the real reason as the message [reason=Unknown] is not very helpful at all.
Thanks in advance, Bernd.
Bernd Bartmann wrote:
/var/log/maillog: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed
/var/log/messages: saslauthd[3665]: do_auth : auth failure: [user=username] [service=smtp] [realm=] [mech=shadow] [reason=Unknown]
Does someone have an idea how to debug this further, esp. how to find the real reason as the message [reason=Unknown] is not very helpful at all.
Is saslauthd still running? Could it have failed or not started if the server has rebooted?
Ian
On Sun, May 25, 2008 at 11:42 AM, Ian Blackwell wrote:
Bernd Bartmann wrote:
/var/log/maillog: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed
/var/log/messages: saslauthd[3665]: do_auth : auth failure: [user=username] [service=smtp] [realm=] [mech=shadow] [reason=Unknown]
Does someone have an idea how to debug this further, esp. how to find the real reason as the message [reason=Unknown] is not very helpful at all.
Is saslauthd still running? Could it have failed or not started if the server has rebooted?
Thanks Ian. That's indeed the reason. "service saslauthd status" gives "saslauthd dead but subsys locked". Now, what could be the reason why saslauthd was not running any more?
cu, Bernd.
Bernd Bartmann wrote:
Thanks Ian. That's indeed the reason. "service saslauthd status" gives "saslauthd dead but subsys locked". Now, what could be the reason why saslauthd was not running any more?
cu, Bernd. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hard to say without seeing the logs. Does it restart for you or is it continuing to fail?
Ian
On Sun, May 25, 2008 at 2:42 PM, Ian Blackwell wrote:
Bernd Bartmann wrote:
Thanks Ian. That's indeed the reason. "service saslauthd status" gives "saslauthd dead but subsys locked". Now, what could be the reason why saslauthd was not running any more?
Hard to say without seeing the logs. Does it restart for you or is it continuing to fail?
It did start without any problems. Looks like I found the cause. From the logs I see that someone tried a brute force attach on the SMTP relay with several username / password combinations. Then one of the attempts lead to a segfault of saslauth. Which probably means that there is a bug in saslauthd as it should not be possible to crash a service just by suppling a "weird" comibination of input data.
May 18 17:25:36 srsrzfw01 saslauthd[5167]: do_auth : auth failure: [user=marketing] [s ervice=smtp] [realm=] [mech=shadow] [reason=Unknown] May 18 17:25:37 srsrzfw01 kernel: saslauthd[5168]: segfault at 000000004ba33160 rip 000000323d e76170 rsp 00007fff78d4fb18 error 4 May 18 17:25:37 srsrzfw01 kernel: saslauthd[5166]: segfault at 000000004ba33160 rip 000000323d e76170 rsp 00007fff78d4fb18 error 4 May 18 17:25:37 srsrzfw01 kernel: saslauthd[5169]: segfault at 000000004ba33160 rip 000000323d e76170 rsp 00007fff78d4fb18 error 4 May 18 17:25:38 srsrzfw01 kernel: saslauthd[5170]: segfault at 000000004ba33160 rip 000000323d e76170 rsp 00007fff78d4fb18 error 4 May 18 17:25:38 srsrzfw01 kernel: saslauthd[5167]: segfault at 000000004ba33160 rip 000000323d e76170 rsp 00007fff78d4fb18 error 4 May 22 18:29:53 srsrzfw01 saslauthd[26597]: detach_tty : master pid is: 26597 May 22 18:29:53 srsrzfw01 saslauthd[26597]: ipc_init : listening on socket: /var/run/sa slauthd/mux May 22 18:45:39 srsrzfw01 saslauthd[26597]: server_exit : master exited: 26597 May 22 18:47:31 srsrzfw01 saslauthd[5160]: detach_tty : master pid is: 5160 May 22 18:47:31 srsrzfw01 saslauthd[5160]: ipc_init : listening on socket: /var/run/sas lauthd/mux May 22 18:57:24 srsrzfw01 saslauthd[5160]: server_exit : master exited: 5160
cu, Bernd
Bernd Bartmann wrote:
It did start without any problems. Looks like I found the cause. From the logs I see that someone tried a brute force attach on the SMTP relay with several username / password combinations. Then one of the attempts lead to a segfault of saslauth. Which probably means that there is a bug in saslauthd as it should not be possible to crash a service just by suppling a "weird" comibination of input data.
Sounds to me like you should consider running SELinux - that is if you aren't already :-) . Of course it won't solve the segfault, but it should restrict any damage a compromised saslauthd process can do.
Anyway, glad you're on track again.
Ian
-
Bernd Bartmann -
Ian Blackwell