リアルタイムLinuxカーネルパッチングソフトウェアの選択方法

こんにちは！9月、OTUSはLinuxセキュリティコースの新しいストリーム用のスイートをリリースします。この点で、私たちは伝統的にあなたのために有用な資料の翻訳を用意しました。

---

1991年に、2つの無関係なイベントが発生し、それぞれが2つの非常に異なる自由を告げました。冷戦の終結とLinuxの誕生です。カーネルにリアルタイム



でパッチを適用する可能性は、Linuxがまだ10代だった2008年に生まれました。今日、Linuxカーネルが30に到達しようとしているので、リアルタイムパッチも熟しており、オプションのアドオンとしての評判を軽視する準備ができています。



これには2つの理由があります。 1つ目は、経済的で用途の広いWebホスティングに最適なプラットフォームとしてのLinuxの優位性です。半分以上既知のすべてのWebサイトは現在Linuxで実行されています。第二に、リアルタイムのパッチ適用は便利以上のものであるという認識。また、Linuxシステムのセキュリティを向上させるための効果的で低コストの方法でもあります。



最初のリアルタイムLinuxカーネルパッチソリューションであるKspliceは、発売後、簡単に収益性の高いステータスに上昇し、2011年にテクノロジーの巨人であるOracleが買収したときにのみリーダーシップを強化しました。今日では、Linux用の自動セキュリティパッチサービスを提供している5つの組織の中で最も有名です。アルファベット順で、これらは次のとおりです。

• Ubuntu用の正規のLivepatchサービス。
• Ubuntu、Red Hat Enterprise Linux、Oracle Linux、AmazonLinuxなどのKernelCare。
• Red Hat EnterpriseLinux用のKpatch。
• OracleLinux用のKsplice。
• SUSE LinuxEnterprise用のSUSELinuxEnterpriseライブパッチ。

各企業は、同じ定型キーワード、同じ標準フレーズを無限に繰り返し使用してサービスを宣伝しています。最も人気のあるものと、それらをどのように理解すべきかを説明します。

• 再起動なし：再起動せずにLinuxカーネルを更新します。
• 自動化：オブザーバーなしでカーネルセキュリティ更新をチェックしてインストールします。
• 簡単なインストール：インストールとセットアップは非常に簡単または不要です。
• 完全にサポートされています。自分でパッチを作成する必要はありません。（Kpatchでパッチを作成するためのマニュアルを見て、これが重要である理由を理解してください）

これらの目がくらむほど明白なセールスポイントを無視すると、考慮すべき他の機能、あるサービスを別のサービスと比較するために使用できる他の要因が見つかります。この記事では、肯定と啓蒙で軽く味付けされたそれらのいくつかを探ります。しかし、最初に、ライブパッチとは何かを思い出してみましょう。

リアルタイムLinuxカーネルパッチとは何ですか？

Linuxカーネルには、主に（おそらく）人間のプログラマーによって書かれた2,000万行を超えるコードが含まれています。すべてのソフトウェアと同様に、バグがあります。サイバーセキュリティへの注目が高まっているこの時代では、バグは脆弱性を意味します。この問題を解決するために、Linuxベンダーはカーネルの更新をできるだけ早くリリースしようとします。Linux sysadminも、これらの更新をインストールすることで迅速に対応しようとしているため、スケジューリングがより困難になっています。これは、脆弱性を検出するパターンがないためです。理由は次のとおりです。

• いつでも使用されているLinuxカーネルにはさまざまなバージョンがあります。一部は修正が必要になります。一部はしません。
• , .
• Linux , .
• Linux . , , — .

めったに言及されないことがもう1つあります。それは、システム管理者がマシンを停止することを本能的に嫌悪し、「サーバーはメンテナンスのためにダウンしています」と言わなければならないという物理的な不快感を引き起こします。



なぜサーバーを停止するのですか？カーネルの更新は再起動するまで有効にならないためです。再起動しない場合（バックバーナーに置いたり忘れたりした場合）、最新のパッチが適用されていないサーバーは安全ではないため、困惑することになります。このマントラについては後で詳しく説明しますが、その本質は次のとおり



です。脆弱性が公開されると、その悪用についても同じことが起こります。



または、言い換えると、以前は知らなかった脆弱性がありますが、今は知っています。そして他のみんなも。



このシナリオの救世主はライブパッチです。これは、Linuxカーネル全体ではなく、問題のある部分のみを更新する方法です。そして、これはプロセスを停止したり、ユーザーの作業を中断したりすることなく実行されます。



