4ae0a12bcb
Makefile yet as John needs to figure out ${LANG}-based doc building.
Please put this in 2.2, or the translators are going to kill me. ;)
Submitted by: doc-jp@jp.freebsd.org (The FreeBSD Japanese Doc Team)
Reviewed by: doc-jp@jp.freebsd.org (mutual review)
580 lines
23 KiB
Plaintext
580 lines
23 KiB
Plaintext
<!-- $Id$ -->
|
|
<!-- The FreeBSD Japanese Documentation Project -->
|
|
<!-- Original revision: 1.14 -->
|
|
|
|
<sect><heading> ファイアウォール <label id="firewalls"></heading>
|
|
|
|
<p><em>原作: &a.gpalmer;, &a.alex;.</em>
|
|
<p><em>訳: &a.saeki;.<newline>
|
|
11 November 1996.</em>
|
|
|
|
ファイアウォールは, インターネットに参加している人はもちろんのこと,
|
|
プライベートネットワークのセキュリティ向上のためのアプリケーションを
|
|
探している人にとっても, ますます興味深くなりつつある分野です.
|
|
このセクションではファイアウォールとは何か, ファイアウォールの使用法,
|
|
そしてファイアウォールを構築するために FreeBSD のカーネルで
|
|
提供されているファシリティ (機能) の使用法について説明したいと思います.
|
|
|
|
<quote><bf> 注: </bf> 社内のネットワークと「巨大かつ信頼のおけない
|
|
インターネット」との間にファイアウォールを構築することで
|
|
セキュリティ上のすべての問題が解決できると考える人がいます.
|
|
ファイアウォールはセキュリティ上の問題を解決する助けになる場合もありますが,
|
|
充分な設定がなされていないファイアウォールは, まったくファイアウォールを
|
|
持たない場合よりもセキュリティ上の危険を増大させてしまいます.
|
|
<!-- (訳注: 増大させてしまう可能性がある程度だと思いますが、十分に理解した
|
|
上でファイアウォールを構築することが非常に重要です). -->
|
|
ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を
|
|
追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに
|
|
侵入するのを妨げることはできません.
|
|
ファイアウォールを侵入不可能と過信して
|
|
内部のセキュリティをおろそかにすることは,
|
|
単にクラッカーの仕事を少し簡単にするだけでしかありません. </quote>
|
|
|
|
<sect1><heading> ファイアウォールとは何か ? </heading>
|
|
|
|
<p> 現在インターネットで普通に使用されているファイアウォールには
|
|
二つの異なるタイプがあります.
|
|
一つは, 厳密には <bf> パケットフィルタリングルータ </bf> と
|
|
呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の
|
|
ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって
|
|
パケットを転送したりブロックしたりするものです.
|
|
もう一つは, <bf> proxy (代理) サーバ </bf> として知られているタイプのものです.
|
|
これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を
|
|
禁止して, デーモンにより認証の提供とパケットの転送とをおこなうものです.
|
|
|
|
<p> 二つのタイプのファイアウォールを組み合わせて使用して,
|
|
特定のマシン (<bf> 要塞ホスト </bf> と呼ばれる) だけが
|
|
パケットフィルタリングルータを通して内部ネットワークへ
|
|
パケットを送ることができるよう設定しているサイトがしばしば存在します.
|
|
proxy (代理) サービスは通常の認証メカニズムよりもセキュリティを強化してある
|
|
要塞ホストで動作させます.
|
|
<!-- (訳注: proxy サービスをおこなうアプリケーションなど,
|
|
おそらくはあまり実績のないアプリケーションプログラムを利用したサービスを
|
|
要塞ホスト上で提供するのは避けた方がよいでしょう.
|
|
proxy サービスを提供する場合には, 要塞ホストとは別の, バリアセグメント上の
|
|
ホストで proxy サービスを提供し, パケットフィルタリングを利用して
|
|
サービスの利用を制限するようにした方が安全です.) -->
|
|
|
|
<p>FreeBSD は (<tt>IPFW</tt> として知られる) カーネルパケットフィルタ込みで
|
|
提供されています. このセクションの後の方では, このフィルタについての
|
|
説明を集中しておこないます.
|
|
サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを
|
|
FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは
|
|
たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを
|
|
カバーすることは不可能です.
|
|
|
|
<sect2><heading> パケットフィルタリングルータ <label id="firewalls:packet_filters"></heading>
|
|
|
|
<p> ルータとは, 二つまたはそれ以上のネットワークの間でパケットの転送をおこなう
|
|
マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に,
|
|
一つ一つのパケットをルールリストと比較して転送するかしないかを決める
|
|
特別なコードを持っています.
|
|
最近の IP ルーティングソフトウェアのほとんどは, 内部に
|
|
パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは
|
|
すべてのパケットを転送するようになっています.
|
|
このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める
|
|
ルールを自分で定義する必要があります.
|
|
|
|
<p> パケットを通すべきか通すべきでないかを決めるために,
|
|
パケットヘッダの内容にマッチするものがルールリストから探されます.
|
|
マッチするルールが見つかると, ルールアクションが実行されます.
|
|
ルールアクションには, パケットを捨てる, パケットを転送する,
|
|
またはパケットの発信元に ICMP メッセージを送り返すというものがあります.
|
|
ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが
|
|
適用されます.
|
|
そのため, このルールリストは「ルールチェーン」と呼ばれることもあります.
|
|
|
|
<p> パケットマッチングの基準は使用するソフトウェアによって異なりますが,
|
|
通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号,
|
|
宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ),
|
|
パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます.
|
|
|
|
<sect2><heading>Proxy サーバ <label id="firewalls:proxy_servers"></heading>
|
|
|
|
<p>Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を
|
|
特別なサーバで置き換えたマシンのことです.
|
|
これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため,
|
|
<bf>proxy サーバ </bf> と呼ばれます.
|
|
(例えば) proxy telnet サーバをファイアウォールホストで走らせておきます.
|
|
外部からユーザがファイアウォールに対して telnet を実行すると,
|
|
proxy telnet サーバが応答して, 何らかの認証メカニズムを実行します.
|
|
これを通過した後で, 内部ネットワークへのアクセスがおこなえるように
|
|
なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り,
|
|
外へ向けて送り出します.)
|
|
|
|
<p>Proxy サーバは通常, 普通のサーバより堅固に構築されていて,
|
|
しばしば「使い捨て」パスワードシステムなどを含む,
|
|
多様な認証メカニズムを持っています.
|
|
「使い捨て」パスワードシステムとは, どういうものなのでしょうか.
|
|
仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします.
|
|
しかし, 一度使用したことで, そのパスワードは既に無効になっているのです.
|
|
ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ
|
|
アクセスすることはできないというわけです.
|
|
これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への
|
|
アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに
|
|
侵入用の裏口を取り付けることは, より困難になっています.
|
|
|
|
<p>proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト
|
|
だけがサーバへのアクセス権を得ることができるようになっていることがあり
|
|
ます. そして目的のマシンと通信できるユーザを制限するように
|
|
設定することもできます.
|
|
もう一度言いますが, どんなファシリティ (機能) が使えるかは,
|
|
どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく依存します.
|
|
|
|
<sect1><heading> IPFW で何ができるか </heading>
|
|
|
|
<p>FreeBSD とともに配布されている <tt>IPFW</tt> は, カーネル内部にあって
|
|
パケットのフィルタリングとアカウンティングをおこなうシステムであり,
|
|
ユーザ側のコントロールユーティリティである <tt>ipfw(8)</tt> を
|
|
含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して,
|
|
カーネルで使用されるルールを定義したり, 現在使用されているルールを
|
|
問い合わせたりすることができます.
|
|
|
|
<p><tt>IPFW</tt> は互いに関連する二つの部分からなっています.
|
|
ファイアウォールセクションはパケットフィルタリングをおこないます.
|
|
また, IP アカウンティングセクションはファイアウォールセクションのものと
|
|
似たルールに基づいてルータの使用を追跡します.
|
|
これにより, (例えば) 特定のマシンからルータへのトラフィックがどのくらい
|
|
発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが
|
|
フォワードされているかを知ることができます.
|
|
|
|
<p><tt>IPFW</tt> は, ルータではないマシンにおいても入出力コネクションの
|
|
パケットフィルタリングのために使用することができるように設計されています.
|
|
これは一般的な <tt>IPFW</tt> の使用法とは異なる特別な使い方ですが,
|
|
こういった状況でも同じコマンドとテクニックが使用されます.
|
|
|
|
<sect1><heading>FreeBSD で IPFW を有効にする </heading>
|
|
|
|
<p><tt>IPFW</tt> システムの中心となる部分はカーネル内部にあります.
|
|
そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは
|
|
それ以上のオプションをカーネルコンフィグレーションファイルに追加し,
|
|
カーネルを再コンパイルする必要があるでしょう.
|
|
カーネルの再コンパイル方法の詳細については,
|
|
<ref id="kernelconfig" name="カーネルコンフィグレーション"> を参照してください.
|
|
|
|
<p>現在, IPFW に関係するカーネルコンフィグレーションオプションは
|
|
三つあります:
|
|
|
|
<descrip>
|
|
<tag/options IPFIREWALL/ パケットフィルタリングのためのコードを
|
|
カーネルに組み込みます.
|
|
|
|
<tag/options IPFIREWALL_VERBOSE/<tt>syslogd(8)</tt> を通じて
|
|
パケットのログを取るためのコードを有効にします.
|
|
フィルタルールでパケットのログを取るように指定しても,
|
|
このオプションが指定されていなければ, ログを取ることはできません.
|
|
|
|
<tag/options IPFIREWALL_VERBOSE_LIMIT=10/<tt>syslogd(8)</tt> を通じて
|
|
ログを取るパケットの数をエントリ毎に制限します.
|
|
敵対的な環境においてファイアウォールの動作のログを取りたいけれど,
|
|
syslog の洪水によるサービス拒絶攻撃に対し無防備でありたくないという場合に,
|
|
このオプションを使用したいと思うことがあるかもしれません.
|
|
|
|
<p> チェーンエントリのログが指定された制限数に達すると,
|
|
そのエントリに関するログ取りは停止されます.
|
|
ログ取りを再開するには, <tt>ipfw(8)</tt> ユーティリティを使用して
|
|
関連するカウンタをリセットする必要があります:
|
|
|
|
<tscreen><verb>
|
|
ipfw zero 4500
|
|
</verb></tscreen>
|
|
|
|
4500 とは, ログ取りを続行したいチェーンエントリの番号です.
|
|
|
|
</descrip>
|
|
|
|
以前のバージョンの FreeBSD は <tt>IPFIREWALL_ACCT</tt> というオプションを
|
|
持っていました.
|
|
しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を
|
|
自動的に含むようになったため, 現在では使用されることはなくなっています.
|
|
|
|
<sect1><heading>IPFW の設定 </heading>
|
|
|
|
<p><tt>IPFW</tt> ソフトウェアの設定は <tt>ipfw(8)</tt> ユーティリティを
|
|
通じておこないます. このコマンドの構文は非常に複雑に見えますが,
|
|
一旦その構造を理解すれば比較的単純です.
|
|
|
|
<p> このユーティリティでは今のところ四つの異なるコマンドカテゴリが
|
|
使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです.
|
|
追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか
|
|
というルールを構築するのに使用します.
|
|
表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの
|
|
内容を調べるのに使用します.
|
|
フラッシュはチェーンからすべてのエントリを取り除くのに使用します.
|
|
クリアは一つまたはそれ以上のアカウンティングエントリをゼロにするのに
|
|
使用します.
|
|
|
|
<sect2><heading>IPFW ルールの変更 </heading>
|
|
|
|
<p> この形式での使用法は:
|
|
<tscreen>
|
|
ipfw [-N] <em> コマンド </em> [<em>index</em>]
|
|
<em> アクション </em> [log] <em> プロトコル </em><em> アドレス </em>
|
|
[<em> オプション </em>]
|
|
</tscreen>
|
|
|
|
<p> この形式で使用する際に有効なフラグは一つだけです:
|
|
|
|
<descrip>
|
|
<tag/-N/ アドレスやサービス名を文字列に変換して表示します.
|
|
</descrip>
|
|
|
|
<em> コマンド </em> は一意である限り短縮可能です.
|
|
有効な <em> コマンド </em> は:
|
|
|
|
<descrip>
|
|
|
|
<tag/add/ ファイアウォール / アカウンティングルールリストに
|
|
エントリを追加します.
|
|
|
|
<tag/delete/ ファイアウォール / アカウンティングルールリストから
|
|
エントリを削除します.
|
|
|
|
</descrip>
|
|
|
|
以前のバージョンの <tt>IPFW</tt> では, ファイアウォールエントリと
|
|
パケットアカウンティングエントリが別々に利用されていました.
|
|
現在のバージョンでは, それぞれのファイアウォールエントリ毎に
|
|
パケットアカウンティングエントリが備えられています.
|
|
|
|
<p><tt>index</tt> が指定されていると, エントリはチェーン中の
|
|
<tt>index</tt> で示される位置に置かれます. <tt>index</tt> が指定されて
|
|
いなければ, エントリは (65535 番のデフォルトルールである
|
|
パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した
|
|
位置 (チェーンの最後) に置かれます.
|
|
|
|
<p> カーネルが <bf>IPFIREWALL_VERBOSE</bf> つきでコンパイルされている場合,
|
|
<bf>log</bf> オプションはマッチしたルールをシステムコンソールに出力させます.
|
|
|
|
<p>有効な <em> アクション </em> は:
|
|
|
|
<descrip>
|
|
|
|
<tag/reject/ パケットを捨てます, ICMP ホスト / ポート到達不能パケットを
|
|
(適切な方を) 発信元へ送ります.
|
|
|
|
<tag/allow/ 通常通りパケットを通過させます. (別名: <bf>pass</bf> および
|
|
<bf>accept</bf>)
|
|
|
|
<tag/deny/ パケットを捨てます. 発信元は ICMP メッセージによる
|
|
通知を受けません (そのためパケットが宛先に到達しなかったように見えます).
|
|
|
|
<tag/count/ このルールはパケットカウンタを更新するだけで, パケットを
|
|
通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます.
|
|
|
|
</descrip>
|
|
|
|
<p> それぞれの <em> アクション </em> は一意な先頭部分だけでも認識されます.
|
|
|
|
指定可能な <em> プロトコル </em> は以下の通り:
|
|
|
|
<descrip>
|
|
|
|
<tag/all/ 任意の IP パケットにマッチします.
|
|
|
|
<tag/icmp/ICMP パケットにマッチします.
|
|
|
|
<tag/tcp/TCP パケットにマッチします.
|
|
|
|
<tag/udp/UDP パケットにマッチします.
|
|
|
|
</descrip>
|
|
|
|
<p><em> アドレス </em> の指定は:
|
|
<tscreen>
|
|
<bf>from</bf> <<em>address/mask</em>>[<em>port</em>] <bf>to</bf>
|
|
<<em>address/mask</em>>[<em>port</em>&rsqb [<bf>via</bf> <<em>interface</em>>]
|
|
</tscreen>
|
|
|
|
<p><em>port</em> はポートをサポートする <em> プロトコル </em> (UDP と TCP) の
|
|
場合にだけ指定可能です.
|
|
|
|
<p><bf>via</bf> は必須ではなく, 特定のインターフェースを通ってきたパケット
|
|
だけにマッチするように, IP アドレスまたはローカル IP インターフェースの
|
|
ドメイン名, またはインターフェース名 (例えば <tt>ed0</tt>) を
|
|
指定することができます.
|
|
インターフェースユニット番号はオプションで, ワイルドカードで指定することが
|
|
できます. 例えば, <tt>ppp*</tt> はすべてのカーネル PPP インターフェースに
|
|
マッチします.
|
|
|
|
<p><tt><address/mask></tt> の指定は:
|
|
<tscreen>
|
|
<address>
|
|
</tscreen>
|
|
または
|
|
<tscreen>
|
|
<address>/mask-bits
|
|
</tscreen>
|
|
または
|
|
<tscreen>
|
|
<address>:mask-pattern
|
|
</tscreen>
|
|
|
|
<p>IP アドレスのかわりに有効なホスト名を指定することも可能です.
|
|
<tt>mask-bits</tt> はアドレスマスクで上位何ビットを１にするべきかを
|
|
示す十進数値です. 例えば次の指定,
|
|
<tscreen>
|
|
192.216.222.1/24
|
|
</tscreen>
|
|
はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする
|
|
マスクを作成します. <tt>mask-pattern</tt> は与えられたアドレスと
|
|
論理 AND される IP アドレスです.
|
|
キーワード <tt>any</tt> は「任意の IP アドレス」を指定するために
|
|
使用することができます.
|
|
<p> ブロックするポート番号は以下のように指定します:
|
|
<tscreen>
|
|
port[,port[,port[...]]]
|
|
</tscreen>
|
|
のように単独のポートまたはポートのリストを指定します. または
|
|
<tscreen><verb>
|
|
port-port
|
|
</verb></tscreen>
|
|
のようにポートの範囲を指定します. 単独のポートとポートのリストを
|
|
組み合わせて指定することも可能ですが, その場合は常に範囲の方を
|
|
最初に指定しなければなりません.
|
|
|
|
<p> 使用可能な <em> オプション </em> は:
|
|
|
|
<descrip>
|
|
|
|
<tag/frag/ データグラムの最初のフラグメントでなければマッチします.
|
|
|
|
<tag/in/ 入力途中のパケットであればマッチします.
|
|
|
|
<tag/out/ 出力途中のパケットであればマッチします.
|
|
|
|
<tag/ipoptions <em>spec</em>/IP ヘッダが <em>spec</em> に指定された
|
|
カンマで区切られたオプションのリストを含んでいればマッチします.
|
|
サポートされている IP オプションのリストは:
|
|
<bf>ssrr</bf> (ストリクトソースルート),
|
|
<bf>lsrr</bf> (ルーズソースルート), <bf>rr</bf> (レコードパケットルート),
|
|
そして <bf>ts</bf> (タイムスタンプ) です.
|
|
特定のオプションを含まないことを指定するには '!' を先頭につけます.
|
|
|
|
<tag/established/ パケットが既に確立されている TCP コネクションの一部であれば
|
|
(つまり RST または ACK ビットがセットされていれば) マッチします.
|
|
<em>established</em> ルールをチェーンの最初の方に置くことで,
|
|
ファイアウォールのパフォーマンスを向上させることができます.
|
|
|
|
<tag/setup/ パケットが TCP コネクションを確立しようとするものであれば
|
|
(SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします.
|
|
|
|
<tag/tcpflags <em>flags</em>/TCP ヘッダが <em>flags</em> に指定された
|
|
カンマで区切られたフラグのリストを含んでいればマッチします.
|
|
サポートされているフラグは, <bf>fin</bf>, <bf>syn</bf>, <bf>rst</bf>,
|
|
<bf>psh</bf>, <bf>ack</bf> と <bf>urg</bf> です.
|
|
特定のフラグを含まないことを指定するには '!' を先頭につけます.
|
|
|
|
<tag/icmptypes <em>types</em>/ICMP タイプが <em>types</em> リストに
|
|
存在していればマッチします. リストはタイプの範囲または個々のタイプを
|
|
カンマで区切った任意の組合せで指定できます.
|
|
一般的に使用されている ICMP タイプは:
|
|
<bf>0</bf> エコーリプライ (ping リプライ),
|
|
<bf>5</bf> リダイレクト, <bf>8</bf> エコーリクエスト (ping リクエスト),
|
|
そして <bf>11</bf> 時間超過 (<tt>traceroute(8)</tt> で使用されているように,
|
|
TTL 満了を示すのに使用されます) です.
|
|
|
|
</descrip>
|
|
|
|
<sect2><heading> IPFW ルールリストの表示 </heading>
|
|
|
|
<p> この形式での使用法は:
|
|
<tscreen>
|
|
ipfw [-atN] l
|
|
</tscreen>
|
|
|
|
<p>この形式で使用する際に有効なフラグは三つあります:
|
|
|
|
<descrip>
|
|
|
|
<tag/-a/ リスト表示の際にカウンタの値も表示します. このオプションは
|
|
アカウンティングカウンタの内容を見る唯一の手段です.
|
|
|
|
<tag/-t/ 各チェーンエントリが最後にマッチした時刻を表示します.
|
|
この時刻表示は <tt>ipfw(8)</tt> ユーティリティで使用される入力形式と
|
|
互換性がありません.
|
|
|
|
<tag/-N/ (可能であれば) アドレスやサービス名を文字列に変換して表示します.
|
|
|
|
</descrip>
|
|
|
|
<sect2><heading>IPFW ルールのフラッシュ </heading>
|
|
|
|
<p> チェーンをフラッシュするには:
|
|
<tscreen>
|
|
ipfw flush
|
|
</tscreen>
|
|
|
|
<p> カーネルに固定されているデフォルトルール (インデックス 65535 番)
|
|
以外の, ファイアウォールチェーンの中のすべてのエントリを削除します.
|
|
デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると,
|
|
パケットを許可するエントリがチェーンに追加されるまで,
|
|
あなたのシステムがネットワークから切り放されてしまいます.
|
|
そのため, ルールのフラッシュをおこなうときは注意が必要です.
|
|
|
|
<sect2><heading> IPFW パケットカウンタのクリア </heading>
|
|
|
|
<p> 一つまたはそれ以上のパケットカウンタをクリアするためには:
|
|
<tscreen>
|
|
ipfw zero [index]
|
|
</tscreen>
|
|
|
|
<p><em>index</em> が指定されていなければ, すべてのパケットカウンタが
|
|
クリアされます.
|
|
<em>index</em> が指定されていれば, 特定のチェーンエントリだけが
|
|
クリアされます.
|
|
|
|
<sect1><heading> ipfw に対するコマンドの例 </heading>
|
|
|
|
<p> このコマンドはルータを介して転送される,
|
|
ホスト <bf>evil.hacker.org</bf> から
|
|
ホスト <bf>nice.people.org</bf> の telnet ポートへの
|
|
すべてのパケットを拒絶します:
|
|
|
|
<tscreen><verb>
|
|
ipfw add deny tcp from evil.hacker.org to nice.people.org 23
|
|
</verb></tscreen>
|
|
|
|
<p> 次の例は, ネットワーク <bf>hacker.org</bf> (クラス C) 全体から
|
|
マシン <bf>nice.people.org</bf> (の任意のポート) への
|
|
任意の TCP トラフィックを拒絶し, ログを取ります.
|
|
|
|
<tscreen><verb>
|
|
ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org
|
|
</verb></tscreen>
|
|
|
|
あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを
|
|
張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます:
|
|
|
|
<tscreen><verb>
|
|
ipfw add deny from any to my.org/28 6000 setup
|
|
</verb></tscreen>
|
|
|
|
<bf>sup.FreeBSD.ORG</bf> の SUP サーバへのアクセスを許可するためには,
|
|
以下のコマンドを使用します:
|
|
|
|
<tscreen><verb>
|
|
ipfw add accept from any to sup.FreeBSD.ORG 871
|
|
</verb></tscreen>
|
|
|
|
アカウンティングレコードを見るには:
|
|
<tscreen><verb>
|
|
ipfw -a list
|
|
</verb></tscreen>
|
|
または短縮形式で
|
|
<tscreen><verb>
|
|
ipfw -a l
|
|
</verb></tscreen>
|
|
最後にチェーンエントリがマッチした時刻を見ることもできます.
|
|
<tscreen><verb>
|
|
ipfw -at l
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading> パケットフィルタリングファイアウォールの構築 </heading>
|
|
|
|
<p><quote><bf> 注: </bf> 以下の提案は, ただの提案にすぎません:
|
|
必要な処理はそれぞれのファイアウォールで異なるため,
|
|
あなた独自の要求にあったファイアウォールを構築する方法を
|
|
ここで述べることはできないのです. </quote>
|
|
|
|
<p> 最初にファイアウォールをセットアップするとき,
|
|
コントロールされた環境でファイアウォールホストの設定がおこなえるような
|
|
テストベンチセットアップが用意できない場合には, カーネルのログ取りを
|
|
有効にしてログ取り版のコマンドを使用することを強くおすすめします.
|
|
そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を
|
|
素早くおこなうことができます.
|
|
初期セットアップフェーズが完了してからであっても,
|
|
アタックの可能性のあるアクセスをトレースしたり,
|
|
要求の変化に応じてファイアウォールルールを変更したりできるので,
|
|
`deny' に対するログ取りをおこなうことをおすすめします.
|
|
|
|
<quote><bf> 注: </BF><bf>accept</bf> コマンドのログ取りをおこなっていると,
|
|
ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため
|
|
<em>大量の</em> ログデータが発生します.
|
|
そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に
|
|
遅くなってしまいます.
|
|
また, パケットが通過するまでにカーネルにより多くの仕事を要求するため,
|
|
パケットのレイテンシ (latency) を増加させてしまいます.
|
|
syslogd もログをディスクに記録するなど, より多くの CPU タイムを
|
|
使用し始め, 実に容易に <tt>/var/log</tt> が置かれているパーティションを
|
|
パンクさせてしまう可能性があります. </quote>
|
|
|
|
<p> 現状では, FreeBSD はブート時にファイアウォールルールをロードする
|
|
能力を持っていません.
|
|
私は <tt>/etc/netstart</tt> スクリプトにロードをおこなうスクリプトを
|
|
追加することをおすすめします. IP インターフェースの設定がおこなわれる前に
|
|
ファイアウォールの設定がおこなわれるように, netstart ファイル中の
|
|
充分に早い位置にルールをロードするスクリプトを配置してください.
|
|
こうすることで, ネットワークがオープンな間は常に抜け道が塞がれている
|
|
ことになります.
|
|
|
|
<p> ルールをロードするために使用するスクリプトは,
|
|
あなたが作成しなければなりません.
|
|
現在のところ <tt>ipfw</tt> は 1 コマンドで複数のルールを
|
|
ロードするユーティリティをサポートしていません.
|
|
私が使用しているシステムでは以下のようにしています:
|
|
|
|
<tscreen><verb>
|
|
# ipfw list
|
|
</verb></tscreen>
|
|
|
|
ファイルに現在のルールリストを出力し, テキストエディタを使用して
|
|
すべての行の前に ``<tt>ipfw </tt>'' と書き足します.
|
|
こうすることで, このスクリプトを /bin/sh に与えてルールをカーネルに再読み込み
|
|
させることができます. これは最も効率的な方法とはいえないかもしれませんが,
|
|
きちんと動作しています.
|
|
|
|
<p> 次の問題は, ファイアウォールが実際には何を <bf> する </bf> べきかです !
|
|
これは外部からそのネットワークへのどんなアクセスを許したいか,
|
|
また内部から外界へのアクセスをどのくらい許したいかに大きく依存します.
|
|
いくつか一般的なルールを挙げると:
|
|
|
|
<itemize>
|
|
|
|
<item> 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします.
|
|
ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な
|
|
サービスが存在する場所だからです.
|
|
|
|
<item><bf> すべての </bf> 入力 UDP トラフィックをブロックします.
|
|
これは UDP を使用しているサービスで有用なものは極めて少ないうえ,
|
|
有用なトラフィック (例えば Sun の RPC と NFS プロトコル) は,
|
|
通常セキュリティに対する脅威となるためです.
|
|
UDP はコネクションレスプロトコルであるため,
|
|
入力 UDP トラフィックを拒絶することは
|
|
すなわち出力 UDP トラフィックに対する返答をも
|
|
ブロックすることになるので, このことはそれなりの不利益をもたらします.
|
|
たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに
|
|
とって問題となる可能性があります.
|
|
もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから
|
|
任意の UDP ポートへ来るパケットがファイアウォールを通過することを
|
|
許可しなければなりません.
|
|
123 番のポートから来るパケットは ntp パケットで,
|
|
これも通過の許可を考慮する必要があるもう一つのサービスです.
|
|
|
|
<item> 外部から 6000 番のポートへのトラフィックをブロックします.
|
|
6000 番のポートは X11 サーバへのアクセスに使用されるポートで,
|
|
セキュリティに対する脅威となりえます. (特に自分のワークステーションで
|
|
<tt>xhost +</tt> をおこなう癖を持っている人がいればなおさらです).
|
|
X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に
|
|
上限を定めると, そのマシンで走らせることのできる X ディスプレイの
|
|
個数が制限されます.
|
|
RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です.
|
|
|
|
<item> 内部のサーバ (例えば SQL サーバなど) がどのポートを使用するかを
|
|
チェックします.
|
|
それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので,
|
|
これらも同様にブロックしておくことはおそらく良い考えです.
|
|
|
|
</itemize>
|
|
|
|
<p> これとは別のファイアウォール設定に関するチェックリストが CERT から
|
|
入手可能です.
|
|
<htmlurl url="ftp://ftp.cert.org/pub/tech_tips/packet_filtering"
|
|
name="ftp://ftp.cert.org/pub/tech_tips/packet_filtering">
|
|
|
|
<p> 前にも述べたように, これはただの <em> ガイドライン </em> にすぎません.
|
|
ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が
|
|
決めなければなりません.
|
|
これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに
|
|
侵入してきたとしても, 私は「いかなる」責任もとることはできません.
|