How To Protect Yourself Against Domain Name Hijackers
Companies overlook the threat of getting their domain names stolen from under them. Here's how to protect yourself.
Domain name hijacking broadly refers to acts where a registered domain name is misused or stolen from the rightful name holder. A domain hijacking is a security risk many organizations overlook when they develop security policy and business continuity plans. While name holders can take measures to protect their domain names against theft and loss, many measures are not generally known.
How Serious Is Domain Hijacking?
The answer is best illustrated with examples. In one hijacking scenario, you begin the day as an e-merchant doing business online at 'www.onlineseller.example.com.' At 2:15 p.m. that afternoon, your visitor traffic and merchant transactions disappear. You investigate and discover someone’s impersonated your company’s administrative contact, transferred your domain name to a different registrar, and modified the DNS. Visitors to your domain name land at a hoax Web site that impersonates your virtual store. Improbable? It happened to Hushmail in April of this year.
In another scenario, the email service you provide to thousands of users suddenly stops. You discover someone’s transferred your domain name to another registrar without your notice or consent. Your DNS configuration has been modified, and your user’s email is being delivered to someone else’s mail server. Hours later, your registration is restored, but only after an exhausting and frustrating incident response effort. Preposterous? It happened to PANIX back in January, 2005.
Internet Corporation for Assigned Names and Numbers (ICANN) CEO Paul Twomey says that while “a domain hijacking is not as obvious a threat as spam and spyware, it can be just as disruptive to the business and operations of name holders; in extreme cases, a domain hijacking can have a lasting impact on an organization."
It may seem implausible that the consequences could be so severe, but domain name holders attribute value to their domain names, both tangible and intangible.
Tangible value increases when consumers associate brand with a domain name (in a positive way). Intangible value increases in proportion to the reputation of a domain name: the domain name of a respected security consulting company is worth more than any financial compensation the company is likely to recover through legal means. Speculative value--the ability to “acquire” a desirable domain name and resell it--creates additional incentives for would-be hijackers, who are motivated by financial gain as well as notoriety.
The threats are real, and include denial and theft of electronic mail services, identity theft, traffic inspection, web site defacement, loss of revenue and even irrecoverable loss of online business operations.
How To Protect Yourself
The Security and Stability Advisory Committee (SSAC) report from ICANN, Domain Name Hijacking: Incidents, Threats, Risks and Remedial Actions , describes measures all parties to the registration process can take to protect domain names. Name holders (“registrants”) have a number of measures at their disposal that can measurably reduce the likelihood of a domain hijacking:
Make domain name protection a part of your security policy. Identify domain names as an asset and perform a risk assessment. Incorporate domain name hijacking into your incident response and business continuity planning, and develop an “urgent restoration of domain name and DNS configuration” strategy as part of business continuity planning. Investigate whether business interruption and losses related to a domain name or DNS configuration incident are covered by insurance policies.
Keep your registration records and contact information accurate. You give hijackers an edge if you fail to keep your contact information accurate. You can’t expect a registrar to know when you change staff, offices, or the email address used in domain name transfer communications. Keep business and emergency contact information for your registrar accurate and available for your incident response staff.
Keep your registrant account information private, secure, and recoverable. Protect this account information as you should every user account and password. This information should only be made available to staff in your company whose role(s) involve domain name administration. When staff changes, change account information, especially passwords. Use a name other than your Transfer Contact email address as your login to registrar domain name self-administration pages. Hijackers use the Whois service to identify transfer contact email addresses of targeted domain names, and will routinely check whether your Transfer Contact email address doubles as your account user name.
Lock it up. Request that domain names be placed on Registrar-Lock. In this state, your registration information and DNS configuration cannot be changed until you unlock your name. This important step can block many domain name transfer attacks. Registries that support the Extensible Provisioning Protocol (EPP) provide a second “lock”, the Authorization Information Code or “authInfo”. If EPP is implemented, your registrar must provide you with your “authInfo” code within five days of your request to transfer a domain “out”. You must then provide this code to the gaining registrar to initiate the transfer “in”. Some registrars let you set the authInfo value. Use a unique EPP authInfo code for each domain name you register; if one authInfo code is broken, only one of your domain names can be put at risk.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.