The Front Door is well protected against DNS DDoS attacks, but what about the back?

/in /by

The DNS is the phone book of the internet, and most IP services are entirely dependent on its stability and performance. With the recent rash of DNS DDoS attacks, it has become clear that the DNS needs a special security status. DNS essentially remains a single point of attack, even when it is deployed across geo-diverse locations with hot-standby’s, etc.  DNS needs very careful security attention because if it is down or unavailable, so are all IP services

Therefore, it is understandable that the focus for CTO’s has been about getting the ‘right’ DNS application along with any necessary bodyguards (firewalls, DPI) that their chosen DNS technology requires.  Secure64 customers need not buy any bodyguards, as the DNS servers are self-protecting against DNS DDoS attacks.

But this attention to the “front door” has masked another somewhat obvious way to create a DDoS attack.  The attack vector in this case is the Operating System and/or NFV environment hosting the DNS.

While CentOS and other Operating System technologies have been in use for many years and are widely deployed in datacenters globally, it is truly striking as well as dismaying to look at the GROWTH in reported critical vulnerabilities (CVE’s).  Hackers are digging deeper into the code and finding new ways to attack the OS, generating CVE’s, which have been growing from 10 to 25% per annum.

Below is a chart listing the 2016 vulnerabilities by vendor – Debian had 319; Linux had 217, or quite a number to stop and patch.  Fortunately, there are ways to dramatically alter the OS CVE profile on the DNS platform.

At Secure64, we use a military grade CentOS kernel in every DNS system we ship.  In the last 3 years, the Secure64 CentOS kernel has had zero CVEs, because it completely eliminates entire classes of vulnerabilities, including buffer overflow attacks and remote code execution.  This same CentOS OS can also be deployed in KVM, VMWare and OpenStack environments.  Combining the secure kernel with the Secure64 six layers of DNS DDoS attack protection provides a DNS system with unparalleled security – at both the front door and the back door.

Blocking Attacks from the Incredibly Insecure Internet of Things (IIIoT)

/in , /by

[vc_row][vc_column width=”1/3″][vc_single_image image=”2540″ img_size=”500×500″ alignment=”right”][/vc_column][vc_column width=”2/3″][vc_column_text]

by on OCTOBER 26, 2016

In the wake of the massive attack against DNS provider Dyn, we as a security industry need to ask ourselves “what the hell are we going to do about the usage of dumb, secure-less IOT devices to become a bot army?”

In the fallout after the attack, security experts are tasking end users, device manufacturers, hosting providers and ISPs to prevent its recurrence.   End users need to change passwords, device manufacturers need to harden their machines, hosting providers need to grow their capability and ISPs need to detect spoofed IPs.  Potentially the easiest and fastest way to block massive DDoS attacks is to use the Domain Name System to detect and mitigate bots.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_column_text]

The DNS Knows

The DNS is an incredibly good place to detect and prevent bot activity. Because IP addresses change, every piece of malware needs to call home to get instructions and when it does so, it queries the DNS. When that query tries to link to a known Command & Control Center or phishing site, the DNS can hang up the phone, preventing the malware from getting instructions and participating in a denial of service attack.
Every network that services IOT devices could prevent their widespread usage as a botnet if they implemented this service – and Congress wants ISPs to act. The co-founder of the Senate Cybersecurity Caucus, Senator Mark Warner, asked what network management practices could be adopted by ISPs to repel traffic that might emanate from botnets.  Although using the DNS to identify and block bots would not help them repel traffic, it would prevent devices on the ISP’s network from participating in a botnet. Such a service protects the very Internet itself by using the backbone of the Internet to detect and then prevent bot activity.

To learn more about using the DNS to block bots, watch the recorded Secure64 webinar, “Defending with DNS.”[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2544″ img_size=”500×500″][/vc_column][/vc_row]

DNS Hosting – the problem with centralization

/in , /by

[vc_row][vc_column width=”2/3″][vc_column_text]Recently, Robert Reich argued that the centralization of DNS on the “platforms of giants” has led to the vulnerability of the internet, as witnessed by the massive assault on DNS provider Dyn.  Last Friday’s attack led to problems accessing popular sites, including Twitter, Reddit, PayPal, and Netflix, and has left the world reeling. Our dependence on the internet and the scope of this attack drives the need for answers.

Reich argues that to prevent these colossal assaults, we need to retain the original structure of the internet – a widely distributed, decentralized system, which is counter to the belief that there is safety in numbers.

