Unsolicited Commercial Email, or email spam, is a topic that hardly needs an introduction. In the last 12 months, the downward trend of message volumes that Cisco noted mid-2010 has continued. In some ways this is good news, as spam message volumes have remained steady, or decreased. Unfortunately, the decline in volume has been accompanied by ever more sophisticated fraud and phishing messages, and the growth of fraud in other vectors like social networking. The use of viral attachments to messages has decreased, but in its place, more malware is being delivered through URLs in messages. Email continues to be the initial vector of more than 50% of cybercrime.
Spam volumes in May and June 2012 are estimated at 110 - 120B messages per day, down from 140B per day in June 2011. Figure 1 shows estimated spam volumes from Cisco’s Senderbase.org.
Figure 1: Global Daily Span Volume
While traffic is inconsistent, with many spikes and dips, we have not seen a return to the consistently high 200B messages per day of summer 2010. Three things have contributed to the decline:
- Better enforcement of more strict terms of service on residential broadband connections. Fewer home Internet connections allow outgoing port 25 SMTP connections, requiring that their users send email through a webmail interface or through provided SMTP servers. The lack of direct access means that botnet infected PCs cannot send spam directly to other Internet domains.
- More effective clean up of botnet infections by software vendors. While desktop operating systems, browsers, and plugins continue to be vulnerable to security exploits, or to users that blindly install “updates” or “video codecs”, several vendors have published legitimate updates that not only correct the security problems but also clean up infected systems. When these updates are done automatically, infected systems can be cleaned up often without the user even aware that they’ve been infected.
- Loss of financial incentives due to law enforcement and business shutdowns. Most traditional advertising spam makes money for the sender from the click-throughs and product sales that their illegal advertising generates. The last two years have seen several illegitimate pharmaceutical retailers, payment processors, and others taken down in law enforcement action, or been pressured by the threat of law enforcement to exit the business voluntarily. Without a revenue stream, spam advertising has decreased.
The volume of spam messages was one component of spammer offense, what I call the “throw enough stuff and some will stick” tactic. If spam filters are 99% effective at stopping spam, the senders need to make the most of that 1% that gets through, and they did so with increasing volumes until 2010. With filters like the Cisco Email Security Appliance (ESA) routinely exceeding 99% capture rate, and spam volumes much lower due to improvements in technology and enforcement, it has simply become less profitable.
Unfortunately, stealing credentials continues to be extremely profitable, and the use of personal information in social engineering messages to trick users into revealing credentials is on the rise. Cisco estimates that incidents of this kind of “targeted attack” have quadrupled in the last 12 months. The goal of these messages is the same as it has been: trick the user into replying or clicking on the URLs in the message and providing their credentials. Bank accounts and other financial information are, of course, the top target, but many other kinds of account credentials are valuable. Webmail and social networking accounts are sought after for spreading more phishing and malware.
Speaking of malware, the trend of using “click to infect” URLs in messages instead of traditional virus-infected attachments has continued. Social engineering techniques are varied, but rely on exploiting the user’s familiarity with retail, technology, and government brands. Popular approaches include fake shipping notices, order cancellation, software security updates, current events and popular artists. Defenses like the new Outbreak Filters in the ESA 7.5 release, and web reputation and filtering products like Cisco Web Security Appliance (WSA) are designed to catch these when the messages are received, or when the user takes action and clicks the URL. This doesn’t mean that you can discard traditional anti-virus at the email gateway, however. Malware viruses like Bredo and Zeus have been very active in the last 12 months, with billions of infected ZIP and PDF attachments sent.
So what can we do about fraud and phishing aside from the endless spy-vs-spy arms race of filtering? A positive trend in all this trouble is the growing use of email sender domain authentication mechanisms like Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM). These mechanisms allow you to publish information in DNS about the domains in your sender addresses, allowing the recipient to verify that the message is sent from an authorized host. The two standards work in different ways, and are complementary. An SPF record lists the IPs and hostnames that are authorized to send mail for a given domain, while DKIM uses public-key crypto to digitally sign the message and provide the recipient a means to verify the signature. You may also have heard of another standard called SenderID Framework (SIDF), also known as SPF 2.0, which attempted to resolve some issues with SPF but in doing so created an unresolvable incompatibility with the earlier standard. SIDF has never been widely adopted and the specification is likely headed to historical status.
Of the two standards, SPF is simpler. An SPF record is nothing more than a DNS TXT record for your domain. You can look up the record using nslookup or dig:
dig cisco.com txt
The real SPF record for cisco.com is fairly long; let’s imagine this shortened version for simplicity:
v=spf1 ip4:171.68.0.0/14 mx:res.cisco.com ~all
This record has a version field that is always spf1 for SPF, and three mechanisms that define the hosts that are authorized to send mail of the form username@cisco.com:
- The ip4 mechanism is an IPv4 dotted-quad address or CIDR range. IPs in this range are authorized to send email, and you can have more than one ip4 entry. The recipient compares the connecting server’s IP to this list.
- The mx mechanism means that the A records for all of the hosts listed in the MX record for the specified domain are authorized. In this case, the record is effectively delegating part of the record to the administrators of Cisco’s Registered Envelope Service (CRES) domain.
- The all mechanism is everything else: it matches all other IPs on the Internet. The tilde character implies that the recipient should “soft fail” these other IPs, meaning that an unlisted source would not pass the SPF check but should still not be discarded. The dash character in front (“-all”) implies a hard fail, where the recipient can discard failed messages.
There are other mechanisms supported in SPF, like ip6, a, and ptr, that specify hosts and include, exists, and redirect that cause additional lookup and evaluation. All of the mechanisms boil down to providing a list of authorized IP addresses for your domain. SPF used to stand for “Sender Permitted From:” which is a good way to think about it.
By contrast, DKIM proves authenticity of the sender using public key (asymmetric) cryptography, specifically RSA digital signatures. The sender hashes a few message headers and some or all of the message body, signs the hash with its private key, and adds the result to the DKIM-signature header in the message; I’ve shortened some of the values for brevity in this example:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=cisco.com; i=chriport@cisco.com; l=2047; q=dns/txt;
s=iport; t=1342102403; x=1343312003;
h=from:to:subject:date:message-id:mime-version;
bh=t0uoloeutFmO8SA9wz6gzHRGft3MRJjMkJs0za/maFg=;
b=MO//qeeZLflIsnnxjyHDIkMRGc1b3neICmcj4AU9V5nyfR5uNl4AD1atxxB9odO5CokHABHXaNengvkmdasOwo6NYugBNBFA=;
There’s a lot going on here, with information specified in key=value pairs. The DKIM version (v), signature and hash algorithm (a), canonicalization (c), sending domain (d), sender (i), length (l), query type (q), selector (s), timestamp (t), expiration (x) are all the basic values. Headers included in the hash are listed in (h) and should only headers whose value doesn’t change from hop to hop. The body hash is in (bh) and the actual digital signature in (b).
The recipient retrieves the corresponding public key from DNS using the selector in the DKIM-signature header value s, hashes the message, and verifies that the has and the signature match. Assuming that the sender keeps their private key private, they are the only ones that can create signatures that can be verified with that public key. The DKIM DNS record for the above message looks like this, again, edited for brevity:
dig iport._domainkey.cisco.com txt
v=DKIM1\; t=y\; s=email\;
p=MIGfMA0GCSqGSIb3DQEBAQUAApdcQLJM6aL23I2cELq+/lwIDAQAB\;
The record contains a DKIM version and the public key, but in this case also includes the testing (t) indicator, and a service type indicator that this record is for electronic mail, which also happens to be the only service type that DKIM specifies today. Because of the hash and signature method, DKIM provides something that SPF does not: proof that the content has not been modified in-transit.
The Online Trust Alliance (OTA) reports that 68% of the top public and private domains have published SPF, or sign with DKIM, or both. The domains included in the definition of “top” include major retail, finance, social network, and government agencies. If you are using these standards, you’re in good company, and if you’re not it’s something you should consider in the near term.
The list of authenticated email senders includes top phished brand name domains like PayPal, eBay, Facebook, Amazon, and the US Internal Revenue Service. The net result is that your organization will see immediate benefits to using the ESA’s SPF and DKIM authentication features and quarantining or dropping messages that fail the authentication tests. As an email sender, you can do your part in stopping email fraud and protecting your customers and partners by publishing SPF records and signing with DKIM.
There are a lot of external considerations before you publish SPF and DKIM records or start signing with DKIM, starting with enumerating all of your legitimate outbound email sources. Remember that many companies authorize external senders to send email on their behalf, so your legitimate sources may include other organization’s IPs. From there it’s easy to create an SPF record using an SPF Wizard on the web, or from scratch. For DKIM, there’s a little more work because messages need to be processed before they are transmitted outside your organization. You need an MTA product that supports signing, like Cisco’s ESA, and you need to use the same signing key on all of your MTAs. The ESA can generate key pairs and the corresponding DNS TXT records for you, or you can do it with open source tools like OpenSSL.
SPF and DKIM are designed to provide protection from fraudulent use of domains, but are not silver bullets against the spam and phishing problem. Using them will allow recipients to identify and discard fraudulent use of your domains, but adoption is still progressing so it won’t work everywhere. And there’s still nothing to stop a sender from registering a look-alike domain like “yourdomain-support.com” or “yourd0main.com”.
One common concern is the lack of visibility that you have as a compliant user of these standards. How do you know what remote recipients are doing with the messages? How often are they discarding messages because of your SPF and DKIM records? A new specification, Domain-based Message Authentication, Reporting, and Conformance (DMARC), aims to resolve that disconnect. Currently a draft specification, the creators hope to publish it to the IETF so it can become a standard RFC. Like SPF and DKIM, DMARC depends on DNS, and it uses key=value pairs like DKIM.
A DMARC record tells compliant recipients two main things: first, it allows you to tell the recipient what to do with messages that fail SPF or DKIM checks, and second provides contact information for reports about the results of those policies. Here’s an example, completely fabricated:
dig _dmarc.cisco.com txt
_dmarc.cisco.com TXT "v=DMARC1; p=none; pct=100;
rua=mailto:dmarc@cisco.com; ruf=mailto:dmarc@cisco.com;"
This example tells the recipient that their policy (p) should be none, i.e., they should not act on messages that fail SPF or DKIM checks. They should act on 100 percent (pct) of messages from this domain, and provide reports on action to the addresses specified in rua and ruf values. The report types available are Aggregate or Forensic, respectively, and several other reporting related values could be specified, including format and time intervals.
DMARC is still a new specification and potentially subject to changes before it is finalized but in its current state the records are being honored by some prominent organizations. Publishing a record like the one above will not be harmful, as no action will be taken on messages. One of the stated goals of DMARC is to allow gradual adoption of domain authentication instead of an “all-or-nothing” approach. And since DMARC depends explicitly on SPF and DKIM, starting with those well-established protocols is the obvious first step in improving your email environment.
Email Security with Cisco IronPort
By Chris Porter.
Published by Cisco Press.
Series: Networking Technology: Security.
Published: Apr 23, 2012
Copyright 2012
Book
ISBN-10: 1-58714-292-9
ISBN-13: 978-1-58714-292-5
$51.99 USD
Chris Porter was one of the first field systems engineers hired by IronPort Systems in 2003, around the time of the launch of the ESA C-series product. He has served as systems engineer, SE manager, and now technical solutions architect at Cisco, who acquired IronPort in June 2007.
Chris has been involved in planning, deploying, and configuring Email Security Appliances (ESA) at hundreds of organizations, with a chief role in both pre-sales engagements and post-sales support. His experience has made him a trusted voice in ESA product design decisions.
Chris holds a bachelor’s and master’s degree in Computer Science from Stevens Institute of Technology in Hoboken, NJ, and a CCNA certification. Chris is currently a technical solutions architect at Cisco, specializing in content security and the IronPort email and web-security products and services.