DHCP***防御處理的示例分析

這篇文章主要為大家展示了“DHCP***防御處理的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“DHCP***防御處理的示例分析”這篇文章吧。

     DHCP應用背景：在局域網組網規模相對較大的環境中，為了提高網絡管理效率減少網絡管理中的繁復勞動我們一般會在局域網中架設DHCP服務器，并通過該服務器來自動為普通工作站提供合法IP地址提供上網服務；當局域網中的普通工作站連接到局域網絡后，它會自動向局域網網絡發送上網參數請求數據包，DHCP服務器一旦接受到來自客戶端系統的上網請求信息后，會自動為其提供合適的IP地址、網絡掩碼地址、網關地址以及DNS地址等參數，獲得相應合法地址后客戶端系統就能正常訪問網絡了，很顯然DHCP服務器的穩定性將直接影響整個局域網網絡的工作穩定。

　　如果在局域網中同時還存在另外一臺不合法的DHCP服務器時或DHCP服務器遭受惡意***時，整個局域網網絡的運行穩定性將會受到破壞，普通工作站的上網將因無法獲得可用的合法IP地址而出現混亂。為了讓局域網網絡運行始終穩定，我們需要想辦法保護合法DHCP服務器的運行安全性，以避免其受到惡意***或不合法DHCP服務器的“沖擊”！

下面看一個圖例：

1、交換機層面解決這個問題
通過交換機的端口安全性設置每個客戶端主機 DHCP 請求指定端口上使用唯一的 MAC 地址，通常 DHCP 服務器通過 DHCP 請求的報文中的 CHADDR 段判斷客戶端 MAC 地址，通常這個地址和客戶端的MAC地址相同，如果***者不修改客戶端的 MAC 而修改 DHCP 報文中 CHADDR ，實施 Dos ***， Port Security 就不起作用了， DHCP 嗅探技術可以檢查 DHCP 請求報文中的 CHADDR 字段，判斷該字段是否和 DHCP 嗅探表相匹配。這項功能在有些交換機是缺省配置的，有些交換機需要配置，具體需要參考相關交換機的配置文檔。

另外利用DHCP Snooping技術，通過建立和維護DHCP Snooping綁定表過濾不可信任的DHCP信息，這些信息是指來自不信任區域的DHCP信息。通過截取一個虛擬局域網內的DHCP信息，交換機可以在用戶和DHCP服務器之間擔任就像小型安全防火墻這樣的角色，“DHCP監聽”功能基于動態地址分配建立了一個DHCP綁定表，并將該表存貯在交換機里。在沒有DHCP的環境中，如數據中心，綁定條目可能被靜態定義，每個DHCP綁定條目包含客戶端地址(一個靜態地址或者一個從DHCP服務器上獲取的地址)、客戶端MAC地址、端口、VLAN ID、租借時間、綁定類型(靜態的或者動態的)。

當交換機開啟了 DHCP-Snooping后，會對DHCP報文進行偵聽，并可以從接收到的DHCP Request或DHCP Ack報文中提取并記錄IP地址和MAC地址信息。另外，DHCP-Snooping允許將某個物理端口設置為信任端口或不信任端口。信任端口可以正常接收并轉發DHCP Offer報文，而不信任端口會將接收到的DHCP Offer報文丟棄。這樣，可以完成交換機對假冒DHCP Server的屏蔽作用，確保客戶端從合法的DHCP Server獲取IP地址。

基本配置命令示例如下：

　　全局命令：

　　ip dhcp snooping vlan 10，20          * 定義哪些 VLAN 啟用 DHCP 嗅探

　　ip dhcp snooping

　　接口命令：

　　ip dhcp snooping trust

　　no ip dhcp snooping trust (Default)

　　ip dhcp snooping limit rate 10 (pps)    * 一定程度上防止 DHCP 拒絕服務***

　　手工添加 DHCP 綁定表：

　　ip dhcp snooping binding  000b.db1d.6ccd vlan 10 192.168.1.2  interface gi1/1  expiry 1000

　　導出 DHCP 綁定表到 TFTP 服務器

　　ip dhcp snooping database tftp:// 10.1.1 .1/file

　　需要注意的是 DHCP 綁定表要存在本地存貯器 (Bootfalsh 、ftp 、 tftp) 或導出到指定 TFTP 服務器上，否則交換機重啟后 DHCP 綁定表丟失，對于已經申請到 IP 地址的設備在租用期內，不會再次發起 DHCP 請求。如果此時交換機己經配置了 DAI 和 IP Source Guard 技術，這些用戶將不能訪問網絡。

   注：對于類似Gobbler的DHCP 服務的DOS***可以利用Port Security限制源MAC地址數目加以阻止，對于有些用戶隨便指定地址，造成網絡地址沖突也可以利用DAI和IP Source Guard技術。有些復雜的DHCP***工具可以產生單一源MAC地址、變化DHCP Payload信息的DHCP請求，當打開DHCP偵聽功能，交換機對非信任端口的DHCP請求進行源MAC地址和DHCP Payload信息的比較，如不匹配就阻斷此請求。
 

2、客戶端服務器層面解決這個問題
  客戶端處理：在客戶端主機上我們可以在DOS命令行提示符下執行“arp -s 192.168.2.45 00-01-02-03-04-05"來綁定客戶端的IP和MAC，同時執行“arp -s 192.168.2.1  00-01-02-6E-3D-2B” 來綁定網關的IP和MAC，或者在客戶端主機上安裝一些ARP防病毒軟件來避免此類的***。
         一旦發現自己的客戶端不能正常上網時，我們可以在DOS命令行提示符下執行“ipconfig/release”字符串命令，來將之前獲得的不正確上網參數釋放出來。

　　然后嘗試執行“ipconfig/renew”字符串命令，來重新向局域網發送上網參數請求數據包，如果上述命令返回錯誤的結果信息，那么我們可以在本地系統運行對話框中繼續執行“ipconfig/release”、“ipconfig /renew”字符串命令，直到客戶端工作站獲得有效的上網參數信息為止。

服務器端處理：
   通常情況下，局域網中的普通工作站安裝使用的都是Windows操作系統，在Windows工作站系統為主的局域網環境中，我們可以通過域管理模式來保護合法DHCP服務器的運行安全性，同時過濾不合法的DHCP服務器，確保該DHCP服務器不會為局域網普通工作站分配錯誤的上網參數信息。我們只要在局域網域控制器中，將合法有效的DHCP服務器主機加入到活動目錄中，就能保證局域網中的所有普通工作站都會自動從合法有效的DHCP服務器那里，獲得正確的上網參數信息了。這是因為域中的普通工作站向網絡發送廣播信息，申請上網參數地址時，位于同一個域中的合法有效的DHCP服務器，會自動優先響應普通工作站的上網請求，如果局域網指定域中的DHCP服務器不存在或失效時，那些沒有加入指定域中的不合法DHCP服務器才有可能響應普通工作站的上網請求。

  當然我們也可以嘗試通過域管理加ISA安全管理的方式來實現更為細致的管理和控制。在域中設置一臺單獨的DHCP服務器，DHCP服務器通過MAC地址來為客戶端分發固定的IP，ISA服務器發布DHCP服務器并通過不同的策略設置來限定客戶端的權限，這樣可以實現粒度更為細致的安全管理。

注：域管理模式對于局域網規模比較小的單位來說，幾乎沒有多大實際意義，因為小規模的局域網幾乎都是工作組工作模式，這種工作模式下合法有效的DHCP服務器是無法得到安全保護的。

以上是“DHCP***防御處理的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！