Protect You and Others from DDoS. Make Your Network "Cleaner" Part 1. DNS Amplification

Protect You and Others from DDoS. Make Your Network "Cleaner" Part 1. DNS Amplification
This article was published in the May issue of the "System Administrator" journal (Russian) .

If you want to make a contribution to the wold-wide cyberspace security and DDoS-protection it is not necessary to buy expensive equipment or service. Any Internet-faced server admin may participate in such a noble action with no additional money but time and knowledge investment only.

Let's analyze DDoS-attacks type "amplification" using DNS.

name='more'>
DNS amplification

Attack's sense is a very large DNS-response to the spoofed address. The victim address is spoofed using UDP as a transport layer protocol for DNS. A large amount of open resolvers in the world is used for high quantity of spoofed requests generation.
The malicious traffic sources are:
- third parties;
- hosting clients;
- internet-provider customers.


How does it work.

Assume we have:

192.168.10.128 - the recursive DNS-server.
192.168.10.129 - the client.

Let's try DNS-request for FQDN with a lot of A-records such as google.com:

client:~$ dig @192.168.10.128 google.com
<skipped>
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 271 IN A 173.194.122.227
google.com. 271 IN A 173.194.122.238
google.com. 271 IN A 173.194.122.228
google.com. 271 IN A 173.194.122.229
google.com. 271 IN A 173.194.122.233
google.com. 271 IN A 173.194.122.224
google.com. 271 IN A 173.194.122.230
google.com. 271 IN A 173.194.122.225
google.com. 271 IN A 173.194.122.226
google.com. 271 IN A 173.194.122.232
google.com. 271 IN A 173.194.122.231
<skipped>
;; MSG SIZE rcvd: 204

Launch tcpdump on the DNS-server:

dns-server# tcpdump -n -s 0 host 192.168.10.129 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:11:20.965578 IP 192.168.10.129.47551 > 192.168.10.128.53: 28004+ A? google.com. (28)
22:11:20.989697 IP 192.168.10.128.53 > 192.168.10.129.47551: 28004 11/0/0 A 173.194.32.136, A 173.194.32.129, A 173.194.32.142, A 173.194.32.135, A 173.194.32.132, A 173.194.32.128, A 173.194.32.133, A 173.194.32.130, A 173.194.32.134, A 173.194.32.131, A 173.194.32.137 (204)

One can see that one A-request returns A-response in the much more large packet than initial one (204 payload bytes vs 28 ones). Please have in mind that the packet contains 42 bytes in headers:
  • 14 - Ethernet;
  • 20 - IP
  • 8 - UDP.
So, 70-bytes A-request google.com returns 246-bytes response.

Then you can request all records with the FQDN queried:

client:~$ dig @192.168.10.128 -t ANY google.com

<skipped>

;; QUESTION SECTION:
;google.com. IN ANY

;; ANSWER SECTION:
google.com. 271 IN A 173.194.122.227
google.com. 271 IN A 173.194.122.238
google.com. 271 IN A 173.194.122.228
google.com. 271 IN A 173.194.122.229
google.com. 271 IN A 173.194.122.233
google.com. 271 IN A 173.194.122.224
google.com. 271 IN A 173.194.122.230
google.com. 271 IN A 173.194.122.225
google.com. 271 IN A 173.194.122.226
google.com. 271 IN A 173.194.122.232
google.com. 271 IN A 173.194.122.231
google.com. 571 IN MX 50 alt4.aspmx.l.google.com.
google.com. 571 IN MX 10 aspmx.l.google.com.
google.com. 571 IN MX 20 alt1.aspmx.l.google.com.
google.com. 571 IN MX 30 alt2.aspmx.l.google.com.
google.com. 571 IN MX 40 alt3.aspmx.l.google.com.
google.com. 20439 IN NS ns2.google.com.
google.com. 20439 IN NS ns1.google.com.
google.com. 20439 IN NS ns3.google.com.
google.com. 20439 IN NS ns4.google.com.
google.com. 20439 IN TYPE257 # 19 0005697373756573796D616E7465632E636F6D
google.com. 31 IN SOA ns2.google.com. dns-admin.google.com. 118858953 900 900 1800 60
google.com. 2439 IN TXT "v=spf1 include:_spf.google.com ~all"

