Puremessage and mitigating zero day APT

I have recently been involved in developing a number of MSSP security related products and services aimed at protecting very high profile customers. One of the constant queries that I get regarding the product development is how I go about mitigating or reducing the risk of Zero day attacks when everyone else seems to fail. Firstly there is no way to mitigate all possible Zero day APT attacks, Particularly ones that have been developed and social engineered over time. However there are a few ways to help reduce and or mitigate the low hanging fruit. Some of these methods are easy in PureMessage for UNIX and others are a little more complicated. There are a number of obvious first steps they are

  1. Curate the types of attachments that you allow through the email gateway. Don’t allow .exe files as one such example. No password protected zips etc.
  2. Use a the built in blocker daemon which ships with PureMessage for UNIX. It contains a well maintained and comprehensive list of known bad hosts or ISPs that have no-email policies.
  3. Ensure that low hanging fruit obvious invalid emails are dropped before being scanned and filtered. It reduces CPU, Memory, Disk load on the server by stopping the obvious at the earlier steps in the filtering process (smtpd).
  4. Ensure that the sender’s IP address reverse resolves.

In Postfix the smtpd configuration looks like this

smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_unknown_client_hostname, check_policy_service inet:localhost:4466, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, permit

2. blocker daemon

The blocker daemon in puremessage is called by the postfix check_policy_service stanza in the smtpd_recipient_restrictions in the main.cf file. A recommended configuration looks like this

    port = inet:4466@localhost
    blocklist_log = blocklist_log
    refresh_interval = 1m
    block_dynamic = no
    block_helo = no
    # Valid template variables for the configuration item <reject_message> are:
    #   %%IP%%: The IP address of the server from which the blocked message originated.
    #   %%TYPE%%: The reason that the message was blocked. The reasons include:
    #   IP - Matched data from SophosLabs.
    #   DYN - Matched dynamic sender data from SophosLabs.
    #   HELO - The HELO string of the connecting mail transfer agent is suspicious.
    #   CUSTIP - Matched an IP or hostname in the IP Blocking Inclusion list.
    #   CUSTRDNS - A glob match has been specified in the IP Blocking Inclusion list.
    #   DYNR - Matched a regular expression for RDNS mail senders.
    #   %%URL%%: The default URL that links to Sophos's web service. This variable
    #   must be replaced with an actual custom URL if you want the rejection message to
    #   direct recipients to a location other than the Sophos site.
    reject_message = Rejected by  email antispam solution : %%TYPE%%

It is possible to look up the dynamic IP addresses (generally home users on DSL). It is also possible to block based on the HELO lookup in the blocker configuration. In the above configuration I have neglected to set that configuration as I found that it blocked some legitimate emails coming from big businesses that do not have quality email services.

3. Low hanging fruit in SMTP negotiation

The following postfix configuration values need to be set to reject the obvious email. reject_non_fqdn_sender, reject_unknown_sender_domain . This configuration will blow any emails that come from domain names which do not resolve. It is recommended that this be done. Often typo squatters and fast flux DNS providers do not resolve in time for their emails which means they get rejected. the reject_non-fqdn_sender makes sure that the return domain is valid.

4. Reverse IP checks

reject_unknown_client_hostname is how to reject SMTP connections that do not reverse resolve.

PureMessage Policy

Due to intellectual property issues I am unable to post the entire policy. However the logical flow is as follows (in order).

  1. If the email originates from an untrusted external service.
  2. Validate that the remote sender address matches the origin country of the email.
  3. reject the email if the attachment is on a banned extension list.
  4. If the email has an attachment quarantine un-scanable emails.
  5. If the email has an attachment check that the SPF and DKIM both return as being VALID and TRUSTED. i.e the origin of the email is the legit email server.
  6. If the email SPF or DKIM FAIL either test or BOTH quarantine the attachment. Ensure that you have a quarantine notify that sends after 24 hours.
  7. If the email passes both the SPF, DKIM and has shown to have no virus continue to scan the email for all of the usual spam message characteristics and any other tests the organisation may have.

Using this simple logic we have found that the number of attachments quarantined because of an SPF of DKIM failure are often then found to be malicious 24 hours later. After running the logic above for 30 days here is the statistical breakdown.

  Total Emails: 171021
  SPF Fails with Attachments: 1209
  DKIM Fails with Attachments: 342
  Emails that scan clean after an hour after quarantine time: 1542
  Emails that scan clean after 24 hours from quarantine time: 560
  Emails that scan clean after 168 hours from quarantine time: 12

All of the remaining 12 emails got sent to anti-virus vendors to investigate. Of the three vendors all three came back saying that they are not malicious.

Tags: , ,