I've been having issues today with several user accounts repeatedly getting locked out.
When i look at the audit.log i see numerous entries like this:
2016-12-06 18:21:29,054 WARN [qtp1508221996-1027:https://<serverip>:7071/service/admin/soap/] [name=<email>;ip=<serverip>;] security - cmd=Auth; account=<email>; protocol=soap; error=authentication failed for [<email>], invalid password;
2016-12-06 18:21:29,250 WARN [qtp1508221996-1026:https://<serverip>:7071/service/admin/soap/] [name=<email>;ip=<serverip>;] security - cmd=Auth; account=<email>; protocol=soap; error=authentication failed for [<email>], invalid password;
access_log has a matching line like this:
<serverip> - - [06/Dec/2016:18:21:29 +0000] "POST /service/admin/soap/ HTTP/1.1" 500 553 "-" "-" 4
<serverip> - - [06/Dec/2016:18:21:29 +0000] "POST /service/admin/soap/ HTTP/1.1" 500 539 "-" "-" 7
I'm not sure whats producing these log errors. If i try manually logging in with an invalid password, the line is similar but different, and contains the browsers user agent string and my local IP address rather than just the servers address.
I'd like to find whatever is causing this and get it sorted out! It smells exploity.
Any ideas? The source IP doesnt seem to be shown anywhere for these invalid logins.
Repeated Account Lockouts
Re: Repeated Account Lockouts
I'd presume it's a brute force attempt on those accounts.
Re: Repeated Account Lockouts
Agreed, but i dont understand why the log is showing the request coming from the server itself.
It was doing that for all requests, then i found a page talking about having to set some flags to fix that (zimbraMailTrustedIP). After setting that flag, the proper genuine logins using the web interface are now shown with the proper IP address, but there are still some like this that appear without, both invalid and accepted.
I've firewalled the 7071 admin port off from the internet, bar my static IP address. Will keep an eye on things and see what happens.
I'd really like to have been able to pinpoint the source IP and block it though!
It was doing that for all requests, then i found a page talking about having to set some flags to fix that (zimbraMailTrustedIP). After setting that flag, the proper genuine logins using the web interface are now shown with the proper IP address, but there are still some like this that appear without, both invalid and accepted.
I've firewalled the 7071 admin port off from the internet, bar my static IP address. Will keep an eye on things and see what happens.
I'd really like to have been able to pinpoint the source IP and block it though!
Re: Repeated Account Lockouts
Sorry, I missed that point and I never read the last line.
I guess I'd only allow my IP on port 7071. Anything else is asking for trouble IMO. So only allowing your static seems like a good start. See if the attempts pop back up, in which case we're venturing into scary exploity territory.
Also, what version of zimbra is it?
I guess I'd only allow my IP on port 7071. Anything else is asking for trouble IMO. So only allowing your static seems like a good start. See if the attempts pop back up, in which case we're venturing into scary exploity territory.
Also, what version of zimbra is it?
Re: Repeated Account Lockouts
Ok so overnight there were more attempts, despite the firewall.
Ofcourse, the logs are showing the requests coming from inside the server, so perhaps that makes sense.
There are also similar log entries for users that definately arent admins, with the same format. Heres some log entries from this morning:
As before a few spammy attempts with the same user accounts as yesterday, then, at the bottom, a couple of accepted auth requests from other (real, non-admin) user accounts. These users wouldnt be accessing the admin panel, so the question is what is creating these (presumably legitimate, genuine) requests?
Is there any way to log these requests in greater detail?
Its running Zimbra 8.0.9. I need to get it upgraded to the latest build, i was holding off as i had thought, for some reason, the latest version wouldnt run on Ubuntu 12.04. Turns out it will. So i will try to get the machine upgraded to 8.7.1 later this week.
Ofcourse, the logs are showing the requests coming from inside the server, so perhaps that makes sense.
There are also similar log entries for users that definately arent admins, with the same format. Heres some log entries from this morning:
Code: Select all
2016-12-07 00:08:25,600 WARN [qtp777206150-436:https://<serverip>:7071/service/admin/soap/] [name=<user1>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user1>@<ourdomain>; protocol=soap; error=authentication failed for [<user1>@<ourdomain>], invalid password;
2016-12-07 00:08:27,872 WARN [qtp777206150-436:https://<serverip>:7071/service/admin/soap/] [name=<user1>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user1>@<ourdomain>; protocol=soap; error=authentication failed for [<user1>], invalid password;
2016-12-07 01:08:30,514 WARN [qtp777206150-843:https://<serverip>:7071/service/admin/soap/] [name=<user2>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user2>@<ourdomain>; protocol=soap; error=authentication failed for [<user2>@<ourdomain>], invalid password;
2016-12-07 01:08:32,557 WARN [qtp777206150-843:https://<serverip>:7071/service/admin/soap/] [name=<user2>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user2>@<ourdomain>; protocol=soap; error=authentication failed for [<user2>], invalid password;
2016-12-07 06:19:49,379 INFO [qtp777206150-2955:https://<serverip>:7071/service/admin/soap/] [name=<user3>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user3>@<ourdomain>; protocol=soap;
2016-12-07 07:39:22,023 INFO [qtp777206150-3496:https://<serverip>:7071/service/admin/soap/] [name=<user4>@<ourdomain>;ip=<serverip>;] security - cmd=Auth; account=<user4>@<ourdomain>; protocol=soap;
Is there any way to log these requests in greater detail?
Its running Zimbra 8.0.9. I need to get it upgraded to the latest build, i was holding off as i had thought, for some reason, the latest version wouldnt run on Ubuntu 12.04. Turns out it will. So i will try to get the machine upgraded to 8.7.1 later this week.
-
- Elite member
- Posts: 1112
- Joined: Sat Sep 13, 2014 12:47 am
Re: Repeated Account Lockouts
Most likely these are attempts at authenticated submission of emails.
If you search for the appropriate matching timestamp (remove the date part) in /var/log/zimbra.log you will most likely find the attempt to send an email. It should provide you with the originating IP address.
You will get a block of lines like this
Hope this helps
If you search for the appropriate matching timestamp (remove the date part) in /var/log/zimbra.log you will most likely find the attempt to send an email. It should provide you with the originating IP address.
You will get a block of lines like this
Code: Select all
Dec 7 10:37:00 mail saslauthd[8132]: zmpost: url='https://mail.my.domain.com:7071/service/admin/soap/' returned buffer->data='<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><context xmlns="urn:zimbra"/></soap:Header><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text>authentication failed for [my.user@my.domain.com]</soap:Text></soap:Reason><soap:Detail><Error xmlns="urn:zimbra"><Code>account.AUTH_FAILED</Code><Trace>qtp509886383-4793:https://192.168.200.10:7071/service/admin/soap/:1481107020918:80a216550b9aee1c</Trace></Error></soap:Detail></soap:Fault></soap:Body></soap:Envelope>', hti->error=''
Dec 7 10:37:00 mail saslauthd[8132]: auth_zimbra: my.user@my.domain.com auth failed: authentication failed for [my.user@my.domain.com]
Dec 7 10:37:00 mail saslauthd[8132]: do_auth : auth failure: [user=my.user@my.domain.com] [service=smtp] [realm=my.domain.com] [mech=zimbra] [reason=Unknown]
Dec 7 10:37:00 mail postfix/submission/smtpd[11849]: warning: SASL authentication failure: Password verification failed
Dec 7 10:37:00 mail postfix/submission/smtpd[11849]: warning: unknown[88.85.171.103]: SASL PLAIN authentication failed: authentication failure
Re: Repeated Account Lockouts
It does, Thanks!
Sure enough each request matches a failed attempt to send an email with SMTP auth.
No pattern to the IP addresses unfortunately, just lots of random crap from russia/thailand etc.
Eased my worry that it was something exploity, rather than just straight up spam.
Sure enough each request matches a failed attempt to send an email with SMTP auth.
No pattern to the IP addresses unfortunately, just lots of random crap from russia/thailand etc.
Eased my worry that it was something exploity, rather than just straight up spam.