AWSのEC2にAmazon Linux 2のインスタンスを作成し、スタンダードかつセキュリティに配慮したインターネットサーバを構築する手順をまとめました。記事はQiitaに投稿しました。

概要

EC2でAmazon Linux 2のインスタンスを作成し、以下のようなサーバを構築する手順をまとめました。

記事一覧

各記事はQiitaに投稿しました。

https://qiita.com/ryu-blacknd/items/23b86d9ad768d58ff161

https://qiita.com/ryu-blacknd/items/36ccfcf96da7b0c981cf

https://qiita.com/ryu-blacknd/items/77eebe43a18a69e7c1e5

https://qiita.com/ryu-blacknd/items/4049f04e445eb1d60e4d

https://qiita.com/ryu-blacknd/items/03030d11eeef65e3cf67

https://qiita.com/ryu-blacknd/items/8e0c28065af3f9b8a06d

https://qiita.com/ryu-blacknd/items/20e5540195501e16e90e

ポイント

ただ単にインストールして初期設定を行うだけでなく、チューにニグやセキュリティ対策にも注力しました。

脆弱性診断「A+」

2020年前半、SSL/TSL絡みで大きな動きがありました。
ChromeやFirefox等、主要ブラウザがSSL 1～3、TLSv1.0～1.1を無効化したのです。
このためサーバ側で設定を変更しTLSv1.2を有効にする必要がありますが、同時にセキュリティリスクのある上記対象バージョンを無効にするという作業も行わないと、脆弱性診断で危険と診断されるようになりました。

りゅう

多くの顧客を抱える制作業者はプラン変更やサーバ移転に追われました。レンタルサーバでは基本的に機器構成やサーバの設定は変更してもらえないためです。

今回の記事ではこの問題にも対処し、かつせっかくなら脆弱性診断で最高の「A+」を取得することを目標に掲げました。

この記事を書きながら構築したサーバは、SSL Labsの診断で「A+」と診断されました。

常時SSL化対応

無料のSSL証明書を取得できるLet's Encryptを利用し、ApacheやNginxの設定で常時SSL化を行います。
Let's Encryptの証明書は更新期限が3ヶ月と短いため、期限切れになる前に自動で更新するようにも設定します。

ApacheのEvent MPM

MPMとはマルチプロセッシングモジュールの略です。
Apacheは、デォルトではシングルスレッドプロセスであるPrefork MPMで動作します。
記事ではイベント駆動であるEvent MPMを採用します。これにはPHPも関係します。
また環境に合わせてチューニングも行います。

PHP-FPMの採用

Apacheのデフォルトでは、モジュール版のPHPを使用するようになっています。
記事ではEvent MPMとFast CGI方式のPHP-FPMと組み合わせて高速化を図っています。
こちらもチューニングを行います。

MySQLの採用

現在、多くのディストリビューションで標準のデータベースサーバはmariaDBとなっています。
MySQLと互換性があり、PHP等からはMySQLとして操作することができます。
しかし記事では本来のMySQLを使用するようにしています。

通信路の暗号化とパスワード認証の排除

ウェブサーバだけでなく、メールサーバもSSL/TLS経由でアクセスするようにしています。
SSH接続はパスワード認証を使わず、公開鍵認証のみとしています。

なお記事ではFTPサーバを導入していません。これはCircleCIのようなCI/CDツールからSSHとGitを用いてデプロイすることを前提としているためで、この場合FTPサーバは不要です。
平文テキストでパスワードをやり取りするFTPサーバは、起動しているだけでセキュリティリスクにもなります。どうしてもFTPクライアントで操作したい場合はSFTP（SSHを用いたFTP）を採用することをお勧めします。

セキュリティと不正アクセス対策

EC2のセキュリティグループとfirewalldにより、不要なポートを外部に公開しないよう設定します。
例えばimaps/pop3sは公開しても、imap/pop3は公開しないようにしています。

他に、Fail2banによる不正アクセス対策（自動Ban / Unban）や、Logwatchの不具合修正も行います。

まとめ

