DNS deception (very interesting article)

xiaoxiao2021-03-06  92

[Briefly]

Those familiar with the network know that when the customer requests services to a server, the server generally analyzes the domain name corresponding to the IP according to the client's IP. This reverse domain name analysis is a process of checking DNS (Domain Name Service).

If the customer's IP corresponds to a domain name, the DNS query returns its domain name. The server side will be recorded and passed to the application after this machine name, so we can see that someone comes from argo.zsu.edu.cn, in fact, she is from 202.116.64.6 - "Yi Xian time" BBS. Careful people will find that the bar of the IP on the BBS is constant, so if the client's domain name is sufficient to hide your own machine name, such as ParallelComput is actually parallelcomputing.xx. Xxx.xxx.xx. This is one of the ways to hide IP. This method is more familiar with the network management or yourself is a DNS network management. ;)

But is you familiar with your network? Anyway is no unfamiliar. ()

Let's change your ideas: What can the server be able to give it our own response information if the server is in the DNS query? The answer is obviously don't need me to say, this is the famous DNS spoof (DNS spoof). To be honest, DNS deceives great power, it is used to hide it in BBS. It is really killing chickens. :)

[Detailed]

The existing DNS service has two comparison "good" properties.

It will accept all the information in this return package when the DNS server receives a legal DNS response message and stores Cache. For example: Users in 10.10.1.2 to Telnet to 100.100.100.100, the DNS used in 100.100.100.100 is 100.100.100.200. After three handshakes, 100.100.100 will send a PTR type DNS query to 100.100.100.200 (by IP check host name):

100.100.100.100 -> 100.100.100.200 [query] nqy: 1 nan: 0 nns: 0 NAD: 0 qy: 2.1.10.10.in-addr.Arpa Ptr

And 100.100.100.200 does not have information about the user IP corresponding to the domain. It first looks out for 10.10.1.2 authorized DNS server - 10.10.1.5 based on the DNS protocol. Then send a query package to it:

100.100.100.200 -> 10.10.1.5 [query] nqy: 1 nan: 0 nns: 0 NAD: 0 qy: 2.1.10.10.in-addr.Arpa Ptr

Here is the difference between Itemive and Recursive. The general DNS is set to iTERATIVE, and Recursive is optional. See RFC1034 for details.

10.10.1.5 Receiving the query information to return 10.10.1.2 Corresponding domain name:

10.10.1.5 -> 100.100.100.200 [Answer] NQY: 1 NAN: 2 NNS: 1 NAD: 1 qy: 2.1.10.10.in-addr.arpa ptr an: 2.4.10.10.in-addr.Arpa Ptr Client.host .com an: client.host.com A 10.10.1.2 ns: 1.10.10.in-addr.Arpa ns ns.host.com ad: ns.host.com A 10.10.1.5

A 10.10.1.2 corresponding to a 10.10.1.2 is given in the returned package, indicating that the corresponding IP corresponding to Client.host.com (Note that these two correspondence are different concepts!). If this return package can be given by us, it is not cool!

So how do you do it? You can control your DNS, then what you want to set it. But too violence, I don't recommend this way :). There is also a moderate way - if there is a DNS server in the LAN, DNS spoof can be implemented by listening, responding. That is, the first SNIFF is transmitted to the DNS query package of the LAN, and then replace the DNS server in this network segment to give the answer information (so much, here is the most important, huh).

However, the DNS server of this network segment will also give answers information at the same time, so that our constructed packages have conflicts with its packages, usually our slow: (such DNS deception is unsuccessful.

In order to get the effect of stable DNS spoof, this involves the nature of the "good" implementation of the second DNS:

When the DNS server is queried, it has a Query ID in the package, and the answer information is only accepted by the Query ID and IP. And this ID is added each time, so you can send a query by the first time to deceive the DNS Server, listen to the ID value, then send a query, then follow the SEND we construct a good response package, in the package Query ID is a predicted query ID value (can specify a range, such as from previous_id 1 to previous_id 100).

On the above example, such as 10.10.1.2 users should deceive 100.100.100.100, he can deceive 100.100. 100.200:

11.11.11.11 -> 100.100.100.200 [query] nqy: 1 nan: 0 nns: 0 NAD: 0 qy: 12345.host.com A

Since Host.com's domain name is controlled by 10.10.1.5, 100.100.100.200 Section 10.10.1.5 query package:

100.100.100.200 -> 10.10.1.5 [query] nqy: 1 nan: 0 nns: 0 NAD: 0 QID: 2345 qy: 12345.host.com A

10.10.1.2 users can monitor the package to get QID: 2345. Then send the second query to 100.100. 100.200:

11.11.11.11 -> 100.100.100.200 [query] nqy: 1 nan: 0 nns: 0 NAD: 0 qy: 67890.host.com A

Turn the answer to the QID of the QID:

10.10.1.5 -> 100.100.100.200 [Answer] nqy: 1 nan: 0 nns: 0 Nad: 0 QID: 2346 qy: 2.1.10.10.in-addr.Arpa Ptr AN: 2.1.10.10.IN-ADDR.ARPA PTR You.want.name

You.want.name is the domain name specified by the user. Pay attention to sending this package to use 10.10. 1.5 this IP address.

Datual! ## $ ## ^

【postscript】

If you are not familiar with DNS, I don't know why, please refer to you first.

转载请注明原文地址:https://www.9cbs.com/read-98040.html

New Post(0)