再起動せずにLinuxサーバーを実行するのに役立つ5つのカーネルライブパッチツール

この記事では、Linuxカーネルのライブパッチとは何か、稼働時間を確保する方法、サーバーを何年も再起動せずに実行するのに役立つ5つのツール、およびその長所と短所について学習します。各ツール。

IT組織内には、目に見えないほど日常的なプロセスと慣行があります。そのようなプロセスや慣行に欠陥があるかどうか、またはより良い方法が存在するかどうかは関係ありません。何かが数年間機能している場合、人々は代替案を探すのをやめます。これは、カーネルパッチへの現在のアプローチを完全に説明しています。。

現在、ほとんどの組織は再起動サイクルを計画してサーバーにパッチを適用しています。サーバーフリートの再起動はダウンタイムの原因となる頭痛の種であるため、人々はできる限りそれを延期します。つまり、パッチはできるだけ早く適用されません。パッチの問題とその適用の間のこのギャップは、リスク、不正行為を意味し、コンプライアンス違反を引き起こす可能性があります。

カーネルパッチへのこの標準的なアプローチは、複数の攻撃ベクトルに対する脅威アクターによる悪意にサーバーをさらし、IT組織を重大なセキュリティ問題のリスクにさらします。組織をサイバー攻撃から保護する任務を負っている人は、再起動せずにLinuxサーバーを実行するためのより良い方法を模索する必要があります（理想的には何年も）。

ライブパッチが存在する理由

2009年、ウェブサーバーを管理しているMITの学生は、サーバーのLinuxカーネルへのパッチ適用を遅らせました。パッチを適用すると、ユーザーに不便をかける再起動が必要になるためです。遅延中に、サーバーがハッキングされました。これは学生、ジェフアーノルドに影響を与えました、サーバーを再起動せずにLinuxカーネルにパッチを適用する方法を開発するため。

彼は他の3人の学生と協力してKspliceを開発しました、Linuxカーネルにパッチを適用するための最初の「リブートレス」ソフトウェアツール。彼らは、オラクルに買収された新製品を宣伝する会社を設立しました。 OracleがKspliceを独自のディストリビューションであるOracleLinuxと統合したとき、他のLinuxベンダーは独自のライブパッチシステムに取り組み始めました。

これは、ライブパッチ（サーバーの実行中にセキュリティパッチを適用し、再起動は不要）が、複数のサーバーを管理する組織に貴重な機能を提供するためです。

再起動せずにサーバーを継続的に運用します。これは、ダウンタイムがほとんどまたはまったくないことを意味します。
パッチ関連タスクの自動化。これにより、サポートスタッフは他の作業に解放されます。
新しいパッチの即時適用。これにより、サーバーの脆弱性が大幅に減少します。

LinuxKernelLiveパッチの仕組み

Linuxカーネルにライブパッチを適用するには、次の2つの基本的な方法があります。一時的 および永続的 。一時的な方法では、再起動せずにパッチを適用しますが、実際には後でサーバーを再起動する必要があります。永続的なライブパッチは、再起動をまったく必要としません。

一時的な方法

一時的な方法ライブパッチを適用するには、パッケージ管理ソフトウェア（YUMプラグインなど）をサーバーにインストールする必要があります。パッチがリポジトリに配信されると、ユーザーが指定した更新ワークフローに従ってパッチが適用されます。

このメソッドは、一部のLinux OSディストリビューション、および一部のベンダーのサポート契約に含まれています。ただし、無料または安価と見なすべきではありません。時間と手間がかかるため、事前にはわかりません。

「スタック」パッチとも呼ばれる一時的な方法には、サーバーの再起動とダウンタイムが含まれます。これは、一時的なパッチが時間の経過とともに積み重なって、パフォーマンスと安定性が低下するためです。この問題の唯一の解決策は、サーバーを再起動して新しいカーネルをメモリにロードすることです。

永続的な方法

永続的な方法を使用ライブパッチの場合、専用のパッチサーバーが最新のパッチを保存します。これらのパッチは、以前のパッチが組み込まれているため、一時的なものではなく「モノリシック」です。パッチを適用するWebサーバーでは、エージェントプログラムがバックグラウンドで実行され、パッチサーバーのパッチを定期的にチェックします。エージェントから指示されると、カーネルモジュールがパッチを実行します。

この方法にはベンダーのライセンス料が含まれますが、これらの料金は驚くほど低くなる可能性があります。また、手動作業を自動化されたプロセスに置き換える場合、永続的な方法により、サーバーの管理に必要な時間と労力が削減されます。最も重要なことは、再起動がまったく必要ないため、サーバーを稼働状態に保つことができ、場合によっては一度に何年も稼働できることです。

永続的なライブパッチは、他の重要な利点も提供します。 Spectre など、通常は再起動が必要なハードウェアの脆弱性がある場合でも、、メルトダウン 、およびゾンビロード 、persistentメソッドを使用するサーバーは稼働し続けます。また、SOC2などのセキュリティ標準に準拠するために重要な脆弱性スキャナーと連携します。

推奨される読み物：

LinuxでMeltdownとSpectreの脆弱性をチェックしてパッチを適用する方法

再起動せずにLinuxサーバーを実行するのに役立つ5つのLinuxカーネルライブパッチシステム

さまざまなベンダーから入手できるいくつかの異なるカーネルライブパッチシステムがあり、そのほとんどは特定のLinuxディストリビューションで使用することを目的としています。

Oracle Ksplice

Kspliceは、2009年に作成され、2011年にOracleによって買収されたオリジナルの「リブートレス」Linuxカーネルパッチシステムです。現在、Oracle Linuxでのみ動作し、RHELはOracleライセンスで動作します。スケジューリング機能はありませんが、再起動を必要とせずにパッチの自動更新を実行します。