本記事の目玉はSSL/TLS周りです。脆弱性診断で「A+」、少なくとも「A」を狙えるようにしています。
今はTLSv1.1までが無効になっていますが、いずれはTLSv1.2も無効になることが考えられます。
その際に同じようにレンタルサーバで対応に苦慮するようであれば、今のうちにクラウドへの移行を進めておいたほうが良いと思います。
AWSはIaaSとしては圧倒的シェアを誇るサービスで情報も豊富なため、幅広い層にお勧めできます。
担当者がわけわからんという場合はもちろん保守を含め委託が良いでしょうが、ある程度VPS等でサーバ構築に触れたことのある方であれば、この記事を参考にして構築してみていただければと思います。

WordPressがマルウェアに感染したり、ファイル等の改ざん被害を受けた際の対策をまとめました。

WordPressは狙われやすい

WordPressは、世界で最も多く利用されているオープンソースのCMSです。

しかし利用者が多いということは、ITリテラシーやセキュリティ意識の低いユーザーが多い可能性も高くなります。

りゅう

つまり悪意あるユーザーにとっては格好の標的となります。

ということで今に始まったわけではありませんが、WordPressは悪意あるユーザーに「常に狙われている」状態にあるとまず考えましょう。

名の売れたサイトが狙われやすいのは当然ですが、「自分のところはアクセス数が少ないから対策しなくても大丈夫だろう」と高をくくるのは危険です。

悪意あるユーザーが求めているのは、まさにそのようなセキュリティ意識の低いサイトです。

被害に遭ってから対策するのはかなり骨の折れる作業になりますので、事前にできる限りの予防をしておきましょう。

乗っ取り被害のチェック

WordPressの管理画面にログインし、左メニューの「ユーザー」を確認します。

もし自分以外のユーザーが不正に登録されていたら、即座に削除しましょう。

さらに自分自身のパスワードも、長く難解なものに変更します。WordPress側で自動生成することもできます。

adminユーザーに注意

WordPressでは、デフォルトの管理ユーザーがadminになっています。

これをこのまま放置するのはセキュリティ上好ましくありませんので、管理権限を持つ別ユーザーを作成して、adminは削除することをおすすめします。

ログインユーザー名が表示されるのを防ぐ

http://******.***/?author=1のように、自サイトのURLに/?author=1を追記してブラウザで表示してみてください。

管理者権限を持つユーザー名が表示される場合、これは危険な状態です。

WordPressの認証は基本的にユーザー名とパスワードの2要素で行いますので、そのうち1つがバレるというのはリスクが高いと考えてください。

手動でなんとかする方法

テーマディレクトリ内のauthor.php（無ければ作成）の内容を、以下の通りにします。

<?php
    wp_redirect(home_url());
    exit();

これで、authorのユーザー名を表示することなくトップページに強制転送します。若干無理やり感がありますが。

プラグインを使用する方法

Edit Author Slugというプラグインで対策できます。

ユーザーアーカイブのスラッグを変更することができますので、/?author=1のようにアクセスしても設定したスラッグのURLに転送され、ユーザー名が露呈することはありません。

りゅう

テーマによっては、ユーザー名の表示を無効化する機能を持っている場合もあります。

ログイン保護と不正アクセス対策

不正アクセスを防ぐためには様々な方法がありますが、まとめて行ってくれるプラグインがあります。

SiteGuard WP Plugin

りゅう

既に改ざんや乗っ取り被害の跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

SiteGuardは国産のセキュリティプラグインで、ログインページの保護と不正アクセス対策に特化しています。

上の画像のように、ログイン履歴を見ることもできます。

注目すべきは右端の「タイプ」で、ログインページではなくXMLRPCからのログイン試行（失敗）が並んでいる点です。私がそのような操作を行ったことはありませんので、これは不正アクセスの試行を受けていることを意味しています。

りゅう

XMLRPCとは外部からWordPressを操作する仕組みと考えてください。外部連携には便利な機能ですが、悪用されやすいというデメリットがあります。

SiteGuardでは、このXMLRPCを無効にする設定も可能です。

いくつかの機能がありますが、私は以下のように設定しました。

日本語で項目ごとに説明が記述されているので迷うことは少ないでしょう。

「ログインページ変更」では、/wp-admin/と決まっている管理画面のURLを変更することができます。想像できる通り、ログインページからの不正ログイン試行の多くを防ぐことができます。

