cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Chalk Talk: Cisco Email Security

931
Views
5
Helpful
0
Comments
Enthusiast

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.

ScreenHunter_03 Jul. 18 11.12.jpg

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 includeexists, 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

chriport.jpg

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.