Monday, June 3, 2019

Protect your outbound Emails!



 Level: Basic

Protect your outbound Emails!


Protecting inbound emails were and remain one of the main requirements to secure environments from external threats. At the beginning of the 3rd millennium, bad emails were considered as junk email and then things had developed and turned into a SPAM "bad email". SPAM was wasting employees' valuable time while reviewing dozens of unwanted emails every day which sometimes reached to hundreds. Bad email “SPAM” grows and becomes dangerous! Hackers utilized email technology and start transmitting phishing emails using attachments with an embedded virus or link. Most of the old email scanners at any MTA levels (Gateway, Exchange, Lotus,…) wasn’t designed properly to look for malware inside the file e.g. PDF or DOC. However, new technology such as Sandboxing is the right solution to protect organizations from malware inside legitimate files. Nowadays inbound SPAM controlled by many technologies including IP reputation, content scoring and more. Nevertheless, sometimes phishing technique bypasses the most sophisticated protection technology and targeting top persons in the organization, this called “spear phishing” and its focus on critical business employees such as CxO, HR, IT, Financial.

Many Security companies offer perfect protection against Email Threats (SPAM, Phishing, Sandboxing…) but they mention that protection protect 99.99% of the incoming threat, and unfortunately, the 0.01 always goes to CxO . And I believe having ideal protection is impossible.
The question here is: What about outbound emails? What solutions available to protect emails leaving the organization? In the past most companies were more about secure inbound emails, they only started outbound protection after they become blacklisted or spoofed. Government sector, Financial and other institutions have also concern from leaking of data, so they consider Data Loss Prevention to protect classified data from been lack.

In this article, I will discuss three kinds of anti-spoofing technology (DKIM, SPF & DMARC) those are considered as kinds of outbound protection and used to enforce the integrity of the message. DKIM used to sign emails at gateway level, SPF used to register all outbound email system and DMARC is to see how DKIM and SPF are working and enforced.


DKIM:


I’m going to start with DomainKeys Identified Mail (DKIM), DKIM designed to detect email spoofing “Fake Sender”, DKIM defined in 2011 with RFC 8301 https://tools.ietf.org/html/rfc8301.

DKIM is a Digital Signature solution at Gateway level. The digital signature on user level is similar but it’s different in the detail. The digital signature is a solution offered to sign emails used an organization private key and then the recipient’s system will verify/authenticate email using the public key. DKIM uses DNS to publish the public key, so the recipient checks the public key by doing a TXT query on the DNS for the sender zone. Without DKIM, Organizations have to send their public key first and then the recipient will verify using local trusted keys in order to verify the digital signature. However, this type is manual way and it is not good to use if you have a huge number of users and recipient.

To implement DKIM, you need to do the following:

  1. Generate Public and Private key
  2. Add the public key in DNS as TXT record
  3. Add the private key into your MTA server
  4. Configure MTA to sign email for outbound


here is an example of the SPF records:
       
"v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClKXSnsvrnUQMt9j6rGvLAWpkh" "kOXCHDVI4hDi7em5wkmRoQ/DU6iqpt4MmBxzlLxFO49ZzhiwyvEkFQY+kDdJ38JL"
"41VPI5+swhk7isqKvJDQvmc9clK0sdrfNPb1zuoGesB3Ah9ENZTWXuCVjngC0fpT" "KHQPbdkYKkcDrGceYwIDAQAB")

In above example for domain mahouk.net:
-        The code after P is my domain public key
-        v: is the version of the DKIM
-        t:s means the domain is not sending email using any subdomains

How it works?

  1. The public key is defined in the public DNS as txt record.
  2. The user sends an email to the public recipient
  3. MTA sign the message using the private key
  4. Email moved from MTA to destination MTA using SMTP session
  5. Recipient MTA check public key that is published in the public DNS
  6. Recipient MTA validate the email and then deliver it to the user mailbox

SPF:


Sender Policy Framework (SPF) is another type of email outbound protection. It is simple to understand and easy to implement. The SPF defined in 2014 with RFC 7208 https://tools.ietf.org/html/rfc7208.

SPF is a way that an organization use to tell recipients of the email if the email arrived from servers that belong to the organization or not, and if the email arrived from different servers then consider the email as spoofed.