ただし、制限があります。リアルタイムカーネルパッチは、すべての種類のバグを修正できるわけではありません。カーネルコードの圧倒的な複雑さと、コードをその場で変更するという技術的な課題は、この手法が、通常はセキュリティ関連の重大な問題のトラブルシューティングにのみ使用されることを意味します。



それにもかかわらず、リアルタイムのパッチ機能を備えたシステムは、それを備えていないシステムよりも安全です。リアルタイムのパッチソリューションを探すときに尋ねる質問がいくつかあります。

1.パッチの内容（およびパッチの背後にあるのは誰か）？

ライブパッチサービスにサインアップすると、ソフトウェア自体だけでなく、それ以上の費用がかかります。これは、Linuxカーネルソースを調べ始めて、不十分に記述されたパッチがLinuxシステム全体にどのように害を及ぼす可能性があるかを理解すると明らかになります。



カーネルは、アクティビティとボリュームの両方で拡張するように見える膨大な量の作業であると前述しました。 Linuxカーネルリポジトリのmasterブランチのコード行数が増加していることに注意してください。 （毎年1月1日時点でカウントされます。C/ C ++ファイルとヘッダー、PythonおよびPerlファイルのみがカウントされます。）



コードが非常に多いため、Linuxカーネルのパッチを作成するのは簡単な作業ではありません。カーネルアーキテクチャとデータ構造を深く理解する必要があります。 Linuxコミュニティのコーディング規則と品質基準の経験。また、機能、パフォーマンス、安定性に影響を与えないソリューションを考案するには、特別な才能が必要です。



パッチベンダーがカーネルパッチの開発と配信に使用する2つの反対の方法があります。私はそれらをインクリメンタルでモノリシックと呼んでいます。



チューイングガムのボールのようなインクリメンタルパッチは、互いに積み重ねられ、それぞれが前のパッチの動作を変更します。顧客として、インストールするパッチとインストールしないパッチ、およびそれらがインストールされる順序を追跡する必要があります。これらの問題に注意を払わないと、システムの動作に予期しない変化が生じる可能性があります。このパッチ適用方法により、ベンダーは小さなターゲットパッチをすばやくリリースできます。しかし、時間の経過とともに、システムが不安定になり、完全なカーネル更新のみで復元できるようになる可能性があります。



モノリシックパッチは、以前のすべてのパッチを含むパッチです。基本的に、アクティブなパッチに追加されるのではなく、それを置き換えるマスターパッチは1つだけです。このアプローチにより、プラットフォームがより安定し、サーバーの稼働時間が大幅に増加します。これは、多くの場合、数千日で測定されます。

2.次のパッチまでどのくらい待ちますか？

脆弱性の報告と修正の間には必然的に遅延があります。カーネルエラーの分析には時間がかかり、その影響を評価するには時間がかかります。解決策を見つけるには創意工夫とスキルが必要であり、それが機能することを確認するには多くのテストが必要です。その後、Linux開発プロセスの一環として、必須のレビューと承認が必要になります。



Linuxベンダーがコミュニティの重大度の評価を独自のものに置き換えると、回避可能な遅延が発生します。これは、ベンダーがより少ないパッチで複数の脆弱性を修正できることを意味しますが、このため、顧客は特定の問題を修正するために平均してより長く待機します。



パッチリリースの不安定な性質の理由を理解しているLinux管理者は、理解していない管理者よりも多くの利益を得ることができません。パッチを待っている間、システムが発見される前よりも悪用に対してさらに脆弱であるという知識に安心感を覚える人はいません。



その理由は次のとおりです。サイバーセキュリティ研究コミュニティのメンバーは、視覚的な使用例とともに脆弱性を発表するのが大好きです。それらは通常、概念の証明、バグの再現方法またはエクスプロイトの使用方法の詳細な技術的説明の形をとります。これらの説明は、カーネル開発者が穴を見つけてパッチを適用するのに役立つように誠実に作成されています。しかし、脆弱性を武器として悪用する競争における災害の文字通りのレシピへの近道をハッカーに与えることによって、ハッカーに多くの時間と労力を節約します。

3.エラーはどの程度深刻ですか？

新しく発見されたほとんどすべての脆弱性には、CVE識別子が割り当てられます。その後、セキュリティ研究者による綿密な調査の結果、脆弱性は重大度、つまりその影響の尺度として評価されます。



重要な評価スキームは、一般的なシステムの脆弱性評価（CVSS-一般的な脆弱性スコアリングシステム）です。これは、脆弱性を一連の数値として表します。各数値は、特性のスコアです。次に例を示します。

