Apache 安全設置

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

保持最新

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

當然，大多數(shù)情況下Web服務器受到攻擊，并不是因為HTTP Server代碼中存在問題。相反，它來自附加代碼，CGI腳本或底層操作系統(tǒng)中的問題。因此，您必須了解系統(tǒng)中所有軟件的問題和更新。

拒絕服務(DoS)攻擊

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

通常，最有效的反DoS工具將是防火墻或其他操作系統(tǒng)配置。例如，大多數(shù)防火墻可以配置為限制來自任何單個IP地址或網(wǎng)絡的同時連接數(shù)，從而防止一系列簡單攻擊。當然，這對分布式拒絕服務攻擊(DDoS)沒有幫助。

還有一些Apache HTTP Server配置設置可以幫助緩解問題：

• RequestReadTimeout指令允許限制客戶端發(fā)送請求所花費的時間。
• 應該在受到DoS攻擊的站點上降低TimeOut指令。將其設置為低至幾秒可能是合適的。由于TimeOut當前用于多個不同的操作，因此將其設置為較低值會導致長時間運行的CGI腳本出現(xiàn)問題。
• KeepAliveTimeout指令也可能會在受到DoS攻擊的網(wǎng)站上降低。有些網(wǎng)站甚至通過KeepAlive完全關閉了Keepalive，這當然還有其他性能上的缺點。
• 應檢查其他模塊提供的各種超時相關指令的值。
• 應仔細配置LimitRequestBody，LimitRequestFields，LimitRequestFieldSize，LimitRequestLine和LimitXMLRequestBody指令，以限制客戶端輸入觸發(fā)的資源消耗。
• 在支持它的操作系統(tǒng)上，確保使用AcceptFilter指令將部分請求處理卸載到操作系統(tǒng)。這在Apache httpd中默認是活動的，但可能需要重新配置內(nèi)核。
• 調(diào)整MaxRequestWorkers指令以允許服務器處理最大數(shù)量的并發(fā)連接，而不會耗盡資源。
• 使用線程mpm可以讓您處理更多的同時連接，從而減輕DoS攻擊。此外，事件mpm使用異步處理來避免將線程用于每個連接。由于OpenSSL庫的性質(zhì)，事件mpm當前與mod_ssl和其他輸入過濾器不兼容。在這些情況下，它會回落到工人mpm的行為。
• 通過http://modules.apache.org/可以使用許多第三方模塊，這些模塊可以限制某些客戶端行為，從而緩解DoS問題。

ServerRoot目錄的權(quán)限

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

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
Shell

假設/，/usr和/usr/local只能由root用戶修改。安裝httpd可執(zhí)行文件時，應確保它受到類似的保護：

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
Shell

您可以創(chuàng)建一個可由其他用戶修改的htdocs子目錄 - 因為root從不執(zhí)行任何文件，并且不應該在那里創(chuàng)建文件。

如果您允許非root用戶修改root執(zhí)行或?qū)懭氲娜魏挝募敲创蜷_系統(tǒng)以進行root妥協(xié)。例如，有人可以替換httpd二進制文件，以便下次啟動它時，它將執(zhí)行一些任意代碼。如果logs目錄是可寫的(由非root用戶)，則有人可以使用符號鏈接將日志文件替換為某個其他系統(tǒng)文件，然后root可能會使用任意數(shù)據(jù)覆蓋該文件。如果日志文件本身是可寫的(由非root用戶)，那么有人可能能夠用偽造的數(shù)據(jù)覆蓋日志本身。

服務器端包含

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

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

SSI文件通常也會帶來與CGI腳本相關的風險。使用exec cmd元素，啟用SSI的文件可以在用戶和Apache運行的組的權(quán)限下執(zhí)行任何CGI腳本或程序，如httpd.conf中所配置的那樣。

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

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

為具有.html或.html擴展名的文件啟用SSI可能很危險。在共享或高流量的服務器環(huán)境中尤其如此。啟用SSI的文件應具有單獨的擴展名，例如傳統(tǒng)的.shtml。這有助于將服務器負載降至最低，并可以更輕松地管理風險。

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

CGI腳本

