有關設置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，後面部分中的行為取決於後一部分是否具有來自模組的任何指令。繼承配置，直到進行更改，此時配置被替換而不是合併。