反向解析公共IP- 這里沒有問題

Tl; dr：有些域名名稱服務器可能會在直接查詢反向解析私有IP時暴露內部的IP地址和域名。用dig -x檢查一下，或者使用privdns.py 檢查一下。

 一個簡單的錯誤

我最近犯了一個很小且看似不重要的錯誤：我試圖連接某個公司的基礎設施的服務器，但沒有登錄到他們的VPN。這看起來很無聊，你可能會覺得，這樣的事情每天都在發生。但幾個小時后，我正在編寫Python代碼，并且在大量掃描互聯網上的DNS服務器。即使我最終沒有取得成功（從安全的角度來看這是很好的結果），但這仍然是一個有趣的實驗。那么到底發生了什么事。

當我試圖ping內部公司的服務器時，我得到了下面的回應：

michael@seventysix:~ ping internal-db1.example.com 
PING internal-db1.example.com (10.0.0.1) 56(84) bytes of data. 
^C 
--- internal-db1.example.com ping statistics --- 
3 packets transmitted, 0 received, 100% packet loss, time 2014ms 

當然，結果顯示超時了。但注意一些事情：域名已經被正確解析。即使我沒有登錄到VPN，我仍然可以解決內部域名。為了確保這不是由于某個DNS緩存造成的，我嘗試從云集群中未曾登錄到公司網絡并使用不同名稱服務器的虛擬機中重現此操作，并得到了相同的結果。

為了理解這背后的事情為什么這么有趣，這里有一些關于IP地址和DNS的背景知識。

 內部，外部IP和DNS

IPv4和IPv6地址空間分為私有和公有IP。以下網絡是私有的：

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• FC00 :: / 7

例如，在你的家庭網絡或公司內部網絡中使用專用IP。如果你在內部網絡中處理公司服務器，他們通常具有上述范圍內的IP。

為了連接名稱服務器和IP地址，我們使用DNS（域名服務）。DNS服務器（或“域名服務器”）是將域名example.com翻譯成IP的服務器。老知識，到目前為止，你很可能知道這一點。內部公司網絡中使用的是同樣的東西：你不必記住10.0.0.1內部數據庫服務器的IP，而是使用DNS將域名internal-db1.example.com 翻譯成私有IP，例如10.0.0.1。因此，當你的普通Windows桌面客戶端嘗試連接到數據庫服務器時，它會要求DNS服務器將該域名解析為internal-db1.example.com可以與之通信的IP。（如果你想了解更多關于DNS的信息，我鼓勵你從偉大的互聯網上觀看這個漂亮，簡潔的視頻 —— 那個人不是我哦:)

https://youtu.be/4ZtFk2dtqv0

在一些公司中，管理內部IP的域名的同一DNS服務器同時也管理著其公共IP的域名，例如他們網站的域名。請求“誰是www.example.com”和“誰是internal-db1.example.com”，都是從同一個DNS服務器 —— 即公司的DNS服務器來問詢ns1.example.com。這就是我剛才遇到的那種情況，ns1.example.com是為解決內部和 外部IP 而設立的名稱服務器。只是這臺名稱服務器不在乎請求解析域名的IP地址是來自公司的內部網絡還是外部，所以它響應了我的請求。

=> "Who is internal-db1.example.com"? 

響應：

<= "Hey, it's 10.0.0.1", 

不用擔心它是通過內部地址來響應來自公司網絡之外的DNS請求。

使這一事件成為可能的另一個要求是該公司使用了相同的域名來服務內部和外部。假設他們的網站被命名為：

· www.example.com。

內部數據庫服務器被命名為：

· internal-db1.example.com。

