Cyber Security - DNS DDOS ATTACK [ Case study Scenario ] & DDOS Attack MITIGATION

• Report rights infringement
• published: 22 Jan 2017
• views: 96

Cyber Security - DNS DDOS ATTACK explained with EXAMPLES & MITIGATION. The DNS protocol is, unfortunately, an effective Denial-of-Service attack vector for a few reasons: DNS generally uses the connectionless User Datagram Protocol (UDP) as its transport. Many autonomous systems allow source-spoofed packets to enter their network. There is no shortage of Open Resolvers on the Internet. These three factors mean that attackers can create large amounts of unwanted response packets by reflecting DNS queries off open resolvers. In such an attack, a DNS query is generated with spoofed source IP addresses belonging to the victim. You can help reduce the effectiveness of these attacks by following the recommendations described below: Network Ingress Filtering Network Ingress Filtering is the idea that a router should only accept a packet on an interface if the packet's source address is reachable via that interface. When implemented on a network, it prevents packets with spoofed sources from entering the network. Thus, if there did happen to be infected/botnet hosts on your network, they would not be able to participate in a source-spoofed DDoS attack. The best current practices for network ingress filtering are documented as BCP38. Network Engineers should be able to follow the BCP38 document. Managers and less technical people should read SAC004. A more detailed document, BCP84, describes network ingress filtering for multihomed networks. Open Resolvers An Open Resolver is a DNS name server that receives and accepts queries from external sources and then either answers the query with cached data, or forwards the query to one or more authoritative name servers to get the answer. An Open Resolver is analogous to SMTP "spam" relays and open HTTP proxies. They all allow external third parties to utilize an organization's resources and hide the source of the originating traffic. Years ago it was common for organizations to combine DNS resolution/recursion (caching) and serving authoritative data in a single name server instance. These days that practice is frowned upon. Recursive name servers should accept queries from the organization's internal address space only. Follow the recommendations in RFC5358 if you are responsible for a recursive name server. Authoritative servers must accept queries from anywhere, but refuse to answer any query that can not be answered authoritatively. BIND users should refer to ISC's Running An Authoritative-Only BIND Nameserver document. You may have Open Resolvers within your network that you don't know about. You can check your network for Open Resolvers at The Measurement Factory. Source Ports Port 53 is the well-known port number for DNS. Many years ago it was common for certain DNS implementations to send queries from source port 53. These days, it is good practice to use non-privileged source ports (i.e., 1024 or greater) and to use a different, random source port for each query. Since the source port for DNS responses is always 53, and since the source port for DNS queries should not be 53, source port filtering may be a viable attack mitigation technique in some situations. Authoritative name server operators (or their upstream providers) may chose to deploy packet filters that drop traffic destined for the name server and having a source port equal to 53. If your recursive name server happens to still be using source port 53, you could be negatively impacted by the use of such filters. Please make sure that your recursive name server follows current practices and does not use source port 53 for queries. If using BIND, look for the query-source option in named.conf. If using Unbound, look for the outgoing-port-permit directive. General Security If you use BIND, take a look at the Team Cymru Secure BIND Template. Zone Data TTLs Domain owners can protect themselves against attacks to their parent zone by using long TTLs on certain "delegation records." These are NS records and their associated A or AAAA records. Generally speaking, as long as these records exist in a recursive name server's cache, there is no reason to query for them in the parent zone. Thus, longer TTLs can help mitigate attacks upon the parent zone. TTLs should be longer than the duration of a typical attack. draft-pappas-dnsop-long-ttl recommends setting NS and associated A/AAAA TTLs to values on the order of days. For zones signed with DNSSEC, DNSKEY and RRSIG records should also have long TTLs. The downside to long TTLs, of course, is the need for better planning and longer schedules when changing NS records or their IP addresses. In particular, if your zone itself is the target of an attack, short TTLs may give you useful flexibility in responding to it.

