淺析配置管理與網絡安全

◆李維峰

?

淺析配置管理與網絡安全

◆李維峰

（中國飛行試驗研究院 陜西 710089）

本文分析了五種不同場景的安全配置管理：安全設備、網絡基礎設施、普通用戶計算機、服務器和PDA。這些場景中的每一個都提出了不同的配置管理挑戰，當然這些問題中的任何一個對于大型站點來說都是嚴重的威脅。本文針對一個真實的案例進行研究，分析一個主要的ISP如何使用以數據庫為中心的配置管理方案。

配置管理；安全性；數據庫

0 引言

計算機系統需要配置，即便最簡單的家用計算機也會要求用戶在第一次開機使用時填寫基本的注冊信息。任何系統管理員或網絡管理員都清楚，完整的安全配置要復雜得多，有時甚至是需要設置很多普通人從未聽說過的選項。

對所有系統管理員來說，配置管理是系統和站點安全性的重要組成部分。安全設備本身不僅需要配置，而且普通計算機使用的許多普通方面都對安全性有影響。安全配置還有另一個獨特的特點：它與業務和人事政策有很強的互動。許多安全決策是管理決策的具體實例，不正確的配置可能危及業務關系或產生法律后果。安全配置還涉及對付潛在的“破壞者”，管理安全配置不僅僅是設計正確的配置和分配的問題，而且管理員必須主動嘗試顛覆配置、躲避配置，或將系統驅動到配置不可預料的狀態。值得注意的是，“破壞者”可以包括網站自己的員工。

這就是安全配置管理的挑戰：制定和部署滿足組織需求的政策。

1 大規模系統面臨的挑戰

（1）被管設備規模問題

通常，規模上的差異是定性的，而不是簡單的量化。管理100臺機器的配置與管理一臺或兩臺機器不同，管理1000臺仍然不同，顯然這是不合理的，每個機器的擁有者都可以管理它的配置。也就是說，我們不是把1000臺機器作為一個組來處理，而是我們已經知道如何解決1000個問題。這種方法至少有四個問題需要考慮：

首先是個人管理的機器往往管理不善。大多數計算機用戶不是專業的系統管理員。就像許多家用計算機被錯誤配置一樣，從安全角度和普通的正確性角度來看，在企業環境中做同樣的事情也會導致很多計算機配置錯誤。

第二個問題是一致性。在許多環境中，企業配置是集中指定的。將配置留給個人將不可避免地導致錯誤配置，以軟件的選擇為例：每個人是否都安裝了企業強制性的應用程序？它們會被及時更新嗎？另外有一些安全設置由于給用戶的工作帶來了麻煩而遭到用戶的抵制，比如：很多公司禁用USB大容量存儲設備，以避免泄露敏感的企業數據，但給正常的工作帶來了麻煩。

第三個問題：互動。也就是說，兩個本身是正確的配置可以以危險的方式進行交互。Martin等人給出一個例子，其中正確的Java行為和正確的防火墻行為為FTP協議[1]結合起來產生一個安全漏洞[2]。

最后,這一點往往被那些不在系統管理業務的人所忽視——許多機器（以及在某些環境下，大多數機器）不是普通的臺式機。服務器，虛擬機甚至許多嵌入式系統也需要配置管理。網絡連接的打印機可能比普通的臺式機更容易被破解，并且實際上可以運行一些相同的軟件。

為了正確的操作和安全，一些形式的集中配置管理是必要的。雖然有許多方法可以做到這一點，但是必須滿足一些要求：安全配置管理方案在許多方面都必須是安全的。其數據庫必須受到保護，以防止無法訪問或修改，與托管主機的通信必須經過身份驗證，完整性保護以及經常加密；管理系統的命令必須正確認證。不同的機器有不同的角色。因此，它們需要不同的配置。普通臺式機可能不需要成為Web服務器，但它可能成為一臺數據庫服務器或者是郵件服務器，這都取決于用戶的需求。有時候安全配置會失效。在嘗試更新期間，機器可能停機、補?。ㄌ貏e是包含供應商提供的修補程序）可能無法安裝，如果配置更改與安全性相關，則可能產生嚴重后果。

（2）管理工作量的問題