<skipped>

;; MSG SIZE rcvd: 509

Tcpdump on the server shows larger response than in the previous case because client receives information for any records type with the google.com FQDN:

dns-server# tcpdump -n -s 0 host 192.168.10.129 and port 53

22:09:45.058655 IP 192.168.10.129.42278 > 192.168.10.128.53: 2825+ ANY? google.com. (28)
22:09:45.094795 IP 192.168.10.128.53 > 192.168.10.129.42278: 2825 23/0/0 A 173.194.32.128, A 173.194.32.136, A 173.194.32.135, A 173.194.32.134, A 173.194.32.130, A 173.194.32.137, A 173.194.32.131, A 173.194.32.133, A 173.194.32.132, A 173.194.32.129, A 173.194.32.142, NS ns4.google.com., NS ns1.google.com., NS ns3.google.com., NS ns2.google.com., MX aspmx.l.google.com. 10, MX alt1.aspmx.l.google.com. 20, MX alt4.aspmx.l.google.com. 50, MX alt2.aspmx.l.google.com. 30, MX alt3.aspmx.l.google.com. 40, Type257, SOA, TXT "v=spf1 include:_spf.google.com ~all" (509)

So, one ANY-type request for google.com returns 509+42=551 bytes in the response packet.
One can see the "Amplification Factor" term in the literature. It is a response and request packets size ratio. Cases mentioned above describes not very large Amp factors (246/70=3.5 and 551/70=7.87, it is not enough for a serious DDoS-attack) but the records quantity increasing may provide a response size for some kilobytes.

An attacker trying DNS Amp usually uses such techniques as:
  • DNS records size manipulation for response size and Amp factor increasing;
  • IP spoofing in a request for a victim bombing by large responses;
  • Spoofed DNS-requests high intensity and frequency.
BCP38 and RFC2827 documents contains recommendations for IP spoofing protection as main DDoS-preventive factor since 2000. Let's analyze them in deed.

DNS service disabling

If Internet-faced server is not authoritative or recursive DNS-server by design it is necessary to disable the DNS requests processing on it. Information security contains some equality:

additional service =additional vulnerability

One can check listening services on Unix-server issung the command:

client:~$netstat -nap | egrep 'udp|tcp'

In the case of DNS-server command output may contain:

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
<skipped>
tcp 0 0 192.168.10.128:53 0.0.0.0:* LISTEN 589/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 589/named
udp 0 0 192.168.10.128:53 0.0.0.0:* 589/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 589/named
<skipped>

If the listening servise is not in use it is necesary to:
  • stop the service;
  • delete the service from the starting scripts;
  • uninstall the service.
In a lot of OS all the 3 deeds may be issued with the service package deinstallation.

DNS-servers protection

If the DNS-resolver role is actual for the server it must have a maximum protection level from external attacks. Let's use such defense methods:

1. Disable unused services. It can be checked with the same command

client:~$netstat -nap | egrep 'udp|tcp'

If you can see some xxx6 pattern in the command output:

udp6 0 0 :::53 :::* 589/named

you can see the IPv6 usage on the server.
If you need IPv4 only by design you must disable it (remember an equity where "additional service = additional vulnerability") uncommenting or adding the string to the /etc/sysctl.conf file:

net.ipv6.conf.all.disable_ipv6 = 1
and then reinitialize it with command:

sudo sysctl -p /etc/sysctl.conf

All the OS hardening is not described because the material volume may become giant and it will take away from the main subject.

2. Management protocols restriction. You must permit management protocols for trusted networks or trusted hosts only. It could be done with external firewall or VPN-concentrator (if applicable) or system iptables/ipfw/etc firewall depending on the network architecture.

