黑客的聰明并不只是在于他們知道如何去入侵服務器，還在于他們知道如何去偽裝自己的攻擊。惡意的攻擊者會使用多種逃避的手段來讓自己不會被檢測到，所以作為系統管理員，也應當了解這些手段以應付可能發生的攻擊。

　　這篇文章的主要目的不是揭示黑客新的攻擊手法，而是對那些黑客所用到的逃避檢測的手法以及他們可能留下的證據做描述。這些手段的欺騙性很大，所以想檢測到它們也更加的困難。

　　　　網絡服務器

　　我們的實驗環境使用兩種最常用的網絡服務器，Apache和微軟的Internet Information Server(IIS)。我們在Red Hat Linux上運行Apache 1.3.9,在Windows NT 4.0上運行IIS 4.0。并且兩種都采用普通和允許SSL的版本，所以我們可以對加密和未加密的服務器的攻擊做測試。

　　　　16進制編碼

　　一種最簡單的將攻擊偽裝的手段就是修改URL請求。作為管理員,我們一般會在日志文件中查找某些字符串，或是一些普通文本的字符集。例如我們在請求中查找匹配已知漏洞的字符串。例如，我們在我們的IIS服務器中發現了如下的字符串，我們就知道有人正在查找是否有IIS中可以遠程利用的MDAC漏洞：

　　　　06:45:25 10.0.2.79 GET /msadc/ 302

　　　　要知道攻擊者是如何躲過這種匹配檢測的，請參考以下作為惡意攻擊者策略一部分的請求。要確定msadc目錄是否存在，攻擊者可能鍵入以下內容：

　　　　[root@localhost /root]# nc -n 10.0.2.55 80

　　　　GET /msadc HTTP/1.0

　　　　這就會產生我們以上所見的日志文件。攻擊者可以將請求進行十六進制的ASCII字符編碼。在以上的例子中，字符串msadc在十六進制編碼以后就會變為6D 73 61 64 63。你可以使用Windows Charmap程序來快速的進行字符的ASCII到十六進制的轉換。以上的HTTP請求，將字符串msadc用十六進制編碼以后，就變成了：

　　　　[root@localhost]# nc -n 10.0.2.55 80

　　　　GET /%6D%73%61%64%63 HTTP/1.0

　　　　IIS的日志文件顯示：

　　　　07:10:39 10.0.2.31 GET /msadc/ 302

　　　　應當注意的是，雖然采用了十六進制編碼的手段，但是所產生的日志和沒有使用十六進制編碼的URL產生的是一樣的。所以在這個例子里，編碼并沒有幫助攻擊者逃避檢測。但是，如果我們看看看Apache的日志情況，那么就是另外一個情形了。以下列出了攻擊者使用來搜索某個CGI腳本的命令，后面跟著的是使用十六進制編碼以后的同樣命令:

　　　　[root@localhost]# nc -n 10.0.0.2 80

　　　　HEAD /cgi-bin/test-cgi HTTP/1.0

　　　　[root@localhost]# nc -n 10.0.0.2 80

　　　　HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0

　　　　現在我們來查看一下access_log文件：

　　　　10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0

　　　　10.10.10.10 - - [18/Oct/2000:08:23:47 -0700] "HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0" 200 0

　　　　首先應注意到的是在這兩個例子中都是200代碼說明命令完成成功。但是在第二中情況中，日志中出現的是十六進制的值而不是明文的。如果我們是依賴于形式來對這種攻擊進行檢測的話，那么我們是不可能檢測到所發生的攻擊的。許多的入侵檢測系統使用的格式匹配技術智能化都不高，并且有些產品不會將十六進制的URL轉換過后進行匹配。但是不論所使用的入侵檢測軟件是否能夠對十六進制的代碼進行轉換，所有的網絡管理員都應當對這種伎倆有所了解。 代理服務器