在ping internal-db1.example.com時，我并沒有明確地查詢這個公司的DNS，因為我家的DNS被設置為使用不同的DNS（假設它是Google的DNS）。由于DNS具有分布式結構，如果Google的DNS想要獲取www.example.com的IP ，它首先會要求其中一個根DNS服務器負責跟蹤誰負責第二級域名example.com。已聯系的根服務器會使用域名ns1.example.com的IP作為域名example.com的授權服務器來響應Google的DNS 。然后谷歌的DNS請求ns1.example.com解析internal-db1.example.com并收到它最終轉給我們的響應也就是我們上面看到的內部IP。如果有內部域名internal-db1.example.local，Google的DNS就不會知道是誰要求頂級域名（.local），因為注冊的公司example.com沒有注冊（也不能）example.local。

想一想：在這一點上，Google的DNS知道公司的內部域名和相應的IP。而互聯網上查詢的其他所有DNS服務器internal-db1.example.com都會知道同樣的事情。乍一看并不是什么大不了的事情，但是作為一個試圖保護這個基礎設施的人，我希望你們仍然能夠明白這一點。

 一個小的信息泄漏

顯然，我現在可以通過詢問任何公共DNS來解析公司的內部域名。更讓人感興趣的是許多公司都可以用來枚舉服務器：

db1-internal.company.com 
db2-internal.company.com 
db3-internal.company.com 

等等 - 這意味著如果你知道一個服務器的名稱，那么你可以猜測其他服務器的名稱。當然，你也可以嘗試爆破域名名稱，也許是dev-internal.company.com或log-internal.company.com。這里的泄露信息的問題在于，你可以爆破內部域名，并檢查公司網絡中是否有這些名稱的機器，檢索內部IP 而不登錄到網絡。但是，你仍然需要暴力域名名稱。（是的，有工具可以做到這一點。）

 一個更嚴重的信息泄漏問題

如果你對網絡，IP和DNS有所了解，你可能會猜測我的下一步是什么。許多人基本上知道DNS是如何工作的。人們所知道的是，你不僅可以將一個域名解析為一個IP地址，而且還可以反過來：給定一個IP地址，你可以將其解析為一個域名。與正向DNS相反，這被稱為反向解析或反向DNS，并且通過查詢特定ARPA域的PTR記錄的DNS來完成。如果你想反向解析一個給定的IP，你必須扭轉IP地址，并添加一個特殊的域名，比如in-addr.arpa.net域名。例如，為了解析IP 1.2.3.4對應的域名，你需要要求你的名稱服務器尋找一條記錄是

4.3.2.1.in-addr.arpa.net 

的PTR類型（與正向解析域名時的類A 的IPv4 或類型為AAAA的IPv6地址相比）。

當你“擁有”一個IP 1.2.3.4（意味著它是在IANA注冊的）時，你可以為相應的域名指定一個權威的域名服務器，4.3.2.1.in-addr.arpa.net并且在該域名服務器上配置一條PTR記錄，該記錄指向一個指定的域名。如果有人試圖反向解析1.2.3.4，他會被重定向到你的域名服務器并尋找PTR條目。（即使將多個域名連接到相同的服務器，你也只能將一個域名附加到IP地址。）

所以回到公司的域名example.com上來。如果我不僅能得到一個域名的IP地址，而且可以相反的操作，那么有沒有辦法來檢查一個內部IP地址是否有一個域名與之相關聯呢？我可以只對私有IP空間進行反向查詢嗎？這會讓事情變得更有趣。如果可能的話，我可以簡單地開始迭代枚舉私有IP空間，檢查每個IP是否有注冊的PTR記錄，通過這種方式可以獲得大量有關公司內部網絡的信息 -——IP地址，域名以及我可以從中得到的所有信息。

由于DNS的結構，簡單地反向解析IP是不起作用的：反向解析意味著你的默認域名服務器（例如Google）需要尋找到1.0.0.10.in-addr.arpa.net的內部IP地址。由于沒有人可以擁有該IP并將其域名服務器指定為權威服務器，因此IANA不允許你在此處輸入條目，因此Google的DNS將無法處理該IP的反向DNS查詢，因為它使用company.com是做不到的。它不會像在域名解析的情況下那樣嘗試聯系我們公司的DNS，因為它不知道我們公司的DNS將自己視為了這個內部IP的權威服務器。