從上面的描述可以明顯看出，管理大量機器的配置需要以下三方共同努力：人員、軟件和數據。同時，配置管理系統本身需要管理層或管理系統層。

首先，在一個足夠大的企業中，單一的配置管理系統是不夠的。不僅不能處理負載，還需要輔助設備來實現冗余。在設備地理位置分散的情況中，數據庫維護至少必須適應在地理上分布。每臺新電腦的配置需求都必須輸入數據庫;當管理員不知道機器的存在時，這是很難做到的，更不用說它的角色和需要了。對于這個問題，在許多環境中，有必要進行手工和電子審計，以檢測新機器并在配置管理系統中正確注冊。最后，配置需要改變。獲得了新的軟件、開發了新的應用程序等，都可能會引起安全配置的改變。

2 場景分析

不同的配置場景有不同的需求，有必要對它們進行仔細分析。

（1）安全設備

具有安全敏感配置的最明顯的一類計算機是安全設備：防火墻，路由器等。這些設備不僅為企業的其他部門提供安全保障，而且還有其自身的嚴格安全需求。

這個環境中最難的問題是獨立于配置的機制。相反，這配置應該是什么又取決于網絡拓撲結構和所需的安全策略。例如，安全策略會因新軟件、新業務需求和新威脅而發生變化。與公司合作的企業發生了改變就需要建立專用鏈接，這必須調整防火墻規則以允許訪問一些資源，但不是全部資源。（新的專用鏈接的替代方案是虛擬專用網絡連接，這些連接通常更便宜，但是卻有自己的安全敏感配置需求。）

復雜的防火墻配置已知是容易出錯的。即使使用完全分布式防火墻，這種情況也可能會保持不變。這樣只解決了拓撲問題而不是政策問題。

驗證防火墻策略是一項重要工作。盡管自動化工具[3]可以檢測某些類別的錯誤，但這些工具無法區分合理的策略和反映實際愿望的策略。也就是說，允許端口80訪問官方公司網站服務器并允許端口80訪問敏感的內部網絡服務器之間沒有先驗的區別，自動化算法無法區分這兩種情況。驗證拓撲變化更加困難。

最終，在地理上分散的組織中，這兩個問題都更為復雜。中央系統管理員很難知道哪些外部參與者應該訪問哪些服務器，更不用說當新的鏈接安裝到遠處的位置時。

安全設備本身也需要安全保護。保持這樣的配置本身就是一個難題。事實上，最近的一項調查[4]報告稱，ISP把訪問控制列表（ACL）的管理稱為“最關鍵”的問題。這對關于自動生成ACL的工作可能會有所幫助。

（2）基礎設施

即使普通的基礎設施節點（即沒有特殊安全角色的節點）也具有安全敏感的配置。如果沒有別的，控制這些元素的對手可能會破壞整個組織的連接。更復雜的攻擊者可以通過竊聽節點重新路由流量。正確的配置——即正確的密碼、正確的訪問控制列表、恰當的日志記錄等，可以大大地防止這種攻擊。

跟蹤某些類型的攻擊時，記錄交換機上的功能非常重要。具體來說，記錄MAC地址和流量可以幫助隔離拒絕服務攻擊的來源并解決欺騙攻擊。另一方面，這也是必須管理的配置。

即使沒有惡意攻擊，維護路由器配置也很困難。當路由出現問題時（這種情況并非不可能），在復雜的配置中，修復問題的技術人員通常會忘記更新主配置數據庫。為此，一些站點定期輪詢路由器的配置，并將其與官方授權的版本進行比較。

然而，更難的問題是安全策略的沖突。這個問題不是技術性的，因為它是政策性的：誰的政策應該占主導地位？也就是說，總體公司政策和地方需求之間存在分歧，應該怎么協調？技術機制可以識別問題，但不能解決問題。我們在這里注意到，做出的決定會影響企業網絡的安全性和本地業務部門的生產力。

（3）臺式機和筆記本電腦

臺式機和筆記本電腦呈現出我們更為熟悉的安全配置挑戰。管理員必須確保已安裝正確的程序、補丁和病毒庫。但是，我們之前看到的很多問題也出現在這個領域，包括政策沖突。但是，問題的大小是不同的。

