Linux IPCHAINS-HOWTO <author>Rusty Russell <date>v1.0.8, Tue Jul 4 14:20:53 EST 2000 <trans>日本語訳: JF Project (<tt>jf@linux.or.jp</tt>) <tdate>v1.0.1j Nov. 21, 2000 <abstract>  この文書は、Linux 向けの拡張された IP ファイアウォーリングチェインソフトウェアをどのように入手し、インストールし、設定し、そして、これを活用するアイディアの幾つかを詳述することを目的とします。 </abstract>  <toc>   <sect>始めに<label id="intro">  この文書は IPCHAINS-HOWTO です。最新版があるマスターサイトは <ref id="intro-where" name="どこ?"> を参照して下さい。 LINUX NET-3-HOWTO も読んだ方がよいでしょう。 IP-Masquerading HOWTO, PPP-HOWTO, Ethernet-HOWTO と Firewall HOTO も面白いでしょう。 (そして、繰り返しますが、 alt.fan.bigfoot FAQ も)。 (訳注: alt.fan.bigfoot FAQ <- [雪男のニュースグループ、ギャグ?])  パケットフィルタリングについて既に知っている人は、 <ref id="intro-why" name="なぜ?"> の章、 <ref id="basics-how" name="どうやって?"> の章を読んで、 <ref id="core" name="IP ファイアウォーリングチェイン"> の章の中のタイトルをざっと眺めてみましょう。  <tt>ipfwadm</tt> から移行したい人は、 <ref id="intro" name="始めに"> の章、 <ref id="basics-how" name="どうやって?"> の章、そして付録内の <ref id="ipfwadm-diff" name="ipchains と ipfwadm との違い"> の章と、 <ref id="upgrade" name="`ipfwadm-wrapper' スクリプトを使う"> の章を読みましょう。  <sect1>何?  Linux <tt>ipchains</tt> は Linux IPv4 ファイアウォーリングのコード (主に BSD からのパクリ)の書き直しであり、<tt>ipfwadm</tt> の書き直しでもあります。その <tt>ipfwadm</tt> は、 BSD の <tt>ipfw</tt> の書き直しでもあると、私は信じています。 Linux バージョン 2.1.102 以降の IP パケットフィルタが、管理に必要です。  <sect1>なぜ?<label id="intro-why">  以前の Linux のファイアウォールのコードは fragment を扱えませんし、 (少なくとも Intel 用では) 32 ビットのカウンタしかありませんし、 TCP/UDP/ICMP 以外の仕様のプロトコルを考慮していませんし、アトミック(瞬間的)に大きく(ルールを)変更することもできませんし、逆ルールを満たせませんし、いくつか妙な癖がありましたし、管理しにくいものでした(利用者のミスを招きやすい)。 (訳注: ここで用いられる「アトミック(原文は `atomically')」は、 ipchains というコマンドの名前の由来にもなっているところだと思います。ユーザ定義チェインに複数のルールを定義しておき、それを既存のチェインに追加したり、或は既存のチェインを新しく定義したチェインと置換することで、一瞬にしてファイアウォールの作用を変更することができます。)  <sect1>どうすれば?  現在、カーネルのコードの主流は 2.1.102 以降です。 2.0 カーネルシリーズでは、 web ページからパッチをダウンロードする必要があります。もし、お手持ちの 2.0 カーネルが web 上にて得られるパッチよりも新しいならば、その古いパッチは多分 OK でしょう。 2.0 カーネルの該当部分はおおよそ安定しています。(例えば、 2.0.34 カーネルのパッチは 2.0.35 カーネルにもしっかり当てられます) 2.0 パッチは ipportfw と ipautofw パッチとの互換性がないので、 ipchains 特有の機能を本当に必要としないならば、パッチの導入はお薦めしません。  <sect1>どこ?<label id="intro-where">  公式ページは3箇所あります。 <url url="http://netfilter.filewatcher.org/ipchains" name="Penguin Computing に感謝します。"> <url url="http://www.samba.org/netfilter/ipchains" name="the SAMBA Team に感謝します。"> <url url="http://netfilter.kernelnotes.org/ipchains" name="Jim Pick に感謝します。">  バグ報告、議論、開発、使い方を話し合うメーリングリストがあります。メーリングリストへの入会には、メッセージに ``subscribe ipchains-list'' を書いて、 east.balius.com にメールして下さい。メーリングリストのメンバー全員にメールを出すには、 east.balius.com の ipchains-list を使って下さい。       <sect>パケットフィルタリングの基礎  <sect1>パケットフィルタとは何をするもの?  ネットワークを通る全てのトラフィックは、パケットの形で送り出されます。例えば、このパッケージ(50Kバイトはあるでしょう)をダウンロードすることで、1460バイトのパケット36個ほどを受信することになるでしょう(実際にはそのときどきによって個数やサイズは異なります)。 (訳注: 現在ではこの文書は100KBを越えています:))  各パケットはそれがどこに向けられたものかを記述する部分から始まり、どこから来たものか、それからパケットの種類と管理上必要な詳細内容を含んでいます。パケットのこの開始部分は、<bf>ヘッダ</bf>と呼ばれています。また、伝送されている実際のデータを含んだパケットの残りの部分は、通常<bf>ボディ</bf>と呼ばれています。    ウェブ・トラフィック、メールとリモートログインのために使われるいくつかのプロトコル(例えば <bf>TCP</bf>)は `接続(コネクション)'とよばれる概念を使います。実際のデータパケットが送り出される前に、`私は、接続したい'、`OK'、そして`ありがとう'といった、(特別なヘッダを伴う)色々なセットアップ・パケットを交換します。  パケット・フィルタは、パケットのヘッダを見て、そのパケット全体をどのように取り扱うかを決定する小さなソフトウェアです。パケットは<bf>拒否(deny)</bf>(すなわち、受信しなかったかのように、パケットを捨てる)ことに決められるかもしれないし、<bf>許可(accept)</bf>(すなわち、パケットを通過させる)することになるかもしれないし、パケットを<bf>返却(reject)</bf>("拒否"と似ているけれど、パケットの発信元にそのことを通知する)するかもしれません。  Linux においては、パケット・フィルタリングはカーネルに組み込まれています。そして、パケットの取扱いに関して少しばかりトリックを仕掛けることができますが、その基本的な規則はあくまでヘッダを見て、パケットの取り扱いを決定するというものです。    <sect1>なぜ?   コントロール。セキュリティ。監視。 <descrip>   <tag/コントロール:/ あなたが Linux ボックスを内部のネットワークと別のネットワーク(例えば、インターネット)を繋ぐために使っているなら、あなたには、特定のトラフィックだけ許可して、他のものを許さないようにするチャンスがあります。例えば、パケットのヘッダーにはあて先アドレスが含まれていて、外部ネットワークのとある所へ向かうパケットを拒否することができます。別の例として、Netscape を使って Dilbert のアーカイブ (訳注: Dilbert というエンジニアが主人公の風刺漫画のサイト、ちなみに dilbert の意味は'ばか') にアクセスする場合です。ページには doubleclick.net の広告があり、 Netscape はそれをいそいそとダウンロードするために私の時間を浪費します。パケットフィルターに doubleclick.net 所有のアドレスからのどんなパケットも許可しないように指示すれば問題は解決します(もっといい方法がありますけれど: Junkbuster (訳注: <url url="http://internet.junkbuster.com" name="http://internet.junkbuster.com"> ) を見て下さい)。   <tag/セキュリティ:/ あなたの Linux ボックスがインターネットの混沌と、秩序正しいあなたのすてきなネットワークの間にある唯一の物なら、すばらしいことに、あなたは殴りにやって来る者をドアのところで制限することができます。例えば、あなたのネットワークから出て行くものは何でも許すようにして、悪意のある外部からのよく知られた `Ping of Death' 攻撃を警戒するようにできます。別の例として、あなたの Linux ボックスに、たとえ全てのアカウントにパスワードが付いているとしても、外部の者が telnet してくることを望まないかもしれません。たぶん、あなたは(大抵の人々のように)インターネットをただ眺めていたいだけで、サーバーに(好むと好まずにかかわらず)なりたくないのです。単純に、パケットフィルターで接続を開始するパケットの流入を拒否して、だれにも接続されないようにして下さい。 (訳注: "死のping" 異常に長大な ICMP パケットなどをネットワーク接続されたコンピュータに送りつけて、システムクラッシュやサービスの停止を引き起こす攻撃のこと。)     <tag/監視:/ ときどきローカルネットワーク中に環境設定の悪いマシンがあり、外の世界にパケットが漏れ出るようになっていることがあります。すばらしいことに、パケットフィルターは何か異常なことが起こったときにあなたに知らせてくれます。それによって何らかの対処ができることを知るか、あるいはただ単に自分が詮索好きな性格だと知るだけかもしれません。 </descrip>    <sect1> どうやって?<label id="basics-how">  <sect2>パケットフィルタリング機能を有効にしたカーネル  新しい IP ファイアウォール・チェーン機能を持つカーネルが必要です。今動作しているカーネルが、この機能を組み込んだものかどうか判断するには、 /proc/net/ip_fwchains を探してみましょう。これが存在するならば、既に組み込まれています。 (訳注: 2.2.x以降のカーネルをお使いの場合は、大抵既に組み込まれていることでしょう。)  もしそうでなければ、あなたは IP ファイアウォール・チェーンを持つカーネルを作る必要があります。最初に、あなたが欲しいカーネルのソースをダウンロードしましょう。あなたのカーネルがバージョン 2.1.102 以降のものなら、現在主流のカーネルであるので、改めてパッチを当てる必要はありません。そうでない時には前出の Web ページからパッチを入手して適用し、そして次に示すような設定でカーネルを構成して下さい。もし、あなたがこれをする方法を知らなくても、慌てないで Kernel-HOWTO を読みましょう。 (訳注: Kernel-HOWTOの邦訳は <url url="http://www.linux.or.jp/JF/JFdocs/Kernel-HOWTO.html" name="http://www.linux.or.jp/JF/JFdocs/Kernel-HOWTO.html"> にあります。)  あなたが2.0-シリーズのカーネルに設定する必要があるコンフィグレーションオプションは、以下の通りです: <code> CONFIG_EXPERIMENTAL=y CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_CHAINS=y </code>  2.1 か 2.2 のシリーズ・カーネルの場合は次の通りです: <code> CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y </code>  ツールである <tt>ipchains</tt> プログラムは、カーネルに対してどんなパケットをフィルタするべきかについて通知するためのものです。あなたがプログラマであるか、奇特な人間でない限り、これがパケットフィルタリングを制御する方法となります。 <sect2> ipchains  <tt>ipchains</tt> ツールは、カーネルのパケット・フィルタリングに関するセクションからルールを挿入したり削除したりします。これは、あなたがたとえ何を設定しても、それが再起動によって消えてしまうことを意味しています。   次回、 Linux がブートされる際に、それらを確実に戻すする方法については、次の節 <ref id="permanent" name="フィルタ規則を恒久的にするには"> を参照して下さい。   <tt>ipchains</tt> は以前までIPファイアウォールを実現するために使われていた ipfwadm と置き換えられることになります。役に立つスクリプトのセットが、次の ipchains のアドレスから入手可能です: <url url="http://netfilter.filewatcher.org/ipchains/ipchains-scripts-1.1.2.tar.gz" name="http://netfilter.filewatcher.org/ipchains/ipchains-scripts-1.1.2.tar.gz">  これには以前行われていたのと同じようなスタイルでパケット・フィルタリングを行わせるための <tt>ipfwadm-wrapper</tt> と呼ばれているシェルスクリプトを含んでいます。あなたが <tt>ipfwadm</tt> (ipchainsと比べ、より遅くて、引数、その他をチェックしない等のもの)を使うシステムをアップグレードする手っ取り早い方法が欲しくない限り、あなたは多分このスクリプトを使うべきではないでしょう。そういう方にはあまりこの HOWTO も必要とはされないことと思います。    <tt>ipfwadm</tt> 関連の詳細については、付録: <ref id="ipfwadm-diff" name="ipchains と ipfwadm との違い"> や付録: <ref id="upgrade" name="`ipfwadm-wrapper'スクリプトを使う"> をご覧下さい。   <sect2> フィルタ規則を恒久的にするには<label id="permanent">  あなたの現在のファイアウォール設定は、カーネルに格納されて、このように再起動時には失われてしまいます。あなたのルールを恒久的にするために `ipchains-save' と `ipchains-restore' スクリプトを使うことをお勧めします。これを使うには、まずあなたのルールを設定して、次のようにコマンドを実行します(root として実行して下さい): <tscreen><verb> # ipchains-save > /etc/ipchains.rules # </verb></tscreen>  スクリプトは次のように作っておきます:  <tscreen><verb> #! /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 </verb></tscreen>  これが起動時の最初のうちに実行されるようにします。筆者のケース (Debian 2.1) では、 `S39packetfilter' というシンボリックリンクを `/etc/rcS.d' ディレクトリに作ってあります(これは、 S40network の前に実行されます)。 (訳注: 「最初のうち」というのは、起動時、ネットワークに対して通信が可能となる状態以前に行うという意味です。ネットワークの他のサービスなどが起動したあとにファイアウオールを設定すると、全く設定されていないわずかな瞬間をついて"悪いやつ"が入り込む危険性があります。)        <sect>もう、混乱して来た! ルーティングだの、マスカレーディングだの、ポートフォワーディングだの、自動フォワーディング(ipautofw)だのって…。  この HOWTO は、パケット・フィルタリングについて述べたものです。それはパケットが通過するのを許すかどうかについて決めることを意味しています。しかしながら、Linuxはいわばハッカー達の遊び場のようなものですので、おそらくそれ以上の機能を実現したいと思うことでしょう。  1つの問題は、本来別な概念であるはずのマスカレーディングと透過的なプロキシの制御のために同じツール (``ipchains'') が使われることです(現在の Linux での実装では、これらが不自然なかたちでいっしょになっており、あたかもそれらが密接に関連があるという印象を与えてしまいます)。 (訳注: カーネル 2.4.x 系では、これらの機能はさらに統合強化されています。それらのカーネルをお使いの方は、Linux 2.4 NAT HOWTO(<url url="http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO.html" name="http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO.html">)もご覧下さい。 JFプロジェクトによる邦訳(<url url="http://www.linux.or.jp/JF/JFdocs/NAT-HOWTO.html" name="http://www.linux.or.jp/JF/JFdocs/NAT-HOWTO.html">)もあります。)  マスカレーディングとプロキシについては別々の HOWTO 文書などによって網羅され、自動フォワーディングとポート・フォワーディング機能は別々のツールで制御されます。しかし、多くの人々からそれらについての問い合わせをうけていますので、ここでは一連の一般的とおもわれるシナリオいくつかと、どのようにすればよいかという設定を提示します。なお、各セットアップのセキュリティに関する長所については、ここで論議しません。  <sect1>Rusty のマスカレーディングに関する 3つの指針  これは、あなたの<bf>外部</bf>インタフェースが `ppp0' であると仮定しています。 ifconfig コマンドをつかって、あなたの環境に合うように読み替えて下さい。 <tscreen><verb> # ipchains -P forward DENY # ipchains -A forward -i ppp0 -j MASQ # echo 1 > /proc/sys/net/ipv4/ip_forward </verb></tscreen>    <sect1>自発的な宣伝: WatchGuard で規制する     市販のファイアウォール専用機を購入することもできます。優れた専用機のひとつとして、WatchGuard 社の FireBox があります。 FireBox が優れていると思うのは、わたしが気に入っているからであり、それが安全だからであり、Linux ベースで動作しているからです。また、この会社は、ipchains のメインテナンスと、(2.4 系カーネル用の)新しいファイアウォールのコードのために資金提供してくれたからです。つまり、わたしが皆さんのために作業をしている間、 WatchGuard 社は、わたしの生活を支えてくれたわけです。そういうわけで、彼らの製品についても御一考願います。 <url url="http://www.watchguard.com" name="http://www.watchguard.com"> (訳注: WatchGuard社の日本国内のリセラーも、このページから手繰ることができます。)  <sect1>ファイアウォール的動作に共通な設定  あなたは、 littlecorp.com というドメイン名でシステムを動かしています。そして内部ネットワークを持ち、インターネットに対して、IPアドレスが 1.2.3.4 である (firewall.littlecorp.com) というコンピュータに1回線のダイヤルアップ(PPP)コネクションを持っています。あなたはイーサネットによるローカルネットワークを構築しており、あなたの個人用コンピュータは "myhost" と呼ばれています。  このセクションでは、一般的とおもわれるいくつかの配置例での設定について詳しく説明します。それらは微妙に異なりますので、注意深く読み進めて下さい。  <sect2>ローカルネットワーク: 伝統的なプロキシ  このシナリオでは、ローカルネットワークからのパケットは、インターネットを行き来することはありません。ローカルネットワークの IP アドレスは、 RFC1918 にてプライベートなインターネット環境のために用意されているアドレス(すなわち 10.*.*.*, 172.16.*.*-172.31.*.* または 192.168.*.*)を割り当てなければなりません。  インターネットに接続する唯一の方法はファイアウォールに接続することで、このコンピュータが両方のネットワーク(訳注: インターネットとローカルネットワーク)に直接つながっています。このファイアウォールの上でプロキシと呼ばれるソフトを動かすことになります(これは FTP 、ウェブ・アクセス、 telnet 、 RealAudio 、 Usenet News や他のサービスについて、"代理"として働きます)。詳細については Firewall HOWTO を見ましょう。 (訳注: "Firewall HOWTO" の原文は <url url="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html" name="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html"> にあります。 JFプロジェクトによる邦訳はまだ作業中です。)  あなたがインターネットへのアクセスで望むサービスについては、必ずファイアウォール上のプロキシでサポートされたサービスでなければなりません(しかし、後述の <ref id="limited-services" name="制限された内部サービス"> を参照して下さい)。  例: プライベートネットワークからインターネットへのウェブ・アクセスを許す <enum>  <item> プライベートネットワークは、192.168.1.*を割り当てられた複数の番地からなり、IPアドレスが192.168.1.100は"myhost"に、ファイアウォールのイーサネット・インタフェースには192.168.1.1が割り当てられています。  <item> ウェブ・プロキシ(例えば"squid")は、ファイアウォールの上にインストールされておりポート8080で動いています。  <item> プライベートネットワークのNetscapeは、プロキシとしてファイアウォールのポート8080を使うように設定されています。  <item> DNSは、プライベートネットワークの中で設定される必要はありません。  <item> DNSは、ファイアウォールの上で設定される必要があります。  <item> デフォルト・ルート(別名、ゲートウェイ)は、プライベートネットワークの中で設定される必要はありません。 </enum>  myhost 上の Netscape から、 http://slashdot.org のページを見る <enum>  <item> Netscape はファイアウォールのポート8080に接続し、 myhost 上のポート1050を使って "http://slashdot.org" のウェブ・ページを見るようにファイアウォールに依頼します。  <item> プロキシは "slashdot.org" という名前を調べて、 "207.218.152.131" というIPアドレスを得ます。それからファイアウォールの外部インタフェース(訳注: ppp0 など)の上でポート1025を使って、その IP アドレスに対してウェブ・サーバ(ポート80)でウェブ・ページを要求します。  <item> 相手のウェブ・サーバに対する接続からウェブ・ページを受け取ると、それはNetscapeへの接続へデータがコピーされます。  <item> Netscapeは、ページを表示します。 </enum>  つまり、 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が接続されることになります。  <sect2>プライベートネットワーク: 透過的なプロキシ  このシナリオでは、ローカルネットワークからのパケットは、インターネットを行き来することはありません。ローカルネットワークの IP アドレスは、 RFC1918 にてプライベートなインターネット環境のために用意されているアドレス(すなわち 10.*.*.* 、 172.16.*.*-172.31.*.* または 192.168.*.*)を割り当てなければなりません。  インターネットに接続する唯一の方法はファイアウォールに接続することで、このコンピュータが両方のネットワーク(訳注: インターネットとローカルネットワーク)に直接つながっています。このファイアウォールの上で"透過的なプロキシ"と呼ばれるソフトを動かすことになりますが、ここではカーネルが出力パケットを外部に送る代りに、透過的なプロキシに送り出すことになります   (すなわち、偽のルーティングを行うようになります)。   透過的なプロキシを動かすということは、クライアントはプロキシの存在を意識しなくてもよいということです。  あなたがインターネットへのアクセスで望むサービスについては、必ずファイアウォール上のプロキシでサポートされたサービスでなければなりません(しかし、後述の <ref id="limited-services" name="制限された内部サービス"> を参照して下さい)。  例: プライベートネットワークからインターネットへのウェブ・アクセスを許す <enum>  <item> プライベートネットワークは、 192.168.1.* を割り当てられた複数の番地からなり、 IP アドレスが 192.168.1.100 は myhost に、ファイアウォールのイーサネット・インタフェースには 192.168.1.1 が割り当てられています。  <item> 透過的なウェブ・プロキシ(squid に対するこの用途のためのパッチがいくつかあると思います。あるいは "transproxy" を試すのもいいかも)はインストールされて、ファイアウォールの上でポート8080にて動いています。  <item> カーネルは ipchains を使ってポート80の接続をプロキシに向けなおすように指示されています。  <item> プライベートネットワークの Netscape は、あたかも直接接続するように設定します。   <item> DNS は、プライベートネットワーク上に設定されている必要があります(すなわち、あなたはファイアウォールの上での「代理」として DNS サーバを実行する必要があります)。 (訳注: つまり、クライアントからの名前解決の処理をすべてプライベートネットワーク内の DNS で賄わなければならないということです。さもないと、名前解決のためのパケットがクライアントからインターネットに出てしまいます。)  <item> ファイアウォールにパケットを送るためにプライベートネットワーク内にデフォルト・ルート(別名、ゲートウェイ)を設定する必要があります。 </enum>  myhost の Netscape から、http://slashdot.org を見る。 <enum>  <item> Netscapeは、 "slashdot.org" という名前を調べて、 207.218.152.131 という IP アドレスを得ます。そして、その IP アドレスに対してポート1050にて接続し、ウェブサーバ(ポート80)へページデータを要求します。  <item> slashdot.org (ポート80)への myhost (ポート1050)からのパケットはファイアウォールを経由しますが、それらはポート8080の上で待っている透過的なプロキシに向け直されます。透過的なプロキシは、 207.218.152.131 のポート80(もともとクライアントからのパケットに指定されていた宛先)に対して、(ローカルなポート1025を使って)接続を行います。  <item> プロキシはその接続によってウェブ・サーバからページを受け取り、 Netscape に対する接続にそのデータをコピーします。  <item> Netscapeは、ページを表示します。 </enum>  つまり、 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までの間で行われています。が、それは実際には透過的なプロキシとやり取りしていることになります。  <sect2>プライベートネットワーク: マスカレーディング   このシナリオでは、ローカルネットワークからのパケットは、特別な扱いがなければインターネットを行き来することはありません。ローカルネットワークの IP アドレスは、 RFC1918 にてプライベートなインターネット環境のために用意されているアドレス(すなわち 10.*.*.* 、 172.16.*.*-172.31.*.* または 192.168.*.*)を割り当てなければなりません。  プロキシを使う代わりに、 "マスカレーディング" と呼ばれる特別なカーネル機能を使います。マスカレーディングは、ファイアウォールを経由したかのようにパケットを書き換えるので、これらのパケットは常にファイアウォール自身からきたように見えます。それから、応答を本来の要求元へ送るように書き換えます。  マスカレーディングはいくつかの "トリッキーな" プロトコルを扱うための個別のモジュールを持っています。例えば、FTP, RealAudio, Quake などです。本当に取り扱いが難しいプロトコルのためには、 "自動フォワーディング" 機能にて、関連したポートの転送を自動的に設定することにより、それらの一部を取り扱うことができます。詳細については ``ipportfw'' (2.0系カーネル)または ``ipmasqadm'' (2.1系カーネル)を調べてみて下さい。  あなたがインターネットへのアクセスで望むサービスについては、必ずファイアウォール上のプロキシでサポートされたサービスでなければなりません(しかし、後述の <ref id="limited-services" name="制限された内部サービス"> を参照して下さい)。  例: プライベートネットワークからインターネットへのウェブ・アクセスを許す <enum>  <item> プライベートネットワークは、 192.168.1.* 上の複数の番地からなり、 myhost には 192.168.1.100 が割り当てられ、ファイアウォールのイーサネットインターフェースには 192.168.1.1 が割り当てられています。  <item> ファイアウォールは、プライベートネットワークからインターネットの上のホストのポート80へのすべてのパケットをマスカレードするよう設定されています。  <item> Netscape は、直接接続するように設定されています。  <item> DNS は、プライベートネットワークの上で正しく設定されていなければなりません。  <item> ファイアウォールは、プライベートネットワークのためのデフォルト・ルート(別名、ゲートウェイ)でなければなりません。 </enum>  myhost の Netscape から、 http://slashdot.org を読む。 <enum>  <item> Netscape は、 "slashdot.org" という名前を調べて、 207.218.152.131 という IP アドレスを得ます。それからローカルなポート1050を使って、その IP アドレスのウェブ・サーバ(ポート80)に対して接続を行い、ウェブ・ページを要求します。  <item> slashdot.org (ポート80)への myhost (ポート1050)からのパケットはファイアウォールに渡され、そこでファイアウォール(ポート65000)の PPP インタフェースから来たかのように書き直されます。 slashdot.org からの応答パケットを返すことが可能となるように、ファイアウォールは有効なインターネットアドレス(1.2.3.4)を持っています。  <item> firewall.littlecorp.com (ポート65000)に対して slashdot.org (ポート80)からのパケットが返され、それらを myhost (ポート1050)へ送るために書き直されます。マスカレーディングを実現するための "魔法" の正体というのは、つまり、応答が来たときに、それを正しく戻せるように、出力パケットを書き換えるときに覚えておくということです。  <item> Netscapeは、ページを表示します。 </enum>  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から行われています。  <sect2>パブリックネットワーク    このシナリオでは、あなたの個人のネットワークはインターネットの一部分です: パケットは変更されることなく両方のネットワークを流れることができます。  内部ネットワークの IP アドレスは、 IP アドレスのブロックを申請することによって割り当てられたもののはずですので、他のネットワークは、どうやってあなたの元へパケットを届けられるかを知っているでしょう。これは継続的に接続されることを意味しています。 (訳注: 例えば、 INTERNIC や JPNIC などに対する正しい手続きによって得られた継続的に使用できる IP アドレスをあなたが所有していなければならないということです。)  この場面でパケット・フィルタリングは、どのようなパケットがあなたのネットワークとそれ以外のインターネットとの間でやり取りされるかを制限するためなどに使われます。例えば、インターネットの他の場所とのパケットのやり取りをあなたのウェブサーバに対してのみに限定させることができます。  プライベートネットワークからインターネットへのウェブ・アクセスを許す <enum>   <item> あなたの内部ネットワークは、あなたが登録した IP アドレス・ブロック(1.2.3.* とします)に応じたアドレスが割り当てられています。  <item> ファイアウォールは、全てのトラフィックを許すよう設定されています。 (訳注: ここで示されたシナリオは説明のための便宜的なケースです。実際のケースでは、次の節("内部サービスの限定")で示されたように、サービスを限定するなど、あなたのネットワークを守るために、出入りするパケットについて適切な許可／拒否のための条件を設定しておかなければなりません。)  <item> Netscapeは、インターネットに直接接続するように設定されています。  <item> DNSは、あなたのネットワークの上で正しく設定されていなければなりません。  <item> ファイアウォールは、プライベートネットワークのためのデフォルト・ルート(ゲートウェイ)でなければなりません。 </enum>  myhost の Netscape から、http://slashdot.org を見る。 <enum>  <item> Netscapeは、 "slashdot.org" という名前を調べて、 207.218.152.131 という IP アドレスを得ます。それからローカルなポート1050を使って、その IP アドレスのウェブ・サーバ(ポート80)に対して接続を行い、ウェブ・ページを要求します。  <item> パケットはあなたのネットワークと slashdot.org の間の他のいくつかのルーターを通り抜けるのと同じように、あなたのファイアウォールを通り抜けてやり取りされます。  <item> Netscapeは、ページを表示します。 </enum>  つまり、この場合は 207.218.152.131 (slashdot.org)ポート80と、 1.2.3.100 (myhost)ポート1050の間のただひとつだけの接続が存在します。    <sect2>制限された内部サービス<label id="limited-services">  外のインターネットからあなたの内部サービスに対して、ファイアウォール上でサービスを実行する以外の方法をとることのできるトリックが少しばかりあります。それらの方法ではプロキシやマスカレーディングを外部のコネクションのために使用するというアプローチをとります。  最も単純なアプローチは "リダイレクター" (それは与えられたポートの上で接続を待つという"貧弱な"プロキシです)を動作させることです。それらはあらかじめ決められた内部ホストとポートに対して接続を行い、データを二つの接続の間でコピーします。 "redir" プログラムを使った例を示すと、外のインターネット側から見ると、接続はあなたのファイアウォールに対して行われます。中のサーバの側から見ると、ファイアウォールとそのサーバに対して接続が行われるようになります。  もう一つのアプローチ(これには ipportfw のためにパッチを当てられた 2.0 系カーネルか、あるいは 2.1 系以降のカーネルが必要です)はカーネルでのポート・フォワーディングを使うことです。これは、 "redir" と同じ動作を別な方法で行います。つまり、カーネルは渡されたパケットに対して、その目的アドレスとポートを内部のホストとポートに対して向けられたように書き換えます。外のインターネット側から見ると、あなたのファイアウォールに対して接続されたように見えます。また、あなたの内部のサーバ側から見ると、インターネット・ホストからサーバまで直接接続されているように見えます。  <sect1>マスカレーディングに対するその他の情報  David Ranch はマスカレーディングに関する優れた新しい HOWTO を書きました。この HOWTO とは多くの重複部分を持ちますが、次のページから見つけることができます。 <url url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html" name="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html">  マスカレーディングの公式ページは次のとおりです。 <url url="http://ipmasq.cjb.net" name="http://ipmasq.cjb.net">      <sect>IP ファイアウォーリングチェイン<label id="core">  この章は、あなたの必要に叶うパケットフィルタを構築するために、実際に知っておかなければならないことを全て説明します。  <sect1>どのようにパケットがフィルタを通過するのか  カーネルは起動時に 3つのルールリストを保持しています。これらのリストは<bf>ファイアウォールチェイン</bf>、または単に<bf>チェイン</bf>と呼ばれます。 3つのチェインは、 <bf>input</bf>, <bf>output</bf> そして <bf>forward</bf> と呼ばれます。  パケットが (例えば、イーサネットカードを通じて) 入って来ると、カーネルはそのパケットの「運命」を決定するために <tt>input</tt> チェインを使います。パケットがこのステップで生き残ると、カーネルはパケットを次にどこに送るかを決定します。(これを<bf>ルーティング</bf>と呼びます。) パケットが他のマシンへ行くと定められているならば、 <tt>forward</tt> チェインを調べます。最後に、パケットが出力される前に、カーネルは <tt>output</tt> チェインを調べます。  1つのチェインは複数の<bf>ルール</bf>のチェックリストから構成されています。各々のルールは「もし、パケットのヘッダーがこんなだったら、パケットをこのようにしなさい」と指示します。もし、あるルールがパケットとマッチしなければ、チェイン内の次のルールが調べられます。最終的に、調べるルールが無くなったら、カーネルはそのチェインの<bf>ポリシー</bf>(方針)を見て何をするか決めます。セキュリティ意識の強いシステムでは、このポリシーは普通、パケットを DROP するようにカーネルに指示します。   ASCII アートファンのために、マシンに入来するパケットの完全な通り道をここに記します。 (訳注: この文書では日本語文字コードを用いた "JIS アート" を作成しております。 <newline> いわゆる全角文字と半角文字が混在する "JIS アート" を、 Netscape Navigator/Communicator や Microsoft Internet Explorer で表示させると、半角文字の幅と全角文字の幅の比が一致しない為に、『ガタガタに崩れた図面』になってしまいます。 <newline> html 版を見る際には、 lynx や w3m 等のテキストブラウザをお薦めします。)  C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|----> _______ --> h a |input | e {Routing } |Chain | |output |ACCEPT e n |Chain | m {Decision} |_______| --->|Chain | c i |______| a ~~~~~~~~ | | ->|_______| k t | s | | | | | s y | q | v | | | u | v e v DENY/ | | v m | DENY/ r Local Process REJECT | | DENY/ | v REJECT a | | | REJECT | DENY d --------------------- | v e ----------------------------- DENY </verb> --> <verb> ┌──────────────────────────────────┐ │ lo インターフェース│ │ ACCEPT/ │ ↓ REDIRECT ┏━━━━━┓ ┌────┐ ACCEPT│ →チ→正→┌────┐→マ→┃ルーティン┃→│forward │──→┌────┐→ ェ当 │ input │ ス ┃グの決定 ┃ │チェイン│┌─→│ output │ ッ性 │チェイン│ カ ┗━━━━━┛ └────┘│┌→│チェイン│ ク │ └────┘ レ │ │ ││ └────┘ サ │ │ ー ↓ │ ││ │ ム │ │ ドローカルプロセス ↓ ││ ↓ │ ↓ ↓ 外 │ DENY/ ││ DENY/ │ DENY DENY/ し │ REJECT ││ REJECT ↓ REJECT │ │ ││ DENY │ └──────────┘│ └────────────────┘ </verb>  以下に各々の段階での説明を逐一記します。 <descrip>  <tag/チェックサム:/ パケットが幾つかの方法にて壊されていないかをテストします。パケットが壊れていれば、否定されます。  <tag/正当性:/ 各々のファイアウォールチェインの前にそれらのパケットの正当性のチェックが一つあります。しかし、 input チェインのそれが最も重要です。幾つかの異常なパケットは規則チェックコードを混乱させる恐れがあります。それらはここで否定されます。 (これが発生すると syslog にメッセージが記録されます。)  <tag/input チェイン:/ パケットがテストされる最初のファイアウォールチェインです。チェインの判断が <tt>DENY</tt> (否定) または <tt>REJECT</tt> (拒絶) でなければ、パケットの動きは続きます。  <tag/デマスカレード(マスカレード外し):/ パケットが以前にマスカレードされたパケットに対する応答なら、マスカレードが外され、 <tt>output</tt> チェインまで一気に処理を飛ばします。 IP マスカレードを使っていなければ、意図的に上記の図から消去できます。  <tag/ルーティングの決定:/ (パケット中の)宛先フィールドはルーティングコードによって、このパケットがローカルプロセスに行くべきなのか (ローカルプロセスの章を参照して下さい) 、リモートマシンに転送されるのか (フォワードチェインの章を参照して下さい) を決定するために調べられます。  <tag/ローカルプロセス:/ マシン上で稼働するプロセスはルーティングの決定の段階の後のパケットを受け取れると共に、パケットを送信できます。 (送信パケットはルーティング決定ステップを経て、 output チェインを通過します。)  <tag/lo インターフェース:/ ローカルプロセスからのパケットがローカルプロセスに行くものならば、それらは `lo' と設定されたインターフェースで output チェインを通り抜け、再び `lo' インターフェースで input チェインに入ります。 lo インターフェースは通常ループバックインターフェースと呼ばれます。  <tag/ローカル:/ パケットがローカルプロセスで生成されたものでないなら、 forward チェインがチェックされ、さもなくば、パケットは output チェインへ行きます。  <tag/forward チェイン:/ このチェインにはこのマシンから他へ転送される全てのパケットが通過します。  <tag/output チェイン:/ このチェインには出力される直前の全てのパケットが通過します。 </descrip>  <sect2>ipchains を使う  先ず、この文書にて扱うお手持ちの ipchains のバージョンを、以下のように参照しましょう: <tscreen><verb> $ ipchains --version ipchains 1.3.9, 17-Mar-1999 </verb></tscreen>  注記として、1.3.4 (`--sport' のような長いオプションがありません) か、 1.3.8 以降をお薦めします; これらは大変安定しています。  個々の事項についてのもっと詳しい説明が必要なら、ipchains にはかなり詳しいマニュアルページ (<tt>man ipchains</tt>) があります。特に詳しく内容を知りたいなら、プログラミングインターフェース(<tt>man 4 ipfw</tt>) か、或は 2.1.x のカーネルソース内の <tt>net/ipv4/ip_fw.c</tt> ファイルを調べると良いでしょう。これらは (明らかに) 信頼できます。  ソースパッケージには Scott Bronson による素晴らしいクィックリファレンスカードもあります。 A4判または US レターサイズの PostScript(TM) の両方があります。  <tt>ipchains</tt> を使って色々なことができます。先ず、全体のチェインを管理する操作。あなたは 3つの組み込み済みチェインである、 <tt>input</tt>, <tt>output</tt>, <tt>forward</tt> (これらは削除できません)から始めます。 <enum>  <item> 新しいチェインを作る (-N) <item> 空のチェインを削除する (-X) <item> 組み込み済みチェインのポリシーを変更する (-P) <item> チェイン内のルールをリストアップする (-L) <item> チェインからルールを全て消し去る (-F) <item> チェイン内の全てのルールのパケットとバイトのカウンターをゼロにする (-Z) </enum>  チェイン内のルールを操作するには様々な方法があります: <enum>  <item> チェインに新しいルールを追加する (-A) <item> チェイン内のある位置に新しいルールを挿入する (-I) <item> チェイン内のある位置のルールを置き換える (-R) <item> チェイン内のある位置のルールを削除する (-D) <item> チェイン内の適合した最初のルールを削除する (-D) </enum>   マスカレーディングに関する操作が少ないながらあります。それらを配置するに相応しい場所の要望の為に <tt>ipchains</tt> に含まれています。 <enum>  <item> 現在のマスカレードされた接続の一覧を表示する (-M -L) <item> マスカレーディングのタイムアウト値を設定する (-M -S) (でも <ref id="no-timeout" name="マスカレーディングのタイムアウト値を設定できません!"> を見て下さい。) </enum>  最後の (そして恐らく最も便利な) 機能は、指定したパケットが指定したチェインを通過するなら、そのパケットがどうなるのかを試しにチェックできることです。  <sect2> あなたのコンピュータが起動する時に見るもの  ipchains コマンドが起動される前 (注意: 幾つかのディストリビューションでは初期化スクリプト内で ipchains を起動しています) は、組み込み済みのルール (`input', `forward' と `output') 以外には何もありません。そして各々のチェインは ACCEPT (許可) のポリシーに設定されています。これは全てを受け入れることと等価です。  <sect2> 単一のルールでの操作  ルールを操作すること ― それは 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 (エコー応答)のパケットでそれに応えます)を発生させるのに使います。これはテストに役立ちます。 <tscreen><verb> # 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 # </verb></tscreen>  ご覧のとおり最初の 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個だけしかないのを分っている場合では、番号を使って以下のように削除できます: <tscreen><verb> # ipchains -D input 1 # </verb></tscreen>  INPUT チェインのルール番号 1 を削除。  2番目の方法は -A コマンドをそっくり写して -A を -D に置き換えたものです。これはルールが複雑なチェインの場合で、例えば、取り除きたいのがルール 37 だと探し当てるためにルールを数えたくない場合に有効です。この場合、次のように使います: <tscreen><verb> # ipchains -D input -s 127.0.0.1 -p icmp -j DENY # </verb></tscreen>  -D の書き方は、 -A (または -I か -R) コマンドの時と正確に同じオプションでなければなりません。もし、同一チェイン中に複数のマッチするルールがあったら、最初のものだけが削除されます。  <sect2>フィルタリングの仕様  これまでに、プロトコルを指定する `-p' オプションと、ソースアドレスを指定する `-s' オプションを見てきましたが、この他にもパケットの特徴を指定する様々なオプションがあります。これから、その概要をあますところなくお話します。  <sect3>ソースと宛先 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' が使えます: <tscreen><verb> # ipchains -A input -s 0/0 -j DENY # </verb></tscreen>  上記の効果は `-s' オプションを指定しないのと全く同じなので、こんな使い方はめったにしません。  <sect3>否定の指定  `-s' と `-d' を含む多くのフラグは、`!' (否定の宣言) をその引数の前に置くことができます。 `-s' や `-d' の場合は与えられたアドレスと等しくないアドレスとマッチします。例えば、 `-s ! localhost' はローカルホストからでない全てのパケットとマッチします。  `!' の前後にスペースを入れるのを忘れないで下さい。本当に必要なのです。  <sect3>プロトコルの指定  プロトコルは `-p' フラグで指定します。プロトコルの値は番号(あなたが IP のプロトコルの数値番号を知っている場合)か `TCP', `UDP' または `ICMP' という特定の名称で指定します。大文字小文字の区別はしませんから、`tcp' も `TCP' と同じ働きをします。  プロトコル名称はそれを否定するために `!' を前に付けることができます。例えば、`-p ! TCP' は TCP でないパケットを指定します。  <sect4>UDP と TCP ポートの指定  特別な場合である TCP 或は UDP のプロトコルが指定された時には、 TCP 或は UDP のポート、或は含まれるポートの範囲 (しかし、後述の <ref id="handling-fragments" name="フラグメントの処理">を参照して下さい) を指し示す拡張引数が存在し得ます。範囲は文字 `:' で表現します。例えば `6000:6010' は 6000 から 6010 迄の範囲に含まれる11個のポート番号を示します。もし下限値が省略されれば、デフォルトの 0 を意味します。上限値が省略されれば、デフォルトの 65535 を意味します。ですから、1024番以下のポートの TCP 接続を指定するには、書き方は `-p TCP -s 0.0.0.0/0 :1023' とします。ポート番号は `www' のように、名前でも指定できます。  注記として、ポート指定の前には否定を意味する `!' を置くことができます。ですから、 WWW パケット以外の全ての TCP パケットを指定するには、以下のように指定します。 <verb> -p TCP -d 0.0.0.0/0 ! www </verb>  以下の指定と、 <verb> -p TCP -d ! 192.168.1.1 www </verb>  以下の指定は全く違うことをしっかり認識して下さい。 <verb> -p TCP -d 192.168.1.1 ! www </verb>  最初の例は、 192.168.1.1 以外の全てのマシンの WWW ポートへの TCP パケットを指定します。次の例は、 WWW ポートを除く全てのポートにおける 192.168.1.1 への TCP 接続を指定します。  最後に、このケースは WWW ポートでなく、 192.168.1.1 でもないことを意味します: <verb> -p TCP -d ! 192.168.1.1 ! www </verb>  <sect4>ICMP タイプとコードの指定  ICMP にもまたオプション引数がありますが、 ICMP はポートを持ち得ません。 (ICMP には<bf>タイプ</bf>と<bf>コード</bf>があります) それらには異なる意味があります。  `-s' オプションの後に ICMP ネームを用いる (<tt>ipchains -h icmp</tt> を用いて、ネームを一覧表示します) か、 ICMP タイプとコードの数値を用いるかで、それらを指定します。タイプは `-s' オプションの後に、コードは `-d' オプションの後に指定します。  ICMP ネームはかなり長いです: 他とはっきり区別できる分だけの長い文字列であれば十分です。  最も一般的な ICMP パケットの小さな一覧を以下に示します:  <tscreen><verb> 番号ネーム必要とされるもの 0 echo-reply ping 3 destination-unreachable 全ての TCP/UDP トラフィック 5 redirect ルーティングデーモンが動作していない時のルーティング 8 echo-request ping 11 time-exceeded traceroute </verb></tscreen>  ICMP ネームは `!' を置けないことに注意して下さい。  絶対に絶対に絶対に、 ICMP タイプ3 メッセージの全部をブロックしないで!! (後述の<ref id="ICMP" name="ICMP パケット">を参照して下さい)  <sect3>インターフェイスの指定  `-i' オプションはマッチすべき<bf>インターフェイス</bf>の名前を指定します。インターフェイスとは、パケットが入って来るか、または出て行く物理デバイスです。<tt>ifconig</tt> コマンドを使って `up' である (すなわち、今動いている)インターフェイスをリストアップできます。  入来するパケット (すなわち、 <tt>input</tt> チェインを通過するパケット) のインターフェースは、それらが流れ込んで来るインターフェースであるものと見なされます。論理的には、出て行くパケット (<tt>output</tt> チェインを通過するパケット) のインターフェースは、それらが出て行くであろうインターフェースであります。 <tt>forward</tt> チェインを通過するパケットのインターフェースもまた、それらが出て行くであろうインターフェースです; 私には、これは全くの独断に思えます。 (訳注: ここで著者は forward チェインのインターフェースを出力インターフェースにしたことに抗議しているように思えます。たぶん著者は入力と出力の両方指定できたほうがよいと思っていて、でも、 ipchains にはインターフェイスを指定するオプションが -i の１つしかないので、どちらかにせざるおえなかった。と言う話だと思います。 ipchains の後継である iptables では、 FORWARD チェインで、入力と出力の両方のインターフェイスを指定できるようになってます。)  現在存在していないインターフェイスを指定することは全く問題がありませんが、指定したインターフェイスが up して来るまでルールがマッチすることはありません。これはダイアルアップ PPP リンク(通常インターフェイスは <tt>ppp0</tt> )や同様のものについて非常に有効です。   特別なケースとして、インターフェース名の最後が `+' で終わるものは、 (現在存在していようとなかろうと) その文字列から始まる全てのインターフェースにマッチします。例えば、全ての PPP インターフェースにマッチするルールを指定するには、 <tt>-i ppp+</tt> オプションが使えます。   指定したインターフェイスと一致<bf>しない</bf>パケットにマッチするようにインターフェイス名の前には `!' を置くことができます。   <sect3>TCP SYN パケットのみを指定する  一方向だけ TCP コネクションを許可し、他方は許可しないようにすることは往々にして有効です。例えば、あなたが外部の WWW サーバーと接続したいが、そのサーバーからの接続を許可したくないときです。   そのサーバーから来る TCP パケットをブロックすることは自然な方法です。残念なことに、TCP コネクションにはとにかく両方向のパケットが行き来することが必要です。   その解決方法は、コネクション要求に用いられるパケットのみをブロックすることです。このようなパケットは <bf>SYN</bf> パケットと呼ばれます。 (技術的には、SYN フラグが設定されていて、 FIN と ACK フラグがクリアされているパケットを指しますが、我々はこれを SYN パケットと呼びます。) それらのパケットだけを許可しないことで、その場の接続要求を止められます。   `-y' フラグはこのために使われます: これは TCP プロトコルを指定されている場合においてのみ有効です。例えば、 192.168.1.1 から要求される TCP コネクションを指定するには: <verb> -p TCP -s 192.168.1.1 -y </verb>  もう一度、このフラグはその前に `!' を置くことによって (訳注: ! -y として) 否定することができ、それは接続開始のパケットを除く全てのパケットを意味します。  <sect3>フラグメントの処理<label id="handling-fragments">  時に、一度にケーブルに送り出すにはパケットが大き過ぎることがあります。こんなときは、パケットは<bf>フラグメント</bf>に分割され、複数のパケットで送られます。受信点でこれらのフラグメントを再び集めて完全なパケットに再構成します。  フラグメントの問題点は、先程リストアップした仕様の幾つか (特に、ソースポート、宛先ポート、 ICMP タイプ、 ICMP コード、或は TCP SYN フラグ) は、カーネルに、最初のフラグメントにだけ含まれているパケットの始めの部分を覗くように要求している点にあります。  あなたのマシンが外部ネットワークにのみ接続されるなら、カーネルの "IP: 常にデフラグメントする" を Y に設定してコンパイルすることにより、通過する全てのフラグメントを再構築するように Linux カーネルに命ずることができます。これは問題をうまく回避します。  そうでなければ、フィルタリングルールがフラグメントをどのように扱うかを理解することが重要です。情報が無ければどんなフィルタリングルールもマッチしません。この意味するところは 1番目のフラグメントは他のパケットと同じように扱われます。 2番目以降のフラグメントは異なります。従って、 <tt>-p TCP -s 192.168.1.1 www</tt> というルール (ソースポートが `www' の指定)は、フラグメント(1番目のフラグメント以外)と決してマッチしません。同様に否定のルール <tt>-p TCP -s 192.168.1.1 ! www</tt> もマッチしません。  とはいえ、`-f' フラグを用いて、 2番目及びそれ以降のフラグメントに合致するルールを指定できます。明らかに、このようなフラグメントルールには TCP や UDP ポート、 ICMP タイプ、 ICMP コード或は TCP SYN フラグを指定するのは間違いです。  また、`!' を `-f' の前に付けて、 2番目以降のフラグメントと適合しないルールの指定もできます。  通常、フィルタリングは 1番目のフラグメントに効力があるので、目的のホストでのフラグメントの再組み立てを妨げるため、2番目以降のフラグメントを通過させることは安全とみなされています。とはいえ、フラグメントを送ることにより簡単にマシンをクラッシュさせることができるバグが知られています。調べて下さいね。    ネットワーク管理者のための注記: 異常なパケット(TCP, UDP および ICMP のパケットで短すぎてファイアーウォールのコードがポート番号または ICMP のコードと種類を読めないもの)は、フラグメントと同様に取り扱われます。フラグメントの位置が 8 から始まるTCP パケットだけが明白にファイアウォールコードによって破棄されます。(これが発生すると syslog にメッセージが現れます。)  例えば、次のルールは 192.168.1.1 へ行くフラグメントはどれでも破棄します: <tscreen><verb> # ipchains -A output -f -d 192.168.1.1 -j DENY # </verb></tscreen>  <sect2>フィルタリングの副次的効果  さて、今我々はルールを用いてパケットにマッチさせる方法の全てを知りました。パケットがルールにマッチすると、以下に記すことが起こります: <enum>  <item> 該当するルールのバイトカウンタはパケットのサイズ(ヘッダとその他全て) によって増加します。  <item> 該当するルールのパケットカウンタがパケットの数によって1 加算されます。  <item> ルールが要求するなら、パケットがログに記録されます。  <item> ルールが要求するなら、パケットの Type Of Service (TOS) フィールドが変更されます。  <item> ルールが要求するなら、パケットに印が付けられます。(2.0 カーネルシリーズにはありません。)  <item> パケットに対し、次に何を行わせるかを決定するべく、ルールターゲットが検査されます。 </enum>  これら以外の種類については、重要度に応じて手を付けたいと思います。  <sect3>ターゲットの指定<label id="target-spec">  <bf>ターゲット</bf>はルールにマッチするパケットに対し何をすべきかをカーネルに指示します。 ipchains はターゲットの指定に `-j' を用います。(`ジャンプする'と考えて下さい) ターゲット名は 8文字以下でなければならず、また大小文字を区別します: "RETURN" と "return" は全く別物です。  最も単純なケースは指定されるターゲットが全くない場合です。このルールのタイプ (しばしば `計数' ルールと呼ばれます) は単純に一定のパケットのタイプをカウントするのに便利です。このルールにマッチするか否かにかかわらず、カーネルは単純にチェイン内の次のルールを検査します。例えば、 192.168.1.1 からのパケットの数を数えるには、以下のようにできます: <tscreen><verb> # ipchains -A input -s 192.168.1.1 # </verb></tscreen>  (`ipchains -L -v' を用いて、各々のルールに関連付けられたバイト及びパケットカウンタを見れます。)  6つの特別なターゲットがあります。最初の 3つの <tt>ACCEPT</tt>, <tt>REJECT</tt> と <tt>DENY</tt> はとても単純です。 <tt>ACCEPT</tt> はパケットの通過を許可します。 <tt>DENY</tt> はあたかもパケットを受け取っていないかのように破棄します。 <tt>REJECT</tt> はパケットを破棄しますが、(もしそれが ICMP パケットでないなら) 宛先は未到達であることを知らせる ICMP 返答を、ソースに対して生成します。  次の一つ、 <tt>MASQ</tt> はカーネルにパケットをマスカレードすることを知らせます。これを動作させるには、カーネルが IP マスカレーディングを有効にしてコンパイルされている必要があります。詳細については、 Masquerading-HOWTO と、付録の<ref id="ipfwadm-diff" name="ipchains と ipfwadm との違い">を見て下さい。このターゲットは <tt>forward</tt> チェインを通過するパケットにおいてのみ有効です。  他の主要な特別なターゲットは、カーネルに対して、何処から発生したかを問わずにパケットをローカルポートへ送る、 <tt>REDIRECT</tt> です。これはプロトコルに TCP または UDP を指定しているルールにおいてのみ指定できます。任意に、ポート (名前又は番号) は `-j REDIRECT' と指定できます。これはパケットが他のポートへアドレスされていたとしても特定のポートへ転送させる効果を持ちます。このターゲットは <tt>input</tt> チェインを通過するパケットにおいてのみ有効です。  最後の特別なターゲットは <tt>RETURN</tt> で、直ちにチェインの最後に落し込むことと等価です。(後述の<ref id="policy" name="ポリシーを設定する">を参照して下さい。)  他のターゲットはユーザー指定のチェインを示します。 (後述の<ref id="chain-ops" name="チェインの操作">で説明しています。) パケットはそのチェイン内のルールを通過し始めます。そのユーザ定義チェインでの検査が全て終ってもパケットの運命が決まらなければ、現在のチェインに戻り、その次のルールから検査を再開します。  ASCII アートの時間です。2つの(おばかさんな)チェイン: <tt>input</tt> (組み込み済みチェイン)と <tt>test</tt> (ユーザ定義チェイン)で考えましょう。   <verb> `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 │ └──────────────┘ </verb>   192.168.1.1 から来て 1.2.3.4 へ向かう TCP パケットについて考えましょう。パケットは <tt>input</tt> チェインに入り、まず、ルール 1 が検査されます ― マッチしません。ルール 2 がマッチして、そのターゲットは <tt>Test</tt> なので、次に検査されるルールは <tt>Test</tt> の先頭です。 <tt>Test</tt> のルール 1 はマッチしますが、ターゲットを指定していないので、次のルールであるルール 2 が検査されます。これはマッチしないので、チェインの終わりに達しました。先程検査したルール 2 のある <tt>input</tt> チェインに戻り、それで今度はルール 3 が検査されますが、これもまたマッチしません。   それで、パケットの経路は次のようになります:  <verb> v __________________________ `input' | / `Test' v ┌───────────|─/ ┌──────────|─┐ │ルール 1 | /│ │ルール 1 | │ ├───────────|/-┤ ├──────────|─┤ │ルール 2 / │ │ルール 2 | │ ├───────────-─┤ └──────────v─┘ │ルール 3 /─┼─\_______________________/ └───────────|─┘ v </verb>   ユーザ定義チェインを効果的に使う方法は、<ref id="organisation" name="ファイアウォールルールをどのように構築するか">の章を参照して下さい。  <sect3>パケットのログ記録  これはルールにマッチすることの副次的効果です; マッチしたパケットを `-l' フラグを用いてログに記録することができます。普通、通常のパケットにおいてログを記録したくはないでしょうけど、例外的なイベントを見たい時に便利な特徴です。  この情報のカーネルのログは以下のような感じです: <tscreen><verb> 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 </verb></tscreen>  このログメッセージは簡潔に設計されており、ネットワークの権威者の為だけに便利な技術情報を含んでいますが、あとの我々にも有用です。簡単に説明すると以下のようになります: <enum>  <item> `input' はパケットにマッチしたルールを含むチェインで、ログメッセージを発生しています。  <item> `DENY' はルールがパケットに何をするかを示しています。もしこれが `-' なら、ルールはパケットに何も行いません。 (計数ルールです。)  <item> `eth0' はインターフェース名です. 何故ならばこれは input チェインであり, パケットは `eth0' から入って来たことを意味するからです。  <item> `PROTO=17' はパケットがプロトコル 17 であったことを意味します。プロトコル番号のリストは /etc/protocols にて与えられます。最も一般的なものは 1 (ICMP), 6 (TCP) と 17 (UDP) です。  <item> `192.168.2.1' はパケットのソース IP アドレスは 192.168.2.1 であったことを意味します。  <item> `:53' はソースポートはポート 53 番であったことを意味します。 `/etc/services' を見れば、これが `domain' ポートであることを開示しています。(すなわち、これは恐らく DNS の返答です。) UDP と TCP においては、この番号はソースポートです。 ICMP においては、 ICMP タイプです。それ以外では、 65535 になるでしょう。  <item> `192.168.1.1' は宛先 IP アドレスです。  <item> `:1025' は宛先ポートは 1025 であったことを意味します。 UDP と TCP においては、この番号は宛先ポートです。 ICMPにおいては、 ICMP コードです。それ以外では、 65535 になるでしょう。  <item> `L=34' は、パケットは合計 34 バイト長であったことを意味します。  <item> `S=0x00' は TOS フィールドを意味します。 (4 で割って、 ipchains で用いられるサービスの型が得られます。)  <item> `I=18' は IP の ID です。  <item> `F=0x0000' は 16 ビットのフラグメントオフセットとフラグの加算です。 `0x4' 又は `0x5' で始まる値は「フラグメントしていない」ビットが設定されていることを示します。 `0x2' 又は `0x3' は `更にフラグメントしている' ビットが設定されていることを示します; この後に更なるフラグメントが予測されます。残りの数値はこのフラグメントのオフセットで、それは 8 で割った値です。  <item> `T=254' はパケットの寿命時間です。この値は全てのホップ毎に減じられ、大概 15 か 255 で始まります。  <item> `(#5)' は、ブラケット内の最後の番号がそれより新しいカーネルであろうことを示します。(恐らく 2.2.9 以降でしょう。) 最後に、より新しいカーネル(たぶん 2.2.9 以降)で、括弧で囲まれた番号があるでしょう。 (訳注: 原文には This is the rule number which caused the packet log. と書かれていますが、これは finally there may be a number ... と思われます。) </enum>  標準的な Linux システムでは、カーネルの出力は klogd (カーネルロギングデーモン) にて捕捉され、 syslogd (システムロギングデーモン) に渡されます。 `/etc/syslog.conf' は、各々の `facility' (我々の場合は、facility は "カーネル"です) の宛先と、 `level' (ipchains の為に、使われる level は "info" です)を指定することによって、 syslogd の振る舞いを制御します。   例えば、私の (Debian) /etc/syslog.conf は `kern.info' にマッチする 2行を含んでいます: <tscreen><verb> kern.* -/var/log/kern.log *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages </verb></tscreen>  これらはメッセージが `/var/log/kern.log' と `/var/log/messages' に複製されることを示しています。詳細は `man syslog.conf' を見て下さい。  <sect3>サービスの型を操作する  IP ヘッダには滅多に使われない 4つのビットがあり、<bf>「サービスの型」</bf> (TOS) ビットと呼ばれています。それらはパケットが取り扱われる用途に影響します; 4つのビットは "Minimum Delay"(最小遅延), "Maximum Throughput" (最大処理能力), "Maximum Reliability"(最大信頼値) そして "Minimum Cost" (最小コスト) です。それらのビットの一つだけが設定を許されます。 TOS 操作コードの作者の Rob van Nieuwkerk は以下のように述べています: <quote>  特に "Minimum Delay"(最小遅延) が私にとって重要です。私は上流の (Linux) ルータで"対話型"パケットの為にこのスイッチをオンしています。私のマシンは 33.6k モデムで外部と接続されています。 Linux はパケットに 3つのキューで優先順位を付けています。この方法で私は大量のダウンロードと同時に許容できる対話的なパフォーマンスを得ています。 (これはシリアルドライバにそのような巨大なキューがなければ良いのですが、待ち時間は1.5秒に落されます。) </quote>  注意: 明らかに、あなたは入って来るパケットに対して制御はできません。あなたは自身の Linux box を去っていくパケットの優先順位だけを制御できます。他の方法で優先順位をやりくりするなら、 RSVP のようなプロトコルが必要です。(これに関しては私は何も知らないので、私には聞かないで下さい。)  最も一般的な使用方法は telnet と ftp のコントロールコネクションに "Minimum Delay" を設定し、 FTP データに "Maximum Throughput" を設定するものです。以下のようになります: <tscreen><verb> 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 </verb></tscreen>  `-t' フラグは 2つの特別なパラメータを持ち、それらは16進で指定します。それらはTOS ビットを複雑にいじくり回します: 最初のマスクはパケットの現在の TOS に AND (論理積)されます。 2番目のマスクはそれに対して XOR (排他的論理和)されます。これで激しく混乱するのでしたら、以下の一覧を使って下さい:  <tscreen><verb> TOS 名値一般的な用途 Minimum Delay 0x01 0x10 ftp, telnet Maximum Throughput 0x01 0x08 ftp-data Maximum Reliability 0x01 0x04 snmp Minimum Cost 0x01 0x02 nntp </verb></tscreen>  Andi Kleen は以下のように指摘しています。 (後々に残すために表現を軟らかくしています。) <quote>  多分、TOS ビットの議論については、 ifconfig の txqueuelen パラメータの参照を追加するのに便利でしょう。デバイスのキュー長の初期値はイーサネットカードの為に調整され、モデムにおいてはそれは長すぎて、 (TOSに則ったキューの) 3バンドのスケジューラを作成し、それらの働きは微々たるものです。モデムやシングル b チャネルの ISDN 接続において、この値を 4-10 の間に設定するのは良いと思います; 太いデバイスならより長いキューが必要です。これはカーネルバージョン 2.0 と 2.1 の問題でしたが、 2.1 においてそれは (最新の nettools を用いて) ifconfig フラグで可能になり、 2.0 においてはデバイスドライバのソースにパッチを適用して可能になります。 </quote>  ですので、モデムでの PPP 接続における TOS 操作の最大の恩恵を得るには、あなたのマシンの /etc/ppp/ip-up スクリプト内で `ifconfig $1 txqueuelen' を実行することです。これを使う際の値はモデムの速度とモデム内のバッファの総量に依存します; 以下に Andi の私への返答をそのまま再度掲載します: <quote>  与えられたコンフィギュレーションの最適値は経験が必要です。もしルータ上のキューが短すぎると、パケットを取りこぼしてしまいます。そして勿論 TOS の書き換えもなく効果を得ることになり、単に TOS の書き換えは非協力的なプログラムに効果をもたらします。 (しかし全ての標準的な Linux システムプログラムは協力的です。) </quote>  <sect3>パケットのマーキング  これは Alexey Kuznetsov による新たな"高品質通信"の実装によって、複雑で強力な相互作用を有効にします。 2.1 シリーズカーネル以降のmarkベースのフォワーディングと同様に良好です。更なるニュースとしてはこれが使えるようになったことです。このオプションは 2.0 カーネルシリーズでは全く無視されます。 (訳注: Quality of Service は、 QoS と略され、ネットワーク流量制限を指します。これはカーネルのコンフィギュレーションスイッチに CONFIG_NET_QOS として存在します。)   <sect3>チェインの操作<label id="chain-ops">  ipchains のとても有効な特徴は、チェイン中の関連するルールをグループ化できることです。お望みのチェインは何でも呼び出せますが、組み込み済みチェイン (<tt>input</tt>, <tt>output</tt> と <tt>forward</tt>) やターゲット (<tt>MASQ</tt>, <tt>REDIRECT</tt>, <tt>ACCEPT</tt>, <tt>DENY</tt>, <tt>REJECT</tt> 或は <tt>RETURN</tt>) を壊さない為に、十分長い名前を使って下さい。将来の拡張に備えて、ラベル名の全部に大文字を使わないことをお勧めします。チェインの名前は最大 8文字まで使えます。  <sect3>新しいチェインを作る  新しいチェインを作りましょう。私はとっても創造力に富んだ野郎なので、それを <tt>test</tt> と名付けます。  <tscreen><verb> # ipchains -N test # </verb></tscreen>  これは簡単です。さて、あなたはこれまで詳細に述べてきたように、これにルールを入れることができます。   <sect3>チェインを削除する  チェインを削除するのも同様に簡単です。 <tscreen><verb> # ipchains -X test # </verb></tscreen>  なぜ `-X' かって? うーん、よい文字が全て取られてしまったのです。   チェインを削除するには 2つの制限があります: そのチェインは空である必要があり(後述の<ref id="flushing" name="チェインを空にする">を見て下さい)、しかも、決してどのルールのターゲットにもなっていないことです。組み込み済みの 3つのチェインはどれも削除できません。   <sect3> チェインを空にする<label id="flushing">  チェインから全てのルールを取り去り空にするのは簡単で、`-F' コマンドを使います。  <tscreen><verb> # ipchains -F forward # </verb></tscreen>  もし、チェイン名を指定しなければ、全てのチェインを空にします。  <sect3>チェインの内容をリストアップする  チェイン中の全てのルールをリストアップするには、`-L' コマンドを使います。  <tscreen><verb> # 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 # </verb></tscreen>  <tt>test</tt> に表示されている `refcnt' は、<tt>test</tt> をターゲットに指定しているルールの数です。この数が 0 でないと(かつチェインが空であること)、そのチェインを削除することはできません。   もし、チェイン名を指定しなければ、空のも含めて全てのチェインについてリストアップされます。   `-L' には 3つのオプションがあります。 (大抵の人々は DNS を使っていますが) DNS が適切に設定されていない場合や DNS の要求をフィルターアウトしている場合は、 <tt>ipchains</tt> が IP アドレスを調べようとするときに長く待たされます。それを防ぐのに `-n' (数値)オプションはとても有効です。このオプションは TCP や UDP ポートについても名前ではなく番号で表示します。   `-v' オプションはルールの詳細を全て、例えば、パケットやバイトのカウンター、TOS マスク、インターフェイス、そしてパケットマークを表示します。このオプションを指定しなければ、これらの値は省略されます。  <tscreen><verb> # 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 </verb></tscreen>  注記として、パケットとバイトのカウンターは、1000, 1,000,000 および 1,000,000,000 を、それぞれ `K', `M' および `G' の接尾辞を使って表示します。 `-x' (拡張数値)オプションを使うと、値の大きさにかかわらず完全な数値を同様に表示します。   <sect3>カウンターを(ゼロに)リセットする  カウンターをリセットできると便利です。これは `-Z' (カウンタをゼロにする) オプションでできます。例えば:  <tscreen><verb> # 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 # </verb></tscreen>  このやり方では、リセットする直前のカウンタ値を知る必要があるときに問題になります。上記の方法では、`-L' から `-Z' コマンドまでの間にいくつかのパケットが通過するかもしれません。そのため、カウンターを読むと同時にリセットするには、`-L' と `-Z' を 同時に使います。残念ながら、あなたがこれを使うと、単一のチェインを操作できません: 一旦全てのチェインをリストアップしてゼロにする必要があります。 <tscreen><verb> # 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 # </verb></tscreen>  <sect3>ポリシーを設定する<label id="policy">  以前にパケットがどのようにチェインを通り抜けるのかを、前述の <ref id="target-spec" name="ターゲットの指定">にて論じたとき、パケットが組み込み済みチェインの終わりに達した時に何が起きるのかを大体述べました。この場合、チェインの<bf>ポリシー</bf>がそのパケットの運命を決定します。組み込み済みチェイン(<tt>input</tt>, <tt>output</tt> および <tt>forward</tt>)だけがポリシーを持っています。なぜなら、パケットがユーザ定義チェインの終わりまで下り落ちると、前のチェインに戻って行くからです。   ポリシーは最初から 4つまでの特別なターゲットのいずれかです: <tt>ACCEPT</tt>, <tt>DENY</tt>, <tt>REJECT</tt> 或は <tt>MASQ</tt> です。 <tt>MASQ</tt> は `forward' チェインにおいてのみ有効です。  また、重要な注意点として、組み込み済みチェイン中のルールにおける <tt>RETURN</tt> ターゲットは、パケットがルールにマッチした時に明示的にチェインのポリシーをターゲットにするため便利です。  <sect2>マスカレーディングの操作  IP マスカレーディングを微調整する幾つかのパラメータがあります。それらは <tt>ipchains</tt> に組み込まれています。何故なら、その機能の為に別のツールを書くのは良くないからです。 (しかしこれは変更されるでしょう。)  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 の為に変更する最初の値です。 (後述の<ref id="ftp" name="FTP の悪夢">を参照して下さい。)  <ref id="no-timeout" name="マスカレーディングのタイムアウト値を設定できません!">に列挙したタイムアウトの設定に関する問題に注意して下さい。  <sect2>パケットをチェックする  時にあなたのマシンに一定のパケットが入り込む際に何が起こるのかを見たいと思うことでしょう。あなたのファイアウォールチェインをデバッグする時など。 <tt>ipchains</tt> はこれを有効にさせる `-C' コマンドを装備しています。その際、カーネルが本当のパケットを診断するのに用いるルーチンと正確に同じルーチンを用います。  パケットをテストするチェインは、引数 `-C' の後にパケットのテストをするチェインの名前を指定します。カーネルは常に <tt>input</tt>, <tt>output</tt> または <tt>forward</tt> チェイン、と移って行きますが、テストはどのチェインからでも始めることができます。  `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 の接続開始の入来です) <tscreen><verb> # ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www packet accepted # </verb></tscreen>  <sect2>一度に複数のルールと何が起こるのかを見る  時に単一のコマンドラインが複数のルールに影響させることができます。これには二つの方法があります。最初に、(DNS を用いて)複数の IP アドレスに解決するホスト名を指定すると、 <tt>ipchains</tt> はあなたが各々のアドレスの組み合わせに対して複数のコマンドを発行したのと同じように振る舞います。  ですから、もしホスト名 `www.foo.com' が 3つの IP アドレスに解決し、ホスト名 `www.bar.com' が 2つの IP アドレスに解決する場合、コマンド `ipchains -A input -j reject -s www.bar.com -d www.foo.com' は、 <tt>input</tt> チェインに 6つのルールを追加することとなります。  <tt>ipchains</tt> に複数の動作を行わせるもう一つの方法は、双方向フラグ(`-b') を用います。このフラグは、 <tt>ipchains</tt> にコマンドを 2回入力させたのと同様に振る舞わせます。その際の 2回目のコマンドは `-s' と `-d' の引数を反転させたことになります。ですので、 192.168.1.1 に相互にフォワードさせることを禁じさせるには、以下のようにできます: <tscreen><verb> # ipchains -b -A forward -j reject -s 192.168.1.1 # </verb></tscreen>  個人的には、 `-b' オプションは好きでないです; もっと便利にしたいなら、後述の<ref id="ipchains-save" name="ipchains-save を使う">を見て下さい。  -b オプションは挿入 (`-I') 、削除 (`-D') (でもルールナンバーの拡張ではありません。) 、追加 (`-A') とチェック (`-C') コマンドと共に使えます。  もう一つの便利なフラグに `-v' (冗長な) があります。これは <tt>ipchains</tt> があなたのコマンドによって何をしているのかを正確にプリントアウトします。あなたが複数のルールをコマンドを施しているのなら、これが便利です。例えば、以下は 192.168.1.1 と 192.168.1.2 との間でフラグメントの振る舞いをチェックする例です。 <tscreen><verb> # 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 # </verb></tscreen>  <sect1> 実例集  私の PC はインターネットへダイヤルアップ PPP 接続されます。 (<tt>-i ppp0</tt>) 私はダイヤルアップの度毎にネットニュース (<tt>-p TCP -s news.virtual.net.au nntp</tt>) とメール (<tt>-p TCP -s mail.virtual.net.au pop-3</tt>) を PC に取り込みます。私は Debian の FTP による PC の更新作業を定期的に行います。 (<tt>-p TCP -y -s ftp.debian.org.au ftp-data</tt>) 私は ISP のプロキシを介して web へのアクセスを行います (<tt>-p TCP -d proxy.virtual.net.au 8080</tt>) が、 Dilbert アーカイヴ上の doubleclick.net からの広告バナーを嫌います。 (<tt>-p TCP -y -d 199.95.207.0/24</tt> と <tt>-p TCP -y -d 199.95.208.0/24</tt>)  私は PC がオンラインの際に誰かが私の PC に対して ftp を試みることに関しては気にしません。 (<tt>-p TCP -d $LOCALIP ftp</tt>) けれども、外部の誰かに私の内部ネットワーク (<tt>-s 192.168.1.0/24</tt>) の IP アドレスを偽装されたくありません。これは通常、 IP スプーフィング (訳注: 偽装) と呼ばれ、バージョン 2.1.x 以降のカーネルにはこれを防ぐ良い方法があります: <ref id="antispoof" name="IP 偽装保護(IP Spoof Protection)を、どのように設定したらよいですか?">を参照して下さい。  このセットアップはとても単純で、何故なら今私の内部ネットワーク上には他にマシンがないからです。  私はあらゆるローカルプロセス(すなわち、ネットスケープ、 lynx 等) を doubleclick.net に接続させたくありません。 <tscreen><verb> # ipchains -A output -d 199.95.207.0/24 -j REJECT # ipchains -A output -d 199.95.208.0/24 -j REJECT # </verb></tscreen>  さて、私は外へ出て行く様々なパケットに優先順位を設定したいです。 (入って来るパケットに対してこれを行う多くのメリットはありません。) これらのルールが多数あるので、<tt>ppp-out</tt> と名付けたチェインにそれら全てを入れることは意味のあることです。 <tscreen><verb> # ipchains -N ppp-out # ipchains -A output -i ppp0 -j ppp-out # </verb></tscreen>  web のトラフィックと telnet へ最小遅延を設定します。 <tscreen><verb> # 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 # </verb></tscreen>  ftp データ, nntp, pop-3 に低コストを設定します: <tscreen><verb> # 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 # </verb></tscreen>  ppp0 インターフェースに入って来るパケットには幾つかの制限があります: `ppp-in' というチェインを作りましょう: <tscreen><verb> # ipchains -N ppp-in # ipchains -A input -i ppp0 -j ppp-in # </verb></tscreen>  さて、 <tt>ppp0</tt> に入って来るパケットは 192.168.1.* のソースアドレスを主張するべきではありません。ですから、我々はそれらをログに記録して否定 (deny) します: <tscreen><verb> # ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY # </verb></tscreen>  私は DNS の UDP パケット (私は全ての要求を 203.29.16.1 へ転送するキャッシュネームサーバを動かしているので、それらの要求からその DNS だけが返答することを予測します。) と入って来る ftp と帰って来る ftp-data (これらは1023番以上のポートのみが使われ、且つ6000番近辺の X11 ポートを使いません。) の TCP パケットのみを許可します。 <tscreen><verb> # 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 # </verb></tscreen>  帰ってくる TCP の返答パケットを許可します。 <tscreen><verb> # ipchains -A ppp-in -p TCP ! -y -j ACCEPT # </verb></tscreen>  最後に、ローカルとローカル同士のパケットは OK です: <tscreen><verb> # ipchains -A input -i lo -j ACCEPT # </verb></tscreen>  さて、私の <tt>input</tt> チェインにおける既定ポリシーは <tt>DENY</tt> (否定) ですので、上述のもの以外は全て破棄します: <tscreen><verb> # ipchains -P input DENY # </verb></tscreen>  注意: 私はこの順番でチェインをセットアップしませんでした。セットアップの最中にパケットが入り込んで来るからです。最も安全なのは最初に DENY のポリシーを設定することです。勿論、あなたのルールがホスト名を解決する為に DNS の参照を要求するなら、問題が発生することでしょう。  <sect2> ipchains-save を使う<label id="ipchains-save">  まさにあなたのお望み通りのファイアウォールチェインをセットアップし、そして次回にやったことを思い出そうとするのは辛いことです。  そこで、今セットアップしたあなたのチェインを読み、ファイルに保存する、 <tt>ipchains-save</tt> というスクリプトです。 <tt>ipchains-restore</tt> が何をするかに関してはちょっと待ってて下さいね。  <tt>ipchains-save</tt> は単一のチェイン又は (チェイン名が指定されなければ) 全てのチェインをセーブできます。オプションとしては `-v' のみが許され、これはセーブされたルールを (標準エラー出力に) プリントします。 <tt>input</tt>, <tt>output</tt> そして <tt>forward</tt> チェインのポリシーも同様にセーブされます。 <tscreen><verb> # ipchains-save > my_firewall Saving `input'. Saving `output'. Saving `forward'. Saving `ppp-in'. Saving `ppp-out'. # </verb></tscreen>  <sect2> ipchains-restore を使う  <tt>ipchains-restore</tt> は <tt>ipchains-save</tt> で保存されたチェインを復元します。これは 2つのオプションを持ち得ます: `-v' は各々のルールが追加されるように説明します。そして `-f' は以下に説明するように、既に存在するユーザー定義チェインを強制的に消去します。  もし、 input チェイン内にユーザー定義チェインがあれば、 <tt>ipchains-restore</tt> はそれが既存のチェインなのかをチェックします。そうであれば、プロンプトが表示され、チェインを消去する (全てのルールを消去する) か、処理をスキップして現在の設定を保持するかの選択を求められます。もしコマンドラインに `-f' を指定すれば、プロンプトは表示されません: チェインは消去されます。  例: <tscreen><verb> # 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'. # </verb></tscreen>     <sect>その他の情報  この項は上述の説明からもれたすべての情報と FAQ 集があります。  <sect1>ファイアウォールルールをどのように構築するか<label id="organisation">  この問題にはある種の方針が必要です。速度を最適化(最も普通のパケットに対するルールチェックを最小限にとどめる)して構築するか、管理性を高めて構築することもできます。  PPP リンクと言う間欠的なリンクを使っているなら、起動時に input チェインの最初のルールを `-i ppp0 -jDENY' に設定したいと思うかもしれません。その場合は、 <tt>ip-up</tt> スクリプトファイルで次のようにします。 (訳注: デバイス ppp0 からのパケットを破棄する。ダイヤルアップ回線などからの侵入を防止した場合に設定する。)  <tscreen><verb> # `ppp-in' チェインを再生成する。 ipchains-restore -f < ppp-in.firewall # ppp-handling チェインに割り込んで DENY ルールを置き換える。 ipchains -R input 1 -i ppp0 -j ppp-in </verb></tscreen>  <tt>ip-down</tt> は次のようになります。 <tscreen><verb> ipchains -R input 1 -i ppp0 -j DENY </verb></tscreen>  <sect1>フィルタリングで破棄してはいけないパケット  必要でないパケットをフィルタリングで破棄する前に注意しておかなければいけない事があります。  <sect2> ICMP パケット<label id="ICMP">  ICMP パケットは、(TCP や UDP のような)別のプロトコルに対して、失敗を表示 (その他数あるもののなかで) するのに使われています。とりわけ `目的地に到達しない' パケットを表示します。これらのパケットをブロックすると、 `ホストに到達しません' や `ホストへの経路がありません' というエラーを受け取ることができなくなります。どのような接続も来るはずのない返答を待つだけになります。これはいらいらしますが致命的ではありません。  さらに悪いことは MTU 検出での ICMP パケットの役割です。すべての良好な TCP の実装(Linux を含めた)は、分割されない状態で(分割されるとパフォーマンスを低下させ、とりわけ、ときどき分割された断片が失われるとさらに低下します)目的地に到達する最大のパケットサイズを割り出すために MTU 検出を使っています。 MTU 検出は、まずパケットを "分割不可" のビットを設定して送り、 '分割が必要だが分割しない設定(DF)をしている'というエラーを示す ICMP パケットを受け取ったら、先ほどのものより小さいサイズのパケットを送り直す、というやりかたで動作します。これは、`目的地へ到達不能' パケットのタイプで、もし受けないなら、ローカルホストは MTU を低下させないで、実行はひどく悪くなるか、存在しないことになるでしょう。訳注: <descrip> <tag>ICMP: Internet Control Message Protocol </tag> IP 相互接続ネットワーク内のノードでエラー通達、診断、制御のためのメッセージを送るプロトコル <tag>MTU: maximum transmission unit</tag> ネットワークインターフェースが一度に送ることができる最大のデータ量 </descrip>  すべての ICMP 経路変更要求メッセージ(type 5)をブロックするのは普通だということに注意して下さい。これらは、経路を手動設定する為に使うことが出来ますが(良好な IP スタックは安全装置を持っています)、しばしばやや危険だと知られています。  <sect2> DNS (ネームサーバー) への TCP 接続  外向きの TCP 接続をブロックするようにしているなら、 DNS はいつも UDP を使わないことに注意して下さい。サーバからの返答が 512 バイトを越えると、クライアントはデータを得るのに TCP 接続(やはり 53 番ポート番号) を使います。訳注: <descrip> <tag>UDP: User Datagram Protocol </tag> データパケットの転送を行うプログラム。UDP は TCP に比べると高速ですが、信頼性が低く、パケットの到達順序が保証されません。 </descrip>  TCP 転送を禁止していても、 DNS が `ほとんど動く' のでハマリます。そのようにしているなら、不可解な長い遅延やその他のときどき発生する DNS の問題を経験することになるでしょう。  DNS の問い合わせが、いつも同一の外部のソース(<tt>/etc/resolv.conf</tt> に書かれた行の<tt>ネームサーバ</tt>を直接使うか、フォワードモードでキャッシュのネームサーバーを使うかのどちらか)にしているなら、(キャッシュを使っているなら)ローカル <tt>domain</tt> ポートから、 <tt>/etc/resolv.conf</tt> を使っているならハイポート(>1023)から、そのネームサーバの <tt>domain</tt> ポートへの TCP 接続を許可する必要だけでかまいません。訳注: domain は /etc/services に次の項目が定義されているかを確認しておきます。次のようにして調べることができます。 <tscreen><verb> $ grep domain /etc/services domain 53/tcp nameserver # name-domain server domain 53/udp nameserver </verb></tscreen>  <sect2> FTP の悪夢<label id="ftp">  典型的なパケットフィルタリングの問題は FTP です。FTP には２つの<bf>モード</bf>があります。伝統的なものは <bf>アクティブモード</bf> と言われるもので、より最近のものは、 <bf>パッシブモード</bf> と言われます。 Web ブラウザは通常パッシブモードがデフォルトですが、コマンドの FTP プログラムは通常アクティブモードがデフォルトです。  アクティブモードでは、リモートホストがファイルを送信したいとき(あるいは、 <tt>ls</tt> や <tt>dir</tt> コマンドの結果でさえ)、ローカルマシンへの TCP 接続をオープンしようとします。これはアクティブ FTP を切断しないなら、これらの TCP 接続を排除できないということです。  パッシブモードを使うオプションがあるなら、良いことです。パッシブモードは入力データに対しても、クライアントからサーバにデータ接続を作ります。パッシブモードが使えないなら、TCP 接続に 1024 を越え、6000 から 6010 の範囲に無いポートに対して TCP 接続を許可することを推奨します。(6000 は X-Window System に使われています。)  <sect1> Ping of Death を排除する  Linux マシンはいまや有名な<bf> Ping of Death </bf>を心配することはありません。 Ping of Death は不法に大きな ICMP パケットを送信し、それは受け取り側で TCP スタックにあるバッファーを溢れさせ、破壊の原因になります。  脆弱なマシンを保護するなら、単純に ICMP フラグメントをブロックできます。通常の ICMP パケットは分割を要求するほど大きくはありませんから、大きな ping を排除する以外他には影響を与えません。 (不確かですが)私は、ICMP フラグメントを落すために、サイズオーバーの ICMP パケットの最後のフラグメントだけを要求し、その結果、最初のフラグメントだけをブロックするシステムがあるという報告を聞いたことがありますが、最初のフラグメントだけをブロックするようなシステムはお勧めできません。  私は ICMP を使うすべてのプログラムを見てきましたが、TCP や UDP フラグメント(あるいは不明のプロトコル)は、このような攻撃に対して使うことができないという理由がないので、 ICMP フラグメントをブロックするのは、間に合わせの解決でしかありません。  <sect1> Teardrop と Bonk を排除する  Teardrop と Bonk と言われるものは、重複するフラグメントを目的にしている 2種類の攻撃(おもにMicrosoft Windows NT マシンに対して)です。 Linux ルータがデフラグ機能を持っているか、攻撃されやすいマシンにすべてのフラグメントを禁止するのは別のオプションです。  <sect1> フラグメント爆撃を排除する  信頼性の低い TCP スタックは、パケットが多数のフラグメントになっていて、それらをすべて受信できないとき、大量のフラグメントを扱うのに問題を持っているものがあると言われています。 Linux はこのような問題がありません。フラグメントを破棄(正当に使用されたものも壊すかもしれません)するか、または、 `IP: always defragment' を `Y' と(あなたの Linux マシンがこれらのパケットに対して唯一取り得る経路である場合のみ)選択したカーネルをコンパイルすることで排除できます。  <sect1>ファイアウォールルールを変更する  ファイアウォールルールを変更するとき、タイミングの問題があります。不手際があると、変更の途中でにパケットを通してしまいます。安易なやりかたとしては次のような方法があります:  <tscreen><verb> # 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 # </verb></tscreen>  変更している間、すべてのパケットが破棄されます。    変更が単一のチェインに限定されたものなら、新しいルールで新しいチェインを作りたいかもしれません。新しいチェインを示すものと、古いチェインを示すルールを置き換えます(`-R')。そうすれば、古いチェインを削除できます。この置き換えはアトミックに(他のものには影響しないで)行われます。  <sect1>IP 偽装保護(IP Spoof Protection)を、どのように設定したらよいですか?<label id="antispoof">  IP 偽装は、ホストが別のホストから請求されるパケットを送り出す技術です。パケットフィルタリングは、このソースアドレスをもとに判定するので、 IP 偽装はパケットフィルターをごまかすために使うものです。 SYN 攻撃やしずく(Teardrop)、また命取りの Ping(Ping of Death) やそれに似たもの(それらが何者かを知らないなら心配は不用です)を使っている攻撃者の身元を隠すためにもまた使われます。  IP 偽装を防御するもっともよい方法は、ソースアドレス認証(Source Address Verification)と言われるもので、それはルーティングコードによって行われるもので、全くファイアウォールではありません。 <tt>/proc/sys/net/ipv4/conf/all/rp_filter</tt> というファイルを探して下さい。これがあるなら、始動するたびにソースアドレス認証(Source Address Verification)を有効することが正しい解決になります。このようにするため、いずれかのネットワークインターフェースが初期化される前に、お使いの init スクリプトのどこかに次の行を加えます。  <tscreen><verb> # これがもっとも良い方法です: ソースアドレス認証 # (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 </verb></tscreen>  これができないなら、すべてのインターフェースを保護するために手動でルールを書き加えます。この場合はそれぞれのインターフェースについての知識が必要です。カーネル 2.1 は自動的に127.* のアドレス(ローカルループバックインターフェース <tt>lo</tt> に予約されたもの)から要求するパケットを拒否します。  例えば <tt>eth0</tt>, <tt>eth1</tt> そして <tt>ppp0</tt> の 3つのインターフェースがあります。インターフェースのアドレスとネットマスクを知るために <tt>ifconfig</tt> を使うことができます。例えば、 <tt>eth0</tt> がネットマスク 255.255.255.0 のネットワーク 192.168.1.0 にアタッチされ、 <tt>eth1</tt> はネットマスク 255.0.0.0 のネットワーク 10.0.0.0 にアタッチされ、 <tt>ppp0</tt> がインターネット(予約されたプライベート IP アドレスを除いて、どんなアドレスでも許されます)。次のようなルールを加えるとよいでしょう。 <tscreen><verb> # 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 # </verb></tscreen>  この方法はお使いのネットワークが変わると、いままでのその状態を維持するためにあなたはファイアウォールルールを変更しなければいけないので、ソースアドレス認証(Source Address Verification)で行うほど良くありません。  2.0 系のカーネルをお使いなら、次に示すようなルールを使って、ループバックインターフェースもまた保護したいかもしれません。次のようにルールを使います: <tscreen><verb> # ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY # </verb></tscreen>  <sect1> 最新のプロジェクト   私はユーザスペースライブラリを書いており、それは`libfw' と呼ばれるソースディストリビューションを含んでいます。それは ipchains のバージョン 1.3 以上の能力を使用して(IP_FIREWALL_NETLINK のコンフィグオプションを使って)ユーザスペースにパケットをコピーします。  マーク値はパケットのための Service の質 (QoS) パラメータを決めるために使うか、あるいは、パケットがどのようにポートに中継されるかを決めるために使うことができます。私はどちらも利用していませんが、あなたがそれについて書いてみようと思うなら、どうぞ私に連絡をして下さい。  <bf>状態観察(stateful inspection)</bf>(私はダイナミックファイアウォールという言葉を提唱します)のようなことは、このライブラリを使うユーザスペースで実装されるでしょう。その他の素晴らしいアイディアは、ユーザスペースデーモンで探すことでユーザごとの基盤上でパケットをコントロールします。これはとても簡単でなければなりません。  <sect2> SPF: ステートフルパケットフィルタリング  <url url="ftp://ftp.interlinx.bc.ca/pub/spf" name="ftp://ftp.interlinx.bc.ca/pub/spf"> 上記は、 Brian Murrell の SPF プロジェクトのサイトで、それはユーザスペースで接続の追跡をします。低バンド幅のサイトに重要なセキュリティを追加しています。  現在、SPF についての文書はほとんどありませんが、次のものは Brian が質問に答えたものをメーリングリストに投稿したものです。  <tscreen><verb> > それこそが正に私の望むことを行なうと信じています。 > 外部への要求のレスポンスとしてパケットを通すように > 一時的な''逆流(backward)''のルールをインストールしています。はい、その通りです。プロトコルについて理解すればするほど、 "逆流(backward)" のルールはもっと正しくなります。今のところは、 (覚えで書いています、エラーや手抜かりがあっても許して下さい) FTP(アクティブとパッシブ、内側と外側の両方)、RealAudio、 traceroute、 ICMP そして初歩的な ICQ( ICQ サーバから入るもの、そして、直接的な TCP 接続からのもの、しかしながらファイル転送のようなことに関する第2 の直接的な TCP 接続などはまだありませんが)をサポートしています。 > SPF は ipchains を置き換えるのですか、それとも補足するのですか。補足するものです。 ipchains は Linux マシンを越えて伝わるパケットを許可したり、防いだりする道具です。 SPF はドライバであり、トラフィックをたえず監視して、どのように変更するかを ipchains に伝え、 ipchains は、変更をトラフィックパターンに伝えます。 </verb></tscreen>  <sect2> Michael Hasenstein の ftp-data ハック  SuSE の Michael Hasenstein は ipchains に ftp 接続の追跡機能を追加するカーネルパッチを書いています。次のところにあります。 <url url="http://www.suse.de/~mha/patch.ftp-data-2.gz" name="http://www.suse.de/~mha/patch.ftp-data-2.gz">  <sect1> 今後の課題  ファイアウォールと NAT は 2.4 で再設計されています。計画と議論は netfilter のメーリングリストで利用できます。 ( <url url="http://lists.samba.org" name="http://lists.samba.org">を見て下さい) このような強化は多くの利便性の問題を解決し、(実際、ファイアウォールやマスカレードはこのような困難 はないはずです)、そしてもっとはるかに柔軟性のあるファイアウォールの発展を促すはずです。    <sect> 一般的な問題    <sect1>ipchains -L を使うとフリーズします!  DNS 検索を受け付けないのでしょう。結局はタイムアウトになってしまいます。 ipchains に対して `-n' (数値)フラグを使ってみましょう。 `-n' は、ネームでの検索を行いません。    <sect1> 反転ができません!  `!'オプションの両側にスペースをおいて、`!' オプションを単独で使わなければいけません。 (4.1.4.1 で注意しました)典型的な間違いです。  <tscreen><verb> # ipchains -A input -i !eth0 -j DENY # </verb></tscreen>  `!eth0' と呼ばれるインターフェースは存在しませんが、 ipchains はそれがわからないのです。 (訳注: `!' の使い方に関する注意は、 4章を参照。 `!' オプションの前後のスペースを忘れないで下さい。)    <sect1>Masquerading または Forwarding が動きません!  パケットの forwarding が可能になっているのかどうかを確認して下さい(最近のカーネルでは、デフォルトで `使用しない'になっています。パケットは `forward' chain を越えることすらないということです)。 root 権限で次のように入力すれば変更できます。 <tscreen><verb> # echo 1 > /proc/sys/net/ipv4/ip_forward # </verb></tscreen>  これでうまくいくなら、毎回、可能になるように、お使いの起動スクリプトのどこかにこの行を書いておくことができます。このコマンドが動く前にファイアウォールを設定したいはずです。そうしないと、(破棄すべき)パケットを通過させてしまう機会を与えてしまいます。    <sect1> -j REDIR が動きません!  リダイレクトを動かすためにはパケットの forwarding (上述を見て下さい)を許可しなければいけません。そうしないと、ルーティングのコードはパケットを落します。そこで、リダイレクトのみを使っていてフォワーディングは全然使っていないならば、このことに注意して下さい。  REDIRECT (input チェインにある)は、ローカルプロセスからの接続には効果がないことに注意して下さい。 (訳注: ipchains のオプションについては、man ipchains で確認して下さい。)    <sect1> ワイルドカードインターフェースが動きません!  カーネルの 2.1.102 と 2.1.103 版(そして私が作ったいくつかの古いパッチ)にはバグがありました。それらのカーネルでは、(-i ppp+ のような)ワイルドカードインターフェースがうまくいかないエラーを明示する ipchains コマンドを生成しました。  この件は、最新のカーネルと web サイトにある 2.0.34 のパッチでは修正されています。カーネルソースを手で修正するなら、 include/linux/ip_fw.h ファイルの 63行あたりを次のように変更します: <tscreen><verb> #define IP_FW_F_MASK 0x002F /* All possible flag bits mask */ </verb></tscreen>  これは ``0x003F'' を読むべきです。これを修正し、カーネルを再構築します。    <sect1> TOS (Type of Service) が動きません!  これは私の間違いでした。 Service field のタイプを設定は、 2.1.102 から 2.1.111 版のカーネルでは実際には Service のタイプを設定できないのです。この問題は、2.1.112 では修正されました。    <sect1> ipautofw とipportfw が動きません!  2.0.x では動きません。 ipchains とipautofw あるいは ipportfw に対する大きなパッチを作成し、維持する時間がありません。  2.1.x に対しては、次のところから Juan Ciarlante の ipmasqadm をダウンロードして下さい。 <url url="http://juanjox.linuxhq.com/" name="http://juanjox.linuxhq.com/">  そして、<tt>ipautofw</tt> や<tt>ipportfw</tt> を使うとき、 <tt>ipportfw</tt> のかわりに <tt>ipmasqadm portfw</tt> を入力し、そして、 <tt>ipautofw</tt> のかわりに<tt>ipmasqadm autofw</tt> を入力して、きちんと使って下さい。    <sect1> xosview が壊れています!  1.6.0 版か、それ以降のものにして下さい。それらの版では、カーネル 2.1.x に対してどのような firewall rule も要求しません。これは 1.6.1 でまだ壊れていると思われるなら、その場合は著者にバグ報告をして下さい(それは、私の失敗ではありません)。    <sect1> `-j REDIRECT' で Segmentation エラーになります!  これは ipchains 1.3.3 版のバグですので、新しい版にアップグレードして下さい。    <sect1> マスカレーディングのタイムアウト値を設定できません!<label id="no-timeout">    (カーネル 2.1.x において) 2.1.123 以降では動きません。 2.1.124 で設定してみると、 masquerading timeouts はカーネルをロックしてしまいます (net/ipv4/ip_fw.c ファイルの 1328 行にある <tt>return</tt> を <tt>ret = </tt> に変更して下さい)。 2.1.125 では、ちゃんと動きます。注: 4.1.1 も見て下さい。    <sect1>IPX をファイアウォールしたいです!  他にも同じようなご希望があると思います。残念ながら、私のコードは IP をすべて網羅しているだけですが、幸いなことに、IPXをファイアウオールするのに必要な機能はすべてそろっています。それを利用してあなたご自身でコードを書く必要がありますが、可能な範囲で私は喜んでお手伝いしましょう。訳注: IPX というのは、Novell による MS-DOS 上のネットワークプロトコルです。 IPX については、IPX-HOWTOを参照して下さい。 <htmlurl url="http://www.linux.or.jp/JF/JFdocs/IPX-HOWTO.html" name="http://www.linux.or.jp/JF/JFdocs/IPX-HOWTO.html">    <sect>実用的な例  この範例は、1999 年の 3 月に開催された LinuxWorld で Michael Neuling と私が発表したチュートリアルから引用しました。これは、与えられた問題を解決するための唯一の方法ではないですが、多分最も単純なものです。この範例を有益なものだと思って頂ければ幸いです。  <sect1>構成  <itemize> <item>マスカレードされた内部ネットワーク(様々な OS が存在しています) が存在し、&dquot;GOOD&dquot; と呼びます。 <item>分離されたネットワーク上に公開サーバが存在しています(非武装化地帯 &dquot;Demilitarized Zone&dquot; ということで &dquot;DMZ&dquot; と呼びます)。 <item>インターネットへ PPP 接続しています( &dquot;BAD&dquot; と呼びます)。 </itemize>  <tscreen><verb> 外部ネットワーク (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) </verb></tscreen>  <sect1>目的  パケットフィルターマシン:  <descrip> <tag>全てのネットワークに対して PING が可能</tag> マシンがダウンしているかどうかを知るのに大変役に立ちます。  <tag>全てのネットワークに対して TRACEROUTE が可能</tag> これもまた、原因分析に役に立ちます。  <tag>DNS へのアクセスが可能</tag> ping と DNS をより使いやすくするためです。 </descrip>  DMZ 内:  メールサーバ <itemize> <item> 外部ネットワークへの SMTP が可能 <item> 内部と外部ネットワークからの SMTP のアクセプト(受け入れ)が可能 <item> 内部ネットワークからの POP-3 のアクセプトが可能 </itemize>  ネームサーバ <itemize> <item> 外部ネットワークへの DNS の要求が可能 <item> 内部と外部ネットワーク、パケットフィルターマシンからの DNS のアクセプトが可能 </itemize>  ウェブサーバ <itemize> <item> 内部と外部ネットワークからの HTTP のアクセプトが可能 <item> 内部ネットワークからの Rsync によるアクセスが可能 </itemize>  内部ネットワーク:  <descrip> <tag>外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する</tag> これらは、許可の対象としてはかなり標準的なことです。内部ネットワーク上のマシンに対してほぼ全てを許可することから始めますが、ここでは制限をかけています。  <tag>メールサーバへの SMTP を許可する </tag> 当然、メールは外部へ送信できるようにしたいです。  <tag> メールサーバへの POP-3 を許可する </tag> メールを読む方法です。  <tag> ネームサーバへの DNS を許可する </tag> WWW と ftp, traceroute, ssh を利用する際に、外部ネームの検索をするのに必要です。  <tag> ウェブサーバへの rsync を許可する </tag> 外部向けウェブサーバと内部ウェブサーバを同期させる方法です。  <tag> ウェブサーバへの WWW を許可する </tag> 当然、外部向けウェブサーバへ接続できるべきです。  <tag> パケットフィルターマシンへの ping を許可する </tag> これは、一般的に広く容認されていることです。つまりファイアウォールマシンがダウンしているかどうかを、確認できるようにするためです(それで外部サイトが壊れていた場合は、非難されませんので)。 </descrip>  <sect1>パケットフィルタリングを行う前に  <itemize> <item> IP 偽装保護 (Anti-spoofing) いかなる非対称のルーティングも持っていないので、全てのインターフェースに対して IP 偽装保護を単にオンできます。 <tscreen><verb> # for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done # </verb></tscreen>  <item> フィルタリングのルールとして全てを拒否にする 今まで通りローカルのループバックトラフィックは許可しますが、それ以外の全てを拒否します。 <tscreen><verb> # ipchains -A input -i ! lo -j DENY # ipchains -A output -i ! lo -j DENY # ipchains -A forward -j DENY # </verb></tscreen>  <item> インターフェースのセットアップ インターフェースのセットアップは、大抵ブート時のスクリプトで実行されます。フィルタリングのルールが適用される前にパケットが漏れだすことを防ぐ為に、インターフェースが設定される前に上記のステップが実行されていることを確認して下さい。  <item> プロトコル別にマスカレードモジュールを組み込む FTP を利用する際には、マスカレードモジュールを組み込む必要があります。そうすることで、内部ネットワークからのアクティブとパッシブ FTP が `ちゃんと動作します'。 <tscreen><verb> # insmod ip_masq_ftp # </verb></tscreen> </itemize>  <sect1>パケットを通過させるためのパケットフィルタリング  マスカレードを使用して、forward チェインでフィルターをかけることは最良の方法です。 forward チェインをソース／あて先インターフェースに合わせて様々なユーザ定義チェインに分割して下さい。つまり、問題を取扱いやすい単位に分解するのです。 <tscreen><verb> ipchains -N good-dmz ipchains -N bad-dmz ipchains -N good-bad ipchains -N dmz-good ipchains -N dmz-bad ipchains -N bad-good </verb></tscreen>  ICMP の標準エラーをアクセプトすることは、共通の内容です。したがって、そのためのチェインを作ります。 <tscreen><verb> ipchains -N icmp-acc </verb></tscreen>  <sect2> forward チェインからジャンプさせる  残念なことに、(forward チェインでは)出力インターフェースしか分かりません。したがって、パケットがどのインターフェースから入ってくるかを見抜くために、ソースアドレスを使用します(偽装保護がアドレスのなりすましを防いでいるので大丈夫です)。  これらのいずれにもマッチしないパケット(明らかに、そのようなことは起こらないはずですが)は全てログを取ることに注意して下さい。 <tscreen><verb> 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 </verb></tscreen>  <sect2> icmp-acc チェインを定義する  パケットが(以下の)エラー ICMP のいずれかならアクセプトされます。さもなければ、マッチしなかったパケットに対する制御は icmp-acc チェインから抜けて、呼出し元のチェインに戻されることになります。 <tscreen><verb> 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 </verb></tscreen>  <sect2> GOOD (内部ネットワーク) から DMZ (サーバネットワーク)  内部ネットワークに対する制限 : <itemize> <item> 外部ネットワークへの WWW, ftp, traceroute, ssh を許可する <item> <bf>メールサーバへの SMTP を許可する</bf> <item> <bf>メールサーバへの POP-3 を許可する</bf> <item> <bf>ネームサーバへの DNS を許可する</bf> <item> <bf>ウェブサーバへの rsync を許可する</bf> <item> <bf>ウェブサーバへの WWW を許可する</bf> <item> パケットフィルターマシンへの ping を許可する </itemize>  内部ネットワークから DMZ の際にマスカレードはできますが、ここでは行いません。内部ネットワーク上のどのマシンも悪意のあることをしないはずなので、拒否される全てのパケットのログを取ります。  Debian の古いバージョンでは、/etc/services 上の `pop3' を`pop-3' と呼ぶので注意して下さい。このことは RFC1700 と一致していません。 <tscreen><verb> 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 </verb></tscreen>  <sect2> BAD (外部ネットワーク)から DMZ (サーバネットワーク)  <itemize> <item> DMZ に対する制限: <itemize> <item> メールサーバ <itemize> <item> <bf>外部ネットワークへの SMTP が可能</bf> <item> 内部と<bf>外部ネットワークからの SMTP のアクセプトが可能</bf> <item> 内部ネットワークからの POP-3 のアクセプトが可能 </itemize> <item> ネームサーバ <itemize> <item> <bf>外部ネットワークへの DNS の要求が可能</bf> <item> 内部と<bf>外部ネットワーク</bf>、パケットフィルターマシン<bf>からの DNS のアクセプトが可能</bf> </itemize> <item> ウェブサーバ <itemize> <item> 内部と<bf>外部ネットワークからの HTTP のアクセプトが可能</bf> <item> 内部ネットワークからの Rsync のアクセプトが可能 </itemize> </itemize> <item> 外部ネットワークから DMZ へ許可すること <itemize> <item> 侵害行為については、ログはとらずそのままにする </itemize> <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect2> GOOD (内部ネットワーク)から BAD (外部ネットワーク)  <itemize> <item> 内部ネットワークに対する制限: <itemize> <item> <bf>外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する</bf> <item> メールサーバへの SMTP を許可する <item> メールサーバへの POP-3 を許可する <item> ネームサーバへの DNS を許可する <item> ウェブサーバへの rsync を許可する <item> ウェブサーバへの WWW を許可する <item> パケットフィルターマシンへの ping を許可する </itemize> <item> 一般に、内部ネットワークから外部ネットワークに対しては、全てを許可し、それから制限を加えます。我々は、ファシストなのです。 <itemize> <item> 侵害行為のログを取る <item> パッシブ FTP は、マスカレードモジュールで処理する <item> UDP のあて先ポート 33434 以降は traceroute で使用される </itemize> <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect2>DMZ から GOOD (内部ネットワーク)  <itemize> <item> 内部ネットワークに対する制限: <itemize> <item> 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する <item> <bf>メールサーバへの SMTP を許可する</bf> <item> <bf>メールサーバへの POP-3 を許可する</bf> <item> <bf>ネームサーバへの DNS を許可する</bf> <item> <bf>ウェブサーバへの rsync を許可する</bf> <item> <bf>ウェブサーバへの WWW を許可する</bf> <item> パケットフィルターマシンへの ping を許可する </itemize> <item> 内部ネットワークから DMZ の際にマスカレードする場合、単にそれ以外のパケットを拒否して下さい。実のところ、単にコネクションが確立された一部のパケットのみ許可するだけです。 <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect2>DMZ から BAD (外部ネットワーク)  <itemize> <item> DMZ に対する制限: <itemize> <item> メールサーバ <itemize> <item> <bf>外部ネットワークへの SMTP が可能</bf> <item> 内部と<bf>外部ネットワークからの SMTP のアクセプトが可能</bf> <item> 外部ネットワークからの POP-3 のアクセプトが可能 </itemize> <item> ネームサーバ <itemize> <item> <bf>外部ネットワークへの DNS の送信が可能</bf> <item> 内部と<bf>外部ネットワーク</bf>、パケットフィルターマシン<bf>からの DNS のアクセプトが可能</bf> </itemize> <item> ウェブサーバ <itemize> <item> 内部と<bf>外部ネットワークからの HTTP のアクセプトが可能</bf> <item> 内部ネットワークからの Rsync のアクセプトが可能 </itemize> </itemize> <item> <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect2>BAD (外部ネットワーク)から GOOD (内部ネットワーク)  <itemize> <item> 外部ネットワークから内部ネットワークへ入って来るもの全て(マスカレードされていないもの)を許可しません。 <tscreen><verb> ipchains -A bad-good -j REJECT </verb></tscreen> </itemize>  <sect2>Linux マシン自身に対するパケットフィルタリング  <itemize> <item> パケットフィルターマシン自身に入って来るパケッットにも、パケットフィルタリングを行いたいなら、input チェインでパケットフィルタリングを行う必要があります。あて先インターフェース毎に、一つチェインを作ります。 <tscreen><verb> ipchains -N bad-if ipchains -N dmz-if ipchains -N good-if </verb></tscreen>  <item> 作ったチェインにジャンプさせます。 <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect3>BAD (外部ネットワーク) インターフェース  <itemize> <item> パケットフィルターマシン: <itemize> <item> <bf>全てのネットワークに対して PING が可能</bf> <item> <bf>全てのネットワークに対して TRACEROUTE が可能</bf> <item> DNS へのアクセスが可能 </itemize> <item> また外部ネットワーク用のインターフェースは、マスカレードされたパケット(マスカレードは、ソースポートとして 61000 から 65095 を使用します)へのリプライと ICMP エラー、PING のリプライも受け入れます。 <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect3>DMZ インタフェース  <itemize> <item> パケットフィルターマシンに対する制限: <itemize> <item> <bf>全てのネットワークに対して PING が可能</bf> <item> <bf>全てのネットワークに対して TRACEROUTE が可能</bf> <item> <bf>DNS へのアクセスが可能</bf> </itemize> <item>DMZ インターフェースは、DNS からのリプライと ping のリプライ、エラー ICMP を受け入れます。 <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect3>GOOD (内部ネットワーク)インターフェース  <itemize> <item> パケットフィルターマシンに対する制限: <itemize> <item> <bf>全てのネットワークに対して PING が可能</bf> <item> <bf>全てのネットワークに対して TRACEROUTE が可能</bf> <item> <bf>DNS へのアクセスが可能</bf> </itemize> <item>内部ネットワークに対する制限: <itemize> <item> 外部ネットワークへの WWW, ftp ,traceroute, ssh を許可する <item> メールサーバへの SMTP を許可する <item> メールサーバへの POP-3 を許可する <item> ネームサーバへの DNS を許可する <item> ウェブサーバへの rsync を許可する <item> ウェブサーバへの WWW を許可する <item> <bf>パケットフィルターマシンへの ping を許可する</bf> </itemize> <item>内部ネットワークインターフェースは、ping と ping のリプライ、エラー ICMP を受け入れます。 <tscreen><verb> 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 </verb></tscreen> </itemize>  <sect1>最後に  <itemize> <item>ブロッキングのルールを削除します。 <tscreen><verb> ipchains -D input 1 ipchains -D forward 1 ipchains -D output 1 </verb></tscreen> </itemize>     <sect> 付録: ipchains と ipfwadm との違い<label id="ipfwadm-diff">  これらの変更の幾つかはカーネルの変更の結果であり、また幾つかは <tt>ipchains</tt> と <tt>ipfwadm</tt> との違いの結果です。 <enum>  <item> 多くの引数は再配置されました: 現在、大文字はコマンドを示し、小文字はオプションを示します。  <item> 任意のチェインがサポートされましたので、組み込みチェインも同様にフラグではなくフルネームで記載する必要があります。 (例. `-I' ではなく `input' と記載します).  <item> `-k' オプションはなくなりました。 `! -y' を使って下さい。  <item> `-b' オプションは、単一の `双方向' ルールというよりも、むしろ実際には2つのルールに対して挿入/追加/削除を行います。  <item> `-b' オプションは 2つのチェックを行うために、 `-C' オプションにて無効化されます。(各々の方向の1つ)   <item> `-l' に対する `-x' オプションは `-v' に変更されました。  <item> もう、複数の送信側と受信側のポートはサポートされません。望ましくは、ポート幅を否定できることで、多少はその目的を補うでしょう。  <item> インターフェースは(アドレスでなく)名前によってのみ指定できます。まぁ、どのみち、以前の意味付けは 2.1 カーネルシリーズで静かに変更されたことですし。  <item> パケットの断片化は検査されますので、自動的には素通りしません。  <item> 明示的な計数チェインは廃止されました。   <item> IP上の任意のプロトコルがテストできます。  <item> SYN と ACK の組合せに対する以前の振舞い (以前は非 TCP パケットは無視していました) は変更されました; SYN オプションは、非 TCP 独特のルールに対しては無効です。  <item> 現在、32ビットマシン上のカウンタは 64ビットであり、32ビットではありません。  <item> 現在、反転オプションがサポートされています。  <item> 現在、 ICMP コードがサポートされています。  <item> 現在、ワイルドカードインターフェースがサポートされています。  <item> 現在、TOS 操作は分別チェックされます: 古いカーネルコードは `ゼロでなければならない' TOS ビットを(不当に)操作されることで、静かに止まってしまっていました; 現在、 ipchains はそのような試みに対して、他の不当な場合と同様にエラーを返します。 </enum>  <sect1> クィックリファレンス一覧  [ 主に、コマンド引数は大文字で、オプション引数は小文字です。]  注意すべき一点として、マスカレーディングは `-j MASQ' と記載します; これは `-j ACCEPT' と全く異なり、また <tt>ipfwadm</tt> のような副次的効果としては取り扱いません。  <verb> ================================================================ | 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 | <none> | -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 と共に指定しない | | | と機能しません。 ---------------------------------------------------------------- </verb>  <sect1> 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 に相当します)。    <sect>付録: ipfwadm-wrapper スクリプトを使う<label id="upgrade">  <tt>ipfwadm-wrapper</tt> シェルスクリプトは、ipfwadm とプラグインにて置換される為にあり、 <tt>ipfwadm</tt> 2.3a との下位互換性があります。  唯一、どうしても処理できない機能は `-V' オプションです。これが用いられる時は、ワーニングが出力されます。 `-W' オプションも使われるなら、 `-V' オプションは無視されます。他の点では、スクリプトは <tt>ifconfig</tt> を用いて、インターフェース名を割り当てられているアドレスから見つけようとします。もしそれに失敗すれば(例えばインターフェースがダウンしている場合)、エラーメッセージを伴って終了します。  このワーニングは `-V' を `-W' に変更するか、スクリプトの標準出力を /dev/null に送れば抑えられます。  このスクリプトのミスや ipfwadm との相違点を発見したら、是非とも、バグレポートを私に下さい: サブジェクトに "BUG-REPORT" と書いて、 rusty@linuxcare.com 宛にメールを下さい。お手持ちの古い <tt>ipfwadm</tt> のバージョン (<tt>ipfwadm -h</tt>) と、 <tt>ipchains</tt> のバージョン (<tt>ipchains --version</tt>) と、 ipfwadm wrapper スクリプトのバージョン (<tt>ipfwadm-wrapper --version</tt>) を列挙して下さい。同時に、 <tt>ipchains-save</tt> の出力も送って下さい。宜しくお願いします。  この <tt>ipfwadm-wrapper</tt> スクリプトを <tt>ipchains</tt> と混用する際には、自己責任にてお願いします。    <sect>付録: 謝辞  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 に。  <sect1>翻訳  翻訳する人は謝辞ページの冒頭に翻訳者一覧を掲載して下さい。例えば: `私の英語から全てを正確に翻訳してくれたXXXさんに感謝します。' そして、私がこの文書に含められる様に、あなたの翻訳文を教えて下さい。 Arnaud Launay, asl@launay.org: <url url="http://www.freenix.fr/unix/linux/HOWTO/IPCHAINS-HOWTO.html" name="http://www.freenix.fr/unix/linux/HOWTO/IPCHAINS-HOWTO.html"> Giovanni Bortolozzo, borto@pluto.linux.it: <url url="http://www.pluto.linux.it/ildp/HOWTO/IPCHAINS-HOWTO.html" name="http://www.pluto.linux.it/ildp/HOWTO/IPCHAINS-HOWTO.html"> Herman Rodr刕uez, herman@maristas.dhis.org: <url url="http://netfilter.kernelnotes.org/ipchains/spanish/HOWTO.html" name="http://netfilter.kernelnotes.org/ipchains/spanish/HOWTO.html"> JF Project, jf@linux.or.jp: <url url="http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html" name="http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html"> <sect>日本語訳について 日本語訳初版: 2000年 11月 21日 <newline> JF Project 「チーム ipchains」翻訳者一覧(敬称略、50音順): <itemize> <item>加藤大典 <daisuke@terra.dti.ne.jp> 7章 <item>後藤雅晴 <magotou@fubyshare.gr.jp> 2,3章 <item>中谷千絵 <jeanne@mbox.kyoto-inet.or.jp> 5,6章 <item>奈古屋広昭 <nagoya@cc.hit-u.ac.jp> 1～4章 <item>松田陽一 <yoh@coolmail.net> 1,4,8～10章及びまとめ </itemize> この文書を翻訳するにあたり、山森浩幸さん <h-yamamo@db3.so-net.ne.jp> の <url url="http://www.linux.or.jp/JF/JFdocs/packet-filtering-HOWTO.html" name="Linux 2.4 Packet Filtering HOWTO 日本語訳"> から多くを引用致しました。また、赤松徹さん <akamatsu@kobedenshi.ac.jp> の、 LinuxJAPAN への投稿記事を参考にさせて頂きました。 この文書を翻訳及び編集するにあたり、以下の方々からアドバイスを頂きました。(50音順) <newline> 本当にありがとうございました。 <itemize> <item>伊藤祐一さん <kade@kadesoft.com> <item>加茂智之さん <kto@interlink.or.jp> <item>日下部陽一さん <void@merope.pleiades.or.jp> <item>柴田尚明さん <shibata@luky.org> <item>瀬戸口崇さん <setzer@mx3.tiki.ne.jp> <item>千旦裕司さん <ysenda@pop01.odn.ne.jp> <item>武井伸光さん <takei@webmasters.gr.jp> <item>西田亙さん <wnishida@skyfree.org> <item>水原文さん <mizuhara@acm.org> <item>山森浩幸さん <h-yamamo@db3.so-net.ne.jp> </itemize> </article>