Secure64 SourceT OS not vulnerable to NTP flaws

/in , /by

CERT recently reported two Network Time Protocol (NTP) vulnerabilities (CERT VU#374268 April 7, 2015) . The first one concerns some versions of NTP Project software that will accept packets without authentication digests as if they actually had valid digests attached, and the second one describes a Denial of Service (DoS) scenario in which an attacker can prevent two peering systems from synchronizing. Neither NTP vulnerabilities affect Secure64 servers.

In the first case, no NTP Project code is used in the Secure64 NTP implementation.  In this implementation, associations that specify the use of authentication digests require all incoming and outgoing packets to have attached digests; any incoming packet without the required authentication information is treated exactly like a packet with an invalid digest, and is dropped.

In the second case, Secure64 NTP never peers with external servers, but rather forms a consensus among servers using periodic timestamp queries. This approach is not as precise as traditional NTP peering, but provides timestamp resolution well within the requirements of DNSSEC signing operations.  Since there is no peering being used, there is no way to disrupt a peering session, and hence no DoS vulnerability. This strategy conforms to the security best-practice of minimizing the code paths that are traversed, in order to maximize resistance to network exploits.

More Defenses Against Pseudo Random Subdomain Attacks (PRSD)

/in , /by

Last year we reported a new kind of DNS attack that we called the “Water Torture Attack”. This attack is also known as the Pseudo Random Subdomain Attack (PRSD, although we still like our name better).

In this attack, hackers send queries to open proxies around the world for random, non-existent subdomains of legitimate domains. For example:

alkuwrejghnlokiqhje.example.com.

These queries are forwarded to DNS resolvers at the upstream ISP. Although the attacks are intended to take down the authoritative servers for these legitimate domains, they have the side effect of dramatically increasing the load on ISP’s DNS resolvers to the point that they, too, can become overloaded and either slow down or crash.

Here are some additional steps that DNS operators can take, in addition to the steps we outlined in our previous blog, to protect their resolvers from these attacks:

1. “Prudently provision” their servers with enough RAM and query capacity. The attacks impact the resolver because it causes them to run out of critical system resources. By increasing these resources, the resolver may be able to sustain the higher recursive query loads.

2. Tune their configurations to maximize the number of simultaneous recursive queries allowed.

3. Automatically block IP addresses generating too many SERVFAIL responses, if possible. This capability is not available in many DNS resolvers, but is a new feature of our DNS Cache product.