DMARC and other protections for your email systems

In our first article on email spoofing, we presented the Sender Policy Framework (SPF) and the DomainKeys Identified Mail (DKIM) method as ways to secure email servers. The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard was addressed for testing SPF and DKIM functions and creating appropriate rules and measures. We explain this standard in more detail in this second article. In addition, we go further measures to secure your e-mail server against spam, phishing and relay attacks.

Table of contents

Are SPF and DKIM enough to protect against email spoofing?

Well blocked is not clicked

Email is the most used work tool in companies and unfortunately also the most vulnerable. Besides spam and phishing, it's often malicious attachments and links that give IT and management sleepless nights. The easiest way to protect yourself from such problems is to block attachments completely. However, this would affect the workflow too much in most companies.

Therefore, there is another solution: Whenever possible, all potentially harmful mails must be blocked or sent to quarantine before anyone can click on links or download attachments without thinking. (As a general rule, everyone in your company should "Think before you click!")

SPF and DKIM only protect if the receiving email server takes appropriate action when the corresponding checks fail. We show you how you, as a domain owner, can use the Domain-based Message Authentication, Reporting and Conformance (DMARC) standard to define recommended actions for these cases.

Would your colleagues click on a phishing link and enter their data there?
Find out and increase your user awareness with a penetration test!
To the penetration test

DMARC as a supplement to SPF and DKIM

DMARC is a standard developed at the initiative of several large tech companies (e.g., Google and Microsoft) to prevent spoofing attacks. It complements SPF and DKIM with important behavioral guidelines in case an audit of these records fails.

A special feature of DMARC is that these recommendations for action are not defined by the recipient, but by the sender. As a legitimate domain owner, you can therefore preemptively define what should happen to mails that supposedly come from your domain but do not pass the SPF/DKIM check: Should they be handled normally, end up in the spam folder or be discarded altogether?

Another important part of DMARC is the possibility to specify addresses for the automatic reception of reports. These give an insight into the statistics of sent mails. For example, you can keep track of how many mails from your domain have recently ended up in the spam directory of recipients. This can provide information about possible misconfiguration or malicious use of your domain. We recommend that you regularly check these reports with the help of visual processing tools to stay up to date.

Using DMARC correctly

Like SPF and DKIM, DMARC also works with TXT resource records in the sender's DNS server and builds on these entries. It is therefore not particularly useful to set just one DMARC record alone. Within this record lies the DMARC policy, with which the domain owner informs that messages from him are secured by SPF and/or DKIM. At the same time, he can give the recipient a recommendation on how to proceed with unauthenticated messages by means of predefined rules.

For example, you can create a subdomain "_dmarc" and set the corresponding resource record there. Within this record you can create several values. You separate them by a semicolon. Many of the possible entries are optional. Only the protocol version ("v"), as well as the policy, how to handle mails of the main domain ("p"), must be specified. However, we strongly recommend that you also specify the e-mail address for receiving reports ("rua"). This way you can analyze which mails are filtered out.

Restrictions on the use of DMARC

When implementing DMARC, you should proceed cautiously and gradually (similar to the implementation of firewall instances). In principle, it is possible to set the percentage of mails to which the DMARC policy is applied to 100%. However, we do not recommend this at the beginning. For the beginning, it is perfectly sufficient to set only the DMARC record and set the "pct" variable to "0". This opens the possibility to receive DMARC reports without having a direct effect on the delivery of the mails.

Once you have gathered enough information, you can gradually increase the percentage. This way you gradually apply the policy to more mails and increase the protection against spoofing.

DMARC is the first and only standard to date that checks the "From header" of a mail for validity. However, in addition to the desired increase in security, this also causes undesirable side effects. This is because DMARC sets very strict requirements. For example, a sent mail must be forcibly forwarded unchanged.

This leads to problems with the usual mailing lists, for example: With DMARC it is no longer so easy to exchange the "From header" of the mail. If you decide to do this, you have to remove the DKIM signature as well. Otherwise the recipient will not be able to verify it successfully. Depending on the settings of the mail flow rules of the receiving server, you run the risk that the mail will not arrive at all due to the missing signature.

In the following section, we will introduce you to the Authenticated Received Chain (ARC), through which you can get a handle on this problem.

Solution for problems with DMARC: Authenticated Received Chain (ARC)

ARC addresses precisely the major drawback of DMARC's strictness: It allows a mail relay server to sign the original authentication of the sent mail. This gives the recipient of a mail the possibility to verify the origin of the mail without considering the SPF and DKIM records (invalidated by the forwarding). Trust plays a major role here, as ARCs can be forged. So the recipient must determine whether to trust the ARC signatures or not.

What other measures can I take to protect my email server?

reverse DNS (rDNS)

