Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
Threat Intelligence |
Sponsored by |
|
After attending the afternoon ICANN Security & Stability Committee meeting, I realized that the issues involved fall into several related but independent dimensions. Shy person that I am *Cough*, I have opinions in all, but I think it's worthwhile simply to be able to explain the Big Picture to media and other folks that aren't immersed in our field. In these notes, I'm trying to maintain neutrality about the issues. I do have strong opinions about most, but I'll post those separately, often dealing with one issue at a time.
ICANN today has made a formal demand stating: "Given the magnitude of the issues that have been raised, and their potential impact on the security and stability of the Internet, the DNS and the .com and .net top level domains, VeriSign must suspend the changes to the .com and .net top-level domains introduced on 15 September 2003 by 6:00 PM PDT on 4 October 2003. Failure to comply with this demand by that time will leave ICANN with no choice but to seek promptly to enforce VeriSign's contractual obligations." What follows is a collection of commentaries made around the net and by experts in response to today's announcement...
Here's another interesting angle on the Verisign Site Finder Web site. VeriSign has hired a company called Omniture to snoop on people who make domain name typos. I found this Omniture Web bug on a VeriSign Site Finder Web page...
A harmful, highly unilateral and capricious action. Tons of software out there depended on the ability to tell the difference between a domain name which exists and does not. They use that to give a meaningful, locally defined error to the user, or to identify if an E-mail address will work or not before sending the mail. Many used it as a way to tag spam (which came from domains that did not exist). It is the local software that best knows how to deal with the error.
Some individual appears to have hijacked more than a 1,000 home computers starting in late June or early July and has been installing a new Trojan Horse program on them. The Trojan allows this person to run a number of small websites on the hijacked home computers. These websites consists of only a few web pages and apparently produce income by directing sign-ups to for-pay porn websites through affiliate programs. Spam emails messages get visitors to come to the small websites.
To make it more difficult for these websites to be shut down, a single home computer is used for only 10 minutes to host a site. After 10 minutes, the IP address of the website is changed to a different home computer...
It seems like spam is in the news every day lately, and frankly, some of the proposed solutions seem either completely hare-brained or worse than the problem itself. I'd like to reiterate a relatively modest proposal I first made over a year ago: Require legitimate DNS MX records for all outbound email servers.
MX records are one component of a domain's Domain Name System (DNS) information. They identify IP addresses that accept inbound email for a particular domain name. To get mail to, say, linux.com, a mail server picks an MX record from linux.com's DNS information and attempts to deliver the mail to that IP address. If the delivery fails because a server is out of action, the delivering server may work through the domain's MX records until it finds a server that can accept the mail. Without at least one MX record, mail cannot be delivered to a domain.
John Banks is a loan officer in New York. John's supervisor recently warned John about the potential number of bad loans he may be carrying as part of his portfolio. To dump some of the bad loans he might be carrying, John came up with a scheme. He pointed his web browser to www.whois.org and entered terms denoting disease or poor health such as 'cancer' and 'illness'. This query on the Internet's WHOIS database reported results of names and addresses of domain name owners who had developed websites devoted to providing information on certain serious illnesses. John compared these names and addresses with those in his portfolio of loans. For the matches, he canceled the loans and required immediate payment-in-full.
A recent study by researchers at the Cooperative Association for Internet Data Analysis (CAIDA) at the San Diego Super Computer Center (SDSC) revealed that a staggering 98% of the global Internet queries to one of the main root servers, at the heart of the Internet, were unnecessary. This analysis was conducted on data collected October 4, 2002 from the 'F' root server located in Palo Alto, California.
The findings of the study were originally presented to the North American Network Operators' Group (NANOG) on October 2002 and later discussed with Richard A. Clarke, chairman of the President's Critical Infrastructure Protection Board and Special Advisor to the U.S. President for Cyber Space Security.
In Part I of this article I set the stage for our discussion and overviewed the October 21st DDoS attacks on the Internet's 13 root name servers. In particular, I highlighted that the attacks were different this time, both in size and scope, because the root servers were attacked at the same time. I also highlighted some of the problems associated with the Domain Name System and the vulnerabilities inherent in BIND. Part II of this article takes our discussion to another level by critically looking at alternatives and best practices that can help solve the security problems we've raised.
The October 21 DDoS attacks against the 13 root-name servers containing the master domain list for the Internet's Domain Name System (DNS), (which reportedly took offline 9 of the 13 servers) remain a clear and daunting reminder of the vulnerabilities associated with online security. Many DNS authorities have named the most recent hit the largest DDoS attack against the root server system. Chris Morrow, network security engineer for UUNET, the service provider for two of the world's 13 root servers, recently told The Washington Post...
A World-Renowned Source for Internet Developments. Serving Since 2002.
