カテゴリー: WordPress

WordPressのバックアップに必要な作業

３月から始めたブログの作成もそろそろ記事の数が５０に近づいてきたので、バックアップをとっておこうと思います。

原稿（文章）はダッシュボードからエクスポート、画像はフォルダのバックアップ

細かく言うとWordPressのアカウント設定などもバックアップしておいた方が良いと思いますが、記事のバックアップという意味では、原稿をエクスポートしたときに生成されるXMLファイルと画像やプラグイン等が含まれるフォルダを固めたZIPファイルがあれば良さそうです。

１．原稿のエクスポート

WordPressダッシュボードの左ペインから「ツール」-「エクスポート」を選択すると以下の画面が表示されます。
以下の画面のとおり「すべてのコンテンツ」を選択し、「エクスポートファイルのダウンロード」をクリックしてください。

すると「サイト名.WordPress.日付.xml」という名前でこれまで投稿したすべての原稿がダウンロードされます。
このファイルを適切な場所に保管しておきます。

２．wp-content フォルダの圧縮＆ダウンロード

PCからWordPressのサーバにsshでログイン後、wordpress/htdocsディレクトリに移動します。（以下はAWSのbitnamiを利用している場合の場所）

/opt/bitnami/apps/wordpress/htdocs

この配下に wp-contentディレクトリがありますので、このフォルダ配下を丸ごとバックアップしておきます。

ディレクトリ配下を丸ごとバックアップするには、以下のコマンドを実行します。

zip -r wp-content.zip wp-content

-r オプションをつける事で、wp-content 配下にサブフォルダがある場合でも再帰的にバックアップしてくれます。
wp-content.zip はバックアップするファイルをまとめるZIPファイルの名前です。

zipファイルを作成したら、あとはそれを自分のPCにダウンロードするだけです。
ダウンロード方法は以下の通りです。自分のPCからWordPressにsshでログインできるようにしていれば、これでダウロードできると思います。

scp -i hogehoge.pem bitnami@xxx.xxx.xxx.xxx:/opt/bitnami/apps/wordpress/htdocs/wp-content.zip .

hogehoge.pemにて、sshの認証キーを指定してください。
また、xxx.xxx.xxx.xxxではWordPressサーバのIPアドレスを指定してください。

Zipファイルがダウンロードできたら、xmlファイルと同じく、適切な場所にバックアップしてください。

以上でバックアップが完了しました。できれば、InstantWPなどの環境を利用して正常に復元できることを確認することをお勧めします。

インスタンスをEIP（固定IP）にしてWordPressのSEOが変わるか確認してみた

WordPressをAWSで立ち上げてから、インスタンスのIPはパブリックIPのままにしていましたが、これだとインスタンスを再起動する度にIPが変わってしまう為、SEO 上よろしくないのではないかとおもっていました。
そこで今回、IPを固定にするEIP（Elastic IP）に変えてみて、検索結果が上位にくるようになるか確認してみることにしました。

パブリックIPからEIPへの変更は非常に簡単

もしかしたら、EIPにするとDNSの情報も書き直さないとアクセスできなくなるのではないかとおもっていましたが、そんな心配は無用でした。
以下の手順でEIPを作成し、既存のインスタンスに紐づけるだけで完成です。

１．EC2の画面に移動

Elastic IPを設定する為に、EC2の画面に移動します。

２．EIPの作成

左ペインからElasitic IPを選択すると、以下の画面が表示されますので、右上にある、「Elastic IP アドレスの割り当て」ボタンを押します。

すると以下の画面が表示されますので、AmazonのIPv4アドレスを選択したまま、「割り当て」ボタンを押します。

これで以下の通り、EIPとして割り当てられるIPアドレス（下の例では18.X.X.X）が決まります。

３．EIPのインスタンスへの割り当て

次に、先ほどのIPアドレスをチェックボックスでチェックした後、右上の「Actions」と書かれているプルダウンから「Elastic IP アドレスの関連づけ」を選択します。

Elastic IPアドレスは必ずインスタンスに割り当てましょう。

割り当てしていない Elastic IP アドレスは課金されるらしいので、必ずインスタンスに割り当てておきましょう。　