「画像認証」は、ひらがなによる画像認証を追加することができます。コメントにも仕掛けられますが、筆者はログインページだけにしておきました。

「XMLRPC防御」では、XMLRPCそのものを無効にしました。具体的には.htaccessにxmlrpc.phpへのアクセスを禁止する記述が追加されます。

これでひとまず、不正ログインに関してはかなりセキュリティを強化することができます。

改ざんと不正ファイルのチェック

これらの被害に遭っているかどうかを手動で調査するのは、大変骨の折れる作業となります。

ここでは、セキュリティリスクをスキャンできるプラグインを使用して、被害に遭っているかどうかを確認します。

Wordfence Security – Firewall & Malware Scan

Wordfenceは、WordPress本体のファイル改ざんや、不正なファイルが作成されていないかをスキャンすることができます。

また、古すぎたり更新が停止しているプラグインはスキャン結果で警告されますので、代替となるプラグインを探すことをおすすめします。

Wordfenceは英語のプラグインですが、使用するのは一部機能のみで設定も特に要らないため問題になることはないでしょう。

何はともあれ、まずは上記プラグインをインストール、有効化します。

りゅう

既に改ざんや乗っ取り被害の形跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

管理画面の左メニューに"Wordfence"が追加されますので、そこから"Scan"を選択します。

"START NEW SCAN"ボタンをクリックすれば、WordPressインストールディレクトリ以下の全ファイルを調査してくれます。

この画像では左下部の"Results Found"が空になっていますが、これは改ざんや不正なファイルが見つからなかったことを示しています。

りゅう

日本語版WordPressではwp-config-sample.phpとreadme.htmlが「内容がオリジナルと異なる」と表示されますが、多くの場合正常です。
前者はPHPスクリプトなので、一応おかしなコードが埋め込まれていないか確認（後述）し、問題がなければどちらもIgnore（無効）にしてしまってOKです。

もし"Results Found"に改ざんされたファイルや不正に作成されたファイルが表示された場合、対策が必要です。

具体的には、以下のように対応します。

• 改ざんされたファイル：対象ファイルをエディタで開き、後述のようなコードが埋め込まれていれば該当部分を削除する。
• 不正に作成されたファイル：対象ファイルを削除する。

このスキャン作業は、たまに行って確認するようにしましょう。日々の作業が増えますが、被害に遭ってから対応するよりよほど楽です。

Live Trafficが便利

Wordfenceには、他にも様々な機能がありますが、主に使用するのは上記のスキャンと、"Live Traffic"です。

アクセスログをほぼリアルタイムに閲覧できる機能ですが、国名を見られたり、怪しいか問題のあったアクセスを色分けして表示してくれたりするので大変便利です。

この機能だけを持つプラグインもありますが、このように1本にまとめられているのは嬉しい限りです。

また、上の画像がまさにそうなのですが、不正なアクセスを行ったIPアドレスをブロックリストに入れることもできます。

りゅう

ただし攻撃者は自らのPCではなく様々な国にある複数の踏み台を操って不正アクセスを試みますので、多くの場合IPアドレスは一定ではありません。
したがって単一のIPアドレスをブロックすることには（無意味とは言いませんが）あまりメリットはありません。

改ざんされたファイルの修正

Wordfenceのスキャンで改ざんされたファイルが見つかったら、エディタで開いてみます。

おそらくファイルの先頭に以下のようなコードが不正に埋め込まれています。

<?php $xxxx = Array(/* 無意味に見える大量の英数字 */);
eval(xxxx_function($base64_data, $xxxx)); ?>

「無意味に見える大量の英数字」の部分をbase64でデコードすると、PHPのコードであることがわかります。

私は何度もいたちごっこを繰り返しましたが、改ざんされるファイルは毎回index.php, wp-config.php, wp-settings.phpあたりでした。

これらのファイルはWordPressが毎回必ず読み込むファイルであるため、悪意あるコードを埋め込むにはうってつけというわけです。

上記のようなコードを発見したら、エディタで不正コード部分の<?phpから?>までを削除してください。

りゅう

完全な原因究明と抜本的な対策が行われない限り、繰り返し改ざんが行われる場合があります。私もそうでした。