DNS hosting services have led to much greater centralization than the internet was originally designed, it is true. But this service has been essential to many organizations, including small business, which lacked domain expertise and capital.  Customers of hosting services have enjoyed enterprise-level hosting, including protection against denial of service, which requires specialized expertise.

But what happens when your DNS host is unable to protect you from the attack and indeed, your customers cannot reach your website BECAUSE you are on that service – you are drug down beneath the waves with your fellow tenants to drown?  This is where Reich’s analogy makes quite a bit of sense – and it begs a series of questions.  Do you become more vulnerable as each tenant is added?  Is the risk worth the reward?  Do you have the resources to go it alone and self-host, and should you?

If you are considering this potential strategy in the wake of the attack, you should know that you will actually be able to increase your DNS security by requiring a secure architecture that provides built-in protection against high volume DDoS attacks.[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2526″ img_size=”500×600″ alignment=”center”][/vc_column][/vc_row]

Water Torture: A Slow Drip DNS DDoS Attack

/in , /by

A number of our service provider customers around the world are reporting that they see a new type of DNS DDoS attack that uses the DNS as the attack vector. The service providers themselves do not appear to be the target of this attack. Instead, the attack tries to overwhelm an outside victim’s authoritative DNS servers. Once the DNS server is taken down, the victim’s domains will appear to be inaccessible.

As a side effect, our service provider customers are seeing a spike in DNS traffic resulting in increased CPU and memory usage. This blogs gives some more details about the attack and suggests what you can do to mitigate the impact of it.

The Attack

It appears that a fairly large botnet is used to send queries for the victim’s domain. Queries are made-up, with random string with up to 16 letters prepended to the victim’s domain, like:

xyuicosic.www.victimdomain.com

A query for this domain is then sent to the service providers DNS server. The DNS server attempts to contact the authoritative nameserver to find the answer. If the authoritative nameserver does not reply (because it is too busy responding to queries from DNS servers all over the world, or perhaps has crashed), the DNS server attempts to contact the next authoritative nameserver and so on. Modern DNS server will make multiple attempts to contact each authoritative nameserver before giving up and responding back to the client with a SERVFAIL response.
The infected client will then repeat the same pattern but this time with another random string prepended, for example:

alkdfasd.www.victimdomain.com

Even though the DNS server was unable to get a response from any of the victimdomain.com authoritative nameservers during the previous query, most DNS servers will still attempt to contact them for this second query.
Now imagine that thousands of bots are sending a relatively small number of queries for such made-up subdomains. This will trigger a large increase in the number of DNS queries sent by the service provider’s DNS servers to the victim’s nameservers.

How to Detect the Attack

While this attack most likely is targeting the authoritative servers for victimdomain.com, it also puts an increased CPU load on the DNS server by forcing it to continually initiate recursive queries and also consumes large amounts of resolver memory resources. More importantly, if the internal resolver resources are fully consumed, the resolver may drop any inbound queries, including queries from legitimate clients.

If the DNS server’s behavior is being monitored, the symptoms of the attack will also show up as:

  • Increased CPU utilization
  • Increased number of SERVFAIL responses
  • Increased number of outbound queries and retransmissions
  • Increased query latency
  • Increased number of dropped client queries (if the resolver resources are fully consumed)

One thing all of the victim domains have in common is that they appear to be Chinese sites, perhaps gaming or gambling sites.

How to Block the Attack

Because the query rate from each client IP address is quite low and because there is no response amplification, it is difficult to determine simply from packet rates or bandwidth consumption which client IP-addresses are participating in the attack. And because the names change periodically, it can be time consuming to track and block queries to the domains being used in the attack.

However, here are some specific steps you can take to minimize the impact of the attack:

  • Check your timeout settings. Most resolvers allow you to specify the initial and subsequent timeout intervals. Make sure that these values are not too high (if they are, they will tie up resolver resources longer than necessary before a query fails).
  • Increase the number of outstanding recursive queries if you have sufficient RAM on your server. This will give the resolver more resources to work with.
  • Specify a non-zero TTL for the negative responses so that if a client requests the same non-responsive name more than once, the SERVFAIL answer is cached. By RFC, you should be able to specify up to a 5 minute TTL.

Secure64 Defenses

Secure64’s DNS Cache has built-in defenses against such an attack. Under attack conditions, the Secure64 resolver will not consume any CPU or memory resources attempting to reach nameservers that it already knows are non-responsive. This adaptive behavior allows the Secure64 resolver to remain 100% available to legitimate clients under such attack conditions.