首先，必須始終記住，信任CGI腳本/程序的編寫者或在CGI中發(fā)現(xiàn)潛在安全漏洞的能力，無論這些漏洞是故意的還是偶然的。CGI腳本可以使用Web服務器用戶的權(quán)限在您的系統(tǒng)上運行基本上任意的命令，因此如果不仔細檢查它們會非常危險。

所有CGI腳本都將作為同一個用戶運行，因此它們有可能(意外或故意)與其他腳本沖突，例如 用戶A討厭用戶B，因此他將腳本寫入垃圾用戶B的CGI數(shù)據(jù)庫。一個可用于允許腳本作為不同用戶運行的程序是suEXEC，它包含在Apache的1.2版本中，并且是從Apache服務器代碼中的特殊鉤子調(diào)用的。另一種流行的方法是使用CGIWrap。

非腳本別名CGI

只有在以下情況下才允許用戶在任何目錄中執(zhí)行CGI腳本：

• 您信任用戶不要編寫會故意或意外地將系統(tǒng)暴露給攻擊的腳本。
• 您認為所在站點的安全性在其他方面非常弱，以至于使一個潛在的漏洞變得無關緊要。
• 您沒有用戶，也沒有人訪問您的服務器。

腳本別名CGI

將CGI限制為特殊目錄可使管理員控制進入這些目錄的內(nèi)容。這不可避免地比非腳本別名CGI更安全，但僅當具有對目錄的寫訪問權(quán)限的用戶可信或管理員愿意測試每個新的CGI腳本/程序以尋找潛在的安全漏洞時。

大多數(shù)站點都選擇此選項而不是非腳本別名CGI方法。

其他動態(tài)內(nèi)容來源

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

動態(tài)內(nèi)容安全性

在設置動態(tài)內(nèi)容時，例如：mod_php，mod_perl或mod_python，許多安全注意事項都超出了httpd本身的范圍，您需要查閱這些模塊的文檔。例如，PHP允許設置安全模式，默認情況下最常禁用安全模式。另一個例子是Suhosin，這是一個更安全的PHP插件。

在Apache級別，mod_security模塊可以被視為HTTP防火墻，如果配置得非常好，可以幫助增強動態(tài)內(nèi)容安全性。

保護系統(tǒng)設置

要運行非常緊湊的船舶，需要阻止用戶設置.htaccess文件，這些文件可以覆蓋已配置的安全功能。這是一種方法。

在服務器配置文件中，加入以下內(nèi)容 -

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

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

注意，此設置是Apache 2.3.9以上版本的默認設置。

默認保護服務器文件

Apache的一個方面是默認訪問的特征。也就是說，除非采取措施進行更改，否則如果服務器可以通過常規(guī)URL映射規(guī)則找到文件，則可以將其提供給客戶端。

例如，請考慮以下示例：

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

這將允許客戶端遍歷整個文件系統(tǒng)。要解決此問題，請將以下塊添加到服務器的配置中：

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

這將禁止默認訪問文件系統(tǒng)位置。添加適當?shù)哪夸泬K以僅允許在希望的那些區(qū)域中進行訪問。例如：

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

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

同時要小心使用UserDir指令玩游戲; 將它設置為./會對root產(chǎn)生相同的效果，就像上面的第一個例子一樣。強烈建議在服務器配置文件中包含以下行：

UserDir disabled root
Shell

查看日志

要及時了解服務器的實際情況，需要檢查日志文件。即使日志文件僅報告已發(fā)生的事件，它們也會讓您了解針對服務器的攻擊，并用于檢查是否存在必要的安全級別。

參考幾個例子：

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

第一個示例將列出嘗試利用Apache Tomcat source.jsp格式錯誤的請求信息泄露漏洞的攻擊數(shù)量，第二個示例將列出最后被拒絕的十個客戶端，例如：

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

如上所見，日志文件僅報告已發(fā)生的情況，因此如果客戶端能夠訪問.htpasswd文件，會看到類似于：

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

在訪問日志中，可能在服務器配置文件中注釋掉以下內(nèi)容：

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

合并配置部分

配置部分的合并是復雜的，有時是指令特定的。在創(chuàng)建合并指令的依賴關系時，始終要測試您的更改。

對于未實現(xiàn)任何合并邏輯的模塊，例如mod_access_compat，后面部分中的行為取決于后一部分是否具有來自模塊的任何指令。繼承配置，直到進行更改，此時配置被替換而不是合并。