kusanagiのWordPressのVPS1契約、WAF(攻撃遮断くん)の効力範囲とSSL、各種設定

この記事は、今は無き、EX-CLOUDの攻撃遮断くんWAF付きVPSプラン､Wordpressホスティングについてまとめた記事です。kusanagiを採用しているVPSだったので、kusanagiコマンドについてのあれやこれや、実践しながら都度更新しています。ごちゃごちゃしていて読みにくい記事ですが、kusanagiコマンドを自由に使う為にはご参考にしていただけると思います。

EX-CLOUDのWordPressホスティングはFQDNに対してWAF（攻撃遮断くん）が適用される。FQDNをhogehoge.mlとした場合、sub.hogehoge.mlの様なサブドメインやその他のドメインに対しては、クラウド型WAF（攻撃遮断くん）は適用されない、hogehoge.ml/sub/の様なサブディレクトリに適用される。FQDNを意識する事が大切。EX-CLOUDのWordPressホスティングのWAF適用とSSL設定で運用するための手引きを以下に記載します。

WordPressホスティング有料契約だけではSSL(JPRS)もWAF(攻撃遮断くん)も無し

WAF向けのFQDN設定は、エクスクラウドのWordPressホスティング有料契約後、PleskのParallels Panelの画面で「ホーム」⇒「サービスを追加購入」⇒「WordPressホステイング」⇒「WP標準_クラウド型WAF」⇒ 「WAF機能を利用するFQDNをお知らせください（1契約１サイトまで）」に入力となります。SSL（JPRS）もWAFもさらに申込や登録設定などが必要です。SSLについては、Whois解除して自分の情報を開示するまでのお金（2～3千円でおそらく十分です）と時間、FQDN申請から認証されるまでの時間も必要でかなりメンドクサイです。WEBサイトリリースの3週間以上前から取り掛かるなど、事前に余裕をもって計画を立てておく必要があります。Let’s Encryptのメール認証みたいに申込時に一瞬で出来ません。WEB制作の受託などの際は、見積に手間賃を載せておかないと赤字になりかねません。

FQDNを設定後に変更したい場合、上記と同じ手順を改めて行うことで変更できます。

WordPressホステイングを契約しただけではWAF無しで、仮想マシン側でHOSTNAMEの設定を変えればWAFが適用されてOKという事ではない。

仕組みとしては、クラウドWAFのサーバー側でFQDNにアクセスがあったものについて不正なアクセスかどうかチェックして、不正アクセスで無ければ仮想環境へアクセスを流す、という感じ。そのため、DNSのAレコードはクラウドWAFのサーバーに向ける必要がある。さらに、クラウドWAFと仮想環境の間を暗号化するため、ここもSSL証明書が必要、KUSANAGIコマンドで無料Let’sEncryptやっときゃOK、簡単で助かるわ！ということではない。EX-CLOUDのサポートにも以下の様に説明されている。

お客様環境に搭載するサーバ証明書は、自動更新のLet’s Encryptや、
自己署名型の証明書ではない、SSLサーバ証明書（JPRS等）をご準備いただく必要があります。
（WordPressホスティングではWAFおよびJPRSのSSL証明書を1契約に対し1サイト分を標準提供しております)

WordPressホスティングやクラウドVPSのWAFはどういう仕組みが採用されますか【WPH】【VPS】より引用。

参考：日本レジストリサービス（JPRS)ドメイン認証型SSL

EX-CLOUD経由のSSLサーバ証明書（JPRS）申込について

自己署名型の証明書ではない、SSLサーバ証明書（JPRS等）の発行用の証明書署名要求CSR（Certificate Signing Request）については、Parallels Panelの画面で「ホーム」⇒ 「サービスを追加購入」⇒ 「WordPressホステイング」⇒「【日本レジストリサービス】WP標準_ドメイン認証型SSL」より別途申し込み必須。SSL1個ならWordPressホスティングの料金プラン内です。以下のような画面になるのでアンケート（1）から（5）までに答えて入力する必要が有る。が、記載方法がわかりにくい。（3）市区町村名はなぜ市区町村だけなのか？フルの住所ではないのか？よくわからなくてもやもやしますが、SSLの認証局側からEX-CLOUDにこの様に促されている？（EX-CLOUDに電話で聞いた）。こういうものだという事ですね。でも、事例は新宿区で、東京都新宿区と書かれている。東京23区は市が無い。市という人はどう書けばいいの？と考えながらググっていたら、ジオトラストのWEBサイトで『都道府県の1つ下のレベル』ということなので、その場合、（3）は市だけ書けばいい。Nagoya-cityとかそんな感じ。シマンテックとかジオトラストなどのQ&Aなどを探すと書き方説明が出てきます。

