回答
可能でございます。
Webサーバ用のサーバが1台、メールサーバ用のサーバを1台、それぞれ別々にご利用をいただくことも可能でございます。
既に1台でWebサーバおよび、メールサーバ用途で運用している場合は、以下の手順をおこなっていただくことで2台で利用をいただくことが可能でございます。
本手順につきましては、現在利用中のネームサーバを変えない前提の手順となります。
・新規サーバをWebサーバ用として利用したい場合は、Webのデータ、データベースの移行が必要となります。
・新規サーバをメールサーバ用として利用したい場合は、メールアドレスの移行が必要となります。
上記どちらのパターンでも移行後には、DNSのレコードの変更作業が必要となります。DNSのレコードの変更をおこなって初めて、新サーバへ接続されます。
新規追加サーバにつきましては、以下のサイトよりお申込みをいただきますようお願い致します。
▼Flex Mini Cubeサービス
▼KUSANAGI with Cubeサービス
▼Flex Web サービス
お客様側でのデータのご移行が難しい場合( 弊社サーバに対してご移行)には、弊社で移行を支援させていただくサービス(有償)もございますのであわせてご検討をいただきますようお願い致します。
・手順0. DNSレコード切り替え前の24時間前までに、TTL値を事前に短くします。
TTL値の変更方法については、以下のFAQをご参照ください。
DNSレコードの切り替えまでに、新サーバ上でのWebコンテンツの動作確認や、メールの動作確認を必ずおこなっていただきますようお願いいたします。
▼Plesk Onyx：TTL値を変更したい
▼Plesk12：TTL値を変更したい
▼Plesk11：TTL値を変更したい
▼Plesk9：TTL値の変更方法
・手順1. 上記手順0.の変更してから24時間経過した後に、PleskからDNSレコードの変更をおこなってください。
新サーバを利用する機能により、変更するレコード内容が変わりますので、以下の内容をご確認をいただきますようお願い致します。
■プライマリDNSがPleskを利用している場合、かつ、新サーバをWebサーバとして利用したい場合
◇変更が必要なレコード一覧
・”ドメイン名” Aレコード “新規サーバのIPアドレス”
・www.”ドメイン名” Aレコード “新規サーバのIPアドレス”
・ftp.”ドメイン名” Aレコード “新規サーバのIPアドレス”
※その他のレコードは変更不要となります。もし、変更された場合にはWeb等が閲覧できない事象が発生致します。
■プライマリDNSがPleskを利用している場合、かつ、新サーバをメールサーバとして利用したい場合
◇変更が必要なレコード一覧
・mail.”ドメイン名” Aレコード “新規サーバのIPアドレス”
・lists.”ドメイン名” Aレコード “新規サーバのIPアドレス”
・webmail.”ドメイン名” Aレコード ”新規サーバのIPアドレス”
※その他のレコードは変更不要となります。もし、変更された場合にはWeb等が閲覧できない事象が発生致します。
また、新サーバをWebサーバとして利用したい場合には、Webサーバ側でメール機能を無効化する必要がございます。
新サーバにPleskを搭載している場合の操作方法につきましては、以下のFAQをご参照ください。
▼特定ドメイン宛て(他のサーバ)にメールが受け取れないが、なぜでしょうか。
なお、新サーバをメールサーバとして利用されたい場合は、メール機能を無効化してはいけません。
2019年8月16日(金)
2019年8月19日(月)-更新-
■問題の概要
平素は弊社サービスをご利用いただきましてありがとうございます。弊社提供のKUSANAGI with Cubeサービスで標準採用しておりますWebサーバ(HTTP/2 )の脆弱性(CVE-2019-9511, CVE-2019-9513, CVE-2019-9516,CVE-2019-10081, CVE-2019-9517, CVE-2019-10097)でサービス運用妨害 (DoS) 攻撃の公表がございました。詳細につきましては、以下のURLをご参照ください。
HTTP/2 の実装に対するサービス運用妨害 (DoS) 攻撃手法-JVN-
Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート-JVN-
nginx [nginx-announce] nginx security advisory (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516)
■脆弱性を受ける可能性が高いサービス名
KUSANAGI with Cubeサービスを利用している、かつWebサーバにnginxもしくは、Apacheを動作させていているサーバ
(弊社ご開通時の標準Webサーバは、nginxとなります。KUSANAGI with Cubeサービス でApacheをご利用場合されている場合も本脆弱性の対象となります )
■脆弱性の影響を受けるバージョン
・nginx 1.9.5 から、nginx 1.17.2まで
・Apache HTTP Web Server 2.4.41 より前のバージョン(mod_http2モジュールを有効化されているサーバ)
なお、今回の脆弱性におきましては、 KUSANAGI 関連のパッケージのアップデートをお勧めいたします。
本ページでは、お客様ご自身にてKUSANAGI関連のパッケージのアップデートをおこなう方法をご案内いたします。
※2019年8月19日現在の情報となります。
アップデートに関する注意事項
・本手順は無保証となります。作業をされる際は、お客様の責任にておこなっていただけますようお願いいたします。
・お客様にて初期設定から設定をカスタマイズしている場合は、以下のアップデート手順で正常にアップデートできない可能性がございます。ご注意ください。
・本手順のアップデート中につきましては、通常の場合は数秒程度Webサイトの表示が行えなくなりますのであらかじめご了承ください。
KUSANAGI関連のパッケージのアップデート方法(nginxの場合)
(1). SSH にてサーバにログイン
SSH にてサーバにログインし、root ユーザに切り替えます。
(2). インストールされているパッケージの確認
| #rpm -qa | grep kusanagi-nginx |
特に何も表示されない場合には、kusanagi-nginxのパッケージが入っておりません。脆弱性影響の対象外となります。
脆弱性の対象バージョンは以下のようなコマンドの出力結果となります。
例)
# rpm -qa | grep kusanagi-nginx
kusanagi-nginx-1.15.8-1.noarch ←作業をおこなう必要がある対象バージョン
(3).nginxの文法チェック
| #nginx -t |
例)# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
↑文法チェック上、問題ない場合のコマンドの出力例
※syntax is okおよび、is successfulという文字以外が、出力された場合にはパッケージのアップデート作業を中止してください。中止しない場合は、アップデート作業後、Webサーバが起動しなくなります。
(4). KUSANAGI関連のパッケージアップデートの実施
以下のコマンドを実行し、KUSANAGI関連のパッケージのアップデートを行います。
| #yum update kusanagi-* |
(5). アップデート後のパッケージバージョンの確認
| #rpm -qa | grep kusanagi-nginx |
上記コマンドを再度実行し、セキュリティパッチが適用されているパッケージのバーション(以下の青文字を参照)かどうかを確認します。
■セキュリティパッチが適用されているnginxのパッケージのバーション
kusanagi-nginx-1.17.3-1.noarch
(6). アップデート後のKUSANAGIのサービス再起動
| #kusanagi restart |
(7). Webサイトの動作確認
以上、となります。
KUSANAGI関連のパッケージのアップデート方法(Apacheの場合)
(1). SSH にてサーバにログイン
SSH にてサーバにログインし、root ユーザに切り替えます。
(2). インストールされているパッケージの確認
| #rpm -qa | grep kusanagi-httpd |
特に何も表示されない場合には、kusanagi-httpdのパッケージが入っておりません。脆弱性影響の対象外となります。
脆弱性の対象バージョンは以下のようなコマンドの出力結果となります。
例)
# rpm -qa | grep kusanagi-httpd
kusanagi-httpd-2.4.33-2.noarch ←作業をおこなう必要がある対象バージョン
(3).Apacheの文法チェック
| #httpd -t |
例)# httpd -t
[Mon Aug 19 12:20:27.949195 2019] [so:warn] [pid 8312] AH01574: module headers_module is already loaded, skipping
Syntax OK
↑文法チェック上、問題ない場合のコマンドの出力例
※Syntax OKという文字以外が、出力された場合にはパッケージのアップデート作業を中止してください。中止しない場合は、アップデート作業後、Webサーバが起動しなくなります。
(4). KUSANAGI 関連のパッケージアップデートの実施
以下のコマンドを実行し、KUSANAGI関連のパッケージのアップデートを行います。
| #yum update kusanagi-* |
(5). アップデート後のパッケージバージョンの確認
| #rpm -qa | grep kusanagi-httpd |
上記コマンドを再度実行し、セキュリティパッチが適用されているパッケージのバーション(以下の青文字を参照)かどうかを確認します。
■セキュリティパッチが適用されているApacheのパッケージのバーション
kusanagi-httpd-2.4.41-1.noarch
(6). アップデート後のKUSANAGIのサービス再起動
| #kusanagi restart |
(7). Webサイトの動作確認
以上、となります。
なお、お客様にて作業が難しい場合は、弊社サポート宛て(support@clara.ne.jp)までご依頼をいただきますようお願い致します。
弊社営業時間内(平日10:00-18:00)にて、弊社の任意のタイミングにて作業を実施させていただきます。
ご依頼の際のメールにつきましては、以下の内容を必ずご記載をいただきますようお願い致します。
□メールのご依頼フォーマット
メールの件名：KUSANAGI のアップデート依頼
メールの本文
・更新対象サーバのホスト名および、IPアドレス
・パッケージの更新作業後のメールのご連絡の有無(必要 or 不要)
※「必要」、「不要」のいずれかのご記載をいただきますようお願い致します。
2019年8月16日 (金）
2019年8月19日(月)-更新-
■問題の概要
平素は弊社サービスをご利用いただきましてありがとうございます。弊社提供のKUSANAGI with Cubeサービスで標準採用しておりますWebサーバ(HTTP/2 )の脆弱性(CVE-2019-9511, CVE-2019-9513, CVE-2019-9516,CVE-2019-10081, CVE-2019-9517, CVE-2019-10097)でサービス運用妨害 (DoS) 攻撃の公表がございました。詳細につきましては、以下のURLをご参照ください。
HTTP/2 の実装に対するサービス運用妨害 (DoS) 攻撃手法-JVN-
Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート-JVN-
nginx [nginx-announce] nginx security advisory (CVE-2019-9511, CVE-2019-9513, CVE-2019-9516)
●脆弱性を受ける可能性が高いサービス名
KUSANAGI with Cubeサービスを利用している、かつWebサーバにnginxもしくは、Apacheを動作させていているサーバ
(弊社ご開通時の標準Webサーバは、nginxとなります。KUSANAGI with Cubeサービス でApacheをご利用場合されている場合も本脆弱性の対象となります )
■脆弱性の影響を受けるバージョン
・nginx 1.9.5 から、nginx 1.17.2まで
・Apache HTTP Web Server 2.4.41 より前のバージョン(mod_http2モジュールを有効化されているサーバ)
なお、今回の脆弱性におきましては、 KUSANAGI 関連のパッケージのアップデートをお勧めいたします。
本ページでは、お客様ご自身にてKUSANAGI関連のパッケージのアップデートをおこなう方法をご案内いたします。
※2019年8月16日現在の情報となります。
アップデートに関する注意事項
本手順は無保証となります。作業をされる際は、お客様の責任にておこなっていただけますようお願いいたします。
お客様にて初期設定から設定をカスタマイズしている場合は、以下のアップデート手順で正常にアップデートできない可能性がございます。ご注意ください。
本手順のアップデート中につきましては、通常の場合は数秒程度Webサイトの表示が行えなくなりますのであらかじめご了承ください。
KUSANAGI関連のパッケージのアップデート方法(nginxの場合)
(1). SSH にてサーバにログイン
SSH にてサーバにログインし、root ユーザに切り替えます。
(2). インストールされているパッケージの確認
| #rpm -qa | grep kusanagi-nginx |
特に何も表示されない場合には、kusanagi-nginxのパッケージが入っておりません。脆弱性影響の対象外となります。
脆弱性の対象バージョンは以下のようなコマンドの出力結果となります。
例)
# rpm -qa | grep kusanagi-nginx
kusanagi-nginx-1.15.8-1.noarch ←作業をおこなう必要がある対象バージョン
(3).nginxの文法チェック
| #nginx -t |
例)# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
↑文法チェック上、問題ない場合のコマンドの出力例
※syntax is okおよび、is successfulという文字以外が、出力された場合にはパッケージのアップデート作業を中止してください。中止しない場合は、アップデート作業後、Webサーバが起動しなくなります。
(4). KUSANAGI関連のパッケージアップデートの実施
以下のコマンドを実行し、KUSANAGI関連のパッケージのアップデートを行います。
| #yum update kusanagi-* |
(5). アップデート後のパッケージバージョンの確認
| #rpm -qa | grep kusanagi-nginx |
上記コマンドを再度実行し、セキュリティパッチが適用されているパッケージのバーション(以下の青文字を参照)かどうかを確認します。
■セキュリティパッチが適用されているnginxのパッケージのバーション
kusanagi-nginx-1.17.3-1.noarch
(6). アップデート後のKUSANAGIのサービス再起動
| #kusanagi restart |
(7). Webサイトの動作確認
以上、となります。
KUSANAGI関連のパッケージのアップデート方法(Apacheの場合)
(1). SSH にてサーバにログイン
SSH にてサーバにログインし、root ユーザに切り替えます。
(2). インストールされているパッケージの確認
| #rpm -qa | grep kusanagi-httpd |
特に何も表示されない場合には、kusanagi-httpdのパッケージが入っておりません。脆弱性影響の対象外となります。
脆弱性の対象バージョンは以下のようなコマンドの出力結果となります。
例)
# rpm -qa | grep kusanagi-nginx
kusanagi-httpd-2.4.33-2.noarch ←作業をおこなう必要がある対象バージョン
(3).nginxの文法チェック
| #httpd -t |
例)# httpd -t
[Mon Aug 19 12:20:27.949195 2019] [so:warn] [pid 8312] AH01574: module headers_module is already loaded, skipping
Syntax OK
↑文法チェック上、問題ない場合のコマンドの出力例
※Syntax OKという文字以外が、出力された場合にはパッケージのアップデート作業を中止してください。中止しない場合は、アップデート作業後、Webサーバが起動しなくなります。
(4). KUSANAGI 関連のパッケージアップデートの実施
以下のコマンドを実行し、kusanagi 関連のパッケージのアップデートを行います。
| #yum update kusanagi-* |
(5). アップデート後のパッケージバージョンの確認
| #rpm -qa | grep kusanagi-httpd |
上記コマンドを再度実行し、セキュリティパッチが適用されているパッケージのバーション(以下の青文字を参照)かどうかを確認します。
■セキュリティパッチが適用されているApacheのパッケージのバーション
kusanagi-httpd-2.4.41-1.noarch
(6). アップデート後のKUSANAGIのサービス再起動
| #kusanagi restart |
(7). Webサイトの動作確認
以上、となります。
なお、お客様にて作業が難しい場合は、弊社サポート宛て(support@clara.ne.jp)までご依頼をいただきますようお願い致します。
弊社営業時間内(平日10:00-18:00)にて、弊社の任意のタイミングにて作業を実施させていただきます。
ご依頼の際のメールにつきましては、以下の内容を必ずご記載をいただきますようお願い致します。
□メールのご依頼フォーマット
メールの件名：KUSANAGI のアップデート依頼
メールの本文
・更新対象サーバのホスト名および、IPアドレス
・パッケージの更新作業後のメールのご連絡の有無(必要 or 不要)
※「必要」、「不要」のいづれかのご記載をいただきますようお願い致します。
回答
更新日 2021年7月21日
KUSANAGI with Cube サービスのご開通時のPHP(HHVM)では、セキュリティ対策のため標準でファイルのアップロードを許可しておりません。 現時点の KUSANAGI with Cube サービスは、php7-fpmを標準で採用させていただいております。詳細につきましては、KUSANAGI with Cubeサービスの仕様をご確認ください。
php7-fpm等へコマンドにて切り替えをいただくか、HHVMの設定を変更いただくかのどちらかになります。php7-fpmへ変更いただく際には、rootユーザにて以下のコマンドを実行します。
kusanagi php7
HHVMの設定を変更いただく場合は、/etc/hhvm/php.iniファイルに以下の設定を追記致します。
hhvm.enable_zend_ini_compat = false
その後、hhvmをサービス再起動します。
systemctl restart hhvm
以上となります。
なお、KUSANAGIコマンドや、ドキュメントにつきましては、公式の以下URLをご参照ください。
KUSANAGI コマンド
KUSANAGI ドキュメント