安全性提示

保持更新

Apache HTTP Server 在安全性方面擁有良好的記錄，並且開發者社群也非常關注安全性問題。但是，軟體在發布後不可避免地會發現一些大小問題。因此，隨時了解軟體更新至關重要。如果您是直接從 Apache 取得 HTTP Server 版本，我們強烈建議您訂閱 Apache HTTP Server 公告列表，以便隨時了解新版本和安全性更新。大多數第三方 Apache 軟體經銷商都提供類似的服務。

當然，大多數情況下，網路伺服器遭到入侵並不是因為 HTTP Server 程式碼本身的問題。而是來自附加程式碼、CGI 腳本或底層作業系統的問題。因此，您必須隨時了解系統上所有軟體的問題和更新。

阻斷服務 (DoS) 攻擊

所有網路伺服器都可能遭受阻斷服務攻擊，這些攻擊試圖透過佔用伺服器資源來阻止對用戶端的回應。完全阻止此類攻擊是不可能的，但您可以採取某些措施來減輕它們造成的問題。

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

還有一些 Apache HTTP Server 組態設定可以幫助減輕問題

• RequestReadTimeout 指令允許限制用戶端傳送請求所需的時間。
• 對於遭受 DoS 攻擊的網站，應降低 TimeOut 指令的值。將其設定為低至幾秒鐘可能是適當的。由於 TimeOut 目前用於幾個不同的操作，將其設定為過低的值會導致長時間執行的 CGI 腳本出現問題。
• 對於遭受 DoS 攻擊的網站，也可以降低 KeepAliveTimeout 指令的值。有些網站甚至透過 KeepAlive 完全關閉 KeepAlive，這當然會對效能造成其他影響。
• 應檢查其他模組提供的各種逾時相關指令的值。
• 應仔細組態 LimitRequestBody、LimitRequestFields、LimitRequestFieldSize、LimitRequestLine 和 LimitXMLRequestBody 指令，以限制用戶端輸入觸發的資源消耗。
• 在支援的作業系統上，請確保使用 AcceptFilter 指令將部分請求處理卸載到作業系統。這在 Apache httpd 中預設為啟用狀態，但可能需要重新組態您的核心。
• 調整 MaxRequestWorkers 指令，以允許伺服器處理最大數量的同時連線而不耗盡資源。另請參閱效能調整文件。
• 使用執行緒 mpm 可以讓您處理更多同時連線，從而減輕 DoS 攻擊。此外，event mpm 使用非同步處理來避免為每個連線分配一個執行緒。
• 有許多第三方模組可用於限制某些用戶端行為，從而減輕 DoS 問題。

ServerRoot 目錄的權限

在典型操作中，Apache 由 root 使用者啟動，並切換到 User 指令定義的使用者來服務點擊。與 root 執行的任何命令一樣，您必須注意保護它不被非 root 使用者修改。不僅檔案本身必須只能由 root 寫入，目錄和所有目錄的父目錄也必須如此。例如，如果您選擇將 ServerRoot 放在 /usr/local/apache 中，那麼建議您使用如下命令以 root 身份建立該目錄

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

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

如果您允許非 root 使用者修改 root 執行或寫入的任何檔案，那麼您的系統就會面臨 root 遭到入侵的風險。例如，有人可能會替換 httpd 二進制檔案，這樣下次您啟動它時，它就會執行一些任意程式碼。如果日誌目錄可寫入（由非 root 使用者），則有人可能會將日誌檔案替換為指向某些其他系統檔案的符號連結，然後 root 可能會用任意資料覆蓋該檔案。如果日誌檔案本身可寫入（由非 root 使用者），則有人可能會用虛假資料覆蓋日誌本身。

伺服器端包含 (SSI)

伺服器端包含 (SSI) 給伺服器管理員帶來了一些潛在的安全風險。

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

