Nginx與安全有關的幾個配置

Nginx與安全有關的幾個配置

原創： 37丫37 運維咖啡吧 昨天

安全無小事，安全防範從nginx配置作起

上一篇文章《Nginx的幾個經常使用配置和技巧》收到了不錯的反饋，這裏再總結下nginx配置中與安全有關的一些配置

隱藏版本號

http {
    server_tokens off;
}

常常會有針對某個版本的nginx安全漏洞出現，隱藏nginx版本號就成了主要的安全優化手段之一，固然最重要的是及時升級修復漏洞

開啓HTTPS

server {
    listen 443;
    server_name ops-coffee.cn;

    ssl on;
    ssl_certificate /etc/nginx/server.crt;
    ssl_certificate_key /etc/nginx/server.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

ssl on： 開啓https

ssl_certificate： 配置nginx ssl證書的路徑

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

ssl_protocols： 指定客戶端創建鏈接時使用的ssl協議版本，若是不須要兼容TSLv1，直接去掉便可

ssl_ciphers： 指定客戶端鏈接時所使用的加密算法，你能夠再這裏配置更高安全的算法

添加黑白名單

白名單配置

location /admin/ {
    allow   192.168.1.0/24;
    deny    all;
}

上邊表示只容許192.168.1.0/24網段的主機訪問，拒絕其餘全部

也能夠寫成黑名單的方式禁止某些地址訪問，容許其餘全部，例如

location /ops-coffee/ {
    deny   192.168.1.0/24;
    allow    all;
}

更多的時候客戶端請求會通過層層代理，咱們須要經過$http_x_forwarded_for來進行限制，能夠這樣寫

set $allow false;
if ($http_x_forwarded_for = "211.144.204.2") { set $allow true; }
if ($http_x_forwarded_for ~ "108.2.66.[89]") { set $allow true; }
if ($allow = false) { return 404; }

添加帳號認證

server {
    location / {
        auth_basic "please input user&passwd";
        auth_basic_user_file key/auth.key;
    }
}

關於帳號認證《Nginx的幾個經常使用配置和技巧》文章中已有詳細介紹，這裏不贅述

限制請求方法

if ($request_method !~ ^(GET|POST)$ ) {
    return 405;
}

$request_method可以獲取到請求nginx的method

配置只容許GET\POST方法訪問，其餘的method返回405

拒絕User-Agent

if ($http_user_agent ~* LWP::Simple|BBBike|wget|curl) {
    return 444;
}

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

Nginx的444狀態比較特殊，若是返回444那麼客戶端將不會收到服務端返回的信息，就像是網站沒法鏈接同樣

圖片防盜鏈

location /images/ {
    valid_referers none blocked www.ops-coffee.cn ops-coffee.cn;
    if ($invalid_referer) {
        return  403;
    }
}

valid_referers： 驗證referer，其中none容許referer爲空，blocked容許不帶協議的請求，除了以上兩類外僅容許referer爲www.ops-coffee.cn或ops-coffee.cn時訪問images下的圖片資源，不然返回403

固然你也能夠給不符合referer規則的請求重定向到一個默認的圖片，好比下邊這樣

location /images/ {
    valid_referers blocked www.ops-coffee.cn ops-coffee.cn
    if ($invalid_referer) {
        rewrite ^/images/.*\.(gif|jpg|jpeg|png)$ /static/qrcode.jpg last;
    }
}

控制併發鏈接數

能夠經過ngx_http_limit_conn_module模塊限制一個IP的併發鏈接數

http {
    limit_conn_zone $binary_remote_addr zone=ops:10m;

    server {
        listen       80;
        server_name  ops-coffee.cn;

        root /home/project/webapp;
        index index.html;

        location / {
            limit_conn ops 10;
        }

        access_log  /tmp/nginx_access.log  main;
    }
}

limit_conn_zone： 設定保存各個鍵(例如$binary_remote_addr)狀態的共享內存空間的參數，zone=空間名字:大小

大小的計算與變量有關，例如$binary_remote_addr變量的大小對於記錄IPV4地址是固定的4 bytes，而記錄IPV6地址時固定的16 bytes，存儲狀態在32位平臺中佔用32或者64 bytes，在64位平臺中佔用64 bytes。1m的共享內存空間能夠保存大約3.2萬個32位的狀態，1.6萬個64位的狀態

limit_conn： 指定一塊已經設定的共享內存空間(例如name爲ops的空間)，以及每一個給定鍵值的最大鏈接數

上邊的例子表示同一IP同一時間只容許10個鏈接

當有多個limit_conn指令被配置時，全部的鏈接數限制都會生效

http {
    limit_conn_zone $binary_remote_addr zone=ops:10m;
    limit_conn_zone $server_name zone=coffee:10m;

    server {
        listen       80;
        server_name  ops-coffee.cn;

        root /home/project/webapp;
        index index.html;

        location / {
            limit_conn ops 10;
            limit_conn coffee 2000;
        }
    }
}

上邊的配置不只會限制單一IP來源的鏈接數爲10，同時也會限制單一虛擬服務器的總鏈接數爲2000

緩衝區溢出攻擊

緩衝區溢出攻擊 是經過將數據寫入緩衝區並超出緩衝區邊界和重寫內存片斷來實現的，限制緩衝區大小可有效防止

client_body_buffer_size  1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

client_body_buffer_size： 默認8k或16k，表示客戶端請求body佔用緩衝區大小。若是鏈接請求超過緩存區指定的值，那麼這些請求實體的總體或部分將嘗試寫入一個臨時文件。

client_header_buffer_size： 表示客戶端請求頭部的緩衝區大小。絕大多數狀況下一個請求頭不會大於1k，不過若是有來自於wap客戶端的較大的cookie它可能會大於 1k，Nginx將分配給它一個更大的緩衝區，這個值能夠在large_client_header_buffers裏面設置

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   10;
client_header_timeout 10;
keepalive_timeout     5 5;
send_timeout          10;

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將關閉鏈接

Header頭設置

經過如下設置可有效防止XSS攻擊

add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";

X-Frame-Options： 響應頭表示是否容許瀏覽器加載frame等屬性，有三個配置DENY禁止任何網頁被嵌入,SAMEORIGIN只容許本網站的嵌套,ALLOW-FROM容許指定地址的嵌套

X-XSS-Protection： 表示啓用XSS過濾（禁用過濾爲X-XSS-Protection: 0），mode=block表示若檢查到XSS攻擊則中止渲染頁面

X-Content-Type-Options： 響應頭用來指定瀏覽器對未指定或錯誤指定Content-Type資源真正類型的猜想行爲，nosniff 表示不容許任何猜想

在一般的請求響應中，瀏覽器會根據Content-Type來分辨響應的類型，但當響應類型未指定或錯誤指定時，瀏覽會嘗試啓用MIME-sniffing來猜想資源的響應類型，這是很是危險的

例如一個.jpg的圖片文件被惡意嵌入了可執行的js代碼，在開啓資源類型猜想的狀況下，瀏覽器將執行嵌入的js代碼，可能會有意想不到的後果

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

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

add_header Content-Security-Policy "default-src 'self'";

上邊的配置會限制全部的外部資源，都只能從當前域名加載，其中default-src定義針對全部類型資源的默認加載策略，self容許來自相同來源的內容

Strict-Transport-Security： 會告訴瀏覽器用HTTPS協議代替HTTP來訪問目標站點

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

上邊的配置表示當用戶第一次訪問後，會返回一個包含了Strict-Transport-Security響應頭的字段，這個字段會告訴瀏覽器，在接下來的31536000秒內，當前網站的全部請求都使用https協議訪問，參數includeSubDomains是可選的，表示全部子域名也將採用一樣的規則

---

閱讀原文

 

微信掃一掃關注該公衆號