選擇網路伺服器軟體以確保安全
Nginx 是市場上相對較新的開源 Web 伺服器，最近引起了一些興趣，在過去幾年的一些基準測試中表現非常好。
在為可公開訪問的業務應用程序選擇伺服器軟體時，我一直在想，從安全的角度來看，使用可能缺乏普遍性的伺服器軟體（例如 Nginx）是否是不負責任的。
另一方面，Apache 擁有多年的公眾審查、許多已修復的漏洞和一個安全團隊。
以下是我對我的兩個候選伺服器的優勢的看法，它們在市場份額、社區和一般開發環境方面存在巨大差異。
Nginx的優勢
- **無處不在。**在我看來，不太容易成為目標和成為小玩家的混合有助於一些軟體產品成為目標攻擊的受害者的可能性降低。一個很好的例子是 Apple 的 Mac OS X 平台，與最近的 Window 相比，它的嘗試相對較少。
2009 年 6 月的 Netcraft 伺服器市場份額數據表明，競爭對手的 Nginx 和 Apache 市場份額分別為 4% 和 50%。
- **更小的程式碼庫，更少的錯誤。**這只是一個假設；我沒有查看任何一個程式碼庫，但假設程式碼與錯誤的比率相似，較小的程式碼庫可能會導致更少的漏洞利用。
根據 Ohloh 的說法，程式碼庫大小為 635:75，其中較大的是 Apache。我不確定這是否包括模組，但考慮到巨大的增量，它可能包括。（當然，這會導致一個非常錯誤的結論，因為如果您關注的是安全性，那麼您將只執行您需要的模組。）
阿帕奇優勢
- **安保團隊。**Apache 軟體基金會似乎擁有相當先進的安全基礎設施。
- **經驗。**多年來，Apache HTTP Server 項目已經看到了許多漏洞，毫無疑問，他們已經制定瞭如何最好地快速處理問題的策略。
- **無處不在。**這既可以是專業人士，也可以是騙子。這意味著更多地關注程式碼，但它沒有說明好眼與壞眼的比例。
- **到期。**正如我之前提到的，該項目經歷了無數次攻擊和大量公眾審查。
這可能會導致零日漏洞利用的風險略低，因為漏洞問題可能不太可能被遺漏。這也可能意味著新的漏洞利用將不那麼重要。
快速搜尋並沒有發現 Apache 是否接受過安全審計。
- **文件。**錯誤配置可能會創建攻擊向量。對於 Apache，這似乎不太可能，因為它提供了大量關於如何保護伺服器的出版物（書籍和文章等）。
- **安全模組的數量。**通過瀏覽這兩個伺服器的站點，我感覺 Apache 在安全增強模組中的數量遠遠超過 Nginx。
無處不在似乎是一把雙刃劍。普遍性的好壞可能不是線性關係（並且可能包括其他因素，例如您是否極易受到攻擊）。我非常懷疑是否有研究普遍存在對安全漏洞的影響，儘管我承認我嘗試過搜尋。
如果我們談論的是社交應用程序、新聞站點或在與業務應用程序分離的伺服器上提供服務的媒體，我可能不會對此感到疑惑。對於處理支付、個人資訊和信用卡號碼的應用程序，我目前的資訊傾向於 Apache。
由於我不是安全專家，而且我的想法沒有經過科學的收集，因此可能不是太具有決定性，因此我很感激任何關於哪些因素會影響這樣的決定的意見。如果沒有別的，這留給處於相同位置的其他人考慮。
nginx 託管著全球網站數量的百分之幾，因此它遠非晦澀難懂。那是數十萬甚至數百萬個站點，因此 nginx 足夠大，可以成為值得攻擊的目標。
nginx 已經出現了安全問題，開源社區已經向作者披露了漏洞，作者已經修復了這些漏洞。在更新日誌中搜尋“安全”，您會看到有一個工作流程： http: //nginx.net/CHANGES-0.6
所以 nginx 與 Apache 具有幾乎相同的過程來修復安全問題。它可能是一個較小的團隊，也不太正式，但它的工作方式大致相同。
從安全的角度來看，擁有一個小而緊湊的程式碼庫，以及乾淨簡單的架構是一項重大改進。更少的程式碼 = 統計上更少的錯誤。經驗表明，隨著程式碼庫變得越來越大，錯誤數量的增長速度超過了線性增長。假設程式碼與錯誤的比率相似，較小的程式碼庫將導致更少的漏洞利用。
由於 nginx 的使用者群較小，從安全形度來看是否不負責任？我會回答絕對不，nginx 是一個非常好的選擇，也是出於安全考慮。
然而，我建議以稍微不同的方式來看待 HTTP 伺服器的安全性。http 守護程序中存在緩衝區溢出問題，這可能導致對 http 守護程序本身的利用。對於大多數設計，通過使用諸如jails / croot /虛擬化之類的作業系統級工具來“容器化”http守護程序並限製成功攻擊的影響，可以相當容易地將其影響降至最低。
針對 Web 應用程序的攻擊可能更嚴重，也更常見，尤其是對於內部開發的 Web 應用程序，這些應用程序通常沒有經過專家的安全審計。範例是使用跨端腳本或 SQL 注入對使用者數據進行惡意操作、提取資金、竊取使用者名和密碼數據庫等。
Apache 在 webapp 安全領域有一個主要的好處，這個好處是第 3 方 mod_security 模組。可以把它想像成一個巨大的 HTTP 請求正則表達式引擎，它允許你對 HTTP 呼叫的任何部分進行模式匹配和過濾。這可用於顯著減少針對您自己的 webapp 程式碼的攻擊面。
對於具有安全意識的開源 webapp 堆棧，我可能會使用：
- 用於負載平衡的容器化 nginx 實例，位於 Web 伺服器前面的單獨物理或虛擬伺服器上，將 HTTP 請求代理到後端 Web 伺服器。
- 帶有 mod_security 的 Apache 用於網路伺服器。
你也可以用另一種方式來做——帶有 mod_security 的 Apache 在 nginx 網路伺服器的前端執行負載平衡。這主要是您希望 CPU 負載在哪裡的問題——使用 mod_security 的 HTTP 過濾需要相當多的 CPU 資源，因此帶有 mod_security 的 Apache 負載均衡器可能只能處理少數後端 Web 伺服器。如果負載均衡器是一個小型、快速的 nginx 實例，並且 Web 伺服器自己進行 mod_security 過濾，負載均衡器上的擁塞就會大大減少。
這為您提供了一個容器化的 HTTP 代理，作為公共 Internet 和您的 Web 應用程序之間的間接層，而 mod_security 作為您的 Web 應用程式碼前面的可擴展 HTTP 級防火牆。但是要為此做好準備，尤其是 mod_security，需要花費大量時間來設置並完全正常工作而不會產生不必要的副作用。