Best-Selling Hosting

Top Rated Providers

Editors Pick

Close Open DNS Servers Published: Mar 16, 2006
  • Rating

    0/5

Internet security experts warned Tuesday of a serious security vulnerability in the Transmission Control Protocol (TCP) a critical communications protocol used on the majority of computer networks in the world, according to an advisory from the United Kin

Experts warn of TCP vulnerability
Networking companies are expected to issue advisories
 
Internet security experts warned Tuesday of a serious security vulnerability in the Transmission Control Protocol (TCP) a critical communications protocol used on the majority of computer networks in the world, according to an advisory from the United Kingdom's National Infrastructure Security Co-Ordination Centre (NISCC).

The hole exists in all implementations of TCP that comply with the Internet Engineering Task Force's TCP specification. By exploiting the holes, malicious hackers could cause TCP sessions to end prematurely, creating a "denial of service," or DOS attack. The TCP vulnerability could also disrupt communications between routers on the Internet by interrupting BGP (Border Gateway Protocol) sessions that use TCP, NISCC said.

The US-CERT Coordination Center issued a warning on Tuesday about the vulnerability. The warning cited an almost three-year-old advisory and said that sustained exploitation of the hole could lead to denial of service affecting "portions of the Internet community." (See: http://www.cert.org/advisories/CA-2001-09.html)

BGP is the most commonly used routing protocol used by major external routers on the Internet. Major ISPs (Internet service providers) use BGP to configure redundant high-speed connections and to coordinate with other ISPs and other peers, said Dan Ingevaldson, research director at Internet Security Systems Inc. (ISS).

"It's the protocol that handles the big pipes on the Internet," he said.

NISCC and US-CERT issued their advisories after a security researcher, Paul Watson, described the problem in a paper called "Slipping in the Window: TCP Reset Attacks." Watson will be presenting the paper at the CanSecWest 2004 security conference in Vancouver, Canada, this week. 

Watson discovered that the current TCP standard allows a malicious hacker to easily guess a unique 32-bit number needed to reset an established TCP connection because the standard allows sequence numbers in a range of values to be accepted rather than just exact matches, according to the NISCC advisory.

By spoofing the source IP (Internet Protocol) address and the TCP port, then randomly guessing the unique sequence number, an attacker could cause an active TCP session to terminate.

Networking experts have known about the potential for such attacks for almost 20 years. However, as Internet use and the use of broadband Internet connections has grown over the years, ISPs and others have gradually increased the size of the "window," or range of acceptable sequence numbers that they permit to reset a connection, making a successful DOS attack more plausible, Ingevaldson said.

BGP sessions are particularly vulnerable to such attacks because they are longer, more predictable connections that often take place between two devices with published IP addresses, he said.

"Attackers know where they are and where they're going, they know the ports on either side that are being used and the window," he said.

ISS notified its customers about the hole and said that network infrastructure providers and enterprises' internal networks are the most vulnerable to DOS attacks that use the vulnerability.

Leading networking equipment vendors Cisco Systems Inc. and Juniper Networks Inc. are expected to release advisories for their customers this week that explain which of their products contain BGP code vulnerable to attack and to offer updated versions of operating system software for those devices that fix the problem, according to the a message posted on the Web site of SANS Institute's Internet Storm Center.

Despite the dire warnings, the impact of the TCP hole will probably be small, Ingevaldson said.

Leading networking vendors have probably been in conversation with US-CERT and the NISCC far in advance of the news becoming public, giving those companies time to prepare a patch. Also, the BGP protocol was designed to be resistant to attack and to support digital signatures using algorithms such as MD5 that can prevent spoofing, he said.

"This is a serious issue because it's widespread, but there probably won't be a widespread impact," he said.

  • Rating

    0/5

Related Articles

Comments (20)

  • Gravatar - Jen
    Jen 19:58, March 20, 2006
    If you have multiple servers running off the same DNS, make sure that you put all those server IPs in the trusted area if they are resolving through that DNS:<br />
    <br />
    <pre>acl "trusted" {<br />
    mainIP;secondaryIP;firstserverip;secondserverip;127.0.0.1;<br />
    };</pre><br />
    <br />
    Otherwise, great tutorial.
  • Gravatar - zac
    zac 21:57, March 22, 2006
    actually all you need to do is tihs:<br />
    <br />
    options {<br />
    recursion no;<br />
    };<br />
    <br />
  • Gravatar - Rajesh
    Rajesh 09:42, March 23, 2006
    i did as per the instructions but the "Open DNS Servers" still show fail. please let me what else is to be done.
  • Gravatar - Andrew
    Andrew 20:11, March 23, 2006
    The above breaks Bind on a VPS
  • Gravatar - Rajesh
    Rajesh 10:10, March 29, 2006
    I did as mentioned above but still the "Open DNS Servers" show fail in the DNS stuff.
  • Gravatar - dew
    dew 11:40, April 12, 2006
    really
  • Gravatar - alan
    alan 12:46, April 18, 2006
    this worked as-is for me
  • Gravatar - valtea
    valtea 20:35, April 19, 2006
    My server have <br />
    <br />
    root@server [/etc]# cat named.conf<br />
    include "/etc/rndc.key";<br />
    <br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    So where do i Add <br />
    acl "trusted" {<br />
    mainIP;secondaryIP;127.0.0.1;<br />
    };<br />
    Will it be on the same line with the keys after "rndckey"; <here><br />
    or <br />
    "rndckey"; }; <Here><br />
    };
  • Gravatar - Ryan
    Ryan 02:22, May 4, 2006
    Did anyone come up with an answer for valtea or does anyone know? I have been researching until I am blue in the face.
  • Gravatar - Dan
    Dan 16:54, May 13, 2006
    Got the same problem as valtea!
  • Gravatar - Kyle
    Kyle 19:34, May 15, 2006
    Same problem as above!
  • Gravatar - Steve
    Steve 17:46, May 18, 2006
    Add it after the controls section. <br />
    <br />
    EG:<br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    <br />
    Add it here<br />
  • Gravatar - Nick
    Nick 08:35, June 27, 2006
    Thanks, this tutorial worked great!
  • Gravatar - Spock
    Spock 21:15, July 9, 2006
    Steve, I tried adding it after controls, but I receive this error:<br />
    <br />
    Stopping named: [ OK ]<br />
    Starting named: /etc/named.conf:17: missing ';' before '}'<br />
    /etc/named.conf:18: missing ';' before '}'<br />
    /etc/named.conf:19: missing ';' before '}'<br />
    <br />
    Jul 10 04:12:50.694 starting BIND 9.2.4 -g<br />
    Jul 10 04:12:50.717 using 1 CPU<br />
    Jul 10 04:12:50.722 loading configuration from '/etc/named.conf'<br />
    Jul 10 04:12:50.723 /etc/named.conf:1: open: /etc/rndc.key: permission denied<br />
    Jul 10 04:12:50.723 loading configuration: permission denied<br />
    Jul 10 04:12:50.723 exiting (due to fatal error)<br />
    Error in configuration file /etc/named.conf : [FAILED]<br />
    <br />
    ===================<br />
    Here are the first lines of my named.conf:<br />
    <br />
    include "/etc/rndc.key";<br />
    <br />
    controls {<br />
    inet 127.0.0.1 allow { localhost; } keys { "rndckey"; };<br />
    };<br />
    <br />
    acl "trusted" {<br />
    ip1;ip2;ip3;ip4;ip5;127.0.0.1;<br />
    };<br />
    <br />
    //<br />
    // named.conf for Red Hat caching-nameserver<br />
    //<br />
    <br />
    options {<br />
    directory "/var/named";<br />
    allow-recursion { trusted };<br />
    allow-notify { trusted };<br />
    allow-transfer { trusted };<br />
    dump-file "/var/named/data/cache_dump.db";<br />
    statistics-file "/var/named/data/named_stats.txt";<br />
    /*<br />
    * If there is a firewall between you and nameservers you want<br />
    * to talk to, you might need to uncomment the query-source<br />
    * directive below. Previous versions of BIND always asked<br />
    * questions using port 53, but BIND 8.1 uses an unprivileged<br />
    * port by default.<br />
    */<br />
    // query-source address * port 53;<br />
    version "surely ye jest?";<br />
    };<br />
    ===================<br />
    Suggestions?
  • Gravatar - Spock
    Spock 21:27, July 9, 2006
    Solved it! I just missed the ";" after the words trusted inside allow-recursion { trusted; }; etc.
  • Gravatar - Andrew
    Andrew 04:40, July 20, 2006
    How long does it takes dnsreport.com to update this info after you make changes?
  • Gravatar - Hussein
    Hussein 05:50, October 15, 2006
    Like Zac above noted.<br />
    All you need to do is add a like in the options sections that looks like this:<br />
    <br />
    recursion no;<br />
    <br />
    This should close your server.<br />
    <br />
    If you need to harden and secure Bind even more, you can have a look at this site:<br />
    <br />
    http://www.cymru.com/Documents/secure-bind-template.html<br />
    <br />
    You need to be carful, and back up your named.conf file before testing, but this is a complete secured Bind template.<br />
    <br />
    Cheers
  • Gravatar - Ricardo
    Ricardo 05:44, April 4, 2007
    I did all this things but the problem i have is that then my clients stop receiving emails and they are not able to send either i have added all the ips of the server plus 127.0.0.1...any ideas?
  • Gravatar - G
    G 03:59, June 1, 2007
    thanks worked a treat
  • Gravatar - ahmed
    ahmed 07:55, February 25, 2010
    close open dns

Add Your Thoughts

WebHostGear.com is a hosting directory, not a web host.

Copyright © 1998-2010 WebHostGear.com