すると、以下の画面が表示されますので、インスタンスのプルダウンからElastic IPを割り当てるインスタンスを選択し、「関連付ける」ボタンを押します。
プライベート IP アドレスも指定できるようですが、ここはオプションのようで何もしなくても勝手にプライベートIPアドレスが割当たるので、放っておいてよいようです。

これで以下の通り、インスタンスにElastic IPが割り当たりました。

パブリックIPアドレスから Elastic IPに切り替える場合、これで作業は完了です。DNSの設定変更などは不要で、いままでのドメイン名でインスタンス上で動いているWordPressにアクセスできました。

EIPに切り替えても。。。

いまのところWordPressへのアクセスは増えていないので、SEOは変わっていない気がします。。。ね。

AWS上のWordPressから 自ドメインでメールを送信をする

以前、AWS上でWordPressを立ち上げ、WP Mail SMTP プラグインを使ってメールを送信できるようにしました。

しかし、その時に設定した環境では、送信されるメールの送信元アドレス（Googleのメールアドレス）と送信元サーバ（Amazon）が異なる為、受信したメーラー側で以下のような警告が発生してしまいます。

自分にメールしているだけなので大きな問題はありませんが、ちょっとかっこ悪いのと、SPFやDKIMが使えるかどうかも確認してみたかったので、AWSから自ドメイン（k-ornata）のメールアドレスを送信元にしてメールを送信してみることにしました。

Amazon SES に送信元ドメインを登録し、Route 53にレコードを登録するだけでOK

DNSとしてroute53を利用している前提ですが、Amazon SES に送信元にしたいドメインを登録し、その勢いでroute 53に必要なレコードを登録するだけで設定が完了します。

１．SES から自ドメインを登録

SES Homeにアクセスし、左ペインから Domains を選択します。

「Verity a New Domain」をクリックし、以下の通り、自ドメイン名の入力と、「Generate DKIM Setting」のチェックを入れます。

２．Route 53へのレコード追加

上の画面で「Verity This Domain」をクリックすると、以下のようにDNSサーバに登録するTXT, CNAME, MXレコードの情報が表示されます。
今回はDNSとして Route 53 を使いますので、「Use Route 53」のボタンを押すだけです。

すると以下のように確認画面が表示されますので、必要に応じて（自ドメインでメールを受信したい場合）「Email Receiving Record」にチェックを入れ、「Create Record Sets」にチェックを入れます。

すると、以下の画面が表示され、ドメインの確認とDKIMの設定をAWSが自動で開始してくれます。

処理が完了（だいたい5分くらい）すると、（AWSコンソールの？）管理者のメールアドレスに、以下２通のメールが送られてきます。

ドメインの確認が完了した旨の通知メール
DKIM の設定が完了した旨の通知メール

メール受領後、再度、SES Home の Domainsを確認すると、ステータスが pendingから verified に変わっているのが確認できます。

３．自ドメインでのメール送信確認

以上で自ドメインでメール送信できるようになりましたので、テストメールを送ってみます。
以下のとおり、SES Home のDomains から今回登録したドメインにチェックし、「Send a Test Email」を押します。

すると以下のとおり、テストメール送信用のウィンドウがでますので、各項目を入力し、「Send Test Mail」を押します。

すると、Toで指定したメールアドレスにテストメールが送られてきます。

上記のとおり、Fromがちゃんと自ドメインで送られてきており、SPFやDKIMもパスしています。（簡単すぎて、SPFやDKIMの理解にはつながらないかもしれませんが。。）
なお、Fromの@の左側は（たぶん）何でも大丈夫です。（ユーザの有無とかは気にしなくてよさそうです。）

また、ToはSES Home のEmail Addressesにてverifiedになっているものを使ってください。もしそれ以外のアドレスに送付しようとすると、以下のように「検証されていない」と怒られます。

これはセキュリティ面を考慮し、デフォルトでは検証済のアドレスにしか送れないようにしているらしいです。（これを解除する方法があるらしいですが、ここでは触れません。）

４．WordPressのWP Mail SMTP の送信元アドレスを自ドメインに変更

WordPressからメールを送信する時にWP Mail SMTP プラグインを使っている場合、その送信元アドレスを今回設定した自ドメインのものに変更します。
そしてテストメールを送信してみると、以下の通り、自ドメインのメールアドレスからメールが送信されてくることが確認できます。

