Blocking Bad Internet Content – do it at the DNS

/in /by

[vc_row][vc_column width=”2/3″][vc_column_text]On June 9th, Ethiopia became the latest nation state to move to legislate on Internet content.  I, for one, am sold on the idea of blocking bad internet content, especially illegal content.  Give organisations, institutions and parents control over what internet content comes through their networks. It is empowering.  It is also clear that many blanket content category bans can take you towards censorship of free speech . Did anyone follow the Australian experience over the last 8 years ?  https://en.wikipedia.org/wiki/Internet_censorship_in_Australia[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”3229″ img_size=”500×300″][/vc_column][/vc_row][vc_row][vc_column width=”1/3″][vc_column_text]The flag of Ethiopia[/vc_column_text][/vc_column][vc_column width=”2/3″][vc_column_text]But this is a technology blog. So in Ethiopia, they will surely now be debating how to achieve this technically.  Two options will be discussed –  to block it on the device or  block it beforehand – in the DNS.  We may be biased, but in our opinion there is usually only one winner in such a debate – DNS.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_column_text]Every internet transaction has to be resolved by DNS – it’s the control point for the internet.  It’s easy to maintain whitelists, blacklists and regulatory compliance  at the DNS.  It is fast with low latency; it cannot be easily bypassed; and it requires nothing to be installed on the device so there are no user dependencies.

Blocking on the PC/device involves use of technology that inevitably slows performance, needs to be maintained across the enterprise and then there is the BYOD complication.

I like the elegance of DNS-based ‘decision making’.  It can be used for multiple roles in content management, authentication and user protection.[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2229″ img_size=”300×300″][/vc_column][/vc_row]

New Year, New BIND Security Vulnerabilities.

/in /by

[vc_row][vc_column width=”2/3″][vc_column_text]We are barely into the new year, and BIND users have more patching to do.

Today, the Internet Software Consortium (ISC) announced the availability of patches to fix two critical BIND security vulnerabilities:

• CVE-2015-8704

• CVE-2015-8705

Both of these vulnerabilities Read more

The Grinch Comes Early for BIND Users

/in , , /by

[vc_row][vc_column width=”2/3″][vc_column_text]The grinch showed up early for BIND users this year, in the form of two new critical security vulnerabilities that can crash BIND. The two vulnerabilities are:

• CVE-2015-8000

• CVE-2015-8461

ISC has released patches of its BIND software that correct the problem.

Users of BIND-based appliances from vendors such as Infoblox, Bluecat Networks, BT, Efficient IP, Radware and F5 are advised to contact their vendor for more information about the availability of a patch.

Secure64 products, which are not based on BIND, do not have these vulnerabilities.

[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2518″ img_size=”500×600″][/vc_column][/vc_row]

When It Rains, It Pours. More BIND Vulnerabilities.

/in , /by

September 2, 2015 was not a good day for BIND users. Two new critical security vulnerabilities were announced today – both of them are remotely exploitable vulnerabilities that crash the server. The two vulnerabilities are:

CVE-2015-5986

CVE-2015-5722

ISC has release patches of its BIND software that correct the problem.

Users of BIND-based appliances from vendors such as Infoblox, Bluecat Networks, BT, Efficient IP, Radware and F5 are advised to contact their vendor for more information about the availability of a patch.

Secure64 products, which are not based on BIND, are not vulnerable to these security threats.

Secure64 DNS Products Not Vulnerable to BIND Security Flaw

/in , , /by

On July 28, 2015, the Internet Systems Consortium reported a critical security vulnerability in BIND, CVE-2015-5477. This vulnerability, which affects both BIND recursive and authoritative servers, is caused by an error in the handling of TKEY queries, allowing a remote attacker to crash BIND by sending a deliberately constructed query.

This vulnerability is considered critical, as it cannot be prevented through ACLs or configuration options, and affects all versions of BIND 9 (BIND 9.1.0 through 9.10.2). Successful attacks on unpatched BIND servers can result in a loss of DNS service, potentially making an organization’s web, email and other internet-connected servers unreachable.

BIND users are strongly encouraged to patch their servers immediately, as attacks against the DNS servers have already been reported. BIND-based appliances are also vulnerable and should be patched – customers are encouraged to contact their vendors for additional patching information.

Secure64 DNS Cache and DNS Authority products, which are not based on BIND, do not contain this flaw, and do not require a patch to provide protection against these attacks.

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.

Don’t drown in the IPv6 address sea

/in , /by

Our Chief Operating Officer, Joe Gersch, recently authored this blog post on managing large numbers of reverse DNS records at our partner, 6connect’s, blog site:

http://www.6connect.com/blog/dont-drown-ipv6-address-sea/

Secure64 DNS Cache not vulnerable to recently announced resource exhaustion bugs

/in , /by

Secure64 has confirmed that its DNS Cache product is not vulnerable to the latest BIND Vulnerability bug announced by ISC on December 8, 2014. This BIND bug is categorized as severe and remotely exploitable, and is the 9th such vulnerability in the past 24 months. The announcements describe flaws in the BIND DNS resolver that could cause it to issue large numbers of queries to resolve names in maliciously constructed zones, leading to resource exhaustion and is exploitable to launch denial of service attacks.

