クラウドの可視性とポートスプーフィング: 既知の未知数

すべてのテクノロジーと同様に、新しいツールは以前のツールに基づいて構築されており、従来のネットワーク ログとメトリックも例外ではありません。

ツール、計測、およびネットワーク トラフィックの監視は、プライベート クラウドとオンプレミスの展開全体で実質的に変わっていません。現在使用されているログやメトリックの多くは 20 年近く前のものであり、もともとは課金などの問題を解決するために設計されたものです。

交通の流れのパターンを可視化できることも利点のひとつです。トラフィック ログは、実績のあるユース ケースです。しかし、確立された方法に依存すると、ネットワークやポートのスプーフィングにいくつかの穴が残ります。

しかし、ポートスプーフィングとは何でしょうか。また、なぜ重要なのでしょうか。

Web 上のアプリケーションやデータの可視性と同様に、現在使用されているルールや RFC の多くは 10 年以上前に書かれたもので、何かが「どのように」機能するべきかを説明していますが、ルールが実際に強制されているわけではありません。

これにより、めったに使用されないデプロイメントに多くの柔軟性がもたらされます。アプリケーションまたはサービスが誤って構成されている場合、または悪意のある攻撃者が検出を回避しようとする場合、標準ポートにわずかな変更が加えられただけでも、現在のほとんどの可視性および検出スキームが妨げられる可能性があります。

ポート スプーフィングは非常によく知られた手法であるため、MITRE ATT&CK にはこの回避策専用のカテゴリが設けられています。

非標準ポートでセキュア シェル (SSH) プロトコルを使用することは、可視性を回避する最も一般的な多目的な例の 1 つです。 SSH は通常ポート 22 に割り当てられます。

セキュリティ ツールは SSH トラフィックがポート 22 を使用することを前提としており、世界中のほぼすべてのセキュリティ チームがそのポートを厳重にロックダウンしています。一般的な方法は、このポートを境界でブロックして安全であるとすることです。簡単ですよね？

そんなに急がなくても。悪意のある攻撃者が SSH トラフィックのデフォルト ポートを変更した場合はどうなるでしょうか?ポート 443 は HTTPS/TLS で広く使用されており、ほぼ常に開いています。

HTTPS トラフィックは、ビジネス上重要な活動と個人的な活動の両方において、現代の企業で広く使用されています。 IT ファイアウォールはポート 443/HTTPS を定期的にブロックしないため、攻撃者にとって理想的な侵入ポイントとなります。

SSH を 443 で実行するように変更するのは簡単です。これを実行する合法的および違法な理由を詳細に説明しているフォーラムは多数あります。ほぼすべての最新のクラウド可視化ツールは、実際に起こっていることではなく、トラフィックをそのまま報告します。

クラウド内のワークロードでも、自身の接続を誤って識別する可能性があります。 Linux オペレーティング システムはポートに基づいて接続タイプのみを取得するため、アクティブな SSH セッションが TLS として誤って報告される可能性があります。

ネットワークは誤った認識をし、オペレーティング システム ツールもこのトラフィックを既知のトラフィックとして報告するため誤った認識をします。

現在、ほぼすべてのトラフィックは TCP ポートと UDP ポートによって評価されます。これにより、トラフィックの性質について多くの仮定が生まれます。これは、パブリック クラウド、プライベート クラウド、オンプレミス クラウドのいずれにも当てはまります。

安全性への意識がますます高まっている今日の世界では、交通の性質について推測することは、以前ほど安全ではありません。 SSH は、脅威の攻撃者があらゆるネットワーク上でファイル転送、トンネリング、横方向の移動を実行するために使用できる非常に強力なツールです。

これは、ツールが複数の用途を持つことができる一例にすぎません。他のアプリケーションやプロトコルを考慮すると、目に見えないものがどれだけあるかに気づくのは気が遠くなるような作業になります。 Mitre にはポート スプーフィングの独自のカテゴリがあり、この傾向は拡大する一方です。

東西輸送にも深い観測性が求められます。次世代ファイアウォール (NGFW) は、境界ポイント内でこの問題に対処します。しかし、パブリック クラウドは別の問題であり、東西または水平規模ではまだ解決されていません。

VPC フロー ログには、ポート番号とともに発生している会話のみが記録され、使用されているアプリケーションやプロトコルに関する実際の情報は記録されません。ディープ パケット インスペクションによる詳細な観測により、会話の調査が可能になり、使用されているアプリケーションとプロトコルを正しく識別できます。

当社ではこれをアプリケーション インテリジェンスと呼んでおり、現在、ネットワーク トラフィックの検査中に 5,000 を超えるアプリケーション、プロトコル、属性を認識します。

アプリケーション メタデータ インテリジェンスは、外側のヘッダーだけでなく、パケットのさらに奥深くまで調べます。特定のアプリケーションを定義するデータ パケットの固有の特性について詳しく説明します。これを「深層観測性」と呼びます。

攻撃者が同じサブネット内のワークロード A からワークロード B に SSH 経由で接続する場合、当社のディープ オブザーバビリティ パイプラインはアプリケーション インテリジェンスを使用してトラフィックの実際の状態を確認し、セキュリティ ツールに報告します。

この場合、ポート 443 に Web トラフィックを装った SSH トラフィックがあることを技術者に警告できます。この深いレベルの可観測性は、パブリック クラウドやコンテナ間通信など、企業全体に容易に広がります。

パブリック クラウドでは、ディープ パケット インスペクションによって独特の課題が生じます。ブロードキャストがない場合、トラフィックを検査するには、トラフィックを誘導する安全な VPC が必要になるか、トラフィック ミラーリングが必要になります。

2 番目の、より簡単なオプションは、トラフィックを適切なツールにミラーリングすることです。 Gigamon は 2 番目の問題を解決します。メリットとしては、オンライン検出パスで発生するパフォーマンスの低下がなく、導入の複雑さと運用上の摩擦が軽減されることが挙げられます。

わかっていることは、開発者は引き続き速いペースで作業を進め、DevOps は不明なアプリケーションや誤って構成されたアプリケーションをデプロイし、脅威アクターはこれらの脆弱性を悪用して盲点を作り出そうとし続けるということです。

SecOps はルールと保護を検証しようとしますが、これはネットワークから得られるインテリジェンスと洞察による深い観測性を通じてのみ真に達成できます。

組織が非標準ポートでの SSH の単純な使用例を検出できない場合、ハイブリッド クラウド インフラストラクチャには他にどのような既知の未知のものが潜んでいる可能性がありますか?