Using DKIM, SPF & DMARC to Protect your Brand and Customers from Spear Phishing

Introduction

Scammers use a variety of tactics to get users to give out personal information. One very common tactic is known as phishing. Phishing is a scam where tech-savvy con artists use spam and malicious websites to deliver malware, or to trick people into giving them personal information such as social security numbers, bank account numbers, and credit card information. A more targeted (and often more dangerous) type of phishing is known as spear phishing.

What is Spear Phishing?

Spear phishing is a targeted attack that’s usually addressed to a specific individual. With spear phishing, the perpetrator knows something personal about you. He may know your name, email address, or the name of a friend, or he may have information about a recent online purchase you made. While most phishing emails will have a generic greeting such as “Dear Sir or Madam,” a spear phishing email may address you by name, such as “Hello John.” It may also appear to come from someone you know.

According to Allen Paller, director of research at the SANS Institute, 95% of all attacks on enterprise networks are the result of spear phishing attacks. Earlier this year, Symantec issued a warning about an ongoing spear phishing attack targeting small and midsize businesses in the United States, India, and the UK that infects users with a remote access Trojan (RAT). A RAT gives an attacker remote access to a machine & can lead to disclosure of sensitive information and financial losses. Based on campaigns run by Symantec’s Phishing Readiness technology, on average, employees are susceptible to email-based attacks 18 percent of the time.

How can You Protect Yourself & Your Business?

Protecting your company from spear phishing attacks is the responsibility of employees as well as the mail server administrator. For employees, user education is key. This post contains helpful email safety tips for end users. For the administrator, implementing DKIM, SPF and DMARC can help reduce data breaches, financial losses, and other threats to your business. These three methods are described in greater detail below.

How DKIM Works

DKIM (DomainKeys Identified Mail) is a cryptographic email verification system that can be used to prevent spoofing. It can also be used to ensure message integrity, or to ensure that the message has not been altered between the time it left the sending mail server and the time it arrived at yours. Here’s how DKIM works:

  • An encrypted public key is published to the sending server’s DNS records.
  • Each outgoing message is signed by the server using the corresponding encrypted private key.
  • For incoming messages, when the receiving server sees that a message has been signed by DKIM, it will retrieve the public key from the sending server’s DNS records and then compare that key with the message’s cryptographic signature to determine its validity.
  • If the incoming message cannot be verified then the receiving server knows it contains a spoofed address or has been tampered with or changed. A failed message can then be rejected, or it can be accepted but have its spam score adjusted.

You can refer to the following knowledge base article for DKIM setup instructions in MDaemon:

How to enable DKIM signing and configure records

You can refer to this knowledge base article for DKIM setup instructions in SecurityGateway:

http://www.altn.com/Support/KnowledgeBase/KnowledgeBaseResults/?Number=496

How SPF Works

Another technique to help prevent spoofing is known as SPF. SPF (Sender Policy Framework) allows domain owners to publish DNS records (SPF records) to identify those locations authorized to send messages for their domain. By performing an SPF lookup on incoming messages, you can attempt to determine whether or not the sending server is permitted to deliver mail for the purported sending domain, and consequently determine whether or not the sender’s address may have been forged or spoofed.

MDaemon’s SPF settings are located under Security | Security Settings | Sender Authentication | SPF Verification. This screenshot displays the recommended settings.

SPF Settings in MDaemon

Recommended Sender Policy Framework Settings

Recommended SPF settings for SecurityGateway are outlined in this knowledge base article:

http://www.altn.com/Support/KnowledgeBase/KnowledgeBaseResults/?Number=497

These are the recommended settings for verifying SPF records of other domains. To help protect against spear phishing attacks that spoof your own domain, you should set up an SPF record in DNS. You can find helpful information on SPF record syntax and deployment at www.openspf.org.

DMARC (Domain-Based Message Authentication, Reporting & Conformance)

When a message fails DKIM or SPF, it is up to the receiving mail server’s administrator as to how to handle the message. The problem with this is that if DKIM or SPF is not set up properly, it can lead to problems. DMARC (Domain-based Message Authentication, Reporting and Conformance) takes out the guesswork on how to handle messages from a domain that are not properly aligned with DKIM or SPF.

DMARC defines a scalable mechanism by which a mail sender can express, using DNS records (DMARC records), domain level policies governing how messages claiming to come from his or her domain should be handled when they do not fully align with DKIM and SPF lookup results. In other words, if you perform SPF, DKIM and DMARC record lookups on a message claiming to come from my domain (example.com), and it does not align with SPF, DKIM, or both, my DMARC record can tell you how I want you to handle messages that are unaligned with SPF & DKIM. My DMARC record can specify whether I want you to accept, quarantine, or reject unaligned messages, and I can even go a step further and specify what percentage of unaligned messages I want you to reject or quarantine based on my policy preferences. This is useful when first deploying DMARC, as it allows you to be more lenient with rejection of unaligned messages until you’re sure DKIM & SPF are configured properly.

You can view the following recorded webinar for a more in-depth overview of DMARC, including examples and syntax of DMARC records and deployment strategy.

https://youtu.be/vrMMKmxCmqs?list=PLt-aAHf-ocsYYmpXFABce39b_CgJXXubp

This knowledge base article will also be useful:

How to Enable DMARC and Configure Records

Conclusion

While we must be vigilant against spoofing and phishing attacks, we must also acknowledge that cautious, informed users and properly implemented SPF, DKIM and DMARC policies are the best defense against cybercriminals who are intent on stealing your data and damaging your brand.

