レポートの内容/proc/uptime:
48973211.37 1627573879.70
48973211 秒は、サーバーが再起動せずに 567 日間稼働していることを意味します。
それ以来、Linux カーネルには多くの重大なセキュリティ修正が適用されました。私のサーバーは一度も再起動されていないので、それらのパッチがすべて適用されていないに違いありません。私はヨーロッパの大手 Web ホスティング会社に勤めています。しかし、誰かを責めたくはないので、名前は言いません。
小さなウェブスペースです。PHP + MySQL を使用しています (特別なものではありません)。
試していませんが、PHP の exec() 関数を使用して実行可能ファイルを実行し、カーネル呼び出しを直接実行できる可能性があります。ただし、たとえそれが不可能であっても、パッチが不足していることは問題だと思います。
それで、どうすれば安全になるのでしょうか? さまざまな仮想化技術があることは知っています。そのうちの 1 つがそれを説明できるでしょうか?
答え1
いいえ、箱を長時間置いておくのは安全ではありません。
汎用オペレーティング システムは、セキュリティ (および品質) アップデートを取得するために、年に複数回再起動する必要があります。最終的にはアプリケーション、C ライブラリ、TLS ライブラリなどの修正が行われるため、すべてのプロセスが影響を受けます。システム全体を停止して、ウォーム ブートを実行できることを確認する方が簡単です。
ライブ パッチは限定的なテクノロジです。一部のエンタープライズ ディストリビューションでは、主にセキュリティ関連のカーネル更新について、再起動不要の更新を提供するという手間をかけています。しかし、これですべてを修正できるわけではなく、ほとんどのアプリケーションにはそのような機能はありません。
これが VM ゲストであると仮定すると、その下のハイパーバイザーも時々メンテナンスが必要です。ライブ マイグレーションまたはメモリ状態の保存により、ゲストは物理ホストを切り替えても実行を継続しているように見えます。ただし、これはゲストのパッチ適用には役立ちません。ゲストには依然として独自の更新が必要です。
マネージド ホスティング サービスを使用する場合、コンピューティング ゲストとホストは別の人の責任になりますが、それでも保証は得られます。プロバイダーに、ソフトウェア更新ポリシーが全般的にどのようなものか尋ねてください。つまり、プロバイダーはこれに対して明示的に責任を負っているか、頻度は四半期ごとか、あるいはその他の頻度か、ということです。回答がなかったり、意図的に何年もそのまま放置したりするのは、無能さの兆候です。
可用性が懸念事項である場合は、複数のノードの高可用性ソリューションを用意する必要があります。これは、1 つのホストの稼働時間ではなく、提供されるサービス全体です。
答え2
いいえ。保護されていません。
コンテナ化などの仮想化技術は、Linux Web サーバーに一定レベルのセキュリティを提供できますが、定期的な更新と監視の代わりにはなりません。潜在的な脅威からサーバーを隔離するのに役立ちますが、基盤となるオペレーティング システムを最新の状態に保ち、問題を監視することは依然として重要です。