10
22
2017
WordPress KUSANAGI 環境をカスタマイズする(その1)
WordPress KUSANAGI を自分のサイト運用ポリシーに合わせる
WordPressについては今更言及するまでもないだろうが、巷で話題の 『超高速WordPress仮想マシン KUSANAGI』を使用している人は果たしてどのくらい居るのだろうか.
“KUSANAGI” はWordPressを高速に動かすために特別にチューニングされたWordPress実行環境パッケージでOSイメージも含めた仮想マシンイメージとして提供されている.”KUSANAGI”がどういう物かは開発提供元のプライムストラテジーさんのホームページを参照して貰う事にして、今回はこの “KUSANAGI” 環境を自分流にカスタマイズする方法を紹介することにする.
何故 “KUSANAGI” 環境のカスタマイズを行うのか
プライムストラテジーさんが提供しているKUSANAGI仮想マシンイメージ(ディストリビューション)は、何も考えなくとも最初からほぼ最適化されたWordPress環境が構築されており、自分でOSやWEBサーバ、PHPなどのアプリケーションパッケージ類をインストールすることなく、簡単にWordPressサイトを立ち上げることが可能だ.
WEBアプリやOS等の専門知識を持たないWEBデザイナーなどがサイトを簡単に立ち上げる事ができるという意味ではお誂え向きのディストリビューションだ.それなりのセキュリティー設定も施されており、ユーザがサーバ環境を一から構築しなくても良い反面、”KUSANAGI” の標準的なシステム構成や運用形態を外れるような事は想定されていない.つまりお仕着せの環境でしか使えないと言うことだ.
“KUSANAGI” のディストリビューションは ConoHa VPSやさくらクラウド(VPS)、AWSなどでも幅広く提供されているので、VPSやAWSの利用経験があれば導入自体はとても簡単だ.但し、”KUSANAGI” のディストリビューションは皆共通のシステム運用環境となるように作られている.全ての”KUSANAGI”サイトはIPアドレスやドメインこそ異なるものの、OSから上の環境は皆殆ど同じと言うことだ.
この金太郎飴的なサイト構成環境は運用面、特にセキュリティー面で大きなリスク要因を抱えてしまう事になる.攻撃者から見ればサイト構成環境が同じシステムが多数存在しているという事はそれだけでもターゲット化し易いという事だ.
“KUSANAGI” の問題点
・”kusanagi” というOSユーザアカウントの存在
サイトの運用管理用のアカウントが存在する事自体は問題ではないが、全てのサイトのコンテンツ管理・運用アカウント名が “kusanagi” UID(1001) ,GID (1001)という事が明白になっている.ホームディレクトリの位置も “/home/kusanagi/” である.
・WordPressのトップディレクトリの位置が “/home/kusanagi/xxxxx/DocumentRoot/” に限られる
・マルチサイト(サブドメイン・サブディレクトリ)を構成することが困難
“KUSANAGI” の標準的なサイト構成は、1サーバあたり1ドメインを前提に組まれており、サブドメイン別に複数のWordPressサイトを構築したり、サブディレクトリ配下に複数のWordPressサイトを構築するような設計になっていない.勿論、OSの設定やApache(NGINX)、PHP類、DBなどの個々の構成を変更して、自分でカスタマイズすれば出来ないことは無いが、多大な苦労を背負い込むことになるだろう.
これらの問題点を見過ごすことができるのであれば、”KUSANAGI” 環境はデフォルトのまま運用するのが得策だ.カスタマイズした環境ではOSやアプリケーションパッケージの構成管理やパッチ充てなど全て自己管理が必要だ.下手にパッチを充てるとシステム自体が動かなくなってしまう可能性も高いので、腕に覚えの無い限り”KUSANAGI”環境のカスタマイズはお薦めしない.
ConoHa VPS上に標準 “KUSANAGI” 環境を構築してみる
先ずは、ConoHa VPSの機能紹介も兼ねて”KUSANAGI” 環境をConoHa VPS上に作成してみることにしよう.”KUSANAGI” の推奨環境は メモリ4GB以上という事の様だが、これは企業などのホームページを運用するときの推奨スペックで、このサイトのような個人ベースの小規模マイナーサイトではこんな贅沢なサーバスペックは不要だ.とりあえず ConoHa VPSの 2GB Memプラン(3 vCPU, SSD 50GB)をテスト用に選んでみることにする.テストのための短期間テンポラリ用途なので料金は気にしない(せいぜい数日程度)ことにする.ConoHa VPSが便利なのは、初期費用ゼロ、クラウドライクな時間課金なので、今回の様なテストサイト構築には最適なサービスだ.
“KUSANAGI” アプリケーションテンプレートからの仮想マシンのデプロイ作業
ConoHa VPSの管理コンソールにログインし、画面左端の操作タブから ”サーバの追加” を選び、仮想サーバの追加作業を行う.
ConoHa VPS管理コンソール上の “サーバ追加” 画面で “KUSANAGI” のデプロイ作業を行う
画面の設定項目は簡単なので特に難しい設定項目はないが、”3.オプション” にある『接続許可ポート IPv4/IPv6』 のチェックボックス項目 “すべて許可” を最初に外しておいて欲しい.ここに並べられている許可ポートの設定項目は、ConoHa VPSサービスが用意している仮想基盤側のFirewall設定項目で、OS側のFirewall(iptablesやfirewalldなど)機能ではなく、その下の仮想サーバ基盤側でFirewall機能を提供しているものである.
仮想サーバ基盤側のFirewallで一旦全ての外部からのインターネット接続を遮断しておく事で、この後に実施する”KUSANAGI” 環境設定前の無防備な状態(初期状態でOS側のfirewalldが設定されていないので、外部からのアクセスを全て受け付けてしまう)での不正アクセスを防ぐ事が可能だ.この仮想サーバ基盤側でのFirewall機能の設定については後ほど説明する事にする.
Firewall設定と共にセキュリティー対策の一環としてrootアカウント用の SSH Key の設定は必ずやっておくことを薦める.rootアカウントのパスワード認証はセキュリティー上問題があるので、先ずはrootユーザアカウントの鍵認証設定をやっておく.
他のVPSサーバなどで予めrootユーザアカウント用のSSH Keyを設定してあれば、それをそのまま流用する(登録済みキー)事も可能だが、今回はこのVPSサーバ用に新規にrootユーザアカウント用のSSH Keyを作成することにする.此処で設定したSSH Keyが仮想サーバのデプロイ作業で自動的にrootアカウントに設定される.対となる秘密鍵データが自動的に生成されるので、この秘密鍵データをダウンロードし、手許のクライアントマシン上に保存しておく.
作成したプライベートキーを手許のPC上にダウンロードしておく
鍵認証方式によるSSHログインについては今更説明の必要も無いと思うが、もしこの仕組みが理解できないようであれば、サーバ管理者としては不適格だ.自分でまともに管理できないVPSサーバをパブリックな環境に構築するような無責任な事はしないで欲しい.
鍵認証方式によるrootアカウントのログイン設定と併用して、SSHの標準ポート(TCP/22)の変更も実施しておくことを薦める.インターネット環境下に置かれたサーバに対しては、攻撃者による SSH(TCP/22)や Telnet(TCP/23) による不正ログインの試みがひっきりなしだ.このような不正アクセスを排除するには標準ポート番号の変更が効果的だ.SSHの設定を変更してSSHの待ち受けポート番号を50000番台や60000番台などの解り難いハイポート番号へ変更しておけば、この手の不正アクセス対策として有効だ.
“KUSANAGI” VPSインスタンス作成準備完了
数十秒程度で”KUSANAGI” VPSインスタンスの作成が終了する
作成された”KUSANAGI” VPSサーバのIPアドレス等の情報を確認しておく
SSHサービスとfirewalldの稼働状態を確認しておく
“KUSANAGI” は初期状態でnginxなどのサービスが外部からアクセス可能な状態に置かれてしまっている
“KUSANAGI” で初期登録されているユーザアカウント
キーボードマップの切り換え(USキーボードユーザのみ)
“KUSANAGI” VPSイメージのOS(CentOS 7)のキーボード設定は”jp106″ に設定されているので、USキーボードを利用している場合は、VPS側のキーボード設定とOS側のキーボード設定をUSキーボードに合わせておく必要がある.
VPS側のキーマップを “US” に変更
コンソール画面上でOSのキーマップを “US” に変更