Identify compromised accounts

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
7310pyperdown
Posts: 31
Joined: Fri Sep 12, 2014 10:02 pm

Identify compromised accounts

Postby 7310pyperdown » Thu May 01, 2014 6:49 pm

Just got hosed by this exact situation today, and my booby-trap didn't catch it. Will take a look-see at the sasl_username and see if that proves more effective. If you have any code for this I'd sure love to see this.
[quote user="drwho18"]The script posted above is a good idea, however it doesn't really stop an in process attack (at least on my Zimbra setup). It checks for "auth ok" of which I tend to see a few, the spammer appears to hold smtp open and I see each send tagged with a "sasl_username" in the logs, checking the message ID out I see it was a new message with fresh recipients. I have modded the script to check for sasl_username, as I think that is more relevant to trip off a spam notice, however locking the account does not stop said account from continuing to spam through the server. If it tries to come in from a new IP it will try to reauth and fail fine, but I believe it will continue to function untl the SMTP session is stopped, by which time a lot of damage can be done to a mail servers reputation. Any ideas how to stop this, or reduce the max SMTP session time or something would be the way to go. I wish every sasl_username request was an actual auth attemp, maybe saslauthd is caching by default on zimbra?[/QUOTE]


7310pyperdown
Posts: 31
Joined: Fri Sep 12, 2014 10:02 pm

Identify compromised accounts

Postby 7310pyperdown » Thu May 01, 2014 7:43 pm

I ended up with something very similar (in the grep/sed/awk commands)... added a logrotation at the end, so that th euser's account can get unlocked once appropriate measures are taken (strung up by thumbs, teaching moment exploited, password changed, etc)


#!/bin/bash

# checks log file and gets a count of authentications sent per minute, per user

# and if the count exceeds the maxmails value the user's account is locked.
logfile="/var/log/zimbra.log"

maxmails="10"

mydomain="example.com"

support="techsupport@$mydomain"

accounts="/tmp/active_accounts"

logrotate_conf="/etc/logrotate.d/zimbra"

rotate="0"

touch $accounts
su zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts
#zgrep -i "auth ok" $logfile | sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$11;}' | uniq -c | sort -n |

#zgrep -i "auth ok" $logfile | sed 's/@example.com//g' | sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$11;}' | uniq -c | sort -n |

zgrep -i "sasl_username" $logfile | sed 's/@example.com//g' |sed 's/ / /g' | awk -F"[ :]" '{print $3":"$4,$13;}' | sed 's/sasl_username=//g' | uniq -c | sort -n |

while read line

do

count=`echo ${line} | cut -d' ' -f 1`

userid=`echo ${line} | cut -d' ' -f 3`

timestamp=`echo ${line} | cut -d' ' -f 2`

active=`grep "$userid@$mydomain" $accounts`
if [ "$count" -gt "$maxmails" ] && [ "$active" == "$userid@$mydomain" ]; then

echo "Maximum email rate exceeded, $userid@$mydomain will be locked"

su zimbra -c "/opt/zimbra/bin/zmprov ma $userid@$mydomain zimbraAccountStatus locked"

subject="$userid account locked due to excessive connections"

# Email text/message

message="/tmp/emailmessage.txt"

echo "$userid account has been locked as there were $count connections made at"> $message

echo "$timestamp. Please have the user change their password, and check for phishing" >>$message

echo "emails if possible." >>$message

# send an email using /bin/mail

/usr/bin/mail -s "$subject" "$support"
rm -f $message



# set flag to rotate logs so that after mitigation the account does not automatically re-lock

rotate="1"

#update list of active accounts

su zimbra -c "/opt/zimbra/bin/zmaccts" | grep "@" | grep active | awk '{print $1}' > $accounts

fi

done
if [ $rotate -eq "1" ]; then

#rotate the logs

logrotate -f $logrotate_conf

fi

rm -f $accounts

User avatar
quanah
Zimbra Alumni
Zimbra Alumni
Posts: 1668
Joined: Fri Sep 12, 2014 10:33 pm
Contact:

Identify compromised accounts

Postby quanah » Thu May 01, 2014 8:10 pm

You have to restart postfix for this to be effective, unfortunately. :/ As I noted previously, they are using a permanent smtp connection, there are not actually additional sasl_auth's occurring, that's an artifact of postfix logging. The only way to close out the connection is to restart postfix.
--
Quanah Gibson-Mount
Product Architect, Symas http://www.symas.com/
OpenLDAP Core team http://www.openldap.org/project/
User avatar
quanah
Zimbra Alumni
Zimbra Alumni
Posts: 1668
Joined: Fri Sep 12, 2014 10:33 pm
Contact:

Identify compromised accounts

Postby quanah » Thu May 01, 2014 8:13 pm

Also, I'd write my own script to get the accounts via ldap, that just pulls active accounts. ;)
--
Quanah Gibson-Mount
Product Architect, Symas http://www.symas.com/
OpenLDAP Core team http://www.openldap.org/project/
Klug
Elite member
Elite member
Posts: 2365
Joined: Mon Dec 16, 2013 11:35 am
Contact:

Identify compromised accounts

Postby Klug » Fri May 02, 2014 5:16 am

Quanah, does the same "caching/closing connection issue" exist when a password is changed?
User avatar
quanah
Zimbra Alumni
Zimbra Alumni
Posts: 1668
Joined: Fri Sep 12, 2014 10:33 pm
Contact:

Identify compromised accounts

Postby quanah » Fri May 02, 2014 11:43 am

There is no "caching" issue. Persistent connections are part of the SMTP specifications, and not interrupting established connections arbitrarily is also part of the SMTP specifications. The only way to force close an established connection is to restart postfix. I already had a bit of a discussion about this with Wietse. ;)
--
Quanah Gibson-Mount
Product Architect, Symas http://www.symas.com/
OpenLDAP Core team http://www.openldap.org/project/
Klug
Elite member
Elite member
Posts: 2365
Joined: Mon Dec 16, 2013 11:35 am
Contact:

Identify compromised accounts

Postby Klug » Mon May 05, 2014 6:16 am

OK, got it...

As long as the spammer is connected, we're doomed. And we need to restart postfix.
essential_mix
Posts: 11
Joined: Sat Sep 13, 2014 3:07 am

Identify compromised accounts

Postby essential_mix » Tue Jul 15, 2014 10:33 am

If they used auth token, need to check which token is sending email and after that figure out, which user was used to create this token.
milos.cuculovic
Posts: 4
Joined: Tue May 05, 2015 2:55 am

Re: Identify compromised accounts

Postby milos.cuculovic » Wed Apr 25, 2018 10:01 am

The shell script works so nice, thank you very much.

I have a question: let's asume we are able to solve the issue by changing the compromised user password within the same day, the script will lock it again. What do you think would be the best solution to solve this issue?
What came to my mind:

- Add a whitelist of solved accounts, but needs to be manually done and may be forgotten to then remove the solved user from that list later on
- A better solution would be to check when was the user's password changed last time? If the password change time is greater than the compromised time, then we can ignore it.

What do you think about?

Return to “Administrators”

Who is online

Users browsing this forum: No registered users and 16 guests