WordPresskusanagiの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設定で運用するための手引きを以下に記載します。「WAF機能を利用するFQDNをお知らせください(1契約1サイトまで)」に入力となります。SSL(JPRS)もWAFもさらに申込や登録設定などが必要です。SSLについては、Whois解除して自分の情報を開示するまでのお金(2~3千円でおそらく十分です)と時間、FQDN申請から認証されるまでの時間も必要でかなりメンドクサイです。WEBサイトリリースの3週間以上前から取り掛かるなど、事前に余裕をもって計画を立てておく必要があります。Encryptのメール認証みたいに申込時に一瞬で出来ません。WEB制作の受託などの際は、見積に手間賃を載せておかないと赤字になりかねません。FQDNを設定後に変更したい場合、上記と同じ手順を改めて行うことで変更できます。WordPressホステイングを契約しただけではWAF無しで、仮想マシン側でHOSTNAMEの設定を変えればWAFが適用されてOKという事ではない。仕組みとしては、クラウドWAFのサーバー側でFQDNにアクセスがあったものについて不正なアクセスかどうかチェックして、不正アクセスで無ければ仮想環境へアクセスを流す、という感じ。そのため、DNSのAレコードはクラウドWAFのサーバーに向ける必要がある。クラウドWAFと仮想環境の間を暗号化するため、ここもSSL証明書が必要、KUSANAGIコマンドで無料Let’sEncryptやっときゃOK、簡単で助かるわ!ということではない。EX-CLOUDのサポートにも以下の様に説明されている。自己署名型の証明書ではない、SSLサーバ証明書(JPRS等)をご準備いただく必要があります。(WordPressホスティングではWAFおよびJPRSのSSL証明書を1契約に対し1サイト分を標準提供しております)WordPressホスティングやクラウドVPSのWAFはどういう仕組みが採用されますか【WPH】【VPS】より引用。「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適用の為に必要です。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における登録情報の公開についてがわかりやすいです。トップレベルドメインによって公開される情報が異なるなどの場合がある様です。(ネームサーバー情報)JPRSの認証依頼のメールを手続きしたらEX-CLOUDのスタッフさんがJPRSの承認作業ができていることを確認したら、EX-CLOUDのスタッフさんにてSSL証明書インストールと該当プロファイル内のワードプレスのSSLかを行ってくれる。その後、攻撃遮断くんを入れる、この時もDNSレコードを修正する。セキュリティ観点のお得感『大』エクスクラウドの商品開発者さん、料金設定含めて大変だったんじゃないかな~。エクスクラウドのWordPressホスティングには結構なお得感を感じます、感謝です。System:不正侵入防御)もサポートしています。EX-CLOUD側がFQDN数制限なしの攻撃遮断くんプランに加入してくれているおかげです。単独で攻撃遮断くんを入れる場合、プランを精査して1秒間のトラフィックボリュームなどにより異なりますが、クラウド型のWEBセキュリティタイプで1万円/月~です。このプランでWordPressだけでなく、KUSANAGIでEC-CUBEやらCS-CARTやらネットショップ、Concrete5、Drupal、その他CMSなどを使う事にも応用が出来る事も考えると非常に素晴らしい。業者目線では攻撃遮断くん付き、SSL付きで、ある程度セキュリティに自信をもって月1万円~という商品プランを考える事ができる。うちはこれでプランリリースします。セキュリティでリード性のある商品は、最終的に価格と自信につなげられるので本当にありがたい。現状、思いつく限りの主要な危惧ポイントは、大規模DDOSやらゼロデイ攻撃だと思われますが、他にも数え上げたらいっぱいあるので、もうしょうがない。契約時にクライアントサイドに説明しておくしかない。WordPressホスティングの最安プラン2環境(本番と開発)でも1万円を切るわけで、この様に考えると素晴らしい。DBを別インスタンスで分離しているわけではない点も注意、このあたりは今後も要検討ですが、こうなってくると顧客層レベルも変わって来るので根本的に違う。AppsでPaasのほうがKUSANAGI仮想マシン2台よりも安く抑えられるのかな?プレビューが早く解けて欲しいです。AzureでClearDB無しでMySQLのPaasです、結構な革命だと思います。AzureでMySQLのPaasですよ!助かる!攻撃遮断くんの話あるクライアントさんのサーバー引越で、一時的に攻撃遮断くんが引越によってはずれた時、Dos/DDos攻撃が発生し、メモリのスケールアップでしのいでいました。この時は、EX-CLOUDではありませんでした。攻撃遮断くんを移行後のサーバーに設定しなおして再び正常に戻りました。顕著に効果を体感出来ると強く感嘆させられ、見えない世界中の犯罪者から解放された喜びもひとしおです。IT土方の中間サプライヤーとしては、この点をいかに価値として伝えて、クライアントのWEBアプリケーションの頼もしい安定性、そして自社利益に結び付けるか、という感じやね。-f-aでエイリアス。-dでDNSドメインの名前。-fで短い形式のホスト名とDNSドメイン名からなるFQDNを表示。-iでホストのIPアドレス。-vで処理内容をすべて表示。Service)ドメイン名を表示・設定。HOSTNAME確認はnetworkファイルにて//HOSTNAME確認/etc/sysconfig/network1台の仮想マシン内で複数WEBサイトを運営するバーチャルホストは、/etc/hostsファイルを見て確認するか以下のコマンドです。-S※Nginxでも上記コマンド使えました。restartしても、別申込を行ったFQDNは削除/変更されません。/etc/redhat-releaseKUSANAGIでWPのプロファイルを構築するコマンドコマンドで2つ目のプロファイル(バーチャルホスト)を追加して、FQDNと異なればそのプロファイルにWAFは適用されない。subhoge_html※プロファイル名とサブドメインの順番を反対に書くとエラーになります。Encryptの登録メールアドレスを使うとエラーになります。Encryptの証明書の自動更新を有効化。on※HSTS関連は、コマンドを打つ前に、https://hstspreload.org/をよく読んで設定手順を確認してください。間違えると時間と手間がかかり非常に面倒くさい。サブドメインを含まないで設定する場合、highをweakに変えてコマンドを打ってください(サブドメインを含まないHSTSの有効化だけで、プリロードHSTSは無効)。※hogehoge@4649-24.comは適当に変えてください。Encrypt自体はうまくいっている様ですが、プリロードHSTSが、HSTSをサブドメイン指定ありで有効化し、プリローディングも合わせて行います。プリローディングリストへの登録を試みています。