Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
html
Overview
This white paper provides information on general best practices, network protections, and attack identification techniques that operators and
administrators can use for implementations of the Domain Name System (DNS) protocol.
What is DNS?
DNS is a globally distributed, scalable, hierarchical, and dynamic database that provides a mapping between hostnames, IP addresses (both IPv4
and IPv6), text records, mail exchange information (MX records), name server information (NS records), and security key information defined in
Resource Records (RRs). The information defined in RRs is grouped into zones and maintained locally on a DNS server so it can be retrieved
globally through the distributed DNS architecture. DNS can use either the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP)
and historically uses a destination port of 53. When the DNS protocol uses UDP as the transport, it has the ability to deal with UDP retransmission
and sequencing.
DNS is composed of a hierarchical domain name space that contains a tree-like data structure of linked domain names (nodes). Domain name
space uses Resource Records (RRs) that may or may not exist to store information about the domain. The tree-like data structure for the domain
name space starts at the root zone ".", which is the top most level of the DNS hierarchy. Although it is not typically displayed in user applications,
the DNS root is represented as a trailing dot in a fully qualified domain name (FQDN). For example, the right-most dot in "www.cisco.com."
represents the root zone. From the root zone, the DNS hierarchy is then split into sub-domain (branches) zones.
Each domain name is composed of one or more labels. Labels are separated with "." and may contain a maximum of 63 characters. A FQDN may
contain a maximum of 255 characters, including the ".". Labels are constructed from right to left, where the label at the far right is the top level
domain (TLD) for the domain name. The following example shows how to identify the TLD for a domain name:
com is the TLD for www.cisco.com as it is the label furthest to the right.
The DNS protocol specification and implementation was originally defined in RFC 882 and RFC 883. These RFCs were made obsolete by RFC
1034 and RFC 1035 and have been updated by multiple RFCs over the years.
Resolver: A DNS client that sends DNS messages to obtain information about the requested domain name space.
Recursion: The action taken when a DNS server is asked to query on behalf of a DNS resolver.
Authoritative Server: A DNS server that responds to query messages with information stored in RRs for a domain name space stored on the
server.
Recursive Resolver: A DNS server that recursively queries for the information asked in the DNS query.
FQDN: A Fully Qualified Domain Name is the absolute name of a device within the distributed DNS database.
RR: A Resource Record is a format used in DNS messages that is composed of the following fields: NAME, TYPE, CLASS, TTL, RDLENGTH,
and RDATA.
Zone: A database that contains information about the domain name space stored on an authoritative server.
If the DNS server is only configured as an authoritative server and it receives a DNS query message asking about information which the server
is authoritative, it will cause the server to inspect locally stored RR information and return the value of the record in the 'Answer Section' of a
DNS response message. If the requested information for the DNS query message does not exist, the DNS server will respond with a
1 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
NXDOMAIN (Non-Existent Domain) DNS response message or a DNS Referral Response message.
If the DNS server is authoritative, not configured as a recursive resolver, and it receives a DNS query message asking about information which
the server is not authoritative, it will cause the server to issue a DNS response message containing RRs in the 'Authority Section' and the
address mapping for the FQDN from that section may be present in the 'Additional Section'. This informs the DNS resolver where to send
queries in order to obtain authoritative information for the question in the DNS query. This is also known as a DNS Referral Response message.
If the DNS server is not authoritative but is configured as a recursive resolver and it receives a DNS query asking about information, it will
cause the server to recursively query (iterative queries) the DNS architecture for the authoritative DNS server of the information included in the
DNS request. Once the recursive DNS resolver has obtained this information, it will provide that information to the original DNS resolver using a
DNS response message and the RR will be non-authoritative (since the recursive DNS resolver is not authoritative for the requested
information). The recursive DNS resolver may also have knowledge about the requested information stored in DNS cache. If the requested
information is present in the DNS cache, then the recursive DNS resolver will respond with that RR information.
Figure 2 illustrates the iterative process used by a DNS recursive resolver (DNS Recursor, server) to answer the DNS query message (question)
on behalf of the DNS resolver (DNS Resolver, client) and provide a DNS query response message (answer).
1. The DNS resolver sends a query message to the recursive resolver asking for the address of www.cisco.com.
2. The DNS recursor sends a query message to the root name servers looking for the .com domain name space.
3. The root name servers send a DNS referral response message to the DNS recursor informing it to ask the gTLD name servers for the .com
domain name space.
4. The DNS recursor sends a query message to the gTLD name servers looking for the .cisco.com domain name space.
5. The gTLD name servers send a DNS referral response message to the DNS recursor informing it to ask the .cisco.com name servers,
ns1.cisco.com or ns2.cisco.com, about this domain name space.
6. The DNS recursor sends a query to ns1.cisco.com or ns2.cisco.com asking for www.cisco.com.
7. The .cisco.com name servers, ns1.cisco.com or ns2.cisco.com, send an authoritative DNS query response message to the DNS recursor with
the A (address) RR information for www.cisco.com.
8. The DNS recursor sends a DNS query response message to the DNS resolver with the A (address) RR information for www.cisco.com.
DNS Messages
All legitimate DNS messages sent or received are composed of multiple sections. These sections of the DNS message contain fields that
determine how the message will be processed by the device receiving the message. These sections also contain information about the question
(query messages) a device is asking or answers (response messages) a device may be providing. The sections present in a DNS message are
Header, Question, Answer, Authority, and Additional.
Note that there are situations where sections of the DNS message may be empty. An example is a 'DNS Referral Response Message', in which
the Answer section is empty, but the Authority and Additional sections are present and contain RR information.
For more information about the sections of a DNS message, their format, and the fields they contain, consult RFC 1035, Section 4., Messages.
2 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
socket buffers. These types of attacks try to consume all available resources to negatively impact operations of the open resolver. The impact of
these attacks may require the device to be rebooted or a service to be stopped and restarted.
Note: Recursion is enabled by default for Version 9.5 of the BIND software and prior. BIND also allows operators to define views that can use the
following configuration methods for disabling recursion. Views are not discussed in this document.
Note: The example configurations for BIND will use version 9.5.
1. Disable Recursion
// Disable recursion for the DNS service
//
options {
recursion no;
};
options {
// Output Truncated.
allow-recursion { recursive-permit; };
allow-query { recursive-permit; };
// Output Truncated.
blackhole { rfc5735-deny; };
};
Other configuration options for BIND are available for limiting how devices can obtain answers to recursive DNS messages. Operators can use the
'allow-recursion-on' configuration option to select which addresses on the DNS server will accept recursive DNS queries. BIND also allows
operators the ability to select which addresses on the DNS server will provide answers from the DNS cache using the 'allow-query-cache-on'
configuration option. Operators may also configure BIND to only listen on specific interfaces using the 'listen-on' or 'listen-on-v6' options
configuration. For additional configuration options, consult the BIND 9.5 Administrator Reference Manual that can be used to secure BIND.
Note: Team Cymru also provides a Secure BIND Template that operators can use as a guide for hardening their DNS servers.
3 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
Left-click on Start
Left-click on Control Panel
Double-click Administrative Tools
Double-click DNS
2. Within the console tree, right-click the DNS server that recursion will be disabled for and then select Properties.
3. Next, left-click the Advanced tab.
4. Within Server options, select the Disable recursion check box and then left-click on OK.
Left-click on Start
Left-click on Run
The Run dialog box will appear
Type cmd in the text box to the right of "Open:"
2. At the Command Prompt, issue the following command:
DnsCmd: This is the name of the tool used from the CLI to perform administrative tasks for the DNS Server service.
/Config: Specifies that the argument for the DnsCmd command applies to the configuration of the DNS Server service.
/NoRecursion: Specifies that an argument of 1 or 0 will follow to disable or enable recursion for the DNS Server service.
{1|0} This is the name of the tool used from the CLI to perform administrative tasks for the DNS Server service.
Using either of the previous configuration examples for the DNS Server service will disable recursion for all resolvers sending recursive DNS
queries to the server. If recursion is disabled, operators will not be able to use DNS forwarders on that server.
Microsoft provides additional information operators can use to harden the configuration of the DNS Server service. More information is available in
the Securing the DNS Server service or Security Information for DNS documentation.
Microsoft Windows also provides a feature called DNS Server Secure Cache Against Pollution that ignores the RRs in DNS response messages
received from a non-authoritative server. Note that this feature is enabled by default on Windows 2000 Service Pack 3 (SP3) and Windows Server
2003, and that using this feature will also produce more queries sent from the DNS server.
Note: The transaction ID field for the DNS protocol is only 16 bits in length, so this value can range from 0 through 65535.
During the configuration of BIND for Unix and Linux based systems, it is recommended that operators use /dev/random with the --with-
randomdev=PATH argument to the configure script. /dev/random is a special file used for generating random numbers, also known as random
number generator (RNG) or pseudorandom number generator (PRNG). Other operating system implementations of /dev/random are different and
operators should consult the vendor’s operating system documentation for details on its implementation. /dev/random is recommended because it
creates an entropy pool (a group of random bits stored in one place) for generating unpredictable random numbers. Once the bits have been
depleted from the entropy pool, a new pool will be created containing random bits. Using /dev/random will assist BIND in generating random DNS
transaction IDs.
[user@server ~/bind-9.5.0]$
Note: The source port field for the UDP protocol is only 16 bits in length, so this value can range from 0 through 65535.
The following configurations can be applied to BIND so the DNS server will randomize the UDP source port for DNS messages. To use these
configurations, apply them to the options section in the 'named.conf' configuration file.
4 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
// default is 15 minutes.
//
// By increasing the number of ports allocated to the query
// port pool, it will be harder for malicious users to predict
// the next UDP source port used in DNS queries. Operators
// may also decrease the time interval for the recreation of
// query port pool, thus allowing for random ports to be
// selected in shorter intervals and making predictability
// of source port values harder to determine.
//
// Note: Operators should test any non-default changes prior
// to deploying to production environments.
queryport-pool-ports <number>;
queryport-pool-updateinterval <number>;
};
Another multifaceted technique used by attackers is to rapidly change hostname to IP address mappings for both DNS A (address) RRs and DNS
NS (name server) RRs, creating a Double-Flux (DF) network.
Additional information about Fast-Flux is available in Know Your Enemy: Fast-Flux Service Networks.
Another potentially malicious use of a short TTL is using a value of 0. This value informs the DNS resolver that the RR information received in the
DNS query response message should not be stored in the cache of the resolver.
Note: DNS SOA RRs are always distributed to resolvers with a TTL value of 0.
Attackers can also use long TTL values for RRs so that DNS resolvers will cache the information received in the query response message for an
extended period of time. This technique can be used for storing malicious RR information in the cache of a resolver for an extended period of time.
If the resolver is a recursive or open resolver, then it can distribute the RRs for the malicious host to many resolver clients, thus allowing use for
malicious activities. This method differs from the Fast-Flux technique that uses a short TTL value and operators are able to use traceback
techniques to more easily identify malicious hosts distributing this information.
To prevent a DNS server from storing RR information in the cache of the resolver for the value of the TTL received in the DNS query response
message, the following options configurations can be used for BIND.
options {
max-cache-ttl <number>;
};
options {
max-cache-size <number>;
};
Because the functions of these resolvers are used for different purposes, the resolvers should be segregated.
Authoritative DNS servers should be used only for responding to queries for domain name space for which the server is administrative. Queries
from anyone (queries source from the Internet) may be allowed for information we know (authoritative RRs).
Recursive DNS servers should be used only for responding to queries from DNS resolvers inside its administrative domain. Queries from
known sources (clients inside your administrative domain) may be allowed for information we do not know (for example, for domain name
space outside our administrative domain).
Authoratative and recursive resolver functions should be segregated because authoritative DNS servers primarily distribute information about
hosts accessible via the Internet and they are also accessible via the Internet for distributing this information. By combining these resolver
functions on a single DNS server and allowing the server to be accessible via the Internet, malicious users could employ the authoritative DNS
server in amplification attacks or easily poison the DNS cache. A recursive DNS resolver must be protected from the Internet and only trusted
sources should be able to send DNS queries. One approach for controlling what DNS queries are permitted to exit the network under an operator’s
control is to only allow DNS queries sourced from the internal recursive DNS resolvers.
5 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
Several security controls can be implemented to limit spoofing. These controls are described in the following sections.
Unicast RPF operates in two modes: strict and loose. In strict mode, the Unicast RPF feature uses the local routing table to determine if the source
address within a packet is reachable through the interface on which the packet was received. If it is reachable, the packet is permitted; if it was not,
the packet is dropped. Strict mode Unicast RPF is best deployed on network boundaries where traffic asymmetry is not prevalent.
Strict mode Unicast RPF is enabled on Cisco IOS devices using the interface configuration command ip verify unicast source reachable-via rx;
the previous format of this command was ip verify unicast reverse-path. Strict mode Unicast RPF can be enabled on the Cisco PIX, ASA, and
FWSM firewalls using the ip verify reverse-path interface interface configuration command.
In loose mode Unicast RPF, if the source address of a packet is reachable through any interface on the Unicast RPF enabled device, the packet is
permitted. If the source address of the IP packet is not present in the routing table, the packet is dropped. Loose mode Unicast RPF can be
enabled on Cisco IOS devices using the ip verify source reachable-via any interface configuration command; loose mode Unicast RPF is not
available on Cisco PIX, ASA or FWSM firewalls.
More information about Unicast RPF is available in the Applied Intelligence Understanding Unicast Reverse Path Forwarding white paper.
IP Source Guard
IP source guard is a Layer 2 security feature that builds upon Unicast RPF and DHCP snooping to filter spoofed traffic on individual switch ports.
DHCP snooping, which is a prerequisite of IP source guard, inspects DHCP traffic within a VLAN to understand which IP addresses have been
assigned to which network devices on which physical switch port. Once this information has been gathered and stored in the DHCP snooping
bindings table, IP source guard is able to leverage it to filter IP packets received by a network device. If a packet is received with a source address
that does not match the DHCP snooping bindings table, the packet is dropped.
The implementation of IP source guard within the access layer of a network can effectively eliminate the origination of spoofed IP traffic. However,
because it requires DHCP to remain manageable, it is not possible to deploy IP source guard on internal-to-external network boundaries.
The following example illustrates the configuration of IP source guard on interface FastEthernet 0/10 which has been assigned to VLAN 100:
!
! Enable DHCP snooping on VLAN 100
!
ip dhcp snooping
ip dhcp snooping vlan 100
!
! Enable IP source guard on FastEthernet 0/10
!
interface FastEthernet 0/10
switchport
switchport mode access
switchport access vlan 100
ip verify source
!
See Configuring DHCP Features and IP Source Guard for more information on IP source guard.
The example that follows demonstrates how ACLs can be used in order to limit IP spoofing. The ACL is applied inbound on the desired interface.
The ACEs that make up this ACL are not comprehensive. If you configure these types of ACLs, seek an up-to-date reference that is conclusive.
!
ip access-list extended ACL-ANTISPOOF-IN
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
!
interface Ethernet 0/0
ip access-group ACL-ANTISPOOF-IN in
!
Refer to Configuring Commonly Used IP ACLs for more information on how to configure Access Control Lists.
The official list of unallocated Internet addresses is maintained by Team Cymru. Additional information about filtering unused addresses is
available at the Bogon Reference Page.
Detecting and Preventing DNS Attacks using Cisco Products and Features
The ASA, PIX, and FWSM firewall products, Cisco Intrusion Prevention System (IPS) and Cisco IOS NetFlow feature, provide capabilities to aid in
identification and mitigation for DNS related attacks. The following subsections provide an overview of how each device or feature can be utilized.
Enabling DNS guard through either the command line DNS Guard function or DNS application inspection provides preventive controls against
DNS cache poisoning attacks. This feature is enabled by default and is available on Cisco ASA, Cisco PIX and Cisco FWSM Firewalls.
Transaction ID randomization
Some DNS implementations use a weak randomization algorithm to generate DNS transaction IDs for DNS query messages. This makes these
implementations prone to cache poisoning and spoofing attacks. The id-randomization parameters submode command for policy-map type
inspect dns can be used to randomize the DNS transaction ID for a DNS query. This function will harden DNS implementations with weak
randomization algorithms.
This feature is available beginning with software release 7.2(1) for Cisco ASA and Cisco PIX Firewalls. This function is disabled by default on the
6 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
ASA and PIX firewalls. This feature is not supported on the FWSM firewalls.
This feature is available beginning with software release 7.2(1) for Cisco ASA and Cisco PIX 500 Firewalls. This function is not available on FWSM
Firewalls. This function is disabled by default.
This feature is available beginning with software release 7.2(1) for Cisco ASA and Cisco PIX Firewalls. This feature is available beginning with
software release 3.1 for FWSM Firewalls. This function is enabled by default with a limit of 512 bytes.
Note: Although use of this command does reduce the possibility of being a victim of a DNS Amplification Denial of Service attack, it is more likely
to prevent the DNS server from used as part of the source of a DNS Amplification attack.
Feature Overview
DNS Guard
Beginning with software release 7.0(5) for Cisco ASA 5500 Series and Cisco PIX 500 Series, and software release 4.0 for the FWSM the DNS
guard function can be controlled through the dns-guard global configuration or the dns-guard parameters submode command for policy-map type
inspect dns. For Cisco ASA 5500 and Cisco PIX 500 Firewalls that are running releases prior to 7.0(5) and for the FWSM Firewall releases prior to
4.0, the DNS guard function is always enabled, and it cannot be configured through this command. The configuration of this feature, when
configurable, will be detailed later in the feature configuration section.
Caution: Application layer protocol inspection will decrease firewall performance. This feature should be tested in a lab environment before
deployment in production environments.
Feature Configuration
DNS Guard Configuration
To determine whether the DNS guard function is enabled globally, look for the following string in the firewall configuration for software releases
7.0(5) and later for Cisco ASA 5500 Series and Cisco PIX 500 Series appliances:
If the DNS guard function has been disabled globally, it can be re-enabled using the following commands for software releases 7.0(5) and later for
Cisco ASA 5500 Series and Cisco PIX 500 Series appliances:
In software releases 7.2(1) and later for the Cisco ASA 5500 Series and Cisco PIX 500 Series appliances, administrators can enable DNS guard
functionality through DNS application inspection and the Modular Policy Framework (MPF). Configuration of DNS Guard through DNS application
inspection and MPF will be demonstrated in the following DNS application inspection configuration section.
Additional information about DNS application inspection and the Modular Policy Framework is available in How DNS Application Inspection Works.
Additional information about application layer protocol inspection is available in Configuring Application Layer Protocol Inspection.
!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
!
!-- Enable dns-guard to verify that DNS query and
!-- response transaction IDs match and only one DNS
!-- response is allowed through the firewall for
!-- each query.
!
dns-guard
!
!-- Enable id-randomization to generate unpredictable
!-- DNS transaction IDs in DNS messages and protect
!-- DNS servers and resolvers with poor randomization
!-- of DNS transaction IDs.
!
id-randomization
!
!-- Enable a maximum message length to help defeat DNS
!-- amplification attacks. Note: This is the default
!-- configuration and value based on RFC 1035.
!
message-length maximum 512
!
!-- Enable id-mismatch to count DNS transaction ID
!-- mismatches within a specified period of time
!-- and generate a syslog when the defined threshold
!-- has been reached.
!
id-mismatch count 10 duration 2 action log
exit
!
!-- Check for DNS query messages with the recursion
!-- desired (RD) flag set in the DNS header and drop
!-- those packets to avoid being used as a recursive
!-- resolver.
match header-flag RD
drop
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
-- CLI Output Truncated --
!
7 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 37841, drop 0, reset-drop 0
message-length maximum 512, drop 0
dns-guard, count 21691
protocol-enforcement, drop 0
nat-rewrite, count 0
id-randomization, count 21856
id-mismatch count 10 duration 2, log 2
firewall#
Interface outside:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 4923, drop 1544, reset-drop 0
message-length maximum 512, drop 39
dns-guard, count 2147
protocol-enforcement, drop 542
nat-rewrite, count 0
id-randomization, count 2220
id-mismatch count 10 duration 2, log 1
Interface inside:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 240, drop 0, reset-drop 0
message-length maximum 512, drop 0
dns-guard, count 88
protocol-enforcement, drop 0
nat-rewrite, count 0
id-randomization, count 116
id-mismatch count 10 duration 2, log 0
firewall#
Syslog Identification
In the following example, the show logging | grep regex command extracts syslog messages from the logging buffer on the firewall. These
messages provide additional information about denied packets. It is possible to use different regular expressions with the grep keyword to search
for specific data in the logged messages.
Firewall syslog message 410002 will be generated when the firewall detects a high rate of DNS responses with a mismatched DNS transaction ID.
The threshold for this function is set by the id-mismatch parameters submode command for policy-map type inspect dns. Additional information
about this syslog message is available in Cisco Security Appliance System Log Message - 410002.
Firewall syslog message 106007 will be generated when the firewall detects that a DNS response message has already been received for a DNS
query message and the connection entry has been torn down by the DNS guard function. This syslog message indicates that the DNS response
message received has been denied. Additional information about this syslog message is available in Cisco Security Appliance System Log
Message - 106007.
Additional information about regular expression syntax is available in Using the Command Line Interface.
For additional information about investigating incidents using syslog events, reference the Identifying Incidents Using Firewall and IOS Router
Syslog Events Applied Intelligence white paper.
Information about configuring syslog for the Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance is
available in Configuring Logging on the Cisco Security Appliance. Information about configuring syslog on the FWSM for Cisco Catalyst 6500
Series switches and Cisco 7600 Series routers is available in Configuring Monitoring and Logging on the Cisco FWSM.
In the preceding example, the DNS guard function has dropped 182 DNS response message packets due to an incorrect DNS transaction ID or a
DNS response message with the correct transaction ID has already been received.
For additional information about debugging accelerated security path (ASP) dropped packets or connections, reference the Cisco Security
Appliance Command Reference for show asp drop.
Cisco IPS
The Cisco IPS provides several signatures to detect application specific vulnerabilities such as buffer overflow vulnerabilities as well as
informational DNS signatures that may be indicative of reconnaissance or probing. In addition to these application specific signatures,
anomaly-based signatures can provide coverage for vulnerabilities such as amplification attacks or cache poisoning, where the rate of DNS
transactions are likely to vary significantly.
The following table lists the DNS specific signatures provided on the Cisco IPS appliance with signature pack S343.
Table 1. DNS-Specific Signatures Provided on the Cisco IPS Appliance with Signature Pack S343
8 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
9 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
The following IPS Signatures provide rate based or anomaly detection and are useful in identifying attacks that cause a change in the rate or
profile of the DNS traffic (such as amplification or cache poisoning attacks). In many cases, these signatures may require baselining and tuning to
accurately detect attacks. For example, administrators could choose to use an event action filter to monitor for traffic destined to only the DNS
servers, or only port 53. Additionally, once signatures have been enabled, baselined or tuned, the signatures must be set to a high enough severity
to cause incident response personnel to become involved. IPS Signature 4004/0 (Signature Name: DNS Flood Attack) can be specifically used to
detect potential DNS Cache Poisoning, Reflection, or Amplification attacks.
When NetFlow records are displayed on an IOS device or exported to an offline collection system used for traffic analysis or anomaly detection,
the following traffic profiles can be used to classify potential DNS attacks.
DNS Spoofing Attack: A high rate of DNS traffic with a source port of 53 (attacker) destined to an unprivileged port (above 1024) for a DNS
resolver (attack target).
DNS Cache Poisoning Attack: A high rate of DNS traffic with a source port of 53 (attacker) destined to a DNS server on your network (attack
target).
DNS Amplification or Reflection Attack: A high rate of DNS response traffic, from multiple sources, with a source port of 53 (attackers) destined
to your network (attack target). These are likely to use large DNS packets to increase their efficiency; however large packets are not a
requirement.
Note: The source addresses of the DNS servers used in this attack scenario are typically DNS open resolvers.
DNS Amplification or Reflection Attack Source: A high rate of DNS traffic from your DNS server with a source port of 53 (attacker) destined to
other networks (attack targets). These are likely to use large DNS packets to increase their efficiency; however large packets are not a
requirement.
Note: This may indicate that your DNS server is configured as a DNS open resolver. Several configuration examples are available in the Prevent
DNS Open Resolver Configurations above to prevent or restrict your server from responding to recursive DNS queries.
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.015 .001 .206 .066 .073 .000 .000 .000 .000 .000 .000
10 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
In the preceding example, there are multiple flows for DNS packets on UDP port 53 (hex value 0035). In this example, the IP address
192.168.150.70 originally sent a DNS query message (request) to the DNS server at IP address 192.168.5.5 using UDP destination port 53 (hex
value 0x0035) and UDP source port 1027 (hex value 0403). The NetFlow records indicate that IP address 192.168.5.5 responded with one
legitimate DNS response message, however IP address 192.168.3.6 returned multiple DNS response messages at the same time with
incrementing UDP destination ports and a UDP source port value of 53 (hex value 0x0035). It is likely, given this example that the IP address
192.168.3.6 was attempting to return falsified RR information and poison the DNS cache of the server at IP address 192.168.150.70.
Administrators should compare these flows to baseline utilization for DNS traffic on UDP port 53 and also investigate the flows to determine
whether they are potential malicious attempts to abuse flaws in implementations of the DNS protocol.
To view only the traffic flows for DNS packets on UDP port 53 (hex value 0035), the command show ip cache flow | include SrcIf|_11_.*0035 will
display the related NetFlow records as shown here:
Table 3. Tools
DNSCAP - DNS traffic https://www.dns-oarc.net/tools/dnscap A DNS traffic capture utility that provides DNS-specific
capture utility functionality beyond that of tcpdump.
DSC - DNS Stats https://www.dns-oarc.net/tools/dsc A DNS tool that creates statistical information for DNS
Collector traffic.
dnstop http://dns.measurement-factory.com/tools/dnstop/ A tool that builds statistics based on DNS traffic seen
on the network.
nslookup http://www.isc.org and is included with many operating A command line DNS lookup utility included in many
systems operating systems.
dnsdump http://dns.measurement-factory.com/tools/dnsdump/ A tool that will monitor and display DNS messages
seen on the network.
Open Resolver Test from http://dns.measurement-factory.com/cgi-bin A web-based tool that will check DNS servers to
The Measurement /openresolvercheck.pl/ determine if they support recursion from the Internet.
Factory
Table 4. Resources
Location Description
11 de 12 23/07/2015 10:51
DNS Best Practices, Network Protections, and Attack Identification - C... http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
RFC 3833, Threat Analysis of the Domain Name System (DNS) http://tools.ietf.org/html/rfc3833
Measures for making DNS more resilient against forged answers http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or
fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves
the right to change or update this document at any time.
Back to Top
Contacts | Feedback | Help | Site Map | Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks
12 de 12 23/07/2015 10:51