SPF has four main qualifiers:

  • (+) for a pass: it means to authorize the sender
  • (-) for fail: means unauthorize sender (if -all is defined in the record then it means the recipient should only receive emails from the pre-defined server, if not then the recipient should not trust the email and consider it as spoofed, this called hardfail)
  • (~) for soft fail: it is like the fail option, however, it doesn’t mean a real fail. It is more used for testing purpose
  • (?) for neutral: it means that the sender tells to accept the email even if the email came from any source of the network. This is the default configuration if the SPF record is not defined completely.

Here is a recommended website to create SPF record:  https://www.spfwizard.net

An example of the SPF records:


  • Single server
v=spf1 ip4:1.2.3.4 -all
It means to accept email only from server 1.2.3.4

  • MX servers

v=spf1 mx -all
It means to accept email only from any server that is defined as mx record

  • Mix DNS records and IPv4

v=spf1 a mx ip4:1.2.3.4 ~all
It means to accept email from any server, make softfail if the email sent by other than servers mentioned in “A” records or “MX” records or IP:1.2.3.4

Note: if the "? all" is mentioned then it means to accept the email and don’t make it as softfail.



How it works?


  1. All servers used to send email to the outside is defined in the public DNS as txt record.
  2. The user sends an email to the public recipient
  3. Email sent to outside of the organization using server IP or Name that is mentioned in the Txt record.
  4. Email moved from MTA to destination MTA using SMTP session
  5. Recipient MTA validates IP or name and makes sure it is available in the TXT record that is published in the public DNS
  6. Recipient MTA validate the email and then deliver it to the user mailbox
  7. The user received an email sent server belongs to the sender domain



DMARC


Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the most interesting outbound protection technology, this technology was defined in 2015 in RCF 7489 https://tools.ietf.org/html/rfc7489

DMARC is the only solution to know if your domain users are successfully authenticated by email recipient’s system, it can check both SPF or DKIM and send a report every day to you about the authenticated emails. With DMARC, organizations could define policies to tell the recipients how to deal with authenticated/unauthenticated emails coming from their domain. Also, they can enforce alignment policy such as define domain and subdomain to be enforced even if it passes DKIM or SPF. DMARC is easy to implement but hard to maintain! The report messages from other systems are very hard to review and manage. This led security companies to develop tools to make this feature more effective, some companies now have a solution to manage the report emails sent by the recipient’s system. Some example of these companies like DMARC Analyzer, OnDMAR, Agari,.. 
The feedback report is one of the great features of DMARC. DMARC can be configured to send two separate reports aggregate (rua) and Forensic/Failure (ruf) reports. The reporting feature will help the domain owner to know who is trying to spoof their domain and make sure that all of their systems are perfectly working.

You can define three different policies to tell the recipient’s system what to do when receiving an email, it will be a request, not an obligation. Here is a list of policies (P):

  • P=None: it used for monitor purpose, rua and ruf will function normally and then you can know if the configuration of DKIM and SPF is correct
  • P=Quarantine: this to tell the mail recipient system to put the email into the spam folder
  • P=reject: this to tell the mail recipient system to not deliver the email to the mailbox. The best is to delete this at the gateway level.

To implement DMARC, you need to do the following:

  1. Make sure you have SPF and DKIM (you can have one but it is not recommended)
  2. Define policy (None, Quarantine or reject and define the bounce report email for mua or muf)
  3. Use DNS to create TXT record for DMARC that define the policy and bounce report email
  4. Start with testing policy and then switch to production.


How DMARC works?



  1. SPF + DKIM + DMAC policies are added in the DNS.
  2. The user sends an email to the public recipient
  3. Email sent to outside after sign using the private key and by using company’s server that is defined in SPF.
  4. Email moved from MTA to destination MTA using SMTP session
  5. Validate email using public key + check if the email came from the registered server.
  6. Recipient MTA validate the email and then deliver it to the user mailbox
  7. The user received an email sent server belongs to sender domain and signed by sender’s server 
  8. In case of failed authentication, the recipient domain system will send feedback to the email defined in public DNS.

I'm going to demonstrate each part in the future and hope if you send me your comments to improve this article.

thanks

1 comment:

  1. Mystino - Best Online Casino for Japanese Players - Casinoinjapan
    Mystino - Best Online Casino for Japanese Players. カジノ シークレット Play casino games for real money or 샌즈카지노 for free. ミスティーノ Casino online for free!

    ReplyDelete