You're familiar with the dangers of phishing, but what about pharming threats? Pharming misdirects Web users of trusted brands to phoney storefronts set up to harvest IDs. The crime is typically accomplished through cache poisoning of DNS servers or domain hijacking, in which registrars are tricked into moving domains.
In recent months, hackers have proven there's reason for concern about both types of attacks. In March, SANS Institute uncovered a single cache-poisoning attack that redirected 1,300 brands, including ABC, American Express, Citi and Verizon Wireless. In January, Panix had its domain hijacked by an Australian hacker; and in April, Hushmail's main name server's IP address was changed to that of a hacker graffiti site.
Statistics tracking pharming occurrences aren't yet available. However, the Anti-Phishing Working Group (APWG) has deemed the potential problem serious enough that it has lumped pharming into the types of Internet scams and fraud the group aims to prevent.
The problems of cache poisoning and domain hijacking have been around a long time, and they're technologically and organisationally complex to solve, experts say. But there are some steps you can take to protect your DNS servers and your domains from being manipulated by pharmers, who will soon be using hacker techniques to trick large numbers of redirected users into giving up personal information.
The DNS security problem points back to Berkeley Internet Domain (BIND), which is riddled with security problems that have been widely reported for the past five years. If you're running a BIND-based DNS server, follow best practices for DNS management, says Ken Silva, VeriSign's chief security officer.
"Keeping DNS servers patched and up to date is a first step, and there are a number of best practices guides about configuring these servers better. But DNS in its current state has fundamental problems," adds Johannes Ullrich, chief research officer at SANS.
Upgrading to BIND 9.2.5 or implementing DNSSec would make the cache poisoning risk disappear, says Paul Mockapetris, chief scientist at Nominum and an original author of the DNS protocol. But such migrations are tedious and difficult without the interfaces provided in DNS management appliances from vendors such as BlueCat Networks, Cisco, F5 Networks, Lucent and Nortel.
Some companies such as Hushmail have opted to replace BIND with the open source TinyDNS. Alternate DNS software options are available from Microsoft, Nominum, PowerDNS and JH Software, among others.
Best practice for name servers
No matter what DNS you're running, follow the best practices that Michael Hyatt, president of BlueCat Networks, outlines below:
• Run separate name servers for redundancy on different network segments.
• Separate external and internal name servers (physically separate machines or run BIND Views) and use forwarders. External authoritative name servers should accept queries from almost any address, but forwarders don't. They should be configured to accept queries from internal addresses only. Disable recursion (the process of locating DNS records from the root server downward) on external authoritative name servers. This allows you to limit which DNS servers have contact with the Internet.
• Restrict dynamic DNS updates when possible.
• Restrict zone transfers to authorised devices only.
• Use transaction signatures to digitally sign zone transfers and zone updates.
• Hide the version of BIND being run on the servers.
• Remove any unnecessary services running on the DNS servers, such as FTP, telnet and HTTP.
• Use firewall services both at the network perimeter and on the DNS servers. Limit access to only those ports/services that are required for DNS functionality.
Hold registrars accountable
Brian Smith, CTO for Hushmail, still seethes about how easy it was for hackers to trick the front-line customer service representatives at his domain registrar, Network Solutions, into changing the IP address for Hushmail's main name server, which he discovered on a Monday morning.
"This looked really bad for us," Smith says. "I would like to see better security policies among registrars that are documented and publicly available. But I can't tell you a single registrar that does this, and I've been looking ever since this happened."
His sentiments echo those of Alex Resin, president of Panix.com, who feels just as strongly about failures on the part of registrars that led to the hijacking of the Panix domain in January. First his registrar sold his domain registration to a reseller without notification. Then, the reseller proceeded to transfer the domain to a social engineer - also without notifying Resin.
"The domain system needs systemic, fundamental changes," Resin says. "There are a lot of proposals, but things aren't happening fast enough."
Minimise the risk
It'll be a long wait for marketplace demand and ICANN leadership to force secure transfer policy among registrars. So Resin, Smith and Tim Cole, chief registrar liaison at ICANN, suggest the following steps to minimise your risk:
• Ask your registrar for written, enforceable policy statements. Put it in writing that they must contact you if a domain move is requested.
• Lock the domain name, which requires registrars to hold transfers until passwords or other identifying information is provided to unlock it.
• Keep your authoritative contact information up to date at your registrar. Assume an ignored notification of change will be processed.
• Use registrars with 24/7 service so they can act quickly in case of a breach.
• If there is an unauthorised move, contact the registrars involved immediately.
• If you don't get resolution, go to your domain registry (VeriSign for .com and .net).
• If you still have problems retrieving your domain, contact ICANN resolution ([email protected]).
• If you're a large domain, become your own registrar like Google has.
Or become your own reseller using TuCows.com's open API, OpenSRS, to control all of your domains.