Cyber Security - DNS DDOS ATTACK [ Case study Scenario ] & DDOS Attack MITIGATION

• Report rights infringement
• published: 22 Jan 2017
• views: 96

Cyber Security - DNS DDOS ATTACK explained with EXAMPLES & MITIGATION. The DNS protocol is, unfortunately, an effective Denial-of-Service attack vector for a few reasons: DNS generally uses the connectionless User Datagram Protocol (UDP) as its transport. Many autonomous systems allow source-spoofed packets to enter their network. There is no shortage of Open Resolvers on the Internet. These three factors mean that attackers can create large amounts of unwanted response packets by reflecting DNS queries off open resolvers. In such an attack, a DNS query is generated with spoofed source IP addresses belonging to the victim. You can help reduce the effectiveness of these attacks by following the recommendations described below: Network Ingress Filtering Network Ingress Filtering is the idea that a router should only accept a packet on an interface if the packet's source address is reachable via that interface. When implemented on a network, it prevents packets with spoofed sources from entering the network. Thus, if there did happen to be infected/botnet hosts on your network, they would not be able to participate in a source-spoofed DDoS attack. The best current practices for network ingress filtering are documented as BCP38. Network Engineers should be able to follow the BCP38 document. Managers and less technical people should read SAC004. A more detailed document, BCP84, describes network ingress filtering for multihomed networks. Open Resolvers An Open Resolver is a DNS name server that receives and accepts queries from external sources and then either answers the query with cached data, or forwards the query to one or more authoritative name servers to get the answer. An Open Resolver is analogous to SMTP "spam" relays and open HTTP proxies. They all allow external third parties to utilize an organization's resources and hide the source of the originating traffic. Years ago it was common for organizations to combine DNS resolution/recursion (caching) and serving authoritative data in a single name server instance. These days that practice is frowned upon. Recursive name servers should accept queries from the organization's internal address space only. Follow the recommendations in RFC5358 if you are responsible for a recursive name server. Authoritative servers must accept queries from anywhere, but refuse to answer any query that can not be answered authoritatively. BIND users should refer to ISC's Running An Authoritative-Only BIND Nameserver document. You may have Open Resolvers within your network that you don't know about. You can check your network for Open Resolvers at The Measurement Factory. Source Ports Port 53 is the well-known port number for DNS. Many years ago it was common for certain DNS implementations to send queries from source port 53. These days, it is good practice to use non-privileged source ports (i.e., 1024 or greater) and to use a different, random source port for each query. Since the source port for DNS responses is always 53, and since the source port for DNS queries should not be 53, source port filtering may be a viable attack mitigation technique in some situations. Authoritative name server operators (or their upstream providers) may chose to deploy packet filters that drop traffic destined for the name server and having a source port equal to 53. If your recursive name server happens to still be using source port 53, you could be negatively impacted by the use of such filters. Please make sure that your recursive name server follows current practices and does not use source port 53 for queries. If using BIND, look for the query-source option in named.conf. If using Unbound, look for the outgoing-port-permit directive. General Security If you use BIND, take a look at the Team Cymru Secure BIND Template. Zone Data TTLs Domain owners can protect themselves against attacks to their parent zone by using long TTLs on certain "delegation records." These are NS records and their associated A or AAAA records. Generally speaking, as long as these records exist in a recursive name server's cache, there is no reason to query for them in the parent zone. Thus, longer TTLs can help mitigate attacks upon the parent zone. TTLs should be longer than the duration of a typical attack. draft-pappas-dnsop-long-ttl recommends setting NS and associated A/AAAA TTLs to values on the order of days. For zones signed with DNSSEC, DNSKEY and RRSIG records should also have long TTLs. The downside to long TTLs, of course, is the need for better planning and longer schedules when changing NS records or their IP addresses. In particular, if your zone itself is the target of an attack, short TTLs may give you useful flexibility in responding to it.