Phishing Protection - SPF, DKIM, DMARC

Phishing Protection

SPF, DKIM, DMARC

Rocco Gagliardi
by Rocco Gagliardi
time to read: 11 minutes

Keypoints

This is how you defend against Phishing

  • Nearly 90% of email attacks are based on false sender identities
  • Well known identity theft methods protection exists
  • Implementation of SPF, DKIM, and DMARC may be tricky for most IT Departments
  • Only a quarter of scanned domains implements at least one of mentioned security mechanisms

According to recent research, nearly 90% of email attacks are based on false sender identities, both brands (83% ) and individuals (6%). One type of identity theft, so-called exact domain identity theft, occurs when scammers use a domain in the From field of the message that is owned by the organization they are impersonating.

There are ways to prevent spammers and phishers from spoofing your domain. Email authentication – verify that an email really comes from the domain it claims to come from – is based on widely-accepted standards, well documented in our article. These security mechanisms are relatively easy to set up and offer a good level of protection.

If these methods almost completely block spam, why are we still hearing about them widely? In practice, not all companies implement them.

SPF, DKIM, DMARC

Implementing SPF is just the beginning, for effective protection, it is also necessary to implement DMARC, and consequently, DKIM.

DMARC provides three main elements to the previously existing email authentication standards:

Problems

Like any protection, these too are an additional problem to solve for the proper functioning of the system: Broadly speaking, the owner of the domain decides what the recipient will do with the emails received in his name.

There is no quick and safe way to test whether a configuration works or not, without involving several parties at the same time. This makes everything more academic: You have to sit in front of a paper and design the policy so that it can theoretically work; once implemented, you must monitor its actual functioning and react to any problem.

The protection systems mentioned are difficult to understand and implement for a common IT department, because:

Besides, there are some specific technical criticalities:

This explains, in part, why many administrators prefer to avoid its implementation or implement it “Pro-forma”.

The Analysis

To find out what is the implementation state in the various companies that communicate daily with millions of users, we tried to do a sample analysis of domains that we think are interesting. The list of domains is provided by OpenPage Rank, we have selected the domains (based on TLDs, keywords, etc.), analyzed the public DNS records, and assigned a security score to the various policies found.

Method

The analysis of the records includes both the identification of the mechanisms present (SPF, DKIM, DMARC) and the defined policies.

In policy analysis:

The information collected is stored in a MongoDB for analysis:

Example of an analyzed record

Dataset

We analyzed 414783 domains, selected by specific top-level-domains:

TDL Number of Domains
.org 185695
.edu 99557
.eu 50526
.ch 46089
.gov 29839
.mil 2911
.bank 166

Results

Usage of security mechanisms

The following figure shows how many domains, in total and grouped by selected TLDs, are implementing protection mechanisms.

Usage of Security Mechanisms

The next figure illustrates in detail for each TDL the percentage of domains using protection mechanisms.

Usage of security mechanisms by TDLs

Takeaway:

Domains Security Levels

The next figure shows the distribution of domains per security level range.

The security level is calculated based on the presence of the protection mechanisms and how good is configured.

Range Description
.-100 to -50 The security policy does not use the security settings or uses them incorrectly
.-49 to 0 The security policy presents options that lead to an insecure result
.1 to 50 The security policy could be more restricted
.51 to 100 The security policy is well configured

Domains by Security Levels

Takeaway:

SPF configuration quality

We now take a closer look at two specific SPF mechanisms (all and ip4_prefix), to show the creativity of some administrators with SPF policies.

The all mechanism

This shows how the most important mechanism of the SPF policy, the all, is configured across the analyzed domains. This mechanism indicates what to do with the non-compliant emails (drop, tag, or ignore). This mechanism is mandatory.

This is a good example of what can go wrong: "v=spf1 +all" is a valid SPF policy, but as stated by SPF organization, The domain owner thinks that SPF is useless and/or doesn’t care.

SPF all Mechanisms Usage

Takeaway:

The ip4_prefix mechanism

The figure shows the configuration of another SPF mechanism, the ip4. This mechanism is used to mark a certain number of servers as valid mail servers for the domain. We extracted the mask to calculate how many servers are whitelisted with this mechanism. The number of those servers should be limited to the mail servers only. Note, that this mechanism is optional.

SPF ip4_prefix Mechanisms Usage

Takeaway:

Other Mechanisms

There are eight mechanisms analyzed for the SPF. We have shown only two in detail, to emphasize that even the presence of the SPF policy is not a guarantee of safety. Furthermore, the intentions of those who configure an ip4 prefix to 0 are always, at least, rummy.

Summary

Systems to protect against identity theft exists for many years, but for various reasons, they are not yet used on a large scale and are often used only in an informational mode.

Our research shows how the implementation of such systems, even for sensitive domains, is still far from complete.

About the Author

Rocco Gagliardi

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.

Links

You want to test the awareness of your users?

Let our Red Team conduct a professional social engineering test!

×
Enhancing Data Understanding

Enhancing Data Understanding

Rocco Gagliardi

Transition to OpenSearch

Transition to OpenSearch

Rocco Gagliardi

Graylog v5

Graylog v5

Rocco Gagliardi

auditd

auditd

Rocco Gagliardi

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here