How to ensure your DNS server is protected from hijacking

Too many DNS servers are hijacked by malicious people and used to implement DDoS attacks. In today's article, we will explore how to ensure that we are protected from such malicious behavior.

Although it now seems to be old, but just about 20 years before the advent of the Internet, we were faced with a huge problem: The mail server is too friendly.

In short, most mail servers allow anyone to access and send messages to any recipient. To achieve this, we don't even need to be a user of a mail server, or just a little bit of effort to disguise ourselves as a user.

An attacker could use the mail server's mail SMTP receive port (TCP port 25) to implement the connection, and to mimic all the internal commands that the SMTP server uses to Exchange messages (via Telent, scripts, or other programs). As a result, hackers will be able to forge e-mail messages, claim that they are from a legitimate user hosted by a mail server, and send any message content to any recipient.

Spammers will look for such "open forwarding" servers and send millions or even billions of spam messages to all over the world. Global technicians-and mail server vendors-have spent about 20 years forcing all originating messages to be verified by the actual source and issued by authenticated users.

Over the years, however, similar open-forwarding issues have emerged in another fundamental technology in the Internet domain, namely DNS. Attackers often use improperly configured DNS servers to send invalid IP addresses to query clients-or send a large amount of spurious traffic to implement a DDoS attack.

Using DNS to implement DDoS attacks

DDoS and other attackers have been using DNS to enforce their evil plots for years, but the situation has intensified over the past few years.

Most large-scale DDoS attackers have been using DNS "amplification" technology frequently in recent times. If you are interested in their specific implementation and background information, you can check the Us-cert, Internet Systems Alliance and CloudFlare on the relevant materials (in English).

Eventually, the DNS server vendor and the protocol developer had to do the same, as did the protection efforts of the SMTP mail provider that year. These include better default settings and a new defense mechanism. Unfortunately, the DNS servers-although they may seem to be running well-are still overlooked and continue to retain a large number of security vulnerabilities that attackers do not want administrators to discover.

Disable the open forwarding DNS server

The protection that every business customer can easily achieve is to limit what and who requests the DNS server responds to. For an internal DNS server, we need to make sure that it only gives DNS responses to queries from internal computers or other authenticated DNS servers.

Even in an external environment, a public-facing DNS server should not respond to all requests in a brain-free manner. If everyone's DNS server is hosted on the *.example.com address, there will never be a legitimate user outside the domain name address query. If everyone's DNS server is currently responding to all queries from any user, especially requests from any domain name, then this is an open forwarding DNS server--trust me, this is no good.

In order to ensure that our DNS server is not classified as an open forwarding class, and that it is strictly locked and guaranteed to operate legally, please enter its IP address into the following DNS open forwarding detection services for security testing:

· Open Resolver Project

· Open DNS Resolver Check Site

· DNS expertise-the Measurement Factory

· DNS Inspect

DNS Response rate Limit

As one of the best defenses against the use of our own DNS servers for DDoS attacks, we should limit them to a response rate (RRL). RRL is primarily for authoritative DNS servers (that is, DNS servers that should respond to one or more domain names), and allows DNS administrators to make effective rate limits for DNS response traffic. Although it is not enabled by default (but should definitely be enabled!), we can find RRL in bind 9.9 (and subsequent versions) as part of Microsoft's upcoming DNS service for Windows Server.

If your DNS server does not support RRL, you can try to use other alternatives to achieve the same effect, including using firewall rate filtering or other anti-DDoS services to protect your DNS.

Disable up-Referral response

For most DNS, when a non-recursive authoritative DNS server receives an unauthenticated domain name query, the DNS server redirects the query client directly to the top-level DNS server (which can be arranged by name and IP address in the file hosting ' root hints '). It's a polite approach, similar to "Hey, I don't know what the answer is, but I suggest you try your luck over there." ”

But in fact, this approach is tantamount to destroying people's lives for personal reasons, and the advent of DNS amplification attacks has also made this use of root hints a source of criticism. Bind has long recommended that you disable this upward referral behavior. Microsoft plans to disable the up-referral mechanism by default in its Windows Server 2016, and everyone can delete the root hints file (C:\windows\system32\DNS\cache.dns). Disable this feature in earlier versions of Windows Server.

Check all DNS Services

Scan for TCP or UDP port 53, which is used by computers and devices to receive connections, to check and securely configure all computers and devices that are running DNS services. In general, you will find that there are some devices and network devices (such as wireless routers) that run unplanned DNS servers.

Invitingthieves is the most foolish

The DNS protocol has had a good performance since it was born in 1983. It has experienced abuse and subsequent updates as a remedy, but in general it still plays a central role in guaranteeing the proper functioning of the Internet. However, we must not be complacent about the existing level of security, especially in the area of DNS.

At the end of the article, I would like to remind you not to let your DNS server repeat the original public mail server mistakes-as a member of the modern IT world, we can not take more than 10 years to solve the problem that should be fixed long ago.

How to ensure your DNS server is protected from hijacking