　　因為對攻擊者而言完全隱藏攻擊行為是很難做到的，所以掩蓋攻擊的真實來源也就成為相當重要的課題了。如果黑客可以隱藏他的源IP地址的話，那么他就可以在不用擔心被抓住的情況下進行攻擊。而黑客用來隱藏他們的源IP地址的一種手段就是使用代理服務器。

　　代理服務器是被合法的用來從一個單一的訪問點轉發多種協議的。一般來說，內部用戶必須通過代理服務器才能訪問Internet，因此管理員就可以在代理服務器指定外部訪問以及內部訪問的限制策略。用戶首先是和代理服務器建立連接，然后代理服務器就將連接請求轉發到真正的目的地址。目的地址會記錄下代理服務器的IP地址以作為請求的源地址，而不是最初發出請求的系統的IP地址。

　　但是不幸的是代理服務器在Internet上的放置太隨意了。(可以查看Proxys-4-All來獲得這些錯誤配置機器的列表。) 這些服務器經常會存在配置錯誤使得Internet用戶可以連接到這些代理服務器上。一旦某個Internet用戶通過代理服務器連接到某個服務器上，該服務器就會將代理服務器的IP地址作為發出請求的源地址記錄在日志中。而在被攻擊服務器的日志中對攻擊者的記錄其IP地址是屬于一個沒有任何攻擊行為的“無辜”主機的，而不是攻擊者的真正地址。我們來看以下的例子。

　　下面的例子顯示了黑客的攻擊和攻擊在日志中產生的相關信息。

　　攻擊者

　　　　[root@10.1.1.1 /]# nc -v 10.8.8.8 80

　　　　HEAD / HTTP/1.0

　　　　日志文件

　　　　10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0

　　　　在下面這種情況中，我們看到攻擊者達到了同樣的目的，但是這次他使用了代理服務器。#p#分頁標題#e#

　　　　攻擊者

　　　　[root@10.1.1.1 /]# nc -v 216.234.161.83 80

　　　　HEAD http://10.8.8.8/ HTTP/1.0

　　　　日志文件

　　　　216.234.161.83 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0

　　　　注意在這個例子中，日志文件中所出現的地址是代理服務器的(216.234.161.83,proxy.proxyspace.com),而不是攻擊者的真實地址。在這個案例中，攻擊者成功的隱藏了攻擊的來源地址。不過網絡管理員如果能得到代理服務的支持的話還是可以追蹤到攻擊的真正來源。大多數的代理服務器都會保存一份相當詳細的日志，所以多半也就可以從中找到攻擊的來源。但是道高一尺魔高一仗，黑客也有相應的方法來反跟蹤：他們可以使用多重代理，也可以說是一個“代理鏈”來進行攻擊。而管理員和執法部門也就必須對所有的中間代理服務器進行依次檢查來獲得攻擊來源。在黑客的團體中這種“代理鏈”的使用非常的普遍，并且有類似SocksChain for Windows這樣的工具可供使用。

　　　　SSL

　　對此以往很多人進行了討論，但是它現在值得再一次提出：允許SSL的服務器是不會被網絡入侵檢測系統所檢測到的。如果讓一個黑客在80端口(HTTP)和443端口(HTTPS)之間做一個選擇的話，攻擊者每一次都會選擇443端口的。這實際上并不是什么手段，而是由于加密通訊的使用所造成的副作用。你可以使用網絡服務器日志文件來監視443端口的請求。

　　　　結論

　　我們向你演示了一些網絡上的黑客常用的欺騙伎倆。無須多說，這些手段是隨著黑客們的想象力和創造力不斷增加而不斷擴展的。例如十六進制編碼這樣的技術不光是用在欺騙性的日志文件入口這樣的地方;它同樣也欺騙網絡服務器的URL解析機制，并可能導致例如源代碼暴露之類的漏洞的出現。攻擊者某些時候也使用多代理服務器來進行掃描和攻擊，讓管理員很難跟蹤攻擊的真正來源。當然，SSL某些時候為“安全黑客行為”鋪平了道路。