Email Gateway Administration

I have been seeing many Email Gateway administrators are suffering from what the information security teams are looking for to protection/detection measures as well as to implement their security policies. The email attack vector is the most critical one since most of attackers these days are using advance tactics to initial their operations using very sophisticated techniques. 

In this blog, I will touch base on how to fine-tune your email traffic from configurational prospective; in another blog, I will talk on recommendations on this vector from security operational prospective. 

When we talk about the types of threats that you might encounter from this vector, the type of threat will come in one of the following forms: 

-      Attachments

-      URLs

-      Email body content 

-      DDos 

-      Spoofing 

The mechanisms or security controls that you might have can be on different levels for example, Email Gateway “Anti-Spam”, Email Sandbox, DLP, or protection on the Exchange server itself. In this blog, I will be talking only about the Email Gateway “Anti-Spam”; thus, in other blogs, I will talk about the Sandbox fine-tuning and configuration. 

The threats these days are very advance to the level it is very challenging to differentiate between legitimate and malicious ones. Thus, what policies and rules that we need to implement at the email gateway to minimize and mitigate this risk. I will talk briefly about these rules from my experience; meaning, you as email admin or security professional could have even more or better ones. 

Depending on your email gateway solution, the solution should be at least capable to give you the ability to implement these policies and rules to take actions to block, quarantine, or process. 

These rules are: 

-       Whitelisting policy; many vendors or standards will ask you to implement blacklisting policies for the attachments’ mime types. However, I don’t agree with this because the attacks are getting more sophisticated and the attackers might come up with new technique that will bypass your policy. 

-       Enable all AV, AS, URL lookups, Spoofing and other engines such as DLP or Heuristics; although they my increase the FP; thus, you need to keep fine-tune these engines. 

-       Quarantine encrypted or password protected attachments to manual inspection.  

-       Block fail to process / fail to modify; Implement in your incoming routes the “Failed to Process” and “Failed to Modify” content rules. They should have “Hold to Message Area” action. These content rules trigger when a message fails to be analyzed or modified, and thus they should be quarantined for manual inspection. 

-      Implement Recipient Validation for ALL domains if possible; most of the spam is sent blindly without attention to the recipient name in some sort of brute force attack, that also enables the spammer to discover who the existent/valid recipients are using a technique called Directory Harvest Attack (DHA). Recipient validation allows you to the accept only those messages that have a valid recipient and reject messages to invalid recipients if Reject Invalid Recipients is enabled. This greatly reduces the volume of spam to be processed.

-      Spam should be not be retained; spam could represent more than 90% of the total volume of messages you receive.

-      Enable sender authentication; you can enable SPF and SenderID sender authentication on a per domain basis and DKIM validation on a system-wide basis.

-      Try to use the "reject" action instead of "drop" or "defer" when possible; the idea behind this is: the more you reject, the less you process. Knowing that the vast majority of the inbound SMTP traffic received these days is spam (75-90%) this greatlyhelps to use the resources available to process valid messages. 

-      Enable Connection Classification; to use this feature the appliance must be deployed at the gateway (receiving SMTP connection from the original IP address). When enabled, it will restrict the quality of service to connections from sources that are known to send spam.

-      Enable Bounce Attack Prevention (BATV); Bounce Attack Prevention protects your systems from bounce attacks. BATV will identify fake Non-Delivery Reports (NDRs) and prevent backscatter attacks from entering the network with configurable actions, including rejecting or deleting these messages, while still allowing legitimate bounce message notifications to be delivered normally. If BATV is enabled, a SenderID record of the following form should be added to DNS in order to avoid emails being rejected due to SenderID. 

-      Make sure the inbound MTA "sees" the original source IP address for inbound connections; A high percentage of the spam messages can be rejected at the time the SMTP connection is made to the Email Gateway based on IP reputation. In order to take advantage of this feature, the email gateway requires the inbound connection to maintain the source IP address unmodified by any upstream host.

-      Do limit attachment sizes (your organization should establish that size)

-      Scan messages for keywords

-      Encrypt messages so that only the intended recipient can read them

-      Ensure that your email system is not being abused by unknown and/or malicious users; thus, integrated by your access control system to ensure Authentication, Authorization, and Accountability. 

-      You need to make sure that you are aware of – and can account for – the email coming into, going out of, and circulating around your organization. This means you must: Retain accessible records of relevant email communications, including log information that can show who sent what to whom and when.

-      Enable structural validation; Structural Validation content rule will look for additional data and files appended to image files (GIF, JPG, PNG, TIF). This is a technique where an attacker tries to append data to image files, in an attempt to bypass scanning. Structural Validation can identify if there are appended data in the above-mentioned media types and make them available to the analysis engine for further inspection according to the content rules in the policy route. Note: This content rule is expected to produce false-positive detections, especially in combination with the ‘Detect Unknown Binary’ content rule above. 

As I’ve mentioned above, this blog is only about the Email Gateway administration not about the Security Visibility, Security Operations, Sandboxing or other else. 

I hope this blog will help you to have better protection and feel free to add or discuss about this topic. 

Regards, 

Khalid Alateeq