& nbsp; General introduction
DNS (Domain Name System) is a distributed database system for mapping between domains and IP addresses. DNS offers a special way to maintain and link these mappings in a unified fashion. To a greater extent, computers connected to the internet use DNS to create URL addresses (Universal Resource Locators). By this method, each computer will not need to use the IP address for the connection.
DNS names are created in the following format <tên miền=""> <kiểu miền="" tên=""> For example, infosec.vasc.com.vn. While the list of DNS name types was designed by ICANN, some common types include: .edu (educational web sites), .mil (websites for .org (of non-commercial organizations), etc. There are also country-specific types of domain names, for example .ie (Ireland), .jp (Japan), .de (Germany)
When a computer (a DNS client) wants to look up a URL, it passes the request (GetHostByName) to its DNS server. The DNS client uses a DNS resolver to locate the DNS server. If the DNS server does not identify the domain to be found, or if the DNS server has no information about that URL in its cache, it will not be able to respond to the client request immediately. Instead, the DNS server will either use a DNS forwarder or recreate a request under recursive rules.
DNS spoofing involves forcing a DNS client to make requests to an impersonation server, and then the client receives the wrong response from the fake server. There are three ways to perform this kind of DNS spoofing attack, including:
1. Fake DNS responses
An attacker could use a recursive mechanism to forge requests that the DNS server sends out during a lookup address, and responds to false information before the actual information arrives. Each DNS packet has a 16-bit ID that the DNS server uses to check what the initial request was sent. When using BIND, a popular DNS server software, this number increases to 1 after each incoming request, and making the request easy to fake. BIND has been bugged in recent versions, with DNS packets being initialized according to random numbers (BIND v9).
To check whether a DNS server can be vulnerable to DNS name spoofing attacks, you can send requests to the server, verifying whether to guess the next number in a packet keep up the DNS. If the ID requirements are predictable, this means that the cache memory in the DNS can be mapped to the real IP address, and that is the DNS vulnerability.
2. Fake addresses in the DNS cache
After recursive requests, the address mappings received will exist in the DNS cache. The DNS server will rely on the same cache to identify information for incoming requests and responses from the client, which will help to access information more quickly. The length of time that the recursive request is kept in the DNS cache (TTL - time to live) can be set.
The presence of spoofed addresses in the DNS cache results in the sending of incorrect mapping information to long TTLs. So, at the next time when a request arrives, it will receive the wrong information. Failure to do so may also be affected by the receipt of data from a remote DNS server that has been tampered with. It is possible to limit the forgery of this information by reducing the amount of time information exists in the cache (TTL), but this also reduces the performance of the server.
One popular application of open source software is BIND (Berkeley Internet Name Daemon), which provides most important DNS server functions. However, there are a lot of vulnerabilities in BIND, and so it is important to make sure that you are using the latest version of BIND. Currently, new standards on DNS have overcome this problem in the cache of DNS.
Break the security level of the environment
DNS spoofing attacks break the security level of the network environment in the DNS server. For example, a buffer overflow vulnerability has been exploited against older versions of BIND, which allow an attacker to gain root access. When the attacker gains access to the DNS environment, he can control the network environment.
For help with management and troubleshooting, it is useful to know that DNS communications use both TCP (Transmission Control Protocol) and User Datagram Protocol (UDP) protocols, and typically use a firewall. Configures packet filtering prior to going through DNS.
One way to prevent unacknowledged dangers is to use a domain-managed DNS system. This involves installing an internal DNS server. At the same time, each external DNS is set up to contain only relevant information by external hosts, such as the SMTP gateway, or an external NS. Most existing mail servers can handle very good SMTP mail (such as MS Outlook and IBM Lotus Lote both have SMTP gateways), which is also safer because of the separate mechanism for receiving SMTP mail. Then, if the external mail is successfully converted, the attacker will not be able to automatically access the internal mail system.
Future development of DNS
DNS may be vulnerable to packet spoofing because of the lack of authentication to access. This can be overcome with DNSSEC. This is a new security mechanism by allowing websites to check their domain names and be responsible for IP addresses by electronic signatures and public encryption algorithms. This also means that, when the DNS client receives a response from its request, it can check that request from an authenticated resource. DNSSEC has begun to be embedded in BIND 9, and in some operating systems.
DNSSEC will require more bandwidth and hardware performance and will require changes to all existing DNS servers. Therefore, the adoption of this new technology is still underway and promising in the future.
Today, through this article Billion refers to the problem of roaming. You will probably be interested. The article will give you a better understanding of it, as well as have certain knowledge about the problem.
Roaming (This part was collected by the author of Binh Trieu - vietnam security)
One of the most serious misconfigurations that system administrators can make is to allow unreliable Internet users to perform DNS roaming.
Zone Transfer allows the secondary server to update the database from the primary server. As a result, DNS server redundancy is lost, as the primary server is not available. In general, the DNS server Second, DNS servers are misconfigured and provide duplicate domains to the requester. It is not necessarily bad if the information provided relates to the Internet. and has a valid hostname, although it makes it easy for the attacker to find the target. The real problem arises when the organization does not enforce a gateway DNS mechanism to isolate external DNS information. with DNS information in. Providing IP address information in for unreliable users via the Internet is like providing an in-place map of the organization.
We have several roaming tools, but I limit discussion to some common types.
The simplest way to get roaming is to use the "nslookup" client usually implemented by UNIX and NT. We apply "nslookup" in interactive mode:
[bash] $ nslookup
Default Server: ns1.example.net
Address: 10.10.20.2
& gt; 216.182.1.1
Default Server: 1
Address: 10.10.20.2
Name: gate.tellurian.net
Address: 10.10.20.2
& gt; set type = any
& gt; ls -d tellurian.net. & gt; & gt; / tmp / zone_out
First, we run "nslookup" in interactive mode. Once the boot is complete, it will indicate the default name server, usually the organization's DNS server or the DNS server. However, the DNS server (10.10.20.2) is not authoritative for the destination area, so there will not be any DNS records. Therefore, we need to manually "nslookup" know that will query the machine. For this example, we use the main DNS server for the Tellurian network (10.10.20.2).
Next, we will specify the type of the message as "any". This allows you to drag any nslookup man record (s) to the complete list.
Finally, list the entire domain related information using the "ls" option. "- d" lists all domain records. We add "." At the end of the sentence to indicate the region name that qualifies. Most of the time it is so. Redirect the result and the file "/ tmp / zone_out" for later operation.
The roaming is done, we see in the file there is interesting information that can target the specific system. See the result:
[bash] more zone_out
ACT18 1D IN A 192.168.230.3
1D IN HINFO
1D IN MX 0 tellurianadmin-smtp
1D IN RP- bsmith.rci bsmith.who
1D IN TXT "Location: Telephone Room"
1D IN CNAME aesop
in 1D IN A 192.168.230.4
1D IN HINFO "aspect" "MS-DOS"
1D IN MX 0 andromeda
1D IN RP jcoy.erebus jcoy.who
1D IN TXT "Location: Library"
acct21 1D IN A 192.168.230.5
1D IN HINFO "Gateway2000" "WinWKGRPS"
1D IN MX 0 tellurianadmin-smtp
1D IN RP bsmith.rci bsmith.who
1D IN TXT "Location: Acounting"
For each entry, we have the A record indicating the IP address of the system name to the right. In addition, each server There is a HINFO message identifying the background or type of operating system running (RFC-952). The HINFO message is not necessary, but it provides a lot of information to the attacker. Since we saved the roaming result Output files should be easy to manipulate results using UNIX programs such as grep, sed, awk, or perl.
Assuming we are experts in SunOS or Solaris, we can find out the IP address of the SPARC, Sun, or Solaris HINFO message.
[bash] $ grep -i solaris zone_out | wc -1
We have 388 references "Solaris". As we have said, we have too many goals.
Suppose we want to find the test system, accidentally selected for the attacker.Why? It's simple - they usually do not trigger many security features, codes to guess, administrators do not pay attention or bother anyone who logs them in. An ideal place for intruders. Find the test system as follows:
[bash] $ grep -i test / tmp / zone_out | wc -1
There should be about 96 entries in the zone file that contain the word "test". Equal to the number of real test systems. Here are just a few simple examples. Most intruders will dissect this data to Focus on specific types of systems with known weaknesses.
There are a few points to keep in mind. The neu method on the server only accesses the name. That is, you have to do the same thing for all nameservers that have authority over the destination area. Tellurian.net region only. If there are sub-regions, will have to implement the same type of query for each sub-region (such as greenhouse.tellurian.net) .After you receive the message can not list the zone or reject This often indicates that the server has been configured to disable roaming of illegal users. So you hardly roaming from this server. But if there are multiple servers DNS, you will have the opportunity to find the machine that allows roaming.
There are many tools that accelerate this process, including: host, Sam Spade, axfr and dig (not mentioned here).
The "host" command has many flavors of UNIX. The "host" command is as follows:
host -1 tellurian.net
or
host -1 -v -t any tellurian.net
If you need each IP address to include in the shell script, you cut (cut) the IP address from the "host" command.
host -1 tellurian.net | cut -f 4 -d "" & gt; & gt; / tmp / ip_out
Not every print job is required to perform a UNIX command. Some Windows products provide such information.
Finally, you will be roaming with one of Gaius's transcendental tools. This utility will transfer the regional information, regional databases, and server files for each region that is queried. You should be able to switch to high levels like com and edu to get all regions related to "com" and "edu". However, do not do so. To run axfr, type the following "
[bash] $ axfr tellurian.net
ch_fr: Using default directory: / root / axfrdb
Found 2 name servers for domain "Tellurian.net";
Text deleted.
Received xxx answer (xxx records)
To retrieve the information you just retrieved in the "axfr" database, type the following:
[bash] $ axfr tellurian.net
& nbsp;