第一個問題是有一個新的用戶：計算機的授權用戶，他把計算機視為個人專用設備，經常把它們用于非官方的目的。這常常包括忽視官方政策。因此確保臺式機和筆記本電腦配置的機制必須解決員工不合作、甚至故意的不當行為。第二個問題是補丁下發的時間必須被控制。補丁通常與基本應用程序不兼容。那么正確的安全配置必須能夠防止補丁的非授權安裝。

（4）服務器

服務器配置在很多方面要簡單得多。服務器的所有者通常是系統管理員，他們具有專業的知識并且能夠理解安全配置策略。但是補丁的下發時間仍然必須控制;另外，他們還面臨著不同的問題：異質性。組織內的桌面機器往往非常相似。大多數人需要的應用程序多數是一樣的;但是在服務器上差別就很大。當然，Web服務器需要一個Web服務器守護進程。取決于所提供的網頁的性質，它們可能還需要數據庫，Perl或PHP解釋器，Wiki等。對這些中的任何一個的安全配置都是棘手的;服務器的配置管理系統（或人員）必須能夠處理這些情況。也就是說，它首先必須知道哪些組件適用于哪些服務器;其次，它必須知道如何將必要的安全配置與服務器特定的參數相結合。例如，Web服務器必須配置文件根目錄，有關執行CGI或ASP腳本的策略、密鑰和證書、訪問控制策略等。在不同的服務器上情況是不同的，但它們是對于安全來說都非常重要。

（5）PDA

對于組織而言，最新的配置挑戰是PDA或“智能手機”。這些設備通常是個人擁有的，但用于商業目的，如檢查電子郵件。再如蘋果的iPhone，最初并沒有考慮公司的需求：

許多IT組織已經禁止使用iPhone，因其無法強制員工用密碼保護他們的iPhone，并且如果設備被盜或丟失，他們不能從遠程擦除敏感的企業數據。另外，他們認為iPhone不支持許多企業使用的軟件，并且只能在一個蜂窩運營商的網絡上運行。目前我們還不清楚如何管理這些設備的配置，但是當他們進入公司網絡時，就必須接受相應的管理。

3 案例分析

3.1數據庫

如前所述，第一個原則是所有的配置都應該是以數據庫為中心的（如圖1）。所有相關信息，無論是任何物理硬件的位置，還是管理分配的參數（例如分配給給定用戶的IP地址）都應記錄在數據庫中。所有更改必須記錄在數據庫中;如果實際的物理配置不同，那么根據定義它是錯誤的。

圖1 以數據庫為中心的配置管理系統示意圖

這種方法有很多優點。最突出的是正確性，另一個重要的優勢是長期的成本節約。雖然構建、運行和管理這些基礎架構會花費一些成本，但它可以節省運營開支。其還有一個重要的安全優勢是響應能力：如果發生安全事件，新配置可以很快地推送到所有節點。例如，當許多ISP通過其路由器上的訪問控制列表阻止UDP端口1434時，就能停止Slammer蠕蟲的傳播。

3.2編譯

編譯過程與普通編程語言相似，但是，程序本身是非常不同的。在這種環境下，每個設備類型都有一個單獨的“主程序”，稱為設備列表，例如路由器或交換機。另外，由于必須支持來自不同廠商的不同型號的設備，所以存在用于不同設備的配置模板。還有一些特定配置細節片段的模板，如BGP對等體，SONET上的數據包（POS）接口等。在設備列表驅動生成的過程中，它會依次查找數據庫中的BGP對等體，接口詳細信息等，并使用這些數據驅動合適的片段模板以生成配置。包含模板的示例代碼段如下所示：

printf (POLICY "policy-statement peer-%d { ", $AS ); printf (POLICY " term ok { ");

printf (POLICY " from { ");

foreach $PREFIX (@PFX) {

printf (POLICY "route-filter $PREFIX exact; ");

}

printf (POLICY "} ");

printf (POLICY "then accept; ");

printf (POLICY "} ");

printf (POLICY "term final { ");

printf (POLICY "then reject ");

printf (POLICY "} ");

printf (POLICY " } ");

printf (PEERS " neighbor %s { ", $IP); printf (PEERS " peer-as $AS; ");

if ( $MD5 ne "NONE" ) {

printf (PEERS " authentication-key "%s"; ", $MD5);

}

