DHCP NAC TCP 路由器 網管 IP 協定

讓DHCP更可靠安全 避免服務失效並留心漏洞

2014-01-21
上一期文章介紹了DHCP協定的歷史與運作機制等等,相信各位讀者對於DHCP協定已經有一個很扎實的認知。本期接著介紹更深入的DHCP議題,也就是與DHCP協定的安全性以及可靠性相關的技術。
本文將先從DHCP協定的可靠性談起,接著講述DHCP協定的安全性,然後詳細介紹與DHCP協定安全性相關的解決方案。

DHCP協定的可靠性

DHCP協定等於是開啟了一般電腦或上網設備在IP層的通訊,因此DHCP協定的可靠性是一個頗為重要的議題。一般來說,DHCP協定透過以下的過程來提升可靠性:

  • 1. 定期更新IP租約(Periodic renewal)
  • 2. 重新連結DHCP伺服器(Rebinding)
  • 3. 容錯轉移(Failover)
接下來,就來看看如何進行這些步驟來提升DHCP協定的可靠性。

定期更新IP租約

如同大部分讀者所知道的,事實上,DHCP用戶端(例如一般個人電腦或手機等等)從DHCP伺服器端所取得的IP位址是有租約(Lease)的。也就是說,這個IP位址只能被DHCP用戶端使用一段時間而已。時間一到,就必須重新更新,取得新的租約。而定期更新所指的,就是定期去更新這個租約。


▲對上網設備的IP層通訊而言,DHCP的可靠性可說事關重大。Photo: John Blyberg (CC BY 2.0)

但是,何時必須開始重新申請租約呢?如果時間到才去申請,是否有可能造成中間某段時間沒有網路可以用?沒錯,為了避免這樣的問題(也就是提升可靠性),每當DHCP用戶端在「租約一半的時間」到的時候,就會開始發送DHCP request封包給DHCP伺服器。這個時候,DHCP用戶端所發送的是Unicast,並非廣播封包。而且只會送往原本發送租約給DHCP用戶端的那一台DHCP伺服器。

當然,在這樣的情況下還是有風險。有可能DHCP伺服器端剛好關閉、重新開機,或是任何無法處理這個DHCP request的時候,若碰到這樣的情況,DHCP用戶端會一直持續發送DHCP request,直到DHCP伺服器可以處理為止。

重新連結DHCP伺服器

如果DHCP伺服器真的在過了很長一段時間還是無法處理DHCP requests,那DHCP用戶端就會採取其他做法:Rebind。簡單來說,就是重新找尋可以提供服務的DHCP伺服器。

剛才第一個步驟當中,DHCP用戶端所發送的DHCP request是採用Unicast的方式,也就是說,只有原本提供IP租約的DHCP伺服器才會收到DHCP request。

而這邊的步驟則是會發送廣播封包方式的DHCP request。差別在於希望所有的DHCP伺服器都能收到這樣的DHCP requests。因為原本的DHCP伺服器無法提供服務,所以透過廣播封包的方式來試試看有哪一個其他的DHCP伺服器能夠提供服務,並且提供IP租約。

但為了確保重新連結的過程是沒有問題的,當DHCP用戶端成功連上新的DHCP伺服器之後,新的DHCP伺服器必須擁有正確的用戶端資訊。在兩個DHCP伺服器之間確保正確無誤的資訊能夠完整被維護,是一件很複雜很困難的事情。

因此,IETF針對這樣的問題開發了可容錯的DHCP伺服器方式,不過這不是這一篇文章所要著重的重點,也許以後有機會再跟各位分享介紹。

容錯轉移

如果連重新連結DHCP伺服器這樣的步驟都失敗了,當然結果就是沒有IP可以使用,因為IP租約已經過期了。此時,DHCP用戶端就會回到最開始的情況,重新透過廣播封包發送DHCP Discovery。

也因為沒有任何的IP位址,所以只要有IP位址發送下來,這個DHCP用戶端就會接受並且使用,也因此,新得到的IP位址有極大的可能性會與原本的IP位址不一樣,導致的結果就是原本的某些網路連線可能就會斷掉並且重新連線。

DHCP協定的安全性

介紹過DHCP協定的基本運作過程之後,想必大家會發現,其實在DHCP伺服器和DHCP用戶端之間的交互運作過程中,完全沒有任何用戶認證(Authentication)的程序,也因此可以說毫無安全性可言,所以DHCP協定有不少安全上的漏洞。


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!