2月 162013
 
この記事の所要時間: 654

どうも、よく分からないなりにWordPressを使っているkuronama です。

WordPressのセキュリティ

先日以下の記事を読んで、WordPress用の2要素認証の存在を知った。
WordPress のセキュリティ: リスクを減らす5ステップ (Sucuri Blog より訳出) | わーどぷれすっ!


記事の大部分が翻訳であり結構ボリュームがあるので該当部分を抜粋すると

ウェブサイトのオーナーが直面するもうひとつのアクセスコントロールに関する危険性は、WordPress のログインページ – /wp-admin もしくは /wp-login.php – に対するブルートフォースアタックです。これには簡単な対処方法が2つあり、そのひとつは WordPress の管理画面のログインに2要素認証を導入することです。もしご存じなければ Google Authenticator プラグインをチェクしてみてください。これはとてもうまく機能しますし、Google Authenticator を導入済みであれば、既存のツールやデバイスの多くでも機能することはご存知かと思います


ということらしい。

ブルートフォース攻撃ってのは、要はパスワードに対して総当たり攻撃を行うこと。ログインIDが判明している状態で、そのIDに対してパスワードを総当たりで自動入力してログインを試みる攻撃手法。
管理者ユーザーとしてWordPressのデフォルト設定である「Admin」をそのまま使っているサイトの場合は既にログインIDが攻撃者にバレているわけで、かなり有効な攻撃手法と思われる。
仮に今回の記事の手法を導入しないとしても、最低限以下の記事を参考にAdmin以外のユーザーを作成・移行して、Adminを削除しておいた方が良いだろう。

WordPressでユーザー名『Admin』をやめてみる。 – HAAYA


ブルートフォース攻撃に対しては特定のクライアントからのログイン失敗回数に上限を持たせることで対応するのが正道だと思うけど、ログインによる認証に本来のパスワードとは別にワンタイムパスワードを使えば良いよってことが書いてある。
確かに長さすら不明なパスワードが2つに増えるだけでも攻撃の手間は増えるし、ましてや片方がワンタイムパスワードであればまず攻撃は成功しないだろう。


少しだけ調べてみたら記事を投稿したユーザ名は簡単に判別できるので、デフォルトの「Admin」以外でもブルートフォース攻撃は有効な攻撃になるっぽい。
なのでWordPressにおいてブルートフォース攻撃に対する唯一?の対抗手段は2要素認証の導入と思われる。

「WordPressに対するブルートフォース攻撃に対抗して2要素認証プラグインを導…」の続きを読む

2月 152013
 
この記事の所要時間: 558

どうも、そろそろラブライブ以外の記事を書かないと検索サイトにラブライブBlogだと思われかねないと危機感を抱いている@kuronamaです。

WordPressのバックアップ

本Blogは月額のレンタルサーバーにWordPressをインストールして運営している。
まぁ毎回ろくでもない記事しか書いていないが、それでも日に数百のアクセスはあったりするようなので日々のデータバックアップには気を遣っている。

WordPressのバックアップにおいて多分メジャーなプラグインというと「WP-DBManager」だと思う。
WP-DBManager(WordPressデータベース・バックアップ用プラグイン)の導入と使い方


このプラグインは記事データが入ったMySQLのテーブルをバックアップするというものだ。
実際自分も元々このプラグインを使っており、日次でGmailにバックアップデータを添付して送信されるようにしていた。

だが「WP-DBManager」の場合は最初に書いた通り、記事データしかバックアップしてくれない。
リストアする際には記事データ以外のWordPress本体やプラグインは入れ直しになる。
もしくは他の方法でバックアップを取得しておく必要がある。
Linuxの知識があればなんかコピー系のコマンドをcronに登録とかして日次バックアップできるんだろうけど、面倒そうだなぁと思っていたところちょうど良いプラグインを見つけた。

BackWpup

それが以下の記事で紹介されていた「BackWpup」というプラグイン。
WordPressのバックアップ方法 – 全データの自動バックアッププラグイン「BackWPup」の使い方 | WP SEOブログ


このプラグインでは記事データであるMySQL上のテーブルはもちろん、サーバー上のWordPressのデータもバックアップしてくれる。
もちろんオプションでバックアップ対象を細かく変更できる。

またこのプラグインの一番嬉しいところは、バックアップ先が豊富なところ。
参考にした記事ではDropboxを使っている。
個人的にはDropboxは他の用途でガッツリ使っていてできれば使いたくなかったので、サービス開始当初アカウントだけ取得して放置してたSugarSyncを使うことにした。
SugarSyncもDropboxと同じく複数端末間でのファイル同期をウリとするサービスだが、今回の用途では別に各端末にファイルを同期させる必要は無かった。
なので保存場所にはウェブアーカイブを使ってみた。
同期不要のファイルはウェブアーカイブに保存しよう – SugarSync使い方マニュアル


これによりデータはサーバ上にのみ保存され、クライアントには同期されない。

ただSugarSyncを使うに当たって注意点があって、どうもアップロードに時間がかかりすぎると失敗するらしい。自分の環境では今のところは大丈夫だが詳しくは以下の記事を参照。
どうやらBackWPupのリトライに関連する仕様の問題のようで、プラグインのファイルを直接編集して修正するらしい。

BackWPupでのWordPressバックアップとリストアに関するFAQメモ | 情報科学屋さんを目指す人のメモ
BackWPup を SugarSync にできた! その設定方法 | thikasa note …


上記を踏まえた当Blogのバックアップ設定は以下。

  • DB、WordPress本体のフルバックアップ
  • バックアップと同時にデータベースの最適化とチェックを行う
  • ジョブ実行間隔は毎日午前4時
  • バックアップ先はSugarSyncのウェブアーカイブ上のフォルダ
  • バックアップの世代は7世代(1週間)管理
  • バックアップの結果に関係無くGmailにログを送信
    最初の1週間くらいはログを確認して様子見してたけど、問題無いようなので現在はエラー検出時のみログ送信

以下が現在のSugarSyncのバックアップ対象フォルダ内。
バックアップを採り始めてから10日くらい経っているはずだが、ちゃんと世代管理してくれているようで7世代を超えたファイルは自動的に削除されているようだった。
sugarsync

まとめ

ちなみにバックアップ容量は現在のところ150MB程度で、バックアップにかかる時間はSugarSyncへのアップロードと旧世代削除も込みで10分以下だった。
リストアに関してはMySQLのデータとサーバ上のファイルで方法が分かれる。
サーバ上のファイルについてはFTPソフトなんかでそのままサーバ上にアップロードすれば良い。
MySQLのデータに関しては、WordPressのサイドバーから[BackWPup] – [Tools]を実行する必要がある。

唯一不安な点としてはリストアした際のファイルパーミッションがどうなるか。
まぁ既にWordPress自体がインストールされた状態でリストアすることになるので、WordPressが動かないようなことにはならないと思うけど。