Today, enterprises have a heightened awareness of their network security measures and are concerned about the cyber threats to their organization.\u00a0 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.\u00a0 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.\u00a0 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.\u00a0 Organizations should realize that there are very low-cost methods they can employ to help protect them from very popular attacks.\u00a0 This article covers one such low-cost security measure that can help secure e-mail exchanges and add to your malware protection strategies.<\/p>\n
Organizations tend to\u00a0forget about the security and resiliency<\/a>\u00a0of their\u00a0Domain Name System<\/a>\u00a0(DNS) infrastructure.\u00a0 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.\u00a0 Due to the extreme dependency on DNS, when the DNS systems are down, virtually all the organization\u2019s applications are offline.\u00a0 DNS is also overlooked by security administrators as a means to helping an organization operate safely on the Internet.\u00a0 One way to strengthen the security of any IP applications is to secure the underlying DNS records using\u00a0Domain Name System Security Extensions<\/a>\u00a0(DNSSEC).\u00a0 DNSSEC is a method of preserving the integrity of the DNS records and providing authentication for the DNS information using digital signatures.\u00a0 DNSSEC uses public-key cryptography and a chain of trust to verify ownership and authenticity of DNS zone information.<\/p>\n With a few exceptions, virtually all\u00a0DNS server software supports DNSSEC<\/a>\u00a0as part of the base software.\u00a0 For most organizations, there are no additional capital expenditures required to implement DNSSEC.\u00a0 It is just a matter of turning on the feature that already exists on your DNS servers.\u00a0 The\u00a0Internet Society<\/a>\u00a0(ISOC) has a\u00a0Deploy360 program<\/a>\u00a0that helps organizations learn about the importance of using DNSSEC and how to go about implementing it.\u00a0 Depending on your DNS software, deploying DNSSEC can be tricky or as simple as checking a checkbox in a GUI.\u00a0 If you are fortunate enough to have an Infoblox DNS infrastructure, then there are\u00a0very easy methods<\/a>\u00a0to configure DNSSEC.\u00a0 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.<\/p>\n E-mail would not be possible without tight integration with DNS.\u00a0 Every e-mail address contains a username and a\u00a0fully qualified domain name<\/a>\u00a0(FQDN).\u00a0 No e-mail will be transmitted if DNS is offline.\u00a0 The real security issue with e-mail is the spam, phishing, and malicious e-mail that constantly barrage an organization\u2019s mail servers. \u00a0These e-mails can be at-best annoying and offensive.\u00a0 But at their worst, they are fraudulent messages that can contain links that lead to web servers hosting malware or that contain malicious attachments.<\/p>\n Security practitioners tend to think in terms of Confidentiality, Integrity, and Availability (CIA).\u00a0 DNS mail exchange (MX<\/a>) records provide a method to have multiple mail servers for a domain.\u00a0 This provides redundancy, and helps solve the availability problem.\u00a0 Standards like\u00a0Transport Layer Security<\/a>\u00a0(TLS),\u00a0Secure\/Multipurpose Internet Mail Extensions<\/a>\u00a0(S\/MIME) and\u00a0Pretty Good Privacy<\/a>\u00a0(PGP) (see\u00a0OpenPGP<\/a>) provide confidentiality and integrity to e-mail.\u00a0 However, these techniques do nothing to verify the authenticity of the e-mail server.<\/p>\n One method that many e-mail servers employ is to deny\u00a0Simple Mail Transfer Protocol<\/a>\u00a0(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.\u00a0 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.\u00a0 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.\u00a0 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.\u00a0 This method does not guarantee the authenticity of the sender\u2019s mail server.<\/p>\n Another method of determining if e-mail servers are legitimate is by using the\u00a0IETF’s working group<\/a>\u00a0on\u00a0Domain Keys Identified Mail<\/a>\u00a0(DKIM) model.\u00a0 DKIM is a method of e-mail validation that uses public key cryptography to determine if the sending e-mail server is legitimate.\u00a0 DKIM is implemented into the Mail Transfer Agent (MTA) software and implements both the signing and verification methods.\u00a0 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\u2019s domain-name.\u00a0 The receiver\u2019s mail server can retrieve the public key information through DNS to verify that sender\u2019s mail server has valid responsibility to send e-mails from that domain and can be trusted.<\/p>\n DKIM is implemented in a DNSSEC-enabled DNS server with the use of a text (TXT) record.\u00a0 However, DNSSEC is not a strict requirement for DKIM; use of DNSSEC is considered a best practice.\u00a0 The DKIM-Signature has many different header fields that are denoted by characters referring to tags and their associated values.\u00a0 For example, the mandatory \u201cd\u201d tag contains the Signing Domain IDentifier (SDID) (e.g. example.com). The \u201cv\u201d tag contains the version (e.g. 1), the \u201ca\u201d tag contains the signing algorithm (e.g. rsa-sha256), and the \u201cb\u201d tag contains the digital signature of the message\u2019s contents.\u00a0 The \u201cbh\u201d tag is for the body hash, and the \u201cs\u201d tag is for the selector to allow for migration from an old key to a new key.\u00a0 There are many other tags and values that can be used in DKIM-Signature header fields.\u00a0 DKIM can also be extended with the use of\u00a0Author Domain Signing Practices<\/a>\u00a0(ADSP).\u00a0 This is an optional DKIM extension that allows a domain to publish its mail signing practices when using an e-mail relaying service.<\/p>\n Here is an example of what the DKIM DNS TXT record might look like:<\/p>\n april2015._domainkey.example.com IN TXT “v=1; d=example.com; s=april2015; p=asdfnkljasdfglkjasdfjkljasdfmkljasdfnlkj”<\/p>\n It is easy to create the DKIM TXT resource record on your Infoblox NIOS DNS grid.\u00a0 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.\u00a0 One issue you might run into is if the TXT record ends up being longer than 255 bytes but less than 512 bytes.\u00a0 You might need to split up the TXT value into two different pieces as shown in this\u00a0Infoblox KB article<\/a>.<\/p>\n When the receiving e-mail server receives the message, it queries the DKIM TXT resource record and performs the verification process.\u00a0 The e-mail recipient\u2019s mail server will send a Sender Signing Practices Query to the author\u2019s domain to determine its signing practices and then use that information to evaluate the message.\u00a0 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.<\/p>\n 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.\u00a0 The good news is that the DKIM and ADSP are IP version agnostic.\u00a0 In other words, DKIM works in a dual-protocol environment, where both IPv4 and IPv6 are being used.<\/p>\n There is a\u00a0DKIM Core web site<\/a>\u00a0that you can go to that can help you with creation of your DKIM-Signature TXT record.\u00a0 You can also check the validity of the record once you have implemented it.<\/p>\n Following is a list of the relevant DKIM IETF RFCs for your reading enjoyment.<\/p>\n DKIM is also a complimentary technology to\u00a0Sender ID<\/a>,\u00a0Sender Policy Framework<\/a>\u00a0(SPF) (RFC 7208<\/a>).\u00a0 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.\u00a0 It works with a TXT record defined within the e-mail sender\u2019s DNS zone file that lists the IP addresses of the mail servers.\u00a0 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.\u00a0 SPF can also work with IPv4 and IPv6.\u00a0 Following is an example of an SPF DNS TXT resource record.<\/p>\n example.com. IN TXT “v=spf1 ip4:192.168.123.456\u00a0 ip6: 2001:db8:1:1::1234:5678 a -all”<\/p>\n Using SPF and\/or DKIM is not an either-or situation.\u00a0 You can use both SPF and DKIM in combination for the ultimate belt-and-suspenders\u201d approach.\u00a0 The main difference between SPF and DKIM is that SPF does not use any form or public cryptography to provide validation of the information.\u00a0\u00a0Section 11 of RFC 7208<\/a>\u00a0covers this security consideration.<\/p>\n Organizations may be concerned with enabling their\u00a0e-mail servers to send and receive e-mail over IPv6<\/a>\u00a0transport.\u00a0 Today, virtually all e-mail server MTA software can operate over IPv4 or IPv6 equally well.\u00a0 But organizations fear that their current e-mail security systems will not be able to protect them when the e-mail is using IPv6.\u00a0 If an organization is relying on an e-mail security appliance, then they should validate that the appliance\u2019s features work equally well with IPv4 and IPv6 e-mail.\u00a0 If the vendor has some features that work over IPv4, but those same features don\u2019t work for IPv6 e-mail, then the organization needs to make a decision.\u00a0 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.\u00a0 With either decision, the customer should apply pressure to the vendor to strive for dual-protocol feature parity of e-mail security features.\u00a0 The organization might decide to switch to a different vendor\u2019s appliance if their current vendor is too slow to respond, especially if their annual maintenance license is due to expire.\u00a0 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.<\/p>\n Thankfully, these are not the only ways to help organizations filter out all the nefarious e-mails streaming in from the Internet.\u00a0 E-mail services have the ability to use block lists (e.g.\u00a0DNSBL<\/a>) of IPv4 and IPv6 addresses to block connections from e-mail servers that are known to be misbehaving.\u00a0 Many block lists have the ability to block IPv6 addresses, but those block lists do not contain many IPv6 addresses.\u00a0 Also, the granularity of block lists with regard to IPv6 can be a challenge.\u00a0 For example,\u00a0should the block list block each 128-bit IPv6 address<\/a>\u00a0individually, or should the block list use the entire \/64 of the offending e-mail server?\u00a0 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.\u00a0 Over time,\u00a0reputation-based filtering will be less and less effective<\/a>.\u00a0 The e-mail system may also rely on the domain-name of the sending mail server rather than its individual IP address.\u00a0 E-mail servers also use many keyword and\u00a0heuristic algorithms<\/a>\u00a0to prevent malicious e-mails.\u00a0 E-mail security systems can be sophisticated enough to use\u00a0sandboxing<\/a>\u00a0and\u00a0SHA-1<\/a>\u00a0hash values to detect malicious e-mail payloads.\u00a0 E-mail security systems can also use web-content-filtering systems to determine if hyperlinks within e-mail lead to web servers hosting malware.\u00a0 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.\u00a0 Using DKIM and SPF are just additional methods to secure e-mail.<\/p>\n","protected":false},"excerpt":{"rendered":" Today, enterprises have a heightened awareness of their network security measures and are concerned about the cyber threats to their organization.\u00a0 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.\u00a0 Security practitioners applaud organizations that are […]<\/p>\n","protected":false},"author":321,"featured_media":3048,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[51],"class_list":{"0":"post-3179","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipam","9":"entry"},"acf":[],"yoast_head":"\nE-Mail (In)Security<\/h2>\n
Domain Keys Identified Mail<\/h2>\n
\n
Sender Policy Framework (SPF)<\/h2>\n
Allowing E-Mail over IPv6<\/h2>\n
Compensating Controls for E-mail Security<\/h2>\n