2018年7月8日の早朝、当ブログをこれまで使ってたレンタルサーバーからVPSに移設しました。
その際、WordPress のセキュリティ対策について再検討しました。
ブロガー歴は1年半くらいのものでしかありません。しかし、本業であるセキュリティ屋の端くれとしてのノウハウを駆使できました。
この記事は、WordPressを個人で運営するブロガーの方々に向けて、OSやネットワークで施すべき最低限のセキュリティ対策についてご紹介します。
なお、WordPressのサーバーをVPSや専用サーバーなどで運用するケースを想定しています。そのため、それ相応にリテラシーがある方向けの記事になっている点、ご了承ください。
WordPressセキュリティ対策
サーバー対策３つの考え方
WordPressに限らず、サーバーのセキュリティ対策について、まず次の３つの要素に分けて考えることを推奨します。
図：セキュリティ対策検討の３要素
- 攻撃者
- 運営サイトに対して、悪意を持ってアクセスや仕掛けをする訪問者のこと
- 脆弱性
- ソフトウェアやネットワークなどで、悪用できる不具合のこと
セキュリティ対策1. 侵入対策
攻撃者の様々な侵入を防ぐことを考えるのが、最初のポイントです。
攻撃者の侵入経路のうち、OSやネットワークという観点では次の３つが考えられます。
- 通常の通信経路：通信ポートへのアクセス
- 通常の通信経路：ログイン画面からの不正アクセス
- 異常な通信経路：脆弱性を突く不正アクセス
ここでのログイン画面とは、SSH でのログインをイメージしています。
これらの経路からの侵入を防ぐため、それぞれのセキュリティ対策を考える必要があります。
セキュリティ対策2. 侵入後対策
攻撃者の侵入を許した後には、実害に至る活動があります。ここを早く止められれば、最悪の事態に至らずに済ませられる可能性があります。
この時、管理者アカウントの乗っ取り、RAT (Remote Access Tool) やハッキングツールなどの不正プログラムの設置といったような、どの手口であっても攻撃者の動きを掴むこと、そして攻撃者の活動を制圧すること、これらを早く対処できるかが重要です。
特に、WordPress自体の侵害と違って、OSの管理者アカウントやVPSサービスのアカウントを乗っ取られて操作されるのは、色んな意味で死活問題です。
そのため、次のような方法が必要と考えましょう。
- 様々なログから異常や痕跡を発見する
- 不正な通信を検知する
- 変更されたデータやプロセスを把握する
これらは WordPress単体のセキュリティと比べて、かなり広範囲にわたります。
そのため、常時監視のような人員体制が整わないであろう、一般的な個人サイト／個人ブログでは厳しいと言わざるをえません。
しかし、完璧を求めず、1つでも2つでも何らか手を打つことだけでも、対策しないよりは遥かにマシです。
可能なところだけでも対策を用意して、とにかく侵入後の対処はできる限り早く、と考えましょう。
セキュリティ対策3. 復旧対策
攻撃者の活動を止めた後は、いち早く復旧することが必要になります。
変更されたデータを正確に特定できる場合には、そのデータだけ元に戻せば復旧完了です。
また、ログインアカウントの乗っ取りにあったなら、パスワード変更が必要です。
影響範囲が正確に把握できることが条件になる一方、これら部分的な復旧作業なら短時間で済むはずです。
しかし、影響範囲が正確に把握できないのであれば、全データを元に戻す完全リストアとその時間が必要になります。
もしどこまで戻せば影響ない状態に戻せるのかが分からなければ、完全リストアしたからといって、リスクを孕む状態は変わらないかもしれない点には注意が必要です。
これらの３つのセキュリティ対策に分けて検討することで、対策の漏れを減らすことができます。
繰り返しとなりますが、この考え方は WordPress だからと特別というわけではありません。
サーバーセキュリティの考え方は色々ありますが、一般に公開しているWEBサーバーであれば概ね同じです。個人用途かつ単体という条件付きで。
そういった事情を踏まえた上で、WordPressサーバーをOS/ネットワークのレベルで守る場合に施すべき、最低限の設定について具体的にご紹介します。
OS/ネットワークのセキュリティ対策
WordPressサーバーは、OSはLinux、ネットワークはVPS提供業者のサービス次第というケースが多いはずです。
もちろん、OSがWindowsだったり、ネットワークは操作できない場合もあるかと思います。
その場合は、どこかで同等のセキュリティ対策が施す、あるいは何らか補えれば良い、と考えて検討しましょう。
セキュリティ対策1. 侵入対策
侵入対策のうち、OSやネットワークで施せる対策はたくさんあります。
その中でも注力すべきは、次の３つの対策です。
ネットワーク対策
インターネットを通じて、総当たり攻撃やDoSなど様々な攻撃を受けるのはもう当たり前です。
当ブロクでさえ、毎日なんらかの攻撃を受けています。
そのため、ネットワークでのセキュリティ対策は最低限と言えます。
ただ、その主な手段は、通信ポートの制御やIPアドレス単位のブロックなど多種多様にあります。
その中でも、WordPressの個人サーバーであれば、最低でも下記の対策をしておきましょう。
ファイアウォールで不要な通信は遮断する
ネットワーク/ファイアウォールは、必要なポート以外は遮断するのが鉄則です。
WordPressの個人サイトであれば、利用する通信（ポート）は下記を除いて全て遮断するのが望ましいです。
【受信ポート※】
- HTTP (80)
- HTTPS (443)
- SSH (22)
※インターネット → WordPressサーバーの通信ポート
これ以外にも、FTPやMySQLなどをインターネット経由で利用したいケースもあるかもしれません。
しかし、通常は上記のポートが使えるなら、SCP や SFTPなどの代替手段があります。そちらを使えば、塞いでも構わないはずです。
また、HTTPS(443) への完全移行てきたブログであれば、HTTP (80) でさえ塞いでしまっても良いでしょう。
そんな感じで、受信ポートは閉じられるなら閉じるように仕向けた方が絶対良いです。
しかも、iptables や firewalld よりも、使えるならVPSのサービス事業者のファイアウォールを使うべきです。
ほとんどの場合、通信ポートの開閉以外の必要な設定は施されていますし、リソース節約にもなって良いです。
例えば、当ブロクで利用している ConoHa VPS
ではファイアウォールサービスが提供されています。
任意のポートを開けるのも可能です。APIで行う必要がありますが。
ちなみに、送信ポート（WordPressサーバー → インターネット）についても閉じられるなら閉じるべきです。
しかし、どことの通信を閉じれば良いのか正確に把握するのは難しい割に、よく使われるHTTPは閉じれなかったりと効果が薄いです。
よって、個人ブログでの送信ポートを閉じる対策は見送っても良いかも知れません。
SSHを強化する
Linuxサーバのあらゆる操作に利用できるSSH。標準的なリモート操作のソフトウェアです。
その通信は基本暗号化されるものの、いまやSSHが使えるだけの状態は危険と言わざるを得ません。
攻撃者だってSSHをみんな使ってるのは分かってます。そこを狙って総当たり攻撃を仕掛けてきたりしてます。
そうあっても、簡単にはログインできないように、最低でもSSHに下記の設定を施すことをオススメします。
【SSHに施すべき設定】
- SSHdの待ち受けポートを22番から変更する（例: 20122）
- 公開鍵方式の認証のみ行う
- パスワード認証は許可しない
- 管理者アカウント（Root）でのログインを許可しない
詳しい方法は、こちらが参考になります。
他にもベストプラクティスはあります。もし理解できるなら、やれるだけやった方が良いです。
ただし、ログインできなくならないよう、慎重に行ってくださいね。
脆弱性対策
WordPressに限らず、OSやネットワークでも今やせ脆弱性対策はセキュリティの要（かなめ）です。
裏を返せば、攻撃者も頻繁に脆弱性を狙って攻撃してきます。
特に、OSは大量のソフトウェアから構成され、それぞれ脆弱性が混入しやすいです。
そのため、今や脆弱性対策はかかせません。これは個人だろうが企業だろうが同じ。
それを踏まえた上で、優先度を上げて対策を施しましょう。
なお、ゼロデイ攻撃への対策も必要ですが、かなりコストがかかります。そのため、個人では既知の脆弱性攻撃への対策に注力した方が無難と考えましょう。
アップデートの定期適用
OS については、可能な限り早くアップデートするのが良いです。
ただ、WordPressなどソフトウェアと比べて、アップデートプログラムの不具合で動作に支障をきたした場合の危険度が高いのも事実。
そのため、アップデートが毎日適用するのは勇気がいります。
企業サイトならすぐのアップデートは勧めません。
しかし、個人で開発環境を持って厳密に検証する技術者でもない限り、慎重になり過ぎて時間を空けるのもリスクが高いという見方もあります。
そこで対応策としては、下記のいずれかを選ぶのが良いでしょう。
1. 週1回アクセスの少ない時間帯にアップデートを自動適用する
すぐに復旧できる体制を整えることが前提です。
例えば、本ブログで利用している ConoHa VPS
では自動バックアップ機能が用意されています。
これらを利用して、問題があればすぐにリストアすると良いでしょう。
2. 検証環境で試してから本番適用する。
検証環境で毎日アップデートを自動適用し、問題なければ本番環境に適用する、という堅い運用です。
検証環境を別に保有すること、検証環境で試す手間は必要なこと、検証環境では出ない問題もあり得る、といった条件付きの方法となります。
ただ、企業向けでも行うように、比較的に確実性が高い運用方法です。
3. 限定的に自動アップデートする
影響の少ない範囲の対象についてのみ、自動アップデートを毎日適用するといった運用です。
例えば、CentOSであれば下記で紹介されている方法がよさそ。
そもそもカーネルが上がらない用に設定する
yum -y update –exclude=kernel*
これならOSが起動しないといった、致命的な不具合を回避できそうです。もちろん、それ以外のリスクは残りますが。
個人ブログであれば、以上の3つから選ぶのが妥当です。ちなみに、
アップデートしない選択肢なし
今の時代、アップデートプログラムなしは自殺行為。
せめてセキュリティアップデートだけでも適用するのは、システムを使う上では必須です。
WAF / IPSの活用
WAF または IPS を導入することで、脆弱性への攻撃を緩和、もしくは遮断することが可能です。
ただし、通常かなり高価だったり、技術知識に詳しくないといけなかったり、個人レベルではハードルが高いのも否めません。
そこで、VPSなどのサービス提供業者のWAF/IPSサービスを活用することをオススメします。
例えば、当ブログで利用している ConoHa VPS
の WAF は月額2000円でフルオートです。これはWAFサービスとしては、破格な方だと思います。
さくらインターネットなら、さくらのVPS
をはじめ、レンタルサーバーでも、クラウドでも、WAFが提供されています。
レンタルサーバなら、ロリポップ
で標準でWAFが導入されてたのを使ってました。
最近だとエックスサーバー
で、WAFの無料提供が始まりました。
有名どころレンタルサーバーの MixHost
でも WAFは無料提供されています。
このように、主要なVPSおよびレンタルサーバーでは有償無償に関わらず、WAFは提供されています。積極的に利用したいものです。
ただし、WordPress プラグインとの若干相性があったりするので注意が必要です。
不正ログイン対策
どんなに穴を塞いでも、正面玄関から入られては意味がありません。
そのため、SSHから不正にログインされないように、最低でも下記を満たすか確認すべきです。
- アカウント名は、辞書にない、かつ推測しにくい名前にする
- パスフレーズは、複雑（辞書にない言葉＋英数字大文字小文字記号）かつ最低16文字以上にする
- rootやAdminといった管理アカウントでのログインは拒否する
これに加えて、下記のような設定も施せれば尚良いです。
- SSHで接続できる接続元IPアドレスを絞る
- 何度かログインに失敗すると、一定時間ログインロックする
- ログインアラートを使う など
これらの設定は、ファイアウォールやOSのくわしい知識が必要になります。そのため、簡単ではないかもしれません。
これらを設定するには、下記が参考になります。
セキュリティ対策2. 侵入後の対策
侵入対策をしていても、巧妙な攻撃者の場合は防ぎきれない可能性もゼロではありません。
そのため、もし攻撃者の侵入を許してしまった場合、異変に気づける仕組みが重要です。
個人サイトであっても、次のどちらか、あるいは両方の導入を検討しましょう。
ウイルスの侵入に気づく
OS上のすべてのファイルについて、定期的なウイルス検査を行いましょう。
パソコン向けのウイルスの感染を見つけるより、攻撃者のRAT (Remote Access Tool) や ハッキングツールをいち早く見つけて、排除することが目的です。
最近は、Linux向け無料ウイルス対策ソフトも出そろっているので、積極的に利用しましょう。
ただ、ウイルス対策ソフトのリアルタイムスキャンはパフォーマンス劣化を引き起こす可能性があります。
影響があるファイルを除外するようチューニングするか、定期スキャンのみにするかを考えておく必要がある点は注意です。
不正なログインに気づく
自分以外が管理画面にログインしたことに気づける仕組みを用意しておきましょう。
ログインなどの操作ログ、通称：監査ログを取得するのも良いです。
匠のおすすめはログインアラートです。
タイムリーに気付ければ気づくほど、良いからです。設定も難しくはありません。
これは先に書いた侵入防御と対策はおなじですが、下記のページが参考になります。
不正な変更に気づく
自分以外が行ったファイルの変更に加え、プロセスの生死なんかに気づけると良いです。
Linuxかつ無料で行うなら Tripwire が古くからあります。
ただし、設定方法にはかなりクセがあります。
また、記事更新など変更のたびにアラートが挙がるので、煩わしいと感じるかもしれません。
あるいは、記事やプラグイン、テーマなどの変更はデータベース内での変更となるため、気付くことができないかもしれません。
そう考えると、個人ブログで変更に気付く仕組みを厳密に使うのは難しいかもしれません。
そこでヒントになるのは下記の内容です。
計画したメンテナンスやアップグレード時にモニタリングを無効化する
サイトの定期的なメンテナンスを実行する際に、不要な警告を回避できます。
実行可能なファイルタイプのみモニタリングする
.php ファイルなど実行可能なファイルタイプのみをモニタリングすれば十分安全です。非実行可能ファイルをフィルタリングから除外すれば、不要なログ出力や警告を削減できます。
これは公式なベストプラクティスですから、ぜひ取り入れたいところです。
不正なログから異変に気づく
タイムリーにログから異常に気付いたり、毎日のまとめログから気付いたり、と色んなパターンがあります。
無料のログ監視ツールがたくさん出ています。
個人的には logwatch が手軽で愛用してます。
もし使われる方は、こちらの記事も参考にしてください。
上記の対策以外にも、サイトの表示に異常がないことを監視する仕組みなど、異常を早く気付く方法はいくつも考えられます。
これらは運用者の技量と余裕次第になりますので、個人ブログでは先の4つもできれば十分だと思います。
セキュリティ対策3. 復旧対策
攻撃者の攻撃を遮断した後、あるいは無力化するために、素早く復旧できる準備は必要です。
WordPressでは部分的に元に戻したり、色々考えられました。
不正な設定変更を元に戻すには、etckeeper を利用するという手もあります。
しかし、OSレベルでそんなことを考えなければいけない時点で、けっこう深刻な状況のハズです。
そのため、先に紹介しましたが、サービス事業者の自動バックアップを活用するのが良いでしょう。
例えば、本ブログで利用している ConoHa VPS では自動バックアップ機能が用意されています。
これらを利用して、問題があればすぐにリストアすると良いでしょう。
自力で rsync や dump などで作り込むこともできなくはないのですが、そんなこんなすると結局バックアップサービス使った方が手軽で安くなったりします。
これでWordPressセキュリティ対策は万全か？
今回この記事で紹介したセキュリティ対策は、あくまで考え方と最低限の方法です。
例えば、これ以上のセキュリティ対策には以下のものが考えられます。
- WAF+HIPSによる脆弱性対策の多重化
- ファイルのサンドボックス解析
- 変更されたファイルのリアルタイム監視
- 許可していない変更のあったファイルを即座にリストアする変更無効化
- サイトの冗長化とロードバランサーでダウンタイム削減 など
これらのように金に糸目をつければキリがありませんし、個人のWebサイトでやるのは現実的ではありませんよね。
WordPress/OS/ネットワークほか様々な箇所で、適切にセキュリティ対策を施して、スキルやコストが少なくて済むセキュリティ対策を考えていくべきだと考えます。
皆様のブロガーライフが安全に過ごせますよう、お祈りしております。
WordPressユーザーであれば、こちらも併せてご覧ください。