これでWordPressのメール環境はスッキリしましたが、あまりにも簡単だったので、SPFやDKIMの勉強にはならなかった気がします。
機会を見て、もうすこし掘りさげてみたいと思います。

WordPressのユーザIDへのDoS攻撃対策

WordPressへのブルートフォース攻撃が気になっていたので、Limit Login Attempsというプラグインを最近導入しました。
そしてそのログを確認したところ、デフォルトユーザへのDoSが多数発生しているのに気がついたので、別のユーザIDを作成し、そのアカウントでログインするようにしていました。
しかしながら、そのユーザに対してもすぐにブルートフォース攻撃が発生していました。
そこでなぜ、新たに作成したユーザIDがすぐにバレてしまったのか調べてみることにしました。

ブログに投稿者名が表示されており、また投稿アーカイブなる機能が有効になっていました。

そこで以下の対策を実施することにしました。

１．ブログ上の投稿者名をユーザIDからニックネームに変更

これはすぐに気がつかない私も悪かったのですが、ブログ上に表示されている投稿者名が、ユーザIDのままとなっていました。これをまずニックネームに変えました。

これは[ユーザ]の「ブログ上の表示名」から簡単に変えることが可能です。

２．投稿者の名前を表示させない

１．の対策をしていればこれは必要ないかもしれませんが、私の場合、記事を投稿するとその投稿ページに誰が投稿したから表示されるようになっており、さらに１．の対応を実施していなかった為、投稿者名としてユーザIDがそのまま表示されていました。

そこで以下の通り、content.phpの50行目付近にある、twentysixteen_entry_meta()関数の呼び出しを無効化しました。（Twenty Sixteenテーマの場合）

[外観]-[テーマエディター]から[個別投稿(single.php)]のcontent.phpを編集

上記の変更後、更新を保存した瞬間から、以下のようにユーザIDを含めたメタ情報が表示されなくなります。

３．投稿アーカイブのパスと名前を変える

これは全く知らなかったのですが、以下のようにWordPressのFQDNの後ろに”?author=番号”を入力すると、WordPressの各アカウントで作成した記事のアーカイブをまとめて見れるようになっているようです。

https://WordPress_FQDN/?author=1

そのアーカイブを表示する時のURLがデフォルトで以下のようになっており、何も対策をしていないと、WordPressに登録しているユーザIDがバレバレとなってしまいます。

https://WordPress_FQDN/author/ユーザID/

これを防ぐ為には、Edit Author Slugというプラグインを導入するのが簡単です。

上記のプラグインを導入後、まず、WordPressダッシュボードの[設定]-[Edit Author Slug]の画面にて、上記の”author”というパス名を変更することができます。（「投稿者ベース」という項目にて変更可能。）

また、このプラグインを導入すると、WordPressダッシュボードの[ユーザ]-[あなたのプロフィール]の画面で一番下までスクロールさせた時に「投稿者スラッグ」という項目が追加されており、ここで、上記の”ユーザID”に表示される名前を変えることが可能です。

実際のユーザIDによるブルートフォース攻撃が激減

以上の３つの対策を実施後、いまのところ、実際のユーザIDで攻撃されることはなくなっており、逆にニックネームやEdit Author Slugで設定したダミーのユーザIDで攻撃されております。
やはり、攻撃者の方は投稿名や投稿アーカイブスの情報を元に攻撃を仕掛けているようですね。

Social Bookmarking Lightで表示していたSNS共有ボタンが表示されなくなった

なぜか最近、WP Social Bookmarking Lightで設定したSNSの共有ボタンが表示されなくなりました。
今のところ原因はわかっていませんが、暫定的に表示させる方法が分かりましたので、その時の作業メモをアップしておきます。

暫定対処として[外観]の[テーマエディター]を編集

１．WordPress管理画面の[外観]-[テーマエディター]から[個別投稿]（single.php）を選択します。

２．その配下にあるtemplate-partsのプルダウンを開き、content.phpを開きます。

３．以下の行をentry-contentクラスの下などに挿入します。（以下の例では47行目に挿入）

<?php if(function_exists(“wp_social_bookmarking_light_output_e”)){wp_social_bookmarking_light_output_e();}?>

[外観]-[テーマエディター]からcontent.phpを編集

４．最後の「ファイルを更新」ボタンを押すことでSNSの共有ボタンが表示されるようになりました。

