DNS system and DDOS attack association

Intermediary trading http://www.aliyun.com/zixun/aggregation/6858.html"> SEO diagnostic Taobao customer hosting technology hall

Since last year, the DDOS attack has risen to a new height. Its landmark attack is a massive DDOS attack against the International Anti-Spam Union and cloudflare. The traffic reached 120G at a time, of course, the DDOS behind it far exceeded 120G, but this An attack is indeed historic.

We are now looking back to see these attacks have been clear that their source of attack is DNS / NTP and other reflective attacks, but why such services as DNS and NTP so powerful? How do attackers create such a huge flow How does DNS, a service that is more common when used on our everyday networks, is exploited to become a massive attack?

We now give the final answer in advance, and then explain:

1, DNS uses a simple UDP packet communication between the client and server;

2, DNS is a natural flow amplifier, through a very small request to return a large response packet;

3, the Internet flooded with a large number of open DNS resolvers, they can accept any client request without refusing;

4, the abuse of the network led to many places can send packets forged source IP address.

The four aspects of the problem finally brought together to form the current pattern of the DNS system, but also make the DNS system has become a source of important issues DDOS attack. A normal DNS request may send out only 64bytes of traffic, but the response it receives may well exceed that number, and on some occasions the traffic can be magnified more than 50 times more easily. Calculating at this rate, generating G / s traffic is very easy if DNS requests are sent over a botnet at the same time, and if DNSSEC is used, traffic will be even greater.

The problem now is that, in essence, these traffic is just normal traffic, just like any other traffic, so a simple filtering mechanism will not work and we need to find deeper solutions to this long-standing problem that plagues the Internet.

In discussing this issue, one of them mentioned that if you implement BCP38 when implementing the network, you can prevent the sending of a DNS request by a fake IP address, thereby preventing the use of DNS for reflection and amplification attacks. Of course, this topic has been a long time earlier than the BCP38 itself, BCP38 as a document has existed for 13 years, but it is unfortunate that this still failed to change the endless stream of source IP forged attacks in the past 13 years, so We should not expect too much in the next few months or even several years.

Another discussion is that the parser should implement a response rate limiting (RRL), silently dropping repeated requests above the threshold, which is indeed quite efficient for the authoritative DNS, but for recursive parser groups That effect is a lot worse, because the attack once walked to the recursive server, then the share can be detected after the frequency may not reach the detection threshold. Nevertheless, the authority of the DNS server implementation of RRL is still a good choice.

