Protecting Against Spammers who Compromise Messaging Server User Accounts

h1. Best Practices for Protecting Against Spammers who Compromise Messaging Server User Accounts

_By Shane Hjorth_

This document contains the following sections:
{toc:minLevel=2|maxLevel=4}

h2. Overview of Email Spammers and Compromised User Accounts

Spammers are now using sophisticated phishing attacks to target individual organizations and collect valid login details from ill-informed and overly-trusting account owners. Phishers then use these compromised account details to send spam emails by authenticating to the Messaging Server MTA and Webmail processes, thus bypassing this security restriction.

As the spam emails are delivered external recipients, Realtime Black-list's (RBLs) are listing these sending organizations. This in turn is causing legitimate non-spam emails to be rejected by organizations that use these same RBL's.

This document provides best-practice information on how to protect your organization against phishers and compromised user accounts. It provides proactive and reactive methods to reduce the impact of compromised accounts.

h2. Preventing Outbound Spam: Proactive Methods

Reduce the chances that a targeted phishing attack succeeds by implementing preventative measures such as:
* Educating your account holders. This is the best method to proactively avoid problems. For example, send regular reminders that your organization will *never* ask for account details by using email, and that users need to immediately report such emails. Set up an appropriate role account for this task.
* Implementing anti-spam and anti-virus applications that check for phishing style email. For more information, see [Planning a Messaging Server Anti-Spam and Anti-Virus Strategy|http://docs.sun.com/app/docs/doc/819-4439/acrkw?a=view].
* Blocking known phishing addresses or common role accounts from sending emails from outside the organization, for example, {{helpdesk@domain.com}}, {{security@domain.com}}, and so on. See [http://code.google.com/p/anti-phishing-email-reply/] for more information.
* Using good password policies. Stop easy-to-guess passwords (this includes administration accounts and role accounts, that is, {{uid=admin}}, {{calmaster}}, and so on) to protect against dictionary attacks. Use password expiry to force users to change passwords on a regular basis.
* Authenticated emails with different From: addresses (especially if not for the organization) increase the chances that your email accounts are used for sending out spam, or indeed used for additional phishing attacks against other organizations.

h2. Preventing Outbound Spam: Reactive Measures

The features described in this section were introduced in *Messaging Server 7 update 2*
{panel}

When a compromised user account is used to send emails to a large number of external email addresses, it is highly probable that a number of these email addresses will be invalid or trigger spam filtering mechanisms at the recipient server end and be rejected. Through the use of the {{LOG\_ACTION}} mapping table and metermaid, it is possible to restrict email upload based on these rejections. Further details are available in the [Blocking submissions of local senders who may be spammers|CommSuite:Triggering Effects From Transaction Logging. The LOG_ACTION Mapping Table#TriggeringEffectsFromTransactionLogging.TheLOG_ACTIONMappingTable-Blockingsubmissionsoflocalsenderswhomaybespammers] section of the [Triggering Effects From Transaction Logging: The LOG\_ACTION Mapping Table|CommSuite:Triggering Effects From Transaction Logging. The LOG_ACTION Mapping Table] documentation.

h4. Rate Limiting All Outgoing Email

Rate limit outgoing email as shown in this [example|http://msg.wikidoc.info/index.php/Rate-limiting_emails_sent_from_UWC]. Use different levels of restrictions depending on the "trust" of the IP address of the client sending the email, for example:
{panel}
=> most emails for internal auth-send
=> less emails for internal non-auth-send
=> less emails again for external-auth-send
=> less emails again for mshttpd source (Webmail emails) for practical reasons a human cannot send a lot of emails via Webmail in a short period of time.
{panel}

h4. Rate Limiting Only Outgoing Spam

Implement scanners/spam filtering on outgoing email. One idea is to use a spam filter, such as SpamAssassin, to flag messages as 'spammy' and call a Sieve action that calls a mapping rule, which calls MeterMaid to monitor the count of these emails (on env-from address). If the number of emails exceeds some threshold then perform an action on the email, for example hold, capture a copy, discard, bounce, and so forth.

For more information on this technique, see [Can Sieve Scripts Use Functions Defined Via Mapping Tables?]

An example:

Configure your anti-spam scanner to add an X-header to all outbound messages that indicates whether the message is spam.  E.g.
{code}
X-Spam-Score-Internal: ****
{code}
Add the following to a channel that processes your outbound mail.  This will cause a sieve filter to be executed for all messages dequeued from that channel.  You can also use a destinationfilter, depending on your environment.

{code}
 sourcefilter file:IMTA_TABLE:authspam.filter
{code}
Create a sieve filter called "authspam.filter" in your config directory.  It checks to see if the message is rated as spam (from the X-header) and it extracts the env-from and env-to from the message.  It makes a call to a mappings table with the env-from and the env-to as arguments.  It then rejects the message back to the env-from if it gets a positive response from the mappings.
The next step after identifying a compromised account is to prevent further misuse of the account by spammers and address any negative consequences e.g. being listed on blacklist. The following techniques will provide a starting point:
{code}
require ["variables","reject","envelope"];

# only limit messages rated as spam
if header :contains "X-Spam-Score-Internal" "****" {

    # pull out the envelope from address
    if envelope :all :matches "from" "*" {
        set "FROM_ADDR" "${1}";

        # pull out the envelope to address
        if envelope :all :matches "to" "*" {
            set "TO_ADDR" "${1}";

            # perform FILTER_limitauthspam mapping callout
            if limitauthspam "${FROM_ADDR}|${TO_ADDR}" {
                set "RESULT" "${0}";

                # reject the message
                reject "Your account has been sending a lot of messages that appear to be spam. ";
            }
        }
    }
}
{code}
Put this in the mappings.  The sieve script makes a call to this mapping to query metermaid.   The mapping includes exemptions if the env-to matches recipients that you want to be able to recieve spam messages from your users.

{code}
 FILTER_limitauthspam

 *|is-spam@*                    $N$E
 *|not-spam@*                   $N$E
 *|abuse@*                      $N$E
*|postmaster@*                 $N$E
 *|*      $[IMTA_LIB:check_metermaid.so,throttle,limitauthspam,$0]$0$Y
{code}
Set these options in configutil to enable the metermaid database.  This will cause metermaid to allow 50 outbound spam messages per hour for each env-from address.

{code}
metermaid.table.limitauthspam.data_type = string
metermaid.table.limitauthspam.quota = 50
metermaid.table.limitauthspam.quota_time = 3600
metermaid.table.limitauthspam.options = nocase
metermaid.table.limitauthspam.max_entries = 1000
{code}
Note: This won't work if the messages aren't rated as spam.  419 scams are notorious for slipping through spam filters.

It's possible for the spammer to forge their env-from address.  If this occurs, the sieve will need to be updated to accommodate. Or, do not allow outgoing email with a different From: address.

h4. Reject/Discard All Outbound Spam

If your tolerance for outbound spam is high, and you don't care about the occasional message being blocked by your spam filter, rejecting or discarding all outbound spam message back to the sender is an effective way to deal with the event of a compromised account.

You may want to disable "IP reputation checks" in your spam scanner for when it processes your outbound mail since many consumer IPs will be on black lists.

If you are rejecting the messages back to the sender, be careful that you are only rejecting mail to authenticated senders. If you want to prevent outbound mail that you are forwarding, then you should not reject the mail since it will backscatter out to the internet and get your servers blacklisted. Consider discarding or quarantining this mail instead.


h2. Recovering From Phishing Attacks That Have Compromised User Accounts

The next step after identifying a compromised account is to prevent further misuse of the account by spammers and address any negative consequences e.g. being listed on a real-time blacklist. The following techniques will provide a starting point:
* Prevent further logins of the comprised user account:
** Mark account as inactive ({{mailUserStatus: inactive}}).
** Change the password of the account.
** Advise the local IT support helpdesk that access to the account has been blocked so that should the owner contact the IT help desk they can work with the customer to use improved password policies, and so on, in the future.
* Kill any existing logins by using the {{./imsconnutil \-k \-u uid}} command (starting with Messaging Server 6.3).
* Block the IP address used to send the email at your network firewall.
* Kill any existing webmail sessions to prevent re-use.
** Increase logging to Information. This is required to capture the session ID information:
{noformat}
./configutil -o logfile.http.loglevel -v Information
{noformat}
** Disable http IP security. With IP security enabled, only the IP address that initially logged into the webmail process will be able to logout.
{noformat}
./configutil -o service.http.ipsecurity -v no
{noformat}
** Restart mshttpd processes.
{noformat}
./stop-msg http;./start-msg http
{noformat}
** If you find an account is compromised, locate the login string with the SID (session ID), for example:
{noformat}
[05/May/2009:12:23:21 +1000] server httpd[7257]: Account Information: login [129.158.87.204:51539] user001
plaintext sid=YvgZdFHgwx0
{noformat}
** Change/reset the password for the compromised account.
** Use {{wget}} to log out the session:
{noformat}
wget -o /dev/null "https://<server name>/cmd.msc?sid=<session ID>&cmd=logout"
for example:
wget -o /dev/null "https://server.aus.sun.com/cmd.msc?sid=YvgZdFHgwx0&cmd=logout"
{noformat}
* Find and remove any existing spam email sent via the compromised account in the tcp_local MTA queue.
* Find out if you have been black-listed: [spamcop|http://www.spamcop.net/bl.shtml], [Realtime Blackhole List Lookup|http://www.mob.net/~ted/tools/rbl.php3].
** To remove yourself from a blacklist depends on the list. For example, see [spamhaus.org|http://spamhaus.org] and [mail-abuse removal request|http://www.mail-abuse.com/removereq_rbl.html].
* Vary the IP address of your outgoing smtp client for the tcp_local channel.
** Bind outgoing email to a IP address by using the interfaceaddress SMTP channel option.
** If an IP address gets blacklisted, shift to another IP address (be careful if you are using SPF).
* Enable Directory Server audit log: monitor for changes, such as signature files and reply-to address, by using a script and crontab to classify likely compromised accounts; remove modifications.

h2. Greylisting Webmail

The following proof-of-concept instructions describe how to enable greylisting of emails that are sent through the webmail process (Messaging Express, Communications Express, or Sun Convergence). You use the third-party [gross daemon|http://code.google.com/p/gross/] and plug-in to provide greylisting functionality. One advantage of the gross daemon is that you can configure greylisting only if the sender's IP address is also on a blacklist.

h4. Requirements for Greylisting Webmail

The software requirements for configuring greylisting on webmail are:
* Gross Daemon: You can run the daemon on the same server as Messaging Server or on another server.
* At least Messaging Server 7.0 MTA: Messaging Server 7.0 inclues the ereject Sieve functionality that you use to cause emails to be rejected.
* At least Communications Express 6.3p4: This version contains a fix for CR 6648111 (UWC should pass client IP address to {{mshttpd}} for use in mail headers).
* At least Messaging Server 6.3: This version contains a fix for RFE 6424798 (Have MEM recognize "Proxy-ip: header for use in passing client IP back to {{mshttpd}}).

h4. Installating and Configuring Greylisting for Webmail

# Download, compile, configure and start the gross daemon.
See [Quick Start Guide|http://iamthek.com/archives/30] and [http://code.google.com/p/gross/].
# Copy the {{grosscheck.so}} library file, compiled as part of the compilations of the gross daemon, to the MTA server's _msg_base{_}{{/lib}} directoy.
# Compile and install the {{c-ares}} library on the MTA server.
{info:title=Note}If the platform that is running the gross daemon is different from the MTA server platform, recompile the gross daemon to get a compatible{{{}grosscheck.so}} library.
{info}
# Configure the Messaging Server 7.0 MTA by creating a new file in the _msg_base{_}{{/config}} directory called {{greylist.sieve}} containing the following code:
{code}
require ["ereject","variables"];
# Need to extract IP address from Received Header
# Require UWC6.3p4 and above to add the Forward-For: header
if (header :matches "Received" "*(Forwarded-For: *)*") {
set "IP_ADDR" "${2}";

# Need to extract header from address
if (header :matches "From" "*<*>*") {
set "FROM_ADDR" "${2}";

# Perform FILTER_GREYLIST mapping callout
set "RESULT" greylist("${IP_ADDR}|${FROM_ADDR}|uwc");

# Block if greylist check returns a value -- indicating that they are a 'bad' sender
if (not string :is "${RESULT}" "")
{ # *NOTE* erejec is used instead of erejec(t) to workaround bug
#6704720
erejec "Delivery failed. Please wait 10 seconds and try sending again...";
}
}
}
{code}

# Add the following to the _msg-svr-base{_}{{/config/mappings}} file:
{code}
FILTER_GREYLIST

! use gross to check all triplets (client_ip,sender,recipient)
*|*|*
$C$[IMTA_LIB:grosscheck.so,grosscheck,129.158.87.192,,5525,$0,$1,$2,]$Y$E
* $Y
{code}
# Add the following to the source channel in the _msg-svr-base{_}{{/config/imta.cnf}} file that accepts email from the {{mshttpd}} process, that is, {{tcp_intranet}}, {{tcp_uwc}}:
{code}
sourcefilter file:IMTA_TABLE:greylist.sieve
{code}
# Recompile and restart the MTA.
{{*./imsimta cnbuild;./imsimta restart{*}}}

h4. Troubleshooting Your Greylisting Deployment

# Configure the {{gross.conf}} file to use a blacklist that returns a result for _all_ IP addresses, for example:
{code}
dnsbl = relays.ordb.org
{code}
# Run the {{grossd}} process in the foreground, for example:
{{*./gross \-d{*}}}
# Attempt to send a test email.
You should see message similar to the follwing in the gross output:
{noformat}
Fri Jul 18 16:34:53 2008 #9: a=greylist d=2 w=1 c=129.158.87.66 s=uwc r=user@example.com m=relays.ordb.org+1
{noformat}
Webmail users should receive an error message in their email client such as:
{noformat}
SMTP Error 5.7.1 Delivery Failed. Please wait 10 seconds and try sending again
{noformat}
If users receive such an error, instruct them to Click OK, wait 10 seconds, then click the Send button again. The following message should then appear in the gross output:
{noformat}
Fri Jul 18 16:42:48 2008 #a: a=match d=0 w=0 c=129.158.87.66 s=uwc r=user@example.com
{noformat}
The email should also be accepted.