10.3. 明示的なマッチ
明示的なマッチ は、-m あるいは --match オプションではっきりとロードする必要のあるマッチだ。例えばステートマッチは、実際に使用したいマッチに先立って -m state ディレクティブ (命令句) を必要とする。この仲間には、プロトコル特有のマッチも幾つかある。また或るものは、プロトコルの種別とは一切無関係 -- 例えばコネクションステートがそうだ。コネクションステートとは NEW (まだ確立していない接続の最初のパケット)、 ESTABLISHED (既にカーネルに記録されている接続)、 RELATED (既存の確立済み接続に関連した接続) などといったものだ。さらに、ごく一部のマッチには、開発途上か実験的だったり、ただ単に iptables の可能性をデモンストレーションする目的で書かれたものもある。そうしたことから、一見しただけではいったい何に使ったらいいのか分からないマッチも存在するのだが、もしかすると、あなた自身がその有効な活用法を発見するかもしれない。さらには、 iptables の新しいリリース毎に、次々と新しいマッチが登場してくる。活用法が見いだせるかどうかは、あなたの創造力とニーズ次第だ。暗黙的なマッチ と 明示的なマッチ との違いは、暗黙的なマッチ 、例えば TCP パケットの性状に基づいてマッチを行うような場合には、そのマッチは自動的にロードされるが、明示的にロードする必要のあるマッチでは、自動的なロードは行われないという点だ。明示的マッチ の発見と活用は、あなたの腕に掛かっている。
10.3.1. Addrtypeマッチ
addrtype モジュールはパケットのアドレスタイプに基づいたマッチを行う。このアドレスタイプを基準にしてカーネルがパケットの分類を行う。このマッチを使えば、カーネルの保持しているアドレスタイプ情報に基づいてパケットをマッチさせることができるわけだ。注意しなければならないのは、アドレスタイプの意味がレイヤー3 のプロトコル毎に異なるという点だ。ここでも概要は述べるが、 Linux Advanced Routing and Traffic Control HOW-TO や Policy Routing using Linux でもっと詳しく読んでおいたほうがいい。利用できるタイプには以下のものがある：
Table 10-6. アドレスタイプ
| Type | 意味 |
|---|---|
| ANYCAST | これは 1対多の関係にあるコネクションであり、実際にデータを受信するのはその多数の受信ホストのうちひとつだけだ。この実装のひとつに DNS が挙げられる。ルートサーバは通常ひとつのアドレスで示すが、実際のルートサーバは複数のロケーションを指しており、パケットは直近のサーバひとつへ誘導されることになる。Linux の IPv4 には実装されていない。 |
| BLACKHOLE | ブラックホールアドレスはパケットをただひらすら破棄し、返答も返さない。おおよそ宇宙のブラックホールと同じだ。これは Linux のルーティングテーブルで設定される。 |
| BROADCAST | ブロードキャストパケットは、ひとつのパケットが 1対多の関係でネットワーク内の全員に送られるタイプのもの。 ARP 解決 (ARP resolution) がその一例で、或る IP への到達路を問い合わせるひとつのパケットが送信されると、我こそはというひとつのホストが然るべき MAC アドレスを回答する。 |
| LOCAL | 我々の今操作しているホスト自体のローカルなアドレス。例えば 127.0.0.1。 |
| MULTICAST | マルチキャストパケットは、最短の距離経路 (distance) を使って複数のホストへ向けて送信される。それぞれの中継地点 (waypoint) へは単一のパケットだけが送られ、そこで特定のマルチキャストアドレスに加入しているホストやルータの分だけ複製して送られる。ビデオやサウンドなど、一方通行のストリーミングメディアに使用されることが多い。 |
| NAT | カーネルによって NAT されたアドレス。 |
| PROHIBIT | blackhole と同じだが、「禁止されている」という返答を発生させる点が異なる。 IPv4 において言うならば、この返答は ICMP communication prohibited (タイプ 3, コード 13) となる。 |
| THROW | Linux カーネルの持つ特殊なルート。ルーティングテーブルでパケットが throw されると、そのパケットは、ルートが見つからなかった時と同じ挙動をする。通常のルーティングでは、ルートがなかったかのように振る舞うことになる。ポリシールーティングにおいては、他のルーティングテーブルを検索して別のルートが割り出される場合もある。 |
| UNICAST | ひとつのアドレスだけを指す正真正銘のルーティング可能なアドレス。最も一般的なルート。 |
| UNREACHABLE | 到達するまでの経路が分からず到達不能なことを知らせる。パケットは破棄され ICMP Host unreachable (タイプ 3, コード 1) が発生する。 |
| UNSPEC | 定義になく正当な意味を持たないアドレス。 |
| XRESOLVE | カーネルの行うルート検索の代わりにユーザ空間のアプリケーションにルート検索指示を送る時に使われるアドレスタイプ。あり得るケースとしては、込み入った汚いルックアップをカーネル外でやらせたり、何らかのアプリケーションにやらせたい場合だ。Linux では実装されていない。 |
addrtype マッチは -m addrtype キーワードを使用した時にロードされる。ロードされると、下表に示すマッチオプションが使えるようになる。
Table 10-7. Addrtypeマッチオプション
| マッチ | --src-type |
| カーネル | 2.6 |
| 例 | iptables -A INPUT -m addrtype --src-type UNICAST |
| 説明 | --src-type マッチオプションは、パケットの送信元のアドレスタイプに対してマッチを行う。アドレスタイプは単一でもよいし、カンマ区切りで複数指定してもよく、例としては --src-type BROADCAST,MULTICAST のようになる。このマッチオプションは手前にエクスクラメーションマークを置いて ! --src-type BROADCAST,MULTICAST のように意味反転を行うことも可能。 |
| マッチ | --dst-type |
| カーネル | 2.6 |
| 例 | iptables -A INPUT -m addrtype --dst-type UNICAST |
| 説明 | --dst-type も --src-type と同様に働き、文法も同じ。違うのは、宛先のアドレスタイプに対してパケットマッチを行うという点だけだ。 |
10.3.2. AH/ESPマッチ
このふたつのマッチは IPSEC の AH と ESP プロトコルを対象にしている。 IPSEC はセキュリティに欠けるインターネット接続上にセキュアなトネリングを構築するためのもの。 AH と ESP プロトコルは、そうしたセキュアなコネクションを構築する際に IPSEC によって利用される。本当のところ、 AH マッチと ESP マッチは全く別個のマッチなのだが、非常によく似たところがあるし用途も共通しているので、ここで一緒に述べることにする。
IPSEC についてここで詳しく述べるのは差し控える。より詳しい情報は以下のページやドキュメントを見て頂きたい：
IPSEC に関するドキュメントはインターネット上に五万とあるが、必要なら思い思いに検索してみてほしい。
AH/ESP マッチを使用するには、 AH マッチなら -m ah、 ESP ならば -m esp を使ってマッチをロードする必要がある。
 | カーネル 2.2 と 2.4 においては、Linux は IPSEC を実装するために FreeS/WAN と呼ばれるものを利用していた。しかし Linux カーネル 2.5.47 以降では、カーネル自体が IPSEC を実装するようになり、カーネルへのパッチを必要としなくなった。 Linux の IPSEC 実装部分がまるっきり書きなおされたのだ。 |