Another discussion is that close the open recursive query server, open resolver project (http://openresolverproject.org) This project is ready to do this, so that the open query server maintainer to check the configuration, the problem Finder turned off, and BCP38 received almost the same level, do not expect too much of this approach can have much effect. Part of the reason is because a lot of recursive servers are neglected to manage.

This behavior of a DNS server receiving a packet request to generate a packaged response has become an intrinsic property of the DNS, especially for DNSSEC, and we both want to be secure against DNS resolution and want to be fast, so inevitably Select UDP protocol, combined with ubiquitous recursive DNS query server, which led to the response packet becomes larger, eventually led to the platform has become a large flow attack artifact.

If we want to completely solve the problem of using DNS for large-scale attacks, the space left for us has been very small. However, there is still a continuation of the idea of ​​whether DNS is used by UDP.

In the original RFC1123 to allow UDP and TCP as a DNS service agreement, the relevant section is described as such:

"The limitation of the new DNS record type exceeding 512bytes in the near future is already quite obvious, so TCP-based DNS is needed, so recursive parsers and authoritative servers need to support TCP as a fallback solution for today's UDP-based approach , Will be used in the future TCP mode.

(Why 512bytes? This limitation comes from ipv4 host requirements definition (RFC1122), all systems that support ipv4 must be able to receive at least 576bytes, 20bytes IP header, 8bytes UDP header and 40bytes ip options, which determines A single UDP packet size up to 512bytes)

It is now possible to generate larger packets in IPv4, with a theoretical maximum of 65535 bytes and a UDP packet size of 65507 bytes, but such a large packet will be fragmented during the transmission. In this case, the typical Firewall rules can block the subsequent packets, which may prevent them from reaching the client, because many firewalls are based on UDP and TCP port addresses. Because these fragmented packets do not themselves contain UDP or TCP headers, which puts the firewall in a dilemma, whether it is allowed or not? In this scenario, the firewall may eventually compromise and in turn allow some of the attacks to succeed. Or discard all the fragmentation? Considering these two factors, the traditional DNS approach is to limit the UDP response packet size 512bytes, and when the packet size exceeds 512bytes always enable TCP as a backup measure.

However, the client may not know that the size of the DNS reply packet will exceed 512 bytes, so in order to inform the client to use TCP to receive the entire DNS response, the DNS resolver sends the client a response with the "truncated" bit set.

We have been stuck in this avenue for many years and DNS uses UDP for communication in most cases, and TCP communication is only enabled in rare cases. This approach later when we consider adding a security certificate for DNS resolution mechanism when it is not so cool, as DNSSEC has been very few response packets can be no more than 512bytes converted from UDP to the client through TCP The mechanism of retransmission will inevitably lead to the delay of analysis.

As RFC5966 wrote:

Since the DNS core prototype has been set, the DNS extension mechanism has also been proposed (EDNS0 RFC2671). This mechanism can be used to indicate that the client can receive packets larger than 512bytes in size. An EDNS0 compliant client can send packets to a compatible server Is the size of the client by the buffer size specified packet size without fragmentation.

EDNS0 allows UDP-based response packet has a larger size, then TCP has been widely used as martial arts cheats, only to be used to do the domain transfer, if you do not want to enable the domain transfer, it seems TCP is completely not Play any role.

The requirements for hosts in RFC1123 are described as follows:

The DNS resolver and home server must support UDP, which can support TCP to send queries.

But TCP-based DNS can not only support larger DNS responses, but if we reexamine the prerequisites for a large-scale DNS reflection attack, the ubiquitous UDP bulk response, and the lack of implementation of BCP38, allowing an attacker to fake over the source IP The means to attack the target.

TCP does not have this problem. If an attacker initiates a TCP request by forging the source IP address, the target IP will only receive a very small packet (40 bytes) at most, only the SYN and ACK tags are included. Since the target system has no Has established a state of the connection, the packet will be discarded, depending on the local configuration, the target IP may send a TCP RESET packet to the other end to indicate the state is not established, or simply silently discarded so DNS Attack flow amplification effect is not effectively solved.

If the DNS system has made such a huge problem for the entire Internet, then should we stop using the larger UDP echo packets that EDNS0 supports and then use TCP to send larger requests?

Let's look at RFC5966:

Most DNS service providers already support TCP and the default software configuration also supports TCP, and the main audience for this document is. . .

The question we need to see in this place is how can we quantify the coverage of DNS support for TCP requests and responses? What exactly is the "majority" here?

Through the test found that most of the DNS system is TCP type of message is responsive, that is, the use of TCP to reply to large packages to organize DNS using UDP to send large package this approach is feasible, does not support TCP That part of the DNS system either because of the configuration of the primary and secondary DNS lead to the request of the first server does not pass to the next server request, or some other problem, that is to say, in dealing with TCP problems DNS server is only part There is a real problem.

If you are a DNS system administrator, we recommend:

1, try not to maintain some small open DNS resolution services, these things are the network operators to do;

2, authoritative DNS must limit the frequency of requests, if you use bind, then you can use the RAR function bundled with the frequency limit, if it is PDNS firewall rules to limit;

3, on the DNS system to conduct a comprehensive inspection of the DNS system configuration checks to prevent the emergence of some low-level errors. Only through various efforts can we gradually reduce the impact of DDOS attacks. Source: http: //blog.51web.net/7, please indicate the source, thank you!