web-dev-qa-db-ja.com

任意の発信データの監視とフィルタリング

中央でmonitorだけでなく、filter Edgeルーターから移動する組織データ関係なく送信側アプリケーションと関係なく送信者アプリケーションが使用するプロトコル/ポート。

たとえば、送信側アプリケーションは、ssh/sftpクライアント、ブラウザ(http/s)、電子メールクライアント(??)、またはゼロから手書きのTCPソケットベースのクライアント)である可能性があります。/serverプログラム。

送信データがたまたま暗号化されている場合(たとえば、https/ssl、ssh/sftpの場合)、MITMのようなパターン(Squidなどのプログラムで採用されている)を介してデータをデコードできるようにしたいと思います。デコードされたコンテンツに基づいて、データの通過を拒否または許可します。

たとえば、大きなファイルがユーザーによって送信された場合、ファイルを抽出して単一の論理ユニットにアセンブルし(IPパケットから?)、このアセンブルされたファイルに対してさらにチェックを実行できるようにしたいと思います。通過を許可するかどうかを決定します。

Linuxベースの環境を考えると、これを実現するためにどの(FOSS)ツールと手法を採用する必要がありますか?私はこの分野に不慣れで、さらに先に進む方法がわかりません。したがって、質問。

1
Harry

まず、このデータをどのように識別するかを決定する必要があります。これはおそらく最大の問題であり、必ずしも技術的なものではありません。

  • すべてのドキュメントとファイルに評価のタグを付けることを目指していますか?これは、ゲートウェイがタグを探してそれに応じて動作するため、単一のデータにタグを付ける組織で機能します。

  • ブロックするデータのブラックリストを設定していますか?たとえば、16桁のシーケンスは、クレジットカード番号である可能性があるため、ブロックできます。誤検知が発生しますが、一部の環境では機能します。

これを並べ替えると、ゲートウェイの側面は比較的単純になります。SSLエンドポイントとして機能するプロキシを介してすべてのデバイスを強制的に接続します。あなたが述べたように、これは事実上MITMです。イカを含む多くのプロキシを使用すると、さまざまな基準に基づいてトラフィックを防止または許可できますが、FOSSスペースでは、可能な複雑さのレベルが制限される場合があります。ただし、上記の2つのオプションは機能するはずです。

これをリアルタイムで実行するためにパケットストリームの詳細な分析を実行しようとすると、FOSSの範囲を超えてしまう可能性があります(ここでいくつかのオプションについては、パロアルトなどの次世代ファイアウォールを参照してください)

3
Rory Alsop

情報漏えい対策(DLP)ソリューションを探しているようですね。商用ツールはたくさんありますが、Google、Snort、およびその他のいくつかの組織がFOSSDLP機能を提供していることを思い出します。

Symantec(Vontu)やWebsenseなどの商用DLPベンダーは、完全なソリューションを提供しています。私が最後にチェックしたところ、FOSS DLPソリューションは、市販のDLPソリューションと比較した場合、まだ機能/機能がかなり不足していました。

HTH

私はあなたが探しているすべての機能を提供するFOSSソリューションを知りません。商用のDLPソリューションでさえsshセッションを覗き見することはできません(l7プロキシアーキテクチャを採用できるため、httpsの方がはるかに簡単です)。課題は、意味のあるルールを構築することです。シグニチャベースのネットワークデバイスはl3/l4で動作し、パケットを会話に再構築しません。それでも、ネットワークのみの動中データ検出器は、何らかのエンドポイントソリューションを実装せずに、プレーンテキストトラフィック(http/https/ftpのインラインl7プロキシを除く)の表示に制限されます。

保護しようとしているデータの種類をもう少し詳しく説明していただけますか?おそらく、機能豊富なデータインモーションFOSSネットワークベースのDLPは利用できないかもしれませんが、データ自体に保護を適用できる可能性があります。そうしないと、適切な予算なしで情報資産を保護することが課題になります。これは、そもそもデータを保護する価値がないと言っていることです。

3
bangdang

SSL Bump 、Squidプロキシに統合されるため、いくつかの条件に従って、発信SSLセッションを復号化できます。

  • 特定のCA証明書をクライアントの「トラストストア」に追加する必要があります。 SSL Bumpは、ターゲットサーバーの偽の証明書を作成し、 man-in-the-middle攻撃 を実行することで機能します。
  • クライアントブラウザは、プロキシを使用することを納得させる必要があります。これは、ファイアウォールとルーターに対する制御のレベルに応じて、ネットワークレベルで実施できます。
  • これにより、証明書ベースのクライアント認証が無効になります。 Web上ではクライアント証明書はまれですが、一部の銀行はクライアントに証明書を発行しています。
  • ユーザーはそれを見ることができます。ほとんどの人間のユーザーは、おそらく「安全な」接続のそのようなフィルタリングの発見に反応しにくい傾向があります。積極的に警告したほうがいいです。透明性は、雇用者と従業員の関係にとって大きな資産です。
0
Thomas Pornin