Linux IPCHAINS-HOWTO Rusty Russell v1.0.8, Tue Jul 4 14:20:53 EST 2000 日本語訳: JF Project (jf@linux.or.jp) v1.0.1j Nov. 21, 2000 この文書は、Linux 向けの拡張された IP ファイアウォーリングチェインソフ トウェアをどのように入手し、インストールし、設定し、そして、これを活用 するアイディアの幾つかを詳述することを目的とします。 ______________________________________________________________________ 目次 1. 始めに 1.1 何? 1.2 なぜ? 1.3 どうすれば? 1.4 どこ? 2. パケットフィルタリングの基礎 2.1 パケットフィルタとは何をするもの? 2.2 なぜ? 2.3 どうやって? 2.3.1 パケットフィルタリング機能を有効にしたカーネル 2.3.2 ipchains 2.3.3 フィルタ規則を恒久的にするには 3. もう、混乱して来た! ルーティングだの、マスカレーディングだの、ポートフォワーディングだの、自動フォワーディング(ipautofw)だのって…。 3.1 Rusty のマスカレーディングに関する 3つの指針 3.2 自発的な宣伝: WatchGuard で規制する 3.3 ファイアウォール的動作に共通な設定 3.3.1 ローカルネットワーク: 伝統的なプロキシ 3.3.2 プライベートネットワーク: 透過的なプロキシ 3.3.3 プライベートネットワーク: マスカレーディング 3.3.4 パブリックネットワーク 3.3.5 制限された内部サービス 3.4 マスカレーディングに対するその他の情報 4. IP ファイアウォーリングチェイン 4.1 どのようにパケットがフィルタを通過するのか 4.1.1 ipchains を使う 4.1.2 あなたのコンピュータが起動する時に見るもの 4.1.3 単一のルールでの操作 4.1.4 フィルタリングの仕様 4.1.4.1 ソースと宛先 IP アドレスの指定 4.1.4.2 否定の指定 4.1.4.3 プロトコルの指定 4.1.4.3.1 UDP と TCP ポートの指定 4.1.4.3.2 ICMP タイプとコードの指定 4.1.4.4 インターフェイスの指定 4.1.4.5 TCP SYN パケットのみを指定する 4.1.4.6 フラグメントの処理 4.1.5 フィルタリングの副次的効果 4.1.5.1 ターゲットの指定 4.1.5.2 パケットのログ記録 4.1.5.3 サービスの型を操作する 4.1.5.4 パケットのマーキング 4.1.5.5 チェインの操作 4.1.5.6 新しいチェインを作る 4.1.5.7 チェインを削除する 4.1.5.8 チェインを空にする 4.1.5.9 チェインの内容をリストアップする 4.1.5.10 カウンターを(ゼロに)リセットする 4.1.5.11 ポリシーを設定する 4.1.6 マスカレーディングの操作 4.1.7 パケットをチェックする 4.1.8 一度に複数のルールと何が起こるのかを見る 4.2 実例集 4.2.1 ipchains-save を使う 4.2.2 ipchains-restore を使う 5. その他の情報 5.1 ファイアウォールルールをどのように構築するか 5.2 フィルタリングで破棄してはいけないパケット 5.2.1 ICMP パケット 5.2.2 DNS (ネームサーバー) への TCP 接続 5.2.3 FTP の悪夢 5.3 Ping of Death を排除する 5.4 Teardrop と Bonk を排除する 5.5 フラグメント爆撃を排除する 5.6 ファイアウォールルールを変更する 5.7 IP 偽装保護(IP Spoof Protection)を、どのように設定したらよいですか? 5.8 最新のプロジェクト 5.8.1 SPF: ステートフルパケットフィルタリング 5.8.2 Michael Hasenstein の ftp-data ハック 5.9 今後の課題 6. 一般的な問題 6.1 ipchains -L を使うとフリーズします! 6.2 反転ができません! 6.3 Masquerading または Forwarding が動きません! 6.4 -j REDIR が動きません! 6.5 ワイルドカードインターフェースが動きません! 6.6 TOS (Type of Service) が動きません! 6.7 ipautofw とipportfw が動きません! 6.8 xosview が壊れています! 6.9 `-j REDIRECT' で Segmentation エラーになります! 6.10 マスカレーディングのタイムアウト値を設定できません! 6.11 IPX をファイアウォールしたいです! 7. 実用的な例 7.1 構成 7.2 目的 7.3 パケットフィルタリングを行う前に 7.4 パケットを通過させるためのパケットフィルタリング 7.4.1 forward チェインからジャンプさせる 7.4.2 icmp-acc チェインを定義する 7.4.3 GOOD (内部ネットワーク) から DMZ (サーバネットワーク) 7.4.4 BAD (外部ネットワーク)から DMZ (サーバネットワーク) 7.4.5 GOOD (内部ネットワーク)から BAD (外部ネットワーク) 7.4.6 DMZ から GOOD (内部ネットワーク) 7.4.7 DMZ から BAD (外部ネットワーク) 7.4.8 BAD (外部ネットワーク)から GOOD (内部ネットワーク) 7.4.9 Linux マシン自身に対するパケットフィルタリング 7.4.9.1 BAD (外部ネットワーク) インターフェース 7.4.9.2 DMZ インタフェース 7.4.9.3 GOOD (内部ネットワーク)インターフェース 7.5 最後に 8. 付録: ipchains と ipfwadm との違い 8.1 クィックリファレンス一覧 8.2 ipfwadm コマンドの変換例 9. 付録: ipfwadm-wrapper スクリプトを使う 10. 付録: 謝辞 10.1 翻訳 11. 日本語訳について ______________________________________________________________________ 1. 始めに この文書は IPCHAINS-HOWTO です。最新版があるマスターサイトは ``どこ?'' を参照して下さい。 LINUX NET-3-HOWTO も読んだ方がよいでしょう。 IP- Masquerading HOWTO, PPP-HOWTO, Ethernet-HOWTO と Firewall HOTO も面白 いでしょう。 (そして、繰り返しますが、 alt.fan.bigfoot FAQ も)。 (訳注: alt.fan.bigfoot FAQ <- [雪男のニュースグループ、ギャグ?]) パケットフィルタリングについて既に知っている人は、 ``なぜ?'' の章、 `` どうやって?'' の章を読んで、 ``IP ファイアウォーリングチェイン'' の章 の中のタイトルをざっと眺めてみましょう。 ipfwadm から移行したい人は、 ``始めに'' の章、 ``どうやって?'' の章、 そして付録内の ``ipchains と ipfwadm との違い'' の章と、 ```ipfwadm- wrapper' スクリプトを使う'' の章を読みましょう。 1.1. 何? Linux ipchains は Linux IPv4 ファイアウォーリングのコード (主に BSD か らのパクリ)の書き直しであり、ipfwadm の書き直しでもあります。その ipfwadm は、 BSD の ipfw の書き直しでもあると、私は信じています。 Linux バージョン 2.1.102 以降の IP パケットフィルタが、管理に必要で す。 1.2. なぜ? 以前の Linux のファイアウォールのコードは fragment を扱えませんし、 ( 少なくとも Intel 用では) 32 ビットのカウンタしかありませんし、 TCP/UDP/ICMP 以外の仕様のプロトコルを考慮していませんし、アトミック(瞬 間的)に大きく(ルールを)変更することもできませんし、逆ルールを満たせま せんし、いくつか妙な癖がありましたし、管理しにくいものでした(利用者の ミスを招きやすい)。 (訳注: ここで用いられる「アトミック(原文は `atomically')」は、 ipchains というコマンドの名前の由来にもなっているところだと思います。 ユーザ定義チェインに複数のルールを定義しておき、それを既存のチェインに 追加したり、或は既存のチェインを新しく定義したチェインと置換すること で、一瞬にしてファイアウォールの作用を変更することができます。) 1.3. どうすれば? 現在、カーネルのコードの主流は 2.1.102 以降です。 2.0 カーネルシリーズ では、 web ページからパッチをダウンロードする必要があります。もし、お 手持ちの 2.0 カーネルが web 上にて得られるパッチよりも新しいならば、そ の古いパッチは多分 OK でしょう。 2.0 カーネルの該当部分はおおよそ安定 しています。(例えば、 2.0.34 カーネルのパッチは 2.0.35 カーネルにも しっかり当てられます) 2.0 パッチは ipportfw と ipautofw パッチとの互換 性がないので、 ipchains 特有の機能を本当に必要としないならば、パッチの 導入はお薦めしません。 1.4. どこ? 公式ページは3箇所あります。 Penguin Computing に感謝します。 the SAMBA Team に感謝しま す。 Jim Pick に感謝します。 バグ報告、議論、開発、使い方を話し合うメーリングリストがあります。メー リングリストへの入会には、メッセージに ``subscribe ipchains-list'' を 書いて、 east.balius.com にメールして下さい。メーリングリストのメン バー全員にメールを出すには、 east.balius.com の ipchains-list を使って 下さい。 2. パケットフィルタリングの基礎 2.1. パケットフィルタとは何をするもの? ネットワークを通る全てのトラフィックは、パケットの形で送り出されます。 例えば、このパッケージ(50Kバイトはあるでしょう)をダウンロードすること で、1460バイトのパケット36個ほどを受信することになるでしょう(実際には そのときどきによって個数やサイズは異なります)。 (訳注: 現在ではこの文書は100KBを越えています:)) 各パケットはそれがどこに向けられたものかを記述する部分から始まり、どこ から来たものか、それからパケットの種類と管理上必要な詳細内容を含んでい ます。パケットのこの開始部分は、ヘッダと呼ばれています。また、伝送され ている実際のデータを含んだパケットの残りの部分は、通常ボディと呼ばれて います。 ウェブ・トラフィック、メールとリモートログインのために使われるいくつか のプロトコル(例えば TCP)は `接続(コネクション)'とよばれる概念を使いま す。実際のデータパケットが送り出される前に、`私は、接続したい'、`OK'、 そして`ありがとう'といった、(特別なヘッダを伴う)色々なセットアップ・パ ケットを交換します。 パケット・フィルタは、パケットのヘッダを見て、そのパケット全体をどのよ うに取り扱うかを決定する小さなソフトウェアです。パケットは拒否(deny)( すなわち、受信しなかったかのように、パケットを捨てる)ことに決められる かもしれないし、許可(accept)(すなわち、パケットを通過させる)することに なるかもしれないし、パケットを返却(reject)("拒否"と似ているけれど、パ ケットの発信元にそのことを通知する)するかもしれません。 Linux においては、パケット・フィルタリングはカーネルに組み込まれていま す。そして、パケットの取扱いに関して少しばかりトリックを仕掛けることが できますが、その基本的な規則はあくまでヘッダを見て、パケットの取り扱い を決定するというものです。 2.2. なぜ? コントロール。セキュリティ。監視。 コントロール: あなたが Linux ボックスを内部のネットワークと別のネットワーク(例 えば、インターネット)を繋ぐために使っているなら、 あなたには、特 定のトラフィックだけ許可して、他のものを許さないようにするチャン スがあります。例えば、パケットのヘッダーにはあて先アドレス が含 まれていて、外部ネットワークのとある所へ向かうパケットを拒否する ことができます。別の例として、Netscape を使って Dilbert のアーカ イブ (訳注: Dilbert というエンジニアが主人公の風刺漫画のサイト、 ちなみに dilbert の意味は'ばか') にアクセスする場合です。ページ には doubleclick.net の広告があり、 Netscape はそれをいそいそと ダウンロードするために私の時間を浪費します。パケットフィルターに doubleclick.net 所有のアドレスからのどんなパケットも許可しないよ うに指示すれば問題は解決します(もっといい方法がありますけれど: Junkbuster (訳注: http://internet.junkbuster.com ) を見て下さい)。 セキュリティ: あなたの Linux ボックスがインターネットの混沌と、秩序正しいあな たのすてきなネットワークの間にある唯一の物なら、すばらしいこと に、あなたは殴りにやって来る者をドアのところで制限することができ ます。例えば、あなたのネットワークから出て行くものは何でも許すよ うにして、悪意のある外部からのよく知られた `Ping of Death' 攻撃 を警戒するようにできます。別の例として、あなたの Linux ボックス に、たとえ全てのアカウントにパスワードが付いているとしても、外部 の者が telnet してくることを望まないかもしれません。たぶん、あな たは(大抵の人々のように)インターネットをただ眺めていたいだけで、 サーバーに(好むと好まずにかかわらず)なりたくないのです。単純に、 パケットフィルターで接続を開始するパケットの流入を拒否して、だれ にも接続されないようにして下さい。 (訳注: "死のping" 異常に長大な ICMP パケットなどをネットワーク接 続されたコンピュータに送りつけて、システムクラッシュやサービスの 停止を引き起こす攻撃のこと。) 監視: ときどきローカルネットワーク中に環境設定の悪いマシンがあり、外の 世界にパケットが漏れ出るようになっていることがあります。すばらし いことに、パケットフィルターは何か異常なことが起こったときにあな たに知らせてくれます。それによって何らかの対処ができることを知る か、あるいはただ単に自分が詮索好きな性格だと知るだけかもしれませ ん。 2.3. どうやって? 2.3.1. パケットフィルタリング機能を有効にしたカーネル 新しい IP ファイアウォール・チェーン機能を持つカーネルが必要です。今動 作しているカーネルが、この機能を組み込んだものかどうか判断するには、 /proc/net/ip_fwchains を探してみましょう。これが存在するならば、既に組 み込まれています。 (訳注: 2.2.x以降のカーネルをお使いの場合は、大抵既に組み込まれているこ とでしょう。) もしそうでなければ、あなたは IP ファイアウォール・チェーンを持つカーネ ルを作る必要があります。最初に、あなたが欲しいカーネルのソースをダウン ロードしましょう。あなたのカーネルが バージョン 2.1.102 以降のものな ら、現在主流のカーネルであるので、改めてパッチを当てる必要はありませ ん。そうでない時には前出の Web ページからパッチを入手して適用し、そし て次に示すような設定でカーネルを構成して下さい。もし、あなたがこれをす る方法を知らなくても、慌てないで Kernel-HOWTO を読みましょう。 (訳注: Kernel-HOWTOの邦訳は http://www.linux.or.jp/JF/JFdocs/Kernel- HOWTO.html にあり ます。) あなたが2.0-シリーズのカーネルに設定する必要があるコンフィグレーション オプションは、以下の通りです: ______________________________________________________________________ CONFIG_EXPERIMENTAL=y CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_CHAINS=y ______________________________________________________________________ 2.1 か 2.2 のシリーズ・カーネルの場合は次の通りです: ______________________________________________________________________ CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y ______________________________________________________________________ ツールである ipchains プログラムは、カーネルに対してどんなパケットを フィルタするべきかについて通知するためのものです。あなたがプログラマで あるか、奇特な人間でない限り、これがパケットフィルタリングを制御する方 法となります。 2.3.2. ipchains ipchains ツールは、カーネルのパケット・フィルタリングに関するセクショ ンからルールを挿入したり削除したりします。これは、あなたがたとえ何を設 定しても、それが再起動によって消えてしまうことを意味しています。次回、 Linux がブートされる際に、それらを確実に戻すする方法については、次の節 ``フィルタ規則を恒久的にするには'' を参照して下さい。 ipchains は以前までIPファイアウォールを実現するために使われていた ipfwadm と置き換えられることになります。役に立つスクリプトのセットが、 次の ipchains のアドレスから入手可能です: http://netfilter.filewatcher.org/ipchains/ipchains- scripts-1.1.2.tar.gz これには以前行われていたのと同じようなスタイルでパケット・フィルタリン グを行わせるための ipfwadm-wrapper と呼ばれているシェルスクリプトを含 んでいます。あなたが ipfwadm (ipchainsと比べ、より遅くて、引数、その他 をチェックしない等のもの)を使うシステムをアップグレードする手っ取り早 い方法が欲しくない限り、あなたは多分このスクリプトを使うべきではないで しょう。そういう方にはあまりこの HOWTO も必要とはされないことと思いま す。 ipfwadm 関連の詳細については、付録: ``ipchains と ipfwadm との違い'' や付録: ```ipfwadm-wrapper'スクリプトを使う'' をご覧下さい。 2.3.3. フィルタ規則を恒久的にするには あなたの現在のファイアウォール設定は、カーネルに格納されて、このように 再起動時には失われてしまいます。あなたのルールを恒久的にするために `ipchains-save' と `ipchains-restore' スクリプトを使うことをお勧めしま す。これを使うには、まずあなたのルールを設定して、次のようにコマンドを 実行します(root として実行して下さい): # ipchains-save > /etc/ipchains.rules # スクリプトは次のように作っておきます: #! /bin/sh # パケットフィルタ制御のためのスクリプト # ルールがなければ何もしない [ -f /etc/ipchains.rules ] || exit 0 case "$1" in start) echo -n "Turning on packet filtering:" /sbin/ipchains-restore < /etc/ipchains.rules || exit 1 echo 1 > /proc/sys/net/ipv4/ip_forward echo "." ;; stop) echo -n "Turning off packet filtering:" echo 0 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -F /sbin/ipchains -X /sbin/ipchains -P input ACCEPT /sbin/ipchains -P output ACCEPT /sbin/ipchains -P forward ACCEPT echo "." ;; *) echo "Usage: /etc/init.d/packetfilter {start|stop}" exit 1 ;; esac exit 0 これが起動時の最初のうちに実行されるようにします。筆者のケース (Debian 2.1) では、 `S39packetfilter' というシンボリックリンクを `/etc/rcS.d' ディレクトリに作ってあります(これは、 S40network の前に実行されます)。 (訳注: 「最初のうち」というのは、起動時、ネットワークに対して通信が可 能となる状態以前に行うという意味です。ネットワークの他のサービスなどが 起動したあとにファイアウオールを設定すると、全く設定されていないわずか な瞬間をついて"悪いやつ"が入り込む危険性があります。) 3. もう、混乱して来た! ルーティングだの、マスカレーディングだの、ポー トフォワーディングだの、自動フォワーディング(ipautofw)だのって…。 この HOWTO は、パケット・フィルタリングについて述べたものです。それは パケットが通過するのを許すかどうかについて決めることを意味しています。 しかしながら、Linuxはいわばハッカー達の遊び場のようなものですので、お そらくそれ以上の機能を実現したいと思うことでしょう。 1つの問題は、本来別な概念であるはずのマスカレーディングと透過的なプロ キシの制御のために同じツール (``ipchains'') が使われることです(現在の Linux での実装では、これらが不自然なかたちでいっしょになっており、あた かもそれらが密接に関連があるという印象を与えてしまいます)。 (訳注: カーネル 2.4.x 系では、これらの機能はさらに統合強化されていま す。それらのカーネルをお使いの方は、Linux 2.4 NAT HOWTO(http://netfilter.kernelnotes.org/unreliable-guides/NAT- HOWTO.html )も ご覧下さい。 JFプロジェクトによる邦 訳(http://www.linux.or.jp/JF/JFdocs/NAT-HOWTO.html )もあります。) マスカレーディングとプロキシについては別々の HOWTO 文書などによって網 羅され、自動フォワーディングとポート・フォワーディング機能は別々のツー ルで制御されます。しかし、多くの人々からそれらについての問い合わせをう けていますので、ここでは一連の一般的とおもわれるシナリオいくつかと、ど のようにすればよいかという設定を提示します。なお、各セットアップのセ キュリティに関する長所については、ここで論議しません。 3.1. Rusty のマスカレーディングに関する 3つの指針 これは、あなたの外部インタフェースが `ppp0' であると仮定しています。 ifconfig コマンドをつかって、あなたの環境に合うように読み替えて下さ い。 # ipchains -P forward DENY # ipchains -A forward -i ppp0 -j MASQ # echo 1 > /proc/sys/net/ipv4/ip_forward 3.2. 自発的な宣伝: WatchGuard で規制する 市販のファイアウォール専用機を購入することもできます。優れた専用機のひ とつとして、WatchGuard 社の FireBox があります。 FireBox が優れている と思うのは、わたしが気に入っているからであり、それが安全だからであ り、Linux ベースで動作しているからです。また、この会社は、ipchains の メインテナンスと、(2.4 系カーネル用の)新しいファイアウォールのコードの ために資金提供してくれたからです。つまり、わたしが皆さんのために作業を している間、 WatchGuard 社は、わたしの生活を支えてくれたわけです。そう いうわけで、彼らの製品についても御一考願います。 http://www.watchguard.com (訳注: WatchGuard社の日本国内のリセラーも、このページから手繰ることが できます。) 3.3. ファイアウォール的動作に共通な設定 あなたは、 littlecorp.com というドメイン名でシステムを動かしています。 そして内部ネットワークを持ち、インターネットに対して、IPアドレスが 1.2.3.4 である (firewall.littlecorp.com) というコンピュータに1回線のダ イヤルアップ(PPP)コネクションを持っています。あなたはイーサネットによ るローカルネットワークを構築しており、あなたの個人用コンピュータは "myhost" と呼ばれています。 このセクションでは、一般的とおもわれるいくつかの配置例での設定について 詳しく説明します。それらは微妙に異なりますので、注意深く読み進めて下さ い。 3.3.1. ローカルネットワーク: 伝統的なプロキシ このシナリオでは、ローカルネットワークからのパケットは、インターネット を行き来することはありません。ローカルネットワークの IP アドレスは、 RFC1918 にてプライベートなインターネット環境のために用意されているアド レス(すなわち 10.*.*.*, 172.16.*.*-172.31.*.* または 192.168.*.*)を割 り当てなければなりません。 インターネットに接続する唯一の方法はファイアウォールに接続することで、 このコンピュータが両方のネットワーク(訳注: インターネットとローカル ネットワーク)に直接つながっています。このファイアウォールの上でプロキ シと呼ばれるソフトを動かすことになります(これは FTP 、ウェブ・アクセ ス、 telnet 、 RealAudio 、 Usenet News や他のサービスについて、"代理" として働きます)。詳細については Firewall HOWTO を見ましょう。 (訳注: "Firewall HOWTO" の原文は http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html にあります。 JFプ ロジェクトによる邦訳はまだ作業中です。) あなたがインターネットへのアクセスで望むサービスについては、必ずファイ アウォール上のプロキシでサポートされたサービスでなければなりません(し かし、後述の ``制限された内部サービス'' を参照して下さい)。 例: プライベートネットワークからインターネットへのウェブ・アクセスを許 す 1. プライベートネットワークは、192.168.1.*を割り当てられた複数の番地か らなり、IPアドレスが192.168.1.100は"myhost"に、ファイアウォールの イーサネット・インタフェースには192.168.1.1が割り当てられています。 2. ウェブ・プロキシ(例えば"squid")は、ファイアウォールの上にインストー ルされておりポート8080で動いています。 3. プライベートネットワークのNetscapeは、プロキシとしてファイアウォー ルのポート8080を使うように設定されています。 4. DNSは、プライベートネットワークの中で設定される必要はありません。 5. DNSは、ファイアウォールの上で設定される必要があります。 6. デフォルト・ルート(別名、ゲートウェイ)は、プライベートネットワーク の中で設定される必要はありません。 myhost 上の Netscape から、 http://slashdot.org のページを見る 1. Netscape はファイアウォールのポート8080に接続し、 myhost 上のポー ト1050を使って "http://slashdot.org" のウェブ・ページを見るように ファイアウォールに依頼します。 2. プロキシは "slashdot.org" という名前を調べて、 "207.218.152.131" と いうIPアドレスを得ます。それからファイアウォールの外部インタフェー ス(訳注: ppp0 など)の上でポート1025を使って、その IP アドレスに対し てウェブ・サーバ(ポート80)でウェブ・ページを要求します。 3. 相手のウェブ・サーバに対する接続からウェブ・ページを受け取ると、そ れはNetscapeへの接続へデータがコピーされます。 4. Netscapeは、ページを表示します。 つまり、 slashdot.org の側から見ると、 1.2.3.4 (ファイアウォールの PPP インタフェース)ポート1025から、 207.218.152.131 (slashdot.org)ポート80 まで接続されることになります。 myhost の側から見ると、 192.168.1.1 ( ファイアウォールのイーサネット・インタフェース)のポート8080と 192.168.1.100(myhost)のポート1050が接続されることになります。 3.3.2. プライベートネットワーク: 透過的なプロキシ このシナリオでは、ローカルネットワークからのパケットは、インターネット を行き来することはありません。ローカルネットワークの IP アドレスは、 RFC1918 にてプライベートなインターネット環境のために用意されているアド レス(すなわち 10.*.*.* 、 172.16.*.*-172.31.*.* または 192.168.*.*)を 割り当てなければなりません。 インターネットに接続する唯一の方法はファイアウォールに接続することで、 このコンピュータが両方のネットワーク(訳注: インターネットとローカル ネットワーク)に直接つながっています。このファイアウォールの上で"透過的 なプロキシ"と呼ばれるソフトを動かすことになりますが、ここではカーネル が出力パケットを外部に送る代りに、透過的なプロキシに送り出すことになり ます (すなわち、偽のルーティングを行うようになります)。 透過的なプロキシを動かすということは、クライアントはプロキシの存在を意 識しなくてもよいということです。 あなたがインターネットへのアクセスで望むサービスについては、必ずファイ アウォール上のプロキシでサポートされたサービスでなければなりません(し かし、後述の ``制限された内部サービス'' を参照して下さい)。 例: プライベートネットワークからインターネットへのウェブ・アクセスを許 す 1. プライベートネットワークは、 192.168.1.* を割り当てられた複数の番地 からなり、 IP アドレスが 192.168.1.100 は myhost に、ファイアウォー ルのイーサネット・インタフェースには 192.168.1.1 が割り当てられてい ます。 2. 透過的なウェブ・プロキシ(squid に対するこの用途のためのパッチがいく つかあると思います。あるいは "transproxy" を試すのもいいかも)はイン ストールされて、ファイアウォールの上でポート8080にて動いています。 3. カーネルは ipchains を使ってポート80の接続をプロキシに向けなおすよ うに指示されています。 4. プライベートネットワークの Netscape は、あたかも直接接続するように 設定します。 5. DNS は、プライベートネットワーク上に設定されている必要があります(す なわち、あなたはファイアウォールの上での「代理」として DNS サーバを 実行する必要があります)。 (訳注: つまり、クライアントからの名前解決の処理をすべてプライベー トネットワーク内の DNS で賄わなければならないということです。さもな いと、名前解決のためのパケットがクライアントからインターネットに出 てしまいます。) 6. ファイアウォールにパケットを送るためにプライベートネットワーク内に デフォルト・ルート(別名、ゲートウェイ)を設定する必要があります。 myhost の Netscape から、http://slashdot.org を見る。 1. Netscapeは、 "slashdot.org" という名前を調べて、 207.218.152.131 と いう IP アドレスを得ます。そして、その IP アドレスに対してポー ト1050にて接続し、ウェブサーバ(ポート80)へページデータを要求しま す。 2. slashdot.org (ポート80)への myhost (ポート1050)からのパケットはファ イアウォールを経由しますが、それらはポート8080の上で待っている透過 的なプロキシに向け直されます。透過的なプロキシは、 207.218.152.131 のポート80(もともとクライアントからのパケットに指定されていた宛先) に対して、(ローカルなポート1025を使って)接続を行います。 3. プロキシはその接続によってウェブ・サーバからページを受け取り、 Netscape に対する接続にそのデータをコピーします。 4. Netscapeは、ページを表示します。 つまり、 slashdot.org から見ると、接続は 1.2.3.4 (ファイアウォールの PPP インタフェース)ポート1025から、 207.218.152.131 (slashdot.org)の ポート80までの間で行われています。 myhost から見ると、 207.218.152.131 (slashdot.org)のポート80に対して、 192.168.1.100 (myhost)ポート1050ま での間で行われています。が、それは実際には透過的なプロキシとやり取りし ていることになります。 3.3.3. プライベートネットワーク: マスカレーディング このシナリオでは、ローカルネットワークからのパケットは、特別な扱いがな ければインターネットを行き来することはありません。ローカルネットワーク の IP アドレスは、 RFC1918 にてプライベートなインターネット環境のため に用意されているアドレス(すなわち 10.*.*.* 、 172.16.*.*-172.31.*.* ま たは 192.168.*.*)を割り当てなければなりません。 プロキシを使う代わりに、 "マスカレーディング" と呼ばれる特別なカーネル 機能を使います。マスカレーディングは、ファイアウォールを経由したかのよ うにパケットを書き換えるので、これらのパケットは常にファイアウォール自 身からきたように見えます。それから、応答を本来の要求元へ送るように書き 換えます。 マスカレーディングはいくつかの "トリッキーな" プロトコルを扱うための個 別のモジュールを持っています。例えば、FTP, RealAudio, Quake などです。 本当に取り扱いが難しいプロトコルのためには、 "自動フォワーディング" 機 能にて、関連したポートの転送を自動的に設定することにより、それらの一部 を取り扱うことができます。詳細については ``ipportfw'' (2.0系カーネル) または ``ipmasqadm'' (2.1系カーネル)を調べてみて下さい。 あなたがインターネットへのアクセスで望むサービスについては、必ずファイ アウォール上のプロキシでサポートされたサービスでなければなりません(し かし、後述の ``制限された内部サービス'' を参照して下さい)。 例: プライベートネットワークからインターネットへのウェブ・アクセスを許 す 1. プライベートネットワークは、 192.168.1.* 上の複数の番地からなり、 myhost には 192.168.1.100 が割り当てられ、ファイアウォールのイーサ ネットインターフェースには 192.168.1.1 が割り当てられています。 2. ファイアウォールは、プライベートネットワークからインターネットの上 のホストのポート80へのすべてのパケットをマスカレードするよう設定さ れています。 3. Netscape は、直接接続するように設定されています。 4. DNS は、プライベートネットワークの上で正しく設定されていなければな りません。 5. ファイアウォールは、プライベートネットワークのためのデフォルト・ ルート(別名、ゲートウェイ)でなければなりません。 myhost の Netscape から、 http://slashdot.org を読む。 1. Netscape は、 "slashdot.org" という名前を調べて、 207.218.152.131 という IP アドレスを得ます。それからローカルなポート1050を使って、 その IP アドレスのウェブ・サーバ(ポート80)に対して接続を行い、ウェ ブ・ページを要求します。 2. slashdot.org (ポート80)への myhost (ポート1050)からのパケットはファ イアウォールに渡され、そこでファイアウォール(ポート65000)の PPP イ ンタフェースから来たかのように書き直されます。 slashdot.org からの 応答パケットを返すことが可能となるように、ファイアウォールは有効な インターネットアドレス(1.2.3.4)を持っています。 3. firewall.littlecorp.com (ポート65000)に対して slashdot.org (ポー ト80)からのパケットが返され、それらを myhost (ポート1050)へ送るため に書き直されます。マスカレーディングを実現するための "魔法" の正体 というのは、つまり、応答が来たときに、それを正しく戻せるように、出 力パケットを書き換えるときに覚えておくということです。 4. Netscapeは、ページを表示します。 slashdot.org の側から見ると、接続は 1.2.3.4 (ファイアウォールの PPP イ ンタフェース)ポート65000から、 207.218.152.131 (slashdot.org)ポート80 まで行われています。 myhost の側から見ると、接続は 207.218.152.131 (slashdot.org)ポート80に対して、 192.168.1.100 (myhost)ポート1050から 行われています。 3.3.4. パブリックネットワーク このシナリオでは、あなたの個人のネットワークはインターネットの一部分で す: パケットは変更されることなく両方のネットワークを流れることができま す。内部ネットワークの IP アドレスは、 IP アドレスのブロックを申請する ことによって割り当てられたもののはずですので、他のネットワークは、どう やってあなたの元へパケットを届けられるかを知っているでしょう。これは継 続的に接続されることを意味しています。 (訳注: 例えば、 INTERNIC や JPNIC などに対する正しい手続きによって得ら れた継続的に使用できる IP アドレスをあなたが所有していなければならない ということです。) この場面でパケット・フィルタリングは、どのようなパケットがあなたのネッ トワークとそれ以外のインターネットとの間でやり取りされるかを制限するた めなどに使われます。例えば、インターネットの他の場所とのパケットのやり 取りをあなたのウェブサーバに対してのみに限定させることができます。 プライベートネットワークからインターネットへのウェブ・アクセスを許す 1. あなたの内部ネットワークは、あなたが登録した IP アドレス・ブロッ ク(1.2.3.* とします)に応じたアドレスが割り当てられています。 2. ファイアウォールは、全てのトラフィックを許すよう設定されています。 (訳注: ここで示されたシナリオは説明のための便宜的なケースです。実際 のケースでは、次の節("内部サービスの限定")で示されたように、サービ スを限定するなど、あなたのネットワークを守るために、出入りするパ ケットについて適切な許可／拒否のための条件を設定しておかなければな りません。) 3. Netscapeは、インターネットに直接接続するように設定されています。 4. DNSは、あなたのネットワークの上で正しく設定されていなければなりませ ん。 5. ファイアウォールは、プライベートネットワークのためのデフォルト・ ルート(ゲートウェイ)でなければなりません。 myhost の Netscape から、http://slashdot.org を見る。 1. Netscapeは、 "slashdot.org" という名前を調べて、 207.218.152.131 と いう IP アドレスを得ます。それからローカルなポート1050を使って、そ の IP アドレスのウェブ・サーバ(ポート80)に対して接続を行い、ウェ ブ・ページを要求します。 2. パケットはあなたのネットワークと slashdot.org の間の他のいくつかの ルーターを通り抜けるのと同じように、あなたのファイアウォールを通り 抜けてやり取りされます。 3. Netscapeは、ページを表示します。 つまり、この場合は 207.218.152.131 (slashdot.org)ポート80と、 1.2.3.100 (myhost)ポート1050の間のただひとつだけの接続が存在します。 3.3.5. 制限された内部サービス 外のインターネットからあなたの内部サービスに対して、ファイアウォール上 でサービスを実行する以外の方法をとることのできるトリックが少しばかりあ ります。それらの方法ではプロキシやマスカレーディングを外部のコネクショ ンのために使用するというアプローチをとります。 最も単純なアプローチは "リダイレクター" (それは与えられたポートの上で 接続を待つという"貧弱な"プロキシです)を動作させることです。それらはあ らかじめ決められた内部ホストとポートに対して接続を行い、データを二つの 接続の間でコピーします。 "redir" プログラムを使った例を示すと、外のイ ンターネット側から見ると、接続はあなたのファイアウォールに対して行われ ます。中のサーバの側から見ると、ファイアウォールとそのサーバに対して接 続が行われるようになります。 もう一つのアプローチ(これには ipportfw のためにパッチを当てられた 2.0 系カーネルか、あるいは 2.1 系以降のカーネルが必要です)はカーネルでの ポート・フォワーディングを使うことです。これは、 "redir" と同じ動作を 別な方法で行います。つまり、カーネルは渡されたパケットに対して、その目 的アドレスとポートを内部のホストとポートに対して向けられたように書き換 えます。外のインターネット側から見ると、あなたのファイアウォールに対し て接続されたように見えます。また、あなたの内部のサーバ側から見ると、イ ンターネット・ホストからサーバまで直接接続されているように見えます。 3.4. マスカレーディングに対するその他の情報 David Ranch はマスカレーディングに関する優れた新しい HOWTO を書きまし た。この HOWTO とは多くの重複部分を持ちますが、次のページから見つける ことができます。 http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html マスカレーディングの公式ページは次のとおりです。 http://ipmasq.cjb.net 4. IP ファイアウォーリングチェイン この章は、あなたの必要に叶うパケットフィルタを構築するために、実際に 知っておかなければならないことを全て説明します。 4.1. どのようにパケットがフィルタを通過するのか カーネルは起動時に 3つのルールリストを保持しています。これらのリストは ファイアウォールチェイン、または単にチェインと呼ばれます。 3つのチェイ ンは、 input, output そして forward と呼ばれます。パケットが (例えば、 イーサネットカードを通じて) 入って来ると、カーネルはそのパケットの「運 命」を決定するために input チェインを使います。パケットがこのステップ で生き残ると、カーネルはパケットを次にどこに送るかを決定します。(これ をルーティングと呼びます。) パケットが他のマシンへ行くと定められている ならば、 forward チェインを調べます。最後に、パケットが出力される前 に、カーネルは output チェインを調べます。 1つのチェインは複数のルールのチェックリストから構成されています。各々 のルールは「もし、パケットのヘッダーがこんなだったら、パケットをこのよ うにしなさい」と指示します。もし、あるルールがパケットとマッチしなけれ ば、チェイン内の次のルールが調べられます。最終的に、調べるルールが無く なったら、カーネルはそのチェインのポリシー(方針)を見て何をするか決めま す。セキュリティ意識の強いシステムでは、このポリシーは普通、パケットを DROP するようにカーネルに指示します。 ASCII アートファンのために、マシンに入来するパケットの完全な通り道をこ こに記します。 (訳注: この文書では日本語文字コードを用いた "JIS アート" を作成してお ります。 いわゆる全角文字と半角文字が混在する "JIS アート" を、 Netscape Navigator/Communicator や Microsoft Internet Explorer で表示させると、 半角文字の幅と全角文字の幅の比が一致しない為に、『ガタガタに崩れた図 面』になってしまいます。 html 版 を見る際には、 lynx や w3m 等のテキストブラウザをお薦めしま す。) ┌──────────────────────────────────┐ │ lo インターフェース│ │ ACCEPT/ │ ↓ REDIRECT ┏━━━━━┓ ┌────┐ ACCEPT│ →チ→正→┌────┐→マ→┃ルーティン┃→│forward │──→┌────┐→ ェ 当 │ input │ ス ┃グの決定 ┃ │チェイン│┌─→│ output │ ッ 性 │チェイン│ カ ┗━━━━━┛ └────┘│┌→│チェイン│ ク │ └────┘ レ │ │ ││ └────┘ サ │ │ ー ↓ │ ││ │ ム │ │ ド ローカルプロセス ↓ ││ ↓ │ ↓ ↓ 外 │ DENY/ ││ DENY/ │ DENY DENY/ し │ REJECT ││ REJECT ↓ REJECT │ │ ││ DENY │ └──────────┘│ └────────────────┘ 以下に各々の段階での説明を逐一記します。 チェックサム: パケットが幾つかの方法にて壊されていないかをテストします。パケッ トが壊れていれば、否定されます。 正当性: 各々のファイアウォールチェインの前にそれらのパケットの正当性の チェックが一つあります。しかし、 input チェインのそれが最も重要 です。幾つかの異常なパケットは規則チェックコードを混乱させる恐れ があります。それらはここで否定されます。 (これが発生すると syslog にメッセージが記録されます。) input チェイン: パケットがテストされる最初のファイアウォールチェインです。チェイ ンの判断が DENY (否定) または REJECT (拒絶) でなければ、パケット の動きは続きます。 デマスカレード(マスカレード外し): パケットが以前にマスカレードされたパケットに対する応答なら、マス カレードが外され、 output チェインまで一気に処理を飛ばします。 IP マスカレードを使っていなければ、意図的に上記の図から消去でき ます。 ルーティングの決定: (パケット中の)宛先フィールドはルーティングコードによって、このパ ケットがローカルプロセスに行くべきなのか (ローカルプロセスの章を 参照して下さい) 、リモートマシンに転送されるのか (フォワードチェ インの章を参照して下さい) を決定するために調べられます。 ローカルプロセス: マシン上で稼働するプロセスはルーティングの決定の段階の後のパケッ トを受け取れると共に、パケットを送信できます。 (送信パケットは ルーティング決定ステップを経て、 output チェインを通過します。) lo インターフェース: ローカルプロセスからのパケットがローカルプロセスに行くものなら ば、それらは `lo' と設定されたインターフェースで output チェイン を通り抜け、再び `lo' インターフェースで input チェインに入りま す。 lo インターフェースは通常ループバックインターフェースと呼ば れます。 ローカル: パケットがローカルプロセスで生成されたものでないなら、 forward チェインがチェックされ、さもなくば、パケットは output チェインへ 行きます。 forward チェイン: このチェインにはこのマシンから他へ転送される全てのパケットが通過 します。 output チェイン: このチェインには出力される直前の全てのパケットが通過します。 4.1.1. ipchains を使う 先ず、この文書にて扱うお手持ちの ipchains のバージョンを、以下のように 参照しましょう: $ ipchains --version ipchains 1.3.9, 17-Mar-1999 注記として、1.3.4 (`--sport' のような長いオプションがありません) か、 1.3.8 以降をお薦めします; これらは大変安定しています。 個々の事項についてのもっと詳しい説明が必要なら、ipchains にはかなり詳 しいマニュアルページ (man ipchains) があります。特に詳しく内容を知りた いなら、プログラミングインターフェース(man 4 ipfw) か、或は 2.1.x の カーネルソース内の net/ipv4/ip_fw.c ファイルを調べると良いでしょう。こ れらは (明らかに) 信頼できます。 ソースパッケージには Scott Bronson による素晴らしいクィックリファレン スカードもあります。 A4判または US レターサイズの PostScript(TM) の両 方があります。 ipchains を使って色々なことができます。先ず、全体のチェインを管理する 操作。あなたは 3つの組み込み済みチェインである、 input, output, forward (これらは削除できません)から始めます。 1. 新しいチェインを作る (-N) 2. 空のチェインを削除する (-X) 3. 組み込み済みチェインのポリシーを変更する (-P) 4. チェイン内のルールをリストアップする (-L) 5. チェインからルールを全て消し去る (-F) 6. チェイン内の全てのルールのパケットとバイトのカウンターをゼロにする (-Z) チェイン内のルールを操作するには様々な方法があります: 1. チェインに新しいルールを追加する (-A) 2. チェイン内のある位置に新しいルールを挿入する (-I) 3. チェイン内のある位置のルールを置き換える (-R) 4. チェイン内のある位置のルールを削除する (-D) 5. チェイン内の適合した最初のルールを削除する (-D) マスカレーディングに関する操作が少ないながらあります。それらを配置する に相応しい場所の要望の為に ipchains に含まれています。 1. 現在のマスカレードされた接続の一覧を表示する (-M -L) 2. マスカレーディングのタイムアウト値を設定する (-M -S) (でも ``マスカ レーディングのタイムアウト値を設定できません!'' を見て下さい。) 最後の (そして恐らく最も便利な) 機能は、指定したパケットが指定したチェ インを通過するなら、そのパケットがどうなるのかを試しにチェックできるこ とです。 4.1.2. あなたのコンピュータが起動する時に見るもの ipchains コマンドが起動される前 (注意: 幾つかのディストリビューション では初期化スクリプト内で ipchains を起動しています) は、組み込み済みの ルール (`input', `forward' と `output') 以外には何もありません。そして 各々のチェインは ACCEPT (許可) のポリシーに設定されています。これは全 てを受け入れることと等価です。 4.1.3. 単一のルールでの操作 ルールを操作すること ― それは ipchains の基本です。ほとんどの場合、普 通、あなたは追加 (-A) と削除 (-D) コマンドを使うことになるでしょう。残 りのコマンド(挿入の -I と置換の -R )は、これらの概念を単純に(機能)拡張 したものです。 各々のルールには、パケットが満たすべき条件のセットと、条件が満たされた ときにすること(‘ターゲット’)を指定します。例えば、IP アドレス 127.0.0.1 からやって来る全ての ICMP パケットを破棄したいとします。その 場合の条件はプロトコルが ICMP で、ソースアドレスが 127.0.0.1 で、ター ゲットは `DENY'(否定) です。 127.0.0.1 は `ループバック' インターフェイスで、それはあなたのマシンが 実際のネットワークに繋がっていなくても存在します。 `ping' プログラムで そのようなパケット (ping は 単純に ICMP タイプ8 (エコー要求)を送り、全 ての協力的なホストは親切にも ICMP タイプ 0 (エコー応答)のパケットでそ れに応えます)を発生させるのに使います。これはテストに役立ちます。 # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # ipchains -A input -s 127.0.0.1 -p icmp -j DENY # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes --- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss # ご覧のとおり最初の ping が成功しています(`-c 1' は ping にパケットを 1 個だけ送るように指示しています)。 次にルールを `INPUT' チェインに追加 (-A) します。ルールの指定は、 127.0.0.1 から (`-s 127.0.0.1') でプロトコル ICMP (`-p icmp') のパケッ トは、DENY へジャンプする (`-j DENY') です。 それから 2番目の ping でルールをテストします。帰って来ない応答を待つの を ping が止めるまで少しの間があるでしょう。 ルールを削除するには 2通りの方法があります。 1番目は、例えば、 input チェインにはルールが 1個だけしかないのを分っている場合では、番号を使っ て以下のように削除できます: # ipchains -D input 1 # INPUT チェインのルール番号 1 を削除。 2番目の方法は -A コマンドをそっくり写して -A を -D に置き換えたもので す。これはルールが複雑なチェインの場合で、例えば、取り除きたいのがルー ル 37 だと探し当てるためにルールを数えたくない場合に有効です。この場 合、次のように使います: # ipchains -D input -s 127.0.0.1 -p icmp -j DENY # -D の書き方は、 -A (または -I か -R) コマンドの時と正確に同じオプショ ンでなければなりません。もし、同一チェイン中に複数のマッチするルールが あったら、最初のものだけが削除されます。 4.1.4. フィルタリングの仕様 これまでに、プロトコルを指定する `-p' オプションと、ソースアドレスを指 定する `-s' オプションを見てきましたが、この他にもパケットの特徴を指定 する様々なオプションがあります。これから、その概要をあますところなくお 話します。 4.1.4.1. ソースと宛先 IP アドレスの指定 ソース (-s) 及び宛先 (-d) IP アドレスは 4通りの指定方法があります。 もっとも一般的な方法は完全に記述された名前(FQDN)を使うことで、例え ば、`localhost' とか `www.linuxhq.com' です。 2番目の方法は `127.0.0.1'のような IP アドレスを指定する方法です。 3番目と 4番目の方法は IP アドレスのグループを指定する方法で、 `199.95.207.0/24' とか `199.95.207.0/255.255.255.0' のように書きます。 両方とも 199.95.207.0 から 199.95.207.255 までのどの IP アドレスも含ま れる指定で、数字のあとの `/' は IP アドレスのどの部分まで有効かを示し ています。省略時は `/32' または `/255.255.255.255' (IP アドレスの完全 一致)です。どんな IP アドレスでもよい場合は、以下のように `/0' が使え ます: # ipchains -A input -s 0/0 -j DENY # 上記の効果は `-s' オプションを指定しないのと全く同じなので、こんな使い 方はめったにしません。 4.1.4.2. 否定の指定 `-s' と `-d' を含む多くのフラグは、`!' (否定の宣言) をその引数の前に置 くことができます。 `-s' や `-d' の場合は与えられたアドレスと等しくない アドレスとマッチします。例えば、 `-s ! localhost' はローカルホストから でない全てのパケットとマッチします。 `!' の前後にスペースを入れるのを忘れないで下さい。本当に必要なのです。 4.1.4.3. プロトコルの指定 プロトコルは `-p' フラグで指定します。プロトコルの値は番号(あなたが IP のプロトコルの数値番号を知っている場合)か `TCP', `UDP' または `ICMP' という特定の名称で指定します。大文字小文字の区別はしませんから、`tcp' も `TCP' と同じ働きをします。 プロトコル名称はそれを否定するために `!' を前に付けることができます。 例えば、`-p ! TCP' は TCP でないパケットを指定します。 4.1.4.3.1. UDP と TCP ポートの指定 特別な場合である TCP 或は UDP のプロトコルが指定された時には、 TCP 或 は UDP のポート、或は含まれるポートの範囲 (しかし、後述の ``フラグメン トの処理''を参照して下さい) を指し示す拡張引数が存在し得ます。範囲は文 字 `:' で表現します。例えば `6000:6010' は 6000 から 6010 迄の範囲に含 まれる11個のポート番号を示します。もし下限値が省略されれば、デフォルト の 0 を意味します。上限値が省略されれば、デフォルトの 65535 を意味しま す。ですから、1024番以下のポートの TCP 接続を指定するには、書き方は `-p TCP -s 0.0.0.0/0 :1023' とします。ポート番号は `www' のように、名 前でも指定できます。 注記として、ポート指定の前には否定を意味する `!' を置くことができま す。ですから、 WWW パケット以外の全ての TCP パケットを指定するには、以 下のように指定します。 -p TCP -d 0.0.0.0/0 ! www 以下の指定と、 -p TCP -d ! 192.168.1.1 www 以下の指定は全く違うことをしっかり認識して下さい。 -p TCP -d 192.168.1.1 ! www 最初の例は、 192.168.1.1 以外の全てのマシンの WWW ポートへの TCP パ ケットを指定します。次の例は、 WWW ポートを除く全てのポートにおける 192.168.1.1 への TCP 接続を指定します。 最後に、このケースは WWW ポートでなく、 192.168.1.1 でもないことを意味 します: -p TCP -d ! 192.168.1.1 ! www 4.1.4.3.2. ICMP タイプとコードの指定 ICMP にもまたオプション引数がありますが、 ICMP はポートを持ち得ませ ん。 (ICMP にはタイプとコードがあります) それらには異なる意味がありま す。 `-s' オプションの後に ICMP ネームを用いる (ipchains -h icmp を用いて、 ネームを一覧表示します) か、 ICMP タイプとコードの数値を用いるかで、そ れらを指定します。タイプは `-s' オプションの後に、コードは `-d' オプ ションの後に指定します。 ICMP ネームはかなり長いです: 他とはっきり区別できる分だけの長い文字列 であれば十分です。 最も一般的な ICMP パケットの小さな一覧を以下に示します: 番号 ネーム 必要とされるもの 0 echo-reply ping 3 destination-unreachable 全ての TCP/UDP トラフィック 5 redirect ルーティングデーモンが動作していない時の ルーティング 8 echo-request ping 11 time-exceeded traceroute ICMP ネームは `!' を置けないことに注意して下さい。 絶対に絶対に絶対に、 ICMP タイプ3 メッセージの全部をブロックしないで!! (後述の``ICMP パケット''を参照して下さい) 4.1.4.4. インターフェイスの指定 `-i' オプションはマッチすべきインターフェイスの名前を指定します。イン ターフェイスとは、パケットが入って来るか、または出て行く物理デバイスで す。ifconig コマンドを使って `up' である (すなわち、今動いている)イン ターフェイスをリストアップできます。 入来するパケット (すなわち、 input チェインを通過するパケット) のイン ターフェースは、それらが流れ込んで来るインターフェースであるものと見な されます。論理的には、出て行くパケット (output チェインを通過するパ ケット) のインターフェースは、それらが出て行くであろうインターフェース であります。 forward チェインを通過するパケットのインターフェースもま た、それらが出て行くであろうインターフェースです; 私には、これは全くの 独断に思えます。 (訳注: ここで著者は forward チェインのインターフェースを出力インター フェースにしたことに抗議しているように思えます。たぶん著者は入力と出力 の両方指定できたほうがよいと思っていて、でも、 ipchains にはインター フェイスを指定するオプションが -i の１つしかないので、どちらかにせざる おえなかった。と言う話だと思います。 ipchains の後継である iptables で は、 FORWARD チェインで、入力と出力の両方のインターフェイスを指定でき るようになってます。) 現在存在していないインターフェイスを指定することは全く問題がありません が、指定したインターフェイスが up して来るまでルールがマッチすることは ありません。これはダイアルアップ PPP リンク(通常インターフェイスは ppp0 )や同様のものについて非常に有効です。 特別なケースとして、インターフェース名の最後が `+' で終わるものは、 ( 現在存在していようとなかろうと) その文字列から始まる全てのインター フェースにマッチします。例えば、全ての PPP インターフェースにマッチす るルールを指定するには、 -i ppp+ オプションが使えます。 指定したインターフェイスと一致しないパケットにマッチするようにインター フェイス名の前には `!' を置くことができます。 4.1.4.5. TCP SYN パケットのみを指定する 一方向だけ TCP コネクションを許可し、他方は許可しないようにすることは 往々にして有効です。例えば、あなたが外部の WWW サーバーと接続したい が、そのサーバーからの接続を許可したくないときです。 そのサーバーから来る TCP パケットをブロックすることは自然な方法です。 残念なことに、TCP コネクションにはとにかく両方向のパケットが行き来する ことが必要です。 その解決方法は、コネクション要求に用いられるパケットのみをブロックする ことです。このようなパケットは SYN パケットと呼ばれます。 (技術的に は、SYN フラグが設定されていて、 FIN と ACK フラグがクリアされているパ ケットを指しますが、我々はこれを SYN パケットと呼びます。) それらのパ ケットだけを許可しないことで、その場の接続要求を止められます。 `-y' フラグはこのために使われます: これは TCP プロトコルを指定されてい る場合においてのみ有効です。例えば、 192.168.1.1 から要求される TCP コ ネクションを指定するには: -p TCP -s 192.168.1.1 -y もう一度、このフラグはその前に `!' を置くことによって (訳注: ! -y とし て) 否定することができ、それは接続開始のパケットを除く全てのパケットを 意味します。 4.1.4.6. フラグメントの処理 時に、一度にケーブルに送り出すにはパケットが大き過ぎることがあります。 こんなときは、パケットはフラグメントに分割され、複数のパケットで送られ ます。受信点でこれらのフラグメントを再び集めて完全なパケットに再構成し ます。 フラグメントの問題点は、先程リストアップした仕様の幾つか (特に、ソース ポート、宛先ポート、 ICMP タイプ、 ICMP コード、或は TCP SYN フラグ) は、カーネルに、最初のフラグメントにだけ含まれているパケットの始めの部 分を覗くように要求している点にあります。 あなたのマシンが外部ネットワークにのみ接続されるなら、カーネルの "IP: 常にデフラグメントする" を Y に設定してコンパイルすることにより、通過 する全てのフラグメントを再構築するように Linux カーネルに命ずることが できます。これは問題をうまく回避します。 そうでなければ、フィルタリングルールがフラグメントをどのように扱うかを 理解することが重要です。情報が無ければどんなフィルタリングルールもマッ チしません。この意味するところは 1番目のフラグメントは他のパケットと同 じように扱われます。 2番目以降のフラグメントは異なります。従って、 -p TCP -s 192.168.1.1 www というルール (ソースポートが `www' の指定)は、 フラグメント(1番目のフラグメント以外)と決してマッチしません。同様に否 定のルール -p TCP -s 192.168.1.1 ! www もマッチしません。 とはいえ、`-f' フラグを用いて、 2番目及びそれ以降のフラグメントに合致 するルールを指定できます。明らかに、このようなフラグメントルールには TCP や UDP ポート、 ICMP タイプ、 ICMP コード或は TCP SYN フラグを指定 するのは間違いです。 また、`!' を `-f' の前に付けて、 2番目以降のフラグメントと適合しない ルールの指定もできます。 通常、フィルタリングは 1番目のフラグメントに効力があるので、目的のホス トでのフラグメントの再組み立てを妨げるため、2番目以降のフラグメントを 通過させることは安全とみなされています。とはいえ、フラグメントを送るこ とにより簡単にマシンをクラッシュさせることができるバグが知られていま す。調べて下さいね。 ネットワーク管理者のための注記: 異常なパケット(TCP, UDP および ICMP の パケットで短すぎてファイアーウォールのコードがポート番号または ICMP の コードと種類を読めないもの)は、フラグメントと同様に取り扱われます。フ ラグメントの位置が 8 から始まるTCP パケットだけが明白にファイアウォー ルコードによって破棄されます。(これが発生すると syslog にメッセージが 現れます。) 例えば、次のルールは 192.168.1.1 へ行くフラグメントはどれでも破棄しま す: # ipchains -A output -f -d 192.168.1.1 -j DENY # 4.1.5. フィルタリングの副次的効果 さて、今我々はルールを用いてパケットにマッチさせる方法の全てを知りまし た。パケットがルールにマッチすると、以下に記すことが起こります: 1. 該当するルールのバイトカウンタはパケットのサイズ(ヘッダとその他全 て) によって増加します。 2. 該当するルールのパケットカウンタがパケットの数によって1 加算されま す。 3. ルールが要求するなら、パケットがログに記録されます。 4. ルールが要求するなら、パケットの Type Of Service (TOS) フィールドが 変更されます。 5. ルールが要求するなら、パケットに印が付けられます。(2.0 カーネルシ リーズにはありません。) 6. パケットに対し、次に何を行わせるかを決定するべく、ルールターゲット が検査されます。 これら以外の種類については、重要度に応じて手を付けたいと思います。 4.1.5.1. ターゲットの指定 ターゲットはルールにマッチするパケットに対し何をすべきかをカーネルに指 示します。 ipchains はターゲットの指定に `-j' を用います。(`ジャンプす る'と考えて下さい) ターゲット名は 8文字以下でなければならず、また大小 文字を区別します: "RETURN" と "return" は全く別物です。 最も単純なケースは指定されるターゲットが全くない場合です。このルールの タイプ (しばしば `計数' ルールと呼ばれます) は単純に一定のパケットのタ イプをカウントするのに便利です。このルールにマッチするか否かにかかわら ず、カーネルは単純にチェイン内の次のルールを検査します。例えば、 192.168.1.1 からのパケットの数を数えるには、以下のようにできます: # ipchains -A input -s 192.168.1.1 # (`ipchains -L -v' を用いて、各々のルールに関連付けられたバイト及びパ ケットカウンタを見れます。) 6つの特別なターゲットがあります。最初の 3つの ACCEPT, REJECT と DENY はとても単純です。 ACCEPT はパケットの通過を許可します。 DENY はあたか もパケットを受け取っていないかのように破棄します。 REJECT はパケットを 破棄しますが、(もしそれが ICMP パケットでないなら) 宛先は未到達である ことを知らせる ICMP 返答を、ソースに対して生成します。 次の一つ、 MASQ はカーネルにパケットをマスカレードすることを知らせま す。これを動作させるには、カーネルが IP マスカレーディングを有効にして コンパイルされている必要があります。詳細については、 Masquerading- HOWTO と、付録の``ipchains と ipfwadm との違い''を見て下さい。このター ゲットは forward チェインを通過するパケットにおいてのみ有効です。 他の主要な特別なターゲットは、カーネルに対して、何処から発生したかを問 わずにパケットをローカルポートへ送る、 REDIRECT です。これはプロトコル に TCP または UDP を指定しているルールにおいてのみ指定できます。任意 に、ポート (名前又は番号) は `-j REDIRECT' と指定できます。これはパ ケットが他のポートへアドレスされていたとしても特定のポートへ転送させる 効果を持ちます。このターゲットは input チェインを通過するパケットにお いてのみ有効です。 最後の特別なターゲットは RETURN で、直ちにチェインの最後に落し込むこと と等価です。(後述の``ポリシーを設定する''を参照して下さい。) 他のターゲットはユーザー指定のチェインを示します。 (後述の``チェインの 操作''で説明しています。) パケットはそのチェイン内のルールを通過し始め ます。そのユーザ定義チェインでの検査が全て終ってもパケットの運命が決ま らなければ、現在のチェインに戻り、その次のルールから検査を再開します。 ASCII アートの時間です。2つの(おばかさんな)チェイン: input (組み込み済 みチェイン)と test (ユーザ定義チェイン)で考えましょう。 `input' `test' ┌──────────────┐ ┌─────────────┐ │ルール 1: -p ICMP -j REJECT │ │ルール 1: -s 192.168.1.1 │ ├──────────────┤ ├─────────────┤ │ルール 2: -p TCP -j Test │ │ルール 2: -d 192.168.1.1 │ ├──────────────┤ └─────────────┘ │ルール 3: -p UDP -j DENY │ └──────────────┘ 192.168.1.1 から来て 1.2.3.4 へ向かう TCP パケットについて考えましょ う。パケットは input チェインに入り、まず、ルール 1 が検査されます― マッチしません。ルール 2 がマッチして、そのターゲットは Test なので、 次に検査されるルールは Test の先頭です。 Test のルール 1 はマッチしま すが、ターゲットを指定していないので、次のルールであるルール 2 が検査 されます。これはマッチしないので、チェインの終わりに達しました。先程検 査したルール 2 のある input チェインに戻り、それで今度はルール 3 が検 査されますが、これもまたマッチしません。 それで、パケットの経路は次のようになります: v __________________________ `input' | / `Test' v ┌───────────|─/ ┌──────────|─┐ │ルール 1 | /│ │ルール 1 | │ ├───────────|/-┤ ├──────────|─┤ │ルール 2 / │ │ルール 2 | │ ├───────────-─┤ └──────────v─┘ │ルール 3 /─┼─\_______________________/ └───────────|─┘ v ユーザ定義チェインを効果的に使う方法は、``ファイアウォールルールをどの ように構築するか''の章を参照して下さい。 4.1.5.2. パケットのログ記録 これはルールにマッチすることの副次的効果です; マッチしたパケットを `-l' フラグを用いてログに記録することができます。普通、通常のパケット においてログを記録したくはないでしょうけど、例外的なイベントを見たい時 に便利な特徴です。 この情報のカーネルのログは以下のような感じです: Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025 L=34 S=0x00 I=18 F=0x0000 T=254 このログメッセージは簡潔に設計されており、ネットワークの権威者の為だけ に便利な技術情報を含んでいますが、あとの我々にも有用です。簡単に説明す ると以下のようになります: 1. `input' はパケットにマッチしたルールを含むチェインで、ログメッセー ジを発生しています。 2. `DENY' はルールがパケットに何をするかを示しています。もしこれが `-' なら、ルールはパケットに何も行いません。 (計数ルールです。) 3. `eth0' はインターフェース名です. 何故ならばこれは input チェインで あり, パケットは `eth0' から入って来たことを意味するからです。 4. `PROTO=17' はパケットがプロトコル 17 であったことを意味します。プロ トコル番号のリストは /etc/protocols にて与えられます。最も一般的な ものは 1 (ICMP), 6 (TCP) と 17 (UDP) です。 5. `192.168.2.1' はパケットのソース IP アドレスは 192.168.2.1 であった ことを意味します。 6. `:53' はソースポートはポート 53 番であったことを意味します。 `/etc/services' を見れば、これが `domain' ポートであることを開示し ています。(すなわち、これは恐らく DNS の返答です。) UDP と TCP にお いては、この番号はソースポートです。 ICMP においては、 ICMP タイプ です。それ以外では、 65535 になるでしょう。 7. `192.168.1.1' は宛先 IP アドレスです。 8. `:1025' は宛先ポートは 1025 であったことを意味します。 UDP と TCP においては、この番号は宛先ポートです。 ICMPにおいては、 ICMP コード です。それ以外では、 65535 になるでしょう。 9. `L=34' は、パケットは合計 34 バイト長であったことを意味します。 10. `S=0x00' は TOS フィールドを意味します。 (4 で割って、 ipchains で 用いられるサービスの型が得られます。) 11. `I=18' は IP の ID です。 12. `F=0x0000' は 16 ビットのフラグメントオフセットとフラグの加算です。 `0x4' 又は `0x5' で始まる値は 「フラグメントしていない」ビットが設 定されていることを示します。 `0x2' 又は `0x3' は `更にフラグメント している' ビットが設定されていることを示します; この後に更なるフラ グメントが予測されます。残りの数値はこのフラグメントのオフセット で、それは 8 で割った値です。 13. `T=254' はパケットの寿命時間です。この値は全てのホップ毎に減じら れ、大概 15 か 255 で始まります。 14. `(#5)' は、ブラケット内の最後の番号がそれより新しいカーネルであろう ことを示します。(恐らく 2.2.9 以降でしょう。) 最後に、より新しい カーネル(たぶん 2.2.9 以降)で、括弧で囲まれた番号があるでしょう。 (訳注: 原文には This is the rule number which caused the packet log. と書かれていますが、これは finally there may be a number ... と思われます。) 標準的な Linux システムでは、カーネルの出力は klogd (カーネルロギング デーモン) にて捕捉され、 syslogd (システムロギングデーモン) に渡されま す。 `/etc/syslog.conf' は、各々の `facility' (我々の場合は、facility は "カーネル"です) の宛先と、 `level' (ipchains の為に、使われる level は "info" です)を指定することによって、 syslogd の振る舞いを制御しま す。 例えば、私の (Debian) /etc/syslog.conf は `kern.info' にマッチする 2行 を含んでいます: kern.* -/var/log/kern.log *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages これらはメッセージが `/var/log/kern.log' と `/var/log/messages' に複製 されることを示しています。詳細は `man syslog.conf' を見て下さい。 4.1.5.3. サービスの型を操作する IP ヘッダには滅多に使われない 4つのビットがあり、「サービスの型」 (TOS) ビットと呼ばれています。それらはパケットが取り扱われる用途に影響 します; 4つのビットは "Minimum Delay"(最小遅延), "Maximum Throughput" (最大処理能力), "Maximum Reliability"(最大信頼値) そして "Minimum Cost" (最小コスト) です。それらのビットの一つだけが設定を許されます。 TOS 操作コードの作者の Rob van Nieuwkerk は以下のように述べています: 特に "Minimum Delay"(最小遅延) が私にとって重要です。私は上 流の (Linux) ルータで"対話型"パケットの為にこのスイッチをオ ンしています。私のマシンは 33.6k モデムで外部と接続されてい ます。 Linux はパケットに 3つのキューで優先順位を付けていま す。この方法で私は大量のダウンロードと同時に許容できる対話的 なパフォーマンスを得ています。 (これはシリアルドライバにその ような巨大なキューがなければ良いのですが、待ち時間は1.5秒に 落されます。) 注意: 明らかに、あなたは入って来るパケットに対して制御はできません。あ なたは自身の Linux box を去っていくパケットの優先順位だけを制御できま す。他の方法で優先順位をやりくりするなら、 RSVP のようなプロトコルが必 要です。(これに関しては私は何も知らないので、私には聞かないで下さい。) 最も一般的な使用方法は telnet と ftp のコントロールコネクションに "Minimum Delay" を設定し、 FTP データに "Maximum Throughput" を設定す るものです。以下のようになります: ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10 ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10 ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08 `-t' フラグは 2つの特別なパラメータを持ち、それらは16進で指定します。 それらはTOS ビットを複雑にいじくり回します: 最初のマスクはパケットの現 在の TOS に AND (論理積)されます。 2番目のマスクはそれに対して XOR (排 他的論理和)されます。これで激しく混乱するのでしたら、以下の一覧を使っ て下さい: TOS 名 値 一般的な用途 Minimum Delay 0x01 0x10 ftp, telnet Maximum Throughput 0x01 0x08 ftp-data Maximum Reliability 0x01 0x04 snmp Minimum Cost 0x01 0x02 nntp Andi Kleen は以下のように指摘しています。 (後々に残すために表現を軟ら かくしています。) 多分、TOS ビットの議論については、 ifconfig の txqueuelen パ ラメータの参照を追加するのに便利でしょう。デバイスのキュー長 の初期値はイーサネットカードの為に調整され、モデムにおいては それは長すぎて、 (TOSに則ったキューの) 3バンドのスケジューラ を作成し、それらの働きは微々たるものです。モデムやシングル b チャネルの ISDN 接続において、この値を 4-10 の間に設定するの は良いと思います; 太いデバイスならより長いキューが必要です。 これはカーネルバージョン 2.0 と 2.1 の問題でしたが、 2.1 に おいてそれは (最新の nettools を用いて) ifconfig フラグで可 能になり、 2.0 においてはデバイスドライバのソースにパッチを 適用して可能になります。 ですので、モデムでの PPP 接続における TOS 操作の最大の恩恵を得るには、 あなたのマシンの /etc/ppp/ip-up スクリプト内で `ifconfig $1 txqueuelen' を実行することです。これを使う際の値はモデムの速度とモデム 内のバッファの総量に依存します; 以下に Andi の私への返答をそのまま再度 掲載します: 与えられたコンフィギュレーションの最適値は経験が必要です。も しルータ上のキューが短すぎると、パケットを取りこぼしてしまい ます。そして勿論 TOS の書き換えもなく効果を得ることになり、 単に TOS の書き換えは非協力的なプログラムに効果をもたらしま す。 (しかし全ての標準的な Linux システムプログラムは協力的 です。) 4.1.5.4. パケットのマーキング これは Alexey Kuznetsov による新たな"高品質通信"の実装によって、複雑で 強力な相互作用を有効にします。 2.1 シリーズカーネル以降のmarkベースの フォワーディングと同様に良好です。更なるニュースとしてはこれが使えるよ うになったことです。このオプションは 2.0 カーネルシリーズでは全く無視 されます。 (訳注: Quality of Service は、 QoS と略され、ネットワーク流量制限を指 します。これはカーネルのコンフィギュレーションスイッチに CONFIG_NET_QOS として存在します。) 4.1.5.5. チェインの操作 ipchains のとても有効な特徴は、チェイン中の関連するルールをグループ化 できることです。お望みのチェインは何でも呼び出せますが、組み込み済み チェイン (input, output と forward) やターゲット (MASQ, REDIRECT, ACCEPT, DENY, REJECT 或は RETURN) を壊さない為に、十分長い名前を使って 下さい。将来の拡張に備えて、ラベル名の全部に大文字を使わないことをお勧 めします。チェインの名前は最大 8文字まで使えます。 4.1.5.6. 新しいチェインを作る 新しいチェインを作りましょう。私はとっても創造力に富んだ野郎なので、そ れを test と名付けます。 # ipchains -N test # これは簡単です。さて、あなたはこれまで詳細に述べてきたように、これに ルールを入れることができます。 4.1.5.7. チェインを削除する チェインを削除するのも同様に簡単です。 # ipchains -X test # なぜ `-X' かって? うーん、よい文字が全て取られてしまったのです。 チェインを削除するには 2つの制限があります: そのチェインは空である必要 があり(後述の``チェインを空にする''を見て下さい)、しかも、決してどの ルールのターゲットにもなっていないことです。組み込み済みの 3つのチェイ ンはどれも削除できません。 4.1.5.8. チェインを空にする チェインから全てのルールを取り去り空にするのは簡単で、`-F' コマンドを 使います。 # ipchains -F forward # もし、チェイン名を指定しなければ、全てのチェインを空にします。 4.1.5.9. チェインの内容をリストアップする チェイン中の全てのルールをリストアップするには、`-L' コマンドを使いま す。 # ipchains -L input Chain input (refcnt = 1): (policy ACCEPT) target prot opt source destination ports ACCEPT icmp ----- anywhere anywhere any # ipchains -L test Chain test (refcnt = 0): target prot opt source destination ports DENY icmp ----- localnet/24 anywhere any # test に表示されている `refcnt' は、test をターゲットに指定しているルー ルの数です。この数が 0 でないと(かつチェインが空であること)、そのチェ インを削除することはできません。 もし、チェイン名を指定しなければ、空のも含めて全てのチェインについてリ ストアップされます。 `-L' には 3つのオプションがあります。 (大抵の人々は DNS を使っています が) DNS が適切に設定されていない場合や DNS の要求をフィルターアウトし ている場合は、 ipchains が IP アドレスを調べようとするときに長く待たさ れます。それを防ぐのに `-n' (数値)オプションはとても有効です。このオプ ションは TCP や UDP ポートについても名前ではなく番号で表示します。 `-v' オプションはルールの詳細を全て、例えば、パケットやバイトのカウン ター、TOS マスク、インターフェイス、そしてパケットマークを表示します。 このオプションを指定しなければ、これらの値は省略されます。 # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any 注記として、パケットとバイトのカウンターは、1000, 1,000,000 および 1,000,000,000 を、それぞれ `K', `M' および `G' の接尾辞を使って表示し ます。 `-x' (拡張数値)オプションを使うと、値の大きさにかかわらず完全な 数値を同様に表示します。 4.1.5.10. カウンターを(ゼロに)リセットする カウンターをリセットできると便利です。これは `-Z' (カウンタをゼロにす る) オプションでできます。例えば: # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any # ipchains -Z input # ipchains -v -L input Chain input (refcnt = 1): (policy ACCEPT) pkts bytes target prot opt tosa tosx ifname mark source destination ports 0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any # このやり方では、リセットする直前のカウンタ値を知る必要があるときに問題 になります。上記の方法では、`-L' から `-Z' コマンドまでの間にいくつか のパケットが通過するかもしれません。そのため、カウンターを読むと同時に リセットするには、`-L' と `-Z' を同時に使います。残念ながら、あなたが これを使うと、単一のチェインを操作できません: 一旦全てのチェインをリス トアップしてゼロにする必要があります。 # ipchains -L -v -Z Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any # ipchains -L -v Chain input (policy ACCEPT): pkts bytes target prot opt tosa tosx ifname mark source destination ports 10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any Chain forward (refcnt = 1): (policy ACCEPT) Chain output (refcnt = 1): (policy ACCEPT) Chain test (refcnt = 0): 0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any # 4.1.5.11. ポリシーを設定する 以前にパケットがどのようにチェインを通り抜けるのかを、前述の ``ター ゲットの指定''にて論じたとき、パケットが組み込み済みチェインの終わりに 達した時に何が起きるのかを大体述べました。この場合、チェインのポリシー がそのパケットの運命を決定します。組み込み済みチェイン(input, output および forward)だけがポリシーを持っています。なぜなら、パケットがユー ザ定義チェインの終わりまで下り落ちると、前のチェインに戻って行くからで す。 ポリシーは最初から 4つまでの特別なターゲットのいずれかです: ACCEPT, DENY, REJECT 或は MASQ です。 MASQ は `forward' チェインにおいてのみ有 効です。 また、重要な注意点として、組み込み済みチェイン中のルールにおける RETURN ターゲットは、パケットがルールにマッチした時に明示的にチェイン のポリシーをターゲットにするため便利です。 4.1.6. マスカレーディングの操作 IP マスカレーディングを微調整する幾つかのパラメータがあります。それら は ipchains に組み込まれています。何故なら、その機能の為に別のツールを 書くのは良くないからです。 (しかしこれは変更されるでしょう。) IP マスカレーディングのコマンドは `-M' で、今マスカレードされているコ ネクションをリストアップするために `-L' と組み合わせられ、マスカレー ディングの値を調整するために `-S' と組み合わせられます。 `-L' コマンドは `-n' (ホスト名やポート名ではなく、数値を表示します。) か、または `-v' (まさにあなたが注意する、マスカレードコネクションの シーケンス番号の詳細を表示します。)を伴います。 `-S' コマンドは以下の 3つのタイムアウト値を設定します、それらは秒単位 です: TCP セッション、 FIN パケット後の TCP セッションと、 UDP パケッ トです。もしそれらの値の一つを変更したくないならば、単純に `0' が与え られます。 既定値は `/usr/src/linux/include/net/ip_masq.h' にリストアップされてお り、 現在はそれぞれ 15 秒、 2秒 そして 5秒です。 変更される最も一般的な値は、 ftp の為に変更する最初の値です。 (後述 の``FTP の悪夢''を参照して下さい。) ``マスカレーディングのタイムアウト値を設定できません!''に列挙したタイ ムアウトの設定に関する問題に注意して下さい。 4.1.7. パケットをチェックする 時にあなたのマシンに一定のパケットが入り込む際に何が起こるのかを見たい と思うことでしょう。あなたのファイアウォールチェインをデバッグする時な ど。 ipchains はこれを有効にさせる `-C' コマンドを装備しています。その 際、カーネルが本当のパケットを診断するのに用いるルーチンと正確に同じ ルーチンを用います。 パケットをテストするチェインは、引数 `-C' の後にパケットのテストをする チェインの名前を指定します。カーネルは常に input, output または forward チェイン、と移って行きますが、テストはどのチェインからでも始め ることができます。 `packet' の詳細は、ファイアウォールルールを指定する為に用いられるのと 同じ書き方を用いて指定します。特に、プロトコル (`-p') 、ソースアドレス (`-s') 、宛先アドレス (`-d') とインターフェース (`-i')は必須です。もし プロトコルが TCP 又は UDP なら、単一のソースと単一の宛先ポートが指定さ れなければなりませんし、 ICMP プロトコルにおいては ICMP タイプが指定さ れなければなりません。 (フラグメントを示す `-f' フラグを指定していなけ れば。指定している場合はこれらのオプションは不正です。) プロトコルが TCP ならば (そして `-f' フラグがしていされていなければ) 、テストパケットに SYN ビットをセットするのに `-y' フラグを指定しても よいでしょう。 以下は 192.168.1.1 の60000 ポートから 192.168.1.2 の www ポートへ、 eth0 インターフェースに入り、 `input' チェインに到達する TCP SYN パ ケットをテストする例です。 (これは典型的な WWW の接続開始の入来です) # ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www packet accepted # 4.1.8. 一度に複数のルールと何が起こるのかを見る 時に単一のコマンドラインが複数のルールに影響させることができます。これ には二つの方法があります。最初に、(DNS を用いて)複数の IP アドレスに解 決するホスト名を指定すると、 ipchains はあなたが各々のアドレスの組み合 わせに対して複数のコマンドを発行したのと同じように振る舞います。 ですから、もしホスト名 `www.foo.com' が 3つの IP アドレスに解決し、ホ スト名 `www.bar.com' が 2つの IP アドレスに解決する場合、コマンド `ipchains -A input -j reject -s www.bar.com -d www.foo.com' は、 input チェインに 6つのルールを追加することとなります。 ipchains に複数の動作を行わせるもう一つの方法は、双方向フラグ(`-b') を 用います。このフラグは、 ipchains にコマンドを 2回入力させたのと同様に 振る舞わせます。その際の 2回目のコマンドは `-s' と `-d' の引数を反転さ せたことになります。ですので、 192.168.1.1 に相互にフォワードさせるこ とを禁じさせるには、以下のようにできます: # ipchains -b -A forward -j reject -s 192.168.1.1 # 個人的には、 `-b' オプションは好きでないです; もっと便利にしたいなら、 後述の``ipchains-save を使う''を見て下さい。 -b オプションは 挿入 (`-I') 、 削除 (`-D') (でもルールナンバーの拡張で はありません。) 、追加 (`-A') とチェック (`-C') コマンドと共に使えま す。 もう一つの便利なフラグに `-v' (冗長な) があります。これは ipchains が あなたのコマンドによって何をしているのかを正確にプリントアウトします。 あなたが複数のルールをコマンドを施しているのなら、これが便利です。例え ば、以下は 192.168.1.1 と 192.168.1.2 との間でフラグメントの振る舞いを チェックする例です。 # ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> * packet accepted tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> * packet accepted # 4.2. 実例集 私の PC はインターネットへダイヤルアップ PPP 接続されます。 (-i ppp0) 私はダイヤルアップの度毎にネットニュース (-p TCP -s news.virtual.net.au nntp) とメール (-p TCP -s mail.virtual.net.au pop-3) を PC に取り込みます。私は Debian の FTP による PC の更新作業を 定期的に行います。 (-p TCP -y -s ftp.debian.org.au ftp-data) 私は ISP のプロキシを介して web へのアクセスを行います (-p TCP -d proxy.virtual.net.au 8080) が、 Dilbert アーカイヴ上の doubleclick.net からの広告バナーを嫌います。 (-p TCP -y -d 199.95.207.0/24 と -p TCP -y -d 199.95.208.0/24) 私は PC がオンラインの際に誰かが私の PC に対して ftp を試みることに関 しては気にしません。 (-p TCP -d $LOCALIP ftp) けれども、外部の誰かに私 の内部ネットワーク (-s 192.168.1.0/24) の IP アドレスを偽装されたくあ りません。これは通常、 IP スプーフィング (訳注: 偽装) と呼ばれ、バー ジョン 2.1.x 以降のカーネルにはこれを防ぐ良い方法があります: ``IP 偽装 保護(IP Spoof Protection)を、どのように設定したらよいですか?''を参照し て下さい。 このセットアップはとても単純で、何故なら今私の内部ネットワーク上には他 にマシンがないからです。 私はあらゆるローカルプロセス(すなわち、ネットスケープ、 lynx 等) を doubleclick.net に接続させたくありません。 # ipchains -A output -d 199.95.207.0/24 -j REJECT # ipchains -A output -d 199.95.208.0/24 -j REJECT # さて、私は外へ出て行く様々なパケットに優先順位を設定したいです。 (入っ て来るパケットに対してこれを行う多くのメリットはありません。) これらの ルールが多数あるので、ppp-out と名付けたチェインにそれら全てを入れるこ とは意味のあることです。 # ipchains -N ppp-out # ipchains -A output -i ppp0 -j ppp-out # web のトラフィックと telnet へ最小遅延を設定します。 # ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 telnet -t 0x01 0x10 # ftp データ, nntp, pop-3 に低コストを設定します: # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02 # ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02 # ppp0 インターフェースに入って来るパケットには幾つかの制限があります: `ppp-in' というチェインを作りましょう: # ipchains -N ppp-in # ipchains -A input -i ppp0 -j ppp-in # さて、 ppp0 に入って来るパケットは 192.168.1.* のソースアドレスを主張 するべきではありません。ですから、我々はそれらをログに記録して否定 (deny) します: # ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY # 私は DNS の UDP パケット (私は全ての要求を 203.29.16.1 へ転送する キャッシュネームサーバを動かしているので、それらの要求からその DNS だ けが返答することを予測します。) と 入って来る ftp と帰って来る ftp- data (これらは1023番以上のポートのみが使われ、且つ6000番近辺の X11 ポートを使いません。) の TCP パケットのみを許可します。 # ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT # ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT # ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT # 帰ってくる TCP の返答パケットを許可します。 # ipchains -A ppp-in -p TCP ! -y -j ACCEPT # 最後に、ローカルとローカル同士のパケットは OK です: # ipchains -A input -i lo -j ACCEPT # さて、私の input チェインにおける既定ポリシーは DENY (否定) ですので、 上述のもの以外は全て破棄します: # ipchains -P input DENY # 注意: 私はこの順番でチェインをセットアップしませんでした。セットアップ の最中にパケットが入り込んで来るからです。最も安全なのは最初に DENY の ポリシーを設定することです。勿論、あなたのルールがホスト名を解決する為 に DNS の参照を要求するなら、問題が発生することでしょう。 4.2.1. ipchains-save を使う まさにあなたのお望み通りのファイアウォールチェインをセットアップし、そ して次回にやったことを思い出そうとするのは辛いことです。 そこで、今セットアップしたあなたのチェインを読み、ファイルに保存する、 ipchains-save というスクリプトです。 ipchains-restore が何をするかに関 してはちょっと待ってて下さいね。 ipchains-save は単一のチェイン又は (チェイン名が指定されなければ) 全て のチェインをセーブできます。オプションとしては `-v' のみが許され、これ はセーブされたルールを (標準エラー出力に) プリントします。 input, output そして forward チェインのポリシーも同様にセーブされます。 # ipchains-save > my_firewall Saving `input'. Saving `output'. Saving `forward'. Saving `ppp-in'. Saving `ppp-out'. # 4.2.2. ipchains-restore を使う ipchains-restore は ipchains-save で保存されたチェインを復元します。こ れは 2つのオプションを持ち得ます: `-v' は各々のルールが追加されるよう に説明します。そして `-f' は以下に説明するように、既に存在するユーザー 定義チェインを強制的に消去します。 もし、 input チェイン内にユーザー定義チェインがあれば、 ipchains- restore はそれが既存のチェインなのかをチェックします。そうであれば、プ ロンプトが表示され、チェインを消去する (全てのルールを消去する) か、処 理をスキップして現在の設定を保持するかの選択を求められます。もしコマン ドラインに `-f' を指定すれば、プロンプトは表示されません: チェインは消 去されます。 例: # ipchains-restore < my_firewall Restoring `input'. Restoring `output'. Restoring `forward'. Restoring `ppp-in'. Chain `ppp-in' already exists. Skip or flush? [S/f]? s Skipping `ppp-in'. Restoring `ppp-out'. Chain `ppp-out' already exists. Skip or flush? [S/f]? f Flushing `ppp-out'. # 5. その他の情報 この項は上述の説明からもれたすべての情報と FAQ 集があります。 5.1. ファイアウォールルールをどのように構築するか この問題にはある種の方針が必要です。速度を最適化(最も普通のパケットに 対するルールチェックを最小限にとどめる)して構築するか、管理性を高めて 構築することもできます。 PPP リンクと言う間欠的なリンクを使っているなら、起動時に input チェイ ンの最初のルールを `-i ppp0 -jDENY' に設定したいと思うかもしれません。 その場合は、 ip-up スクリプトファイルで次のようにします。 (訳注: デバイス ppp0 からのパケットを破棄する。ダイヤルアップ回線など からの侵入を防止した場合に設定する。) # `ppp-in' チェインを再生成する。 ipchains-restore -f < ppp-in.firewall # ppp-handling チェインに割り込んで DENY ルールを置き換える。 ipchains -R input 1 -i ppp0 -j ppp-in ip-down は次のようになります。 ipchains -R input 1 -i ppp0 -j DENY 5.2. フィルタリングで破棄してはいけないパケット 必要でないパケットをフィルタリングで破棄する前に注意しておかなければい けない事があります。 5.2.1. ICMP パケット ICMP パケットは、(TCP や UDP のような)別のプロトコルに対して、失敗を表 示 (その他数あるもののなかで) するのに使われています。とりわけ `目的地 に到達しない' パケットを表示します。これらのパケットをブロックすると、 `ホストに到達しません' や `ホストへの経路がありません' というエラーを 受け取ることができなくなります。どのような接続も来るはずのない返答を待 つだけになります。これはいらいらしますが致命的ではありません。 さらに悪いことは MTU 検出での ICMP パケットの役割です。すべての良好な TCP の実装(Linux を含めた)は、分割されない状態で(分割されるとパフォー マンスを低下させ、とりわけ、ときどき分割された断片が失われるとさらに低 下します)目的地に到達する最大のパケットサイズを割り出すために MTU 検出 を使っています。 MTU 検出は、まずパケットを "分割不可" のビットを設定 して送り、 '分割が必要だが分割しない設定(DF)をしている'というエラーを 示す ICMP パケットを受け取ったら、先ほどのものより小さいサイズのパケッ トを送り直す、というやりかたで動作します。これは、`目的地へ到達不能' パケットのタイプで、もし受けないなら、ローカルホストは MTU を低下させ ないで、実行はひどく悪くなるか、存在しないことになるでしょう。 訳注: ICMP: Internet Control Message Protocol IP 相互接続ネットワーク内のノードでエラー通達、診断、制御のため のメッセージを送るプロトコル MTU: maximum transmission unit ネットワークインターフェースが一度に送ることができる最大のデータ 量 すべての ICMP 経路変更要求メッセージ(type 5)をブロックするのは普通だと いうことに注意して下さい。これらは、経路を手動設定する為に使うことが出 来ますが(良好な IP スタックは安全装置を持っています)、しばしばやや危険 だと知られています。 5.2.2. DNS (ネームサーバー) への TCP 接続 外向きの TCP 接続をブロックするようにしているなら、 DNS はいつも UDP を使わないことに注意して下さい。サーバからの返答が 512 バイトを越える と、クライアントはデータを得るのに TCP 接続(やはり 53 番ポート番号) を 使います。 訳注: UDP: User Datagram Protocol データパケットの転送を行うプログラム。UDP は TCP に比べると高速 ですが、信頼性が低く、パケットの到達順序が保証されません。 TCP 転送を禁止していても、 DNS が `ほとんど動く' のでハマリます。その ようにしているなら、不可解な長い遅延やその他のときどき発生する DNS の 問題を経験することになるでしょう。 DNS の問い合わせが、いつも同一の外部のソース(/etc/resolv.conf に書かれ た行のネームサーバを直接使うか、フォワードモードでキャッシュのネーム サーバーを使うかのどちらか)にしているなら、(キャッシュを使っているな ら)ローカル domain ポートから、 /etc/resolv.conf を使っているならハイ ポート(>1023)から、そのネームサーバの domain ポートへの TCP 接続を許可 する必要だけでかまいません。 訳注: domain は /etc/services に次の項目が定義されているかを確認してお きます。次のようにして調べることができます。 $ grep domain /etc/services domain 53/tcp nameserver # name-domain server domain 53/udp nameserver 5.2.3. FTP の悪夢 典型的なパケットフィルタリングの問題は FTP です。FTP には２つのモード があります。伝統的なものは アクティブモード と言われるもので、より最近 のものは、 パッシブモード と言われます。 Web ブラウザは通常パッシブ モードがデフォルトですが、コマンドの FTP プログラムは通常アクティブ モードがデフォルトです。 アクティブモードでは、リモートホストがファイルを送信したいとき(あるい は、 ls や dir コマンドの結果でさえ)、ローカルマシンへの TCP 接続を オープンしようとします。これはアクティブ FTP を切断しないなら、これら の TCP 接続を排除できないということです。 パッシブモードを使うオプションがあるなら、良いことです。パッシブモード は入力データに対しても、クライアントからサーバにデータ接続を作ります。 パッシブモードが使えないなら、TCP 接続に 1024 を越え、6000 から 6010 の範囲に無いポートに対して TCP 接続を許可することを推奨します。(6000 は X-Window System に使われています。) 5.3. Ping of Death を排除する Linux マシンはいまや有名な Ping of Death を心配することはありません。 Ping of Death は不法に大きな ICMP パケットを送信し、それは受け取り側で TCP スタックにあるバッファーを溢れさせ、破壊の原因になります。 脆弱なマシンを保護するなら、単純に ICMP フラグメントをブロックできま す。通常の ICMP パケットは分割を要求するほど大きくはありませんから、大 きな ping を排除する以外他には影響を与えません。 (不確かですが)私 は、ICMP フラグメントを落すために、サイズオーバーの ICMP パケットの最 後のフラグメントだけを要求し、その結果、最初のフラグメントだけをブロッ クするシステムがあるという報告を聞いたことがありますが、最初のフラグメ ントだけをブロックするようなシステムはお勧めできません。 私は ICMP を使うすべてのプログラムを見てきましたが、TCP や UDP フラグ メント(あるいは不明のプロトコル)は、このような攻撃に対して使うことがで きないという理由がないので、 ICMP フラグメントをブロックするのは、間に 合わせの解決でしかありません。 5.4. Teardrop と Bonk を排除する Teardrop と Bonk と言われるものは、重複するフラグメントを目的にしてい る 2種類の攻撃(おもにMicrosoft Windows NT マシンに対して)です。 Linux ルータがデフラグ機能を持っているか、攻撃されやすいマシンにすべてのフラ グメントを禁止するのは別のオプションです。 5.5. フラグメント爆撃を排除する 信頼性の低い TCP スタックは、パケットが多数のフラグメントになってい て、それらをすべて受信できないとき、大量のフラグメントを扱うのに問題を 持っているものがあると言われています。 Linux はこのような問題がありま せん。フラグメントを破棄(正当に使用されたものも壊すかもしれません)する か、または、 `IP: always defragment' を `Y' と(あなたの Linux マシンが これらのパケットに対して唯一取り得る経路である場合のみ)選択したカーネ ルをコンパイルすることで排除できます。 5.6. ファイアウォールルールを変更する ファイアウォールルールを変更するとき、タイミングの問題があります。不手 際があると、変更の途中でにパケットを通してしまいます。安易なやりかたと しては次のような方法があります: # ipchains -I input 1 -j DENY # ipchains -I output 1 -j DENY # ipchains -I forward 1 -j DENY . 変更します ... # ipchains -D input 1 # ipchains -D output 1 # ipchains -D forward 1 # 変更している間、すべてのパケットが破棄されます。 変更が単一のチェインに限定されたものなら、新しいルールで新しいチェイン を作りたいかもしれません。新しいチェインを示すものと、古いチェインを示 すルールを置き換えます(`-R')。そうすれば、古いチェインを削除できます。 この置き換えはアトミックに(他のものには影響しないで)行われます。 5.7. IP 偽装保護(IP Spoof Protection)を、どのように設定したらよいです か? IP 偽装は、ホストが別のホストから請求されるパケットを送り出す技術で す。パケットフィルタリングは、このソースアドレスをもとに判定するので、 IP 偽装はパケットフィルターをごまかすために使うものです。 SYN 攻撃やし ずく(Teardrop)、また命取りの Ping(Ping of Death) やそれに似たもの(それ らが何者かを知らないなら心配は不用です)を使っている攻撃者の身元を隠す ためにもまた使われます。 IP 偽装を防御するもっともよい方法は、ソースアドレス認証(Source Address Verification)と言われるもので、それはルーティングコードによって行われ るもので、全くファイアウォールではありません。 /proc/sys/net/ipv4/conf/all/rp_filter というファイルを探して下さい。こ れがあるなら、始動するたびにソースアドレス認証(Source Address Verification)を有効することが正しい解決になります。このようにするた め、いずれかのネットワークインターフェースが初期化される前に、お使いの init スクリプトのどこかに次の行を加えます。 # これがもっとも良い方法です: ソースアドレス認証 # (Source Address Verification) を有効にし、現在あるものとこれから # 使うすべてのインターフェースに偽装保護をします。 if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo -n "Setting up IP spoofing protection..." for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done echo "done." else echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED. echo "CONTROL-D will exit from this shell and continue system startup." echo # コンソール上でシングルユーザシェルを起動します。 /sbin/sulogin $CONSOLE fi これができないなら、すべてのインターフェースを保護するために手動でルー ルを書き加えます。この場合はそれぞれのインターフェースについての知識が 必要です。カーネル 2.1 は自動的に127.* のアドレス(ローカルループバック インターフェース lo に予約されたもの)から要求するパケットを拒否しま す。 例えば eth0, eth1 そして ppp0 の 3つのインターフェースがあります。イン ターフェースのアドレスとネットマスクを知るために ifconfig を使うことが できます。例えば、 eth0 がネットマスク 255.255.255.0 のネットワーク 192.168.1.0 にアタッチされ、 eth1 はネットマスク 255.0.0.0 のネット ワーク 10.0.0.0 にアタッチされ、 ppp0 がインターネット(予約されたプラ イベート IP アドレスを除いて、どんなアドレスでも許されます)。次のよう なルールを加えるとよいでしょう。 # ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY # ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY # この方法はお使いのネットワークが変わると、いままでのその状態を維持する ためにあなたはファイアウォールルールを変更しなければいけないので、ソー スアドレス認証(Source Address Verification)で行うほど良くありません。 2.0 系のカーネルをお使いなら、次に示すようなルールを使って、ループバッ クインターフェースもまた保護したいかもしれません。次のようにルールを使 います: # ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY # 5.8. 最新のプロジェクト 私はユーザスペースライブラリを書いており、それは`libfw' と呼ばれるソー スディストリビューションを含んでいます。それは ipchains のバージョン 1.3 以上の能力を使用して(IP_FIREWALL_NETLINK のコンフィグオプションを 使って)ユーザスペースにパケットをコピーします。 マーク値はパケットのための Service の質 (QoS) パラメータを決めるために 使うか、あるいは、パケットがどのようにポートに中継されるかを決めるため に使うことができます。私はどちらも利用していませんが、あなたがそれにつ いて書いてみようと思うなら、どうぞ私に連絡をして下さい。 状態観察(stateful inspection)(私はダイナミックファイアウォールという言 葉を提唱します)のようなことは、このライブラリを使うユーザスペースで実 装されるでしょう。その他の素晴らしいアイディアは、ユーザスペースデーモ ンで探すことでユーザごとの基盤上でパケットをコントロールします。これは とても簡単でなければなりません。 5.8.1. SPF: ステートフルパケットフィルタリング ftp://ftp.interlinx.bc.ca/pub/spf 上記は、 Brian Murrell の SPF プロジェクトのサイトで、それはユーザス ペースで接続の追跡をします。低バンド幅のサイトに重要なセキュリティを追 加しています。 現在、SPF についての文書はほとんどありませんが、次のものは Brian が質 問に答えたものをメーリングリストに投稿したものです。 > それこそが正に私の望むことを行なうと信じています。 > 外部への要求のレスポンスとしてパケットを通すように > 一時的な''逆流(backward)''のルールをインストールしています。 はい、その通りです。 プロトコルについて理解すればするほど、 "逆流(backward)" のルールはもっと正しくなります。 今のところは、 (覚えで書いています、エラーや手抜かりがあっても許して下さい) FTP(アクティブとパッシブ、内側と外側の両方)、RealAudio、 traceroute、 ICMP そして初歩的な ICQ( ICQ サーバから入るもの、そして、直接的な TCP 接続からのもの、しかしながらファイル転送のようなことに関する第2 の直接的な TCP 接続などはまだありませんが)をサポートしています。 > SPF は ipchains を置き換えるのですか、それとも補足するのですか。 補足するものです。 ipchains は Linux マシンを越えて伝わるパケットを許可したり、防いだりする道具です。 SPF はドライバであり、トラフィックをたえず監視して、どのように変更するかを ipchains に伝え、 ipchains は、変更をトラフィックパターンに伝えます。 5.8.2. Michael Hasenstein の ftp-data ハック SuSE の Michael Hasenstein は ipchains に ftp 接続の追跡機能を追加する カーネルパッチを書いています。次のところにあります。 http://www.suse.de/~mha/patch.ftp-data-2.gz 5.9. 今後の課題 ファイアウォールと NAT は 2.4 で再設計されています。計画と議論は netfilter のメーリングリストで利用できます。 ( http://lists.samba.org を見て下さい) このような強化は多くの利便性の問 題を解決し、(実際、ファイアウォールやマスカレードはこのような困難 はな いはずです)、そしてもっとはるかに柔軟性のあるファイアウォールの発展を 促すはずです。 6. 一般的な問題 6.1. ipchains -L を使うとフリーズします! DNS 検索を受け付けないのでしょう。結局はタイムアウトになってしまいま す。 ipchains に対して `-n' (数値)フラグを使ってみましょう。 `-n' は、 ネームでの検索を行いません。 6.2. 反転ができません! `!'オプションの両側にスペースをおいて、`!' オプションを単独で使わなけ ればいけません。 (4.1.4.1 で注意しました)典型的な間違いです。 # ipchains -A input -i !eth0 -j DENY # `!eth0' と呼ばれるインターフェースは存在しませんが、 ipchains はそれが わからないのです。 (訳注: `!' の使い方に関する注意は、 4章を参照。 `!' オプションの前後の スペースを忘れないで下さい。) 6.3. Masquerading または Forwarding が動きません! パケットの forwarding が可能になっているのかどうかを確認して下さい(最 近のカーネルでは、デフォルトで `使用しない'になっています。パケットは `forward' chain を越えることすらないということです)。 root 権限で次の ように入力すれば変更できます。 # echo 1 > /proc/sys/net/ipv4/ip_forward # これでうまくいくなら、毎回、可能になるように、お使いの起動スクリプトの どこかにこの行を書いておくことができます。このコマンドが動く前にファイ アウォールを設定したいはずです。そうしないと、(破棄すべき)パケットを通 過させてしまう機会を与えてしまいます。 6.4. -j REDIR が動きません! リダイレクトを動かすためにはパケットの forwarding (上述を見て下さい)を 許可しなければいけません。そうしないと、ルーティングのコードはパケット を落します。そこで、リダイレクトのみを使っていてフォワーディングは全然 使っていないならば、このことに注意して下さい。 REDIRECT (input チェインにある)は、ローカルプロセスからの接続には効果 がないことに注意して下さい。 (訳注: ipchains のオプションについては、man ipchains で確認して下さ い。) 6.5. ワイルドカードインターフェースが動きません! カーネルの 2.1.102 と 2.1.103 版(そして私が作ったいくつかの古いパッチ) にはバグがありました。それらのカーネルでは、(-i ppp+ のような)ワイルド カードインターフェースがうまくいかないエラーを明示する ipchains コマン ドを生成しました。 この件は、最新のカーネルと web サイトにある 2.0.34 のパッチでは修正さ れています。カーネルソースを手で修正するなら、 include/linux/ip_fw.h ファイルの 63行あたりを次のように変更します: #define IP_FW_F_MASK 0x002F /* All possible flag bits mask */ これは ``0x003F'' を読むべきです。これを修正し、カーネルを再構築しま す。 6.6. TOS (Type of Service) が動きません! これは私の間違いでした。 Service field のタイプを設定は、 2.1.102 から 2.1.111 版のカーネルでは実際には Service のタイプを設定できないので す。この問題は、2.1.112 では修正されました。 6.7. ipautofw とipportfw が動きません! 2.0.x では動きません。 ipchains とipautofw あるいは ipportfw に対する 大きなパッチを作成し、維持する時間がありません。 2.1.x に対しては、次のところから Juan Ciarlante の ipmasqadm をダウン ロードして下さい。 http://juanjox.linuxhq.com/ そして、ipautofw やipportfw を使うとき、 ipportfw のかわりに ipmasqadm portfw を入力し、そして、 ipautofw のか わりにipmasqadm autofw を入力して、きちんと使って下さい。 6.8. xosview が壊れています! 1.6.0 版か、それ以降のものにして下さい。それらの版では、カーネル 2.1.x に対してどのような firewall rule も要求しません。これは 1.6.1 でまだ壊 れていると思われるなら、その場合は著者にバグ報告をして下さい(それは、 私の失敗ではありません)。 6.9. `-j REDIRECT' で Segmentation エラーになります! これは ipchains 1.3.3 版のバグですので、新しい版にアップグレードして下 さい。 6.10. マスカレーディングのタイムアウト値を設定できません! (カーネル 2.1.x において) 2.1.123 以降では動きません。 2.1.124 で設定 してみると、 masquerading timeouts はカーネルをロックしてしまいます (net/ipv4/ip_fw.c ファイルの 1328 行にある return を ret = に変更して 下さい)。 2.1.125 では、ちゃんと動きます。 注: 4.1.1 も見て下さい。 6.11. IPX をファイアウォールしたいです! 他にも同じようなご希望があると思います。残念ながら、私のコードは IP を すべて網羅しているだけですが、幸いなことに、IPXをファイアウオールする のに必要な機能はすべてそろっています。それを利用してあなたご自身でコー ドを書く必要がありますが、可能な範囲で私は喜んでお手伝いしましょう。 訳注: IPX というのは、Novell による MS-DOS 上のネットワークプロトコル です。 IPX については、IPX-HOWTOを参照して下さい。 http://www.linux.or.jp/JF/JFdocs/IPX-HOWTO.html 7. 実用的な例 この範例は、1999 年の 3 月に開催された LinuxWorld で Michael Neuling と私が発表したチュートリアルから引用しました。これは、与えられた問題を 解決するための唯一の方法ではないですが、多分最も単純なものです。この範 例を有益なものだと思って頂ければ幸いです。 7.1. 構成 o マスカレードされた内部ネットワーク(様々な OS が存在しています) が存 在し、"GOOD" と呼びます。 o 分離されたネットワーク上に公開サーバが存在しています(非武装化地帯 "Demilitarized Zone" ということで "DMZ" と呼びます)。 o インターネットへ PPP 接続しています( "BAD" と呼びます)。 外部ネットワーク (BAD) │ │ ppp0│ ┌───────┐ │192.84.219.1 │ サーバネットワーク (DMZ) │ │eth0 │ │───────┬──────┬──────┬─ │ │192.84.219.250│ │ │ │ │ │ │ │ │192.168.1.250 │ │ │ │ └───────┘ ┌───┐ ┌───┐ ┌───┐ │ eth1 │ SMTP │ │ DNS │ │ WWW │ │ └───┘ └───┘ └───┘ │ 192.84.219.128 192.84.219.129 192.84.218.130 │ 内部ネットワーク (GOOD) 7.2. 目的 パケットフィルターマシン: 全てのネットワークに対して PING が可能 マシンがダウンしているかどうかを知るのに大変役に立ちます。 全てのネットワークに対して TRACEROUTE が可能 これもまた、原因分析に役に立ちます。 DNS へのアクセスが可能 ping と DNS をより使いやすくするためです。 DMZ 内: メールサーバ o 外部ネットワークへの SMTP が可能 o 内部と外部ネットワークからの SMTP のアクセプト(受け入れ)が可能 o 内部ネットワークからの POP-3 のアクセプトが可能 ネームサーバ o 外部ネットワークへの DNS の要求が可能 o 内部と外部ネットワーク、パケットフィルターマシンからの DNS のアクセ プトが可能 ウェブサーバ o 内部と外部ネットワークからの HTTP のアクセプトが可能 o 内部ネットワークからの Rsync によるアクセスが可能 内部ネットワーク: 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する これらは、許可の対象としてはかなり標準的なことです。内部ネット ワーク上のマシンに対してほぼ全てを許可することから始めますが、こ こでは制限をかけています。 メールサーバへの SMTP を許可する 当然、メールは外部へ送信できるようにしたいです。 メールサーバへの POP-3 を許可する メールを読む方法です。 ネームサーバへの DNS を許可する WWW と ftp, traceroute, ssh を利用する際に、外部ネームの検索をす るのに必要です。 ウェブサーバへの rsync を許可する 外部向けウェブサーバと内部ウェブサーバを同期させる方法です。 ウェブサーバへの WWW を許可する 当然、外部向けウェブサーバへ接続できるべきです。 パケットフィルターマシンへの ping を許可する これは、一般的に広く容認されていることです。つまりファイアウォー ルマシンがダウンしているかどうかを、確認できるようにするためで す(それで外部サイトが壊れていた場合は、非難されませんので)。 7.3. パケットフィルタリングを行う前に o IP 偽装保護 (Anti-spoofing) いかなる非対称のルーティングも持っていないので、全てのインター フェースに対して IP 偽装保護を単にオンできます。 # for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done # o フィルタリングのルールとして全てを拒否にする 今まで通りローカルのループバックトラフィックは許可しますが、それ以 外の全てを拒否します。 # ipchains -A input -i ! lo -j DENY # ipchains -A output -i ! lo -j DENY # ipchains -A forward -j DENY # o インターフェースのセットアップ インターフェースのセットアップは、大抵ブート時のスクリプトで実行さ れます。フィルタリングのルールが適用される前にパケットが漏れだすこ とを防ぐ為に、インターフェースが設定される前に上記のステップが実行 されていることを確認して下さい。 o プロトコル別にマスカレードモジュールを組み込む FTP を利用する際には、マスカレードモジュールを組み込む必要がありま す。そうすることで、内部ネットワークからのアクティブとパッシブ FTP が `ちゃんと動作します'。 # insmod ip_masq_ftp # 7.4. パケットを通過させるためのパケットフィルタリング マスカレードを使用して、forward チェインでフィルターをかけることは最良 の方法です。 forward チェインをソース／あて先 インターフェースに合わせて様々なユー ザ定義チェインに分割して下さい。つまり、問題を取扱いやすい単位に分解す るのです。 ipchains -N good-dmz ipchains -N bad-dmz ipchains -N good-bad ipchains -N dmz-good ipchains -N dmz-bad ipchains -N bad-good ICMP の標準エラーをアクセプトすることは、共通の内容です。したがって、 そのためのチェインを作ります。 ipchains -N icmp-acc 7.4.1. forward チェインからジャンプさせる 残念なことに、(forward チェインでは)出力インターフェースしか分かりませ ん。したがって、パケットがどのインターフェースから入ってくるかを見抜く ために、ソースアドレスを使用します(偽装保護がアドレスのなりすましを防 いでいるので大丈夫です)。 これらのいずれにもマッチしないパケット(明らかに、そのようなことは起こ らないはずですが)は全てログを取ることに注意して下さい。 ipchains -A forward -s 192.168.1.0/24 -i eth0 -j good-dmz ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j good-bad ipchains -A forward -s 192.84.219.0/24 -i ppp0 -j dmz-bad ipchains -A forward -s 192.84.219.0/24 -i eth1 -j dmz-good ipchains -A forward -i eth0 -j bad-dmz ipchains -A forward -i eth1 -j bad-good ipchains -A forward -j DENY -l 7.4.2. icmp-acc チェインを定義する パケットが(以下の)エラー ICMP のいずれかならアクセプトされます。さもな ければ、マッチしなかったパケットに対する制御は icmp-acc チェインから抜 けて、呼出し元のチェインに戻されることになります。 ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT 7.4.3. GOOD (内部ネットワーク) から DMZ (サーバネットワーク) 内部ネットワークに対する制限 : o 外部ネットワークへの WWW, ftp, traceroute, ssh を許可する o メールサーバへの SMTP を許可する o メールサーバへの POP-3 を許可する o ネームサーバへの DNS を許可する o ウェブサーバへの rsync を許可する o ウェブサーバへの WWW を許可する o パケットフィルターマシンへの ping を許可する 内部ネットワークから DMZ の際にマスカレードはできますが、ここでは行い ません。内部ネットワーク上のどのマシンも悪意のあることをしないはずなの で、拒否される全てのパケットのログを取ります。 Debian の古いバージョンでは、/etc/services 上の `pop3' を`pop-3' と呼 ぶので注意して下さい。このことは RFC1700 と一致していません。 ipchains -A good-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.219.128 pop3 -j ACCEPT ipchains -A good-dmz -p udp -d 192.84.219.129 domain -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.218.130 www -j ACCEPT ipchains -A good-dmz -p tcp -d 192.84.218.130 rsync -j ACCEPT ipchains -A good-dmz -p icmp -j icmp-acc ipchains -A good-dmz -j DENY -l 7.4.4. BAD (外部ネットワーク)から DMZ (サーバネットワーク) o DMZ に対する制限: o メールサーバ o 外部ネットワークへの SMTP が可能 o 内部と外部ネットワークからの SMTP のアクセプトが可能 o 内部ネットワークからの POP-3 のアクセプトが可能 o ネームサーバ o 外部ネットワークへの DNS の要求が可能 o 内部と外部ネットワーク、パケットフィルターマシンからの DNS の アクセプトが可能 o ウェブサーバ o 内部と外部ネットワークからの HTTP のアクセプトが可能 o 内部ネットワークからの Rsync のアクセプトが可能 o 外部ネットワークから DMZ へ許可すること o 侵害行為については、ログはとらずそのままにする ipchains -A bad-dmz -p tcp -d 192.84.219.128 smtp -j ACCEPT ipchains -A bad-dmz -p udp -d 192.84.219.129 domain -j ACCEPT ipchains -A bad-dmz -p tcp -d 192.84.219.129 domain -j ACCEPT ipchains -A bad-dmz -p tcp -d 192.84.218.130 www -j ACCEPT ipchains -A bad-dmz -p icmp -j icmp-acc ipchains -A bad-dmz -j DENY 7.4.5. GOOD (内部ネットワーク)から BAD (外部ネットワーク) o 内部ネットワークに対する制限: o 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する o メールサーバへの SMTP を許可する o メールサーバへの POP-3 を許可する o ネームサーバへの DNS を許可する o ウェブサーバへの rsync を許可する o ウェブサーバへの WWW を許可する o パケットフィルターマシンへの ping を許可する o 一般に、内部ネットワークから外部ネットワークに対しては、全てを許可 し、それから制限を加えます。我々は、ファシストなのです。 o 侵害行為のログを取る o パッシブ FTP は、マスカレードモジュールで処理する o UDP の あて先ポート 33434 以降 は traceroute で使用される ipchains -A good-bad -p tcp --dport www -j MASQ ipchains -A good-bad -p tcp --dport ssh -j MASQ ipchains -A good-bad -p udp --dport 33434:33500 -j MASQ ipchains -A good-bad -p tcp --dport ftp -j MASQ ipchains -A good-bad -p icmp --icmp-type ping -j MASQ ipchains -A good-bad -j REJECT -l 7.4.6. DMZ から GOOD (内部ネットワーク) o 内部ネットワークに対する制限: o 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する o メールサーバへの SMTP を許可する o メールサーバへの POP-3 を許可する o ネームサーバへの DNS を許可する o ウェブサーバへの rsync を許可する o ウェブサーバへの WWW を許可する o パケットフィルターマシンへの ping を許可する o 内部ネットワークから DMZ の際にマスカレードする場合、単にそれ以外の パケットを拒否して下さい。実のところ、単にコネクションが確立された 一部のパケットのみ許可するだけです。 ipchains -A dmz-good -p tcp ! -y -s 192.84.219.128 smtp -j ACCEPT ipchains -A dmz-good -p udp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 www -j ACCEPT ipchains -A dmz-good -p tcp ! -y -s 192.84.218.130 rsync -j ACCEPT ipchains -A dmz-good -p icmp -j icmp-acc ipchains -A dmz-good -j DENY -l 7.4.7. DMZ から BAD (外部ネットワーク) o DMZ に対する制限: o メールサーバ o 外部ネットワークへの SMTP が可能 o 内部と外部ネットワークからの SMTP のアクセプトが可能 o 外部ネットワークからの POP-3 のアクセプトが可能 o ネームサーバ o 外部ネットワークへの DNS の送信が可能 o 内部と外部ネットワーク、パケットフィルターマシンからの DNS の アクセプトが可能 o ウェブサーバ o 内部と外部ネットワークからの HTTP のアクセプトが可能 o 内部ネットワークからの Rsync のアクセプトが可能 o ipchains -A dmz-bad -p tcp -s 192.84.219.128 smtp -j ACCEPT ipchains -A dmz-bad -p udp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-bad -p tcp -s 192.84.219.129 domain -j ACCEPT ipchains -A dmz-bad -p tcp ! -y -s 192.84.218.130 www -j ACCEPT ipchains -A dmz-bad -p icmp -j icmp-acc ipchains -A dmz-bad -j DENY -l 7.4.8. BAD (外部ネットワーク)から GOOD (内部ネットワーク) o 外部ネットワークから内部ネットワークへ入って来るもの全て(マスカレー ドされていないもの)を許可しません。 ipchains -A bad-good -j REJECT 7.4.9. Linux マシン自身に対するパケットフィルタリング o パケットフィルターマシン自身に入って来るパケッットにも、パケット フィルタリングを行いたいなら、input チェインでパケットフィルタリン グを行う必要があります。あて先インターフェース毎に、一つチェインを 作ります。 ipchains -N bad-if ipchains -N dmz-if ipchains -N good-if o 作ったチェインにジャンプさせます。 ipchains -A input -d 192.84.219.1 -j bad-if ipchains -A input -d 192.84.219.250 -j dmz-if ipchains -A input -d 192.168.1.250 -j good-if 7.4.9.1. BAD (外部ネットワーク) インターフェース o パケットフィルターマシン: o 全てのネットワークに対して PING が可能 o 全てのネットワークに対して TRACEROUTE が可能 o DNS へのアクセスが可能 o また外部ネットワーク用のインターフェースは、マスカレードされたパ ケット(マスカレードは、ソースポートとして 61000 から 65095 を使用し ます)へのリプライと ICMP エラー、PING のリプライも受け入れます。 ipchains -A bad-if -i ! ppp0 -j DENY -l ipchains -A bad-if -p TCP --dport 61000:65095 -j ACCEPT ipchains -A bad-if -p UDP --dport 61000:65095 -j ACCEPT ipchains -A bad-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A bad-if -j icmp-acc ipchains -A bad-if -j DENY 7.4.9.2. DMZ インタフェース o パケットフィルターマシンに対する制限: o 全てのネットワークに対して PING が可能 o 全てのネットワークに対して TRACEROUTE が可能 o DNS へのアクセスが可能 o DMZ インターフェースは、DNS からのリプライと ping のリプライ、エ ラー ICMP を受け入れます。 ipchains -A dmz-if -i ! eth0 -j DENY ipchains -A dmz-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p UDP -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A dmz-if -j icmp-acc ipchains -A dmz-if -j DENY -l 7.4.9.3. GOOD (内部ネットワーク)インターフェース o パケットフィルターマシンに対する制限: o 全てのネットワークに対して PING が可能 o 全てのネットワークに対して TRACEROUTE が可能 o DNS へのアクセスが可能 o 内部ネットワークに対する制限: o 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する o メールサーバへの SMTP を許可する o メールサーバへの POP-3 を許可する o ネームサーバへの DNS を許可する o ウェブサーバへの rsync を許可する o ウェブサーバへの WWW を許可する o パケットフィルターマシンへの ping を許可する o 内部ネットワークインターフェースは、ping と ping のリプライ、エラー ICMP を受け入れます。 ipchains -A good-if -i ! eth1 -j DENY ipchains -A good-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A good-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A good-if -j icmp-acc ipchains -A good-if -j DENY -l 7.5. 最後に o ブロッキングのルールを削除します。 ipchains -D input 1 ipchains -D forward 1 ipchains -D output 1 8. 付録: ipchains と ipfwadm との違い これらの変更の幾つかはカーネルの変更の結果であり、また幾つかは ipchains と ipfwadm との違いの結果です。 1. 多くの引数は再配置されました: 現在、大文字はコマンドを示し、小文字 はオプションを示します。 2. 任意のチェインがサポートされましたので、組み込みチェインも同様にフ ラグではなくフルネームで記載する必要があります。 (例. `-I' ではなく `input' と記載します). 3. `-k' オプションはなくなりました。 `! -y' を使って下さい。 4. `-b' オプションは、単一の `双方向' ルールというよりも、むしろ実際に は2つのルールに対して挿入/追加/削除を行います。 5. `-b' オプションは 2つのチェックを行うために、 `-C' オプションにて無 効化されます。(各々の方向の1つ) 6. `-l' に対する `-x' オプションは `-v' に変更されました。 7. もう、複数の送信側と受信側のポートはサポートされません。望ましく は、ポート幅を否定できることで、多少はその目的を補うでしょう。 8. インターフェースは(アドレスでなく)名前によってのみ指定できます。 まぁ、どのみち、以前の意味付けは 2.1 カーネルシリーズで静かに変更さ れたことですし。 9. パケットの断片化は検査されますので、自動的には素通りしません。 10. 明示的な計数チェインは廃止されました。 11. IP上の任意のプロトコルがテストできます。 12. SYN と ACK の組合せに対する以前の振舞い (以前は非 TCP パケットは無 視していました) は変更されました; SYN オプションは、非 TCP 独特の ルールに対しては無効です。 13. 現在、32ビットマシン上のカウンタは 64ビットであり、32ビットではあり ません。 14. 現在、反転オプションがサポートされています。 15. 現在、 ICMP コードがサポートされています。 16. 現在、ワイルドカードインターフェースがサポートされています。 17. 現在、TOS 操作は分別チェックされます: 古いカーネルコードは `ゼロで なければならない' TOS ビットを(不当に)操作されることで、静かに止 まってしまっていました; 現在、 ipchains は そのような試みに対して、 他の不当な場合と同様にエラーを返します。 8.1. クィックリファレンス一覧 [ 主に、コマンド引数は大文字で、オプション引数は小文字です。] 注意すべき一点として、 マスカレーディングは `-j MASQ' と記載します; こ れは `-j ACCEPT' と全く異なり、また ipfwadm のような副次的効果としては 取り扱いません。 ================================================================ | ipfwadm | ipchains | 注意 ---------------------------------------------------------------- | -A [both] | -N acct | `acct' チェインを生成し、 | |& -I 1 input -j acct | 出力と入力パケットをそれ | |& -I 1 output -j acct | に通過させます。 | |& acct | ---------------------------------------------------------------- | -A in | input | ターゲットなしのルール ---------------------------------------------------------------- | -A out | output | ターゲットなしのルール ---------------------------------------------------------------- | -F | forward | [チェイン]として用います。 ---------------------------------------------------------------- | -I | input | [チェイン]として用います。 ---------------------------------------------------------------- | -O | output | [チェイン]として用います。 ---------------------------------------------------------------- | -M -l | -M -L | ---------------------------------------------------------------- | -M -s | -M -S | ---------------------------------------------------------------- | -a policy | -A [chain] -j POLICY | (でも -r と -m も見て下 | | | さい). ---------------------------------------------------------------- | -d policy | -D [chain] -j POLICY | (でも -r と -m も見て下 | | | さい). ---------------------------------------------------------------- | -i policy | -I 1 [chain] -j POLICY| (でも -r と -m も見て下 | | | さい). ---------------------------------------------------------------- | -l | -L | ---------------------------------------------------------------- | -z | -Z | ---------------------------------------------------------------- | -f | -F | ---------------------------------------------------------------- | -p | -P | ---------------------------------------------------------------- | -c | -C | ---------------------------------------------------------------- | -P | -p | ---------------------------------------------------------------- | -S | -s | 1ポートまたはレンジに対 | | | してのみ機能し、複数で | | | はありません。 ---------------------------------------------------------------- | -D | -d | 1ポートまたはレンジに対 | | | してのみ機能し、複数で | | | はありません。 ---------------------------------------------------------------- | -V | | -i [名前] で用います。 ---------------------------------------------------------------- | -W | -i | ---------------------------------------------------------------- | -b | -b | 現在、実際には2ルールを | | | 作成します。 ---------------------------------------------------------------- | -e | -v | ---------------------------------------------------------------- | -k | ! -y | -p tcp と共に指定しない | | | と機能しません。 ---------------------------------------------------------------- | -m | -j MASQ | ---------------------------------------------------------------- | -n | -n | ---------------------------------------------------------------- | -o | -l | ---------------------------------------------------------------- | -r [redirpt] | -j REDIRECT [redirpt] | ---------------------------------------------------------------- | -t | -t | ---------------------------------------------------------------- | -v | -v | ---------------------------------------------------------------- | -x | -x | ---------------------------------------------------------------- | -y | -y | -p tcp と共に指定しない | | | と機能しません。 ---------------------------------------------------------------- 8.2. ipfwadm コマンドの変換例 旧コマンド: ipfwadm -F -p deny 新コマンド: ipchains -P forward DENY 旧コマンド: ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0 新コマンド: ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0 旧コマンド: ipfwadm -I -a accept -V 10.1.2.1 -S 10.0.0.0/8 -D 0.0.0.0/0 新コマンド: ipchains -A input -j ACCEPT -i eth0 -s 10.0.0.0/8 -d 0.0.0.0/0 (インターフェースをアドレスによって指定するのとは違うことに注意して下 さい: インターフェース名を用いて下さい。このマシン上では、 10.1.2.1 は eth0 に相当します)。 9. 付録: ipfwadm-wrapper スクリプトを使う ipfwadm-wrapper シェルスクリプトは、ipfwadm とプラグインにて置換される 為にあり、 ipfwadm 2.3a との下位互換性があります。 唯一、どうしても処理できない機能は `-V' オプションです。これが用いられ る時は、ワーニングが出力されます。 `-W' オプションも使われるなら、 `-V' オプションは無視されます。他の点では、スクリプトは ifconfig を用 いて、インターフェース名を割り当てられているアドレスから見つけようとし ます。もしそれに失敗すれば(例えばインターフェースがダウンしている場 合)、エラーメッセージを伴って終了します。 このワーニングは `-V' を `-W' に変更するか、スクリプトの標準出力を /dev/null に送れば抑えられます。 このスクリプトのミスや ipfwadm との相違点を発見したら、是非とも、バグ レポートを私に下さい: サブジェクトに "BUG-REPORT" と書いて、 rusty@linuxcare.com 宛にメールを下さい。お手持ちの古い ipfwadm のバー ジョン (ipfwadm -h) と、 ipchains のバージョン (ipchains --version) と、 ipfwadm wrapper スクリプトのバージョン (ipfwadm-wrapper --version) を列挙して下さい。同時に、 ipchains-save の出力も送って下さ い。宜しくお願いします。 この ipfwadm-wrapper スクリプトを ipchains と混用する際には、自己責任 にてお願いします。 10. 付録: 謝辞 Michael Neuling に多くの感謝をしなければなりません。彼は私のために最初 の IP チェインのコードを書いてくれました。彼のリザルトキャッシュのアイ ディアを拒否したことについて、ここに公式に謝罪致します。実は後に Alan Cox が同じアイディアを提案し、間違いに気づいた私は結局、実装にとりかか ることになったのです。 Alan Cox の24時間体制のメールによる技術サポートと激励に感謝します。 ipfw と ipfwadm のコードの作者全てに感謝します。特に Jos Vos。巨人の肩 の上に立ち、そして全て…。これは Linus Torvalds とカーネルやユーザー空 間のハッカー全てに当てはまります。 (訳注:「巨人の肩の上に立つ」というのは、ニュートンが言った有名な言葉で す。私が万有引力の発見という業績を成し遂げられたのは、巨人 (先駆者) た ちの肩の上に立っていたからにすぎない、と。日本人も真っ青の謙譲の美徳で すね。) 念入りなベータテスターとバグハンターに感謝します、特に Jordan Mendelson, Shaw Carruthers, Kevin Moule, Dr. Liviu Daia, Helmut Adams, Franck Sicard, Kevin Littlejohn, Matt Kemner, John D. Hardin, Alexey Kuznetsov, Leos Bitto, Jim Kunzman, Gerard Gerritsen, Serge Sivkov, Andrew Burgess, Steve Schmidtke, Richard Offer, Bernhard Weisshuhn, Larry Auton, Ambrose Li, Pavel Krauz, Steve Chadsey, Francesco Potorti`, Alain Knaff, Casper Boden-Cummins, そして Henry Hollenberg に。 10.1. 翻訳 翻訳する人は謝辞ページの冒頭に翻訳者一覧を掲載して下さい。例えば: `私 の英語から全てを正確に翻訳してくれたXXXさんに感謝します。' そして、私 がこの文書に含められる様に、あなたの翻訳文を教えて下さい。 Arnaud Launay, asl@launay.org: http://www.freenix.fr/unix/linux/HOWTO/IPCHAINS-HOWTO.html Giovanni Bortolozzo, borto@pluto.linux.it: http://www.pluto.linux.it/ildp/HOWTO/IPCHAINS-HOWTO.html Herman Rodrguez, herman@maristas.dhis.org: http://netfilter.kernelnotes.org/ipchains/spanish/HOWTO.html JF Project, jf@linux.or.jp: http://www.linux.or.jp/JF/JFdocs/IPCHAINS- HOWTO.html 11. 日本語訳について 日本語訳 初版: 2000年 11月 21日 JF Project 「チーム ipchains」 翻訳者一覧(敬称略、50音順): o 加藤大典 7章 o 後藤雅晴 2,3章 o 中谷千絵 5,6章 o 奈古屋広昭 1〜4章 o 松田陽一 1,4,8〜10章及びまとめ この文書を翻訳するにあたり、山森浩幸さん の Linux 2.4 Packet Filtering HOWTO 日本語訳 から多 くを引用致しました。また、赤松徹さん の、 LinuxJAPAN への投稿記事を参考にさせて頂きました。 この文書を翻訳及び編集するにあたり、以下の方々からアドバイスを頂きまし た。(50音順) 本当にありがとうございました。 o 伊藤祐一さん o 加茂智之さん o 日下部陽一さん o 柴田尚明さん o 瀬戸口崇さん o 千旦裕司さん o 武井伸光さん o 西田亙さん o 水原文さん o 山森浩幸さん