注意喚起と反省をかねて書きます。
数年来、開発に使っていたChrome拡張の “jQuery Injector” が突如マルウェア化しました。
この拡張機能はjQuery未導入ウェブページにワンクリックでjQueryをロードできる開発者向けものです。（執筆時点でGoogle 拡張機能ストアからは削除済み）
なお、今回は私用のChromeアカウントで感染が判明し、仕事などで使用している個別のアカウントでは関連する拡張機能を導入しておりませんので、所属する会社や個々に依頼いただいている業務データなどへの影響はないことを先に明記いたします。
数日前から、ウェブブラウジングしていると希に “Sponsored by <ドメイン名>” というポップアップ広告が出現するようになりました。偶然にも最初の数回が初回アクセスの英語圏のサイトで起こったため、マルウェアによるものだと気付くのが遅れてしまいました。
何度か表示されている内に、拡張機能によるものだと推測し調査を始めました。
先日2016年5月3日ごろ、ImageMagickの重大な脆弱性（CVE-2016-3714 ほか）情報が公開されました。この脆弱性は ImageTragick と名付けられています。
次のページに日本語で完結にまとまっているため、是非一読ください。
ImageTragick (英語)
https://imagetragick.com/
ImageMagick内で処理する際にコマンドのエスケープが完全でなかったことが原因で、リモートで任意のコードを実行可能になります。
次のmvgファイルを作り、処理させることで再現できます。
随分昔に話題になっていたのですが、Twitterで偶然この話題を見つけたので書いてみます。
Googleは、Android端末や GoogleMaps などを使用しているiPhone端末などから、接続しているWiFiアクセスポイント（以下AP）のMACアドレスとモバイル端末のGPS情報を収集しています。
このデータを用いてAPと位置情報をマッピングするデータベースを構築しており、非GPS搭載端末の位置情報サポートや、位置情報精度向上のために使われています。
（別にこの手法はGoogleが悪者というわけではなく、MicrosoftやAppleをはじめとして、日本ではPlaceEngineなど、広く使われています。）
ここでもGoogleのサービスを例に挙げますが、Googleはジオロケーションサービスプロバイダとして、 “Google Maps Geolocation API” というものが提供されています。
問題はこのAPIの一部に対し、APのMACアドレスを与えることで、誤差数十メートルの圏内までAPの位置が特定できることにあります。
これは悪用を考えたとき、例えば遊びに行った友達のMACアドレスを使えば過去に住んでいた場所が特定できる可能性もありますし、引っ越した後も同じAPを使っていれば容易に新しい住所を知ることができます。
より一般的なケースでは、例えば古いAP機器を友人に譲る際に、下記のオプトアウトを実施していないと自宅の住所が知られてしまいます。
（関連記事: Let’s Encryptをnginxで使ってみる）
ウソです忘れてました。忘れてたところ、こんなメールが先週届いていました。
これはありがたい・・・本当にエラーになってから思い出すところでした。
3ヶ月ぶりなので、まずはLet’s Encrypt本体をアップデートしておきます。
|
1 2 3 |
$ sudo su - # cd ~/letsencrypt/ # git pull |
最近、アプリケーションなどから利用するAWSの認証情報（credentials）をgithubなどの公開リポジトリに誤ってコミットしてしまい、不正利用され高額な使用料を請求されるケースが増えています。
いくらルートアカウントを無効化してIAMユーザーを使おうが、2段階認証を導入しようが、認証情報をヒューマンミスで公開してしまっては意味がありません。
万が一、認証情報を公開してしまった場合は、一刻も早くAWSの管理コンソールから公開してしまった認証情報のアクセス権限を取り消しましょう。もしそれが会社で使っている認証情報だとしたら本当に1分1秒を争いますので、深夜だろうが構わずにAWSを管理しているエンジニアを電話で叩き起こして助けを求めてください。放置すると高確率で首が飛びます。
こういった大事故を防ぐためにAWSが公開している git-secrets というgitのプラグインがあります。
https://github.com/awslabs/git-secrets
つい先月末までは、インストールするためにソースをローカルにクローンしてきた後で make install する必要がありました。しかし、先月の26日にformulaがHomebrewのmasterにマージされ、brew経由でより簡単にインストールできるようになりました。
昔からhomebrewを使っていた人は、formulaの一覧を更新しないとインストールできないため、まずupdateしてからinstallします。
|
1 2 |
$ brew update $ brew install git-secrets |
git secrets コマンドが使えるようになっているはずです。
git-secretsはまだ有効になっていません。
リポジトリ単位で有効化する必要があるので、ここでは適当に新しいリポジトリを作ることにします。
|
1 2 |
$ mkdir test; cd $_ $ git init |
リポジトリの中にcdしたら –install で有効化。
|
1 2 3 4 |
$ git secrets --install ✓ Installed commit-msg hook to .git/hooks/commit-msg ✓ Installed pre-commit hook to .git/hooks/pre-commit ✓ Installed prepare-commit-msg hook to .git/hooks/prepare-commit-msg |
見ての通り、pre-commitをフックして実現しています。
次にどのルールにマッチしたとき、コミットを拒否するか指定します。AWSの認証情報については、 --register-aws パラメータを使えます。
|
1 |
git secrets --register-aws |
設定された拒否ルールは、 --list パラメータで確認できます。
|
1 2 3 4 5 6 7 |
$ git secrets --list secrets.providers git secrets --aws-provider secrets.patterns [A-Z0-9]{20} secrets.patterns ("|')?(AWS|aws|Aws)?_?(SECRET|secret|Secret)?_?(ACCESS|access|Access)?_?(KEY|key|Key)("|')?\s*(:|=>|=)\s*("|')?[A-Za-z0-9/\+=]{40}("|')? secrets.patterns ("|')?(AWS|aws|Aws)?_?(ACCOUNT|account|Account)_?(ID|id|Id)?("|')?\s*(:|=>|=)\s*("|')?[0-9]{4}\-?[0-9]{4}\-?[0-9]{4}("|')? secrets.allowed AKIAIOSFODNN7EXAMPLE secrets.allowed wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY |
上の出力3行目では、大文字英数20文字にマッチして拒否しているようですね。乱暴じゃないかと思いましたが、実際プログラミングをしていて大文字固定で20文字も打ちませんからね。
6,7行目はAWSの公式ドキュメントなどでも使われている、サンプルのアクセスキー/シークレットキー（Allowed patterns for example AWS keys）だそうです。
ちゃんと弾いてくれるか確認してみます。
|
1 |
vim test.php |
|
1 2 3 |
<?php $AWSAccessKeyId = "AKIAIOSFODNN1EXAMPLE"; $AWSSecretKey = "wJalrXUtnFEMI/K1MDENG/bPxRfiCYEXAMPLEKEY"; |
適当にそれっぽいのを書いて、これでコミット。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ git add test.php $ git commit -m "first commit" test.php:2:$AWSAccessKeyId = "AKIAIOSFODNN1EXAMPLE"; test.php:3:$AWSSecretKey = "wJalrXUtnFEMI/K1MDENG/bPxRfiCYEXAMPLEKEY"; [ERROR] Matched one or more prohibited patterns Possible mitigations: - Mark false positives as allowed using: git config --add secrets.allowed ... - List your configured patterns: git config --get-all secrets.patterns - List your configured allowed patterns: git config --get-all secrets.allowed - Use --no-verify if this is a one-time false positive |
弾いてくれました！
実際の運用では、認証情報やパスワードなど本当に外部に漏れてマズいものは、環境変数にセットするのが個人的にはオススメです。そもそもファイルに書かない運用であれば、ファイルの取扱い不備でリークする可能性がゼロになり、セキュリティリスクを減らせます。
とはいえ、実情そんなこと言ってられないケースも多いですので、ファイル＋.gitignoreで気をつけて運用するのが一般的でしょうか…。万が一のためにAWS内外問わず、トークンごとに権限設定ができるものは必要最小限の付与に留めるようにしましょう。AWSの場合、ルートキーでないと使えないAPIがあったりもするみたいですが……。
今回のgit secretsは他にも、既にインデックスされているファイルの中にキーが混ざっていないかどうかをスキャンしたりすることもできます。詳しく知りたい方は公式のドキュメントをどうぞ。
AWSなんかは凄い勢いで請求額が増えていくサービスが山ほどあります。ルートキーなんかが漏洩したと思うとゾッとしますね……。従量課金制のクラウドサービスを使う際には、そのセキュリティにはより一層の注意を払って取り扱いたいですね。
たいそうなタイトルだけど実際そんなことない。思ったより長くなってしまったのでお時間のあるときにどうぞ。
今までWordPressのデプロイにはrsyncを使って同期させていたんですが、WordPress専用のRuby製デプロイツール、WordMoveを使ってみようと思い立ちこちらの記事を参考にしながら準備しました。
WordMoveはSSHやFTPでログインしてファイルを置き換えるために、ログインユーザーがドキュメントルート以下への書き込み権限を持っていないとデプロイできません。
前述の参考記事ではドキュメントルート以下の所有者と、ウェブサーバーの実行ユーザーをec2-userに変更する荒技で解決しています。ここが自分の中でめちゃくちゃ引っかかったので、セキュリティ的により良いと考える権限管理ついて書いてみます。
（後から調べたことですが、Red Hatが共有ディレクトリのベストプラクティスとして提案していたようです。）
今回のゴール
デプロイ元の環境で鍵ペアを作る
今回はVCCWを使ったVagrant内のWordMoveを使います。特にWordMoveはrootになって使う必要もないので、今回はvagrantユーザーで鍵を作ります。
|
1 |
$ vagrant ssh |
|
1 2 |
$ ssh-keygen $ less ~/.ssh/id_rsa.pub |
秘密鍵のパスフレーズは必要に応じて設定してください。
ssh-keygenコマンドで鍵ペアが生成されますが、触れていいのは ~/.ssh/id_rsa.pub のように最後にpubが付いたものだけです。これがWordMoveの公開鍵になるので控えておきます。なお、当然ですが ~/.ssh/id_rsa は秘密鍵です。これを漏らしてしまうとデプロイ対象のドキュメントルート以下を丸々書き換えることができてしまうので、十分に気をつけてください。
デプロイ用のユーザーを準備する
ここでは deployer という名前で作成します。
|
1 2 3 4 5 |
sudo useradd deployer # ユーザー追加 sudo -u deployer mkdir -p /home/deployer/.ssh # ディレクトリ作って sudo -u deployer vim /home/deployer/.ssh/authorized_keys # WordMoveの公開鍵を登録 sudo -u deployer chmod 600 /home/deployer/.ssh/authorized_keys # authorized_keysを保護 |
デプロイユーザーが対象のディレクトリに書き込めるようにする
今回のデプロイ対象はウェブサーバーの実行ユーザーが所有しているドキュメントルートです。
今回はnginxを使っており、所有権はnginx:nginxです。戦略としては、nginxのグループにdeployerユーザーを追加し、ドキュメントルート以下のディレクトリに対してグループ内からの書き込み権限を付与します。
|
1 2 3 |
sudo usermod -G nginx deployer # nginxグループにdeployerユーザーを追加 sudo chown nginx:nginx -R /usr/share/nginx # ドキュメントルート以下を再帰的にnginx:nginxに所有権変更 sudo chmod g+w -R /usr/share/nginx # グループに書き込み権限を与える |
これで終わり…なら簡単で、記事にすることもないんですが、2つ問題があります。
deployerでファイルの編集をしてみます。問題なくできます。
|
1 |
sudo -u deployer vim /usr/share/nginx/html/index.php |
次はデプロイ先にないファイルをデプロイしてファイルを作成することを想定してtouchしてみます。
|
1 |
sudo -u deployer touch /usr/share/nginx/html/index-new.php |
次にパーミッションをチェックします。
|
1 2 3 |
$ ls -l /usr/share/nginx/html | grep index -rw-rw-r-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-r--r-- 1 deployer deployer 5 12月 24 04:26 index-new.php |
1つめの問題です。このように、新規でファイルを作成してしまうと所有権は deployer:deployer になってしまいます。deployerグループにnginxを追加してしまう方法もありますが、一貫性が無くなってしまう上に、何かグループに対して権限を付与する際にも複数のグループを気にすることとなり運用コストが高まります。
これを解決する方法として特殊なパーミッションビット、setgidを使います。
setgidを理解する
setgidというのは、setuid, setgid, sticky bit と並んで紹介されることの多いLinux系ファイルシステムにおける特殊なパーミッションビットのことです。今回はsetuidとsticky bitは使わないので省略します。
setgidはset group idの略で、このパーミッションを有効にしたディレクトリ内でファイルやサブディレクトリを作成すると、setgidを付与したディレクトリと同じグループが所有グループとなります。グループを継承することができるということです。
setgidはchmodコマンドで g+s を指定することで設定できます。
|
1 |
sudo chmod g+ws -R /usr/share/nginx # setgidビットフラグを起てる |
|
1 |
sudo -u deployer touch /usr/share/nginx/html/index-new2.php |
チェックしてみます。
|
1 2 3 4 |
$ ls -l /usr/share/nginx/html | grep index -rw-rwSr-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-rwSr-- 1 deployer deployer 5 12月 24 04:26 index-new.php -rw-r--r-- 1 deployer nginx 3 12月 24 09:23 index-new2.php |
デフォルトでグループがnginxに割り当てられています。
今度こそ終わり… と思ったら、新しく作られたファイルのグループはnginxになっていますが、よく見るとグループへの書き込み権限がありません。2つめの問題です。
デフォルトパーミッションを変更する
ここまでで、ファイルやディレクトリを作成したときに所有グループを継承できるようになりました。最後は、デフォルトのパーミッションでグループに書き込み権限を付与することです。これにはumaskを使います。
umaskは許可*しない*ビットを指定する方法なのでかなり柔軟に設定できます。デフォルトではumask 022（＝新規ファイルは644、自分だけ書き込み可）になっていますので、今回はumask 002（＝664、自分とグループの人が書き込み可）に変更したいわけです。
今回はdeployerユーザーにumask 002を付与したいので、deployerユーザーの .bash_profile を利用します。
|
1 |
sudo vim /home/deployer/.bash_profile |
|
1 2 |
# .bash_profile +umask 002 |
テストしてみます。ただし、sudo -u deployerを使うとrootのログインシェルに入ってしまいumask 022が適用されてしまいますので、su – を使います。
|
1 2 |
sudo su - deployer touch /usr/share/nginx/html/index-new3.php |
|
1 2 3 4 5 |
$ ls -l /usr/share/nginx/html | grep index -rw-rwSr-- 1 nginx nginx 5 12月 24 04:26 index.php -rw-rwSr-- 1 deployer deployer 5 12月 24 04:26 index-new.php -rw-r--r-- 1 deployer nginx 3 12月 24 09:23 index-new2.php -rw-rw-r-- 1 deployer nginx 3 12月 24 09:39 index-new3.php |
新規ファイルも664のパーミッションで、グループを継承できました！念のためにサブディレクトリを作って、その中でファイルを作っても同様の結果になることを確認しておきましょう。テストが済んだらテスト用ファイルはすべて消しておきます。
WordMoveでデプロイしてみる
今回はWordMoveを使っていますがWordMoveの紹介ではないので簡単に。実際にdeployerユーザーを使ってデプロイしてみます。
|
1 2 3 |
vagrant ssh cd /vagrant wordmove pull --all |
Pulling Databaseで、サーバー側でmysqldumpが効かなくて一度コケましたがmysqlをyumで入れて解決しました。
|
1 |
wordmove push --themes |
ちゃんとプッシュできていることを確認して終わりです。お疲れ様でした。
雑感
ここまで書いておいて何ですが、本当はこのように役割ごとにユーザーを切り分けるべきだと信じています。ただめちゃくちゃ面倒くさくて、最後デプロイツールでも一工夫必要なことを考えると、同一ユーザーでやってしまいたくなるのもとても分かります。難しいですね。
非SSL環境で動かしていたWordPressをSSL化するときの手順です。ちょうどLet’s Encryptを使って認証された証明書が手に入ったので、これを使ってWordPress全体をSSL化してみました。手順を備忘録として残しておきます。
wp-config.phpの修正
まずは基本ですね。WP_HOMEとWP_SITEURLを書き換えます。また、FORCE_SSL_ADMINを設定することで管理画面はHTTPSを強制できます。
|
1 2 3 4 5 6 |
- define( 'WP_HOME', 'http://saku.io' ); - define( 'WP_SITEURL', 'http://saku.io' ); + define( 'WP_HOME', 'https://saku.io' ); + define( 'WP_SITEURL', 'https://saku.io' ); + define('FORCE_SSL_ADMIN', true); |
データベースの修正
WordPressのデータベースに接続し、(WPプレフィックス)_options テーブルを開きます。
option_nameカラムがsiteurlになっているレコードを探し、値のhttp://をhttps://に書き換えます。続いてoption_nameカラムがhomeになっているレコードを探し、同じように書き換えます。
HTTP接続をHTTPSにリダイレクト
上の2ステップでWordPressのシステム的な部分の移行が終わりました。HTTPSで適当なページを開いて正しくリンクが遷移できるか、リンク遷移後もページもHTTPSになっているか、画像や画像のサムネイルが正しく読み込めているか、管理画面へHTTPSのままログインできるか、などをチェックします。
問題がないようであれば、httpでの接続はすべてhttpsにリダイレクトするようにします。（任意です。httpsにすると若干サーバーの負荷も増えますので、ハイトラフィックなブログを運営されている方はhttpの方が有利という考え方もできます。ブログであれば、http/httpsどちらでもアクセス出来るようにしておき、通信を暗号化するかどうか判断をユーザーに委ねるのも良い方法です。）
今回nginxを使っているので、nginx.confを書き換えることにしましょう。リダイレクトにはrewiteを使っているブログも多く見られますが、nginx.orgではreturnが使われていたのでreturnを使うことにします。計った訳ではないですが、シンプルな分処理も早そうです。
|
1 2 3 4 5 6 7 8 9 10 |
+ server { + listen 80; + server_name saku.io; + return 301 https://$host$request_uri; + } server { - listen 80; listen 443 ssl; } |
保存したらnginxを再起動します。
|
1 |
sudo service nginx restart |
再起動が終わったら、適当なURLを叩いてみてHTTPSに正しくリダイレクトされることを確認します。
安全でないリソースを排除する（Mixed Content問題）
これで9割方終わっていて、SSLにするという目的自体は達成なのですが、次のように「このページに安全でない他のリソースが含まれています。」と表示され、URLのアイコンや文字色も緑色にならないことがあります。
これは、アクセスしているページはSSL接続にも関わらず、そのページ内から非SSLの静的ファイル等をロードしているためです。例えば、サードパーティのCSSやJavaScript、フォントファイル、画像ファイル等を絶対パスでhttp:// に続く形でロードしていることに起因するものが多いです。
これらを見つけて、httpsが提供されているコンテンツはhttpsでロードするように、提供されていない場合はライセンスを確認して自分のサーバーでホスティングできるか確認して移行するなどの対策を行います。量が多いと結構大変ですね…。
どのファイルがMixed Contentなのかは、Google Chromeのデベロッパーツールにあるコンソールが助けになります。
例えば上の画像のように、過去にアップロードした画像ファイルに起因するものであれば、次の項を読んでみてください。テーマやプラグインに起因するものは、手動で直さなければいけません。
ちなみに、Protocol Relative URLという仕様により、CSSやJavaScriptをロードする際のhttpやhttpsを省いて記述すると、読み込み元のスキーム（SSLか非SSLか）に従って読み込むスキームも変更されポータビリティが高まります。（例えば //example.com/main.js をSSLのページからロードさせた場合はhttps://〜と解釈され、非SSLのページからロードさせた場合はhttp://〜と解釈されます。）
アップロード画像に起因するMixed Contents問題を直す
この場合、基本的には記事を編集して、画像へのURLを書き直すことで修正できますが、過去の記事・画像が多いと直すのに骨が折れます。
一気に前述したProtocol RelativeなURLに画像リンクを書き換えるSQL文を使うと一瞬で解消できるでしょう。テストしていますが、万一のために必ず実行前にテーブルのバックアップを取ってください。
|
1 2 3 4 5 6 |
UPDATE wp_posts # 適宜プレフィックスがあれば読み替えてください SET post_content = ( Replace (post_content, 'src="http://', 'src="//') ) WHERE Instr(post_content, 'jpeg') > 0 OR Instr(post_content, 'jpg') > 0 OR Instr(post_content, 'gif') > 0 OR Instr(post_content, 'png') > 0; |
無事にMixed ContentsによるSSLの警告も消えました。
雑感
サクっとこなすつもりが意外と色々気にすることがあって大変でした。一度やっておくとノウハウ的に使い回せるので、知識として蓄えておきたいですね。
次はHTTP/2, SPDY対応や、証明書の透明性確保あたりを触れたらいいなと思っています。
Let’s Encryptとは
無料で認証されたSSL証明書を発行できるサービスです。今月パブリックベータになり、誰でも試すことができるようになりました。Web Tech界隈では今アツい技術の一つです。
今回使うnginxは1.8系のため、HTTP/2、SPDYは使えません。メインラインの1.9系を使うことで対応できるので、興味がある方は別に調べてみてください。
ビジネスなどエンタープライズで使用する際はこのSSLではなく信頼された発行元から
Let’s Encryptのインストール
Let’s Encryptを使うためには、nginxやapacheなどのウェブサーバーのほかGitが必要です。OpenSSLなどはインストールされていない場合、Let’s Encryptが自動的にインストールしてくれます。Gitがインストールされていなければ、事前にyumで入れておきます。
まず、Let’s Encryptのクライアント本体を適当な場所にgitでクローンしておきましょう。
gitが必要な箇所はここだけです。結構頻繁に更新されているようなので、都度ローカルリポジトリも追従させてあげるのが良いでしょう。
|
1 2 3 |
cd ~ git clone https://github.com/letsencrypt/letsencrypt.git cd letsencrypt |
クローンしたら、内包されているメインのコマンド letencrypt-auto を叩いてみましょう。このコマンドを実行した場合、letsencryptが使用する必要なライブラリがインストールされていなければ自動でインストールしようとします。rootで実行していない場合はパスワードを入力してください。
|
1 2 3 4 5 |
cd letsencrypt ./letsencrypt-auto # WARNING: Amazon Linux support is very experimental at present... # if you would like to work on improving it, please ensure you have backups # and then run this script again with the --debug flag! |
今回、AWS EC2で実行している関係で上のような警告が表示されました。EC2上で利用するのであれば一般的なCentOS等と使い方は何ら変わりませんので、言われるままに継続します。
|
1 2 3 4 5 6 7 |
./letsencrypt-auto --debug # Bootstrapping dependencies for Amazon Linux... # (中略) # Running with virtualenv: (インストールパス)/bin/letsencrypt --debug # Version: 1.1-20080819 # Version: 1.1-20080819 # No installers are available on your OS yet; try running "letsencrypt-auto certonly" to get a cert you can install manually |
一度debugをつけて実行した後はdebugなしで利用できるようです。
証明書の取得
発行にはドメインの所有権認証が必要です。letsencrypt-autoでは、次の方法でこの認証を簡単なコマンドだけで実行できます。
現時点でlets encryptでは apache, standalone, webroot の3種類の証明書取得方法をサポートしています。apacheを使っている場合はapacheを使うと自動でインストールしてくれます。standaloneはletsencrypt自身がウェブサーバーを起動して所有権の認証を行います。webrootは既にウェブサーバーが起動している場合、ドキュメントルートを指定して既存のサーバーを介して認証を行います。 詳しい違いについては ./letsencrypt –help で確認してください。
今回はnginxですし、既に起動しているサーバーに対してインストールしょうとしているので、3番目のwebrootオプションを使って認証を行います。
|
1 |
./letsencrypt-auto certonly --webroot --webroot-path <発行するドメインのドキュメントルート> -d <ドメイン> |
上記を実行するとメールアドレスの入力と利用規約への同意が求められますので、指示通り進みます。認証情報を紛失した際などは、ここで登録したメールアドレスを使ってリカバリするので間違えないように気をつけてください。
次のようなメッセージが出力されれば、正しく証明書を取得することができました。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
IMPORTANT NOTES: - If you lose your account credentials, you can recover through e-mails sent to <登録したメールアドレス>. - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/<ドメイン>/fullchain.pem. Your cert will expire on <有効期限>. To obtain a new version of the certificate in the future, simply run Let's Encrypt again. - Your account credentials have been saved in your Let's Encrypt configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Let's Encrypt so making regular backups of this folder is ideal. |
上の例では、/etc/letsencrypt/live/<ドメイン>/ の中に証明書類が保存されています。
DH鍵交換のパラメーター生成
証明書をウェブサーバーにインストールする前に、セキュリティ向上のために実行することをおすすめします。
opensslコマンドで生成します。AWSのsmallインスタンスで3分程度かかりました。環境によってはもっと時間がかかるかもしれません。
|
1 2 |
sudo mkdir /etc/nginx/ssl # フォルダがない場合 sudo openssl dhparam 2048 -out /etc/nginx/ssl/dhparam.pem |
証明書をnginxに設定
最後に取得したSSL証明書をnginxから参照して利用できるようにします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
server { listen 80; + listen 443 ssl; - server_name localhost; + server_name <ドメイン>; + ssl_certificate /etc/letsencrypt/live/<ドメイン>/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/<ドメイン>/privkey.pem; + ssl_session_timeout 1d; + ssl_session_cache shared:SSL:50m; + # 生成したDHパラメータを使用 + ssl_dhparam /etc/nginx/ssl/dhparam.pem; + # 暗号化スイートを明示的に指定する + ssl_prefer_server_ciphers on; + ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; + # POODLE対策でSSLv1〜3は有効にしない + ssl_protocols TLSv1 TLSv1.1 TLSv1.2; + # HSTSヘッダを設定 （SSL接続を強制する場合のみ） + #add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains;'; } |
上の通り変更して、nginxを再起動します。設定ファイルに問題がなければSSLで通信できるようになっていますので、テストしてみましょう。
|
1 2 |
sudo service nginx restart echo "Lets Encrypt" > /usr/share/nginx/html/test.html |
ということで、Let’s Encryptで簡単にSSL対応できました！
SSLのセキュリティテスト
SSLサーバーのセキュリティテストは Qualys SSL Report を使って簡単に実施できます。
最低限の設定を施しただけだとCやDランクになるかと思います。例えばPOODLEや弱いDHパラメーター、ダウングレード攻撃などの脆弱性を防いでいない場合は評価が下がります。
前述のnginx.confの設定を施せばAまたはA+の評価になると思います。ときどきこのサイトでSSLの安全性をチェックして、常にこの評価をキープしていきましょう。
雑感
以前から無料で発行できるSSL証明書もありましたが、手続きが煩雑だったりと色々厄介なことが多かったです。Let’s Encryptもまだ改善の余地はあり、速い速度で開発も進んでいますので、まだまだ今後に期待できるでしょう。Let’s EncryptでSSL対応が当たり前な時代になれば良いですね。
いくらWordPressをホストするサーバーのセキュリティを高めたところで、WordPressが脆弱だと意味がありません。WordPressのセキュリティ対策をまとめてみます。
それぞれの先頭の★は、3段階でその対策の効果を元にしたお勧め度を表します。
管理用のユーザー名を変更する（★★★）
ログインする際のユーザー名は管理画面の設定から変更することができません。ただし、新しくユーザーを作成し、古いユーザーを削除する方法で管理用のアカウントを作り直すことができます（記事は引き継げます）。adminのような脆弱なユーザー名を使っているのであれば、今すぐにでも変更すべきです。また当然ですがパスワードは使い回さず、堅牢なものを設定しましょう。
ログイン時に2段階認証を行う（★★★）
2段階認証というのは、IDとパスワードの他にワンタイムパスワードを入力する方式のことです。管理画面へのブルートフォース攻撃対策にとても有効です。
WordPressでこれを実現するには「Google Authenticator」プラグインがお勧めです。ユーザー毎に二段階認証の有効無効を切り替えることができます。スマートフォンに「Google Authenticator」のアプリをインストールして、WordPressのユーザー管理画面に表示されたQRコードをスキャンして紐付けます。ちなみに、有料版の1Passwordなど一部その他ワンタイムパスワード用のアプリでも利用可能です。
ログイン用のURLを変更する（★★★）
WordPressは /wp-admin や /wp-login.php にアクセスすることでログインページが表示されますが、このログイン用のファイル名を変更してしまうことでそもそも不正なログインを試される可能性がぐんと下がります。
直接コードに手を加えて実現することも可能ですが、日本語対応のお勧めプラグインもあります。Login Rebuilder です。これも簡単に実装可能な上、効果はとても大きいので是非実装しましょう。ただし、他のセキュリティ系プラグインとの相性が悪いこともあるのでその点は要注意です。
wp-config.phpファイルを守る（★★☆）
このファイルはWPがデータベースに接続するための接続情報などが含まれ、流出などに一番気をつけなくてはいけないファイルです。PHPのコードになっているため、PHPファイルが正しく処理される環境下では基本的に問題になることはありませんが、万が一PHPが正常に処理されなかった場合に備えてウェブサーバー側で対策を講じておきましょう。
nginxの場合、/etc/nginx/nginx.confのserverセクションに以下を記述します（ただしphpをハンドリングしている箇所より上に書く必要があります）。
|
1 |
location ~* wp-config.php { deny all; } |
apacheの場合、WPルートにある.htaccessに下記を追記します。
|
1 2 3 4 |
<files wp-config.php> order allow,deny deny from all </files> |
xmlrpc.phpを無効化する（★★☆）
WordPressは3.5以降、デフォルトでXML-RPCの機能が有効になっています。これはpingbackやメール投稿などの機能をサポートするものですが、pingbackの悪用によりDoS攻撃の踏み台にされることがあります。これらの機能を使っていないのであれば、上記wp-config.phpを無効にする手順と同様に xmlrpc.php を無効にしてください。適切に設定がなされていれば、/xmlrpc.php へアクセスした際に403 Forbiddenが返されるはずです。
WordPressのバージョンを隠す（★☆☆）
WordPressで生成されたページのソースコードには、metaタグやcssのサフィックスとしてWordPressのバージョン番号が記載されています。バージョン番号が知られてしまうと、既知の脆弱性を用いた攻撃が容易となります。悪意のある攻撃者へ情報を与えないために、バージョン番号を出力しないようにしましょう。
これもプラグインを用いることで用意に実現できます。「Remove Version」というプラグインをインストールして有効化するだけで、ソースコードにバージョン番号が出力されなくなります。
readme.htmlを削除する（★☆☆）
インストールする際のreadme.htmlがルートディレクトリに残っていたりしませんか？このファイルにもWordPressのバージョン番号が含まれています。もし存在するようなら消しておきましょう。
テーブルのプレフィックスを変更する（★☆☆）
データベースのテーブルに割り当てられるプレフィックスです。もしデフォルトの wp_ を設定されているのであれば、これも別のものに変更されることをお勧めします。SQLインジェクションの対策になります。インストール済みのWPでプレフィックスを変更することも可能ですが、手を入れなければならない箇所が多く、長くなるので割愛します。
管理画面からソースコードの編集を禁止する（★☆☆）
wp-config.phpに次の行を追記することで、管理画面からテーマやプラグインのソースコードを編集できなくすることができます。
|
1 |
define('DISALLOW_FILE_EDIT', true); |
これは管理権限を持つユーザーの不正なコードの改竄を防ぐ効果があります。また、不正に第三者に管理画面にアクセスされた際にも限定的ながら有効です。
その他
これも良い対策の一つですが、私の場合は外出先からでも執筆のためアクセスすることが多く、IPを固定できないため敢えて導入していません。その場合でも、国外からのアクセスなど出来るだけ絞り込むというのは十分にアリな対策です。
まとめ
いくつか対策を挙げてみました。WordPressを用いたサイトを運用する上での、セキュリティ対策の一助になれば幸いです。