KUSANAGI EX-CLOUD 仮想マシン1台で複数WP構築、WAF(攻撃遮断くん)適用範囲

excloud-kusanagi

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

WordPressホステイングを有料契約しただけではWAF無し

FQDN設定は、エクスクラウドのWordPressホスティング有料契約後、PleskのParallels Panelの画面で「アカウント」⇒「サービスを追加購入」⇒「WordPressホステイング」⇒「WP標準_クラウド型WAF」⇒ 「WAF機能を利用するFQDNをお知らせください(1契約1サイトまで)」に入力となります。

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】より引用。

自己署名型の証明書ではない、SSLサーバ証明書(JPRS等)については、Parallels Panelの画面で「アカウント」⇒ 「サービスを追加購入」⇒ 「WordPressホステイング」⇒「【日本レジストリサービス】WP標準_ドメイン認証型SSL」より別途申し込み必須。1個ならWordPressホスティングのプラン内です。

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

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

WHOIS情報表示代行の解除

エクスクラウドのWordPressホスティング、攻撃遮断くんのWAF適用の為に必要です。レジストラのお名前ドットコムの場合、ドメイン初回の申込時以外はWHOIS変更有償です。リセラー(登録代行)のムームードメインであれば無料でいつでもWHOIS変更が出来ます。

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

WHOISで情報公開すると、そこからスパムメールが送られてくる可能性があるので気を付けてください。

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

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

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

2017年5~6月頃にAzure Database for MySQLのプレビュー版がローンチされた為、このあたりと組み合わせたほうがKUSANAGI仮想マシン2台よりも安く抑えられそう。プレビューが早く解けてくれるといいかと思います。AzureでClearDB無しでMySQLのPaasです。

攻撃遮断くんの話

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

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

参考です。

HOSTNAME確認はnetworkファイルにて

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

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

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

 

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

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

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

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

 

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

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

kusanagi ssl --email hogehoge@4649-24.com --hsts high --auto on

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

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

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

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

kusanagi ssl --email hogehoge@4649-24.com --auto on

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

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

kusanagi初期化コマンド

kusanagi init --tz tokyo --lang ja --keyboard ja --nginx --php7

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

Basic認証(KUSANAGI Nginx)について

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

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

Basic認証のhttpd-tools確認

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

httpd-toolsインストール

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

結果

パッケージ 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のパッケージアンインストールコマンド(参考)

.htpasswdを置く場所

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

.htpasswdを作る

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

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

Basic認証の為に以下を記載

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

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

再起動

念のため、ブラウザで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の場所

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

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

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

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

KUSANAGIのアップデート

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

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

コメントを残す