KUSANAGI バージョンアップ情報 8.0.3-2

KUSANAGI バージョンアップ情報 8.0.2-1

KUSANAGI 8.0.3-1 にバグフィクスを行った、KUSANAGI 8.0.3-2 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.3-2 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.3-2 でのバグフィクス

8.0.3-2 は、以下の問題を解決します。

1. kusanagi ssl --auto on でのメッセージ間違い

Let’s Encryptの自動更新がONの状態で、kusanagi ssl --auto on を実行した際のメッセージが不正なものでした。
このバグは、KUSANGI-8.0.3-2 で解消済みです。

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

HHVM 3.17.1

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.3-1

KUSANAGI バージョンアップ情報 8.0.3-1

KUSANAGI専用プラグインのアップデートを行ったKUSANAGI 8.0.3-1 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.3-1 へのアップデートが可能となります。

# yum update

KUSANAGI 専用プラグインアップデート内容

以前のバージョンまでは、ページキャッシュタブ内にあった「キャッシュ置換文字列」設定を「置換」タブに移動しました。
合わせて、ログイン/サインアップ画面にて、置換処理を行うかどうかの設定項目を追加しています。

置換タブ

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

WP 4.7.1

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.2-3

KUSANAGI バージョンアップ情報 8.0.2-3

KUSANAGI 8.0.2-2 にバグフィクスを行った、KUSANAGI 8.0.2-3 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.2-3 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.2-3 でのバグフィクス

KUSANAGI 8.0.2-3 では、以下の問題を解決します。

  1. kusanagi provision でエラーが表示される

1. kusanagi provision でエラーが表示される

KUSANGI-8.0.2-2 でkusanagi provision 実行時に --email で Let’s Encrypt のSSL証明書を発行するとき、CTログサーバを登録しないようにしました。しかし、この処理で問題があったためスクリプトのエラーメッセージが出力されていました。
このバグは、kusanagi-8.0.2-3 で修正されています。

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

NGINX 1.11.8

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.2-2

KUSANAGI バージョンアップ情報 8.0.2-2

KUSANAGI 8.0.2-1 にバグフィクスを行った、KUSANAGI 8.0.2-2 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.2-2 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.2-2 でのバグフィクス

KUSANAGI 8.0.2-2 では、以下の問題を解決します。

  1. SSL証明書のCTログサーバへの登録失敗
  2. DBの登録削除失敗

1. SSL証明書のCTログサーバへの登録失敗

KUSANAGI-8.0.1-1 で追加しSSL証明書の透明性対応ですが、Google提供のログサーバの一部がサービス停止したことにより、登録に失敗することがわかりました。この影響で、Let’s Encrypt のSSL証明書を使用した場合、Safariなどの一部Webブラウザでの閲覧ができない状態になっていました。
そのため KUSANGI-8.0.2-2 では、以下の措置を取りました。

  1. CTログサーバの変更
    サービスを停止したログサーバ ct.googleapis.com/aviator への登録を停止し、ct.googleapis.com/pilot、icarus、rocketeer、skydiver へ登録するように変更しました。
  2. CTログサーバ登録失敗の処理
    CTログサーバへ登録失敗したとき、エラーメッセージを表示して次のログサーバを登録するように変更しました。またCTログサーバへの登録に失敗したときに、空のSCTファイルが残らないように修正しました。
  3. Let’s Encrypt SSL証明書取得時に、CTをonにしない
    kusanagi provision/ssl でLet’s SSL証明書を取得する際に、自動的にCTをon にしないように変更しました。
  4. CT有効時にログサーバへの登録を抑制するオプション追加
    kusanagi ssl --ct on では、自動的にSSL証明書をCTログサーバへ登録していましたが、既にCT登録済みの商用SSL証明書でも再度登録していました。そこで、オプション --no-register もしくは --noregister を追加し、このオプション指定時には、ログサーバへ登録しないように致しました。
    実行例)

    kusanagi ssl --ct on --no-register プロファイル名

2. DBの登録削除失敗

kusanagi removeでのDB削除処理に問題があり、DB名に記号が含まれる場合にDB削除に失敗していました。
このバグは、KUSANGI-8.0.2-2 で解消済みです。

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

NGINX 1.11.7
Apache2 2.4.25

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

Apache2では、今回から /etc/httpd/conf.d/http.conf および mod_ssl パッケージに含まれる ssl.conf を
_http.conf および _ssl.conf と改名します。これにより、必ずこのファイルに記述された設定をデフォルトとします。

yum update 実行時には問題ないのですが、yum install で kusanagi-httpd を新規にインストールするとき、
mod_sslパッケージが依存関係によりインストールされ、ssl.conf が生成される場合があります。

この場合は、手動で以下のコマンドを実行して改名して下さい。

# mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/_ssl.conf

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

PHP7 7.0.14
WordPress 4.7

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.2-1

KUSANAGI バージョンアップ情報 8.0.2-1

KUSANAGI 8.0.1-2 にバグフィクスを行った、KUSANAGI 8.0.2-1 をリリースします。
また、WP-CLI の1.0.0 へのバージョンアップを行い、併せてリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.2-1 および kusanagi-wp-cli-1.0.0-1 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.2-1 でのバグフィクス

8.0.2-1 は、以下の問題を解決します。

  1. rootkit check tool での誤検知対応

1. rootkit check tool での誤検知対応

chkrootkitrkhunterなどのrootkit検出ツールで、kusanagi-wp-cli に含まれるファイル、/usr/bin/wp が 「RH-Sharpe’s Rootkit」の一部であると検出される問題が発生しました。
内容を確認したところ、以下の点から誤検知と判断しています。

  1. chkrootkitおよびrkhunter での「RH-Sharpe’s Rootkit」のチェックは、指定ファイルが存在するかどうかのみチェックし、内容のチェックは行っていない
  2. 弊社で作成した RPMに含まれる、/usr/bin/wp と配置された /usr/bin/wp の checksum が同一である
  3. kusanagi-wp-cli に含まれる /usr/bin/wp をVirus Check tool(VirusTotal)で確認したところ、Virus は検出されない

この誤検知は今後も発生すること、「RH-Sharpe’s Rootkit」は古くからあるrootkitで、複数あるrootkit検出ツール開発元に誤検知であること通知するのは非現実的なことから、今回 wp のパスを /usr/local/bin/wp に変更いたしました。
今回の変更後、chkrootkitおよびrkhunterで、rootkit が検出されないことは確認済みです。

アップデート後、以下の点ご注意ください。

  1. root ユーザで wpコマンドを使用する場合、.bashrc で設定する wp コマンドの alias を変更して /usr/local/bin/wp を使用するようになっております。yum update を実施後は再ログインし、新しい wp コマンドの alias が有効になるようにしてください。
  2. kusanagi ユーザで wp コマンドを使用する場合、/usr/local/bin を 環境変数PATHに含めるようにしてください