Warning: is_readable(): open_basedir restriction in effect. File(C:\Inetpub\vhosts\caznet.com.au\httpdocs/wp-content/plugins/C:\Inetpub\vhosts\caznet.com.au\httpdocs\wp-content\plugins\wp-mail-smtp/languages/wp-mail-smtp-en_US.mo) is not within the allowed path(s): (C:/Inetpub/vhosts/caznet.com.au\;C:\Windows\Temp\) in C:\Inetpub\vhosts\caznet.com.au\httpdocs\wp-includes\l10n.php on line 584
Shane Clay – Caznet Solutions

Like many of the technologies we rely on which were developed in a pre-global-internet world, the entire system is built on trust. Unfortunately the days of a trustworthy Internet are long gone and while MSPs, CTOs, global security companies and home users alike are scrambling to ensure their networks, firewalls and operating systems are secure, E-mail tends to be forgotten about.

A systematic and sensible approach to email security applying some mature and well documented techniques can save a lot of pain:

1. Get your mail server (if you have one) and domain setup right!

This one should be obvious, but its surprising how many mail servers and domains I come accross that are just poorly configured. Heres the things you should be doing:

  1. Configure your HELO so that when you connect to an external mail server you present a real, fully qualified domain. For example: mail.example.com, instead of exchange-server.companydomain.local. This HELO will preferably be a DNS record that can be connected back to for email delivery.
  2. If your ISP allows for it, set the PTR record of your IP address to match the HELO of your mail server.
  3. Keep your MX record priority around 10. Sending servers always prefer to send email to the record with the lowest priority. Therefore, why not set it to 0? Because if you ever need to make changes, you’ve no where else to go. If its set to 10, you can add higher and lower priority servers without changing your existing setup.
  4. Remove any mail.mydomain.com records from your DNS if they aren’t being used.

2. Basics first… the firewall

This bit is simple. When it comes to the firewall – email comes in, and email goes out…

Do your users and devices need to be able to send email directly to the outside world? If you have a central mail server (such as Microsoft Exchange) or you’re using a hosted mail service (something like Google Mail or Microsoft Office 365), then the answer to this is probably NO!. If thats the case, block Port 25 outbound for devices that don’t need it.  If you have some devices (such as a printer) that do, configure them to relay through to your internal mail server, hosted service or (if you’ve no other choice) your ISP.

As for incoming email – you only really have control over this if you’re hosting your own mail server. If thats the case, you’re probably using a hosted mail security service (such as ours… Caznet Email Guardian) and you should block all incoming email that doesn’t originate from their servers. Its extremely common for spammers to deliver email directly to an IP rather than using a domain and its MX records.

3. Anti-Spam & Anti-Virus

If you’re not running some form of Anti-Virus and Anti-Spam filtering on your inbound email… you should be! For on-premises email servers (Exchange… etc…), there are a wide variety of plug ins available which will do the job. A better alternative is hosted email security that receives and processes all inbound email for Spam, Viruses, Malware and other threats before it ever reaches your mail server. We’ve been providing this service as Caznet Email Guardian since 2006.

The product you select should have some key features:

  • Bayesian Filtering
  • Realtime Black Lists
  • Blocking email before it reaches your users inbox (not just send it to junk mail)
  • The ability to create global and per-user white lists and black lists
  • The ability to block certain attachment types (and not give your users the ability to override it) such as EXEs
  • Per-user reporting (preferably automated)

Hosted mail services such as Google Mail and Microsoft Office 365 provide some of this protection built in. However, the results vary and reporting/customisability is generally fairly poor. We recommend an additional layer you can control in front of your hosted email service.

4. Sender Policy Framework (SPF)

Despite SPF being around for quite a while, its very poorly done in general. In principal it’s simple… each domain publishes a list of servers who are authorised to send email from that domain (using DNS). For example: here is the SPF record for one of our clients domains:

“v=spf1 mx a ip4:202.6.150.28 include:spf.caznet.com.au include:spf.protection.outlook.com -all”

Lets take a look at what that all means:

Essentially we’re saying that all email from this domain will originate from a server on the domain (listed in DNS), Office 365 or Caznet Solutions. The “-all” at the end means this is a complete list and any other sender should be rejected. If you’re unsure, replace it with “~all” but for the sake of security you should spend the time to get it right.

A great tool for constructing your SPF record can be found here: https://www.spfwizard.net/

Don’t forget to include your Mail Server, ISP, Hosted Email Services and any Software as a Service products you use.

5. TLS!

This one is irrelevant if you’re using a hosted mail service. But if you’re hosting your own mail server then pay attention…. are you using TLS? Why Not?

TLS stands for Transport Layer Security. Think HTTPS… When you enable TLS on your inbound and outbound email, the actual SMTP traffic itself is encrypted using a public certificate as it travels over the internet. It’s designed to stop man-in-the-middle attacks and also, like HTTPS, verify the identity of each server involved in the email transmission to the other. When an SMTP session is opened between two servers, they negotiate, and if TLS is available they establish the secure channel before email transmission begins. There are no changes required to your firewall (it uses port 25) or your domain. Just turn it on and supply it with a certificate.

All the big email service providers are supporting TLS and it takes very little to setup on most mail servers. Even better, you don’t actually need a publicly signed certificate. A self-signed one will do just fine meaning this is totally free to setup.

6. DomainKeys Identified Mail (DKIM)

DKIM is really the next generation of E-Mail security but what it does is fairly simple. When your mail server sends an email from your domain, it signs it with a publicly accessible public key that verifies the email originated from the domain it claims to have come from and that the content of the email hasn’t changed. So, how does it work?

  • Each mail server responsible for sending email from your domain has a public and private key for email signing. The public key is published in DNS as a TXT record that might look something like this (there may be more than one):

ceg._domainkey.caznet.com.au =”v=DKIM1; k=rsa p={very long string of random text here – this is the public key}”

  • When the mail server sends an email, it generates a series of headers which indicate which fields within the email (From Address, Subject, etc) are a part of the signature.
  • The signature is then signed using those fields and the servers private key. That signature is then added to the email headers.
  • When the email is received by a server, it can look for the public key in DNS and use that to confirm the signature is correct, thereby confirming the email originated from an authorised server and that the signed fields have not been modified since the email was signed.

How does this help us? Well… it makes it much more difficult for an unauthorised third party to send email using your domain name and allows receiving servers to verify the origin. This will make more sense once you implement DMARC.

DKIM is available on Microsoft Office 365, but if you’re not using their DNS servers you’ll need to do some manual configuration: https://technet.microsoft.com/en-au/library/mt695945(v=exchg.150).aspx

7. Domain Message Authentication Reporting & Conformance (DMARC)

DMARC is the black sheep of E-Mail security because very few understand it. However, its very simple and extremely powerful.

In essence, DMARC tells recipient servers what to do with email they receive from your domain that do not match your SPF and/or DKIM policies.

Lets take a look at the DMARC policy for caznet.com.au:

What am I doing here? I’m telling the world that if you receive an email from *@caznet.com.au which does not come from any of the hosts listed in my SPF record and is not DKIM signed, then outright reject it because it didn’t originate from us.

There is an excellent break down of the DMARC options available here: https://dmarc.org/overview/

In summary…

  • Get your mail server setup squeeky clean.
  • Lock the firewall down as much as you can on inbound and outbound port 25.
  • Get a quality anti-virus and anti-spam system in front of your mail… preferably something hosted externally to your server.
  • Make sure your SPF records are up to date.
  • Start securing your email sending and receiving with TLS.
  • Sign your outgoing mail using DKIM.
  • Publish a DMARC policy to help recipients identify phishing email using your domain.