この文書では、ファイアウォール機能について、 特に、動的なフィルタリングと侵入検出の機能について、仕様と使い方を説明します。 一般に、ファイアウォールの機能にはVPNやNATが含まれることが多いようですが、 これらの機能については、既存の別の文書で扱うものとします。
従来のフィルタは、定められた設定にしたがって、 いつも同じ動作をするという意味で「静的」だといえます。 静的なフィルタでは、通信を制御するためのドアは、常に開いているか、 常に閉じています。基本的には、ドアの開閉は設定によって決まり、 途中で開いたり閉じたりするものではありません。
これに対して、動的なフィルタでは、 通信の状態に応じてドアが開閉します。 具体的には、通信が始まったらドアを開け、 通信が終了したらドアを閉じます。通信がないときにはドアは閉まり、 必要のない限りはドアが開くことはありません。
ドアを開ける権限は、特定のホストに限定されます。 例えば、内部ネットワークのホストだけがドアを開けるようにすれば、 外部ネットワークから攻撃を受ける機会を減らすことができます。 これは、ノブのない押し戸の仕組みと似ています。
動的なフィルタでは、コネクションの最初のパケットがドアを開く契機になります。 一度ドアが開くと、 そのコネクションに属する往きと戻りのパケットが両方とも通過するようになります。 静的なフィルタでは、 往きと戻りのそれぞれの方向についてフィルタを設定する必要がありますが、 動的なフィルタでは、往きの方向のフィルタだけを書けば、 戻りのパケットも自動的に通るようになります。
動的なフィルタは、静的なフィルタよりも優先して動作します。すなわち、 特定のコネクションに対応するドアが開いた後は、 そのコネクションを静的なフィルタで制御することはできません。逆にいえば、 コネクションの最初のパケットだけは、静的なフィルタで制御できます。 詳細は、2.3.3.の絵を参照してください。
以下の説明では、静的なフィルタを単に静的フィルタと呼びます。 同様に動的なフィルタを動的フィルタと呼びます。なお、動的フィルタでは、 TCPとUDPだけを扱い、ICMPやOSPFなどのプロトコルは扱いません。
単にコネクションというときには、TCPとUDPのコネクションを指します。 端末は個々のコネクションに対してポート番号を割り当てるので、コネクションは、 2つの端末のIPアドレスとポート番号によって識別されることになります(下図)。
┏━━━━━━┓ポート番号 ポート番号┏━━━━━━┓
┃ 端末A ┃60000 ←──────────────→ 23 ┃ 端末B ┃
┗━━━━━━┛ コネクション ┗━━━━━━┛
IPアドレス: 192.168.0.1 IPアドレス: 192.168.0.2
IPパケットの中には、IPアドレスとポート番号を示す部分があります。 この部分を見ると、個々のIPパケットが、 どのコネクションに属するかを知ることができます。 IPアドレスはIPヘッダの中に格納され、 ポート番号はIPヘッダの後ろのTCPヘッダやUDPヘッダの中に格納されます。
アプリケーションによっては、 複数のコネクションを使って通信を実現するものがあります。例えば、FTPは、 制御用のコネクションとデータ用のコネクションを使いわけます。 この文書では、 このような複数のコネクションをまとめてセッションと呼びます。 もちろん、SMTPやTELNETのように、 1つのコネクションしか持たないセッションも数多くあります。
FTPのセッションを観察すると、最初に制御用のコネクションが作られ、 それから、必要に応じてデータ転送用のコネクションが作られます。 一般に、複数のコネクションを持つセッションでは、 最初に制御用のコネクションを作り、 そのコネクションを使って残りのコネクションの管理をすることが多いようです。 そこで、この文書では、 最初に作られる制御用のコネクションをトリガーとよんで、特別に扱います。 1つのコネクションしか持たないセッションでは、 そのコネクション自身がトリガーになります。
(1) 最初にトリガーが作られる
┏━━━━━━┓ポート番号 ポート番号┏━━━━━━┓
┃ 端末A ┃60000 ←──── トリガー ─────→ 21 ┃ 端末B ┃
┗━━━━━━┛ ┗━━━━━━┛
(2) 必要に応じてコネクションが作られる
┏━━━━━━┓ポート番号 ポート番号┏━━━━━━┓
┃ 端末A ┃60000 ←──── トリガー ─────→ 21 ┃ 端末B ┃
┗━━━━━━┛60001 ←──────────────→ 20 ┗━━━━━━┛
60002 ←──────────────→ 20
60003 ←──────────────→ 20
それから、重要な概念として、コネクションの向きがあります。 コネクションの向きは、接続の要求の向きと同じです。 たとえば、 AがBに接続要求を送信したときには、コネクションの向きは、 AからBへ向かう方向になります。 動的フィルタでは、コネクションの向きに応じて、 異なるアクセス制限を適用することができます。
ここでは、基本的な使用方法を説明するとともに、 動的フィルタの基本的な動作を見ていきます。
まず、動的フィルタを定義します。 動的フィルタは、簡単にいうと「通すべきコネクション」の定義といえます。 もっとも簡単な定義は、通信プロトコルだけを記述したもので、 以下のようなコマンドで設定されます。
# ip filter dynamic 1 * * ftp
このコマンドはFTPのコネクションを通すための動的フィルタを定義するものです。 コマンドの「1」は動的フィルタの識別子であり、整数を自由に設定できます。 FTPが使用するデータ転送用のコネクションについても 自動的に通過しますので、特に考える必要はありません。
通信する端末を絞りたいときには、 アスタリスク「*」の代わりにIPアドレスやネットワークを指定することもできます。 例えば、FTPを始める端末が、192.168.0.0/24に限られているのならば、 以下のように書くことができます。
# ip filter dynamic 1 192.168.0.0/24 * ftp
また、FTPを接続する先のサーバが172.16.0.1に限られているのならば、 以下のように書くことができます。
# ip filter dynamic 1 * 172.16.0.1 ftp
「ftp」のところには、FTP以外のプロトコルを指定することもできます。 例えば、以下のようなものを設定することができます。 詳しくはコマンド仕様を参照してください。
実際のところ、 この方法で設定できるアプリケーションはそれほど多くありません。 たとえば、 identやSSHは、この方法では定義できません。 そこで、他のアプリケーションを通す方法を、これから説明します。
先に具体例を書きます。以下のように2行で1つの設定になります。
# ip filter 100 pass * * tcp 10000 20000 # ip filter dynamic 1 192.168.0.1 172.16.0.1 filter 100
これは、192.168.0.1の10000番ポートから172.16.0.1の20000番ポートに対する TCPのコネクションを定義するものです。
┏━━━━━━┓ポート番号 ポート番号┏━━━━━━┓
┃ 端末A ┃10000 ─────────────→ 20000 ┃ 端末B ┃
┗━━━━━━┛ ┗━━━━━━┛
IPアドレス: 192.168.0.1 IPアドレス: 172.16.0.1
ip filterコマンドをつかって、TCP/UDPの区別と、ポート番号を記述します。 また、ip filter dynamicコマンドをつかって、端末のIPアドレスを設定します。
先ほどと同じように、アスタリスク(「*」)による省略が許されます。 例えば、次の設定は、 あらゆる端末間のidentのコネクションを意味することになります。
# ip filter 100 pass * * tcp * ident # ip filter dynamic 1 * * filter 100
前節で動的フィルタを定義したので、実際に動作させる方法を説明します。 動的フィルタを動作させるためには、 ip INTERFACE secure filterコマンドで、 先に定義した動的フィルタの番号を指定します。例えば、 FTPに関する動的フィルタを「LAN1」インタフェースで動作させるためには、 以下のように設定します。
# ip filter dynamic 1 * * ftp # ip lan1 secure filter out dynamic 1
ここで、「out」という引数は、 ドアがインタフェースの外に向かって開くことを意味します。 逆に、ドアをインタフェースの内に向かって開けるときには、 「out」の代わりに「in」を指定します。
そもそも、ip INTERFACE secure filterというコマンドは、 昔から存在するもので、これまでは、 静的フィルタを適用するために使われてきました。 新しいファームウェアでは、このコマンドを使って、 静的フィルタと動的フィルタの両方を適用できるようになります。
たとえば、静的フィルタの1〜3番と、動的フィルタの6〜8番を適用するには、 次のような設定になります。静的フィルタの番号と動的フィルタの番号を 「dynamic」というキーワードで区切ることになります。
ip INTERFACE secure filter in 1 2 3 dynamic 6 7 8
なお、このコマンドで、動的フィルタだけを設定したときには、 静的フィルタは何も働かず、動的フィルタのみが動作します。つまり、 パケットがまったく破棄されない状態になりますので、ご注意ください。
動的フィルタは、原則として、パケットを破棄するのではなく、 通過させるために働きます。つまり、動的フィルタだけでは、 パケットを破棄することはできません。したがって、通常の運用では、 動的フィルタを静的フィルタと組み合わせる必要があります。
基本的には、動的フィルタは静的フィルタよりも優先的に適用されます。 したがって、 動的フィルタに該当するパケットは、静的フィルタの設定にかかわらず、 通過します。逆に、動的フィルタに該当しないパケットは、 静的フィルタの設定によって通過になるか破棄になるかが決まります。
動的フィルタは最初から存在するのではなく、 トリガーのコネクションが現れたときに動的に作られます。 したがって、トリガーの最初のパケットだけは、動的フィルタではなく、 静的フィルタが適用されます。 一度、動的フィルタが作られれば、その後に続くパケットは、 動的フィルタによって通過していきます。
(1) 初期状態 (動的フィルタはない)
┏━━━━━━━┓拒否
――――→┃ 静的フィルタ ┃―――→ 破棄
┗━━━━━━━┛
｜ 受理
└―――――――→ 通過
(2) トリガーの最初のパケットが通過する
→■→ ┏━━━━━━━┓拒否
――――→┃ 静的フィルタ ┃―――→ 破棄
┗━━━━━━━┛
｜ →■→
└―――――――→ 通過
(3) 動的フィルタが追加される
┏━━━━━━━┓拒否 ┏━━━━━━━┓拒否
―→┃ 動的フィルタ ┃―――→┃ 静的フィルタ ┃―――→ 破棄
┗━━━━━━━┛ ┗━━━━━━━┛
｜受理 ｜ 受理
｜ └―――――――→ 通過
｜
└―――――――→ 通過
(4) 引き続くパケットが通過する
→■■┏━━━━━━━┓拒否 ┏━━━━━━━┓拒否
―→┃ 動的フィルタ ┃―――→┃ 静的フィルタ ┃―――→ 破棄
┗━━━━━━━┛ ┗━━━━━━━┛
｜■ 受理 ｜ 受理
｜■ └―――――――→ 通過
｜■■■■■■■→
└―――――――→ 通過
この動作は動的フィルタのすべてのコネクションについて通用するものです。 繰り返しになりますが、トリガーのコネクションの最初のパケットは、 静的フィルタで通す必要があります。
具体例をあげて、静的フィルタと動的フィルタの組み合わせを説明します。 ここで、例として取りあげるのは、 以下のようなネットワークであり、 非常に簡単なアクセス制御を想定しています。
プロバイダ
↑
｜
｜PP1
┏━━━━━━┓
┃ ルータ ┃
┗━━━━━━┛
｜LAN1
｜
──┬───┴──┬──────┬──── 172.16.1.0/28
｜ ｜ ｜
｜ ｜ ｜
┏━━━┓ ┏━━━┓ ┏━━━━━┓
┃ホスト┃ ┃ホスト┃ ┃FTPサーバ ┃172.16.1.2
┗━━━┛ ┗━━━┛ ┗━━━━━┛
LANにFTPサーバがあり、これを公開するほかは、 外側からのアクセスは受け付けないものとします。 また、LANから外側へのアクセスとしてHTTPを通過させるものとします。
まず、静的フィルタを設定します。とりあえず、FTPサーバは忘れて、 外側からのパケットをすべて破棄します。
# ip filter 100 reject * * * * * # pp select 1 # ip pp secure filter in 100
内側からのアクセスとしてHTTPだけを通します。 先ほど説明したように、 トリガーのコネクションの最初のパケットだけは静的フィルタで通す必要があります。 そこで、次のように静的フィルタを設定します。
# ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www # pp select 1 # ip pp secure filter out 90
tcpflagの部分は、 TCPのパケットのうちSYNフラグだけが立っているパケットを表します。 このフィルタによって、コネクションの最初のパケットだけを通すことができます。
※ リビジョンによっては、tcpflagを設定できないものもあります。 その場合には、次のように2行に分けることで同様の効果を得ることができます。
# ip filter 90 reject 172.16.1.0/28 * established * www # ip filter 91 pass 172.16.1.0/28 * tcp * www # pp select 1 # ip pp secure filter out 90 91
※ UDPの場合には、SYNのようなフラグで判断することはできないので、 プロトコルの欄は単に「udp」となります。
# ip filter 92 pass 172.16.1.0/28 * udp * domain
次にHTTPを通すための動的フィルタを追加します。 ここまでの設定と合わせると、次のようになります。
# ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www # ip filter 100 reject * * * * * # ip filter dynamic 1 172.16.1.0/28 * www # pp select 1 # ip pp secure filter in 100 # ip pp secure filter out 90 dynamic 1
次に、FTPサーバを公開するためのフィルタを追加します。 まず、トリガーのコネクションの最初のパケットを通すために次の静的フィルタを 追加します。
# ip filter 80 pass * 172.16.1.0/28 tcpflag=0x0002/0x0017 * 21 # pp select 1 # ip pp secure filter in 80 100
最後に、FTPを通す動的フィルタを追加します。 全体をまとめると次のようになります。
# ip filter 80 pass * 172.16.1.0/28 tcpflag=0x0002/0x0017 * 21 # ip filter 90 pass 172.16.1.0/28 * tcpflag=0x0002/0x0017 * www # ip filter 100 reject * * * * * # ip filter dynamic 1 172.16.1.0/28 * www # ip filter dynamic 2 * 172.16.1.0/28 ftp # pp select 1 # ip pp secure filter in 80 100 dynamic 2 # ip pp secure filter out 90 dynamic 1
なお、内側のホストを信頼できる場合には、 90番のフィルタのtcpflagを単にtcpとしてもかまいません。
2.3.1.では、FTPやTELNETのような特定のアプリケーションについては1行で設定でき、 それ以外のアプリケーションについては2行に分けて設定することを説明しました。 このうち、後者の設定方法については、もう少し拡張した使い方があるので、 それを説明しておきます。
先に説明したとおり、一般に1つのセッションは複数のコネクションを持ちます。 例えば、FTPでは、制御用のコネクションが作られた後に、 データ転送用のコネクションが作られます。したがって、 このような種類のセッションを正しく扱うためには、 トリガーの設定だけでは不十分で、 トリガー以外のコネクションを表現し、定義する必要があります。
また、一般にコネクションには向きがあるので、 向きを区別して扱う必要があります。したがって、 セッションを完全に表現するためには、 次の3つの項目が必要になることがわかります。
┏━━━━━━┓ポート番号 ポート番号┏━━━━━━┓
┃ 端末A ┃60000 ───── トリガー ─────→ 21 ┃ 端末B ┃
┗━━━━━━┛60001 ───── 順方向 ──────→ 20 ┗━━━━━━┛
60002 ←──── 逆方向 ─────── 20
[注意] くりかえしになりますが、FTPについては、 データ転送用のコネクションについて、ユーザが意識する必要はありません。 ルータは、FTPが使用するポート番号を把握し、 関係するコネクションを通過させます。
なお、1つのセッションに属するすべてのコネクションは、 同じ端末の間で接続されるものと考えます。 つまり、トリガーとそれ以外のコネクションのIPアドレスが異なることはありません。
それでは、具体的な例を使って、説明を続けます。
このルールに相当する設定は次のようになります。
# ip filter 10 pass * * tcp * 6000 # ip filter 11 pass * * udp * 7000 # ip filter 12 pass * * udp * 8000 # ip filter dynamic 1 * 172.16.0.1 filter 10 in 12 out 11
「in」はトリガーと逆方向のコネクションを、 「out」はトリガーと同じ方向のコネクションを設定するための キーワードになっています。3種類のフィルタ番号には、それぞれ、 複数のフィルタ番号を列挙することもできます。
2.3.1.では、動的フィルタを設定するための2通りの方法を説明しました。 1つは直接アプリケーションの名前を指定する方法(※)で、 もう1つはip filterコマンドを使って2行で設定する方法です。 この節では、前者の場合、つまり、 アプリケーションの名前を指定するときの動作を説明します。
※ この文書を書いている時点では、FTP、TFTP、HTTP、DNS、SMTP、POP3、 TELNET、NetMeetingの8つのアプリケーションを指定できます。
これらのアプリケーションのほとんどは、複数のコネクションを扱ったり、 ポート番号が変化したり、アプリケーションに固有の処理を必要とします。 したがって、ip filter dynamicコマンドにアプリケーション名を書くことで、 このような固有な処理をすることを明示的に設定します。
※ HTTP、POP3、TELNETは、現在のところ、特別な処理はありません。 また、NetMeetingはノーマルパスでないと動作しません。
なお、ip filter dynamicコマンドで、 アプリケーション名のかわりにudpとtcpという指定をすることができます。 これは、UDPとTCPの全般的なコネクションを扱うもので、 アプリケーションに固有の動作は行いません。
FTPではデータ転送用のコネクションのポート番号が動的に決まるので、 PORTコマンドやPASVコマンドを調べ、 対応するポート番号を自動的に開閉します。 データ転送用のコネクションは動的フィルタによって通過するので、 静的フィルタでこれらのコネクションを通す必要はありません。 FTPで必要になる静的フィルタは、 制御用のコネクションの最初のパケットを通すフィルタのみです。
[設定例]
# ip filter 10 pass * 192.168.0.0/24 tcpflag=0x0002/0x0017 * 21 # ip filter 100 reject * * * * * # ip filter dynamic 1 * 192.168.0.0/24 ftp # pp select 1 # ip pp secure filter in 100 # ip pp secure filter out 10 100 dynamic 1
TFTPではサーバがエフェメラルポートを選んで返事をする場合があります。 したがって、サーバが送信する最初のパケットについては、 ポート番号の変化を検出する仕組みを持っています。また、TFTPでは、 データ転送の最後のパケットだけが短いという特性があるので、 それを見て、セッションの終了を判定します。
クライアント サーバ
セッション開始
COMMAND
4000 --------------------------> 69
ACK
4000 <-------------------------- 7000
DATA (len = 512)
4000 --------------------------> 7000
ACK
4000 <-------------------------- 7000
・
・
・
DATA (len < 512)
4000 --------------------------> 7000
ACK
4000 <-------------------------- 7000
セッション終了
DNSでは、問い合わせと応答がセットになっているため、 応答を見てセッションの終了を判定します。DNSのポート番号は53番です。
動的フィルタとは直接は関係がありませんが、SMTPに固有な攻撃を検知します。 詳細は3. 不正アクセス検知を参照してください。 SMTPのポート番号は25番です。
NetMeetingを通すために、H.323のメッセージをチェックし、 該当するコネクションを通過させます。 対応機種はRTX1500、RTX1100、RT107e、RT250i、RT57i、RTV700です。 ノーマルパスに設定してください。
[設定例]
# ip lan3 secure filter in 1000 # ip lan3 secure filter out 90 dynamic 1 # ip filter 90 pass-log * * tcpflag=0x0002/0x0017 * 1720 # ip filter 1000 reject * * * * * # ip filter dynamic 1 * * netmeeting # ip routing protocol normal
動的フィルタの状態を見るためには、show ip connectionコマンドを使用します。 まず、何もコネクションが観測されていないときには、次のように表示されます。
pp1# show ip connection PP[01][out] inspecting no sessions
次に、セッションが1つのコネクションしか持たないときには、 次のように表示されます。
pp1# show ip connection PP[01][out] ID FILTER T P INITIATOR D RESPONDER S 60001 1 T 192.168.1.2:1073 > 192.168.2.2:21 E
ID、FILTERなどのバナー部分の意味は以下のようになっています。
| ID | セッションの識別番号 |
| FILTER | 該当する動的フィルタの番号 |
| T | コネクションの種類(後述) |
| P | プロトコル(TCPかUDPか) |
| INITIATOR | セッションを開始したノードのIPアドレス |
| D | セッションの方向 |
| RESPONDER | セッションを受けたノードのIPアドレス |
| S | コネクションの状態 |
FTPのように、1つのセッションが複数のコネクションからなるときには、 次のような表示になります。 主な違いは、IDと、T(種別)の表示です。IDは、 セッションの番号とコネクションの番号が連結された形で表示されます。 また、T(種別)では、ドアを開けるきっかけとなったコネクションが「T」で、 それ以外のコネクションが「D」で表現されます。
pp1# show ip connection PP[01][out] ID FILTER T P INITIATOR D RESPONDER S 60001-1 1 T T 192.168.1.2:1073 > 192.168.2.2:21 E 60001-2 1 D T 192.168.1.2:1077 < 192.168.2.2:20 E
TCPコネクションについては、「S」の欄にコネクションの状態を表示します。 UDPコネクションについては何も表示しません。 表示する記号の意味は次のようになっています。
なお、上記の状態に含まれない過渡的な状態では、 何も記号を表示しません。
コネクションが終了したときに、 そのコネクションのサマリーがnoticeレベルのsyslogとして出力されます。
2001/01/31 18:21:00: [INSPECT] PP[01][out][1] TCP 192.168.1.2:1077 < 192.168.2.2:20 (2001/01/31 18:20:48) 2001/01/31 18:21:05: [INSPECT] PP[01][out][1] TCP 192.168.1.2:1073 > 192.168.2.2:21 (2001/01/31 18:20:14)
最後の括弧の中は、コネクションの始まった日時をあらわしています。
なお、ip filter dynamicコマンドで、syslogオプションをoffに設定すると、 このようなサマリーは表示されなくなります。
動的フィルタを使うと、 外側から始まるコネクションを動的に通過させることができるようになります。 しかし、IPマスカレードを使用しているときには、 外側から始まるコネクションを動的に通過させることができないため、 動的フィルタの意味が薄れてしまいます。
そこで、動的フィルタとIPマスカレードを併用しているときには、 静的IPマスカレードのテーブルを動的に変更し、 外側からのコネクションを通過させる仕組みを用意しています。
このときに作られるテーブルは動的なものであり、 コネクションが開始してから終了するまでの間しか存在しません。したがって、 サーバを公開するときのように、常に同じポートを開けて待つ必要があるならば、 従来と同じように、静的IPマスカレードを設定する必要があります。
例として、以下の設定を考えます。 トリガーが6000番宛てのTCPコネクションであり、トリガーが検出されたら、 トリガーと同じ方向の7000番宛てのUDPコネクションと、 トリガーと逆方向の8000番宛てのUDPコネクションを通すという設定です。
nat descriptor type 1 masquerade ip filter 10 pass * * tcp * 6000 ip filter 11 pass * * udp * 7000 ip filter 12 pass * * udp * 8000 ip filter dynamic 1 * 192.168.0.128 filter 10 in 12 out 11 ip pp nat descriptor 1 ip pp secure filter in dynamic 1
このとき、トリガーについては、常にポートを開けて待つ必要があるので、 以下のように静的IPマスカレードを設定する必要があります。
nat descriptor masquerade static 1 1 192.168.0.128 tcp 6000
UDPの7000番宛てのコネクションは、内側から外側へ接続するコネクションなので、 通常のIPマスカレードの処理によって、テーブルが自動的に追加されます。 つまり、動的フィルタに関する限り、 このコネクションに対するケアは必要ではありません。
UDPの8000番宛てのコネクションについては、常に通す必要がないので、 静的IPマスカレードを設定する必要はありません。このコネクションについては、 ユーザではなく、ルータが自動的にテーブルを変更します。
まとめると、次のようになります。
つまり、ユーザが注意すべきことは、トリガーを通すために、 静的IPマスカレードを設定するという1点です。
コネクションを手動で削除する機能が用意されています。 この機能を使うためには、disconnect ip connectionコマンドを実行します。
例えば、60000番のセッションを削除するには、以下のように入力します。
# disconnect ip connection 60000
あるセッションに属する特定のコネクションだけを削除するときには、 セッションの番号とコネクションの番号を指定します。
# disconnect ip connection 60001 1
静的フィルタでは、複数のフィルタに該当するパケットは、 最初にマッチしたフィルタにのみ該当するものとして扱いますが、 動的フィルタでも、同様に、 最初にマッチしたフィルタのみに該当するものとして扱います。
1つのインタフェースで管理できるセッションの最大数は下記のとおりです。 機種やファームウェアによって最大数は固定されており、 設定などで最大数を変更することはできません。
| 機種 | 最大数 |
|---|---|
| vRX VMware ESXi版、vRX Amazon EC2版、RTX5000、RTX3500、RTX1210、RTX830、NVR700W、NVR510 | 65,534 |
| RTX3000 | 40,000 |
| FWX120 | 32,000 |
| RTX1200 | 20,000 |
| RTX810 | 10,000 |
| 上記以外のRTXシリーズ、RT107e、RT58i、NVR500 | 2,000 |
| 上記に該当しないもの | 200 |
この機能は、 侵入(Intrusion)や攻撃(attack)を目的とするパケットを受信したときに、 それを検出してユーザに通知するものです。 もっとも、侵入に該当するか否かを正確に判定することは難しく、 完全な検知が不可能であることに注意してください。
RTシリーズの実装では、不正なパケットの持つパターン(signature)を 比較することで侵入や攻撃を検出します。 基本的には、パターンの比較はパケット単位の処理ですが、 それ以外にも、コネクションの状態に基づく検査や、 ポートスキャンのような状態を持つ攻撃の検査も実施します。
この機能は、2章で説明した動的フィルタで管理している情報を利用して動作します。 そのため、動的フィルタと併用することで、最大限の効果を発揮します。 例えば、 SMTPに対する動的フィルタが設定されていれば、その情報に基づいて、 SMTPに関する不正アクセスを検知します。逆に、 動的フィルタが設定されていなければ、SMTPに関する不正アクセスを検知しません。
一方、IPヘッダやICMPのように、動的フィルタでは扱わないパケットについては、 動的フィルタの設定の有無に関わらず動作します。 また、TCPやUDPについても、基本的には、動的フィルタを定義しなくても、 機能するようになっています。これらの詳細については、後の節で説明します。
なお、不正アクセスを検知するために動的フィルタを設定するのでは、 本末転倒になってしまいます。本来、許可しないアクセスについては、 侵入を検出する必要もないはずですから、 あくまで動的フィルタの設定が優先されるべきであり、 不正アクセスを検知するために動的フィルタを設定することは避けるべきです。
それでも、不正アクセスを検知したいときには、動的フィルタを設定して、 該当するアクセスを許可し、 不正アクセス検知の結果に基づいて拒否するという方法があります。 しかしながら、不正アクセス検知の誤検出によっては、 攻撃を通過させたり、攻撃ではないパケットを破棄するという問題があります。
不正アクセスを検知するためには、 ip INTERFACE intrusion detectionというコマンドを設定します。 例えば、LAN1インタフェースの内向きのトラヒックを検知するときには、 以下のように設定します。
ip lan1 intrusion detection in on
また、不正なパケットを破棄するかどうかを設定するために、 rejectオプションを指定することができます。 デフォルトではrejectオプションはoffになっています。rejectオプションは、 必ずしも、すべての攻撃に対して効果を持つわけではありませんので、 ご注意ください。
[設定例] ip lan1 intrusion detection in on reject=on
判定条件を以下の表にまとめます。
| ★： | 動的フィルタを設定しなければ働かないことを示します。
例えば、種別がSMTPのところに★があるときには、以下のようにSMTPを通す動的フィルタが設定されているときに検出されます。
ip filter dynamic 1 * SNMP_SERVER smtp ip lan1 secure filter in dynamic 1 ip lan1 intrusion detection in on |
| ☆： | 動的フィルタが設定されていれば、不正アクセス検知が設定されていなくても検出するものを示します。この攻撃を検出した場合には、不正アクセス検知の設定にかかわらず必ず破棄します。 |
| ▲： | 誤検出の可能性が低く、破棄したときの影響が少ないと思われるものを示します。この攻撃に関しては、rejectオプションの設定にかかわらず必ず破棄します。 |
| △： | rejectオプションの設定にかかわらず破棄しないものを示します。 |
| ○： | 既存のリビジョンでも検出されるため、特別に対応しなかったものを示します。 これらの攻撃を検出したときには必ず破棄されます。 |
| 種別 | 名称 | 判定条件 | |
|---|---|---|---|
| IPヘッダ | Unknown IP protocol | protocolフィールドが143以上のとき (※1) | |
| Land atack | 始点IPアドレスと終点IPアドレスが同じとき | ▲ | |
| Short IP header | IPヘッダの長さがlengthフィールドの長さよりも短いとき | ○ | |
| Malformed IP packet | lengthフィールドと実際のパケットの長さが違うとき | ○ | |
| IPオプションヘッダ | Malformed IP opt | オプションヘッダの構造が不正であるとき | ▲ |
| Security IP opt | Security and handling restriction headerを受信したとき | ||
| Loose routing IP opt | Loose source routing headerを受信したとき | ||
| Record route IP opt | Record route headerを受信したとき | ||
| Stream ID IP opt | Stream identifier headerを受信したとき | ||
| Strict routing IP opt | Strict source routing headerを受信したとき | ||
| Timestamp IP opt | Internet timestamp headerを受信したとき | ||
| フラグメント | Fragment storm | 大量のフラグメントを受信したとき | ☆ |
| Large fragment offset | フラグメントのoffsetフィールドが大きいとき | ☆ | |
| Too many fragment | フラグメントの分割数が多いとき | ☆ | |
| Teardrop | teardropなどのツールによる攻撃を受けたとき | ☆▲ | |
| Same fragment offset | フラグメントのoffsetフィールドの値が重複しているとき | ☆ | |
| Invalid fragment | そのほかのリアセンブル不可能なフラグメントを受信したとき | ☆▲ | |
| ICMP | ICMP source quench | source quenchを受信したとき | |
| ICMP timestamp req | timestamp requestを受信したとき | ||
| ICMP timestamp reply | timestamp replyを受信したとき | ||
| ICMP info request | information requestを受信したとき | ||
| ICMP info reply | information replyを受信したとき | ||
| ICMP mask request | address mask requestを受信したとき | ||
| ICMP mask reply | address mask replyを受信したとき | ||
| ICMP too large | 1025バイト以上のICMPを受信したとき | ||
| UDP | UDP short header | UDPのlengthフィールドの値が8よりも小さいとき | ▲ |
| UDP bomb | UDPヘッダのlengthフィールドの値が大きすぎるとき | ||
| UDP port scan | ポートスキャンを受けたとき (※2) | △ | |
| TCP | TCP queue overflow | TCPのパケットキューが長くなったとき | ★ |
| TCP no bits set | フラグに何もセットされていないとき | ||
| TCP SYN and FIN | SYNとFINが同時にセットされているとき | ||
| TCP FIN and no ACK | ACKのないFINを受信したとき | ||
| TCP port scan | ポートスキャンを受けたとき (※2) | △ | |
| TCP SYN flooding | 一定時間に大量のSYNを受けたとき (※2) | △ | |
| FTP | FTP improper port | PORTやPASVコマンドで指定されるポート番号が1024〜65535の範囲でないとき | ★ |
| SMTP | SMTP pipe attack | From:などのヘッダにパイプ「|」を含むとき | ★ |
| SMTP decode alias | ヘッダに「: decode@」を含むとき | ★ | |
| SMTP DEBUG command | DEBUGコマンドを受信したとき | ★ | |
| SMTP EXPN command | EXPNコマンドを受信したとき | ★ | |
| SMTP VRFY command | VRFYコマンドを受信したとき | ★ | |
| SMTP WIZ command | WIZコマンドを受信したとき | ★ | |
| Winny | Winny version 2 | Winny version 2のコネクションを発見したとき (※3) | ★ |
| Share | Share version 1 | Share version 1のコネクションを発見したとき (※4) | ★ |
| (※1) | RT250iのRev.8.02.52以降、RTX1100/RTX1500/RT107eのRev.8.03.92以降、RTX3000のRev.9.00.56以降、RT58iのRev.9.01.51以降、SRT100のRev.10.00.60以降、RTX1200のRev.10.01.32以降、NVR500のRev.11.00.16以降、Rev.11.01系以降の全機種の場合です。 上記以外の機種での判定条件は「protocolフィールドが101以上のとき」となります。 |
| (※2) | Rev.10以降の機種では動作しません。 |
| (※3) | Winny検出・遮断(Winnyフィルター)機能に対応している機種のみとなります。 関連文書：Winny検出・遮断機能(Winny フィルタ)について |
| (※4) | Shareフィルター機能に対応してる機種のみとなります。 関連文書：Shareフィルター機能 |
継続的に同じ攻撃が続くときには、 検知した情報を制限して履歴に残すようにします。 まず、同じターゲットに対して同じ種類の攻撃が繰り返される場合には、 60秒に1回の割合でsyslogに表示して履歴に残します。 また、攻撃の種類が異なる場合でも、同じターゲットに対する攻撃は、 1秒について1回に制限されます。
受けた攻撃の履歴を見るためには、 show ip intrusion detectionコマンドを実行します。 各インタフェースの各方向ごとに、最大50件の攻撃を表示することができます。 これを超える分については、古いものから順に削除されます。
攻撃を受けたときには、noticeレベルのsyslogに出力します。
不正アクセス検知の機能は、静的フィルタを補うように動作するものであり、 静的フィルタに置き換わるものではないことに注意してください。 いくつかの攻撃は、静的フィルタによって、効果的に防御することができます。
また、動的フィルタと静的フィルタと不正アクセス検知を組み合わせることも重要です。 例えば、SMTPサーバを公開しているときには、以下のような設定が有効です。
ip filter 11 reject * SMTP_SERVER established * smtp ip filter 12 pass * SMTP_SERVER tcp * smtp ip filter dynamic 1 * SMTP_SERVER smtp pp select 1 ip pp secure filter in 11 12 dynamic 1 ip pp intrusion detection in on reject=on
[入力形式]
ip filter dynamic ID SRCADDR DSTADDR PROTOCOL [OPTION ...]
ip filter dynamic ID SRCADDR DSTADDR filter FILTER_LIST [in FILTER_LIST] [out FILTER_LIST] [OPTION ...]
[パラメータ]
ID ... 動的フィルタ番号 (1..21474836)
PROTOCOL ... プロトコル
- tcp/udp/ftp/tftp/www/domain/smtp/pop3/telnet/netmeeting
Rev.10.01以降では以下が設定できます
- echo/discard/daytime/chargen/ftp/ssh/telnet/smtp/time/whois/dns/domain/dhcps/
- dhcpc/tftp/gopher/finger/http/www/pop3/sunrpc/ident/nntp/ntp/ms-rpc/
- netbios_ns/netbios_dgm/netbios_ssn/imap/snmp/snmptrap/bgp/imap3/ldap/
- https/ms-ds/ike/rlogin/rwho/rsh/syslog/printer/rip/ripng/
- dhcpv6c/dhcpv6s/ms-sql/netmeeting/radius/l2tp/pptp/nfs/msblast/ipsec-nat-t/sip/
-ping/ping6/tcp/udp
FILTER_LIST ... ip filterコマンドで登録された静的フィルタ番号のリスト
OPTION ... オプション
- syslog=on/off
... セッションの通信履歴をsyslogに残すか否か
- timeout=TIMEOUT
... データが流れなくなったときにセッション情報を
解放するまでの時間(秒)
[説明]
動的フィルタを定義する。第1書式ではあらかじめルータに登録され
ているアプリケーション名を指定する。
第2書式では、ユーザがアクセス制御のルールを記述する。'filter'、
'in'、'out'の後には、ip filterコマンドで定義されたフィルタ番
号を設定する。
filter キーワードの後に記述されたフィルタに該当するトリガを
検出したら、それ以降inキーワードとoutキーワードの後に記述さ
れたフィルタに該当するコネクションを通過させる。inキーワード
はトリガの方向に対して逆方向のアクセスを制御し、outキーワード
は動的フィルタと同じ方向のアクセスを制御する。なお、ip filter
コマンドのIPアドレスは無視される。 pass/rejectの引数も同様に
無視される。
プロトコルとしてtcpやudpを指定したときには、アプリケーションに
固有な処理は実施されない。特定のアプリケーションを扱う必要があ
るときには、アプリケーション名を指定する。
[デフォルト値]
syslog=on
timeout=60
[入力形式]
ip filter dynamic delete ID (Rev.6以外)
no ip filter dynamic ID (Rev.6)
[パラメータ]
ID ... 動的フィルタ番号
[説明]
IDで指定された動的フィルタの定義を削除する。
ip INTERFACE secure filterコマンドが以下のように拡張される。 Rev.6.01系のファームウェアでは、ip filter setコマンドも同じ要領で拡張される。
[入力形式]
ip INTERFACE secure filter DIRECTION [ID ... ] [dynamic ID ... ]
no ip INTERFACE secure filter DIRECTION (Rev.6)
ip INTERFACE secure filter DIRECTION clear (Rev.6以外)
[パラメータ]
INTERFACE ... インタフェース名
DIRECTION ... 検査の方向
- in
- out
ID ... フィルタの識別子
[説明]
インタフェースに静的フィルタと動的フィルタを適用する。
DIRECTIONの直後に静的フィルタの番号を記述し、dynamicの直後に
動的フィルタの番号を記述する。
[入力形式]
ip filter dynamic timer [OPTION=TIMEOUT ... ]
no ip filter dynamic timer (Rev.6)
[パラメータ]
OPTION ... オプション名
- tcp-syn-timeout
... SYNを受けてから設定された時間内に
データが流れなければセッションを切断する
- tcp-fin-timeout
... FINを受けてから設定された時間が経てば
セッションを強制的に解放する
- tcp-idle-time
... 設定された時間内にTCPセッションのデータが
流れなければセッションを切断する
- udp-idle-time
... 設定された時間内にUDPセッションのデータが
流れなければセッションを切断する
- dns-timeout
... DNSのqueryを受けてから設定された時間内に
データが流れなければセッションを切断する
TIMEOUT ... 待ち時間 (秒)
[説明]
動的フィルタのタイムアウトを設定する。
[ノート]
この設定はすべての検査において共通に使用される。
[デフォルト値]
tcp-syn-timeout=30
tcp-fin-timeout=5
tcp-idle-time=3600
udp-idle-time=30
dns-timeout=5
[入力形式]
show ip connection [INTERFACE [INTERFACE_NUMBER] [DIRECTION]]
[パラメータ]
INTERFACE ... インタフェース
- lan/lan1/lan2
- pp
- tunnel
INTERFACE_NUMBER ... PP/TUNNELインタフェースの番号
DIRECTION ... 方向
- in
- out
[説明]
指定したインタフェースについて、動的なフィルタによって管理さ
れているコネクションを表示する。インタフェースを指定しないと
きには、すべてのインタフェースの情報を表示する。
[入力形式]
disconnect ip connection SESSION_ID [CHANNEL_ID]
[パラメータ]
SESSION_ID ... セッションの識別子
CHANNEL_ID ... チャネルの識別子
[説明]
指定したセッションに属する特定のチャネルを削除する。チャネ
ルを指定しないときには、そのセッションに属するすべてのチャ
ネルを削除する。
[入力形式]
ip INTERFACE intrusion detection DIRECTION [TYPE] SW [OPTION]
no ip INTERFACE intrustion detection
[パラメータ]
INTERFACE ... インタフェース名
DIRECTION ... 観察するパケットの方向
- in
- out
TYPE ... 観察するパケットの種類
- ip ... IP ヘッダ
- ip-option ... IP オプションヘッダ
- fragment ... フラグメント
- icmp ... ICMP
- udp ... UDP
- tcp ... TCP
- ftp ... FTP
- winny ... Winny
- share ... Share
- default ... 設定していないものすべて
SW ... 動作
- on ... 実行する
- off ... 実行しない
OPTION ... オプション
- reject=on/off ... 不正なパケットを破棄するかどうか
[説明]
指定したインタフェースで、指定された向きのパケットやコネクシ
ョンについて異常を検知する。
typeオプションを省略したときには、侵入検知機能の全体について
の設定になる。
[ノート]
危険性の高い攻撃については、rejectオプションの設定に関わらず、
常にパケットを破棄する。
typeオプションはRev.8.03.46、Rev.9.00.15以降のリビジョンで指
定可能で、各パラメータは以下のリビジョン以降で指定可能となっ
ている。
- winny、default ... Rev.8.03.46、Rev.9.00.15以降のリビジョン
- 上記以外のパラメータ ... Rev.10.00.38以降のリビジョン
Winnyについては、バージョン2の検知が可能であり、それ以前のバ
ージョンには対応していない。
また、対応するのはRev.8.03.46、Rev.9.00.15以降のリビジョンで
ある。
Shareについては、バージョン1.0EX2(ShareTCP版)の検知が可能であ
り、それ以前のバージョンには対応していない。
また、対応するのは Rev.10.00.38以降のリビジョンである。
[デフォルト値]
SW = typeを指定しないときoff, typeを指定したときon
reject = off
[入力形式]
show ip intrusion detection [INTERFACE [INTERFACE_NUMBER] [DIRECTION]]
[パラメータ]
INTERFACE ... インタフェース
- lan/lan1/lan2
- pp
- tunnel
INTERFACE_NUMBER ... PP/TUNNELインタフェースの番号
DIRECTION ... 方向
- in
- out
[説明]
最近の侵入情報を表示する。各インタフェースの各方向ごとに
最大50件まで表示できる。
[入力形式]
alarm intrusion SW
[パラメータ]
SW ... スイッチ
- on ... ブザーを鳴らす
- off ... ブザーを鳴らさない
[説明]
不正アクセスを検知したときにブザーを鳴らすかどうかを設定します。
[デフォルト]
on
[入力形式]
ip INTERFACE intrusion detection notice-interval FREQUENCY
no ip INTERFACE intrusion detection notice-interval
[パラメータ]
FREQUENCY ... 頻度 (1...1000)
[説明]
1秒間に侵入検知情報を通知する頻度を設定します。
[デフォルト]
1
[適用モデル]
vRX VMware ESXi版, vRX Amazon EC2版, RTX5000, RTX3500, RTX3000, RTX1210, RTX1200, RTX830, RTX810, FWX120, SRT100
[入力形式]
ip INTERFACE intrusion detection repeat-control TIME
no ip INTERFACE intrusion detection repeat-control
[パラメータ]
TIME ... 秒数 (1..1000)
[説明]
同じホストに対する同じ種類の攻撃を、time秒に1回のみ通知するよう抑制します。
[デフォルト]
60
[適用モデル]
vRX VMware ESXi版, vRX Amazon EC2版, RTX5000, RTX3500, RTX3000, RTX1210, RTX1200, RTX830, RTX810, FWX120, SRT100
[入力形式]
ip INTERFACE intrusion detection report NUM
no ip INTERFACE intrusion detection report
[パラメータ]
NUM ... 件数 (1..1000)
[説明]
show ip intrusion detectionコマンドで表示される侵入検知情報の最大件数を
設定します。
[デフォルト]
50
[適用モデル]
vRX VMware ESXi版, vRX Amazon EC2版, RTX5000, RTX3500, RTX3000, RTX1210, RTX1200, RTX830, RTX810, FWX120, SRT100
[入力形式]
ip INTERFACE intrusion detection threshold TYPE COUNT
no ip INTERFACE intrusion detection threshold TYPE
[パラメータ]
TYPE ... 閾値を設定する攻撃の種類
- port-scan ... ポートスキャン
- syn-flood ... SYNフラッド
COUNT ... 閾値 (1..65535)
[説明]
侵入検知で用いる閾値を設定します。
攻撃のタイプと設定する数値の意味は以下です。
port-scan ... 同じホストに対して、1秒間にcount種類の異なる
ポートへのアクセスを検出したらポートスキャンと判定する
syn-flood ... 同じホストに対するSYNパケットを、1秒間にcount回以上
検出したらSYNフラッドと判定する
[デフォルト]
port-scan=64, syn-flood=100
[適用モデル]
RTX3000