共有ボタンが表示される場所は、利用されているWordPressのテーマによって少しかわるかもしれません。

今回、初めてWordPressのphpを直接編集してみました。これをきっかけにすこしphpの勉強をしてみるものいいかもしれませんね。

AWS上に作成したWordPressのMysqlに接続し、ユーザの権限を変更する方法

WordPressのセキュリティを高める為にLimit Login Attemptsというプラグインを入れたところ、予想以上にアカウントへの不正アクセスがあることがわかりました。
そこで、デフォルトで利用していたユーザIDの権限を変えることにしました。
しかし、その時に操作をミスして自分がログインできなくなってしまう可能性もあります。
そこで事前に、直接mysqlに乗り込んで、ユーザの権限を変える方法を確認することにしました。

以下の手順でmysqlの情報を直接操作可能

１．sshでサーバにログイン

ここは大丈夫でしょう。AWS上でbitnamiのインスタンスを作成した際にログインできるようにしているはずです。

２．mysqlにログイン

そもそもmysqlにログインする為のID/PASSWORDはどこにある？ということなですが、以下のファイルの中に書かれています。

/opt/bitnami/apps/wordpress/htdocs/wp-config.php

このファイルの中で「DB_NAME」「DB_USER」「DB_PASSWORD」として、それぞれデータベース名、ユーザ名、パスワードが記載されていますので、メモしておきましょう。

その後、以下のコマンドを実行後、パスワードを入力すればログインできます。（※DB_USERはユーザ名に置き換えてください。）

mysql -u DB_USER -p

３．データベースの指定

ログイン後、テーブルを確認しようと show tables; などのコマンドを実行しようとすると以下のエラーが表示されることがあります。

ERROR 1046 (3D000): No database selected

これは操作するデータベースが指定されていないので発生しています。
したがって、テーブルを操作する前に以下のコマンドを実行し、データベースを指定してください。（以下の場合は、データベースとして”bitnami_wordpress”を指定しています。）

mysql> use bitnami_wordpress

４．テーブルの確認（ユーザIDの確認）

これで操作するデータベースが指摘できましたので、まずは、wp_usersというテーブルの中身を覗いてみます。
以下のコマンドでは、”hogehoge”ユーザの情報を表示させています。また、最後に”¥G”をつけることで出力結果を見やすくしていますが、その代わりに”;”をつけても大丈夫です。

mysql> select * from wp_users where user_login = “hogehoge”¥G

この結果により、”hogehoge”のユーザID（user_id）が分かりました。これでユーザ権限変更の準備が整いました。

５．テーブルの更新（ユーザ権限の更新）

４．で取得したuser_idでwp_usermeta テーブルを検索します。以下のコマンドを入力してください。（※user_idは実際のユーザIDに置き換えてください。）

mysql> select * from wp_usermeta where user_id = “user_id“\G

出力されたテーブル情報の中で、meta_key が wp_capabilities とwp_user_levelの部分を書き換えることで、ユーザ権限を変えることが可能です。
たとえば、管理者に権限を変更する為のコマンドの例は以下の通りです。（※user_idは実際のユーザIDに置き換えてください。）

mysql> update wp_usermeta set meta_value=’a:1:{s:13:”administrator”;b:1;}’ where user_id=”user_id” AND meta_key=”wp_capabilities”;
mysql> update wp_usermeta set meta_value=10 where user_id=”user_id” AND meta_key=”wp_user_level”;

参考までに、管理者と投稿者の設定値を記載しておきます。

権限wp_capabilitieswp_user_level
管理者a:1:{s:13:”administrator”;b:1;}10
投稿者a:1:{s:6:”author”;b:1;}2
ユーザ権限と設定値

これで権限設定を間違ってしまっても、mysql側から何とか変更できますね。

デフォルトのユーザIDをそのまま利用するのは危険

私のようにブログを立ち上げたばかりでも、数十件の不正アクセスが発生している状態ですので、ブログを立ち上げたらすぐにデフォルトのIDから新規に作成したIDにお引っ越ししたほうがよいと思います。

AWS上のWordPressで管理者メールアドレスを変更する方法

WordPressを導入し、管理者のメールアドレスを変更する際に、変更後のメールアドレスにメールを送って承認を取ろうとしますが、メールが送れずに承認待ちとなり変更できないことがあります。