3. Default deny. Trust only permitted connections.

4. Patch management. Install the latest stable OS and application releases with security bug fixes.

Recursion limitation

If the DNS-server is authoritative only it is necessary to disable recursive requests processing. It must reply only for its' zone requests without relaying. In Bind server the options section of configuration file must contain strings:
 
allow-transfer {"none";};
allow-recursion {"none";};
recursion no;
If the server is authoritative and recursive DNS it is necessary to process recursive requests going from trusted subnets. One can modify config file with such settings:

 acl "trusted_ip" {
     192.168.0.0/16;
     10.0.0.0/8;
     localhost;
     localnets;
 };
 
 options {
<skipped>
     allow-recursion { trusted_ip; };
     allow-query-cache { trusted_ip; };
<skipped>
 };

In the case when engineer manages customer edge network equipment (e.g. home routers) it is critical to be sure that DNS-relay function is not used or it is inactive on interface available from the Internet. The external interface also must be unavailable for device management form the Internet.

EDNS0

RFC6891 describes Extension Mechanisms for DNS (EDNS0) requirements for server overloading prevention and RFC1035-compatibility. By default DNS-requests uses UDP but in the case UDP-response is more than 512 bytes it must be request reinitiation with TCP as a transport layer protocol (RFC5966). EDNS0 support allows server utilize less resources using UDP even if response is more than 512 bytes long. The disadvantage is ability to participate in DDoS attacks as amplificator.
For example, the request

client:~$ dig @192.168.10.128 -t ANY irs.gov

returns such a response:

;; Truncated, retrying in TCP mode.

<skipped>

;; QUESTION SECTION:
;irs.gov. IN ANY

;; ANSWER SECTION:
irs.gov. 7077 IN RRSIG SOA 7 2 7200 20160416030058 20160409020058 13368 irs.gov. mmRD+b1bZHI+nKC3uc4zHtbfspUwMARdGVkWgsoYd0sRKwvKzxJyWzJ9 2/4zeNTB/nAFGcZAF3Cu5fklQ+WbrpsSk3Nq7emzZPo45DXWLk0/JcaH 2ydEGLXqJC5iF4uBhMxRoIOtzvFzXn4RqtiVRHUImv04ddjE8hdky2U1 0rA=
irs.gov. 7077 IN SOA ns1.irs.gov. it.aciouns.external.dns.admin.irs.gov. 2010085496 3600 1800 2419200 900
irs.gov. 7077 IN RRSIG NSEC3PARAM 7 2 7200 20160416030058 20160409020058 13368 irs.gov. MTDhI91CSla/AsANt3j9Bu5KmPyL0ZCbosh3V8qNIC89C+Ra0PofExcr FhGCSLNA518UgbcLp+a9CXWfkg4Pnc/Phm5aZQK1SqXW8kORlGTcR9l5 c3Liy01hG3ddooCH/fseY3htzvcfe8OIxj2emRougRhdWt3vB4Cl7NpT CR4=
irs.gov. 7077 IN NSEC3PARAM 1 0 100 AABBCCDD

<skipped>

;; MSG SIZE rcvd: 3334

Where the response size is more than 3 Kbytes. So the amplification factor is approx 50 in the case of UDP usage. One can see that the UDP response packet was truncated the client reinitialized request using TCP.
The traffic dump shows TCP usage in the next way:

