Today, enterprises have a heightened awareness of their network security measures and are concerned about the cyber threats to their organization. With the emphasis on Internet security due to recent highly publicized corporate security breaches, enterprises are re-evaluating their security measures and increasing their funding of IT security initiatives. Security practitioners applaud organizations that are striving for a higher level of protection and not just trying to achieve the minimum level of protection based on compliance-driven, check-box security. Reactive spending may not always be the most effective use of funds resulting in the best protection measures, but it is better than underfunding a corporate cybersecurity program. Organizations should realize that there are very low-cost methods they can employ to help protect them from very popular attacks. This article covers one such low-cost security measure that can help secure e-mail exchanges and add to your malware protection strategies.
DNS is Integral to Your Security Measures
Organizations tend to forget about the security and resiliency of their Domain Name System (DNS) infrastructure. Every application in the TCP/IP networked environment relies on the integrity and availability of the DNS as the first step in establishing a connection between two systems. Due to the extreme dependency on DNS, when the DNS systems are down, virtually all the organization’s applications are offline. DNS is also overlooked by security administrators as a means to helping an organization operate safely on the Internet. One way to strengthen the security of any IP applications is to secure the underlying DNS records using Domain Name System Security Extensions (DNSSEC). DNSSEC is a method of preserving the integrity of the DNS records and providing authentication for the DNS information using digital signatures. DNSSEC uses public-key cryptography and a chain of trust to verify ownership and authenticity of DNS zone information.
With a few exceptions, virtually all DNS server software supports DNSSEC as part of the base software. For most organizations, there are no additional capital expenditures required to implement DNSSEC. It is just a matter of turning on the feature that already exists on your DNS servers. The Internet Society (ISOC) has a Deploy360 program that helps organizations learn about the importance of using DNSSEC and how to go about implementing it. Depending on your DNS software, deploying DNSSEC can be tricky or as simple as checking a checkbox in a GUI. If you are fortunate enough to have an Infoblox DNS infrastructure, then there are very easy methods to configure DNSSEC. Now that the root zone has been signed and most of the Top Level Domains (TLDs) are signed, there is little that prevents an organization from deploying DNSSEC.
E-Mail (In)Security
E-mail would not be possible without tight integration with DNS. Every e-mail address contains a username and a fully qualified domain name (FQDN). No e-mail will be transmitted if DNS is offline. The real security issue with e-mail is the spam, phishing, and malicious e-mail that constantly barrage an organization’s mail servers. These e-mails can be at-best annoying and offensive. But at their worst, they are fraudulent messages that can contain links that lead to web servers hosting malware or that contain malicious attachments.
Security practitioners tend to think in terms of Confidentiality, Integrity, and Availability (CIA). DNS mail exchange (MX) records provide a method to have multiple mail servers for a domain. This provides redundancy, and helps solve the availability problem. Standards like Transport Layer Security (TLS), Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP) (see OpenPGP) provide confidentiality and integrity to e-mail. However, these techniques do nothing to verify the authenticity of the e-mail server.
One method that many e-mail servers employ is to deny Simple Mail Transfer Protocol (SMTP) connections from e-mail servers IP addresses that do not have a matching pointer (PTR) record that resolves to the same FQDN as the forward lookup address. The SMTP Banner is also checked in the same way to compare the hostname announced by the sending mail server with the forward and reverse DNS query responses. These age-old technique are well understood by the attackers and they can simply use their own newly minted nefarious domain name that has the appropriate PTR record for their spam-sending mail server. Also, other organizations that have their mail server compromised or leveraged as an open mail relay would likely have a valid PTR record in DNS. This method does not guarantee the authenticity of the sender’s mail server.
Domain Keys Identified Mail
Another method of determining if e-mail servers are legitimate is by using the IETF’s working group on Domain Keys Identified Mail (DKIM) model. DKIM is a method of e-mail validation that uses public key cryptography to determine if the sending e-mail server is legitimate. DKIM is implemented into the Mail Transfer Agent (MTA) software and implements both the signing and verification methods. DKIM-Signatures are inserted into the SMTP mail header by the sender MTA and then the receiver MTA verifies the DKIM DNS entry for the sender’s domain-name. The receiver’s mail server can retrieve the public key information through DNS to verify that sender’s mail server has valid responsibility to send e-mails from that domain and can be trusted.
DKIM is implemented in a DNSSEC-enabled DNS server with the use of a text (TXT) record. However, DNSSEC is not a strict requirement for DKIM; use of DNSSEC is considered a best practice. The DKIM-Signature has many different header fields that are denoted by characters referring to tags and their associated values. For example, the mandatory “d” tag contains the Signing Domain IDentifier (SDID) (e.g. example.com). The “v” tag contains the version (e.g. 1), the “a” tag contains the signing algorithm (e.g. rsa-sha256), and the “b” tag contains the digital signature of the message’s contents. The “bh” tag is for the body hash, and the “s” tag is for the selector to allow for migration from an old key to a new key. There are many other tags and values that can be used in DKIM-Signature header fields. DKIM can also be extended with the use of Author Domain Signing Practices (ADSP). This is an optional DKIM extension that allows a domain to publish its mail signing practices when using an e-mail relaying service.
Here is an example of what the DKIM DNS TXT record might look like:
april2015._domainkey.example.com IN TXT “v=1; d=example.com; s=april2015; p=asdfnkljasdfglkjasdfjkljasdfmkljasdfnlkj”
It is easy to create the DKIM TXT resource record on your Infoblox NIOS DNS grid. Consult the Administrator Guide for your particular version of NIOS for details on enabling your domain for DNSSEC and creating a TXT resource record in your zone. One issue you might run into is if the TXT record ends up being longer than 255 bytes but less than 512 bytes. You might need to split up the TXT value into two different pieces as shown in this Infoblox KB article.
When the receiving e-mail server receives the message, it queries the DKIM TXT resource record and performs the verification process. The e-mail recipient’s mail server will send a Sender Signing Practices Query to the author’s domain to determine its signing practices and then use that information to evaluate the message. If the receiving mail server finds that the key or the ADSP is insecure because DNSSEC is not being used or if the key is bogus, then the receiving mail server can chose to ignore that fact or fail the message.
DKIM allows for e-mail validation based on the domain-name rather than the IP address of the sending e-mail server which is typically used by block lists. The good news is that the DKIM and ADSP are IP version agnostic. In other words, DKIM works in a dual-protocol environment, where both IPv4 and IPv6 are being used.
There is a DKIM Core web site that you can go to that can help you with creation of your DKIM-Signature TXT record. You can also check the validity of the record once you have implemented it.
Following is a list of the relevant DKIM IETF RFCs for your reading enjoyment.
- RFC 4686, Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
- RFC 5016, Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
- RFC 5585, DomainKeys Identified Mail (DKIM) Service Overview
- RFC 5617, DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
- RFC 5863, DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
- RFC 6377/BCP0167, DomainKeys Identified Mail (DKIM) and Mailing Lists
- RFC 6651, Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting
Sender Policy Framework (SPF)
DKIM is also a complimentary technology to Sender ID, Sender Policy Framework (SPF) (RFC 7208). SPF is also a simple way to allow e-mail receivers to validate the IP address of the mail servers that are authorized to send mail for a domain-name. It works with a TXT record defined within the e-mail sender’s DNS zone file that lists the IP addresses of the mail servers. With SPF, mail should be rejected if the e-mail server trying to send mail to us has an IP address that is not on the specified list of validated e-mail servers. SPF can also work with IPv4 and IPv6. Following is an example of an SPF DNS TXT resource record.
example.com. IN TXT “v=spf1 ip4:192.168.123.456 ip6: 2001:db8:1:1::1234:5678 a -all”
Using SPF and/or DKIM is not an either-or situation. You can use both SPF and DKIM in combination for the ultimate belt-and-suspenders” approach. The main difference between SPF and DKIM is that SPF does not use any form or public cryptography to provide validation of the information. Section 11 of RFC 7208 covers this security consideration.
Allowing E-Mail over IPv6
Organizations may be concerned with enabling their e-mail servers to send and receive e-mail over IPv6 transport. Today, virtually all e-mail server MTA software can operate over IPv4 or IPv6 equally well. But organizations fear that their current e-mail security systems will not be able to protect them when the e-mail is using IPv6. If an organization is relying on an e-mail security appliance, then they should validate that the appliance’s features work equally well with IPv4 and IPv6 e-mail. If the vendor has some features that work over IPv4, but those same features don’t work for IPv6 e-mail, then the organization needs to make a decision. The organization could decide to delay IPv6 enabling their e-mail servers until the vendor has feature parity, or the organization could proceed with IPv6 enablement of their e-mail servers and use a compensating control to limit the exposure. With either decision, the customer should apply pressure to the vendor to strive for dual-protocol feature parity of e-mail security features. The organization might decide to switch to a different vendor’s appliance if their current vendor is too slow to respond, especially if their annual maintenance license is due to expire. That might be the compelling event that allows an organization to switch e-mail security appliance vendors and go to a vendor that supports IPv6 as effectively as they support IPv4.
Compensating Controls for E-mail Security
Thankfully, these are not the only ways to help organizations filter out all the nefarious e-mails streaming in from the Internet. E-mail services have the ability to use block lists (e.g. DNSBL) of IPv4 and IPv6 addresses to block connections from e-mail servers that are known to be misbehaving. Many block lists have the ability to block IPv6 addresses, but those block lists do not contain many IPv6 addresses. Also, the granularity of block lists with regard to IPv6 can be a challenge. For example, should the block list block each 128-bit IPv6 address individually, or should the block list use the entire /64 of the offending e-mail server? In an effort to make the block list more scalable, the block list might chose to list the entire /64 despite the fact that there might be collateral damage in the form of valid mail servers addressed within the same prefix. Over time, reputation-based filtering will be less and less effective. The e-mail system may also rely on the domain-name of the sending mail server rather than its individual IP address. E-mail servers also use many keyword and heuristic algorithms to prevent malicious e-mails. E-mail security systems can be sophisticated enough to use sandboxing and SHA-1 hash values to detect malicious e-mail payloads. E-mail security systems can also use web-content-filtering systems to determine if hyperlinks within e-mail lead to web servers hosting malware. If an organization has a sophisticated e-mail security system, it can go a long way toward helping the end-users defend against malware on their computers and mobile devices. Using DKIM and SPF are just additional methods to secure e-mail.
