This chapter describes protecting against spam, viruses, and other attacks sent through Oracle Communications Messaging Server.
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 to external recipients, Realtime Blacklists (RBLs) are listing these sending organizations. This in turn is causing legitimate non-spam emails to be rejected by organizations that use these same RBLs.
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.
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 the discussion on integrating spam and virus filtering programs in the Messaging Server System Administrator's Guide.
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. For more information, see:
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.
Using 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.
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.
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. For further details, see the discussion on blocking potential spammers in the Messaging Server System Administrator's Guide.
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) because for practical reasons, a human cannot send lots of emails via Webmail in a short period of time
Implement scanners/spam filtering on outgoing email. One idea is to use a spam filter, such as SpamAssassin, to flag messages as spammy. It will also 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 such as: hold, capture a copy, discard, bounce, and so forth.
An example:
Configure your anti-spam scanner to add an X-header to all outbound messages that indicates whether the message is spam.
X-Spam-Score-Internal: ****
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.
sourcefilter file:IMTA_TABLE:authspam.filter
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 such as being listed on blacklist. The following techniques will provide a starting point:
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. ";
}
}
}
}
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 receive spam messages from your users.
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
Set these options to enable the MeterMaid database. This will cause MeterMaid to allow 50 outbound spam messages per hour for each env-from address. Table 6-1 shows the MeterMaid database options in both Unified Configuration and legacy configuration as well as the value of each option.
Table 6-1 MeterMaid Database Options
| Unified Configuration Option | Legacy Configuration Option | Value |
|---|---|---|
|
metermaid.local_table:limitauthspam.data_type |
metermaid.table.limitauthspam.data_type |
string |
|
metermaid.local_table:limitauthspam.quota |
metermaid.table.limitauthspam.quota |
50 |
|
metermaid.local_table:limitauthspam.quota_time |
metermaid.table.limitauthspam.quota_time |
3600 |
|
metermaid.local_table:limitauthspam.table_options |
metermaid.table.limitauthspam.options |
nocase |
|
metermaid.local_table:limitauthspam.max_entries |
metermaid.table.limitauthspam.max_entries |
1000 |
Note:
This will not work if the messages are not rated as spam. 419 scams are notorious for slipping through spam filters.It is 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.
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 blacklists.
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.
Experienced Messaging Server administrators know that dealing with spam is a high-priority job requiring constant attention as spammers evolve and refine their methods of attacks. Recently, many administrators have noted the rise of phishing attacks, especially against (but not exclusively) Webmail clients.
Long time Messaging Server administrators have been exchanging ideas and collaborating on all aspects of Messaging Server, including anti-spam/anti-virus techniques, by using the Info-iMS@sonnection.nl forum. In brief, this alias is the independent discussion forum for those interested in Messaging Server and all its permutations. If you are a Messaging Server administrator and haven't yet subscribed to this alias, we highly recommend that you do so.
An email thread from July 2008 highlighted the phishing problem, especially in the EDU space. Many ideas were suggested on how to combat this particular spam issue.
The following is a summary of anti-spam techniques to consider:
Examine the sent folder to get the source IP of the submission, then null route the IP address on the Webmail front ends.
Configure MeterMaid. MeterMaid limits the number of messages a user can send in a number of minutes regardless of source (SMTP, Webmail).
Use the imsconnutil -k -u uid command to disconnect the offending user account.
Block the offending IP address at your firewall.
Set the inetuserstatus attribute for the offending user to inactive, change the user's password, then clear the queue(s). This technique is in response to an attack, rather than preventing or detecting the attack.
Enable the Directory Server audit log. Monitor for changes to directory entries, such as signature files and reply-to addresses, by using a script and crontab to classify likely compromised accounts.
Read about Sun's recommendation for how to deploy the Messaging Server MTA and anti-spam/anti-virus scanning systems: http://www.oracle.com/technetwork/systems/networking/preferred-deploy-mta-jsp-135699.html
Call out to MeterMaid from the FROM_ACCESS mapping table, passing the user authentication as data rather than (or perhaps in addition to) calling out to MeterMaid from the PORT_ACCESS mapping table, passing the source IP as data. This technique limits how many messages some (authenticated) user can submit.
Use Postfix/Policyd. Then change the default smtphost of Webmail to use it.
Use this list of these password phishing reply addresses: http://code.google.com/p/anti-phishing-email-reply/
Implement scanning systems on both incoming and outgoing email.
Use the http://www.senderbase.org/ database.
You can use LOG_ACTION to block submissions of local senders who might be sending spam.
The next step after identifying a compromised account is to prevent further misuse of the account by spammers and address any negative consequences such as 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.
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:
Unified Configuration: msconfig set http.logfile.loglevel Information
Legacy Configuration: 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.
Unified Configuration: msconfig set http.ipsecurity 0
Legacy Configuration: 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 of 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 blacklisted: Spamcop, Realtime Blackhole List Lookup.
To be able to remove yourself from a blacklist depends on the list. For example, see: https://www.spamhaus.org and https://ers.trendmicro.com/.
Vary the IP address of your outgoing SMTP client for the tcp_local channel.
Bind outgoing email to an 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.
The following proof-of-concept instructions describe how to enable greylisting of emails that are sent through the Convergence Webmail process. Use the third-party gross daemon and plug-in to provide greylisting functionality:
http://code.google.com/p/gross/
One advantage of the gross daemon is that you can configure greylisting only if the sender's IP address is also on a blacklist.
Download, compile, configure, and start the gross daemon. See:
Copy the grosscheck.so library file, compiled as part of the compilations of the gross daemon, to the MTA server's MessagingServer_home/lib directory.
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 compatible grosscheck.so library.Configure the MTA by creating a new file in the MessagingServer_home/config directory called greylist.sieve containing the following 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...";
}
}
}
Add the following to the MessagingServer_home/config/mappings file:
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
Add the following to the source channel in the MessagingServer_home/config/imta.cnf file that accepts email from the mshttpd process, that is, tcp_intranet, tcp_uwc:
sourcefilter file:IMTA_TABLE:greylist.sieve
Recompile and restart the MTA. imsimta cnbuild; imsimta restart
Configure the gross.conf file to use a blacklist that returns a result for all IP addresses, for example:
dnsbl = relays.ordb.org
Run the grossd process in the foreground, for example: gross -d
Attempt to send a test email. You should see a message similar to the following 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.