注意点として、エクスクラウドさんにてSSL証明書インストールとデフォルトとワードプレスのSSL化まで行ったあとにバトンタッチしてくれるので、kusanagiコマンドで新たにプロファイルを作り、「その他」欄などにプロファイル名をお伝えする。また、この設定により該当のプロファイルは、EX-CLOUDさんにてリセットされてしまうので、必要な人はバックアップを事前に行っておく。

この申込の後、認証作業の依頼のメールがEX-CLOUDではなくJPRSから届く。

ついでに、メモリリソースブースト（一時的にメモリが逼迫した場合など一週間限定でメモリをプラン上限の約1.5倍まで引き上げるサービス）も必要な際は別途申込が必要です。

そして、FQDNをhogehoge.mlと申し込んだ場合、FQDNそのものとhogehoge.ml/sub/の様にFQDNサブディレクトリに自分でインストールしたワードプレスのみがWAF適用範囲。

SSLのチェッカー

https://cryptoreport.websecurity.symantec.com/checker/

Whois情報表示代行の解除

エクスクラウドのWordPressホスティング、SSL適用の為に必要です。WHOIS情報のAdmin Emailをサイト管理者本人が確認できるメールアドレスに変更する必要が有ります。レジストラのお名前ドットコムの場合、ドメイン初回の申込時以外はWHOIS変更は有償です。リセラー（登録代行）のムームードメインであれば無料でいつでもWHOIS変更が出来ますが、TTLが3600秒の1時間で固定で、DNS設定時にTTL欄が無い！また、whois公開で登録されているメールアドレスが自分のメールアドレスである必要が有ります。道理として、開発者は事前にWHOIS公開の許可を発注主(ドメインの登録主）からもらっておく必要もあり、理解を得るまでのコミュニケーションも含めた時間の分もコミュニケーションコストです。

お名前ドットコムに登録している独自ドメインがWhois情報公開代行（ドメイン登録が自分の名義ではない場合）となっている場合、ムームーへ移管申請すると『WHOIS情報が代理公開情報となっているため移管できません』というメールが届き、移管申請そのものが失敗します。結局、お名前ドットコムでWhois情報公開代行の解除のお金が必要です。

WHOISで情報公開すると、スパムメールが送られてくる可能性がある様ですが、個人的にはスパムが増えている感じは無いです（Gmailだからかも）。

尚、SSL証明書の更新時には、EX-CLOUDからメールや電話がもらえるらしいので、SSL初期申込時だけWhois解除にしておいて、その他の時はWhois公開代理にしておくことも可能。更新の時もJPRSから手続き依頼のメールが届く。

Whois情報公開で開示される情報たち

.comと.netと.orgは次のものです。Whoisにおける登録情報の公開についてがわかりやすいです。トップレベルドメインによって公開される情報が異なるなどの場合がある様です。

• Domain Name （ドメイン名）
• Registration Date　（ドメイン登録日）
• Expiry Date　（ドメイン契約満了日）
• Organisation Name　（ドメイン登録者　氏名）
• Organisation Address　（ドメイン登録者　住所）
• Admin Name　（ドメイン管理担当者　氏名）
• Admin Address　（ドメイン管理担当者　住所）
• Admin Email　（ドメイン管理担当者　E-mailアドレス）
• Admin Phone　（ドメイン管理担当者　電話番号）
• Tech Name　（技術担当者　氏名）
• Tech Address　（技術担当者　住所）
• Tech Email　（技術担当者　E-mailアドレス）
• Tech Phone　（技術担当者　電話番号）
• Name Server　（ネームサーバー情報）

JPRSの認証依頼のメールを手続きしたら

EX-CLOUDのスタッフさんがJPRSの承認作業ができていることを確認したら、EX-CLOUDのスタッフさんにてSSL証明書インストールと該当プロファイル内のワードプレスのSSLかを行ってくれる。その後、攻撃遮断くんを入れる、この時もDNSレコードを修正する。

セキュリティ観点のお得感『大』

エクスクラウドの商品開発者さん、料金設定含めて大変だったんじゃないかな～。エクスクラウドのWordPressホスティングには結構なお得感を感じます、感謝です。攻撃遮断くんは、クラウドWAFタイプで仮想マシンホストのプロセス負担も少ない、WAF（Web Aprication Firewall）だけでなくIPS(Intrusion Prevention System：不正侵入防御)もサポートしています。EX-CLOUD側がFQDN数制限なしの攻撃遮断くんプランに加入してくれているおかげです。単独で攻撃遮断くんを入れる場合、プランを精査して1秒間のトラフィックボリュームなどにより異なりますが、クラウド型のWEBセキュリティタイプで1万円/月～です。このプランでWordPressだけでなく、KUSANAGIでEC-CUBEやらCS-CARTやらネットショップ、Concrete5、Drupal、その他CMSなどを使う事にも応用が出来る事も考えると非常に素晴らしい。業者目線では攻撃遮断くん付き、SSL付きで、ある程度セキュリティに自信をもって月1万円～という商品プランを考える事ができる。とりあえず、うちはこれでプランリリースします。心強い。セキュリティでリード性のある商品は、最終的に価格と自信につなげられるので本当にありがたい。

現状、思いつく限りの主要な危惧ポイントは、大規模DDOSやらゼロデイ攻撃だと思われますが、他にも数え上げたらいっぱいあるので、もうしょうがない。契約時にクライアントサイドに説明しておくしかない。でも、WordPressホスティングの最安プラン2環境（本番と開発）でも1万円を切るわけで、この様に考えると素晴らしい。DBを別インスタンスで分離しているわけではない点も注意、このあたりは今後も要検討ですが、こうなってくると顧客層レベルも変わって来るので根本的に違う。

2017年5～6月頃にAzure Database for MySQLのプレビュー版がローンチされた為、WEB AppsでPaasのほうがKUSANAGI仮想マシン2台よりも安く抑えられるのかな？プレビューが早く解けて欲しいです。AzureでClearDB無しでMySQLのPaasです、結構な革命だと思います。AzureでMySQLのPaasですよ！助かる！

攻撃遮断くんの話

あるクライアントさんのサーバー引越で、一時的に攻撃遮断くんが引越によってはずれた時、Dos/DDos攻撃が発生し、メモリのスケールアップでしのいでいました。この時は、EX-CLOUDではありませんでした。そして、攻撃遮断くんを移行後のサーバーに設定しなおして再び正常に戻りました。顕著に効果を体感出来ると強く感嘆させられ、見えない世界中の犯罪者から解放された喜びもひとしおです。IT土方の中間サプライヤーとしては、この点をいかに価値として伝えて、クライアントのWEBアプリケーションの頼もしい安定性、そして自社利益に結び付けるか、という感じやね。

仮想マシンのホスト名確認

参考です。

//ホスト名のFQDN確認
hostname -f

-aでエイリアス。-dでDNSドメインの名前。-fで短い形式のホスト名とDNSドメイン名からなるFQDNを表示。-iでホストのIPアドレス。-vで処理内容をすべて表示。-yでNIS(Network Information Service)ドメイン名を表示・設定。

HOSTNAME確認はnetworkファイルにて

//HOSTNAME確認
/etc/sysconfig/network

1台の仮想マシン内で複数WEBサイトを運営するバーチャルホストは、/etc/hostsファイルを見て確認するか以下のコマンドです。

//Apacheバーチャルホストの一覧確認（Sは小文字ではなく大文字）
httpd -S

※Nginxでも上記コマンド使えました。

kusanagi remove コマンドで契約初期のプロファイルを削除して仮想マシンを再起動kusanagi restartしても、別申込を行ったFQDNは削除/変更されません。

CentOSのバージョン確認
cat /etc/redhat-release

KUSANAGIでWPのプロファイルを構築するコマンド

コマンドで2つ目のプロファイル（バーチャルホスト）を追加して、FQDNと異なればそのプロファイルにWAFは適用されない。

//プロファイル名:subhoge_html、サブドメイン:sub.hogehoge.ml
kusanagi provision --WordPress --wplang ja --fqdn sub.hogehoge.ml subhoge_html

※プロファイル名とサブドメインの順番を反対に書くとエラーになります。

※hogehoge.mlと同じLet’s Encryptの登録メールアドレスを使うとエラーになります。

プロファイル構築時にLet’s Encrypt用のメールアドレスを入力せず、後でSSL(Let’s Encrypt)を設定する場合（参考）

プリロードhsts有効化（サブドメイン含む）、Let’s Encryptの証明書の自動更新を有効化。

kusanagi ssl --email hogehoge@dev-labo.com --hsts high --auto on

※HSTS関連は、コマンドを打つ前に、https://hstspreload.org/をよく読んで設定手順を確認してください。間違えると時間と手間がかかり非常に面倒くさい。サブドメインを含まないで設定する場合、highをweakに変えてコマンドを打ってください（サブドメインを含まないHSTSの有効化だけで、プリロードHSTSは無効）。

※hogehoge@dev-labo.comは適当に変えてください。

以下を見ると、Let’s Encrypt自体はうまくいっている様ですが、プリロードHSTSが、HSTSをサブドメイン指定ありで有効化し、プリローディングも合わせて行います。設定を変更しました。HSTS プリローディングリストへの登録を試みています。失敗しました。となりコケます。Nginxのserverディレクティブの設定など、ドキュメントを漁る必要が有りそうです。リニューアルでhttps⇒httpsの様なサーバー引越しの場合、まず、https⇒httpで移して、それからSSL化という手順になるので、このあたりはしっかり詰めておかないと厄介。

HSTSはhttps://hstspreload.org/を見ながら設定する必要が有ります。FQDNのサブドメイン含有の有無とプリロードHSTS設定の有効化/無効化など選択すべき点があります。httpリクエストやレスポンスがよくわからなかったりメンドクサイという場合は、以下のコマンドの方が良さそう。このあたりは、/var/spool/mail/rootにメールが届くので適宜内容を確認しながら行うのがお勧めですが、UTC時間でメールが届くのでややこしい・・・。ご参考にUTC時間は日本マイナス9時間です。/etc/monit.d/alertでmonitの設定も確認出来ます。

kusanagi ssl --email hogehoge@dev-labo.com --auto on

また、kusanagi https redirectでhttpからhttpsへのリダイレクト設定も忘れずに。

/var/log/letsencrypt でログが見られます。/etc/nginx/conf.d/プロファイル名_ssl.conf にてlessやcatでserverディレクティブを見る事が出来ます。

//serverディレクティブの中

ssl_certificate      /etc/letsencrypt/live/独自ドメイン/fullchain.pem;
ssl_certificate_key  /etc/letsencrypt/live/独自ドメイン/privkey.pem;
ssl_dhparam /etc/kusanagi.d/ssl/dhparam.key;

kusanagi初期化コマンド

kusanagi init --tz Tokyo --lang ja --keyboard ja --nginx --httpd --php7 --ruby24

※CircleCIを使う場合、Linuxユーザーkusanagiのキーペアのパスフレーズは無しにすることを強く推奨します。

KUSANAGIでプロファイルを削除するコマンド

//プロファイル削除コマンド
kusanagi remove subhoge_html

Basic認証(KUSANAGI Nginx)について

KUSANAGIの場合、ダッシュボードログイン画面にBasic認証を掛けられるようになっています。指定したIPアドレスでなければBasic認証を実行する様にKUSANAGIのドキュメントを見ていただくと設定する事が出来ます。

開発段階からEX-CLOUD WordPressホスティングを使い、ダッシュボードログイン画面ではなく、WPサイトを表側から見た部分にBasic認証をかける場合、以下の手順となります。

Basic認証のhttpd-tools確認

//yumインストール一覧確認
yum list installed

httpd-toolsが入っているかどうかよくわからない・・・。

httpd-toolsインストール

KUSANAGIは最初からダッシュボードログイン画面にBasic認証を設定出来る様になっているので、おそらくhttpd-toolsはKUSANAGIに既に入っていますが、インストールをやってみる。

//Basic認証のhttpd-toolsインストール
sudo yum install httpd-tools

結果

パッケージ httpd-tools-2.4.6-45.el7.centos.x86_64 は既にインストール済みの kusanagi-httpd-2.4.25-1.noarch によって不要扱いになりました。何もしません

KUSANAGIにおいてのhttpd-toolsは、kusanagi-httpd-2.4.25-1.noarch あたりっぽいです。

yumのパッケージアンインストールコマンド（参考）

//yumパッケージアンインストールコマンド
yum remove パッケージ１ パッケージ２

.htpasswdを置く場所

DocumentRootより上、プロファイル名より下として他プロファイル（バーチャルホスト）との干渉を避けました。

//.htpasswdを置く場所
/home/kusanagi/プロファイル名

.htpasswdを作る

所有ユーザー（chown）、所有グループ(chgrp)等に注意。usernameの部分を任意のユーザー名に置き換える。

//htpasswdファイルを作る
htpasswd -cs .htpasswd username

KUSANAGIのNginxのバーチャルホスト設定、*.confのファイル場所について

//KUSANAGIのNginxのバーチャルホスト設定、*.confのファイル場所
/etc/nginx/conf.d/プロファイル名_html.conf（プロファイル名_ssl.conf）;

Basic認証の為に以下を記載

所有ユーザー（chown）、所有グループ(chgrp)、SELinux等も場合によって注意。

locationディレクティブのtry_fileの下にauth_basicの2行を追記。

//Basic認証設定 /etc/nginx/conf.d/プロファイル名_html.conf（プロファイル名_ssl.conf）
location / {
	try_files $uri $uri/ /index.php?$args;

    auth_basic  "Basic認証";
    auth_basic_user_file /home/kusanagi/プロファイル名/.htpasswd;
}

再起動

//再起動
kusanagi restart

念のため、ブラウザでsub.hogehoge.mlなどをたたいてBasic認証が機能しているか確認してみてください。

KUSANAGIでroot権限に昇格出来ない人

kusanagiユーザーでsshログインすると、root権限の管理者スーパーユーザーにsudo su -で昇格できません。エクスクラウドのPleskのParallels Panelの画面⇒「システム」⇒「ファイルマネージャ」⇒「root」⇒「user_password」にて確認できる「アカウント情報」でsshログインしてsudo su -してください。同画面内の「▽sftp初期接続設定情報」のkusanagiユーザーでsshログインするとroot昇格できなくて仕事が止まり焦りました。wheelグループとかそのあたりのKUSANAGIの設定だと思いますが、気を付けてください。sshは正式運用までに、パスワード認証から鍵ファイル認証に変えておきましょう。iptables設定（sshポート変更）やfail2banの設定更新なども行っておきましょう。

.sshの場所

//.sshの場所
/home/kusanagi/.ssh

※ディレクトリトラバーサルが頭の中をよぎり、気になる方は工夫したほうがいいと思います。

KUSANAGI専用プラグインについて

MU（Must Use）プラグインです。wp-content/mu-pluginsというディレクトリを作って配置するものです。

mu-pluginsディレクトリで次のコマンドを打つと復元できます。

//KUSANAGI専用プラグインの復元
cp -r /usr/lib/kusanagi/resource/DocumentRoot/wp-content/mu-plugins/kusanagi-core ./

KUSANAGIのアップデート

kusanagiバージョン確認。
kusanagi status |grep Version
kusanagiのアップデート。
ただのyum updateではできません。普通のyum updateで出来たっぽいです。そのうち、もう一度しっかり確認します。以下をroot権限で実行してください。ダッシュボードでMUプラグインで常にphpやnginx等が最新バージョンであることにリスクと安心感を覚えます、ちょっと複雑な心境。スゴイ楽です。EX-CLOUD WordPressホスティングくらいの月額であれば、検証用と本番用で2つ借りて、検証用でアップデートの実験をしながらの運用でもいいと思います。

//アップデートの確認
yum check-update

//yumキャッシュ削除
yum clean all

//アップデート
yum -y update

プロビジョニング以外でもこっちじゃないと出来ない時があったような気がします・・・。

//kusanagiのアップデート root権限で行ってください
yum --enablerepo=remi,remi-php56 update -y

上記コマンド内のremi-php56についてremi-php73などを試しました。–skip-brokenの指示が出てきてyum update出来ませんでした。

kusanagi pluginのアップデート

kusanagi target プロファイル名
kusanagi update plugin

kusanagiプロファイル一覧確認

grep PROFILE /etc/kusanagi.d/profile.conf

非SSLのkusanagiプロファイルをLet’s Encrypt SSLにする

kusanagi ssl --email example@dev-labo.com subhoge_html

kusanagi Let’s Encrypt SSL自動更新のONなど

httpsのリダイレクト、hstsの設定など、該当プロファイルのWordpressバーチャルホストの状態に応じて変えてください。
kusanagi ssl --https redirect --hsts weak --auto on subhoge_html

kusanagi Let’s Encrypt 手動更新

以下のどちらか。よくわからないので上段のプロファイル指定でしっかり確認してください。
kusanagi update cert subhoge_html
こちらはkusanagiというプロファイルを指定しているのか、ホスト全体のkusanagiプロファイル達を対象にしてしまうのか、何なのか不明。
kusanagi update cert kusanagi

画像ファイル最適化

ファイルが多いと、かな～り時間がかかるかも。何してるか調べてないので遅いと不安になるけど、終わるまでプロンプトを見つめながら、温かく見守り、待つべし。
kusanagi images subhoge_html