20:10:11.512845 IP 192.168.10.129.47720 > 192.168.10.128.53: 62574+ ANY? irs.gov. (25)
20:10:11.513048 IP 192.168.10.128.53 > 192.168.10.129.47720: 62574| 4/0/0 RRSIG, SOA, RRSIG, Type51 (450)
20:10:11.513561 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [S], seq 1836767364, win 29200, options [mss 1460,sackOK,TS val 78657 ecr 0,nop,wscale 7], length 0
20:10:11.513580 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [S.], seq 1926843090, ack 1836767365, win 28960, options [mss 1460,sackOK,TS val 89135 ecr 78657,nop,wscale 7], length 0
20:10:11.513710 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 1, win 229, options [nop,nop,TS val 78657 ecr 89135], length 0
20:10:11.513755 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [P.], seq 1:28, ack 1, win 229, options [nop,nop,TS val 78657 ecr 89135], length 2737688+ ANY? irs.gov. (25)
20:10:11.513762 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [.], ack 28, win 227, options [nop,nop,TS val 89135 ecr 78657], length 0
20:10:11.513988 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [P.], seq 1:3337, ack 28, win 227, options [nop,nop,TS val 89135 ecr 78657], length 333637688 31/6/12 RRSIG, SOA, RRSIG, Type51, RRSIG, RRSIG, A 166.123.218.220, RRSIG, TXT "v=spf1 ip4:152.216.0.0/20 ip6:2610:30::/32 include:qai.irs.gov -all", RRSIG, MX emg6.irs.gov. 10, MX emg5.irs.gov. 10, MX emg3.irs.gov. 10, MX emg2.irs.gov. 10, MX emgw.irs.gov. 20, MX emg1.irs.gov. 10, MX emg4.irs.gov. 10, RRSIG, RRSIG, DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, DS, NS ns2.irs.gov., NS ns6.irs.gov., NS ns4.irs.gov., NS ns5.irs.gov., NS ns3.irs.gov., NS ns1.irs.gov. (3334)
20:10:11.514121 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 3337, win 281, options [nop,nop,TS val 78657 ecr 89135], length 0
20:10:11.518986 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [F.], seq 28, ack 3337, win 281, options [nop,nop,TS val 78658 ecr 89135], length 0
20:10:11.519093 IP 192.168.10.128.53 > 192.168.10.129.60506: Flags [F.], seq 3337, ack 29, win 227, options [nop,nop,TS val 89136 ecr 78658], length 0
20:10:11.519312 IP 192.168.10.129.60506 > 192.168.10.128.53: Flags [.], ack 3338, win 281, options [nop,nop,TS val 78658 ecr 89136], length 0

Response Rate Limiting (RRL)

Forced TCP usage is not 100% resolution. E.g. if DNS-requests are recursively relayed by your clients' open resolvers or customer edge equipment with DNS-relay activated. In such case the client is legitimate and TCP usage force server resources utilization in the case of an attack.

1. Authoritative server.
It is necessary to tune response rate limiting by responses quantity per second from one client IP-address on the server. Such limitation lets an ability to save server resources and slow down an attack. Response Rate Limiting (RRL) function must be enabled during DNS-server compilation (--enable-rrl).
Configuration file named must contain such paramteters:
slip - packets quantity where responses are truncated;
responses-per-second - a quantity of responses per second to one client IP.


E.g.:

slip 2
responses-per-second 5

Such functionality is recommended only for authoritative servers. Recursive ones' values are heavy to tune because of individual environment behavior and RRL is dangerous for productive traffic.

2. Recursive server.
DNS-relays may use another RRL solution. Dominating requests are A- or CNAME type. Query type ANY, TXT, RRSIG, DNSSEC intensity is much lower. So their processing rate must be controlled. Assume one client may be allowed to process 3 requests type ANY per 10 seconds. It is Application Firewall solution specific task but it also may be done by well-known iptables.
DNS-request may be identified as some symbols sequence in the packet.

You need to know
  • the sequence symbols expression;
  • where to find it;
  • how to describe it to iptables.

Let's consider request example.


Pic. 1. DNS-request.
One can see on the Pic. 1 that ANY type request is identified by 2-bytes sequence 00ff with numbers 63-64 in the packet. Iptables starts to search with IP-header, so you must search the sequence since byte 49. So the iptables offset is 48.
According to RFC1034 and 1035 query type uses 2 bytes with the maximum length 255 as a decimal value.
DNS query types are:
  • ANY - 255 (0x00FF)
  • RRSIG - 46 (0x002e)
  • DNSKEY - 48 (0x0030)
  • TXT - 16 (0x0010)