Table 10-8. AHマッチオプション
| マッチ | --ahspi |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p 51 -m ah --ahspi 500 |
| 説明 | このマッチは AH パケットの持つ AH Security Parameter Index (SPI) ナンバーを照合する。注意が必要なのは、このマッチを使用するならプロトコルも指定しなければならないという点。 AH は標準的な TCP, UDP, ICMP とは違ったプロトコルの上で働くからだ。 SPI ナンバーは送信元/宛先アドレスと秘密キーとともに、セキュリティアソシエーション (SA = security association) の生成に使われる。 SA はホスト毎の IPSEC トンネルそれぞれに一意性を与える。 SPI は一対のピア-ピア間の個々の IPSEC トンネルを識別するのに利用される。 --ahspi を使うと、パケットの SPI に基づいたマッチングを行うことができる。このマッチでは : を使って SPI 値の範囲をまとめてマッチさせることも可能だ。例えば 500:520 のような使い方で、これは範囲内の SPI に合致する。 |
10.3.3. Commentマッチ
comment マッチを使うと iptables ルールセット及びカーネル内にコメントを記述することができる。ルールセットが理解しやすくなりデバグに役立つだろう。例えば、或る一連のルールがどの bash ファンクションによってどんな理由で差し込まれたかを述べたコメントを加える、といった使い方が考えられる。このマッチは実際のところ本当のマッチではないことに注意していただきたい。comment マッチは -m comment キーワードによってロードされる。現在のところ、以下のオプションが利用できる。
10.3.4. Connmarkマッチ
connmark マッチは、 MARK ターゲットと mark マッチの組み合わせと全く同じような使い方をする。 CONNMARK ターゲットでコネクション単位に付けられたマークに対して、マッチを行うのが connmark だ。オプションはひとつのみ。
 | そのコネクションに mark を付けるに至ったまさにその最初のパケットをマッチさせるには、先に CONNMARK ターゲットに最初のパケットへマークを付けさせてから、 connmark マッチを使用しなければならない。 |
