2016 has seen an unsettling amount of e-mail and web security breaches that’s compelling businesses all over the world to ask themselves how they can best prepare and prevent similar attacks on their own environments. One such attack that we have noticed a sharp increase of in the past several months has been spoofing.
Spoofing occurs when a malicious sender sends e-mail that appears to be from a high ranking staff member requesting things such as a wire transfer or sensitive company information in a very convincing, but false, manner.
The internet was designed for information sharing and research while email was designed to send short messages to share information from server to server. When it came to the process of delivering mail to the receiving email server, it was accepted to be whoever the email said it was trusting that the sender was using the honor system and was not falsifying information. We can no longer afford have his option if we are to protect our businesses; it is now necessary to define what servers and services are allowed to send on our behalf, our email systems are the front door to our business operating environments and it’s imperative that we protect them.
Email Address Spoofing
As we mentioned earlier, spoofing is when an attacker impersonates an email address from your organization in an effort to entice the recipient to open the email and share potentially sensitive information or resources. This method of attack can be used to exploit and compromise unsuspecting staff, clients, and business relationships.
An organization’s reputation is hard to recover from when damaged. There are steps that can be used to protect your business and those with whom you communicate. Implementation of Sender Policy Framework is an integral component in protecting your business from email impersonation.
Your business, and the security of your business is important to us! If you would like to schedule a review of your email security settings. Please contact us at firstname.lastname@example.org, and we’ll go through the process with you!
Step 1 – Ensure all traffic is being scanned
It used to be standard operating procedure to bypass the spam filters from internal senders. We now recommend scanning all traffic, so all emails emails including those that may appear to be internal, which are impersonations, are scanned the same as all incoming emails. Please ensure that the box for Bypass spam filters for messages received from internal senders is unchecked.
See: Customize spam filter settings
Step 2 – Setup Sender Policy Framework (SPF)
Define what servers are designated to send on behalf your organization’s domain name. If this text record does not exist, any server or service with an Internet connection can be used to impersonate your email addresses.
In your DNS Zone you can use the Google Settings to ensure that the proper Google Servers are specified.
Add: v=spf1 include:_spf.google.com ~all with a host name of “@” to your DNS zone. (This may differ from different hosting providers.)
See: Configure SPF records to work with Google Apps
Send Policy Framework: Project Overview
Kitterman SPF Record Testing Tools
Step 3 – Setup DomainKeys Identified Mail (DKIM)
DKIM is another to help identify that you are the originator of a message, and depends on SPF to be in place in order to work.
Excerpt from the Google Apps Administrator Help for DKIM:
To generate the domain key used to sign mail:
- Sign in to the Google Admin console.
- Click Apps > Google Apps > Gmail > Authenticate email.
- Select the domain for which you want to generate a domain key.
- The name of your primary domain appears by default. To generate a domain key for a different domain, select it from the drop-down list.
- Click Generate new record.
- If your registrar doesn’t support 2048-bit keys, change the key length from 2048 to 1024.
- Optionally, update the text used as the DKIM selector prefix.
- The selector prefix is used to distinguish the domain key that Google Apps uses from any other domain keys you may have. In most cases, you’ll select the default prefix “google”. The only reason to change the prefix is if your domain already uses a DKIM domain key with the selector prefix “google”.
- Click Generate.
- The text box displays the information you need in order to create the DNS record that recipients query in order to retrieve the public domain key.
The Output of what is generated looks like this:
Add the DKIM to your entry like:
- Once the DNS has been updated, leave time for it to propagate throughout the DNS and then click on Start Authentication in the Authenticate mail dialogue, that is identified in the example above.
Domain Keys can be obtained for most email providers, including systems like Mailchimp and Constant Contact and systems that send mail on behalf of your business. You can find out more by doing a Google Search for the service that you use and SPF or DKIM.
Following the steps above can benefit your business’s security by ensuring that only those that are authorized to send from your domain are allowed to send. We will be adding more information that we hope that will beneficial as well.
See: Domain-Keys Identified Mail (DKIM)
Step 4 – Setup Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC depends on the SPF and DKIM records to communicate to receivers mail server what the disposition of emails are if they do not meet the authentication requirements. There is a caveat that must be considered that we we implement DMARC so that it does not disrupt normal mail flow. Observation for the first week of implementation will indicated if there are valid emails that are being detected from servers that are receiving mail from your domain.
To setup DMARC for your domain:
- Set Up a Group in Google Apps that you can use for capture information from the receiving servers. (Don’t bother assigning group members, the group contents can be reviewed after it has captured some information.)
- Log in to your DNS management console.
- Go to the DNS Zone where you’ll be publishing the DMARC TXT record.
- Most DNS management consoles will ask for:
- Hostname: this should be “_dmarc”. NOTE: the leading “underscore” character is required!
- Resource type: this is “TXT”, as DMARC records are published in the DNS as TXT resources.
- Value: this is the DMARC record itself, of the form “v=DMARC1; p=none; rua=mailto:email@example.com”
- Save and you’re done.
- After a week look at the information collected in the Google Group, and determined if there was any valid mail that was reported that did not pass DKIM and SPF, and remediate any missing information.
- Adjust the p=from none to quarantine or reject. We suggest that you use quarantine until you are sure that reject can be safely implemented.
We understand that your business communications are of the highest importance. If would like for Suitebriar to take care of making sure that your Google Apps Domain is up-to-date with these settings, please set up a time to discuss by sending an email to firstname.lastname@example.org.
Dmarcian: DMARC Inspector
Posted by Jon Pankhurst at 2:44 PM