Protecting Against Spammers who Compromise Messaging Server User Accounts

Skip to end of metadata
Go to start of metadata

Best Practices for Protecting Against Spammers who Compromise Oracle Communications Messaging Server User Accounts

By Shane Hjorth

Topics:

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.

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.
  • 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.

Preventing Outbound Spam: Reactive Measures

Despite the best preventative measures, spammers can still acquire valid account details. By putting in place mechanisms to limit the number of email messages that users can send, you reduce the impact of compromised accounts. You should use these limiting techniques on both outgoing and incoming email.

Blocking Submissions of Local Senders Who Might Be Spammers

The features described in this section were introduced in Messaging Server 7 Update 2

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 section of the Triggering Effects From Transaction Logging: The LOG_ACTION Mapping Table documentation.

Rate Limiting All Outgoing Email

Rate limit outgoing email as shown in this example. Use different levels of restrictions depending on the "trust" of the IP address of the client sending the email, for example:

=> 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.

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.

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.

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:

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.

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.

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.

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.

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:
      ./configutil -o logfile.http.loglevel -v Information 
      
    • Disable http IP security. With IP security enabled, only the IP address that initially logged into the webmail process will be able to logout.
      ./configutil -o service.http.ipsecurity -v no
      
    • Restart mshttpd processes.
      ./stop-msg http;./start-msg http
      
    • If you find an account is compromised, locate the login string with the SID (session ID), for example:
      [05/May/2009:12:23:21 +1000] server httpd[7257]: Account Information: login [129.158.87.204:51539] user001
      plaintext sid=YvgZdFHgwx0
      
    • Change/reset the password for the compromised account.
    • Use wget to log out the session:
      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"
      
  • 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, Realtime Blackhole List Lookup.
  • 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.

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 Convergence). You use the third-party gross daemon 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.

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).

Installing and Configuring Greylisting for Webmail

  1. Download, compile, configure and start the gross daemon.
    See Quick Start Guide and http://code.google.com/p/gross/.
  2. 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.
  3. Compile and install the c-ares library on the MTA server.
    Note
    If the platform that is running the gross daemon is different from the MTA server platform, recompile the gross daemon to get a compatiblegrosscheck.so library.
  4. 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:
  1. Add the following to the msg-svr-base/config/mappings file:
  2. 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:
  3. Recompile and restart the MTA.
    ./imsimta cnbuild;./imsimta restart

Troubleshooting Your Greylisting Deployment

  1. Configure the gross.conf file to use a blacklist that returns a result for all IP addresses, for example:
  2. Run the grossd process in the foreground, for example:
    ./gross -d
  3. Attempt to send a test email.
    You should see message similar to the follwing in the gross output:
    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
    

    Webmail users should receive an error message in their email client such as:

    SMTP Error 5.7.1 Delivery Failed. Please wait 10 seconds and try sending again
    

    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:

    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
    

    The email should also be accepted.

Labels:
mta mta Delete
metermaid metermaid Delete
antispam antispam Delete
messagingserver messagingserver Delete
antivirus antivirus Delete
spam spam Delete
sieve sieve Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.