Table 10-11. Connmarkマッチオプション
| マッチ | --mark |
| カーネル | 2.6 |
| 例 | iptables -A INPUT -m connmark --mark 12 -j ACCEPT |
| 説明 | mark オプションは、コネクション単位で関連付けされたマーク (mark) に対してマッチを行う時に使用する。マークは完全に一致する必要がある。実際のマッチングに先立って不要なコネクションマークを排除しておきたい場合には、マスクを指定してマークとの論理積 (logical AND) を行わせることもできる。例を示す。或るコネクションにマーク 33 (バイナリ表現 10001) がセットされており、最初のビットだけをマッチさせたいとしよう。この時、 --mark 1/1 のようにコマンドすることができる。マスク (00001) は 10001 に対してマスク適用され、その結果 10001 && 00001 = 1 となり、 1 にマッチすることになる。 |
10.3.5. Conntrackマッチ
conntrack マッチはステートマッチの拡張版であり、ステートマッチよりも格段に詳しくパケットを照合することが可能だ。これは、コネクション追跡機構から得られる情報を、ステートマッチのような "フロントエンド" の助けを借りることなしに直接調べることを可能にしてくれる。コネクション追跡機構についての詳細は ステート機構 のチャプターを参照して頂きたい。
conntrack マッチには、コネクション追跡機構の様々なフィールドに呼応する、幾種類ものマッチが収められている。そうしたマッチを集めたのが、下のリストだ。これらのマッチをロードするには -m conntrack を指定する必要がある。
Table 10-12. Conntrackマッチオプション
| マッチ | --ctstate |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctstate RELATED |
| 説明 | このマッチは conntrack の状態を基にしてパケットのステートをマッチさせる場合に使用する。本来の state マッチでのステートとほぼ同じものを対象にしたい場合に用いる。このマッチで有効なステートエントリは：
ステートエントリをカンマで区切って複数指定することもできる。例えば -m conntrack --ctstate ESTABLISHED,RELATED といった具合だ。また、 -m conntrack ! --ctstate ESTABLISHED,RELATED の例ならば ESTABLISHED と RELATED 以外にマッチする。 |
| マッチ | --ctproto |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctproto TCP |
| 説明 | これは --protocol が行うのと同様にプロトコルでマッチを行う。タイプとして指定できる値も同じで、 ! 記号を使っての反転もできる。例えば -m conntrack ! --ctproto TCP は TCP プロトコルを除く全てのプロトコルにマッチする。 |
| マッチ | --ctorigsrc |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctorigsrc 192.168.0.0/24 |
| 説明 | --ctorigsrc マッチは、特定のパケットに関する conntrack エントリに記録された送信元IP の諸元に基づいてマッチを行う。 --ctorigsrc ! 192.168.0.1 のように --ctorigsrc と IP 指定との間に ! を挟むことにより意味を反転させることもできる。また --ctorigsrc 192.168.0.0/24 といった風に CIDR 形式のネットマスクを採ることも可能だ。 |
| マッチ | --ctorigdst |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctorigdst 192.168.0.0/24 |
| 説明 | このマッチは、照合対象が conntrack エントリの宛先フィールドである点を除けば --ctorigsrc と全く同じ。書式もあらゆる点において共通だ。 |
| マッチ | --ctreplsrc |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctreplsrc 192.168.0.0/24 |
| 説明 | --ctreplsrc マッチは、 conntrack に記載されている回答パケットの送信元に基づいてマッチを行いたい時に使う。基本的には --ctorigsrc と同様なのだが、こちらの場合には、次に期待される返答の送信元と照合する。もちろん、このクラスの前述のターゲットと同様に、反転や、アドレスの範囲指定も可能だ。 |
| マッチ | --ctrepldst |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctrepldst 192.168.0.0/24 |
| 説明 | --ctrepldst マッチは --ctreplsrc と同様で、パケットがマッチしたことにより記録された conntrack エントリの中の、回答の宛先を照合対象にする点が異なる。これも --ctreplsrc 同様に反転や範囲指定ができる。 |
| マッチ | --ctstatus |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctstatus RELATED |
| 説明 | このマッチは ステート機構 のチャプターで述べたコネクションの状態 (status) でマッチを行う。照合できるステータスには以下のものがある：
このマッチもまた ! 記号で反転することができる。例えば -m conntrack ! --ctstatus ASSURED で、これは ASSURED 以外のステータスに合致する。 |
| マッチ | --ctexpire |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m conntrack --ctexpire 100:150 |
| 説明 | このマッチは conntrack エントリの有効期限タイマー (expiration timer) に残っている時間 (秒単位) に基づいたパケットマッチに使用する。単一の値を与えて照合することもできるし、上記の例のように範囲を指定することもできる。また、 -m conntrack ! --ctexpire 100 のように ! 記号を使用しての反転も可能で、これは、ぴったり 100 秒残っているもの以外の有効期限をマッチさせる。 |
10.3.6. DSCPマッチ
このマッチはパケットをその DSCP (Differentiated Services Code Point) フィールドに基づいてマッチさせる。 DSCP については RFC 2638 - A Two-bit Differentiated Services Architecture for the Internet に網羅されている。このマッチは明示的に -m dscp を指定するとロードされる。下記に挙げる、排他関係にあるふたつのオプションが採れる。[訳者補足: DSCP自体については IPヘッダ セクションで幾分か詳しく述べられている]
Table 10-13. DSCPマッチオプション
| マッチ | --dscp |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m dscp --dscp 32 |
| 説明 | このオプションは引数として 10進または 16進表記の DSCP 値を採る。オプション値を 10進で書くとすれば 32 や 16 などといった具合。 16進表記の際には頭に 0x を添えて 0x20 のように書く。 ! の字を使って -m dscp ! --dscp 32 のように意味を反転することも可能。 |
| マッチ | --dscp-class |
| カーネル | 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m dscp --dscp-class BE |
| 説明 | --dscp-class マッチはパケットの DiffServ クラスによってマッチを行う際に使用する。その値は、幾つかの RFC で定義されているように BE, EF, AFxx, CSx のいずれかのクラスとなる。 --dscp と同じく反転もできる。 |
| --dscp オプションと --dscp-class オプションは排他の関係にあり、同時指定はできないことに注意して頂きたい。 |
10.3.7. ECNマッチ
ECN マッチは TCP と IPv4 ヘッダにある ECN フィールド類を照合するのに使う。 ECN の詳細は RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP の中で述べられている。このマッチはコマンドラインで -m ecn を指定して明示的にロードしなければならない。 ECN マッチが採れるオプションには以下のようなものがある。[訳者補足: ECN自体については IPヘッダ のセクションで幾分か詳しく述べられている]
Table 10-14. ECNマッチオプション
| マッチ | --ecn |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m ecn --ecn-tcp-cwr |
| 説明 | このマッチは、パケットに CWR (Congestion Window Received) ビットがセットされているかどうかを照合する。 CWR フラグを設定するのは、 ECE を受け取ったかどうかと ECE に対して反応したかを、コネクションの相手方に知らせる時。デフォルトでは、このマッチは CWR ビットがセットされていれば一致するが、エクスクラメーションマークを使って逆の意味にすることもできる。 |
| マッチ | --ecn-tcp-ece |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m ecn --ecn-tcp-ece |
| 説明 | このマッチは ECE (ECN-Echo) ビットでマッチを行うことができる。 ECE ビットは、どちらか一方のエンドポイントが、ルータによって CE ビットの立てられたパケットを受け取った場合にセットされる。すると、受信者は応答の ACK パケットに ECE ビットを立てることによって、相手方に、ペースを遅くする必要があることを知らせる。知らせを受け取った相手は --ecn-tcp-cwr で述べた CWR パケットを送出する。デフォルトではこのマッチは ECE ビットが立っているとマッチするが、エクスクラメーションマークを使って意味を逆転することもできる。 |
| マッチ | --ecn-ip-ect |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m ecn --ecn-ip-ect 1 |
| 説明 | --ecn-ip-ect マッチは ECT (ECN Capable Transport) コードポイントによってマッチを行いたい時に利用する。 ECT コードポイントには幾つかの利用法がある。まず主には、2 ビットあるうちの片方を 1 にセットすることにより、そのコネクションが ECN に対応しているかどうかを折衝する、という使い方。また、ルータにおいては、 ECT コードポイントを 2 ビットとも 1 にして、輻輳の発生を知らせるという使い方もある。 ECT の値は下表 IP内のECNフィールド にまとめておいた。 マッチはエクスクラメーションマークで ! --ecn-ip-ect 2 のように反転することができる。この例の場合、コードポイント ECT(0) を除いた全ての ECN値にマッチする。 iptables で使用できる値は 0 から 3 までだ。それらの値に関しては下表を参照のこと。 |
10.3.8. Hashlimitマッチ
これは Limitマッチ の変形バージョンだ。単にひとつのトークンバケツ (token backet) ではなく、宛先IP, 送信元IP, 宛先ポート, 送信元ポートの組み合わせから成る幾つものトークンバケツを指す、ひとつのハッシュテーブルが構築される。例えば、各 IPアドレス毎に最大 1000個/秒のパケットを受け取れるようにしたり、待ち受け IPアドレスはひとつであっても異なったサービス毎に最大 200パケット/秒まで受け入れるようにするなどといった設定ができる。 hashlimit マッチは -m hashlimit を指定するとロードされる。
hashlimit マッチの使用された各々のルールに対して別個のハッシュテーブルが生成され、ひいては、バケツのサイズ及び数の上限値は各ハッシュテーブル毎に定義できる。このハッシュテーブルはひとつの値だけを保持することもできるし、複数を保持することもできる。その値とは、宛先IP, 送信元IP, 宛先ポート, 送信元ポートのいずれか、またはそれら全てだ。これが形成されれば、それぞれのルールエントリが自分のトークンバケツを limit マッチ同様に参照できるようになる。
Table 10-16. Hashlimitマッチオプション
| マッチ | --hashlimit | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000/sec --hashlimit-mode dstip,dstport --hashlimit-name hosts | ||
| 説明 | --hashlimit はトークンバケツのリミットを設定する。上記の例では、ハッシュリミットを 1000 に設定している。その中でハッシュリミット-モードを dstip,dstport、宛先を 192.168.0.3 にしている。これによって、送信先ホストのポートまたはサービス毎に、1秒あたり 1000個のパケットを受信することができる。これは limit マッチの limit オプションと同じ設定だ。リミットの値には /sec, /minute, /hour, /day のいずれかの接尾語を付けることもできる。接尾語を付けない場合のデフォルトは毎秒となる。
| ||
| マッチ | --hashlimit-mode | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.0/16 -m hashlimit --hashlimit 1000/sec --hashlimit-mode dstip --hashlimit-name hosts | ||
| 説明 | --hashlimit-mode オプションは、ハッシュの値としてどの値を使用するかを定義する。上記の例では、ハッシュ値に dstip (destination IP) だけを使用している。これにより、当例の場合 192.168.0.0/16 のネットワークからの受信は、各相手ホストあたり最大 1000パケット/毎秒に制限される。 --hashlimit-mode に設定可能な値には dstip (宛先IP), srcip (送信元IP), dstport (宛先ポート), srcport (送信元ポート) がある。複数のハッシュ値を含めたい場合にはカンマで区切ることによってどれでも指定することができる。例えば --hashlimit-mode dstip,dstport といった具合だ。
| ||
| マッチ | --hashlimit-name | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts | ||
| 説明 | このオプションは、そのハッシュを利用する際の名称を指定する。ここで指定したものは /proc/net/ipt_hashlimit ディレクトリで見ることができる。上記のものは /proc/net/ipt_hashlimit/hosts ファイルとして見られる。指定できるのはファイル名だけだ。
| ||
| マッチ | --hashlimit-burst | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-burst 2000 | ||
| 説明 | このマッチは、バケツのサイズを設定するという意味で --limit-burst と同じ。バケツには必ずバーストリミットがある。バーストリミットは、単位時間内にマッチさせることのできる最大パケット数だ。トークンバケツの動作については、 Limitマッチ に示した例を見ていただくといいだろう。 | ||
| マッチ | --hashlimit-htable-size | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-htable-size 500 | ||
| 説明 | このオプションは、利用可能なバケツの最大数を規定する。上記の例は 500個までのポートが同時にオープンでき並行してアクティブになれることを意味する。 | ||
| マッチ | --hashlimit-htable-max | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-htable-max 500 | ||
| 説明 | --hashlimit-htable-max はハッシュテーブル・エントリの最大数を指定する。これによって表されるのはコネクションの総数であり、その時トークンバケツを一切使用していない非活性なコネクションも含まれる。 | ||
| マッチ | --hashlimit-htable-gcinterval | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-htable-gcinterval 1000 | ||
| 説明 | ガーベッジ・コレクション (garbage collection=ゴミ収集) 機能の実行頻度。一般論的には、expire の値よりも低くすべきである。単位はミリ秒。小さくしすぎるとシステムリソースや CPUパワーを無用に消費する一方、大きくしすぎると、使いもしないトークンバケツが長期間ほったらかしになり、他のコネクションが受け入れ不能となる。上記の例では、ガーベッジ・コレクションは 1秒毎に実行される。 | ||
| マッチ | --hashlimit-htable-expire | ||
| カーネル | 2.6 | ||
| 例 | iptables -A INPUT -p tcp --dst 192.168.0.3 -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-htable-expire 10000 | ||
| 説明 | この値は、ハッシュテーブルの特定エントリがどれくらいの期間アイドルを続けたら失効となるかを規定する。バケツの使用されない期間がこの値を超えるとそのエントリは失効し、次回のガーベッジ・コレクションの際に、関連する情報もろともハッシュテーブルから削除される。 |
10.3.9. Helperマッチ
これは、書式の特殊性という意味において、マッチの中でも異端に数えられるマッチと言えるかもしれない。このマッチは、そのパケットがどの conntrack ヘルパーに関係しているかに基づいてパケットを選定する。 FTP セッションを例に採ろう。コントロールセッションが開き、そのコントロールセッションを通じてデータセッション用のポート/コネクションがネゴシエートされる。その情報を見つけるのがヘルパー ip_conntrack_ftp で、それが conntrack テーブルに RELATED エントリを記録する。よって我々は、次のパケットが来た時、それがどのプロトコルに関連したパケットなのかを知ることができ、利用されたヘルパーの種類に基づいたパケットマッチをルールセットの中で行えるのだ。このマッチは、キーワード -m helper を使用することによってロードされる。
Table 10-17. Helperマッチオプション
| マッチ | --helper |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m helper --helper ftp-21 |
| 説明 | --helper オプションの利用法は、文字列値を指定して、合致させたい conntrack ヘルパーを指示することだ。基本的な書式としては --helper irc のようになる。しかしここからがちょっと込み入ってくる。特定のポートで初期ネゴシエーションが行われたパケットだけをマッチさせることも可能なのだ。例えば FTP では、コントロールセッションには通常なら 21番ポートを使うが、 954など他のポートを使用することもある。そういった場合には、どのポートでネゴシエーションが行われたものかを指定すればいい。例えば --helper ftp-954 のようにだ。 |
10.3.10. IP rangeマッチ
IP range マッチは IP の範囲に対してマッチを行う。これは --source マッチや --destination マッチでもできることだが、 IP range マッチでは --source や --destination では不可能だった 始点IP - 終点IP という形での照合が可能となる。特異な設定のネットワークではこうしたやり方が必要で、しかもこちらのほうがやや柔軟性に富む。IP range はキーワード -m iprange を使うことによってロードされる。
Table 10-18. IP rangeマッチオプション
| マッチ | --src-range |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m iprange --src-range 192.168.1.13-192.168.2.19 |
| 説明 | このマッチは送信元 IP の範囲を照合する。指定した範囲は始点から終点までの全 IP を含み、上の例なら 192.168.1.13 から 192.168.2.19 までが入る。 ! を加えることによって意味を反転することもできる。それを使うとすれば上記の例は -m iprange ! --src-range 192.168.1.13-192.168.2.19 のようになり、指定した範囲を除く全 IPアドレスがマッチすることになる。 |
| マッチ | --dst-range |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m iprange --dst-range 192.168.1.13-192.168.2.19 |
| 説明 | --dst-range の動作は、対象が送信元でなく宛先である点を除けば --src-range マッチと全く同様だ。 |
10.3.11. Lengthマッチ
Length マッチを使うと、パケットの長さに基づいたマッチが行える。ことは至って単純だ。もしも何か特別な理由でパケットの長さを制限したかったり、 ping-of-death 的な挙動をブロックしたいのであれば、 length マッチを使うといい。
Table 10-19. Lengthマッチオプション
| マッチ | --length |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m length --length 1400:1500 |
| 説明 | 例に示した --length は、長さが 1400バイトから 1500バイトである全パケットに合致する。また、このマッチは ! 記号を使って -m length ! --length 1400:1500 といった具合に意味を反転させることもできる。更に、 : 記号以下を取り去って特定の長さのパケットだけをマッチさせることも可能だ。言うまでもないが length マッチの対象は「以上」や「以下」であり、指定した数値も含めた中間のあらゆる長さのパケットを含む。 |
10.3.12. Limitマッチ
limit マッチ拡張機能は -m limit オプションによって明示的にロードする必要がある。このマッチは例えば、特定のルールのログを限定的に間引きながら取るなどの活用法がある。或る値が指定数値以下であるパケットにマッチさせ、その数値を超えたら、対象としているイベントのロギングを抑制 (limit) する、などといった場合だ。時間的な limit について考えてみよう。あるルールが一定の単位時間内に何回マッチするかを制限することによって、例えば DoS の synパケット氾濫 (syn flood) 攻撃の影響を低減することができる。これが limit マッチの主な使い道ではあるが、もちろん利用法は他にもある。limit マッチは、マッチの前に ! 記号を用いることによって反転することも可能だ。これを使うと、-m limit ! --limit 5/s と書ける。これは、リミットを突破した後のすべてのパケットにマッチする。[訳者補足: 以下の説明に出てくる "トークン (token)" は地下鉄などの切符を意味する英語彙、"バースト (burst)" は直訳すると "爆発" や "突発"]
より詳しく説明すると、 limit マッチは、理屈としては一種のトークンバケツフィルタ (token bucket filter) だと言える。ここに、水漏れバケツがあるとしよう。このバケツは、単位時間あたり X 個のパケットが漏れる。 X は、条件に合致するパケットがいくつ入ってきたかによって規定が変化する。もし 3パケット入ってくれば、バケツからは単位時間あたり 3 個のパケットが漏れる。 --limit オプションは単位時間あたりいくつのパケットをバケツに補充できるかを規定し、 --limit-burst オプションは、そもそものバケツの大きさを表す。よって、 --limit 3/minute --limit-burst 5 と指定してあるところに 5個のパケットがマッチすると、バケツはカラになる。 20秒 [訳者補足: 1/3 分] 経つと、バケツのトークンは 1 つ増え...が、再び --limit-burst に達するかトークンが使用されるまで繰り返される。
これがどう作動するかの説明に代えて、以下の例を考察していただこう。
-m limit --limit 5/second --limit-burst 10/second というルールを設定する。 limit-burst トークンバケツの初期値は 10 にセットされる。ルールに合致する各パケットはトークンをひとつ消費する。
マッチするパケット 1-2-3-4-5-6-7-8-9-10 が来る。パケットは 1/1000 秒以内で入ってくるとする。
トークンバケツはカラになった。トークンバケツが一旦カラになると、ルールに沿ったパケットであってももうルールにマッチしないので、もし次のルールがあればその評価を受け、なければチェーンのポリシーが適用される。
パケットがマッチしない時間が 1/5 秒続くと、そのたびにトークンカウントが 1 ずつ上がり、最大では 10 まで上がる。先ほどの 10パケットを受け取ってから 1秒経過すると、トークンの残り数は 5 まで復活している。
そして当然、パケットを 1つ受け取る度に、バケツのトークンも 1 ずつ減っていく。
Table 10-20. Limitマッチオプション
| マッチ | --limit |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m limit --limit 3/hour |
| 説明 | limit マッチのための、平均マッチ頻度の最大値を設定する。指定には、数と単位時間 (省略可能) が使用できる。現行では、次の様な単位時間が理解可能だ: /second /minute /hour /day 。デフォルト値は毎時 3回、 つまり 3/hour。この指定は limit マッチに対して、単位時間 (例えば分) あたりに許容するマッチの回数を指示する。 |
| マッチ | --limit-burst |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m limit --limit-burst 5 |
| 説明 | limit マッチにおける burst limit [訳者補足: 短い時間内で爆発的ににヒットする数の上限] を設定する。これは iptables に対して、与えられた単位時間内にマッチするパケットの最大数を伝える。この数は、1 単位時間 (--limit オプションで指定されたもの) がイベントの発生なしに経過する度に、この値の採れる最小値である 1 へ向かって 1 ずつ減ってゆく。イベントがまた発生すると、カウントがバーストリミットに達するまで、カウンタの値はまた増えていく。この繰り返しだ。デフォルトの --limit-burst 値は 5。その動作を確認する簡単な方法は、たったひとつのルールから成るスクリプト例 Limit-match.txt を使ってみることだ。このスクリプトを利用すれば、間隔とバースト数 [訳者補足: 短い時間内で爆発的ににヒットする数] を変えながら ping を送るだけで、 limit ルールがどう働くのかをその目で見ることができる。カウントがバーストリミットのしきい値まで回復するまで、 echo応答 はブロックされて返ってこない。 |
10.3.13. MACマッチ
MAC (Ethernet Media Access Control) マッチは送信元 MACアドレス に基づいたパケットマッチに使用する。このドキュメントを書いている時点では、このマッチには幾らかの制限事項があるが、将来的にはもっと開発が進み便利になるだろう。既に述べたように、送信元の MACアドレス によるマッチしかできない。
| このモジュールを使用するには明示的に -m mac オプションを指定しなければならない。わざわざこんなことを言うのは、 -m mac-source でいいのではないかと勘違いする人が多いからだ。 |
Table 10-21. MACマッチオプション
| マッチ | --mac-source |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m mac --mac-source 00:00:00:00:00:01 |
| 説明 | 送信元 MACアドレス に基づいたパケットマッチに使用する。指定する MACアドレス は XX:XX:XX:XX:XX:XX の形式でなくてはならなず、それ以外は通用しない。マッチは ! 記号で反転でき、 --mac-source ! 00:00:00:00:00:01 のように書ける。これはマッチの意味を逆転するので、その MACアドレス 以外から来るパケットにマッチする。留意点として、 MACアドレス はイーサネットタイプのネットワークでだけ用いられており、このマッチもイーサネットインターフェースにしか使用できない。 MAC マッチは PREROUTING, FORWARD, INPUT チェーンでのみ有効で、他で使うことはできない。 |
10.3.14. Markマッチ
mark マッチは、パケットに付けておいたマーク (mark) に基づいてパケットをマッチさせるのに使用する。マークはカーネルの中でのみ維持管理できる特別なフィールドで、パケットがコンピュータの中を通過している間だけ識別に利用できる。マークはトラフィックシェーピングやフィルタリングなどといった様々なカーネル関連ルーティンに利用可能だ。今のところ、マークをセットする Linux で唯一の方法は、iptables の、その名も MARK ターゲットのみだ。同じことが、以前は ipchains の FWMARK ターゲットで行われていた。高度ルーティングのコミュニティで未だに FWMARK が言及されるのは、これが理由だ。現行では、mark フィールドには符号無しの整数が指定でき、32ビットシステムでは 4,294,967,296通りの値を採ることができる。おそらく、この制限にひっかかることは滅多にないだろう。
Table 10-22. Markマッチオプション
| マッチ | --mark |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -t mangle -A INPUT -m mark --mark 1 |
| 説明 | あらかじめマークを付けられたパケットにマッチさせるために用いる。マークは、次のセクションで述べる MARK ターゲットによって付与することができる。 Netfilter を通過している間、パケットにはもれなく特殊なマークフィールドが関連づけされる。このマークフィールドは、パケットの内側にも外側にも、実際に余分なフィールドをくっつけるわけではないという点に注意してほしい。マークは、マークを生成したコンピュータの中に保持されるのだ。マークフィールドが指定したマークに合致すれば、即ちマッチとなる。マークフィールドは符号無しの整数で、 4,294,967,296 通りの値を採ることができる。また、マークにマスクを設定することも可能だ。これを使用した場合、マークの指定は、 --mark 1/1 といった具合になる。マスクが指定されていた場合には、実際の比較に先立って、マスクとマークの論理積が行われる。 |
10.3.15. Multiportマッチ
multiport マッチ拡張によって、複数の宛先ポートや、複数の宛先ポート範囲が指定できるようになる。このマッチの能力を利用しないと、ポートが異なるだけで、同じタイプのルールをいくつも書かなければならない。
| 通常のポートマッチングと multiport マッチを同時に使用することはできない。つまり、このように書くことはできない: --sport 1024:63353 -m multiport --dport 21,23,80。実際にやったらどうなるかといえば、 iptables はルールの最初の要素だけを尊重し、 multiport 指示は無視される。 |
Table 10-23. Multiportマッチオプション
| マッチ | --source-port |
| カーネル | 2.3, 2.4, 2.5 2.6 |
| 例 | iptables -A INPUT -p tcp -m multiport --source-port 22,53,80,110 |
| 説明 | このマッチは複数の送信元ポートにマッチする。不連続なポート 15個まで指定できる。上記の例のように、ポートはカンマ区切りで指定する。このマッチは -p tcp または -p udp との併用でしか使用できない。基本的には、通常の --source-port マッチの拡張版だ。 |
| マッチ | --destination-port |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m multiport --destination-port 22,53,80,110 |
| 説明 | このマッチは複数の宛先ポートを合致させるのに使用する。ポートが宛先である点を除いては、上記の送信元ポートマッチとまったく同様に働く。このマッチも制限は 15個で、 -p tcp または -p udp と組み合わせなければ使えない。 |
| マッチ | --port |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m multiport --port 22,53,80,110 |
| 説明 | このマッチ拡張は、宛先と送信元のポートに基づいてパケットをマッチさせるのに用いる。上記の --source-port と --destination-port と同じように作用する。最大 15個のポートを採ることができ、 -p tcp か -p udp との組み合わせでしか機能しない点も同じだ。ただし、 --port マッチは、送り手のポートと受け側ポートが同じであるパケットのみにマッチする。例えば、ポート 80 からポート 80 へ宛てたパケット、ポート 110 からポート 110 へ宛てたパケット、といった具合だ。 |
10.3.16. Ownerマッチ
owner マッチ拡張は、パケットを作り出したプロセスの身元に基づいてパケットをマッチさせるのに用いる。 owner にはプロセスの ID を指定する。 ID は、当該のコマンドを発行したユーザ、グループ、プロセス、セッションの ID、あるいはコマンドそのもの ID のいずれか。この拡張は元々 iptables の活用方法のひとつを示す例として書かれたものだ。 owner マッチは OUTPUT チェーンでしか使えない。その理由はいくつかある: パケットを送り出したプロセスの身元に関する情報を、着信した先で探し出しすのはほぼ不可能に近い。また、最終的な目的地に辿り着くまでに中継ホップを経ている場合にも、やはり難しい。ある種のパケットはオーナーを欠いているため、たとえ OUTPUT チェーン内に限ったとしても、このマッチはあまり信頼できない。これに類する悪名高いパケットには、(他にもあるが) 様々な ICMP 応答が挙げられる。 ICMP応答 は決してこれにマッチすることはない。
Table 10-24. Ownerマッチオプション
| マッチ | --cmd-owner |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m owner --cmd-owner httpd |
| 説明 | コマンドのオーナーによるマッチであり、パケットを送り出したプロセスの名前に基づいてマッチを行う。例に示したものには httpd が合致する。エクスクラメーションマークを使って -m owner ! --cmd-owner ssh のように意味を反転させることもできる。 |
| マッチ | --uid-owner |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m owner --uid-owner 500 |
| 説明 | このマッチは、パケットを作り出したユーザ の ID が、指定された ID (UID) と一致していればマッチする。これは、誰がパケットを発生させたかに基づいて、ローカルから出ていくパケットを選択するのに用いられる。想定される用途としては、root 以外のユーザがファイヤーウォール外への新規コネクションを開始するのを阻止する場合。あるいは、 http ユーザ以外は HTTP ポートからパケットを送出できなくする、という使い方が考えられる。 |
| マッチ | --gid-owner |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m owner --gid-owner 0 |
| 説明 | このマッチは、パケットのグループID (GID) に基づいてパケットをマッチさせる。つまり、パケットを発生させたユーザがどのグループに属するかによってパケットをマッチさせるわけだ。 network グループに属するユーザを除いてはインターネットに出て行けなくする、あるいは、前のマッチのように HTTP ポートから出ようとするパケットの発行を http グループのメンバーにのみ許す、という使い方ができる。 |
| マッチ | --pid-owner |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m owner --pid-owner 78 |
| 説明 | このマッチは、パケットの元となったプロセス の ID (PID) に基づいてパケットマッチを行うのに使用する。このマッチは使い方がやや難しいが、例えば、PID 94 にだけ HTTP ポートからのパケット送出を許す場合がある (言うまでもなく、HTTPD プロセスがスレッド化されていない場合に限る)。或いは、 ps の出力を利用して探知した特定デーモンの PID に応じてルールを追加するような小さなスクリプトを書いておく、という手法も考えられる。やるとすれば、スクリプト例 Pid-owner.txt で示しているようなルールが書ける。 |
| マッチ | --sid-owner |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m owner --sid-owner 100 |
| 説明 | 当該プログラムのセッションID に基づいてパケットをマッチする。SID つまりセッションID の値は、プロセス自体の ID であると同時に、そのプロセスから派生した全プロセスの SID でもある。後者には、元のプロセスのスレッドや子プロセスも含まれる。つまり、例えば HTTPD がスレッド化されていたとしても (ほとんどの HTTPD はそうだ。 Apache も Roxen も)、すべての HTTPD プロセスは親プロセス (大元の HTTPD プロセス) と同じ SID を持っているはずである。この実例として Sid-owner.txt を作っておいた。この小さなスクリプトの使い道は、 HTTPD が起動しているかどうか調べて必要ならば起動させ、必要に応じて OUTPUT チェーンをフラッシュしてから OUTPUT チェーンをロードし直すような、追加のスクリプトと組み合わせて、例えば 1時間に 1回走らせることだ。 |
| pid, sid マッチは SMPカーネルでは動作が破綻している。これらのマッチはプロセスリストをプロセッサ別に管理するからだ。とはいえ、将来は修正されるだろう。 |
10.3.17. Packet type マッチ
packet type マッチはパケットのタイプに基づいてマッチを行う。言い換えると、特定のひとりに宛てたものなのか、全員なのか、あるいは或る限られたマシンの一団やユーザの一団宛てなのか、ということだ。これら 3つの括りはそれぞれ、ユニキャスト、ブロードキャスト、マルチキャスト と呼ばれる。そのことは TCP/IPのおさらい のチャプターで述べている。このマッチは -m pkttype によってロードする。
Table 10-25. Packet typeマッチオプション
| マッチ | --pkt-type |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m pkttype --pkt-type unicast |
| 説明 | --pkt-type マッチは、どのようなパケットタイプに合致させるかを指示する。例にあるように、その引数には unicast, broadcast, multicast のいずれが指定できる。 ! を使って -m pkttype --pkt-type ! broadcast のように意味を反転することも可能で、この場合、ブロードキャスト以外のパケットタイプにマッチすることになる。 |
10.3.18. Realmマッチ
realm は、そのパケットがどのルーティング・レルム (Routing realm) に属するかによってマッチを行う。ルーティング・レルムは Linux で複雑なルーティングを行う必要のある場面で、例えば、どんな場合に BGP を使用するかといった制御をするのに使われる。 realm マッチはコマンドラインに -m realm キーワードを加えるとロードされる。[訳者註: 英語彙 realm の元々の意味は「領域」「〜界」で、感覚的には domain という語と近い]
Linux においては、ルーティング・レルムというものは複数のルートを幾つかの論理上のグループにまとめるのに使われる。現今の専用ルータでは、RIB (Routing Information Base) と転送エンジン (forwarding engine) は非常に近くにある。例えばだが、どちらもカーネルの中で扱われていたりする。しかし Linux は専用ルータではないので、RIB と FIB (Forwarding Information Base) を別々に扱わざるを得ない。 RIB はユーザ空間、 FIB はカーネル空間にあるわけだ。これが足かせとなり、 RIB の高速検索はかなりリソースに厳しい処理となってしまう。ルーティング・レルムは Linux におけるその解決策であり、柔軟な対応と機能の充実をシステムにもたらしている。
Linux でのレルムは、BGP など、大量のルート情報を遣り取りするプロトコルと組み合わせての使用が想定される。そうすれば、ルーティングデーモンはプレフィクスや AS PATH、送信元などに基づいてそれらをソートし、別々のレルムに仕分けすることができる。 realm は数値だが、 /etc/iproute2/rt_realms ファイルで定義された名前を使うことも可能だ。
Table 10-26. Realmマッチオプション
| マッチ | --realm |
| カーネル | 2.6 |
| 例 | iptables -A OUTPUT -m realm --realm 4 |
| 説明 | このオプションはレルムナンバーと、場合によってはマスクによるマッチを行う。数値以外で指定された時には、ファイル /etc/iproute2/rt_realms を照会して数値への解決も行おうとする。名前によるレルム指定時にはマスクは指定できない。エクスクラメーションマークを使って意味を反転することも可能で、その場合の例は --realm ! cosmos のようになる。[訳者註: マスクの指定方法が原文に抜けているので補足。書式は REALM/MASK] |
10.3.19. Recentマッチ
recent マッチは、かなり幅広い使い方のある複雑なマッチング機構で、前に行われたマッチを手掛かりにしてパケットを選定することができる。例えば、今こちらから IRC コネクションを張ったとしよう。その IPアドレスをホストのリストに記録しておけば、別のルールで、先ほどのパケットから数えて 15秒間だけその IRC サーバからの ident 要求を許可する、といったことができるのだ。
このマッチをつぶさに見ていく前に、その動作の仕組みを分かってもらえるかやってみることにする。まず前提として、 recent マッチを活用するには複数のルールが要る。 recent マッチは最近発生したイベントについてのリストを何種類か使う。デフォルトで使用されるリストは DEFAULT リストだ。リストには set オプションを使ってエントリを追加するのだが、或るルールが完全にマッチする度に (set オプションではマッチは常に真となる)、当該の「最近 (recent) リスト」に set オプションでエントリをさらに追加していく。リスト上の各エントリには、タイムスタンプと、その set オプションのトリガーとなったパケットの送信元 IPアドレスが記録されている。ここまで準備が整えば、それらの情報を頼りに recent マッチの様々なオプションを使ってマッチを行ったり、エントリのタイムスタンプを更新するといったことができる。
最後に付け加えておくと、もし何かの理由で或るエントリをリストから削除したい場合には recent モジュールの提供する remove マッチで削除ができる。他のモジュールと同様、 recent マッチを使用するには recent モジュールをロード (-m recent) しなければならない。では、使用例を云々する前にまず、オプションの全てを見てみよう。
Table 10-27. Recentマッチオプション
| マッチ | --name |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m recent --name examplelist |
| 説明 | name オプションは使用するリストの名前を指定する。デフォルトでは DEFAULT リストが使用されるが、 DEFAULT リストは、複数のリストを使用している時にはおそらく用のないリストだ。 |
| マッチ | --set |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m recent --set |
| 説明 | このオプションを使うと name 済みのリストへエントリを追加できる。リストエントリには、そのルールのトリガーとなったホストの送信元 IPアドレスとタイムスタンプが格納される。このマッチは ! 記号を前置きすれば偽を返すが、そうしない限り常に真を返す。 |
| マッチ | --rcheck |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m recent --name examplelist --rcheck |
| 説明 | --rcheck オプションは指定のリストにそのパケットの送信元 IPアドレスが登録済みかどうかをチェックする。あれば真を返すし、なければ偽を返す。 ! 記号を使えばオプションの意味は反転する。その場合、送信元 IPアドレスがリストになければ真を返し、あれば偽を返す。 |
| マッチ | --update |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m recent --name examplelist --update |
| 説明 | このマッチは、その送信元情報の組み合わせが指定したリストにあれば真となるとともに、そのリストの最終観測時間を更新する。このマッチも前置きの ! 記号で反転でき、例えば ! --update のようにも指定できる。 |
| マッチ | --remove |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --remove |
| 説明 | このマッチを発すると、リストからそのパケットの送信元アドレスを探し、見つかれば真を返す。と同時に、リストから当該のエントリを削除する。これも ! 記号で反転か可能だ。 |
| マッチ | --seconds |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --check --seconds 60 |
| 説明 | このオプションが使えるのは --check または --update マッチと併用した時だけ。 --seconds マッチを使うと、「最近リスト」の最終観測時間カラムが最後に更新されてからの時間を指定することができる。もしも最終更新時間カラムが指定秒以上に古ければ [訳者註: 等しい時は含まない]、マッチは偽を返す。その点を除いては、リストにその送信元アドレスがある時だけ真を返すという通常の振る舞いは変わらない。 |
| マッチ | --hitcount |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --check --hitcount 20 |
| 説明 | --hitcount マッチは --check もしくは --update と一緒に使用しなければならない。このマッチを使用すると、指定回数以上観測された [: イコール含む] パケットにだけマッチするようになる。 --seconds マッチと併用した場合には、指定時間内に指定回数以上のヒットカウントのあったパケットだけがマッチする。マッチの前に ! を置けば意味を反転できる。反転を --seconds と組み合わせた時の意味は、指定時間内に N 回以下しか観測されなかったパケットということになる。 --hitcount と --seconds を両方とも反転した場合、今から遡って S 秒以内にパケットが N 回以下しか観測されなかった時に真となる。 |
| マッチ | --rttl |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --check --rttl |
| 説明 | --rttl マッチを使うと、「最近リスト」にエントリを登録するきっかけになった元パケットと今取り扱っているパケットの TTL の値が同じかどうかを突き合わせることができる。これを利用すれば、 recent マッチで、送信元アドレスを詐称して正規ユーザによるサーバ利用を妨げている奴はいないか、調べることができる。 |
| マッチ | --rsource |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --rsource |
| 説明 | --rsource マッチは送信元のアドレスとポートを「最近リスト」へ保存するよう recent マッチに指示を与える。これが recent マッチのデフォルトの挙動だ。 |
| マッチ | --rdest |
| カーネル | 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m recent --name example --rdest |
| 説明 | --rdest マッチは recent マッチに現在の宛先アドレスとポートを保存させる。その意味で --rsource マッチのちょうど反対だ。 |
recent マッチの使い方を表す小さなサンプルスクリプトを作った。 Recent-match.txt セクションにある。
簡単に言うと、これは netfilter の備えるステート機構の、粗末な代用品だ。現バージョンは基本的に http サーバを想定しているが、おそらくどんな TCP コネクションでも機能するだろう。この中ではまず、 http-recent, http-recent-final というふたつのチェーンを作成している。 http-recent チェーンはコネクションの開始段階と実際のデータ送受信で使われ、 http-recent-final チェーンは最後の FIN, FIN/ACK ハンドシェイクで使用される。
 | これはビルトインのステート機構に比べれば非常に出来の悪い代用品で、ステート機構で処理できる全てのケースを扱えるわけではない。とはいえ recent マッチで何ができるかを俯瞰的にさらってみるには良い教材だ。実際の運用環境で使ってはいけない。動作が遅い上に、特殊なケースとなるとうまく対応できないので、あくまでもサンプルとしてのみ使っていただきたい。 例えば、接続しようとしたポートがクローズしていた時や、同期的でない FIN ハンドシェイク (コネクションの片端は接続をクローズしているがもう一方の相手はデータをまだ送り続けている時) などには対応できないのだ。 |
