Nginx導入時やること

  • 1286
    いいね
  • 5
    コメント

HTTPレスポンスヘッダにサーバのバージョンの表示を消す

なぜ必要?

潜在攻撃者への情報提供になることも。
もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。

対応

nginx.confのhttpディレクティブに server_tokens off; を追加。

nginx.conf
http {
    server_tokens off;
    ~

ok。

スクリーンショット_2014_04_23_23_07.png

未対応だと赤枠内にバージョン情報も表示されます。

デフォルトのWelcome to Nginxの表示を消す

なぜ必要?

同上。
これですね。

スクリーンショット_2014_04_23_23_11-2.png

対応

デフォルトのindex.htmlの中身を変更。

/usr/share/nginx/html/index.html
[root@localhost ~]# cat /usr/share/nginx/html/index.html
Not Found

ok。

スクリーンショット_2014_04_23_23_08.png

IPベースでのアクセス制限の準備

/admin等でよく必要になりますね。
geoディレクティブを用意しておくと便利。

/etc/nginx/conf.d/sample_app.conf
upstream sample_app {
  server unix:/tmp/unicorn.sock;
}

geo $allow_ip {
  default 0;
  93.184.216.119 1;  # 自社IP(example.com)
}

server{
  ~

  # geoで許可したIP以外はdeny
  location ~ ^/admin/ {
    if ($allow_ip) {
      proxy_pass http://sample_app;
    }
    deny all;
  }
}

許可IPを増やしたい場合は下に追加していくだけ。

geo $allow_ip {
  default 0;
  93.184.216.119 1;  # 自社IP
  xx.xxx.xxx.xxx 1;  # 支社IP1
  yy.yyy.yyy.yyy 1;  # 支社IP2
}

参考

nginxのgeoモジュールが便利すぎる
http://og732.hatenadiary.com/entry/2013/05/02/072150

ログローテート準備

設定自体は/etc/logrotate.conf/etc/logrotate.d/nginxのデフォルトでも良いと思いますが、
そもそもcrondが動いていないと動かないので、そこだけ注意かもしれません。

crondの起動確認

$ service crond status
crond は停止しています
$ sudo service crond start
crond を起動中:                                            [  OK  ]

詳しい設定については、以下記事がとても参考になります。

Nginx - ログローテーション設定!
http://www.mk-mode.com/octopress/2013/02/17/nginx-logrotation/

SSLのciphersやprotocolsの見直し

  • 脆弱性があるまたは弱い暗号化を除いて、明示的に使用する暗号化スイートを設定する。
  • あくまで例なのでサイトに合ったものを設定してください。
/etc/nginx/conf.d/sample_app_443.conf
server {
  ~
  ssl_prefer_server_ciphers on;
  ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:
            DH+AESGCM:ECDH+AES256:DH+AES256:
            ECDH+AES128:DH+AES:
            !aNULL!eNull:!EXPORT:!DES:!3DES:!MD5:!DSS;
  ~
}

httpsだからというだけで安全?調べたら怖くなってきたSSLの話!?
http://qiita.com/kuni-nakaji/items/5118b23bf2ea44fed96e

より引用させて頂いています!

特定ページのみSSL対応する

SSL通信は少々重い(※)ので、対応が必要なページのみに絞った方が好ましいですね。

※Webの表示速度を遅くする「SSLハンドシェイク」とは
http://www.atmarkit.co.jp/ait/articles/1002/09/news120.html

443.conf

/etc/nginx/conf.d/sample_app_443.conf
upstream sample_app_443 {
  server unix:/tmp/unicorn.sock;
}

server{
  ~
  # SSL対応したいページはそのままsample_app_443へ。
  location ~ ^/user/info {
    proxy_pass http://sample_app_443;
    break;
  }

  # その他ページはHTTP(80)へrewrite。
  location ~* / {
    rewrite ^(.*) http://$http_host$1;
  }
}

80.conf

/etc/nginx/conf.d/sample_app.conf
upstream sample_app {
  server unix:/tmp/unicorn.sock;
}

server{
  ~
  # SSL対応したいページはHTTPS(443)へrewrite。
  location ~ ^/user/info  {
    rewrite ^(.*) https://$http_host$1;
    break;
  }
  # その他はそのままsample_app(80)へ。
  location ~* / {
    proxy_pass http://sample_app;
  }
}

※upstreamでバックエンドに流す(unicornなどとの連携)ケースです。

静的ファイルのキャッシュ

クライアント(ブラウザ)側にキャッシュしてもらいます。

/etc/nginx/conf.d/sample_app.conf
server {
  ~
  location ~ .*\.(html?|jpe?g|gif|png|css|js|ico|swf|inc) {
      expires 1d;  # キャッシュ期間は1日
      access_log off;
  }
}

静的ファイルはログいらない、という場合はaccess_log off;を入れても。

静的ファイルは別サーバ(画像サーバ)に処理してもらう

以下はRails利用時(静的ファイルは全部/assets配下)の例。

/etc/nginx/conf.d/sample_app.conf
server{
  ~
  # 静的ファイルはimgサーバにproxy
  location ~ ^/assets/ {
    rewrite ^(.*)$ http://img-example.com$1 permanent;
  }
}

これはサーバ構成検討の上でもし必要なら、ですね。

faviconへのリクエストをよしなに

※ コメント欄にて頂いた追記分です。

faviconが存在する場合はそのまま返却し、
存在しない場合は、

  • メモリ上の1×1の空GIFファイルを返却(empty_gif)
  • アクセスログを捨てる(access_log off)
  • エラーログを捨てる(log_not_found off)
/etc/nginx/conf.d/sample_app.conf
server {
  ~
  location /favicon {
    empty_gif;
    access_log    off;
    log_not_found off;
  }
}