• 再現（使用）は簡単です。
• それを修正するのはどれほど難しいか。
• サーバーとサービスの可用性への影響の規模。
• オープンデータの重要性または機密性。

完全なセットには、さらに多くの同様の評価が含まれています。アルゴリズムはそれらをベースラインスコアに結合します。1つのきちんとした数値は脆弱性の重大度を表し、0（低）から10（高）の範囲です。2番目のバージョンのCVSSは、これらの数値の範囲をキーワードLOW、MEDIUM、およびHIGHに分割します。 CVSS 3の新しいバージョンでは、NONEとCRITICALの2つが追加されています。



したがって、脆弱性の数は、月や年だけでなく、重大度によっても異なります。



CVSSなどの脆弱性評価スキームにより、Linuxベンダーは特定のカーネルの脆弱性に対応する方法を評価できます。たとえば、累積スコアが7以上の脆弱性のパッチを作成したい場合があります。これは、CVSS v2ではHIGH、CVSSv3ではHIGHまたはCRITICALを意味します。重大な脆弱性をターゲットにしていると主張するベンダーは、CVSS v3を使用している場合、重大度が9および10の脆弱性のみを参照できます。

4.パッチをロールバックできますか？

多くのsysadminにとって、監視なしでパッチを自動的にインストールすることは恐ろしい考えです。彼らは、徹底的にテストされた修正でさえ、システムの動作を変更し、そのパフォーマンスや機能に微妙で完全に明白ではない方法で影響を与える可能性があることを知っています。これが発生した場合、パッチのインストール後にサーバーが異常な動作をする場合、それに対処する最も簡単な方法はパッチを削除することです。



一部のリアルタイムパッチサービスでは、パッチを削除できます。これにより、最近の更新がシステムの動作に変化を引き起こしているかどうかを簡単に判断できます。

5.独自のパッチサーバーをホストできますか？

パッチ適用ソフトウェアエージェントは、リモートパッチサーバーで使用可能なパッチをリアルタイムでチェックします。これは、通常、カスタムチェックを実行する機能を使用して、定期的に構成可能な間隔で実行されます。パッチが利用可能な場合、エージェントソフトウェアはそれをダウンロードしてインストールします。ただし、パッチ適用エージェントが、ベンダーのパッチ適用サービスがパッチを格納しているパッチサーバーと通信できない場合、ライブパッチ適用は行われません。



この問題を解決するには、独自のパッチサーバーを作成する必要があります。このようなローカルサーバーは、ファイアウォールの下にある社内のすべてのコンピューターにパッチをブロードキャストします。Copy Safeはパッチをダウンロードし、パッチファイルの整合性を確認した後、ファイアウォールを介して配布します。会社の取締役会をもう少しリラックスさせることで、都合の良いときにこのプロセスを管理および監査できます。



他にも利点があります。

• サーバーが受信するパッチとそのタイミングをより適切に制御できます。
• 既知のパッチレベルで多数のサーバーをブロックできます。
• 開発、テスト、ステージング、および本番用にサーバークラスターを分離する方が簡単です。

動的パッチには、ローカルエージェントとリモートパッチサーバーが必要です。両方を制御することは、エンタープライズ展開にとって重要です。

結論

目を覚ます前に、潜在的なパッチソリューションプロバイダーに尋ねる3つの追加の質問があります。

• 自動更新をキャンセルできますか？カーネルを自動的に更新したくない場合があります。
• どのプラットフォームで動作しますか？サーバー環境では、リアルタイムのパッチ適用ソリューションを柔軟に選択できない場合がありますが、サービスへのサブスクリプションによって、使用する必要のあるLinuxバリアントが制限されない場合に最適です。
• ? , Linux. . , .

ベンダーの製品説明にパッチを適用する際にそれらがあまり目立たないという事実は、この記事で説明されている機能の重要性を低下させるものではありません。これらはいずれも、特定のサプライヤーに連絡するという決定に影響を与える可能性があります。これらはそれぞれ、環境に対するソリューションの有効性と関連性に直接影響を与える可能性があります。サーバーのサブスクリプション料金は、月に数十から数千米ドルの範囲であるため、Linuxカーネルパッチソリューションを選択する際には注意が必要です。

続きを読む：

AlienVault SIEM（OSSIM）をインストールして構成

するDockerイメージを保護するための10のベストプラクティス。パート

110ockerイメージを保護するための10のベストプラクティス。パート2