ではサンプルのルールセットの中のパケットの道のりを追ってみよう。まずは、ひとつのパケットが INPUT チェーンに入ってくる。そして、我々はそれを http-recent チェーンに送り込む。
最初のパケットは SYN パケットであり、 ACK,FIN や RST ビットは立っていないはずである。よって --tcp-flags SYN,ACK,FIN,RST SYN の行でマッチさせている。この時 -m recent --name httplist --set の行で httplist にこのコネクションを登録する。そして最終的にこのパケットを受け入れる。
第1パケットの次に我々は、 SYN パケットの受領を示す SYN/ACK パケットを受け取るはずだ。それは --tcp-flags SYN,ACK,FIN,RST SYN,ACK の行で捕捉できる。もちろん FIN や RST は問題外である。この時には -m recent --name httplist --update を使用して httplist を更新し、最終的にパケットを受け入れる。
そろそろ、サーバの送った SYN/ACK を了解する締めの ACK パケットが、コネクションの始動者からやってくるはずだ。このコネクション段階では SYN, FIN, RST は異常である。よって、捕捉のための命令は --tcp-flags SYN,ACK,FIN,RST ACK のようになる。ひとつ前のステップと全く同様に、リストをアップデートし、パケットを受け入れる。
もうデータの送受信がいつでも始められる状態だ。今、コネクションの中で SYN パケットが現れるはずはなく、こちらの送ったデータに対する了解を示す ACK パケットなら見られるだろう。こうしたパケットを観測する度に、我々はリストを更新して受け入れていく。
送受信の終わり方は 2種類ある。単純なのは RST パケット。 RST は即座にコネクションをリセットして断ち切る。 FIN の場合には、相手方がFIN,ACK でそれに答えてコネクションに幕を下ろし、 FIN を送った方のホストはもうデータを送ることはできなくなる。ただし、 FIN を受け取った方のホストはまだデータを送ることが可能だ。かくして、我々はこのコネクションを「最終 (final)」ステージへと引き渡し、ここから先はそちらの受け持ちとなる。
http-recent-final チェーンでは、パケットがまだ httplist にあるかどうか確認し、あれば、そのパケットを http-recent-final チェーンへ送る。そこで、 httplist からコネクションのエントリを削除し、代わりに http-recent-final リストに登録する。一方、コネクションが既に削除されて http-recent-final リストに登録替えされていたら、パケットは http-recent-final2 へ送る。
http-recent-final2 チェーンでは、まだ締め切っていない方のホストがデータを送りきってコネクションをクローズするのを待つ。それを見届けたら、コネクションをエントリから完全に削除する。
ご覧のように recent のリストは結構複雑な様相を呈するが、必要となれば相当いろいろなことを可能にしてくれる。ただし、車輪をもう一度発明しようなどとは思わないように。必要とする機能が既に実装されているなら、独自の解決策を作ろうとするよりも、既存のものを使うほうが得策だ。
10.3.20. Stateマッチ
state マッチ拡張は、カーネルの備えるコネクション追跡コードを利用して働く。ステートマッチは、コネクション追跡機構にそのパケットのコネクション追跡ステートを問い合わせる。これによって、我々は当該の接続がどういう状態 (state) にあるかを知ることができ、 ICMP や UDP などステートレスなプロトコルも含め、ほとんどあらゆるプロトコルへの対処が可能となる。いかなる場合にも、コネクションにはデフォルトタイムアウトが与えられ、やがてはコネクション追跡データベースから破棄される。このマッチを利用するには、ルールには明示的に -m state 句を入れなくてはならない。それで、 state という新たなマッチが利用可能となる。ステートマッチのコンセプトは、チャプター ステート機構 の中で余すところなく語られている。ここで詳述するには手に余る話題だ。
Table 10-28. Stateマッチオプション
| マッチ | --state |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -m state --state RELATED,ESTABLISHED |
| 説明 | このマッチオプションは、 state マッチに対して、マッチするためにはパケットがどういう状態にあるべきかを指示する。現行で利用できるステートは、 INVALID, ESTABLISHED, NEW, RELATED の 4つ。 INVALID は、パケットがどの把握済みのストリームやコネクションにも属していないか、データかヘッダに異常のあるパケットかのどちらかであることを意味する。 ESTABLISHED は、そのパケットが、既に双方向のパケットが検出された確立済みコネクションの一部であり、パケットが完全に正常であることを意味する。 NEW は、そのパケットが、新しいコネクションを開始する (開始した) ものである、つまり、相互どちらの方向にもパケットがやりとりされたことのないコネクションに属していることを意味する。最後の RELATED は、そのパケットが、新しいコネクションを開始しているが、同時に、既に確立したコネクションに関連しているということを表す。これに当たるのが、例えば、 FTP のデータ搬送や、既存の TCP または UDP コネクションに関係した ICMPエラー などだ。気を付けなければならないのは、 NEW ステートは、新しい接続を開こうとする TCP パケットを、SYN ビット の有無を見て判断しているわけではないという点だ。よって、ファイヤーウォールをひとつしか備えず、他のファイヤーウォールとのロードバランシングも行っていない環境で、 NEW ステートを素のまま使うのは好ましくない。それでもなお、 NEW ステートに利用価値のある場面は出てくる。使い方に関してより詳しく知りたければ、チャプター ステート機構 を読んでいただきたい。 |
10.3.21. TCPMSSマッチ
tcpmss マッチを使用すると、 TCP の最大セグメントサイズ (Maximum Segment Size) に基づいたパケットマッチが行える。このマッチが有効なのは SYN と SYN/ACK パケットのみ。 MSS 値に関する子細に渡る解説は、付録 TCPオプション か、 RFC 793 - Transmission Control Protocol、あるいは RFC 1122 - Requirements for Internet Hosts - Communication Layers などのドキュメントを参照していただきたい。このオプションは -m tcpmss によってロードされ、オプションはひとつだけだ。
Table 10-29. TCPMSSマッチオプション
| マッチ | --mss |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp --tcp-flags SYN,ACK,RST SYN -m tcpmss --mss 2000:2500 |
| 説明 | --mss オプションは tcpmss マッチに対して、ヒットさせる最大セグメントサイズ を伝える。特定の MSS 値をひとつだけ指定することもできるし、 : で区切って範囲で指定することもできる。他のマッチと同じく ! 記号を使って下記のように反転させることも可能だ。 -m tcpmss ! --mss 2000:2500 この例は 2000 から 2500 までを除く全ての MSS 値にマッチする。 |
10.3.22. TOSマッチ
TOS マッチは、パケットの TOS フィールドに基づいてパケットマッチを行う時に使用する。 TOS とは Type Of Service のことで、 IP ヘッダの中にあり、8ビットから成っている。このマッチはルールに -m tos を加えることにより明示的にロードされる。 TOS は通常、経由するホストに対して、そのストリームの優先順位や中身についての連絡を行う (本当はそのようなことは行わないのだが、できるだけ早く送るべきだとか、可能な限り大きなペイロードが必要だといった、ストリームに要求される特別な要件を通知する)。これらの値がどう扱われるかは、ルータや管理者毎で大きく異なる。まったく関知しないものが大半だが、その一方で、当該のパケットとそれによってもたらされるデータに対して、でき得る限りの善処を尽くすものもある。
Table 10-30. TOSマッチオプション
| マッチ | --tos |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A INPUT -p tcp -m tos --tos 0x16 |
| 説明 | このマッチは上記のような使い方をする。 TOS フィールドとそこに持つ値に基づいてパケットのマッチを行う。用途は様々だが、例えば、 iproute2 や、 Linux の高度ルーティング機能と組み合わせて、後で利用するためにパケットに mark を付けるといった使い方がある。引数には、16進、10進の数字の他、 'iptables -m tos -h' で得られる名称のどれかひとつを指定できる。執筆時点では、その出力には以下のものが含まれていた: Minimize-Delay 16 (0x10), Maximize-Throughput 8 (0x08), Maximize-Reliability 4 (0x04), Minimize-Cost 2 (0x02), Normal-Service 0 (0x00)。 Minimize-Delay は、パケットを渡す際の遅延 (daley) を最小限にすることを表し、これを必要とする標準的なサービスには、 telnet、SSH、FTP-control がある。 Maximize-Throughput は、できる限り高スループットの経路を探せ、の意味で、標準的プロトコルでは FTP-data がこれに当たる。 Maximize-Reliability は、コネクションの信頼性をできる限り高く、そして、できる限り信頼性の高いラインを使うことを意味しており、例としては BOOTP と TFTP がある。 Minimize-Cost は、パケットがリンクを辿ってクライアントあるいはサーバまで至る間のコストを最小限にすること、例えば、通過コストの最も小さくてすむ経路を見つけることを表す。これを使用する一般的なプロトコルに、RTSP (Real Time Stream Control Protocol) をはじめとするビデオ/ラジオプロトコルがある。最後の Normal-Service は、特別の要件を持たないあらゆる一般的プロトコルを指す。 |
10.3.23. TTLマッチ
TTL マッチは、 IP ヘッダに存在する TTL (Time To Live) フィールドに基づいてパケットのマッチを行うのに用いる。 TTLフィールド は 8ビットのデータを持ち、クライアント・受け取りホスト間で経由するホストによって中継が行われる度に、ひとつずつ減らされていく。 TTL が 0 に達すると、 ICMP のタイプ 11 コード 0 (TTL equals 0 during transmit) または コード 1 (TTL equals 0 during reassembly) が、パケットを送信してきたホストへ発信され、この障害が通知される。このマッチは TTL に基づいたマッチを行うだけであり、パケットにいかなる変更を加えるものでもない。なお、後者はマッチ全般に当てはまる事柄だ。このマッチをロードするには、ルールに -m ttl を加える必要がある。
Table 10-31. TTLマッチオプション
| マッチ | --ttl-eq |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m ttl --ttl-eq 60 |
| 説明 | このマッチはそのものずばりの TTL の値を指定する時に使う。引数は数字で、それとパケットの中の値との照合を行う。意味の反転など、その他の要素は使えない。このマッチは、ローカルネットワークのデバグなどに活用できる。例を挙げるとすれば、LAN 上のホストがインターネット上のホストへ接続できない時や、トロイの木馬による進入路を検査する時などだ。使い道はかなり限られているが、有効活用は発想次第。例えば、不適切な TTL 値を送ってくるホスト (TCP/IP スタックの不適切な実装や単なる設定ミスが原因だろう) の検知が挙げられる。 |
| マッチ | --ttl-gt |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m ttl --ttl-gt 64 |
| 説明 | このオプションは、指定した値よりも大きな TTL に対してマッチを行う時に使用する。指定可能な値は 0 から 255 までで、反転は通用しない。例えば、或る特定の TTL を超えるパケットをマッチさせて一律の値へと矯正する、といった使い方が考えられる。ポリシーに反して複数のマシンを繋いでいるやつがいたら分かるようにと ISP の仕掛ける極単純な偵察システムを掻い潜るのに使えるだろう。 |
| マッチ | --ttl-lt |
| カーネル | 2.3, 2.4, 2.5, 2.6 |
| 例 | iptables -A OUTPUT -m ttl --ttl-lt 64 |
| 説明 | --ttl-lt マッチは、指定値よりも小さな TTL をマッチさせるのに使う。 --ttl-gt マッチとほぼ同じだが、既に述べたように、こちらは TTL の小さい時にマッチする。使い方の面でも --ttl-gt と同様だが、単純に、自分のネットワークから出て行くパケットの TTL を揃えるという使い方もある。 |
10.3.24. Uncleanマッチ
unclean マッチにはオプション引数はなく、明示的にロードさえすれば利用できる。このオプションは実験的なものとされており、常に動作するとは限らない上、汚染された (unclean) パケットや異常を何から何まで捉えられるわけではないという点にも気を付けなければならない。 unclean マッチは、ヘッダやチェックサムがおかしい場合など、異常の認められるパケットをマッチさせようとする。例えば、コネクションを DROP するのに用いたり、異常、或いは悪意のあるストリームを検知するといった目的に利用可能だ。ただし、正規のコネクションまでもが切断される可能性のあることもまた、承知しておかなければならない。