Apache教學 » Apache安全設定

Apache安全設定

有關設定Web伺服器的安全問題的一些提示和技巧。一些建議通用的，其他建議特定於Apache版本。

保持最新

Apache HTTP Server具有良好的安全記錄和高度關注安全問題的開發人員社群。但是，在軟體發布之後，軟體中會發現一些小問題或大問題是不可避免的。因此，了解軟體更新至關重要。如果是直接從Apache獲得了HTTP Server的版本，我們強烈建議您訂閱Apache HTTP Server公告列表，以便隨時了解新版本和安全更新。大多數Apache軟體的第三方分銷商都提供類似的服務。

當然，大多數情況下Web伺服器受到攻擊，並不是因為HTTP Server程式碼中存在問題。相反，它來自附加程式碼，CGI指令碼或底層作業系統中的問題。因此，您必須了解系統中所有軟體的問題和更新。

拒絕服務(DoS)攻擊

所有網路伺服器都可能遭受拒絕服務攻擊，這些攻擊試圖通過佔用伺服器的資源來阻止對用戶端的響應。不可能完全阻止此類攻擊，但可以做某些事情來緩解這些問題。

通常，最有效的反DoS工具將是防火牆或其他作業系統組態。例如，大多數防火牆可以組態為限制來自任何單個IP地址或網路的同時連線數，從而防止一系列簡單攻擊。當然，這對分散式拒絕服務攻擊(DDoS)沒有幫助。

還有一些Apache HTTP Server組態設定可以幫助緩解問題：

  • RequestReadTimeout指令允許限制用戶端傳送請求所花費的時間。
  • 應該在受到DoS攻擊的站點上降低TimeOut指令。將其設定為低至幾秒可能是合適的。由於TimeOut當前用於多個不同的操作，因此將其設定為較低值會導致長時間執行的CGI指令碼出現問題。
  • KeepAliveTimeout指令也可能會在受到DoS攻擊的網站上降低。有些網站甚至通過KeepAlive完全關閉了Keepalive，這當然還有其他效能上的缺點。
  • 應檢查其他模組提供的各種超時相關指令的值。
  • 應仔細組態LimitRequestBody，LimitRequestFields，LimitRequestFieldSize，LimitRequestLine和LimitXMLRequestBody指令，以限制用戶端輸入觸發的資源消耗。
  • 在支援它的作業系統上，確保使用AcceptFilter指令將部分請求處理解除安裝到作業系統。這在Apache httpd中預設是活動的，但可能需要重新組態核心。
  • 調整MaxRequestWorkers指令以允許伺服器處理最大數量的並行連線，而不會耗盡資源。
  • 使用執行緒mpm可以讓您處理更多的同時連線，從而減輕DoS攻擊。此外，事件mpm使用非同步處理來避免將執行緒用於每個連線。由於OpenSSL庫的性質，事件mpm當前與mod_ssl和其他輸入過濾器不相容。在這些情況下，它會回落到工人mpm的行為。
  • 通過http://modules.apache.org/可以使用許多第三方模組，這些模組可以限制某些用戶端行為，從而緩解DoS問題。

ServerRoot目錄的許可權

在典型操作中，Apache由root使用者啟動，並切換到User指令定義的使用者以提供命中。與root執行的任何命令一樣，必須注意保護它免受非root使用者的修改。檔案本身不僅必須只能由root寫入，而且目錄和所有目錄的父項也必須可寫。例如，如果選擇將ServerRoot放在/usr/local/apache中，則建議以root身份建立該目錄，其命令如下：

mkdir /usr/local/apache 
cd /usr/local/apache 
mkdir bin conf logs 
chown 0 . bin conf logs 
chgrp 0 . bin conf logs 
chmod 755 . bin conf logs

假設/，/usr和/usr/local只能由root使用者修改。安裝httpd可執行檔案時，應確保它受到類似的保護：

cp httpd /usr/local/apache/bin 
chown 0 /usr/local/apache/bin/httpd 
chgrp 0 /usr/local/apache/bin/httpd 
chmod 511 /usr/local/apache/bin/httpd

您可以建立一個可由其他使用者修改的htdocs子目錄 - 因為root從不執行任何檔案，並且不應該在那裡建立檔案。

如果您允許非root使用者修改root執行或寫入的任何檔案，那麼開啟系統以進行root妥協。例如，有人可以替換httpd二進位制檔案，以便下次啟動它時，它將執行一些任意程式碼。如果logs目錄是可寫的(由非root使用者)，則有人可以使用符號連結將紀錄檔檔案替換為某個其他系統檔案，然後root可能會使用任意資料覆蓋該檔案。如果紀錄檔檔案本身是可寫的(由非root使用者)，那麼有人可能能夠用偽造的資料覆蓋紀錄檔本身。

伺服器端包含

伺服器端包含(SSI)為伺服器管理員提供了若干潛在的安全風險。

第一個風險是伺服器上的負載增加。無論檔案中是否包含任何SSI指令，所有啟用SSI的檔案都必須由Apache解析。雖然這種負載增加很小，但在共用伺服器環境中，它可能會變得很重要。

SSI檔案通常也會帶來與CGI指令碼相關的風險。使用exec cmd元素，啟用SSI的檔案可以在使用者和Apache執行的組的許可權下執行任何CGI指令碼或程式，如httpd.conf中所組態的那樣。

有一些方法可以增強SSI檔案的安全性，同時仍然利用它們提供的好處。

要隔離任意SSI檔案可能導致的損壞，伺服器管理員可以啟用suexec。

