服務器構成了網絡基礎結構中最基本的要素，它也是網絡安全中最關鍵的環節。雖然Unix服務器以安全、可靠著稱，但這並不意味著它無懈可擊。並且Unix服務器的安全性影響或決定著網絡基本結構的安全性。
通常情況下，我們特別關注特定主機的安全問題，卻忘記了整體的網絡安全設計。事實上，整個網絡的安全設計問題還是與基於主機的安全有些區別的，在此我們不打算就這個問題展開討論。
下面我們可以定義三種類型的服務器，當然根據你的實際需要，這些服務器可以進一步分類。
公共服務器，這是一種可以訪問互聯網的服務器。
登錄服務器，這種服務器允許非超級用戶登錄。
其它服務器，如MySQL，內部LDAP或NFS服務器，這些服務器只能從內部網絡到達。
根據我們定義的這些服務器，網絡的總體布局和我們要運用的防火牆規則也就顯而易見了。
問題是我們該如何管理這些服務器，保持其安全性。這是我們設計的難題之一，因為一個脆弱的設計可能就意味著災難的降臨。
從一個更高級的視點上來看，我們知道有些服務器要比其它服務器重要。一個或多個服務器需要被其它的服務器信任，這樣才能保證自動化改變的發生。賬號的創建，按照Tripwire 或Samhain方式對主機完整性的監視，甚至配置文件的備份都需要從某個服務器配置並維持，而這個服務器能夠以根用戶身份訪問其它服務器。
這樣一個服務器，我們或可稱它為主服務器，只有超級用戶賬戶可用於登錄訪問。超級用戶的口令需要與其它服務器的口令不同，而且這個主服務器不應向外部世界提供服務。公共服務器的損害不應影響主服務器的安全。當一個表面上不重要的機器被損害時，一次黑客性質的登錄會成為一個rootkit的一部分，這又會導致用戶賬戶口令的暴露。這也就是sudo並非一個好主意的原因：它給你的用戶口令根目錄的訪問權限。一個被損害的su可能會洩露根用戶的口令，這也就是主服務器如此重要的原因。
主服務器應能夠以SSH方式並以根用戶的身份登錄到所有其它的服務器，但只能通過SSH密鑰進行。基於口令的根用戶的登錄絕對不要允許通過SSH進行。如果主服務器被危及到其安全性，那麼其它任何一個服務器都會落得同樣的下場。因此，主服務器是一個堡壘，只運行SSH服務，並只與其它機器連接。配置文件的備份、主機完整性數據庫等都可被存儲在主服務器上。
可被公共訪問的服務器是最為脆弱的，原因就在於它們運行的應用程序，但登錄服務器也會引起問題，而且它們在許多其它方面也是很脆弱的。其用戶，不管是開發人員還是學生、客戶，都不太在乎安全問題。他們會運行心目中的任何可得到的應用程序，其中包括SQL服務器，基於PHP的WEB應用程序(只采用安全性很差的安全記錄)，以及看起來有用的其它任何東西。為了防止未知用戶通過這些程序的漏洞進入系統，你最好還是為你的操作系統安裝最新的補丁程序。
為操作系統打補丁並不是可選的，更不是一件可掉以輕心的事情。必須要反復強調：在一個安全更新可用時，必須為所有的服務器及時更新。對於那些只在周末為Unix服務器打補丁的用戶來說，他們要承擔一種嚴重的責任，因為具有惡意用心的人可以很輕松地獲得根目錄的訪問，因為對於系統漏洞的惡意利用代碼出現的速度是極快的。此外還有一些很新的惡意利用;這些都是十分可怕的事情。SELlinux或者一台正確配置的Unix計算機能夠在防止惡意利用漏洞方面大有幫助。因此我們認為總體上的安全架構是最為關鍵的。
那些不安全的服務器可能允許用戶登錄。假定我們需要共享的home目錄，要支持此處描述的環境可能會很困難。輸出到不安全客戶端的NFS共享需要仔細檢查，特別是當開發人員或研究人員需要其機器上的根目錄權限時。
既然NFS意味著無安全性，向一個未被控制的客戶端授權訪問NFS共享是相當可怕的。實質上，你必須假定在共享文件系統中的任何東西都可能被危及安全，因為在根用戶可能會很輕易地SU到碰巧擁有文件的任何人那裡。老的標准工作區是要將這些類型的共享移到其自有的分區中，而且將其共享給那些有害的客戶端。AFS並不支持企業級特性，因此你最好不要采用它，而且它本身並不支持快照或兼容的ACL等。
我們可以對系統安全提出各種各樣的最優方法和缺陷。從架構的視點來看，一般的觀點是用兩種方式將風險最小化：一是使其難於滲入，二是一旦進入系統，應難於擴散。通過采用恰如其分的監控，你應該能夠快速地檢測任何入侵並能阻止它。
不管你有300個還是3000個服務器，基本的原則都是相同的。這看起來簡單，在配置一個新的或被破壞的服務器時卻是最基本的。請記住：
在暴露的服務器上盡量地減少服務;
盡量地減少暴露的服務器的數量;
在給NFS客戶端任何權限時需要極端小心;