Nginx與安全有關的幾個配置

經常會有針對某個版本的nginx安全漏洞出現，隐藏nginx版本号就成了主要的安全優化手段之一，當然最重要的是及時更新修複漏洞

ssl on： 開啟https

ssl_certificate： 配置nginx ssl證書的路徑

ssl_certificate_key： 配置nginx ssl證書key的路徑

ssl_protocols： 指定用戶端建立連接配接時使用的ssl協定版本，如果不需要相容TSLv1，直接去掉即可

ssl_ciphers： 指定用戶端連接配接時所使用的加密算法，你可以再這裡配置更高安全的算法

白名單配置

上邊表示隻允許192.168.1.0/24網段的主機通路，拒絕其他所有

也可以寫成黑名單的方式禁止某些位址通路，允許其他所有，例如

更多的時候用戶端請求會經過層層代理，我們需要通過​<code>​$http_x_forwarded_for​</code>​來進行限制，可以這樣寫

關于賬号認證​​《Nginx的幾個常用配置和技巧》​​文章中已有詳細介紹，這裡不贅述

​<code>​$request_method​</code>​能夠擷取到請求nginx的method

配置隻允許GET\POST方法通路，其他的method傳回405

可能有一些不法者會利用wget/curl等工具掃描我們的網站，我們可以通過禁止相應的user-agent來簡單的防範

Nginx的444狀态比較特殊，如果傳回444那麼用戶端将不會收到服務端傳回的資訊，就像是網站無法連接配接一樣

valid_referers： 驗證referer，其中​<code>​none​</code>​允許referer為空，​<code>​blocked​</code>​允許不帶協定的請求，除了以上兩類外僅允許referer為www.ops-coffee.cn或ops-coffee.cn時通路images下的圖檔資源，否則傳回403

當然你也可以給不符合referer規則的請求重定向到一個預設的圖檔，比如下邊這樣

可以通過​<code>​ngx_http_limit_conn_module​</code>​子產品限制一個IP的并發連接配接數

limit_conn_zone： 設定儲存各個鍵(例如​<code>​$binary_remote_addr​</code>​)狀态的共享記憶體空間的參數，zone=空間名字:大小

大小的計算與變量有關，例如​<code>​$binary_remote_addr​</code>​變量的大小對于記錄IPV4位址是固定的4 bytes，而記錄IPV6位址時固定的16 bytes，存儲狀态在32位平台中占用32或者64 bytes，在64位平台中占用64 bytes。1m的共享記憶體空間可以儲存大約3.2萬個32位的狀态，1.6萬個64位的狀态

limit_conn： 指定一塊已經設定的共享記憶體空間(例如name為​<code>​ops​</code>​的空間)，以及每個給定鍵值的最大連接配接數

上邊的例子表示同一IP同一時間隻允許10個連接配接

當有多個​<code>​limit_conn​</code>​指令被配置時，所有的連接配接數限制都會生效

上邊的配置不僅會限制單一IP來源的連接配接數為10，同時也會限制單一虛拟伺服器的總連接配接數為2000

緩沖區溢出攻擊 是通過将資料寫入緩沖區并超出緩沖區邊界和重寫記憶體片段來實作的，限制緩沖區大小可有效防止

client_body_buffer_size： 預設8k或16k，表示用戶端請求body占用緩沖區大小。如果連接配接請求超過緩存區指定的值，那麼這些請求實體的整體或部分将嘗試寫入一個臨時檔案。

client_header_buffer_size： 表示用戶端請求頭部的緩沖區大小。絕大多數情況下一個請求頭不會大于1k，不過如果有來自于wap用戶端的較大的cookie它可能會大于 1k，Nginx将配置設定給它一個更大的緩沖區，這個值可以在​<code>​large_client_header_buffers​</code>​裡面設定

client_max_body_size： 表示用戶端請求的最大可接受body大小，它出現在請求頭部的Content-Length字段， 如果請求大于指定的值，用戶端将收到一個"Request Entity Too Large" (413)錯誤，通常在上傳檔案到伺服器時會受到限制

large_client_header_buffers 表示一些比較大的請求頭使用的緩沖區數量和大小，預設一個緩沖區大小為作業系統中分頁檔案大小，通常是4k或8k，請求字段不能大于一個緩沖區大小，如果用戶端發送一個比較大的頭，nginx将傳回"Request URI too large" (414)，請求的頭部最長字段不能大于一個緩沖區，否則伺服器将傳回"Bad request" (400)

同時需要修改幾個逾時時間的配置

client_body_timeout： 表示讀取請求body的逾時時間，如果連接配接超過這個時間而用戶端沒有任何響應，Nginx将傳回"Request time out" (408)錯誤

client_header_timeout： 表示讀取用戶端請求頭的逾時時間，如果連接配接超過這個時間而用戶端沒有任何響應，Nginx将傳回"Request time out" (408)錯誤

keepalive_timeout： 參數的第一個值表示用戶端與伺服器長連接配接的逾時時間，超過這個時間，伺服器将關閉連接配接，可選的第二個參數參數表示Response頭中Keep-Alive: timeout=time的time值，這個值可以使一些浏覽器知道什麼時候關閉連接配接，以便伺服器不用重複關閉，如果不指定這個參數，nginx不會在應Response頭中發送Keep-Alive資訊

send_timeout： 表示發送給用戶端應答後的逾時時間，Timeout是指沒有進入完整established狀态，隻完成了兩次握手，如果超過這個時間用戶端沒有任何響應，nginx将關閉連接配接

通過以下設定可有效防止XSS攻擊

X-Frame-Options： 響應頭表示是否允許浏覽器加載frame等屬性，有三個配置​<code>​DENY​</code>​禁止任何網頁被嵌入,​<code>​SAMEORIGIN​</code>​隻允許本網站的嵌套,​<code>​ALLOW-FROM​</code>​允許指定位址的嵌套

X-XSS-Protection： 表示啟用XSS過濾（禁用過濾為​<code>​X-XSS-Protection: 0​</code>​），​<code>​mode=block​</code>​表示若檢查到XSS攻擊則停止渲染頁面

X-Content-Type-Options： 響應頭用來指定浏覽器對未指定或錯誤指定​<code>​Content-Type​</code>​資源真正類型的猜測行為，nosniff 表示不允許任何猜測

在通常的請求響應中，浏覽器會根據​<code>​Content-Type​</code>​來分辨響應的類型，但當響應類型未指定或錯誤指定時，浏覽會嘗試啟用MIME-sniffing來猜測資源的響應類型，這是非常危險的

例如一個.jpg的圖檔檔案被惡意嵌入了可執行的js代碼，在開啟資源類型猜測的情況下，浏覽器将執行嵌入的js代碼，可能會有意想不到的後果

另外還有幾個關于請求頭的安全配置需要注意

Content-Security-Policy： 定義頁面可以加載哪些資源，

上邊的配置會限制所有的外部資源，都隻能從目前域名加載，其中​<code>​default-src​</code>​定義針對所有類型資源的預設加載政策，​<code>​self​</code>​允許來自相同來源的内容

Strict-Transport-Security： 會告訴浏覽器用HTTPS協定代替HTTP來通路目标站點

上邊的配置表示當使用者第一次通路後，會傳回一個包含了​<code>​Strict-Transport-Security​</code>​響應頭的字段，這個字段會告訴浏覽器，在接下來的31536000秒内，目前網站的所有請求都使用https協定通路，參數​<code>​includeSubDomains​</code>​是可選的，表示所有子域名也将采用同樣的規則