Edited at

Nginx導入時やること

More than 1 year has passed since last update.


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;
}
}