Reverse Domain Name System (reverse DNS/ rDNS) requests help the receiving email server confirm the authenticity of the sender. This is done as follows: Before receiving the entire email body, the header information is checked. In addition, a DNS query is made with the sender IP and the domain specified in the HELO command. If the authoritative DNS server does not have a (matching) pointer record (PTR record) for the sender IP, the e-mail is discarded or moved to the spam area.

Sender Restriction

A domain owner can use the Sender Restriction to define which users within his domain are allowed to send e-mails "outside", i.e. beyond his own domain. Using Postfix as an example, two different lookup tables are used here: one table in which all users with restrictions are listed, and another in which all "local" domains are defined. If a restricted user now wants to send a mail to a domain that has not been marked as local in the config, he will be rejected with a generic message.

Mail Transport / Mail Flow Rules in O365

As already mentioned, you can use different sets of rules for your domain, which make it easier for you to deal with spam and other e-mails. You can imagine it like this: There is an employee in front of your mailbox who checks every letter that is posted using a set of rules that you have defined. Based on these rules, the employee decides whether the letter should actually end up in the mailbox or not. For example, if you have recently received a lot of annoying advertising from a certain advertising agency, you can say: "You can throw all letters with a sender from this company location in the trash without further checking.

This is exactly how digital email transport rules work. You can set up different sets of rules depending on which appliance or vendor you use.

Many roads lead to Rome: Ports 25/465/587

A common fallacy is the assumption that the Simple Mail Transfer Protocol (SMTP) is exclusively at home on port 25 and that only this port is responsible for it. This was the case in the early days of the Internet. In the meantime, however, the spectrum has expanded: In addition to port 25, ports 465 and 587 are also responsible for handling e-mails.

Why does this matter to you? Depending on which ports are open and which configurations take effect, emails can be handled differently depending on the port used. For example, the following configuration would be possible: Mails submitted to the server on port 587 go through predefined security checks. On port 465, however, mails can be submitted unhandled.

These are the specifics of all ports relevant to SMTP:

  • Port 25 was already established in 1982 and is mainly used for SMTP relay. Many private Internet Service Providers (ISP) and hosting operators now block this port because it is often misused for sending spam.
  • Port 465 was once intended and registered for SMTPS (secured "SMTP over SSL"), but has since been released for other uses. Today, many ISPs still support submitting mail via port 465.
  • Port 587 is now the standard port for SMTP transmission on the modern Internet. As with port 465, secure transmission via TLS is also possible here.

Avoid open gates

Beware of STARTTLS: vulnerable to STRIPTLS attacks

STARTTLS is a method introduced in 1999 for establishing encrypted communication using Transport Layer Security (TLS). In the meantime, the use of STARTTLS is discouraged because the initial communication setup up to the actual encrypted communication runs in plain text. It is therefore vulnerable to man-in-the-middle or so-called "downgrade" or "STRIPTLS" attacks. These attacks assume that the attacker has already successfully positioned himself as man-in-the-middle before the actual communication begins in order to prevent the establishment of a secure connection.

The recommended alternative is the directly secured connection setup via TLS over the predefined ports. Here, communication is not in plain text and the use of TLS is negotiated, but communication begins directly with the TLS handshake.

How exactly would a downgrade/STRIPTLS attack work?

An attacker interposes himself between an ongoing communication and starts to capture traffic. If the attacker is able to intercept a beginning SMTP communication, he grabs the STARTTLS packet. In it, the responsible mail server tells you that it wants to communicate in encrypted form and replaces the content with an arbitrary string that the client does not understand. The client can then assume that this is an option it does not understand and falls back to using plaintext.

Open Relay

An Open Relay is often a misconfigured SMTP server that allows email to be sent and forwarded without prior authentication. While there are conditions that require the internal use of Open Relay.(A typical example here is the often-used scan-to-mail function.) However, if possible, the problem should be fixed instead of using a gap as a workaround.

For example, an Open Relay allows an attacker to send emails with forged sender information via this server. Unfortunately, you can still find some such servers today. 

If open relay is so insecure, why does this option even exist?

Like many older protocols (such as DNS), SMTP dates from a time when the Internet as such was still very young and full of insecure configurations and standards. The objective was to ensure the highest possible availability of services. The "normal" postal service also tried to deliver letters at any cost. At that time, simply no one could imagine that SMTP would one day be used for the mass sending of spam.

Many have now switched to secure configurations and providers, but some such legacy systems still exist. You cannot simply "disconnect" them and exclude them from communication.

Increase the security of your IT system now!
You will receive detailed advice from us!
Contact Now
OTHER CONTRIBUTIONS
ProSec Kerberos Attacks
Kerberos Attacks

Kerberos ist das überwiegend genutzte Authentifizierung-Protokoll im Microsoft Active Directory und hat dort in der alltäglichen Verwendung den New Technology

Read more "

Table of contents

Do you want to be part of our team?