RedHat Kpatch

Kpatchは、独自のLinuxディストリビューションで動作するようにRed Hatによって作成されましたが、Fedora、CentOS、およびUbuntuやGentooなどのDebianベースのシステムに移植できます。自動化されていません。Kpatchを使用する場合、管理者はパッチを手動で確認して適用する必要があります。

SUSE Kgraft

KgraftはSUSEのライブパッチシステムであり、SUSE独自のLinuxEnterpriseServerでのみ動作します。他のシステムとは異なり、パッチが適用されている間、Kgraftはカーネル機能を停止しません。代わりに、関数を監視して、1回のシステムコールですべてのパッチを適用できるようにします。

Ubuntu Livepatch

Livepatchは、Ubuntuを開発している会社であるCanonicalによって作成されました。管理者が独自のカスタムカーネルパッチを作成できるという点で、ライブパッチシステムの中でもユニークです。もちろん、Ubuntuで動作しますが、Red HatEnterpriseLinuxでも動作します。

KernelCare

CloudLinuxによって開発されたKernelCareは、CentOS、RHEL、Oracle Linux、Amazon Linux、Debian、Ubuntuなどの最も一般的なディストリビューションで動作します。自動化されており、インストールが簡単で、複雑なパッチを処理し、特定のニーズを満たすためのカスタムおよび固定日付のパッチを提供します。

機能と価格の比較

パッチ機能

	KernelCare	Oracle Ksplice	レッドハットKpatch	SUSE Kgraft	Ubuntu Livepatch
パッチセットの配布	すべてのパッチに単一のパッチセット	それぞれが個別のモジュールです	それぞれが個別のモジュールです	それぞれが個別のモジュールです	すべてのパッチの単一パッチセット
リリースのタイミング	ベースディストリビューションの前または直後	ベースディストリビューションのパッチ後	提供されていません	SUSEのリリースサイクルに一致	UBUNTUのリリースサイクルに一致
Glibcパッチ適用	はい	はい	いいえ	いいえ	いいえ
OpenSSLパッチ適用	はい	はい	いいえ	いいえ	いいえ
カスタムパッチ	はい	いいえ	はい	はい	いいえ

互換性と実装

	KernelCare	Oracle Ksplice	レッドハットKpatch	SUSE Kgraft	Ubuntu Livepatch
古いカーネルをサポートしますか？	はい	はい	いいえ	いいえ	いいえ
32ビットサポート？	カスタム	はい	いいえ	いいえ	いいえ
APIを利用できますか？	はい	はい	いいえ	はい	はい
ロールバック機能？	はい	はい	いいえ	いいえ	いいえ
ファイアウォールの背後で機能しますか？	はい	はい	はい	はい	はい

サポートされているディストリビューション

Oracle Ksplice	Oracle Linux、Fedora 25-27、Ubuntuデスクトップ14.04-17.10
レッドハットKpatch	Red Hat Enterprise Linux、Ubuntu、Debian、Gentoo
SUSE Kgraft	SUSE
Ubuntu Livepatch	Ubuntu
KernelCare	CloudLinux OS、Amazon Linux 1＆2、CentOS、Debian、OpenVZ、Oracle Enterprise Linux、Oracle UEK、Proxmox VE、Red Hat Enterprise Linux、Ubuntu、Ubuntu Core、Virtuozzo 、Xen4 CentOS、Yokto

サーバーごとの料金

Oracle Ksplice	サーバーあたり年間2299ドル（1399ドル）：Oracle Linux Premierまたは（限定）サポートサブスクリプションのコスト
レッドハットKpatch	サーバーあたり年間1299ドル：RHELプレミアムサポートサブスクリプションのコスト
SUSE Kgraft	サーバーあたり年間2198ドル：ライブパッチサービス（699ドル）と優先サーバーサブスクリプション（1499ドル）の合計コスト
Ubuntu Livepatch	サーバーあたり年間225ドル、仮想マシンの場合は年間75ドル：UbuntuAdvantageサポートサブスクリプションのコスト
KernelCare	500以上のサーバーライセンスの場合、サーバーあたり年間27ドル。

関連記事

Ucheckerを使用してメモリ内の古い共有ライブラリを検出する

どのLinuxカーネルライブパッチシステムがあなたに最適ですか？

Webサーバーを社内で実行し、システム管理者の大規模なスタッフ、標準化されたシステム、およびOracle、Red Hat、またはSUSEとの既存のサポート契約を結んでいる企業の場合、付属のパッチシステムを使用するメリットがコスト。これらのベンダーのサポート業務と定期的にやり取りすることで、ベンダーのサポート業務を合理化できる可能性があります。

Ubuntuで標準化されているWebサーバーを実行している組織の場合、サポートサブスクリプションに含まれているLivepatchシステムが適しています。システムは健全であり、前述のサポート契約と比較してコストは低くなっています。

さまざまなLinuxディストリビューションを含む大規模なサーバーフリートを持つ企業にとって、KernelCareシステムが唯一の実行可能なオプションです。また、コストと効率が懸念される企業にとっても良い選択であり、自動化された柔軟なパッチ適用を低コストで提供します。

「モノのインターネット」の一部としてインターネット対応デバイスを実行している企業の場合、KernelCareが唯一のオプションです。これらのデバイスの大部分はLinuxコンテナを使用しており、ハッキングされると致命的な結果を招く可能性があるため、カーネルにパッチを適用しておくことが重要です。 KernelCareシステムのパッチのリリースタイミングが速いため、IoTアプリケーションに最適です。

関連記事：

Ubuntu用のLinuxカーネルを更新するさまざまな方法

現在、前述のライブパッチシステムのいずれかを使用していますか？以下のコメントセクションセクションであなたの考えを共有してください。