為具有.html或.html擴充套件名的檔案啟用SSI可能很危險。在共用或高流量的伺服器環境中尤其如此。啟用SSI的檔案應具有單獨的擴充套件名，例如傳統的.shtml。這有助於將伺服器負載降至最低，並可以更輕鬆地管理風險。

另一種解決方案是禁用從SSI頁面執行指令碼和程式的能力。要執行此操作，請在Options指令中將Includes替換為IncludesNOEXEC。請注意，如果這些指令碼位於ScriptAlias指令指定的目錄中，則使用者仍可以使用<--#include virtual="..." -->來執行CGI指令碼。

CGI指令碼

首先，必須始終記住，信任CGI指令碼/程式的編寫者或在CGI中發現潛在安全漏洞的能力，無論這些漏洞是故意的還是偶然的。CGI指令碼可以使用Web伺服器使用者的許可權在您的系統上執行基本上任意的命令，因此如果不仔細檢查它們會非常危險。

所有CGI指令碼都將作為同一個使用者執行，因此它們有可能(意外或故意)與其他指令碼衝突，例如 使用者A討厭使用者B，因此他將指令碼寫入垃圾使用者B的CGI資料庫。一個可用於允許指令碼作為不同使用者執行的程式是suEXEC，它包含在Apache的1.2版本中，並且是從Apache伺服器程式碼中的特殊勾點呼叫的。另一種流行的方法是使用CGIWrap。

非指令碼別名CGI

只有在以下情況下才允許使用者在任何目錄中執行CGI指令碼：

  • 您信任使用者不要編寫會故意或意外地將系統暴露給攻擊的指令碼。
  • 您認為所在站點的安全性在其他方面非常弱，以至於使一個潛在的漏洞變得無關緊要。
  • 您沒有使用者，也沒有人存取您的伺服器。

指令碼別名CGI

將CGI限制為特殊目錄可使管理員控制進入這些目錄的內容。這不可避免地比非指令碼別名CGI更安全，但僅當具有對目錄的寫存取許可權的使用者可信或管理員願意測試每個新的CGI指令碼/程式以尋找潛在的安全漏洞時。

大多數站點都選擇此選項而不是非指令碼別名CGI方法。

其他動態內容來源

作為伺服器本身的一部分執行的嵌入式指令碼選項，例如：mod_php，mod_perl，mod_tcl和mod_python，在伺服器本身的標識下執行(參見User指令)，因此這些引擎執行的指令碼可能存取任何內容 伺服器使用者可以。某些指令碼引擎可能會提供限制，但最好是安全而不是假設。

動態內容安全性

在設定動態內容時，例如：mod_php，mod_perl或mod_python，許多安全注意事項都超出了httpd本身的範圍，您需要查閱這些模組的文件。例如，PHP允許設定安全模式，預設情況下最常禁用安全模式。另一個例子是Suhosin，這是一個更安全的PHP外掛。

在Apache級別，mod_security模組可以被視為HTTP防火牆，如果組態得非常好，可以幫助增強動態內容安全性。

保護系統設定

要執行非常緊湊的船舶，需要阻止使用者設定.htaccess檔案，這些檔案可以覆蓋已組態的安全功能。這是一種方法。

在伺服器組態檔案中，加入以下內容 - 

<Directory "/">
    AllowOverride None
</Directory>

這可以防止在除特別啟用的目錄之外的所有目錄中使用.htaccess檔案。

注意，此設定是Apache 2.3.9以上版本的預設設定。

預設保護伺服器檔案

Apache的一個方面是預設存取的特徵。也就是說，除非採取措施進行更改，否則如果伺服器可以通過常規URL對映規則找到檔案，則可以將其提供給用戶端。

例如，請考慮以下範例：

# cd /; ln -s / public_html 
Accessing http://localhost/~root/

這將允許用戶端遍歷整個檔案系統。要解決此問題，請將以下塊新增到伺服器的組態中：

<Directory "/">
    Require all denied
</Directory>

這將禁止預設存取檔案系統位置。新增適當的目錄塊以僅允許在希望的那些區域中進行存取。例如：

<Directory "/usr/users/*/public_html">
    Require all granted
</Directory>
<Directory "/usr/local/httpd">
    Require all granted
</Directory>

特別注意Location和Directory指令的互動; 例如，即使<Directory "/">拒絕存取，<Location "/">指令也可能推翻它。

同時要小心使用UserDir指令玩遊戲; 將它設定為./會對root產生相同的效果，就像上面的第一個例子一樣。強烈建議在伺服器組態檔案中包含以下行：

UserDir disabled root

檢視紀錄檔

要及時了解伺服器的實際情況，需要檢查紀錄檔檔案。即使紀錄檔檔案僅報告已發生的事件，它們也會讓您了解針對伺服器的攻擊，並用於檢查是否存在必要的安全級別。

參考幾個例子：

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log 
grep "client denied" error_log | tail -n 10

第一個範例將列出嘗試利用Apache Tomcat source.jsp格式錯誤的請求資訊洩露漏洞的攻擊數量，第二個範例將列出最後被拒絕的十個用戶端，例如：

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

如上所見，紀錄檔檔案僅報告已發生的情況，因此如果用戶端能夠存取.htpasswd檔案，會看到類似於：

foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

在存取紀錄檔中，可能在伺服器組態檔案中註釋掉以下內容：

<Files ".ht*">
    Require all denied
</Files>

合併組態部分

組態部分的合併是複雜的，有時是指令特定的。在建立合併指令的依賴關係時，始終要測試您的更改。

對於未實現任何合併邏輯的模組，例如mod_access_compat，後面部分中的行為取決於後一部分是否具有來自模組的任何指令。繼承組態，直到進行更改，此時組態被替換而不是合併。