不正に作成されたファイルの削除

Wordfenceの"Live Traffic"の部分で紹介した画像のように、いかにもランダムで付けたファイル名である場合が多いですが、たまに意味ありげなファイル名になっていることもあります。拡張子は.phpです。

作成されるディレクトリはまちまちで、wp-admin/やwp-includes/の中であったり、wp-content/uploads/の中であったり、プラグインやテーマのディレクトリ内であったりします。深い階層内に作成されることもあります。

該当ファイルをエディタで開くと、コードは概ね以下のように難読化されています。

最後の方でeval関数によって文字列がPHPコードとして評価されます。

りゅう

実行されるコードは様々でしょうが、筆者の場合はSPAMを送信するコードになっていました。

攻撃者はこの不正に作成したPHPファイルにPOSTメソッドでアクセスし、実行してきます。これはアクセスログやWordfenceの"Live Traffic"で確認することができます。

この不正ファイルを放置するのは大変危険ですので、見つけ次第 問答無用で削除してください。

海外のIPアドレスを拒否する

いささか乱暴ではありますが、攻撃はほぼすべて海外のIPアドレスから行われますので、サイトの公開対象が国内のみであれば、海外からのアクセスをすべて遮断してしまう方法があります。

これは大変効果的で、攻撃者とのいたちごっこを繰り返していた私が最終的に問題を解決するに至った手法です。

遮断する方法はいくつかありますが、ここでは最も修正が手軽な.htaccessによるアクセス制限を紹介します。

以下は、私が採用している.htaccessです。内容は、以下のような流れになっています。

1. すべてのアクセスを拒否
2. Googleやfacebook, Twitterなどbotからのアクセスを例外として許可
3. 日本国内で使用されるIPアドレスを例外として許可（4千行以上）

Apacheのバージョンによってアクセス制限の書式が異なる点に注意してください。

▼Apache 2.2系を使用している場合

https://gist.github.com/ryu-blacknd/3625090cd46b2b60d7ce3700ae7d6b78

▼Apache 2.4系を使用している場合

https://gist.github.com/ryu-blacknd/59dc7f1dbf5c82a3be507a9acb0146d9

多くの場合、既に何かが書かれた.htaccessファイルが存在すると思いますので、その部分は残して上記コードを追記してください。

貼り付ける場所に悩んだら、# BEGIN WordPressの直前にしておけばOKです。

SPAM送信の踏み台にされた場合の対処

私が実際に被害に遭ったサーバの環境は、OSがCentOS 7で、MTA（メールサーバ）はPostfixです。

ここではPostfixであった場合、かつrootによる作業が可能な場合の対処方法を紹介します。

まずは現在溜まっているキューを確認します。

$ postqueue -p

送信した覚えのないメールがズラッと表示された場合、既にSPAM送信が実行されています。

この場合は以下のコマンドでまずキューを削除します。

$ postsuper -d ALL

上記対応によって問題が解決している場合は、このままPostfixの運用を続けて構いません。

まだ対策が完了していない場合はさらにキューが増加しますので、不本意ながらPostfixを停止しておきます。

$ systemctl stop postfix

当然ですが、Postfixを停止している間はメールの送受信が機能しません。なるべく早期に対策を終え、再度Postfixを起動します。

$ systemctl start postfix

一度SPAMの踏み台になってしまった以上、以後しばらくはキューの確認を行うことをおすすめします。

まとめ

既に書きましたが、最も効果的な対策は海外のIPアドレスを排除することです。

すべての対策を行っても解決しない場合、最終手段は再セットアップということになります。WordPressのファイル群をすべて削除し、素のWordPressから再度環境を構築をすることで、クリーンな状態に戻せます。

ただし事前にバックアップを取ることはもちろんですが、バックアップしたファイルをそのまま書き戻さないこともまた重要です。
プラグインやテーマは改めて新規インストールし、手動で以前の設定を復元するべきです。

この作業は困難かつ時間がかかりますので、できることならここで紹介した方法で解決したいものです。

最後になりましたが、WordPress本体やプラグイン、テーマのアップデートは無視せず実行してください。

りゅう

公開されたばかりのバージョンであっても脆弱性が発見されることがしばしばありますので、常に目を光らせておいてください。