Don’t Make It Easy For The Phishers
A few years ago, a smart product manager showed me a way to visualize the evolution of features in a legacy product. It looked like kind of like a set of stairs. At the bottom were the basic features that the product had when it launched; those had become standard, every competing product had them also, but they were still required. Above that, the 2.0 features — also now standard, also still required. Above that, the 3.0 features which weren’t quite standard, but were now expected by users. And at the top, the features we planned to release soon — unique to our product, certain to excite our users, but built on the foundation of everything which came before. Viewed that way, it was clear that neither the old nor the new, the de rigeur or the shiny, could be ignored.
This model works for security features, too — especially when addressing spam and phishing, where relatively simple prevention methods like IP-based blacklists are still extremely effective. The old methods can never catch all of the newest attacks, which causes some analysts to declare them useless — but ancient spamming techniques are still used by a surprisingly large percentage of miscreants, and their messages can be just as destructive as the tricky new stuff. Neither the old nor the new, the easy or the difficult, can be ignored.
There’s no such thing as a Final Ultimate Solution to the Spam Problem, or a Final Ultimate Solution to the Phish Problem. What works is security in layers — and more layers, and more layers, and more layers. Yet in the search for that FUSSP or FUSPP, some of the simpler, lower layers have been skipped over.
One of these, believe it or not, is email authentication. Despite early predictions from wild-eyed, ill-informed enthusiasts, neither SPF nor DKIM will stop spam. They also won’t stop all phishing. But they’re extremely effective in catching specific types of phishing, especially when applied to mail inbound to your own system.
1. does the message have a valid signature? (yes or no)
2. which domain signed the message?
When a message has a valid signature, and that signature was applied by your domain name, then you know the message is from a mail server under your control. In most cases, that’s enough to know you can trust the message, let it bypass spam filters, et cetera.
The converse is also true: when a message does not have a valid signature, yet it claims to be From: your domain, you know you shouldn’t trust it.
So here it is, the simplest anti-phishing method to date:
1. start signing all your outbound mail with DKIM
2. use Return Path’s Domain Assurance tool to audit your mailstreams, and make absolutely sure that you’re signing everything correctly (there are other ways to do this, but ours is easier)
3. configure your mail server to reject all non-authenticated mail which purports to be From: your domains
Similarly, if the message is signed by any other domain you trust, you know you can trust the message — at least as far as you trust the domain which signed it. Perhaps that domain belongs to a corporate partner, or an employee’s home system; you can add those trusted domains to your DKIM whitelist, and be protected from forgeries of those domains too. (Assuming, again, that your partner/employee/etc signs all of their legitimate outbound mail.) And they can do the same for your domains, creating a small but effective web of trust.
Doing the same thing with SPF is a bit trickier. SPF tells you which IP addresses are authorized to send mail on behalf of a particular domain, so in effect you’d be configuring your mail server to only accept mail which purports to be from your domain (in the SMTP MAIL FROM or HELO; SPF ignores the visible From: header) if it’s from an IP address you control. You could do the same thing without SPF, since you know what those IP addresses are.
Problem is, there are often legitimate reasons for mail to leave your system from one IP address, and return from another. Forwarding services and mailing lists are the standard examples; there are probably more. As such we’d recommend being very cautious with the SPF method and focusing instead on DKIM.
Obviously, neither of these would catch messages which don’t forge your domain. You’ll need additional tools for those. But why not implement the simplest protections first? Don’t make it easy for the criminals to get to you or your users. Neither the easy nor the difficult can be ignored.