4

問題の説明: 私のアプリケーションでは、データ パケットの内容を特定の形式で提示する必要があります。例：

例 任意のパックされたバイナリ データ。たとえば、4 バイトのヘッダー、4 バイトの型 (定義済みの意味を持つ型コード)、送信元アドレス、宛先アドレスなど。

以前は、データをバイナリ ファイルに格納する家庭料理の実装を作成しました (固定レコード長により高速検索が可能)。たとえば、非常に大きなデータ ファイル用に独自の効率的なバイナリ ストレージ フォーマットを実装しています。また、一部のフィールドで検索を迅速に実行するために、独自のインデックス作成も実装しています。本当の DB (単純な SQLite でさえも) は、このようなことを透過的に単純化できると思います。

質問 #1: DB はそのようなデータの保存に役立ちますか? また、どのように行う必要がありますか? ここには 1 対多、多対多のマッピングやその他の高度なものがないことに注意してください。これは、特定の内部構造を持つ単純なパケットのシーケンスであり、ユーザーに表示して対話させます (つまり、検索特定の分野によって）。

質問 #2:ここで、ユーザー自身が自分のパケットのフォーマット、つまり構成ファイルで指定できるとします: 各フィールドの長さ、そのタイプ、その値の意味 (列挙の場合) など。このために DB を利用した実装を拡張するにはどうすればよいですか? ユーザーが DB スキーマを定義する必要がありますか? 構成ファイルをこのスキーマに自動変換する必要がありますか? ORM?

質問 #3:さらに高度な. データ パッケージの長さと内容が異なる場合があるとします。つまり、タイプ #2 のパッケージにはいくつかのフィールドがあり、タイプ #3 にはいくつかの他のフィールドなどがあります。しかし、アプリでそれを処理して、すべてを適切に表示し、ユーザーが構成ファイルで形式を指定できるようにしたいと考えています。それはどのように行われますか？

前もって感謝します。

4

6 に答える 6

1

3つの方法が思い浮かびます。

sFlow と IPFlow は、限定された一連のパケット コンテンツを送信できます。これは、いくつかの異なるデータベースに直接ログインできます。

より的を絞ったもう 1 つの方法は、送信元アドレスや宛先アドレスなどの非常に単純な Snort ルールを作成することです。次に、パケットのペイロードをキャプチャします。そうすれば、必要な実際のデータのみを取得できます。たとえば、パケット内のデータのフィールドだけを取得できます。例：パスワードなど

ngrep は、選択したデータをすぐに取得することもできます。

もちろん、サーバー/ワークステーション自体でキャプチャを行っていない場合は、これらのそれぞれにポートでのタップまたはモニター セッションが必要になる可能性があります。

于 2010-08-12T13:01:31.117 に答える
1

1対多の関係はないとあなたが述べたという事実にもかかわらず、あります:)

パケット ストレージ用に 2 つのテーブルを作成することをお勧めします。パケットに共通の「ヘッダー」または「スカラー」情報を格納するものであり、どのデータが存在するかを定義する場合がありますが、パケットに格納される実際のデータではありません。

2 番目のテーブルには、各パケットのデータが格納され、各フィールドと値の組み合わせがこのテーブルの行を表します。たとえば、次の 2 つのテーブル:

create table packet
(
    packet_id int identity(1, 1) primary key,
    destination varchar(50),
    sender varchar(50),
    packet_type_id int not null
)

create table packet_field
(
    packet_field_id int identity(1, 1) primary key,
    packet_id int not null references packet (packet_id),
    field_id int not null,
    data varbinary(500)
)

明らかに、これら 2 つのテーブルは、格納されるデータの型とサイズについて仮定を行っており、格納する必要があるものを網羅しているわけではありません。ただし、この基本的な構造により、動的に定義されたパケット形式が可能になり、簡単にインデックスを作成できるスキーマになります (たとえば、インデックスを追加するのはpacket_id+field_id簡単packet_fieldです)。

アプリケーションが担当するのは、パケットをアンパックしてこのスキーマのDBに保存し、必要に応じて再パックすることだけです。

もちろん、この時点から、パケットの実際の形式を格納するテーブルが必要になります。何かのようなもの...

create table packet_type
(
    packet_type_id int identity(1, 1) primary key,
    name varchar(200) not null
)

create table packet_type_field
(
    field_id int identity(1, 1) primary key,
    packet_type_id int not null references packet_type (packet_type_id)
    field_offset int not null,
    name varchar(200) not null
)

繰り返しますが、明らかに単純化されていますが、基本的な考え方を示しています。packet_typeテーブルにはパケット形式ごとに 1つのレコードがありpacket_type_field、特定のパケットの各フィールドには 1 つの行があります。これにより、バイナリ データの任意のチャンクを前述のパケット ストレージ スキーマに処理するために必要なほとんどの情報が得られます。

于 2009-04-02T13:23:10.363 に答える
0

私はこの実装の大ファンではありませんが、一部の呼び出しリストに対して本質的にこれを行うソフトウェアがいくつかあります。基本的に、これが彼らがすることです：

  1. 列定義を含むテーブル - tblColumnDefs と呼びます。このテーブルには、「名前」、「タイプ」、「長さ」、「説明」などの列が含まれています
  2. インスタンス マスター テーブル (tblPacketNames)。基本的に、定義している各パケット タイプの「PacketTypeID」、「PacketName」、および「Description」だけです。
  3. インスタンス定義テーブル (あなたの場合、これは tblPacketColumns になります)。このテーブルは、事前定義された列をまとめて、保存するデータ構造を形成します。たとえば、「PacketTypeID」、「ColumnNumber」、「ColumnID」を保持できます。データベースの正規化で言えば、これは多対多のテーブルです。これは、列をそれらを使用するパケットにマップするためです。
  4. 2 番目のデータベースでは (このステップの動的 SQL/インジェクションの影響のため)、実際のデータを保持するためにテーブルが動的に作成されます。たとえば、(手順 2/3 で) "PING" というパケット タイプを定義した場合、そのデータを保持するためにデータベースに "PING" というテーブルが存在する可能性があります。tblColumnDefs にリンクされた tblPacketColumns を使用して、作成するフィールド タイプとそのサイズを決定します。手順 1 の列を使用して、手順 3 のパケット タイプの定義に一致するテーブルのコレクションが作成されます。

注: ステップ 4 の SQL インジェクションの影響は特に好きではありません。動的にテーブルを作成すると、セキュリティが適切に設計されておらず、アプリケーションのユーザー入力フィールドからの入力が適切にクレンジングされていない場合、何らかの結果が生じる可能性があります。特に、このアプリケーションに、信頼されていない呼び出し元 (つまり、インターネット) が使用できるインターフェイスがある場合。

これを使用すると、テーブルの作成時に必要に応じてインデックスを作成できます (手順 1 で、特定の列に「インデックス可能」のフラグを立てる列があり、テーブルの作成時にそれらの上にインデックスが作成される場合があります)。

于 2009-03-30T16:53:50.177 に答える