但是 - 如果我直接聯系公司的域名服務器，詢問能否為我解析1.0.0.10.in-addr.arpa.net，那么這時會發生什么？在這之間沒有谷歌DNS是不知道該怎么做的。盡管這樣做是沒有意義的，但是盡管不能在IANA上注冊私有IP，但是這不會阻止DNS管理員會在他的服務器上自己配置反向解析，對吧?

該公司的名稱服務器并沒有讓人失望：

michael@seventysix:~ dig -x 10.0.0.1 @ns1.example.com 
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 10.0.0.1 @ns1.example.com 
;; global options: +cmd 
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6077;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available 
;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;1.0.0.10.in-addr.arpa.   IN  PTR 
;; ANSWER SECTION:1.0.0.10.in-addr.arpa.    3600    IN  PTR internal-db1.example.com. 
;; Query time: 16 msec 
;; SERVER: XXX.XXX.XXX.XXX#53(XXX.XXX.XXX.XXX);; WHEN: Wed Jan 21 14:37:49 CET 2018;; MSG SIZE  rcvd: 110 

你看到那個美麗的“ANSWER ”部分了嗎？沒錯。我們通過公司的域名服務器來解析內部IP。現在事情變得非常有趣，因為沒有什么能阻止我迭代枚舉整個私有的IPv4地址空間，通過外部可訪問的DNS服務器從網絡外部來解決公司網絡的每個IP地址。這是最純粹的樂趣。

自動化所有的東西

我現在所需要的是一個腳本，它可以遍歷私有IP地址空間，來獲取該公司的所有內部域名和IP地址。由于配置不當的DNS，導致了一個簡單而又簡單的信息泄漏。(后來有人告訴我，DNS實際上并不是“錯誤配置”的，但這完全是為了克服一些VPN DNS解析問題。要真正獲得這種反向IP地址解析，通常需要設置一個適當的zonefile，這意味著必須顯式地配置它，來反向解析內部IP。無論如何，至少在幾個小時后，本文中這個反向解析的問題已經被修復了。)

在發現了這個缺陷之后，我也很想知道它有多普遍，以及有多少DNS管理員應用了類似的配置。我編寫了一個python腳本，用于對給定的名稱服務器的每個私有網絡范圍的前15個主機進行反向查詢，并開始對域名服務器進行掃描。使用masscan發生了一些麻煩，處理了麻煩之后 (最終效果很好)，我從Shodan下載了大約20.000 DNS服務器的列表，并在周末進行了檢查。這些結果并不引人注目，但也有一些有趣的結果。我通知了一些受影響的公司，但也發現了一些私有的路由器(大多是Broadcom)，這些公司透露了諸如“邁克爾的iPhone”或惠普打印機、亞馬遜之類的名稱。

michael@seventysix ~/privdns % ./privdns.py XXX.XXX.XXX.XXX 10.0.0.0/8 
[*] Checking nameserver XXX.XXX.XXX.XXX 
[+] 10.0.0.1 : E***.net. 
[+] 10.0.0.2 : P***.net. 
[+] 10.0.0.3 : A***.net. 
[+] 10.0.0.4 : A***.net. 
[+] 10.0.0.5 : E***.net. 
[+] 10.0.0.6 : E***.net. 
[+] 10.0.0.7 : P***.net. 
[+] 10.0.0.8 : P***.net. 
[+] 10.0.0.9 : E***.net. 
[+] 10.0.0.10 : P***.net. 
[+] 10.0.0.11 : a***.net. 
[.] Resolved but no entry for 10.0.0.12 
... 

如果你想自己玩的話，你可以在我的GitHub上找到這個腳本。畢竟，這只是一個信息泄露，而我所看到的并不是太常見。據我所知，它還需要一個特定的DNS配置。

privdns.py 

就是這樣。這是一個關于如何在一個公司的DNS中解析私有IP地址時，泄露他們的基礎設施和IP的故事，并且沒有特別的復雜的黑客攻擊和利用技術。