(57)【要約】【課題】IPエンティティ120/121からサーバ108への接続を制御する方法を提供すること【解決手段】最初に、該IPエンティティ120/121とサーバ108との間で同時に許容できる接続106の数を表す限度カウントを決定する。到来するIPパケットを受信した際に、該IPパケットを処理してその送信元及び宛先IPアドレスを決定する。IPエンティティ120/121のエントリが制限テーブル(103)中に存在しない場合、該IPエンティティのエントリを該制限テーブル中に作成する。該制限テーブル103中の限度カウント及びエントリを参照して、保留中の接続を前記IPパケットについて許可すべきか否かを判定する。試行された接続がIPエンティティ120/121の限度カウントを超えない場合、該接続が許可されて該エントリの限度カウントがインクリメントされ、それ以外の場合には該パケットを阻止する。【選択図】図１
2004364306.tif 000002
【特許請求の範囲】
【請求項１】
送信元IPアドレスを有するIPエンティティ(120/121)からサーバ(108)への接続を制御する方法であって、
前記IPエンティティ(120/121)と前記サーバ(108)との間で同時に許容できる接続(106)の数を表す限度カウントを設定し、
到来するIPパケットを受信し、
該IPパケットを処理して、該IPパケットの前記送信元IPアドレス及び宛先IPアドレスを決定し、
前記IPエンティティ(120/121)のエントリが制限テーブル(103)中に存在しない場合に、該IPエンティティ(120/121)のエントリを該制限テーブル(103)中に作成し、
該制限テーブル(103)中の前記限度カウント及び前記エントリを参照して、保留中の接続を前記IPパケットについて許可すべきか否かを判定し、
前記保留中の接続が前記IPエンティティ(120/121)の前記限度カウントを超えない場合、前記接続(106)を許可し、及び前記エントリの前記限度カウントをインクリメントし、
前記保留中の接続が前記IPエンティティ(120/121)の前記限度カウントを超えることになる場合には、前記パケットを阻止する、
という各ステップを含む、IPエンティティからサーバへの接続を制御する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IPエンティティからサーバへの接続を制御する方法に関するものである。
【背景技術】
【０００２】
本出願は、2003年6月3日出願の同時係属中の「Method and Program Product for Reducing Database Walk Frequency While Repetitively Accessing A Firewall Connection and Rule Database」と題する米国特許出願第10/453,102号に関連するものである。
【０００３】
コンピュータネットワークにおけるファイアウォールは、内部ネットワーク内の受信者を宛先とするメッセージを監視するゲートウェイ又は他のネットワークサーバに接続されたプログラムされたプロセッサ又はそのサブシステムである。ファイアウォールは、所定の基準（特定のパケット送信元アドレス又はメッセージ内容を含むことが可能なもの）を満たすメッセージを阻止する。典型的なファイアウォールでは、送信側クライアントとネットワーク受信者との間の接続は、受信するTCP/IPパケットのパラメータを、所与の伝送を許可すべきか阻止すべきかを判定するルールと比較することにより、許容され又は拒絶される。特定のメッセージが正当なメッセージであるか不要な「スパム」（広告、悪意のある大量送信、及び／又はその他の迷惑メールを含む）であるかを判定するためには、ネットワークトラフィックを解析して、不要なメッセージを送信している特定のクライアントを特定しなければならない。
【０００４】
現行のファイアウォールシステムは、受信するメッセージをスクリーニングするという基本的な機能を提供するが、メッセージを阻止し又は拒絶すべき特定のクライアントを検出するように該システムのルールをセットアップし又はプログラムしなければならない。システム管理者は往々にして、ログに記録された情報を解析して何れのクライアントが受信接続要求で自分のシステムを攻撃しようとしていたかを発見するだけではなく、自分の内部ネットワークに対する特定の「スパマー」のアクセスを制限する特定のルールを設定するために、多大なる時間を費やしている。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
多くの既存のファイアウォールは、コンテンツベースのものであり、すなわち、実際のメッセージ自体を読み、すなわちスキャンする。コンテンツベースのメッセージスクリーニングは、コンピュータ資源の観点から高コストを要し、潜在的なプライバシー問題も存在するものである。コンテンツベースのファイアウォールは幾つかの正当なメッセージを拒絶することが多いということも知られている。ファイアウォールが可能な限り多くの不要なメッセージを検出可能であることは重要であるが、ファイアウォールが正当な電子メール又はその他の伝送を阻止又は拒絶しないことは、前者よりも一層重要ではないとしても、前者と等しく重要なことである。
【０００６】
更に、受信するTCP/IP接続を制御するシステムを管理するために、システムクライアントから受信するトラフィック、及び所定の接続限度を超える接続試行回数を記述する、正確なレポートを作成することが望ましい。従来の既知のアクティビティログ記録方法は非効率的なものである。かかる方法は、(1)カーネル内メモリテーブルを保持すること（特定の受信システムについてログ情報が不必要な場合を知ることが困難であるため、その維持は困難である)、及び、(2)限度を超えた各TCP/IP SYN(接続)パケットのログを記録すること(これは非常に大量のログメッセージを作成するものとなる）を含む。
【課題を解決するための手段】
【０００７】
IPエンティティからサーバへの接続を制御するシステムを開示する。まず、IPエンティティとサーバとの間で同時に許容することのできる接続の数を表す限界数が決定される。到来するIPパケットが受信された際に、該パケットを処理して該パケットの送信元IPアドレス及び宛先IPアドレスが決定される。次いで、そのIPエンティティについてのエントリが制限テーブル中に存在しない場合に、該IPエンティティについてのエントリが該制限テーブル内に作成される。前記限度数及び前記制限テーブル内のエントリを参照することにより、保留中の接続をそのパケットについて許可すべきか否かが判定される。試行されている接続がそのIPエンティティについての限度数を超えない場合には、接続が許可され、そのエントリについての限度数がインクリメントされる。また、試行されている接続がIPエンティティの限度数を超える場合には、パケットは阻止される。
【発明を実施するための最良の形態】
【０００８】
図１は、クライアントからサーバへの同時接続を制限する例示的なシステムの一実施形態のブロック図である。本ＤＣＡ（Dynamic Connection Allocation：動的接続割当）ファイアウォールシステム100は、一組のルール及び監視コマンドを含む。図１に示すように、例示的な一実施形態では、ファイアウォール100は典型的には、電子メールクライアント120とSMTP（Simple Mail Transport Protocol）サーバ108との間のトラフィックをフィルタリングするが、代替的な実施形態では、POP3（Post Office Protocol）等の他のプロトコルを使用した伝送をフィルタリングするために使用することが可能である。サーバ108を宛先とするIP(インターネットプロトコル)パケットは、クライアント120から、インターネット等のネットワーク121、ゲートウェイ及び／又はルータ111、及びシステムインタフェースカード112を介して送信され、その後、該パケットはＤＣＡファイアウォール100に遭遇する。
【０００９】
ファイアウォール100は、インバウンドTCP/IP接続要求パケットを解析し、ルールテーブル105を使用して、特定の送信元IP、宛先IP、及び宛先TCPポート110に許容すべき同時接続106の数を決定する。次いで、IPパケットがアウトバウンドインタフェース上のスイッチ123を介してサーバ108へ送られる。ＤＣＡファイアウォール100は、プロセッサ112上で実行されるフィルタリング機能を含むフィルタ101を備えている。該フィルタリング機能は、プロセッサによりアクセスすることが可能なメモリに格納されている関連するファイル及びテーブル102〜105を使用する接続限度チェック関数［'fnlimit_check()'］109を含む。
【００１０】
ＤＣＡファイアウォール100は、
-個々のIPアドレス
-IPサブネット(CIDR)範囲
-サブネットに対して設定された個々の限度を有する各アドレス、又は、
-累積限度を共有するサブネット範囲内の全てのアドレス、及び、
-デフォルト値
により、IPエンティティ（例えばクライアント又はサブネット）がサーバに対して同時に行うことのできる接続数を制限すると共に、一度にアクティブ化することのできる特定のクライアント又はサブネットからの接続数に対する明示的な限度をシステム管理者が設定することを可能にする。
【００１１】
明示的な限度を有さないIPアドレスにはデフォルト値（許可される同時接続数についての個々の限度）を割り当てることができる。システム管理者は、接続が阻止された場合に接続を切断するかRSTパケット（接続をリセットするもの）を返すかを設定することができる。
【００１２】
本システムは、範囲の広い「限度維持(keep-limit)」ルールを使用して、クライアントシステムのカテゴリを識別し、次いで特定のクライアント120又はクライアントグループからの同時接続要求を予め設定された限度に制限する。デフォルトルールは、他の全てのクライアントを識別し、それらを予め設定された接続限度に従わせる。
【００１３】
以下は、ＤＣＡ「限度維持」ルールの例示的な構文である。
pass [return-rst] in [log|log limit[freq] quick proto tcp from
to[port=]keep limit[cumulative]
この限度維持ルールの構文は、次のように説明することができる。
１. pass［return-rst］
−これは、限度数を超えない場合には接続を許可し、設定された限度「limit count」を超える場合にはリセット(TCP RST)を送るように、ＤＣＡシステム100に命令する。
２. ［log｜log limit］
−これは接続をログに記録するようＤＣＡシステムに命令する。「log」が使用される場合にはセッション全体がログに記録され、「log limit」が使用される場合には限度を超えた接続試行のSYNパケットのみがログに記録される。ログ記録については、以下の「サマリログ記録」の項で詳細に述べる。
３. 送信元アドレスは、ワイルドカード、特定のIP、又はIPサブネットとすることが可能である。宛先IPアドレスも送信元IPアドレスと同じ構文に従わなければならない。
４. 送信元ULP(上位レベルプロトコル)ポートは指定できない。
５. 宛先ポートは、ワイルドカード又は所定のポート（resolved port）とすることが可能である。しかし、ポート範囲は指定できない。
６. 「keep limit」キーワードは、確立された状態＞＝で同時接続数を指定する。したがって、IPアドレスが10個の接続を許容する場合には、11番目の接続は阻止されることになる。ルールが「return-rst」キーワードを有する場合には、TCP RSTパケットが送信元IPアドレス／TCPポートに返送される。
７. ＜limit type＞キーワードは、維持されている制限のタイプを指定する。これについては次項でより詳細に説明する。明示的に指定される唯一の制限タイプは「cumulative（累積）」である。
【００１４】
図２は、図１のシステムの動作中に行われる例示的なステップを示すフローチャートである。まず、図２に示すようにステップ201において、システム管理者又は他のユーザが、各クライアント及びクライアント群、又はサブネット毎に「keep limit」ルールをルールテーブル105に入力することにより、特定のクライアント又はクライアント群に対して同時に許容可能な接続数を構成する。これらルール（以下に詳述する）は、許可する送信元アドレス範囲、宛先アドレス範囲、宛先ポート範囲、及び同時接続数を指定することができる。接続限度は、ルールに適合する１つの明示的な送信元についての単一のカウントに設定することもでき、又はルールに適合する全てのクライアントについての累積カウントに設定することもできる。
【００１５】
本システム100は、以下の各フィールドを含むルールテーブル105に格納されたルール構造を使用する。
(1) fn_limit
これは、例えば特定のサブネット121に累積接続限度が設定されている場合に、IP(アドレス)についての現在の限度を含む。
(2) fn_threshold
これは、何れの送信元IPにも許可される同時確立接続の最大数を指定する。limit typeがcumulativeである場合には、これの代わりにfn_limitがチェックされる。
(3) fn_lock
これは、limit typeがcumulativeである場合に「fn_limit」に保持されている現在の限度カウントが変更されないよう保護するために使用される。
(4) fn_limit_excd
これは、限度を超えることになった回数を追跡する。これは、現在の限度が設定された限度を超える度に、fn_checklimit()によってインクリメントされる。
【００１６】
ステップ205において、受信TCP/IPパケットが受信され、処理されて、送信元アドレス、宛先アドレス、及び宛先ポートが決定される。ステップ210において、制限テーブルエントリハッシュテーブル(制限テーブル)103（瞬時にチェック可能なもの）が調べられて、新しい接続を許可すべきか否かが判定される。
【００１７】
例示的な一実施形態では、ＤＣＡファイアウォール100は、４つの方法でIP接続を制限する。
１. IP毎：この場合、送信元IPは、完全に決定された（fully resolved）IPアドレスであり、設定された限度は、接続ターゲットの各々毎にカウントされ、クライアントは、宛先IPアドレス及び／又は宛先TCPポートによって区別される。
２. サブネット：この場合、送信元は、CIDR（Classless Inter-Domain Routing）フォーマットのIPサブネット121（例えば15.10.130.0／24）である。この場合、設定された限度は、15.10.130.0／24サブネット中の完全に決定されたIPの各々に対してカウントされる。
３. 累積：この場合もまた、送信元及び／又は宛先はIPサブネット121として指定される。しかし、そのサブネット中のIPは全て、設定された限度を共有することになる。このため、設定された限度が10であり、15.10.130.76から５つの接続が確立され、15.10.130.136から更に５つの接続が確立されている場合、15.10.130.0／24サブネットからのそれ以上の接続は許可されない。
４. デフォルト：何れのルールにも適合せず、上記制限タイプの何れにも分類されない送信元IPは全て、デフォルト制限タイプを有することになる。したがって、設定された限度が10である場合、このカテゴリに入るIPはそれぞれ、最大で10個の接続の確立が許可されることになる。また、これによりＤＣＡは未知のIPアドレスを構成可能な接続限度に制限できるようになる。
【００１８】
例示的な一実施形態では、制限テーブル103のエントリは、送信元IPアドレス、宛先IPアドレス、及び宛先TCPポート番号によってハッシュ処理される。このハッシュ構造により、IPアドレス及び宛先TCPポートを、特定のIPアドレス、サブネット、任意のIPアドレス又はサブネット（すなわちワイルドカードマッチ）、又は特定のポート番号又は任意のポート番号とすることが可能となる。このハッシュ機構は、送信元IPアドレス及び宛先IPアドレス又は宛先ポート番号に関するルール中のワイルドカード又はサブネットIP値が不正な一致を生じさせないことを確実にする。制限テーブルのエントリは、その送信元IPアドレス、宛先IPアドレス、及び宛先UL(上位レベル)ポートによって識別され、このため、正しい制限テーブルのエントリは常に、より広範囲にわたるワイルドカードルールにも一致する特定のIP/TCPパラメータについて特定の限度を指定するルールを用いた場合であっても見い出されることになる。上記ハッシュ方式を使用すれば、任意の特定のIPsrc／dst(送信元／宛先)ULポートの組み合わせについての制限テーブルのエントリは、ハッシュリストをウォークしながら見つけられる。特定の一致するエントリが見つからない場合のみ、ルールテーブルを調べて正しい限度値を決定した後、新しい制限テーブルエントリが作成される。したがって、特定のエントリは常に、ワイルドカードを使用して新しいエントリを作成する前に見い出されることになる。
【００１９】
例示的な一実施形態では、限度(ハッシュ)テーブル103は以下に示す構造を有する。
typedef struct fn_limit_hash{
lock_t lock; /*このハッシュバケツチェーンのロック*/
fn_limit_t *pnext; /*次のハッシュバケツ要素へのポインタ*/
int init; /*ロックが初期化された際に設定されるブール*/
}fn_limit_hash_t;
制限テーブル103中のエントリの例示的なデータ構造を以下に示す。
typedef struct fn_limit{
struct fn_limit *pnext; /*バケツ中の次のハッシュエントリへのポインタ*/
struct in_addr src;
struct in_addr dst;
int sport; /*これは最初の接続のみを反映する*/
int dport;
int limit_thresh; /*このIPの限度*/
int limit_cur; /*このIPの現在の限度*/
int limit_type; /*個別・累積・サブネット*/
struct fentry_t*fin_fr; /*このエントリのルールへのポインタ*/
}fn_limit_t;
制限テーブルエントリを作成した「ルール」は制限テーブルエントリのデータ構造にも組み込まれることに留意されたい。個別、サブネット、又はデフォルトルールが最初に処理される度に制限テーブルエントリが作成される。「累積サブネット」ルールに適合するパケットは、制限テーブルエントリを有さず、その代わりに、許可される最大接続数及び現在の接続カウントがルール自体に保持される、ということに留意されたい。これは、累積ルールに適合する全てのパケットが、同じ現在の接続カウント及び最大接続カウントを共有することができるようにするためである。
【００２０】
設定されたルールに適合するTCP/IPパケットが処理されるとき、ステップ215で、このクライアントについての制限テーブルエントリがまだ存在しない場合に、制限テーブルエントリが作成される。パケットがルールテーブル105中の何れのルールにも適合しない場合には、ステップ212でデフォルトルールが適用され、次いでステップ215で制限テーブルエントリが作成される。
【００２１】
このクライアントが同じ宛先サーバ及びサーバTCPサービス（SMTP(電子メール)、HTTP(ウェブサーバ)、telnet、及びrlogin(リモート接続)）へのTCP/IP接続を試みる場合、又は他のあらゆるサーバサービスが宛先TCPポートによって識別される場合には必ず、接続が、ステップ220で適当なルールに対してチェックされ、対応する制限テーブルエントリ中の現在の接続カウントに応じて許可され(ステップ225)又は阻止される(ステップ230)。接続が許可される場合には、現在の接続カウントがインクリメントされる。制限テーブルエントリで指定される接続限度は、対応するルール中の限度カウントを更新することにより動的に更新することができる。ルール中で指定されたアクションに応じて、到来する接続要求を阻止し又はTCPリセットを返送することが可能である。
【００２２】
ＤＣＡルールから構築された接続を処理する際に、ステップ215で作成された状態テーブル102中のエントリを使用して、クライアント120とサーバ108との間で交換されるTCPパケットによって生成されるTCP状態遷移を追跡して、接続の確立及び終了を決定する。制限テーブル103中のエントリは、特定の送信元IPアドレス、宛先IPアドレス、及び宛先ポートについての現在の接続数、並びにＤＣＡルールが許可する接続数を追跡するために作成される。特別なタイプのＤＣＡルールは、１グループのIPアドレスについて「累積限度」を確立し、ルール自体内に現在の限度を保持し、すなわち、累積接続の場合には「制限テーブル」エントリは存在しない。
【００２３】
本システム100による処理では、接続限度を追跡する目的で追跡する必要があるのは、接続のセットアップ及び解除（teardown）のみである。状態テーブル102がこの機能を提供する。
【００２４】
図３は、ＤＣＡファイアウォールシステム100の基本構造を示している。図３に示すように、ＤＣＡファイアウォール100は、各システムインタフェースカード112上にある１つ又は２つ以上の「pfil」モジュール302、及び「ipf」擬似ドライバ305を含む。各pfilモジュールは、ルール処理及び接続限度チェックのためにIPパケットをipf擬似ドライバ305に送る。各pfilモジュール302は、各システムインタフェースカード112上のIPモジュール301とDPLIデバイス303の間でプッシュされる。pfil302中のルーチンは、ipf擬似ドライバ305中のfn_limit_check()を呼び出し、本書で解説するように、設定されたフィルタリングルールに従って各IPパケットを処理する。例示的な一実施形態では、本システム100は到来するTCP/IPパケットのみを処理するが、代替的な実施形態では、他のパケットタイプを処理することも可能である。
【００２５】
ipf擬似ドライバ305は、擬似デバイス306〜308を使用し、モジュール316〜318によって処理されるコマンドを介して管理者にルール及び他の機能を設定させる。モジュール316及び擬似デバイス／dev／ipl306によって処理されるipfコマンドは管理機能に使用される。モジュール317及び擬似デバイスdev／ipl306及びdev／ipstate307によって処理されるipstatコマンドは、ファイアウォールフィルタ統計を含む監視情報を収集するために使用される。モジュール318及び擬似デバイスdev／ipl306及びdev／iplimit308によって処理されるipmonコマンドは、ipfカーネルモジュールからログ記録を得るために使用される。擬似デバイス306〜308はカーネル空間300内に存在し、ドライブモジュール316〜318は上述のようにユーザ空間310内に存在する。
【００２６】
図４は、図１及び図３のシステムの動作中に行われる例示的なステップを更に示すフローチャートである。pfilモジュール302からipf擬似ドライバ305に入ったIPパケットはまず、Hewlett-PackardのIP Filter製品等の既存のファイアウォールによって通常提供されるものと同様の機能を実行するルーチンfn_limit_check()109によって処理される。かかる典型的なファイアウォール機能をステップ405,415,420,425,430,440に示す。図４に示すように、ステップ405で、fn_limit_check()はまず、ライン122(図１)上で受信するパケットのサマリを構築する。このパケットサマリは、IP／TCPパケットの関連要素を含み、パケットが適合するルール、及び制限テーブルデータ構造を再検証する必要があるか否かを示すUID(一意の識別子)等、パケットの処理に関連する情報も格納している。
【００２７】
ステップ407で、受信したパケットがチェックされて該パケットがSYNパケットであるか否かが判定される。１つの「keep limit」ルールがイネーブルになっている（すなわち、ＤＣＡファイアウォール100がシステム管理者により「ディセーブル」にされていない）場合には、（1) パケットがインバウンドであり、(2) パケットがSYNのみのパケットであり(すなわちSYN／ACKではなく)、及び(3) 上位レイヤプロトコル(ULP)がTCPであるならば、ステップ410で、接続限度チェックサブルーチン107（fn_checklimit()）に対する呼び出しが行われて、このIPアドレス／TCP宛先ポートの３つ一組について制限テーブルエントリが既に存在するか否かが調べられる。fn_checklimit()に対する初期呼び出しは、関数引数「1」すなわちfn_checklimit(1)により示される。限度チェックサブルーチン107の初期呼び出し中に行われる動作の詳細を図５に関して以下で説明する。
【００２８】
基本的には、サブルーチン107の初期呼び出しの目的は、線形探索がルールテーブルハッシュリストの探索に使用されるため、可能な場合には必ずルールテーブルの処理を回避することにある。特定のIPアドレス／宛先ULPポートの３つ一組について制限テーブルエントリが既に存在する場合には、制限テーブル103中のそのエントリの現在の限度カウントに基づいて新しい接続を許容すべきか拒絶すべきかについての判定を直ちに行うことができる。更に、エントリの限度カウントが許す場合には、新しい接続状態エントリを直ちに追加することができる。
【００２９】
fn_checklimit(1)の呼び出しにあたり、制限テーブル103中に制限テーブルエントリが存在する場合には、ルールに指定された接続限度を超えることなく新しい接続の追加が許されるか否かがチェックされる。新しい接続が許されない場合には、接続は拒絶又は阻止される。代替的に、「reset」コマンドをクライアントに返送することが可能である（ルールにそのような指定がある場合）。パケットについて現在の制限テーブルエントリが存在しない場合には、引数「continue」が返され、fn_limit_check()はパケットの処理を続けることになる。
【００３０】
ステップ415で、ULPポート／IPアドレス／プロトコルに関する５つ一組のエントリが状態テーブル102内に既に存在する場合には、ステップ417で、それに従って状態テーブルが更新され、接続が終了しているか否かがチェックされる。非SYNパケットは、TCP接続における遷移を記録する状態テーブルにおいて処理される。クライアント又はサーバが接続を閉じるためにFINパケット又はRSTパケットを送ったことが検出された場合、接続はCLOSE_WAIT状態に遷移し、fn_dellimit()（後述する）が呼び出され、制限テーブルエントリの接続カウントがデクリメントされ、接続カウントがゼロの場合にはその制限テーブルエントリが削除される。状態テーブルエントリは、それに関連する制限テーブルエントリへのポインタを有しており、このため、ハッシュリストを再びトラバースする必要がないことに留意されたい。このパケットについての状態テーブルエントリが現在存在しない場合には、ステップ420で、サブルーチン［fn_scanlist()］に対する呼び出しが行われて、パケットがルールテーブル105中のルールに適合するか否かが調べられる。本システム100では、管理者は、テーブル中の最後のルール（いわゆる「デフォルトルール」）が、「from any(あらゆる送信元)」から「to any(あらゆる宛先)」へのワイルドカード・ルールを指定するようにルールテーブルを設定しなければならない。該ワイルドカード・ルールは、ルールテーブル中の他の何れのルールにも適合しない到来する接続要求についてデフォルト限度カウントを指定するものである。ステップ422で、該デフォルトルールが適用される場合に、本パケットについてのエントリが制限テーブル103内に作成される。
【００３１】
ステップ420で、本パケットに適合するルールがルールテーブル105中に存在する場合には、ステップ430で、fn_checklimit(2)に対する呼び出しを介してチェックを行って、以下の図６に関連して詳細に述べるようにパケット接続が許可されているか否かが判定される。上記処理に応じて、パケットを破棄し又はリセットすることが可能であり(ステップ440)、又はpfilモジュール302を介して適当なIPモジュール301へ送って、宛先サーバ108に転送することを許可する(ステップ425)ことが可能である。
【００３２】
ステップ435で、パケットが許可されない場合には、チェックが行われて、パケットをログに記録すべきか否かが判定される。パケットのログ記録について図８に関連して以下で説明する。
【００３３】
上述のように、図４中のステップ405,415,420,425,430,440は、典型的には既存のファイアウォールによって提供される。本システム100は、ステップ410でfn_checklimit(1)に対する呼び出しを挿入し、fn_checklimit(2)に対する呼び出しを包含して、以下に述べるように「keep limit」処理を行うことによって、上記ステップ430を変更する。
【００３４】
図５は、図４におけるステップ410から呼び出されるfn_checklimit(1)のコードにおいて行われる例示的なステップを示すフローチャートである。ステップ410におけるこのfn_limit_check()からfn_checklimit(1)に対する呼び出しは最適化である。これにより、新しい接続指示(インバウンドTCP SYNパケット)に遭遇した際に所与の送信元IP／宛先／IP／宛先ポートについて制限テーブルエントリが存在するか否かをチェックすることにより、図４のステップ420における高価な線形ルール探索をバイパスすることが可能となる。
【００３５】
図５に示すように、ステップ510で、チェックが行われて、制限テーブル103中に本パケットの現在のエントリが存在するか否かが判定される。かかるエントリが見つからない場合には、接続限度処理は、図４のステップ415におけるfn_limit_check()に戻って続けられる。適合するエントリが見つかった場合には、ステップ515で、本パケットの現在の接続限度カウンタ(上記「struct fn_limit」中の「limit_cur」)がチェックされ、パケット接続が許可された場合に本パケットの接続限度(「struct fn_limit」中の「limit_thresh」)を超えることになるか否かが調べられる。パケットを許可することにより限度を超えることになる場合には、パケット接続要求は、システム管理者により設定された所定の構成に従って阻止され又はリセットされる。
【００３６】
パケット接続限度を超えないと判定された場合には、ステップ520で、本パケット接続の限度カウンタがインクリメントされる。ステップ525で、このパケットについて新しいエントリを状態テーブル102に作成することが試行される。ステップ530で新しい状態テーブルエントリの作成が成功したと判定された場合、ステップ545で接続要求が許可される。しかし、新しい状態テーブルエントリを作成する試みが成功しなかった場合には、ステップ535で、本パケットの限度カウンタがデクリメントされ、ステップ540で、接続要求が阻止される。
【００３７】
例示的な代替的な一実施形態では、fn_checklimit()コードは、１回目及び２回目の呼び出し［fn_checklimit(1)及びfn_checklimit(2)］の両方で以下のステップを実行する。
【００３８】
パケットの送信元IP、宛先IP、及び宛先TCPポートから制限テーブルハッシュバケツのハッシュインデックスを決定
ハッシュテーブルバケツロックが初期化されていない場合
ipf_rw lockを取得
制限テーブルハッシュバケツロックのロックを初期化する場合
ipf_rw lockを解除
ハッシュバケツロックを取得
ハッシュバケツエントリをウォークして、送信元IPアドレス、宛先IPアドレス、又は宛先ULPポートの一致を探す
(fn_checklimitに対する２回目の呼び出しでは、ハッシュテーブルヘッド構造中のUIDがパケットサマリ内に保存されているUIDと一致する場合に、ハッシュテーブルのウォークが回避されることに留意されたい。UIDが一致する場合には、他のスレッドで、作成すべきハッシュリスト中に同じ制限テーブルエントリを入力しているものはなく、加えて、新しい制限テーブルエントリを添付すべきハッシュリスト中の位置がこれにより既知となる。UIDが一致しない場合にはハッシュリストを再度ウォークしなければならない。)
一致する場合、制限テーブルエントリレコードからルールポインタを読み出す
ルールが非推奨とされているか否かをチェック  /*ルールがrefカウントを有するためこれは削除されない*/
イエスの場合、fn_continueを返し、fn_limit_check()処理を継続
一致する場合、制限テーブルエントリの現在の接続カウントにより新しい接続が許可されるか否かを判定
ノー：
接続のログ記録、リセット、阻止についてルールをチェックし、fn_blockを返す
イエス：
この制限テーブルエントリの限度カウントをインクリメント
ルールをパケットサマリに付加  /*状態追加に必要*/
fn_checkstate()を呼び出し、パケットが現在接続の一部であるか否かを調べる
イエスの場合(状態エントリが存在する)、fn_continueを返す
その他の場合、fn_addstate()を呼び出して新しい状態エントリを付加
fn_addstate()が失敗する場合
限度カウントをデクリメント
fn_addstate()が成功する場合、接続のログ記録、リセット、阻止についてのルールをチェックし、fn_blockを返す
リターンパス
パケットに整合する制限テーブルエントリが存在しない場合
これがfn_limit_check()から呼び出され始めている(1回目の呼び出し)場合、fn_limit_check()がパケットの処理を続けるようにfn_continueを返す
その他の場合、呼び出しが、ルールが処理された後でのfn_limit_check()からのものであった場合、fn_addlimit()を呼び出して新しい制限テーブルエントリを作成し、これをハッシュリストに添付-新しい制限テーブルエントリを常に追加することができる空きメモリが存在する場合。fn_addstate()呼び出しが失敗する場合、新たに作成された制限テーブルエントリはデクリメント又は削除される
この時点で、fn_addlimit()内の状態チェック（後述する）が実行される。まず、制限テーブルエントリが作成され、制限テーブルハッシュロックが解除される。addstate()呼び出しが失敗する場合、新しい制限テーブルエントリが除去される。これはfn_checklimit()への２番目の呼び出し［fn_checklimit(2)］においてのみ当てはまることに留意する。１回目の呼び出しにおいてなど、制限テーブルエントリが既に存在する場合、制限テーブルエントリ接続カウントがインクリメントされ（その制限テーブルエントリが削除されないことを保証する）、ロックが解除され、それからfn_addstate()が呼び出される。fn_addstate()が失敗する場合、制限テーブルハッシュロックが再度取得され、制限テーブルエントリの接続カウントがデクリメントされる。
【００３９】
「非推奨ルール」とはユーザインタフェースを介して管理者により無効化されたルールであることに留意されたい。ここで非推奨となったルールを使用して構築された最終的な接続が終了すると、そのルール構造は、制限テーブルエントリ構造がデアロケートされたときにデアロケートされる。この時点で、ルールの参照カウント（削除されたルールの追跡に使用される）は１のみ：制限テーブルエントリからの参照のみである。限度エントリはここでは、非推奨ルールに代えて新しいルールを使用することになる。
【００４０】
図６は、図４のステップ430から呼び出されるfn_checklimit(2)コードにおいて行われる例示的なステップを示すフローチャートである。図６に示すように、ステップ610で、チェックが行われ、パケットの現在エントリが制限テーブル103に存在するか否かが判定される。このようなエントリが見つからない場合、ステップ612で、このパケットについて新しいエントリが制限テーブル103に作成される。
【００４１】
パケットに関して一致するエントリが見つかった場合、ステップ615で、本パケットの現在の接続限度カウンタ(上述の「struct fn_limit」中の「limit_cur」)がチェックされ、パケット接続が許可された場合に本パケットの接続限度(「struct fn_limit」中の「limit_thresh」)を超えることになるか否かが調べられる。パケットを許可することによって限度を超えることになる場合、パケット接続要求は、所定の構成に従って阻止又はリセットされる。
【００４２】
パケット接続限度を超えないと判定された場合、ステップ620で、本パケット接続の限度カウンタがインクリメントされる。ステップ625で、このパケットに新しいエントリを状態テーブル102に作成することが試行される。ステップ630において新しい状態テーブルエントリの作成が成功したと判定された場合、ステップ645において接続要求が許可される。しかし、新しい状態テーブルエントリを作成する試みが成功しなかった場合、ステップ635で、本パケットの限度カウンタがデクリメントされ、ステップ650で、接続要求が阻止される。
【００４３】
fn_checklimit()への２番目の呼び出し［すなわち、fn_checklimit(2)］では、fn_scanlist()が呼び出されており、このパケットが適合する「keep limit」ルールが見つけられている。並列スレッドによってエントリが作成されている可能性があるため、この場合もチェックを行ってこの接続の制限テーブルエントリが存在するか否かを判定しなければならないことに留意されたい。例示的な一実施形態では、fn_checklimit(2)コードは以下のステップを実行する。
【００４４】
パケットが整合するルールが累積ルールであるか否かをチェック
イエスの場合、ルールのロックを取得
ルール中の現在の接続カウント及び最大許可接続カウントをチェック
現在接続限度がしきい値未満の場合
カウントをインクリメント
ロックを解除
fn_addstate()を呼び出して新しい接続を状態テーブルに付加
リターンパス
fn_addstate()が失敗する場合
ルールロックを取得
カウントをデクリメント
ルールロックを解除
ログの記録、リセット、ブロックリターンについてルールをチェック
限度カウントを超えることになる場合
ログの記録、リセット、ブロックリターンについてルールをチェック
ルールが累積でない場合、fn_addlimit()を呼び出す
制限タイプが累積である場合のストラテジーは、ルールロックを保持しながらルールの限度カウントをインクリメントするというものになる。次に、ロックが解除されて、新しい接続を状態テーブル102に付加することが試行される。別のインスタンシエーションが続いてルールにアクセスする場合、ルールの限度カウントは、新しい接続を考慮に入れることになる。しかし、fn_addstate()が失敗する場合には、ルールロックが再度取得され、ルールの限度カウントがデクリメントされ、全てを正しく戻し、次いで接続が阻止される。これにより、fn_addstate()呼び出しを通してルールロックを保持する必要がなくなる。
【００４５】
上述したように、ステップ610で、本パケットの現在エントリが制限テーブル103に存在しない場合には、fn_checklimit()はfn_addlimit()を呼び出して新しい制限テーブルエントリを作成する。fn_addlimit()の呼び出し引数は、
*fin--パケットサマリ
*pentry--制限テーブルハッシュバケツエントリへのポインタ
*last_pentry--ハッシュバケツリレー中の最後のエントリへのポインタ
である。
【００４６】
例示的な代替の一実施形態におけるfn_addlimit()の例示的な擬似コードを以下に示す。
【００４７】
新しい制限テーブルエントリを割り振る(最終コードにおいて限度エントリがアロケートされる／予めアロケートされていたエリアから削除されることに留意されたい)
メモリがない場合、１を返し、他の場合、新しいメモリをゼロアウト
last_pentry==0の場合、これはハッシュリレー中の最初のエントリであるため、これをpentry->pnextに添付、その他の場合、last_pentry->pnext
送信元IP、宛先IPアドレス、TCPポート、最大限度、及びルールからのエントリタイプを含む新しい制限テーブルエントリに記入
ルールロック取得
ルールの参照カウントを更新し、ルールへのポインタをエントリ限度に付加
ルールロック解除
制限テーブルハッシュロック解除
fn_addstate()呼び出し
fn_addstate()がエラーを返す場合、
fn_remove_limit()を呼び出して新しい制限テーブルエントリをデクリメント又は削除
ロック解除後に有効なポインタが得られない場合があるため、fn_remove_limit()は、ハッシュテーブルをウォークして正しい制限テーブルエントリを見つけるfn_delimit()の派生ルーチンであることに留意されたい。
【００４８】
制御の流れ
図７は、ＤＣＡファイアウォールシステム100における制御の流れを示す例示的なステップを有するフローチャートである。図７に示すように、ステップ705で、受信SYNパケットをクライアント120から受け取る。ステップ710で、制限テーブル103中のエントリが作成され又はインクリメントされ、ステップ715で、状態テーブル102中のエントリが本接続パケットについて作成される。次に、接続完了タイマがステップ720において開始される。タイマが満了すると、ステップ755で、制限テーブルエントリがデクリメント又は削除される。
【００４９】
クライアント120から最終的に接続ACKを受け取ると、ステップ725で、接続が完全に形成されたとマークされる。ステップ730で、受信したFINパケット又はRSTパケットを受け取り、ステップ750において接続がCLOSE_WAIT状態に進み、ステップ755で、制限テーブルエントリがデクリメント又は削除される。ステップ760で、「時間待ち」タイマが開始され、このタイマが満了すると、ステップ745で、本パケットの状態テーブルエントリが削除される。
【００５０】
制限テーブルエントリ接続カウントは、先に確立した接続がクライアント又はサーバから接続が切断されていることを表すFINパケット又はRST TCPパケットを受け取ってCLOSE_WAIT状態に進む場合、fn_dellimit()がfn_tcpstate()又はfn_tcp_age()から呼び出されるときにデクリメントされる。代替的に、接続が管理者によってタイムアウト又はフラッシュされたために状態が削除された場合、fn_delimit()をfromfn_delstate()から呼び出すことができる。fn_dellimitの引数は、
状態テーブルエントリへのポインタ
制限テーブルエントリへのポインタ
である。
【００５１】
fn_dellimit()の例示的な擬似コードを以下に示す。
【００５２】
制限タイプが「累積」の場合、ルールの現在の接続カウントをデクリメントし戻る、他の場合、
状態テーブルエントリに格納されている送信元／宛先IPアドレス、及び宛先ポートを使用して、制限テーブルエントリハッシュテーブルへのハッシュを見つける
ハッシュテーブルバケツエントリをロックし、バケツの限度エントリへのアクセスを制御
制限テーブルエントリ引数ポインタを使用して制限テーブルエントリにアクセス
制限テーブルエントリ中の現在の接続カウントをデクリメント
制限テーブルエントリの現在カウントがここでゼロになる場合、
ルールの参照カウント＞0であるか否かをチェック
ルールロックを取得
ルールの参照カウントをデクリメント
これにより参照カウントが０になる場合
ルールロックを解除
ルールを削除
制限テーブルエントリを削除
制限テーブルハッシュエントリロックを解除
ロック解除後に有効なポインタがない場合があるため、fn_remove_limit()は、ハッシュテーブルをウォークして正しい制限テーブルエントリを見つけるfn_delimit()の派生ルーチンであることに留意されたい。
【００５３】
サマリログ記録
本ログ記録方法は、サマリログ記録の使用をベースとする。ログ記録がイネーブルされているとき、構成された接続限度を超えることになる全てのパケットがＤＣＡファイアウォールシステム100によってログに記録される。典型的にはこれらはSYNパケットである。制限テーブル103中の各エントリの寿命にわたり、試行された接続により現在の限度を超えることになる場合、図４のステップ435で、クライアント120による各接続試行が記録される。フィールド「fn_threshold」及び「fn_limit_excd」がルールテーブル105に格納される。fn_thresholdフィールドは、任意の送信元IP／宛先IP、宛先ポートエントリに許可されている現在確立接続の最大数を指定する。制限タイプが累積の場合、fn_limitがこれと照らし合わせられてチェックされる。fn_limit_excdフィールドは、特定のクライアントエントリが限度を超えた回数を格納する。このフィールドは、現在限度が構成された限度を超える都度、fn_checklimit()によってインクリメントされる。
【００５４】
図８は、本システムのサマリログ記録態様において行われる例示的なステップを示すフローチャートである。サマリログ記録動作は、図４と併せて図８を見ることによって最もよく理解される。図８に示すように、ステップ805で、システム管理者等のユーザがまず、現在述べているサマリログ記録機能の動作を制御するパラメータを使用してＤＣＡファイアウォールシステム100を構成する。これらパラメータは、サマリログ記録プロセスをイネーブル又はアクティブにするか否かを示す情報、及び各keep limitルールにおける頻度カウントを含む他の情報を含む。この頻度カウントは、「アラームログ記録レコード」を生成する頻度を決定するためにＤＣＡ限度ログ記録機能によって使用される。アラームログ記録レコードは、正常システムログファイル104に格納される。この場合、正常ログファイル104はこれら「異常な」イベントの記録に使用されるため、アラームログ記録レコードは、特定のクライアント又はシステムが構成された限度を超えて複数の接続を繰り返し確立しようと試みている場合、管理者に通知する。
【００５５】
サマリログ記録がイネーブルされる(ステップ807において)と、制限テーブルエントリに関連するアクティブ接続がそれ以上ない(図４のステップ417)ために制限テーブルエントリがデアロケートされるときに、ステップ810で、サマリログ記録レコードが生成される。サマリログ記録レコードは、クライアント(又はサブネット)IPを示すもの、限度を超えて行われた最初の接続試行がいつかであったかを示すもの、及び限度を超えての接続試行の総数を含む情報を包含する。これらサマリログ記録レコードがサマリログ記録ファイル104Sに書かれ、システム管理者によって開始され又は所定間隔で自動的に生成されるレポートプログラムによって相関付けることができる。ステップ815で、クライアントが現在接続限度を超える接続を初めて試みたとき、また限度を超えての接続試行のあらゆる「頻度数」毎に、「アラームログ記録レコード」が生成される。ユーザ要求に応答して、本システム100はアクティブな制限テーブルエントリを全て訪れ、ステップ820で、アクティブな制限テーブルエントリからサマリログ記録レポートを生成して、システム管理者に現在のシステムアクティビティについて正確に通知する。
【００５６】
「ログ限度」がルールに設定された典型的なログ記録は、(1)データスタンプ及び時刻、(2)インタフェースパケットを搬送したローカルネット、(3)ローカルエンドポイント、(4)リモートエンドポイント、(5)プロトコル、(6)TCPフラグ、(7)接続限度、(8)パケットの方向、(9)ルール番号／グループルール番号、(10)フィルタ決定、及び(11)設定された限度、現在の限度カウント、及び限度超過カウントを含む情報を記録することができる。
【００５７】
図２及び図４〜図８に関連して述べた動作を実行する命令は、コンピュータにより読み出しを行うことが可能な記憶媒体に格納することができる。これら命令は、図１のプロセッサ112等のプロセッサによって媒体から検索して実行されて、プロセッサに本システムに従って動作するように指示することができる。命令はファームウェアに格納することが可能である。記憶媒体の例としては、メモリ装置、テープ、ディスク、集積回路、及びサーバが挙げられる。
【００５８】
本発明の範囲から逸脱することなく、特定の変更を上記方法及びシステムに行うことができる。上記説明に含まれる、又は添付図面に示されることは全て、限定の意味ではなく例示として解釈すべきであることに留意されたい。例えば、図１及び図３に示すアイテムは他の構成での構築、接続、配置、及び／又は組み合わせが可能であり、図２及び図４〜図８に示すステップのセットは、本発明の精神から逸脱することなく図示の順序と異なる順序で実行することが可能である。
【図面の簡単な説明】
【００５９】
【図１】クライアントからサーバへの同時接続を制限する例示的なシステムの一実施形態のブロック図である。
【図２】図１のシステムの動作中に行われる例示的なステップを示すフローチャートである。
【図３】ＤＣＡファイアウォールシステム100の例示的な基本構造を示す。
【図４】図１及び図３のシステムの動作中に行われる例示的なステップを更に示すフローチャートである。
【図５】図４のステップ410において行われる例示的なステップを示すフローチャートである。
【図６】図４のステップ430において行われる例示的なステップを示すフローチャートである。
【図７】ファイアウォール100における制御の流れを示す例示的なステップを有するフローチャートである。
【図８】本システムのサマリログ記録態様において行われる例示的なステップを示すフローチャートである。
【符号の説明】
【００６０】
100        ファイアウォールシステム
101        フィルタ
102〜105   テーブル
105        ルールテーブル
106        接続
108        SMTPサーバ
110        宛先TCPポート
111        ゲートウェイ及び／又はルータ
112        システムインタフェースカード
120        電子メールクライアント
121        ネットワーク
123        スイッチ
【図１】
2004364306.tif 000003
【図２】
2004364306.tif 000004
【図３】
2004364306.tif 000005
【図４】
2004364306.tif 000006
【図５】
2004364306.tif 000007
【図６】
2004364306.tif 000008
【図７】
2004364306.tif 000009
【図８】
2004364306.tif 000010