セキュリティに関するいくつかの構成

7768 ワード

開発ツール NRBC

セキュリティに関するいくつかの構成
安全は小さいことがなくて、安全はnginx配置からし始めます.
この記事の転載元:https://blog.csdn.net/weixin_44290425/articale/detail/91411191
前の記事「Nginnxのいくつかの常用的な構成と技術」はいいフィードバックを受けました.ここでは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を開く
同前certifticate:nginx ssl証明書を設定する経路
同前certifcate_key:nginx ssl証明書keyを設定する経路
同前protocols:クライアントが接続を確立する際に使うsslプロトコルのバージョンを指定します.TSLv 1に対応する必要がないなら、直接にキャンセルしてもいいです.
同前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を禁止することによって簡単に防げます.
Nginnxの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はプロトコルを持たない要求を許可して、以上の2つの種類を除いて、refererがwwww.ops-coffee.cnまたはops-coffee.cnであることを許可します.
もちろん、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_connzone:各キー(例えば$binary_remote_addr)状態を保存する共有メモリ空間のパラメータを設定します.zone=空間名:サイズ
サイズの計算は変数に関連しており、例えば$binary_remote_addr変数のサイズはIPV 4アドレスを記録するために固定された4 bytesであり、IPV 6アドレスを記録するとき固定された16 bytesであり、記憶状態は32ビットプラットフォームで32または64 bytesを占有し、64ビットプラットフォームで64 bytesを占有する.1 mの共有メモリ空間は約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;

clientbody_ブザーsize:デフォルト8 kまたは16 kは、クライアント要求bodyがバッファサイズを占有することを示しています.接続要求がキャッシュ領域で指定された値を超えた場合、これらの要求エンティティの全体または一部は、一時ファイルの書込みを試みる.
clientheader_ブザーsize:クライアント要求ヘッダのバッファサイズを表します.ほとんどの場合、次の要求ヘッドは1 kより大きくはないが、wapクライアントからの大きなクッキーがあれば、1 kより大きくなる可能性があり、Ngixはそれより大きなバッファに割り当てられ、この値はlarge_client_header_buffersに設定されてもよい.
clientmax_body_size:クライアント要求の最大許容可能なbodyサイズを表します.要求ヘッドのConteet Lengthフィールドに現れます.要求が指定値より大きい場合、クライアントは「Request Entity Too Large」を受信します.(413)エラーは通常、ファイルをサーバにアップロードする際に制限されます.
largeclientheader_バffersはいくつかの比較的大きな要求ヘッドが使用するバッファの数とサイズを表しています.デフォルトのバッファサイズはオペレーティングシステムにおける改ページファイルサイズで、通常は4 kまたは8 kです.要求フィールドはバッファサイズより大きくないです.クライアントが比較的大きなヘッダを送信すると、inxは「Request URI too large」に戻ります.要求されたヘッダの一番長いフィールドはバッファエリアより大きくしてはいけません.そうでないとサーバは「Bad request」に戻ります.(400)
同時にいくつかのタイムアウト時間の設定を変更する必要があります.

client_body_timeout   10;
client_header_timeout 10;
keepalive_timeout     5 5;
send_timeout          10;

clientbody_time out:読み出し要求bodyのタイムアウト時間を表し、この時間を超えて接続された場合、クライアントが応答しない場合、Ngixは「Request time out」に戻ります(408)エラー.
clientheader_time out:クライアント要求ヘッダの読み取りのタイムアウト時間を表し、この時間を超えて接続された場合、クライアントが応答しない場合、Ngixは「Request time out」に戻ります(408)エラー.
keepalive_timeout:パラメータの最初の値は、クライアントとサーバが長い間接続されたタイムアウト時間を表しています.この時間を超えると、サーバが接続をオフにします.オプションの第二のパラメータは、ResonseヘッダのKeep-Aliveを表します.timeout=timeのtime値です.この値はいくつかのブラウザにいつ接続をオフにするかを知らせることができます.このパラメータを指定しないと、inxはレスポンスヘッダにKeep-Alive情報を送信しません.
send_timeout:クライアントへの応答後のタイムアウト時間を表します.Timeoutとは、完全なestablished状態には入らず、2回の握手のみを完了しました.この時間を過ぎると、クライアントは何の応答もなく、nginxは接続をクローズします.
ヘッド設定
以下の設定により、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などの属性をローディングすることを許可するかどうかを示し、3つの構成DENYは、任意のウェブページが埋め込まれることを禁止し、SAMEORIGINは、当サイトのネスティングのみを許可し、ALLOW-FROMはアドレスのネスティングを指定することができる.
X-XSS-Parotection:XSSフィルタリングを有効にすることを示し、X-XSS-Protection: 0はXSS攻撃を確認したらレンダリングページを停止すると表しています.
X-Connect-Type-Options:応答ヘッダは、指定されていないまたはエラー指定mode=blockリソースの真のタイプに対するブラウザの推察挙動を指定するために使用され、nosniffは任意の推測を許可しないと表しています.
通常の要求応答では、ブラウザはContent-Typeに従って応答のタイプを識別するが、応答タイプが指定されていないか、またはエラーが指定されていない場合、ブラウズはMIME−sniffingを使用してリソースの応答タイプを推測することを試み、これは非常に危険である.
例えば、jpgの画像ファイルは実行可能なjsコードに悪意的に埋め込まれています.リソースタイプの推測を開くと、ブラウザは埋め込まれたjsコードを実行します.思わぬ結果をもたらすかもしれません.
また、要求ヘッドの安全配置について注意が必要です.
Conteet-Security-Paolicy:ページを定義して、どのような資源をロードできますか?

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

上の構成は、すべての外部リソースを制限し、現在のドメイン名からしかロードできない.Content-Typeは、すべてのタイプのリソースに関するデフォルトのローディングポリシーを定義し、default-srcは、同じソースからのコンテンツを許可する.
Strict-Tirasport Security:HTTPの代わりにHTTPSプロトコルで目的局にアクセスするようにブラウザに伝えます.

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

上の配置は、ユーザが初めて訪問した後、self応答ヘッダを含むフィールドに戻ることを示しています.このフィールドは、次の31536000秒以内に、現在のウェブサイトのすべての要求はhttpsプロトコルでアクセスし、パラメータStrict-Transport-Securityはオプションであり、すべてのサブドメインも同様のルールを採用することをブラウザに教えます.

javascript-node and Error:EMFILE、too many open filesを解決します.