在Unix操作系統中，可以利用兩個文件來統一管理客戶端的連接。誰可以訪問Unix服務器，都有這兩個文件說了算。也就是說，這Hosts.allow與Hosts.deny兩個文件就好像是Unix服務器的“看門狗”，它決定了哪些客戶端可以訪問Unix服務器，哪些則不行。
筆者在描述這兩個文件的工作流程時，各位讀者不知道有沒有注意一個問題。當客戶端的信息在兩個文件中都沒有定義的時候，Unix操作系統服務器最終是否允許連接呢?答案是可以連接。也就是說，Unix操作系統服務器有一個默認的策略，當在以上兩個文件中都找不到相關的紀錄時，則服務器最終是允許客戶端進行連接的。
這就會造成一個安全的隱患。如上面財務管理軟件這個案例。企業可能只允許四個財務人員與系統管理員可以連接到財務管理軟件服務器。為此Unix操作系統管理員就只在Hosts.allow文件中定義了這五個用戶的信息。而在hosts.deny文件中沒有定義其他信息。此時采購部的某個用戶其能否訪問這台Unix服務器呢?首先Unix操作系統會查詢hosts.allow文件，發現沒有這個客戶端的相關信息。此時Unix服務器就會去查詢hosts.deny文件的信息。
由於在這個文件中也沒有明確定義用戶不能夠訪問Unix服務器，故Unix操作系統又會放行。最後的結果就是采購用戶可以訪問財務管理軟件的服務器系統。這個結果顯然跟系統管理員的本意不符。
筆者上面談到過，這兩個文件的處理機制跟思科防火牆的訪問控制列表類似。但是在這方面則是一個最大的不同。在思科路由器等網絡設備中的防火控制列表，其默認情況下是全部拒絕的。也就是說，如果其前面沒有匹配選項的話，則其最後采用拒絕全部用戶連接電策略。而現在Unix操作系統對這個兩個文件的處理過程則剛好相反。默認情況下，其是允許用戶進行連接的。
即如果前面兩個文件都沒有客戶端信息的話，則最終將允許這個客戶端連接到Unix服務器中。這顯然對於Unix操作系統服務器不怎麼安全。為了避免這種情況，筆者建議在hosts.deny文件的尾部最好能夠添加ALL:ALL一句。
這個表示默認情況下拒絕所有客戶端連接到Unix操作系統服務器中。如此的話，第一個文件定義允許的客戶端;第二個文件定義拒絕的客戶端(默認情況下為所有客戶端都拒絕連接)。這就可以保證只有第一個文件中定義的客戶端才可以連接到Unix服務器，就不會有漏網之魚了。當然這是對於安全要求比較要的企業或者服務器來說。
而對於像文件服務器這種多個部門需要用到的管理軟件，則不能夠這麼設置。因為其默認情況下是所有客戶端都可以連接到文件服務器，故要把hosts.deny文件中的ALL:ALL參數去掉。
如果Unix操作系統需要限制某些客戶端的連接(如某個員工要離職了，為了防止其對文件服務器中的文件進行故意損壞，就會中斷這個員工跟服務器的連接)，則可以以顯示的方式在hosts.deny這個文件中加入這個信息。拒絕這個客戶端再次連接到Unix服務器中。
