サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ニコニコ動画
www2.matsue-ct.ac.jp
nginxは HTTP リクエストに対して、最初にどのサーバでそれを処理すべきか を決定します。その際に用いられるのが、リクエストヘッダ中の Host フィールド です。以下の例では、このHost フィールドと server_name が一致した 場合、該当するサーバ設定が採用されます。 server { listen 80; server_name www.test.jp w3.test.jp; ... } server { listen 80; server_name www2.test.jp; ... } 一方、もしこれらの server_name と Hostフィールドの名前が一致 しなかった場合には、デフォルトのサーバでリクエストは処理されます。 デフォルトのサーバは、最初に定義されているサーバになります。 従って、上の例では、www.test.jp が該当します。 もし、デフォ
Nginx 入門
worker_processes 1; events {} http { include mime.types; access_log /var/log/nginx_access.log; error_log /var/log/nginx_error.log info; server { listen 80; server_name net-0.matsue-ct.ac.jp; index index.html index.htm; location / { root /usr/local/www/nginx; } } } worker_processes 実際にクライアント要求を処理するプロセス数を指定 通常、コア数程度を指定することが推奨されている。一方、ファイルへのアクセスなどが多い場合には、ファイルI/Oをフルに利用するために、このワーカー数を増やす方が、 パフォーマンスが出る場合
目次
たくさんのルールがある場合には、http_geo_module の変数を使うほうが 良いとマニュアルにあります。 実際、geo モジュールの変数を使うと非常に簡単になります。 geo ディレクティブは、httpコンテキストのみで利用できます(勿論、定義した 変数自体は他のコンテキストで利用できます)。 geo ディレクティブでは、$remote_addr のアドレスに対して、 { ... } の中の条件を評価し、その結果が変数 $variable に 格納されます。もし、評価するアドレスを別の変数のものにしたい場合に、 $address を指定します。例えば、
Naxsi は、ModSecurity などとは異なるポリシーの元に作られた新しい WAFです。Naxsi は、Nginx Anti Xss & Sql Injection の略で、 アンチウィルスソフトなどで使われるシグネチャータイプではなく、 以下のような特徴を持っています。 XSS, SQL injection, CSRF, File include からの防衛 既知の攻撃に対するシグネチャーによらない防衛 GET/POST リクエストのチェック HTTP ヘッダとクッキーのチェック 危険な記号類、SQL キーワードの禁止 早いエンジン 比較的に単純な設定 ホワイトリストアプローチの採用 学習モードのサポート シグネチャーによらない防衛機能として、脆弱性のある良く知られた パターンの99% を含む単純なルールが用意されており、例えば、 URIの一部として <,|, drop などは含
# 例 5.2.1 server { index index.html index.htm; location = / { # config A root /usr/local/www/nginx; } location / { # config B root /usr/local/www/nginx/root; } location ^~ /images/ { # config C root /usr/local/www/nginx/graph; } location ~* \.(gif|jpg|jpeg)$ { # config D root /usr/local/www/nginx/images; } } これは nginx の Wiki に載っている例です(rootディレクティブなど少し 変更しています)。 まず、URIが、/ であった場合、最初の config A がヒットします
クライアント証明を要求するのはサーバ側です。従って、先のサーバ証明に 対応したHTTPSの設定に加えて以下の部分が必要です。 server { listen 443 ssl; ssl_certificate ssl/allcert.pem ssl_certificate_key ssl/private.pem; ssl_verify_client on; ssl_client_certificate ssl/cacert.pem; ... } クライアント証明書を要求します。結果は、$ssl_client_verify 変数に 保存されます。 パラメータの意味は、以下の通りです。 on クライアント認証を行います。 off クライアント認証を要求しません。 optional クライアント証明書を要求し、CA証明書があればその証明書を検証します。 optional_no_ca クライアント証
ウェブに特化したアプリケーションファイヤーウォールが WAF (Web Application Firewall) です。 WAF のようなアプリケーションサイドでのファイヤーウォールは、 今日の攻撃が、サーバなどへの侵入から、ウェブサーバやPCへの侵入へと変化する 中で、重要性が増してきていると考えられています。特に、ウェブサーバは、 サーバ自体が安全であっても、ウェブアプリケーションに問題があれば、 簡単に侵入を許したり、情報漏洩を引き起こしてしまう点で、最重要の防御 対象だといえます。このために商用のWAFも様々なものが販売されていますが、 残念ながら、その価格に見合わないのではないかという声もあり、一時ほどの 盛り上がりを欠いているようです。ここでは、主にOSSで Nginx 用に開発がされている Naxsi を取り上げます。 11.1 WAFとは 11.1.1 Naxsiのモデル
nginx では、コメントは頭に # をつけます。コメントは、ディレクティブ の後から# をつけても構いません。 nginx では、変数は頭に $ が置かれる。nginxでは非常に多数の変数が 用意されており、例えばHTTPの要求ヘッダの値にアクセスできるように $http_host 変数のような要求ヘッダのHostの値や、それが設定 されていない場合に備えて servername 変数、クライアントのIPアドレスがセット されている $remote_addr、あるいは応答メッセージのヘッダへ アクセスするために、例えば $sent_http_keep_alive 変数などがある。 値は、数値と文字列がありますが、数値に関しては以下の略記号が使える ようになっています。
nginxでは、設定ファイルは通常 nginx.conf となり、FreeBSDでは、 /usr/local/etc/nginx/ に置かれます。 設定ファイルは、ディレクティブと言われる設定項目の集合です。各々の ディレクティブは適用範囲などを明確にするために、ブロック に分けることが出来ます。ブロックは、入れ子にすることができ(出来ない ブロックもありますが)、上位のブロックで定義された設定は、基本的に 下位(内部)のブロックにデフォルト値として引き継がれます(継承)。
なお、nginx ではマスタープロセスと、指定した数だけのワーカープロセスが 走り、ワーカープロセスがユーザのリクエストを処理します。ワーカープロセス はFreeBSDの標準設定では、wwwユーザの権限で走ります。 また、FreeBSDでは、起動・停止・再起動などのためのスクリプトが用意 されていますが、/etc/rc.conf に以下の設定をしないと、 スクリプトが動きませんので、注意して下さい。
このページを最初にブックマークしてみませんか?
『www2.matsue-ct.ac.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く