The ISC vulnerability announcements can be found here:

ISC                           CVE-2014-8500                  https://kb.isc.org/article/AA-01216

Unlike some previous CVE’s, immediate patching is available for ISC BIND. Users of BIND-based appliances like Efficient IP, Infoblox and Bluecat should check the vendor web sites.

Bluecat: A support note is posted at https://www.bluecatnetworks.com/support/security_updates/2014

Secure64′s DNS Cache product is not susceptible to this vulnerability or any of the previously announced BIND vulnerabilities. DNS Cache limits the amount of resources that are consumed by the resolver under normal and attack conditions to remain available and responsive, even under resolver-targeted attacks.

DNS is arguably the most critical control point for every on-line business and IP based service. Secure64 is a software applications company enabling secure DNS services and is built upon the industry’s only genuinely secure platform. Secure64 DNS technology brings protection to over 180 Million on-line users, supports 85% of all internet reverse DNSSEC and is used by leading service providers, enterprises and government organizations.

For more information on Secure64′s DNS capabilities and the latest wave of potent DNS attacks please request the “Death by One Thousand Paper Cuts” white paper by clicking on the Contact Us button the home page of our website www.secure64.com and filling in the contact form.

Latin America Going IPv6-only

/in , , /by

IP address assignments around the world are handled by the Regional Internet Registries (RIR). In the beginning of May, I had the pleasure to attend and be a speaker at the LACNIC (the Latin American RIR) conference in Cancun, Mexico. My talk about IPv6 and DNS was very well received and I think the audience really understood how running the DNS supporting dual stack or IPv6-only clients differs from running in a pure IPv4 environment. There were several other talks, most of them discussing IPv6 and how to handle the depletion of IPv4 addresses.

In terms of the depletion of IPv4 addresses, all RIRs have implemented a phased approach to handing out their remaining IPv4 addresses. In this phased approach it will be harder and harder to get IPv4 addresses allocated from the RIRs as they move from phase to phase. Most RIRs have decided that the first of these phases, the depletion phase, will be reached when about 16 million addresses (A network of size /8) are still available in their pool. However, LACNIC took a somewhat different approach. Instead they decided to go into a limited depletion phase when they reached 8 million (/9) free addresses and a more restrictive phase once they reached 4 million (/10) free addresses.

At the time of the event, LACNIC had around 14-15 million addresses left in their free pool. Demand for the last blocks has been very high and on May 20th, LACNIC announced that they are down to one /9. This means that LACNIC entered the more restrictive depletion phase and also triggered the RIR’s parent organization (IANA) to send some recovered addresses to each RIR (about 2 million addresses to each RIR).

The next phase for LACNIC was triggered on June 10th when they reached a /10 (about 4 million addresses).  Once this phase is reached the policy restricts allocation to only 1000 addresses every 6 months per member. 1000 is not a lot of addresses – they can perhaps be used for translators when implementing IPv6 so that backwards compatibility with IPv4 still can be achieved using NAT64/DNS64 but not to any dual stack deployment.

The final phase will occur when a /11 (about 2 million addresses) are left. At that point a limited number of IPv4 addresses will only be available for new members.

We are, in other words, very close to going IPv6-only in Latin America. During the last year this region has used up a lot of IPv4 address space and is currently the region with the fewest IPv4 addresses remaining. Latin American service providers should make sure their DNS servers can receive traffic over IPv6 so that their customers can still reach them.

Heartbleed SSL Bug, DNS and the Perils of a Monoculture

/in , /by

 

The Heartbleed flaw in OpenSSL highlights a critical vulnerability in the structure of the Internet: lack of diversity in critical software and hardware that run everything.

Use of “free” open source software and commodity hardware enables a lot of applications and services to be delivered inexpensively but also leaves critical infrastructure open to exploitation by a single attack or bug. No system can be resilient if a single point of failure can take it out.  To be resilient the Internet needs redundancy and genetic diversity in its systems.

Cryto libraries are just one example of the genetic software bottleneck. Another is web servers; they are dominated by Apache and Microsoft with a roughly 70% combined market share.

A third example is the DNS. Over 85% of the DNS software in use today is BIND – which historically has disclosed a new critical vulnerability every few months. It is likely there are multiple governments and perhaps terror/crime-that-is-organized that could take it down in several ways.

The DNS knows everything that happens on the Internet  – every web lookup, every email, every phone call and text. Nothing in the cyber world works and nothing is secure without secure, reliable DNS. Yet a critical exploit of BIND would effectively take out the Internet.  No phone, no navigation, no Internet of anything.

What would you do in such a doomsday scenario? Wait for your bank statement by snail mail. Drop by the bank teller line to make a deposit or withdrawal. Pull out those CDs to listen to music. Fax those documents. Keep the Rand McNally map handy. Got a dictionary or encyclopedia?

Maybe civilization goes on but it sure would be a mess until fixed.

The Heartbleed bug is an inconvenience but it serves as a wake up call. If we are serious about reducing our exposure to potential cyber catastrophe we need to diversify critical infrastructure, starting with the DNS. Secure64 does not use BIND or OpenSSL in our DNS products.