その際にWP Mail SMTP のプラグインを導入すればよいという記事をたくさん見かけますが、AWSの場合は、それだけではメールがまだ送れません。

メールが送れない場合、以下の対応が必要になります。

AWS SES をセットアップし、その情報をプラグインに登録しよう

WP Mail SMTP のプラグインをセットアップする前に、AWS SES(Simple Email Service)をセットアップし、その SES 経由でメールを送信する必要があります。
また、送信できたとしても、Gmail の場合、SPAMとして判定されてしまうことがありますので、SPAMフォルダも確認する必要があります。
プラグインは導入されている前提で、その後、以下の手順で対応していけば、メールが送信できるようになります。

１．AWS SESをセットアップ

AWS SESをセットアップし、認証の為のID、パスワードを取得します。

AWS SESを選択すると、自動的にUSリージョン（バージニア北部）に飛ばされ、SESのホームが表示されます。

そこで、左の枠から[Email Address]を選択し、[Verify a New Email Address]を選択すると、以下のポップアップが表示されますので、メールを送信したいE-mailアドレス登録し、 [Verify a New Email Address] ボタンを押してください。

そうるすと、メールが入力したE-mailアドレスに送られてきますので、リンクをクリックして承認してください。

次に SESホームの左の枠から[SMTP Setting]を選択し、右枠に表示されるServer NameとPortをメモした後、[Create My SMTP Credentials]ボタンを押します。

そうすると以下のようにIAM User Nameが表示されますので、そのまま[作成]ボタンを押してください。SMTPユーザー名とパスワードが作成されますので、メモしておきます。

２．WP Mail SMTPプラグインの設定

AWS SESの情報を以下の通りプラグインにセットアップします。

・SMTPホスト：SESの Server Name
・SMTPポート： SESの Port
・SMTP Username：SESの SMTPユーザー名
・SMTP Password：SESの SMTP パスワード

この後、メール送信テストをしてください。

３．テストメールが届いていることを確認

送信先にメールが届いていることを確認しますが、Gmailの場合は、SPAMフォルダに振り分けられる場合がありますので、そちらも確認してください。

４．WordPressの管理者メールアドレスを変更

これで、変更後のWordPressの管理者メールアドレス宛にメールが送れるようになります。 届いた変更確認メールのリンクをクリックし、承認してください。無事メールアドレスが変更できているはずです。

WordPressを公開する場合にDNS設定でハマるポイントは？

AWS上にWordPressを構築した時に一番手こずったのが、DNSの設定でした。

設定自体はそんなに難しくありませんが、ドメインを登録してから実際にそのドメイン名でアクセスできるようになるには、いくつか時間が掛かる場所があります。

私の場合、うまく行っているか不安になり再度余計な設定をしてしまい、さらに時間がかかる結果となってしまいました。

そこで途中で焦らない為の確認方法を記載しておきます。

Whois, nslookupの順で反映状況を確認

AWS上でのWordPress構築から実際にドメインでアクセスできるようになるまでには、以下のステップで実施していきます。

１．AWS上でWordPressを構築
２．IPアドレスでWordPressにアクセスできることを確認
３．ドメイン名の取得（お名前.com）
４．Route 53の設定（AWS）
５．ネームサーバ情報の登録（お名前.com）
６．DNSレコードの登録（お名前.com）
７．ネームサーバ情報の登録内容確認（お名前.com）
８．DNSレコードの登録内容確認（お名前.com）
９．whoisでドメイン登録状況の確認
１０．nslookupでドメイン登録反映状況の確認
１１．数時間待つ

なお今回は「３．ドメイン名の取得」「５．ネームサーバ情報の登録」「６．DNSレコードの登録」については、お名前.comで作業しました。

以降では、今回手こずった「７．ネームサーバ情報の登録内容確認」以降の手順について記載していきます。

ネームサーバ情報の登録内容確認

「お名前.com」でネームサーバ情報を登録した後、「ドメイン詳細」で「ネームサーバ情報」を確認してみます。

いろいろいじっているといつまにか設定が外れていることもあるので注意してください。

DNSレコードの登録内容確認

次は、DNSレコードの設定から、CNAMEが正しく登録されているか、再度確認してみみます。