SSL & TLS Best Practices

You may have heard the terms SSL and TLS, but do you know what they are and how they’re different?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are methods of securing (encrypting) the connection between a mail client and mail server (Outlook and MDaemon, for example) or between mail servers (MDaemon and another mail server, for example). They are also methods for securing communications between websites and your browser. In this post, we’ll focus on its uses for encrypting email connections.

Without SSL or TLS, data sent between mail clients and servers would be sent in plain text. This potentially opens up your business to theft of confidential information, credentials being stolen and accounts being used to send spam. SSL and TLS can be used to help protect that data. SSL and TLS allow users to securely transmit sensitive information such as social security numbers, credit card numbers, or medical information via email.

How do SSL and TLS work?

In order to use SSL or TLS, you’ll need an SSL certificate to establish an SSL/TLS connection. SSL certificates use a key pair (a public and private key) to establish a secure connection. When a mail client or server wants to connect to another server using SSL, an SSL connection is established using what’s known as an “SSL handshake.” During this process, three keys are used to establish an SSL connection – a public key, a private key, and a session key. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice-versa. Encryption via the public & private keys only takes place during the SSL handshake to create a symmetric session key. Once the secure connection is made, all transmitted data is encrypted with the session key.

This diagram provides a simplified overview of how an SSL connection is established.

How SSL & TLS workBoth SSL and TLS protect data privacy through data-in-motion encryption, provide server-side and (optionally) client-side encryption of the communication channel, and help ensure message integrity.

POP, IMAP and SMTP traffic are transmitted over designated ports. By default, IMAP uses port 143, POP uses port 110, and SMTP uses port 25. IMAP over SSL/TLS uses port 993. POP over SSL/TLS uses port 995, and SMTP over SSL/TLS uses port 465. For SSL to take place over these connection types, the mail client and mail server must both be configured to use the proper ports, and a valid SSL certificate must be installed on the server.

What are the Differences between SSL and TLS?

So what are the differences between SSL and TLS? TLS is the successor to SSL. It was introduced in 1999 as an upgrade to SSL 3.0, so TLS 1.0 is most similar to SSL 3.0 & is sometimes referred to as SSL 3.1, though TLS is not compatible with SSL 3.0. The version numbers for SSL are 1.0, 2.0 and 3.0, while TLS uses a different numbering pattern – 1.0, 1.1, 1.2.

Because TLS is incompatible with SSL 3.0, the client and server must agree on which protocol to use. This is accomplished via what’s known as a “handshake.” If TLS cannot be used, the connection may fall back to SSL 3.0.

Without getting too technical (there are plenty of online resources that explain the technical differences between SSL and TLS), here are some of the differences between SSL and TLS:

TLS has more alert descriptions – When a problem is encountered with an SSL or TLS connection, the party who encountered the problem would send an alert message.

SSL had the following 12 alert messages:

  • Close Notify
  • Unexpected Message
  • Bad Record MAC
  • Decompression Failure
  • Handshake Failure
  • No Certificate
  • Bad Certificate
  • Unsupported Certificate
  • Certificate Revoked
  • Certificate Expired
  • Certificate Unknown
  • Illegal Parameter

TLS has the following additional alert messages:

  • Decryption Failed
  • Record Overflow
  • Unknown CA (Certificate Authority)
  • Access Denied
  • Decode Error
  • Decrypt Error
  • Export Restriction
  • Protocol Version
  • Insufficient Security
  • Internal Error
  • User Canceled
  • No Renegotiation
  • Unsupported Extension
  • Certificate Unobtainable
  • Unrecognized Name
  • Bad Certificate Status Response
  • Bad Certificate Hash Value
  • Unknown PSK
  • No Application Protocol

TLS uses HMAC for message authentication – SSL verifies message integrity (to determine whether a message has been altered) using Message Authentication Codes (MACs) that use either MD5 or SHA. TLS, on the other hand, uses HMAC, allowing it to work with a wider variety of hash functions – not just MD5 and SHA.

TLS uses a different set of cipher suites.

A cipher suite is basically a combination of authentication, encryption, message authentication code (MAC) and key exchange algorithms used to negotiate security settings for a network connection. More information can be found here: https://en.wikipedia.org/wiki/Cipher_suite

Why are SSL and TLS Important?

Businesses have a responsibility to protect financial data such as credit card information, and consumer records such as names, addresses, phone numbers, and medical information. Without some form of encryption, whether via an encrypted connection using SSL & TLS, or by encrypting the message itself using Virtru or OpenPGP, sensitive data may be vulnerable to hackers & other forms of unauthorized access.

Which method is recommended?

SSL 3.0 suffers from a well-known vulnerability called the POODLE vulnerability. POODLE stands for Padding Oracle On Downgraded Legacy Encryption. Click here for a thorough overview of this vulnerability and recommended actions.  One workaround recommended in the overview is to completely disable the SSL 3.0 protocol on the mail client and server. This might not be practical, as it may affect legacy systems that are still using SSL 3.0.

We recommend using TLS whenever possible. TLS 1.2 is currently the best version for security, but it is not yet universally supported. TLS 1.1+ support was not added until Windows 7 and Server 2008 R2, in 2009.

The encryption protocol and cipher used by MDaemon and SecurityGateway depend on the operating system and can be configured via the registry. You can use the free IIS Crypto tool to set the appropriate registry keys. More information can be found here:
https://www.nartac.com/Products/IISCrypto

I hope this information helps clarify any questions about SSL and TLS, and which encryption method is recommended. As always, if you have questions or comments, let us know!