printf (PEERS " import [ no-bogons dampening peer-%d ]; ",

$AS);

printf (PEERS " } ");

當這段模板代碼運行在圖2所示的數據庫上時，它產生如下的輸出：

圖2 示例數據庫摘錄

neighbor 191.42.180.10{

peer-as 6666;

import [ no-bogons dampening peer-6666 ];

}

neighbor 191.42.180.12{

peer-as 1234;

authentication-key "fnardle";

import [ no-bogons dampening peer-1234 ];

}

neighbor 191.42.180.13{

peer-as 1243;

authentication-key "fnoofle";

import [ no-bogons dampening peer-1243 ];

}

neighbor 191.42.180.22{

peer-as 1423;

authentication-key "fnuffle";

import [ no-bogons dampening peer-1423 ];

}

除了特定于提供者的數據庫以外，公共數據庫（Internet Routing Registry）也被用作有關網絡拓撲和前綴分配的信息來源，用以創建路由器的ACL。

許多設備具有必須容納的操作特性。例如，當被要求完全重新加載配置時，一些設備重置一些或全部子系統;例如許多Cisco路由器重置BGP會話，即使沒有任何關于BGP的改變）。因此，生成系統通常會生成一個“diff”文件，只需要將更改推送到設備。

由于推向設備的結果可能會跟預期的不一樣，因此通常在改變設備配置之前幾小時自動向管理員發送電子郵件，并要求最后的確認。這個過程通常是每天進行的，但是周期和時間因供應商的不同而異，并且跨越地理和拓撲結構。一個大型的ISP會傾向于在整個網絡中緩慢地進行更改。

偶爾，緊急修復必須被推送到一個或多個設備。管理系統必須能夠立即重啟和推送配置。工程師更改數據庫條目以表示所需的更改，按下按鈕以生成新配置，然后檢查它是否有錯誤，最后通知系統將其推送到設備。

盡管我們不知道有哪些ISP實際執行此操作，但基于編譯的方法可以輕松使用更復雜的機制來驗證和構建配置。

3.3監控

當設備配置完全生成時，配置的正式版本位于管理系統上，而不是設備上（圖3）。這意味著設備配置不應該意外改變。為了驗證這一點，可以使用一些工具，例如rancid（http://shrubbery.net/rancid/），它們用于定期從設備上獲取運行配置（傳統上每小時一次），將其存檔，如果發現不同于以前的或規范的配置就會自動向工程師發送電子郵件。

圖3 配置監控系統結構示意圖

rancid只是簡單的用來收集和區分來自所有設備的運行配置，它不一定與網絡數據庫或配置生成系統相關聯。

當然，外部人員造成的配置改變是一種侵入的形式。這意味著可以使用標準的入侵檢測和跟蹤技術，可以跟蹤未經授權更改的機器的IP地址（當然，這是假設網元或連接到它的控制臺服務器做了足夠的日志記錄，本身就是一個重要的安全要求）。此外，授權配置與入侵者安裝的配置之間的差異可以給出有價值的線索目標和動機。

4 結論

成功管理安全配置需要三個要素：明確的政策;準確了解所有計算機和網絡元素;適當的管理軟件?？梢钥隙ǖ氖?，所有這些要素都是其他類型的配置管理所需要的。但是，在安全設置中，故障可能會導致遠遠超出一個設備或系統的故障。因此，配置管理對網絡安全至關重要。根據工作經驗我們斷言，即使在中等規模的網絡環境中，也不應該完全依靠手工管理配置，這樣會產生太多的錯誤。

[1]J.Postel and J.Reynolds,File transfer protocol, Intern et Engineering Task Force,RFC 959,Oct.1985.[Online].Av ailable:http://www.rfceditor.org/rfc/rfc959.txt.

[2]D.Martin,S. Rajagopalan, and A. D. Rubin,Blocking Java applets at the firewall,Proc. Internet Society Symposium on Network and Distributed System Security,1997.

[3]A.Mayer,A.Wool,and E. Ziskind,Fang:A firewall analysis engine,in Proc. IEEE Symposium on Security and Privacy, 2000.

[4]Worldwide Infrastructure Security Report. Arbor Networks,2007,vol.III.[Online]. Available:http://www.harborn etworks.com/report..