この設定をする際に最後に”.”（ドット）があると怒られるので、VALUEの最後は”aws”で終わっているはずです。

Whois確認

以上のようにネームサーバ情報とDNSレコードが正しく設定されていれば、nslookupが可能となっているはずです。

まずその前に、whoisに情報が登録されているか確認してみましょう。
Whoisサイトに行き、Whois情報検索を実施し、以下のようにIPアドレスが表示されていれば問題ないはずです。

この時、AWS上のインスタンスの「IPv4 パブリック IP」と一致している必要はありません。このIPはAWSのサービスエンドポイントを示しているらしいです。

心配なら同じサイトでこのIPを使って逆引きしてみると良いと思います。

nslookupによるドメイン登録反映状況の確認

nslookupサイトに行き、ホスト名からIPアドレスが表示されれば、AWSのサービスエンドポイントまでは到達できるようになっているはずです。

しかし、ここまでたどり着けても、まだドメイン名でWordPressにアクセスできな場合があります。
それは、AWS内でDNS情報の伝達に時間がかかっている場合があるからです。

数時間待ってみる

アクセスできないからと言って、すぐにネームサーバ情報やCNAME情報を再設定したりしてはいけません。

そうすると、再度設定情報が反映されるまでに数時間を要してしまうことになります。（私の場合、一度ネームサーバを初期化し、再設定してしまった為、丸１日程度、反映に時間がかかってしまいました。

またもう一つの注意点としては、AWS上のWordPressのインスタンスを一度落としてしまうと、再度立ち上げてもすぐにドメイン名でアクセスできなくなってしまいます。

おそらくインスタンスを落とすことでAWS内のDNSレコードの反映が消えてしまい、再度反映されるのに時間がかかる為だと思われます。

うまくドメイン名で接続できた後は？

もし今、ドメインにHTTPで接続しているのなら、HTTPS（SSL通信）に変えた方が良いです。

特に、WordPressの管理画面に入る場合にはログインIDとパスワードを入力するが、それが盗聴されてしまう恐れがあります。

また最近のグーグル検索ではHTTPSのサイトが優先的に表示されることもあり、そう言った意味からもHTTPSにする意味は大きいと思います。

InstantWPをMacで動かすとlibnettle6.dylibのエラーが出る場合の対処方法

最近ブログに興味を持ち始めた為、WordPressを使ってみることにしました。
しかしながらいきなりサーバを立てるのは難しとおもったので、Mac上で簡単に仮想サーバを構築できるInstantWPを導入してみることにしました。

しかし、Macの初期設定はセキュリティが厳しい為、最初はうまく動作しませんでした。
具体的にはFinderからStart-InstantWPを起動してみると、「”libnettle.6.dylib”は、開発元を検証できないため開ません。」というエラーが起動中に発生し、 InstantWPのコントロールパネルは表示されるのだが、「WordPress Admin」をクリックしても正常に接続できない状況でした。

sudu spctlコマンドで一発解決

このエラーは、事前に以下のコマンドをMacのターミナルで実行することで一発解決しました。

sudo spctl – -master-disable
※masterの前の”-“は続けて入力してください。ここでは２つ”-“があることをわかりやすくする為、間にスペースをいれていますので、コピペする場合は注意してください。

このコマンドを実行した後、OSのパスワードを入力すればOKです。
そして、Start-InstantWPを再度実行すると、今度はエラーが発生せず、「WordPress Admin」に接続できます。

ただし、このコマンドはMacのセキュリティを下げてしまうので、InstantWPを利用し終わった後は、以下のコマンドで元に戻しておきましょう。

sudo spctl – -master-enable

セキュリティとプライバシーを確認してみよう

実は上のコマンドを実行すると、Apple Storeや確認ずみの開発元からのアプリケーション以外も自由に実行可能になります。

Macの「システム環境設定」から「セキュリティとプライバシー」を選択してみよう。コマンドを実行した後は下図のように「すべてのアプリケーションを許可」という選択項目が増えている事が確認できます。

まずはローカルでWordPressを試してみましょう。

これで無事にWordPressの管理画面にログインでき、操作感をつかむ事ができるようになります。
そしてこの後、実際にインターネット上にサーバを構築し、WordPressを導入してみることにしました。

http://k2-ornata.com/wordpres-and-dns/