Hack Router Port 53 Protocol
Hi all, I have a Netgear DGN2200v3. A few months ago, we noticed that there was significant upload useage on our connection when it was not possible for it to be us using it. We ran tests such as disconnecting everything from the router and sure enough, large uploads made with NOTHING connected to the router! We talked to our ISP who suggested it was most likely someone accessing our router to upload info. I think it would be very, very unlikely that they could be doing so wirelessly (large grounds, no way to get within wifi range) so the ISP suggested we make sure that remote management of the router was turned off (done successfully) and that we block port 53 to incoming traffic. Can't find how to do this, can anybody help?!
Also, are there any other precautions we could take? The router does have a security system hard wired to it (currently disconnected) and a Sonos (again, disconnected) that we had to do some playing around with to get working so wary of going mad to start with in case I stop those working! Many thanks for any help or thoughts you can offer. What I would have done as step one is a reset of the router to factory default and a reconfiguration - making sure that upnp was disabled and the wireless encryption key changed. With nothing physically connected to the router, the only way to get substantial bandwidth usage in either direction is via wireless - which is the reason for the change in encryption key - that would immediately break any and all wireless connections, even those you have may have forgotten about. I suggest disabling upnp (universal plug'n'play) because this allows the router to be configured for port forwarding without your being aware of it - whether or not this is enabled makes no difference if there is nothing connected to the router.
Blocking port 53 incoming does nothing for you - first all incoming ports are blocked by default so that port is already blocked unless you take specific steps to open it, and second port 53 is DNS, if you're not running an internal DNS server, there will be no traffic on that port whatsoever, and even if you were running an internal DNS server, the traffic would be minimal, insignificant to the point where it's not worth discussing. Unless you advertise the availability of a DNS server, for example, through an associated DHCP server, no one knows it's available, no one connects to it. Hi Fordem, thanks for the reply! I didn't know port 53 was automatically blocked so that's interesting, thanks.
SG Ports Services and Protocols - Port 53 tcp/udp information, official and unofficial assignments, known security risks, trojans and applications use. Hack Router Port 53 Udp. (even for intrinsically stateless protocols such as UDP). UDP Hacking port 53 UDP Hacking port 53.
Re the wireless, are there devices that allow people to connect over considerable distances? The closest someone could get to the router without being within the boundaries is about 40 meters away.
If I export the settings and reset to default to change the key, then re-install all the setting to get the security and sonos working again I assume the key would remain changed so that at least could be ruled out? Upnp is active for the security camera system, it won't work without it for some reason, I'm going from memory here a little so will have to double check but I'm fairly sure we also had to set up a DHCP server with the security camera company and also required setting up an internal DNS server. Please don't be afraid to talk to me in idiot terms on this, I'm relatively adept at PC's maintenance but networking isn't something I exactly excel at lol. Davince wrote: If I export the settings and reset to default to change the key, then re-install all the setting If you're importing the previously exported settings, you will end up with the same encryption key. Also 40 metres is neither here nor there - I've done greater distances than that without any fancy antennas. Regarding upnp and the security cameras - you can have the camera company tell you what ports are required and manually forward those- upnp is just a matter of convenience in that it allows the camera system to do it for you, but just as the camera system can do it, other devices can do similar tricks with your router and crate openings that compromise your security.
Regarding DHCP & DNS and the security cameras - that was most likely a DHCP reservation and a dynamic DNS registration, not an internal DNS server.
Contents 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. 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. Domain Name Space The following diagram illustrates a sample of the Domain Name System hierarchy starting from the root '.' Everything below the '.org' domain name space is in the org domain and everything below '.cisco.com' domain name space is in the cisco.com domain.
Domain Name Space. The DNS protocol specification and implementation was originally defined in and. These RFCs were made obsolete by and and have been updated by multiple RFCs over the years. Important DNS Terminology To understand DNS and the DNS-specific recommendations in this document, it is important that operators and administrators are familiar with the following terms:. 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. Primary Function of DNS DNS primarily translates hostnames to IP addresses or IP addresses to hostnames.
This translation process is accomplished by a DNS resolver (this could be a client application such as a web browser or an e-mail client, or a DNS application such as BIND) sending a DNS query to a DNS server requesting the information defined in a RR. Some examples of the DNS resolution process follow:. 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 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). Recursive Query.
The DNS resolver sends a query message to the recursive resolver asking for the address of. The DNS recursor sends a query message to the root name servers looking for the.com domain name space. 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. The DNS recursor sends a query message to the gTLD name servers looking for the.cisco.com domain name space.
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. The DNS recursor sends a query to ns1.cisco.com or ns2.cisco.com asking for. 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. The DNS recursor sends a DNS query response message to the DNS resolver with the A (address) RR information for. 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, Section 4., Messages. Maliciously Abusing Implementation Flaws in DNS Flaws in the implementation of the DNS protocol allow it to be exploited and used for malicious activities. Because DNS is such a critical protocol for Internet operations, countless operating systems, and applications, operators and administrators must harden DNS servers to prevent them from being used maliciously. Some of these flaws are presented in this document to inform operators how they can be used maliciously.
Techniques are shared that can be used to prevent these types of activities. DNS Open Resolvers A DNS open resolver is a DNS server that allows DNS clients that are not part of its administrative domain to use that server for performing recursive name resolution. Essentially, a DNS open resolver provides responses (answers) to queries (questions) from anyone asking a question.
DNS open resolvers are vulnerable to multiple malicious activities, including the following:. DNS cache poisoning attacks. DNS cache poisoning attacks‡. Resource utilization attacks ‡Denial of Service (DoS) or Distributed DoS (DDoS) DNS Cache Poisoning Attacks DNS cache poisoning occurs when an attacker sends falsified and usually spoofed RR information to a DNS resolver.
Once the DNS resolver receives the falsified RR information, it is stored in the DNS cache for the lifetime (Time To Live TTL) set in the RR. To exploit this flaw in the DNS resolver implementation so it will store the falsified information, an attacker must be able to correctly predict the DNS transaction identifier (TXID) and the UDP source port for the DNS query (request) message. Attackers use this exploitation technique to redirect users from legitimate sites to malicious sites or to inform the DNS resolver to use a malicious name server (NS) that is providing RR information used for malicious activities. DNS Amplification and Reflection Attacks DNS amplification and reflection attacks use DNS open resolvers to increase the volume of attacks and to hide the true source of an attack, actions that typically result in a DoS or DDoS attack. These attacks are possible because the open resolver will respond to queries from anyone asking a question. Attackers use these DNS open resolvers for malicious activities by sending DNS messages to the open resolvers using a forged source IP address that is the target for the attack. When the open resolvers receive the spoofed DNS query messages, they respond by sending DNS response messages to the target address.
Attacks of these types use multiple DNS open resolvers so the effects on the target devices are magnified. Resource Utilization Attacks Resource utilization attacks on DNS open resolvers consume resources on the device. Examples of such resources include CPU, memory, and 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. Prevent DNS Open Resolver Configurations Multiple vendors have products that implement the DNS protocol and that can be configured as a DNS open resolver intentionally or unintentionally.
A configured open resolver exposed to the Internet allows anyone to send DNS queries to the resolver. The examples that follow are configurations for some vendor products that are broadly deployed throughout the Internet. These example configurations show how to prevent a DNS server from acting as an open resolver.
Berkeley Internet Name Domain Berkeley Internet Name Domain (BIND), a software product of Internet Systems Consortium, Inc., implements the DNS protocol that is discussed in this document. The following configurations can be applied to BIND so that the DNS server is prevented from acting as an open resolver. These configurations are applied in the 'named.conf' configuration file. 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. 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 that can be used to secure BIND. Note: also provides a that operators can use as a guide for hardening their DNS servers. DNS Server Service The DNS Server service is a software product provided by Microsoft Corporation that implements the DNS protocol.
The following configurations can be applied to the DNS Server service to prevent the server from acting as an open resolver. These configurations are applied to the DNS Server service either through the Windows user interface (UI) or from the command-line (CLI). DNS Server service: Disable Recursion using Windows User Interface The following steps provide information on how to disable recursion for the DNS Server service using the Windows User Interface (UI). Open DNS using the following procedure:. Left-click on Start. Left-click on Control Panel. Double-click Administrative Tools.
Double-click DNS. Within the console tree, right-click the DNS server that recursion will be disabled for and then select Properties. Next, left-click the Advanced tab. Within Server options, select the Disable recursion check box and then left-click on OK.
Router Port Forwarding
DNS Server service: Disable Recursion using Windows Command-Line The following example provides information on how to disable recursion for the DNS Server service using the Windows Command-Line) CLI. Open a Command Prompt using the following procedure:. 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:'.
At the Command Prompt, issue the following command. UDP Source Port Randomization in BIND DNS uses both the source port value and transaction ID for tracking queries and the responses to queries. Flaws have been discovered in DNS where the implementations do not provide sufficient entropy in the randomization of the UDP source port when issuing queries. Malicious users can analyze the source port values generated by the DNS implementation to create an algorithm that can be used to predict the next UDP source port value used for a query message. If the next UDP source port value used in the DNS query along with the transaction ID can be predicted, an attacker can construct and send spoofed DNS messages with the correct UDP source port. Even though the DNS message sent by the attacker is falsified, the DNS resolver accepts the query response because the UDP source port value and the DNS transaction ID match up with the query the resolver sent, resulting in the DNS resolvers cached being poisoned.
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. Maliciously Abusing Resource Record Time To Live When a DNS resolver sends a query asking for information, an authoritative or a non-authoritative server may respond with a DNS query response message and the relevant resource record (RR) data or an error. The RR contains a 32-bit Time To Live (TTL) field used to inform the resolver how long the RR may be cached until the resolver needs to send a DNS query asking for the information again.
This field can be used maliciously by setting the value for an RR to a short or long TTL value. By using a short TTL value, malicious users can leverage DNS to distribute information about a large number of devices hosting malicious code or being used for malicious activities to DNS resolvers. The hostname to IP address mapping for devices in the requested domain name space will rapidly change (usually anywhere from several seconds to a few minutes). This is known as a Fast-Flux (FF) network. Abusing the TTL value using this technique for an RR in a DNS query response messages is known as Single-Flux. This malicious technique makes it difficult for operators to use traceback methods and identify compromised hosts participating in the Fast-Flux network.
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.
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. Segregating Authoritative and Recursive Resolvers Authoritative and recursive resolvers have different primary functions. An authoritative DNS server distributes information to DNS resolvers for authorative domain name space. A recursive resolver recursively walks through the DNS architecture and locates the authoritative DNS server for the information in the DNS query (question asked), then distributes an answer or error for that information using a DNS query response message to the resolver who asked the question. 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. Domain Name System Security Extensions adds security functions to the DNS protocol that can be used to prevent some of the attacks discussed in this document such as DNS cache poisoning. DNSSEC adds data origin authentication and data integrity to the DNS protocol. DNSSEC specifications, implementation, and operational information is defined in multiple RFCs.: DNS Security Introduction and Requirements.: Resource Records for the DNS Security Extensions.: Protocol Modifications for the DNS Security Extensions.: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence.: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP).: DNSSEC Operational Practices Protections for Spoofing The DNS protocol leverages the User Datagram Protocol (UDP) for the majority of its operations. UDP is a connectionless protocol and, as such, it can be easily spoofed.
Many of the attacks described in this document rely on spoofing to be successful. Several security controls can be implemented to limit spoofing. These controls are described in the following sections. Unicast Reverse Path Forwarding Unicast Reverse Path Forwarding (Unicast RPF) is a feature that can reduce the effectiveness of packets with spoofed source addresses. A network device using Unicast RPF evaluates the source of each IP packet against its local routing table in order to determine source address validity. While it can detect and filter some spoofed traffic, Unicast RPF does not provide complete protection against spoofing because spoofed and valid packets with the same source address may arrive on the same interface.
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 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. See for more information on IP source guard. Access Control Lists Manually configured Access Control Lists (ACLs) can provide static anti-spoofing protection against attacks that utilize unused or untrusted address space.
Commonly, these anti-spoofing ACLs are applied to interfaces in the ingress direction for traffic received at network boundaries as a component of a more comprehensive ACL. Spoofing can be minimized in traffic originating from the local network by applying ACLs that use Access Control Entries (ACEs) which limit the traffic to only valid local addresses. 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. Refer to for more information on how to configure Access Control Lists.
The official list of unallocated Internet addresses is maintained. Additional information about filtering unused addresses is available at the. 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.
Cisco ASA and FWSM firewalls The Cisco ASA, PIX and FWSM Firewalls have several features that can be utilized to minimize attacks against the DNS protocol. The following subsections will provide an overview of these features and the capabilities they can provide.
Attack Mitigation Capabilities: Query and Response Verification DNS cache poisoning attacks commonly use multiple responses to each query as the attacker attempts to predict or brute force the transaction ID and the UDP source port to corrupt the DNS cache. The DNS guard function inspects and tears down an existing DNS connection associated with a DNS query as soon as the first DNS response message is received and forwarded by the firewall. The firewall also monitors the message exchange to ensure that the transaction ID of the DNS reply matches the transaction ID of the initial DNS query. For the firewall to successfully mitigate cache poisoning attacks, both the initial DNS query and the subsequent non-malicious DNS response will need to transit the firewall. In the unlikely occurrence that the malicious DNS response arrives first and with the correct transaction ID, then the firewall is unable to prevent DNS cache poisoning type attacks. 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 ASA and PIX firewalls. This feature is not supported on the FWSM firewalls.
DNS Header Flag Filtering DNS cache poisoning attacks use DNS open resolvers when attempting to corrupt the DNS cache of vulnerable resolvers. The DNS messages sent to open resolvers set the recursion desired (RD) flag in the DNS header. Utilizing the DNS application inspection flag filtering feature, these attacks can be minimized by dropping DNS messages with the RD flag present in the DNS header. 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.
DNS message size limitations DNS amplification and reflection attacks are more effective when leveraging large DNS messages than small DNS message sizes. The message-length parameters submode command for policy-map type inspect dns can be used to ensure that message sizes to not exceed a specified size thus reducing the efficiency of these attacks. 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. DNS Application Inspection Application layer protocol inspection is available beginning in software release 7.0 for the Cisco ASA 5500 and Cisco PIX 500 Series Firewalls and in software release 3.1 for the FWSM Firewall. Configuration of DNS application inspection capabilities will be detailed later in the feature configuration section of this document. 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. 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. DNS Application Inspection Configuration DNS application inspection utilizes the Modular Policy Framework (MPF) for configuration. To configure application inspection, administrators may construct an inspection policy through the configuration of inspect class maps and inspect policy maps, which are applied via a global or an interface service policy.
The following example demonstrates configuration of this feature. Additional information about DNS application inspection and the Modular Policy Framework is available in. Additional information about application layer protocol inspection is available in. Class-map inspectiondefault match default-inspection-traffic! Policy-map type inspect dns presetdnsmap 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 globalpolicy class inspectiondefault inspect dns presetdnsmap - CLI Output Truncated -! Service-policy globalpolicy global!
Cisco Router Port 53
!- Output for service-policy applied globally! Firewall# show service-policy inspect dns Global policy: Service-policy: globalpolicy Class-map: inspectiondefault Inspect: dns presetdnsmap, 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#!- Output for service-policy applied per interface!
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.
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. Additional information about regular expression syntax is available in. For additional information about investigating incidents using syslog events, reference the 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.
Information about configuring syslog on the FWSM for Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers is available in. Accelerated Security Path Identification The show asp drop frame command can identify the number of DNS packets that the DNS guard function (with the counter name inspect-dns-id-not-matched) has dropped because the transaction ID in the DNS response message does not match any transaction IDs for DNS queries that have passed across the firewall earlier on the same connection. As shown in the following example, the counter inspect-dns-id-not-matched is represented in the command output as DNS Inspect id not matched. 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 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. DNS-Specific Signatures Provided on the Cisco IPS Appliance with Signature Pack S343. 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.
Rate-based or Anomoly Detection Signatures. Cisco IOS NetFlow Administrators can configure Cisco IOS NetFlow on Cisco IOS routers and switches to aid in the identification of traffic flows that may be attempts to exploit these DNS implementation flaws. In general, the following traffic profiles will be associated with these types of attacks; however it is important to note, that depending on NetFlow monitoring location, Network or Port address translation (NAT or PAT) and other variables that these are not absolutes. Administrators should consider these as guidelines and evaluate these events in the context of their network to determine if these events represent malicious activities. The following guidelines assume no Port Address Translation (PAT). 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.
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. Tool Name Location Description DNSCAP - DNS traffic capture utility A DNS traffic capture utility that provides DNS-specific functionality beyond that of tcpdump.
DSC - DNS Stats Collector A DNS tool that creates statistical information for DNS traffic. Fpdns - DNS fingerprinting tool A tool used to fingerprint DNS resolvers. Dnstop A tool that builds statistics based on DNS traffic seen on the network. Dnsstat A DNS-specific tool that builds statistics based on DNS traffic seen on the network. Dig A powerful command line utility for debugging and troubleshooting DNS. Host A DNS lookup command line utility. Nslookup and is included with many operating systems A command line DNS lookup utility included in many operating systems.
Dnsdump A tool that will monitor and display DNS messages seen on the network. Dnsmap A tool that collections all available information for a sub-domain.
TXDNS A multithreaded Win32 tool used primarily send many DNS queries at a time for testing DNS servers. Open Resolver Test from The Measurement Factory A web-based tool that will check DNS servers to determine if they support recursion from the Internet. Dnsenum A tool that attempts to collect all possible information available for a domain.