Telnet服務是最早的遠程訪問服務。它是在網絡發展的早期，所有的操作系統還基於命令模式控制時，為了解決用戶遠程維護主機、遠程辦公等用戶需求而特意開發的一個服務，被一直沿用到現在。
當終端服務這個基於圖形界面訪問的服務推出之後，現在已經很少有人利用Telnet服務進行遠程訪問和遠程辦公了。但是Telnet服務卻搖身一變成為了黑客的最愛。據統計，被黑客利用得最多的一個系統服務，就是Telnet服務。
黑客為什麼不喜歡使用同樣基於遠程訪問，並且更加方便直觀的終端服務，而偏愛Telnet服務呢？難道因為黑客就喜歡在黑乎乎的命令窗口中操作嗎？NO，當然不是這樣。因為使用Telnet服務進行遠程控制更加隱蔽，對系統的資源消耗也非常小，並且只需要一個命令即可開啟和關閉它。所以對於網絡安全來講Telnet服務是一個非常危險的服務。
Telnet服務使用Telnet協議傳輸，在系統中使用的默認端口為TCP23端口。由於Telnet協議是集成在TCP/IP協議中的，所以我們無法使用刪除協議的辦法來禁止Telnet服務。在我們講防御Telnet服務之前，首先來看看黑客是如何利用Telnet服務的（筆者系統為Windows2000）。
攻：利用Telnet服務入侵
1.開啟Telnet服務
要想利用系統當中的Telnet服務必須先開啟Telnet服務，因為在默認情況下Telnet服務是被系統所禁止的。Tw.wINGWIT.Com所以當黑客使用緩沖溢出，IPC$等方法拿到遠程主機的Shell之後，必須開啟Telnet服務。
在命令行方式下開啟Telnet服務的方法非常簡單，只要在命令行當中鍵入“net start telnet”命令，即可開啟系統中的Telnet服務。這是黑客使用得最多的一種開啟Telnet服務的手法（圖1）。
圖1
2.利用Telnet服務
那麼是不是啟動了Telnet服務，黑客就可以利用Telnet服務連接到遠程主機中去了呢？在命令行窗口中鍵入“telnet IP”命令，如telnet 192.168.0.3，這時命令行窗口會出現如圖2所示的情況。
圖2
在這個窗口中，無論用戶選擇“Y”還是“N”都會出現“失去了跟主機的連接”提示。
這是因為用戶沒有通過遠程主機的NTLM驗證。正是利用NTLM這個基於WorkGroup網絡當中的身份驗證協議，使得黑客不能輕易地利用到Telnet服務，這時即使黑客知道了Telnet服務器的管理員用戶名和密碼，他仍然通不過NTLM驗證，這無疑給系統帶給了一定的安全性。
3.突破NTLM驗證
既然入侵者無法通過NTLM驗證，那麼Telnet服務就安全了？其實黑客有非常多的方法可以突破NTLM驗證。
比如黑客知道了Telnet服務器上的一個管理員組的用戶名和密碼（如用戶名為xiewei,密碼為12345），那麼黑客可以在自己的系統中建立一個用戶名和密碼與之相同的管理員組用戶。然後按住“Shift”鍵不放，找到“開始→程序→附件”中的“命令提示符”，右擊“命令提示符”選項，可以在右鍵菜單中看到一個“運行方式”選項，打開它就可以看到一個選擇用戶打開程序的選項，勾上“下列用戶”，黑客就可以在選項中填入剛剛建立的與Telnet服務器上等同的管理員組用戶（圖3）， 確定之後在打開的命令行窗口中，連接Telnet服務器，就可以非常順利地通過NTLM驗證。
圖3
這只是突破NTLM驗證方法中的一種，黑客如果拿到了遠程系統的CmdShell，可以上傳一些第三方的工具，如Ntlm.exe，然後執行這一工具也可以刪除NTLM驗證。
在系統中用戶其實也可以手動地更改NTLM驗證的設置，在“Telnet服務管理器”中就提供了修改NTLM驗證的選項。用戶可以在“程序→控制面板→管理工具”中找到“Telnet服務管理”選項，單擊就可以打開。或者用在命令行窗口下鍵入“tlntadmn.exe”也可以打開“Telnet服務管理器”。用戶可以看到“Telnet服務管理器”是以命令行的方式出現的。選擇當中的選項3“顯示 / 更改注冊表設置” （圖4），用戶可以看到會出現一個選項的列表，總共有八個選項。
圖4
大家可以發現，選項7是針對NTLM驗證的，它的默認值是“2”，其中還有兩個值可以選擇，分別是“0”和“1”。“0”的意思是不使用 NTLM 身份驗證；“1”則表示先嘗試 NTLM 身份驗證，如果失敗，再使用用戶名和密碼；“2”的意思是只使用 NTLM 身份驗證。
如果把NTLM的值改為“0”或者“1”，在Telnet連接的時候，我們都可以順利地通過NTLM驗證。所以接下來的步驟，選擇列表中的“（7）NTML”，並且選擇“Y”更改默認值，最後把NTLM驗證的值改為“0”或者“1”即可（圖5）。從圖5中可以看到“Telnet服務管理器”提示，只有當Telnet服務重新啟動之後配置才能夠生效。用戶可以在命令行窗口下鍵入“net stop telnet”和“net start telnet”即可重新啟動Telnet服務。
圖5
接下來遠程用戶就可以使用“telnet IP”連接到Telnet服務器上了，雖然沒有了NTLM驗證的限制，但是訪問用戶必須鍵入Telnet服務器的管理員組用戶名和密碼方能訪問到。當訪問到時，用戶就可以執行Windows SHELL命令來管理遠程主機了。
防：全面封鎖Telnet服務
知道了黑客利用Telnet服務的手法，那麼針對Telnet服務的防御辦法自然也就有了。根據黑客利用Telnet服務的思路，筆者總結了防御Telnet服務四種方法。
1.管理好用戶的密碼
最簡單的方法，管理好本機系統當中的用戶名和密碼，如果用戶名和密碼無法被黑客取得，那麼黑客將很難利用到Telnet服務。
2.修改服務端口
從前面的內容中大家可以了解到Telnet服務使用的是系統的23端口，如果我們修改了Telnet服務的默認端口，無疑隱藏了Telnet服務的入口點，給系統帶來了一定的安全保障。修改方法非常簡單，首先打開“Telnet服務管理器”，同樣選擇當中的選項3“顯示 / 更改注冊表設置”，打開Telnet服務管理列表，選擇當中的選項8“TelnetPort”，選擇“Y”更改Telnet服務的默認端口23，把Telnet服務的端口改為1024或1024以上的端口，確定即可。接著重新啟動Telnet服務，配置即可生效。以後用戶只要鍵入“telnet IP 1024”即可訪問到Telnet服務器。
3.禁用Telnet服務
大家知道要想使用Telnet服務必須開啟Telnet服務，假如黑客利用緩沖溢出或者其它方法拿到了用戶的CmdShell，那麼他只要在中CmdShell下鍵入“net start telnet”即可啟動Telnet服務，並且可以利用Telnet服務作為用戶系統中的後門使用。有什麼辦法才能夠阻止黑客開啟Telnet服務呢？其實辦法非常簡單，禁用Telnet服務即可實現。用戶打開“控制面板→管理工具→服務”在當中找到Telnet服務選項，雙擊就可以進入“Telnet服務屬性”對話框，在“啟動類型”中選擇“已禁用”，單擊“確定”按鈕即可。
4.終極Telnet服務
禁用服務並不是防御Telnet服務的終極辦法，針對這一限制，黑客專門有一些第三方工具，只要拿到了遠程主機的CmdShell，他只須上傳該工具到遠程主機並運行它就可以突破禁用服務這一限制，開啟Telnet服務。
所以針對這個問題，筆者最後給大家介紹一種最完美的防御方法。
首先打開“Telnet服務管理器”，同樣選擇選項3“顯示 / 更改注冊表設置”，進入Telnet服務管理列表，大家可以看到其中的選項4“DefaultShell”，前面我們已經介紹過這個選項的具體含義，“顯示Telnet服務所對應的程序。默認值是： %Systemroot%\System32\Cmd.exe /q /k”，這個含義的具體意思是什麼呢？為什麼當我們通過Telnet驗證的時候能夠取得遠程主機的命令控制權限呢？
因為我們可以看到Telnet服務對應的默認程序是“%Systemroot%\System32\Cmd.exe /q /k”也就是系統根目錄WinNT（或Windows）下System32目錄下的Cmd.exe，我們都知道Cmd.exe是系統中的命令行窗口，那麼當遠程用戶通過了Telnet驗證的話，遠程系統就會把自己的Cmd.exe調給遠程用戶使用，這就是為什麼使用Telnet能夠拿到遠程主機命令控制權限的最根本原因。
講到這裡似乎防御方法也出來了，其實思路很簡單，我們把Telnet服務所對應的默認程序改為一個未知的程序，這樣即使黑客知道了遠程主機的管理員用戶和密碼，突破了NTLM驗證對方仍然無法拿到對主機的命令控制權，因為Telnet服務對應的默認程序已經不在是Cmd.exe中。有了好思路我們就來具體使用這個方法。
選擇Telnet服務管理列表中的選項4“DefaultShell”，就會提示我們是否更改Telnet服務的默認設置，選擇“Y”，並且把Telnet服務對應的默認程序改為一個未知的文件，如：%SystemRoot%\system32\xiewei.exe，我的系統中根目錄下根本不存在xiewei.exe文件，設置好之後重新啟動服務。
設置好之後，我們來看一下它的效果。假如現在黑客知道這台系統的管理員用戶Administrator，密碼為12345，並且這台系統開啟了Telnet服務，NTLM驗證也被突破，那麼使用 “Telnet IP”連接到這台系統，這時會提示鍵入遠程系統的用戶名和密碼，證明已經通過了NTLM驗證，在正確地輸入用戶名密碼之後，系統仍然提示“失去了跟主機的連接”。
通過對這種方法，用戶可以全面禁止系統中的Telnet服務。
From:http://tw.wingwit.com/Article/Network/201309/1061.html