The next bytes in the packet contain query class. According to RFC it has 16-bits size too (values between 0x0001 and 0x00FF). So the next byte after the request type is 0x00. Byte before the query type is 0x00 too. So query type ANY hexadecimal sequence for search is 0000FF00.
The most short request is the request for zone root (.) where query type is situated in 55-56 bytes and sequence 0000FF00 is calculated starting the 40th byte for iptables. Query name limit is 63 bytes and zone.
If you execute the request

$ dig -t ANY qwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiopqwertyuiop123.northwesternmutual

then query type bytes will have numbers 138-139 and 4-bytes 0000FF00 sequence search must start from the byte #123. It is not the largest query but it it also possible.
So you must configure iptables on the DNS server for DDoS usage prevention by the way:
  • 3 DNS-requests type ANY processing from one client IP,
  • UDP-packets must have destination port 53,
  • Identify query type ANY as a sequence "0000FF00" in 40-127 bytes.
Resulting iptables commands sequence is:

iptables -N DNS_ANY
iptables -v -A DNS_ANY -m recent --name dns_any --update --seconds 10 --hitcount 3 -j DROP
iptables -v -A DNS_ANY -m recent --name dns_any --set -j ACCEPT
iptables -v -A INPUT -p udp --dport 53 -m string --from 40 --to 123 --algo bm --hex-string '|0000FF00|' -j DNS_ANY

It is also possible to limit another query types (TXT, DNSSEC, RRSIG) response rate. Their legitimate intensity may vary according to services used. If you decided to make a filter you must use another sequences instead of 0000FF00:
RRSIG - 00002E00
DNSKEY - 00003000
TXT - 00001000

In some cases it is possible when another resource DDoS  attack may affect your services. See Pic. 2. The negative effect as DoS is possible for stub resolvers and/or recursive DNS server. DNS-relay must process stub resolvers' requests because they are clients, so it is only possible to limit ANY/RRSIG/DNSKEY/TXT-requests rate using application firewall, scripts ot iptables on DNS-relay.



Pic. 2. When the pain of others may become yours. Recursive DNS and stub resolvers DoS.

uRPF-check
In the case infected client which initiates spoofed traffic is L3-terminated on your equipment it is possible to protect your network from spoofing by means of Unicast Reverse Path Check (uRPF) technology. It checks source IP addresses of incoming traffic packets for their presense in the routing table. Router forwards traffic only if source address is routed via interface.
Pic. 3 shows the situation when routers' interfaces must process traffic sourced from "honest" clients 192.0.2.0/24 (VLAN2 interface on CE or/and Gi0/1 on PE) and 198.51.100.0/24 (VLAN100 interface on CE or/and Gi0/1 on PE) and discard if the source address doesn't match routing table.




Pic. 3. CE connection.

You must apply such Cisco IOS command on interfaces VLAN2(CE), VLAN100(CE) and/or Gi0/1(PE):

CE(config-if)# ip verify unicast source reachable-via rx


Conclusion

The article describes settings which doesn't protect your infrastructure in the case of DDoS directly but they make it impossible to use your resources for DDoS attacks to other networks.
So, one can decrease quantity of DDoS-attacks type amplification and eliminate his infrastructure participation in such malicious activity with some actions which doesn't need additional money:
    • Disable unused services on servers.
    • Secure network design.
    • Patch management.
    • Vulnerabilities management.
    • Recursion restriction. Allow your clients only.
    • Use TCP protocol according to RFC5966 recommendations.
    • Response Rate Limiting (RRL) on DNS-servers using Bind or Iptables.
    • Use uRPF on the network edge.
      If each Internet-faced service admin and network engineer apply all the recommendations the digital world become cleaner.
      Alt text

      Большой брат следит за вами, но мы знаем, как остановить его

      Подпишитесь на наш канал!
      article-title

      Андрей Дугин

      Практическая информационная безопасность и защита информации | Information Security and Cyber Defense in Deed