One of our recent clients asked us to review their existing Internet sites and make sure that they were in a position to avoid problems like hijacked URLs or loss of service caused by a failed xSP. During our investigation, we found that the client actually owned only one of the four domains it had registered. The other three were owned by the client’s ISP, which was charging the client $100 per year to “maintain” the sites. We were able to get the domain names and contacts moved to the customer and eliminate these bogus charges.
Another customer wasn’t so lucky. Their ISP wasn’t paying attention to their domain name registration warnings (having just acquired the customer from a recent acquisition). The registration expired, and the company opened its doors to hundreds of phone calls from angry customers who navigated to the company Web site only to be greeted by an offer for the finest collection of German flesh sites. They were able to re-acquire their domain name for a small blackmail fee of $5,000. To avoid becoming the victim of these types of scams or other common security and connection problems, you should take a quick inventory of the common problems you’re likely to encounter: domain ownership issues, domain access issues, and domain certificate services.
Protecting your domains
To protect your Web site assets, you should do two things. First, get a list of all of your company’s registered addresses. You may think that the only addresses your company has registered are those with the company.com or company.net domains. But many departments create their own URLs for projects or may have consultants or ad agencies create URLs for them. If any of these are in production, you should add them to your list. If they’re not, you should release them before someone implements a system using one of them.
Second, you should change all of your administrative contacts and technical contacts to individuals in your organization. These may be the same staff members who are responsible for other technical services, like security or technical asset management. You may also consider setting up fake e-mail addresses like AdminWeb@Company.com or TechWeb@Company.com. This gives you two advantages. First, the e-mail addresses won’t have to be changed if the person responsible for maintaining the e-mail address leaves the company. Second, when (not if!) Web crawlers look for contact addresses for spam advertisements, it won’t litter up the company mailbox. You can also set up custom filters and forwarding rules on the e-mail addresses to get rid of the junk and forward important messages from the real registrar to someone in the organization who can handle them.
Protecting access to domains
Even if your servers are running, and you have clear rights to the domain names, that doesn’t mean that everyone on the Internet can find them. Location is handled by a series of domain name service (DNS) servers housed on the Internet. When you first register a domain, you have to tell the registrar which DNS will handle location services. Unfortunately, many companies who chose local providers or data centers to provide these services have been surprised to find out that when the companies fail, the DNS gets turned off—cutting off access to customer sites.
To guarantee continued access, you should update your DNS entries for each domain to include a DNS server from two different providers as primary and secondary servers. You may also consider running your own internal DNS server as the secondary server for all of your domains, and then using an external provider as the primary. This will provide continued access if the primary provider’s servers are down, and will give you more control over the registration of new domains. Many companies run their public DNSs using a Linux box with one of the publicly available DNS servers, or a Microsoft Windows 2000 box using the built-in DNS.
Securing your domains
Although using server and client certificates to secure all or part of your domain using a Secure Sockets Layer (SSL) connection doesn’t pose a security issue, it can pose a financial one. Paying an external service to provide certificates makes sense for public Web sites where operators want to collect confidential information or sensitive financial data. But it may not be the most cost-effective solution for companies needing certificates to allow employees or trading partners to access their network. It often makes better financial sense to set up and maintain your own certificate server in that scenario.
There are publicly available, Linux-based certificate servers, and Windows 2000 has its own built-in certificate server. As long as your trading partners accept your company as a certificate authority, you can issue your own certificates. This allows you to set up secure communications for Web sites or Web services between your company and the trading partner. Until there is an industry standard for authentication, it’s likely to be your company’s best bet for allowing secure external access to your domains.