SSI 檔案也存在與 CGI 腳本相關的相同風險。使用 exec cmd 元素，啟用 SSI 的檔案可以使用 Apache 執行的使用者和群組的權限執行任何 CGI 腳本或程式，如 httpd.conf 中所組態。

有一些方法可以在利用 SSI 檔案提供的優點的同時增強其安全性。

為了隔離任性 SSI 檔案可能造成的損害，伺服器管理員可以按照 CGI 總論 一節中的說明啟用 suexec。

為副檔名為 .html 或 .htm 的檔案啟用 SSI 可能很危險。在共用或流量大的伺服器環境中尤其如此。啟用 SSI 的檔案應使用單獨的副檔名，例如傳統的 .shtml。這有助於將伺服器負載保持在最低限度，並允許更輕鬆地管理風險。

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

CGI 總論

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

所有 CGI 腳本都將以同一個使用者身份執行，因此它們有可能（意外地或故意地）與其他腳本發生衝突，例如使用者 A 討厭使用者 B，因此他編寫了一個腳本來破壞使用者 B 的 CGI 資料庫。一個允許腳本以不同使用者身份執行的程式是 suEXEC，它從 1.2 版開始包含在 Apache 中，並從 Apache 伺服器程式碼中的特殊掛鉤中呼叫。另一種流行的方法是使用 CGIWrap。

非腳本別名 CGI

僅當滿足以下條件時，才應考慮允許使用者在任何目錄中執行 CGI 腳本

• 您相信您的使用者不會編寫會故意或意外地將您的系統暴露於攻擊之下的腳本。
• 您認為您網站上的安全性在其他方面非常薄弱，以至於再多一個潛在漏洞也無關緊要。
• 您沒有使用者，而且從來沒有人訪問過您的伺服器。

腳本別名 CGI

將 CGI 限制在特殊目錄中，管理員可以控制進入這些目錄的內容。這不可避免地比非腳本別名 CGI 更安全，但前提是具有對目錄寫入權限的使用者是受信任的，或者管理員願意測試每個新的 CGI 腳本/程式是否存在潛在的安全漏洞。

大多數網站都選擇這種方式，而不是非腳本別名 CGI 方式。

其他動態內容來源

嵌入式腳本選項，例如 mod_php、mod_perl、mod_tcl 和 mod_python，會以伺服器本身的身分執行（請參閱 使用者 指令），因此這些引擎執行的腳本可能會存取伺服器使用者可以存取的任何內容。某些腳本引擎可能會提供限制，但最好還是安全起見，假設沒有。

動態內容安全性

設定動態內容時，例如 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 映射規則找到檔案，它就可以將其提供給用戶端。

例如，請考慮以下範例

這將允許用戶端瀏覽整個檔案系統。若要解決此問題，請將以下區塊新增至伺服器的設定中

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

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

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

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

還要注意使用 UserDir 指令的遊戲規則；將其設定為類似 ./ 的內容，對於 root 使用者來說，將會產生與上述第一個範例相同的效果。我們強烈建議您在伺服器設定檔中包含以下這一行

UserDir disabled root

監控您的日誌

若要隨時掌握針對伺服器實際發生的事情，您必須檢查 日誌檔案。即使日誌檔案僅報告已發生的事件，它們也會讓您瞭解對伺服器發起了哪些攻擊，並允許您檢查是否存在必要的安全級別。

幾個例子

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

如您所見，日誌檔案僅報告已發生的事件，因此如果用戶端能夠存取 .htpasswd 檔案，您會在 存取日誌 中看到類似以下的內容

這表示您可能在伺服器設定檔中將以下內容註解掉了

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

設定區塊的合併

設定區塊的合併很複雜，有時還取決於特定指令。在建立對指令合併方式的依賴關係時，請務必測試您的變更。

對於未實作任何合併邏輯的模組，例如 mod_access_compat，後續區塊中的行為取決於後續區塊中是否有來自該模組的任何指令。設定會被繼承，直到進行變更為止，此時設定會被_取代_而不是合併。