|
次のページ
前のページ
目次へ
5. その他の情報この項は上述の説明からもれたすべての情報と FAQ 集があります。 5.1 ファイアウォールルールをどのように構築するかこの問題にはある種の方針が必要です。速度を最適化(最も普通のパケットに対するルールチェックを最小限にとどめる)して構築するか、管理性を高めて構築することもできます。 PPP リンクと言う間欠的なリンクを使っているなら、起動時に
input チェインの最初のルールを
`-i ppp0 -jDENY'
に設定したいと思うかもしれません。
その場合は、 (訳注: デバイス ppp0 からのパケットを破棄する。ダイヤルアップ回線などからの侵入を防止した場合に設定する。)
5.2 フィルタリングで破棄してはいけないパケット必要でないパケットをフィルタリングで破棄する前に注意しておかなければいけない事があります。 ICMP パケットICMP パケットは、(TCP や UDP のような)別のプロトコルに対して、失敗を表示 (その他数あるもののなかで) するのに使われています。 とりわけ `目的地に到達しない' パケットを表示します。 これらのパケットをブロックすると、 `ホストに到達しません' や `ホストへの経路がありません' というエラーを受け取ることができなくなります。 どのような接続も来るはずのない返答を待つだけになります。 これはいらいらしますが致命的ではありません。 さらに悪いことは MTU 検出での ICMP パケットの役割です。 すべての良好な TCP の実装(Linux を含めた)は、分割されない状態で(分割されるとパフォーマンスを低下させ、とりわけ、ときどき分割された断片が失われるとさらに低下します)目的地に到達する最大のパケットサイズを割り出すために MTU 検出を使っています。 MTU 検出は、まずパケットを "分割不可" のビットを設定して送り、 '分割が必要だが分割しない設定(DF)をしている'というエラーを示す ICMP パケットを受け取ったら、先ほどのものより小さいサイズのパケットを送り直す、というやりかたで動作します。 これは、`目的地へ到達不能' パケットのタイプで、もし受けないなら、ローカルホストは MTU を低下させないで、実行はひどく悪くなるか、存在しないことになるでしょう。 訳注:
すべての ICMP 経路変更要求メッセージ(type 5)をブロックするのは普通だということに注意して下さい。 これらは、経路を手動設定する為に使うことが出来ますが(良好な IP スタックは安全装置を持っています)、しばしばやや危険だと知られています。 DNS (ネームサーバー) への TCP 接続外向きの TCP 接続をブロックするようにしているなら、 DNS はいつも UDP を使わないことに注意して下さい。 サーバからの返答が 512 バイトを越えると、クライアントはデータを得るのに TCP 接続(やはり 53 番ポート番号) を使います。 訳注:
TCP 転送を禁止していても、 DNS が `ほとんど動く' のでハマリます。 そのようにしているなら、不可解な長い遅延やその他のときどき発生する DNS の問題を経験することになるでしょう。 DNS の問い合わせが、いつも同一の外部のソース( 訳注: domain は /etc/services に次の項目が定義されているかを確認しておきます。 次のようにして調べることができます。
FTP の悪夢典型的なパケットフィルタリングの問題は FTP です。FTP には2つのモードがあります。 伝統的なものは アクティブモード と言われるもので、より最近のものは、 パッシブモード と言われます。 Web ブラウザは通常パッシブモードがデフォルトですが、コマンドの FTP プログラムは通常アクティブモードがデフォルトです。 アクティブモードでは、リモートホストがファイルを送信したいとき(あるいは、 パッシブモードを使うオプションがあるなら、良いことです。 パッシブモードは入力データに対しても、クライアントからサーバにデータ接続を作ります。 パッシブモードが使えないなら、TCP 接続に 1024 を越え、6000 から 6010 の範囲に無いポートに対して TCP 接続を許可することを推奨します。(6000 は X-Window System に使われています。) 5.3 Ping of Death を排除するLinux マシンはいまや有名な Ping of Death を心配することはありません。 Ping of Death は不法に大きな ICMP パケットを送信し、それは受け取り側で TCP スタックにあるバッファーを溢れさせ、破壊の原因になります。 脆弱なマシンを保護するなら、単純に ICMP フラグメントをブロックできます。 通常の ICMP パケットは分割を要求するほど大きくはありませんから、大きな ping を排除する以外他には影響を与えません。 (不確かですが)私は、ICMP フラグメントを落すために、サイズオーバーの ICMP パケットの最後のフラグメントだけを要求し、その結果、最初のフラグメントだけをブロックするシステムがあるという報告を聞いたことがありますが、最初のフラグメントだけをブロックするようなシステムはお勧めできません。 私は ICMP を使うすべてのプログラムを見てきましたが、TCP や UDP フラグメント(あるいは不明のプロトコル)は、このような攻撃に対して使うことができないという理由がないので、 ICMP フラグメントをブロックするのは、間に合わせの解決でしかありません。 5.4 Teardrop と Bonk を排除するTeardrop と Bonk と言われるものは、重複するフラグメントを目的にしている 2種類の攻撃(おもにMicrosoft Windows NT マシンに対して)です。 Linux ルータがデフラグ機能を持っているか、攻撃されやすいマシンにすべてのフラグメントを禁止するのは別のオプションです。 5.5 フラグメント爆撃を排除する信頼性の低い TCP スタックは、パケットが多数のフラグメントになっていて、それらをすべて受信できないとき、大量のフラグメントを扱うのに問題を持っているものがあると言われています。 Linux はこのような問題がありません。 フラグメントを破棄(正当に使用されたものも壊すかもしれません)するか、または、 `IP: always defragment' を `Y' と(あなたの Linux マシンがこれらのパケットに対して唯一取り得る経路である場合のみ)選択したカーネルをコンパイルすることで排除できます。 5.6 ファイアウォールルールを変更するファイアウォールルールを変更するとき、タイミングの問題があります。 不手際があると、変更の途中でにパケットを通してしまいます。 安易なやりかたとしては次のような方法があります:
変更している間、すべてのパケットが破棄されます。 変更が単一のチェインに限定されたものなら、新しいルールで新しいチェインを作りたいかもしれません。 新しいチェインを示すものと、古いチェインを示すルールを置き換えます(`-R')。 そうすれば、古いチェインを削除できます。 この置き換えはアトミックに(他のものには影響しないで)行われます。 5.7 IP 偽装保護(IP Spoof Protection)を、どのように設定したらよいですか?IP 偽装は、ホストが別のホストから請求されるパケットを送り出す技術です。 パケットフィルタリングは、このソースアドレスをもとに判定するので、 IP 偽装はパケットフィルターをごまかすために使うものです。 SYN 攻撃やしずく(Teardrop)、また命取りの Ping(Ping of Death) やそれに似たもの(それらが何者かを知らないなら心配は不用です)を使っている攻撃者の身元を隠すためにもまた使われます。 IP 偽装を防御するもっともよい方法は、ソースアドレス認証(Source Address Verification)と言われるもので、それはルーティングコードによって行われるもので、全くファイアウォールではありません。
これができないなら、すべてのインターフェースを保護するために手動でルールを書き加えます。
この場合はそれぞれのインターフェースについての知識が必要です。
カーネル 2.1 は自動的に127.* のアドレス(ローカルループバックインターフェース 例えば
この方法はお使いのネットワークが変わると、いままでのその状態を維持するためにあなたはファイアウォールルールを変更しなければいけないので、ソースアドレス認証(Source Address Verification)で行うほど良くありません。 2.0 系のカーネルをお使いなら、次に示すようなルールを使って、ループバックインターフェースもまた保護したいかもしれません。 次のようにルールを使います:
5.8 最新のプロジェクト私はユーザスペースライブラリを書いており、それは`libfw' と呼ばれるソースディストリビューションを含んでいます。 それは ipchains のバージョン 1.3 以上の能力を使用して(IP_FIREWALL_NETLINK のコンフィグオプションを使って)ユーザスペースにパケットをコピーします。 マーク値はパケットのための Service の質 (QoS) パラメータを決めるために使うか、あるいは、パケットがどのようにポートに中継されるかを決めるために使うことができます。 私はどちらも利用していませんが、あなたがそれについて書いてみようと思うなら、どうぞ私に連絡をして下さい。 状態観察(stateful inspection)(私はダイナミックファイアウォールという言葉を提唱します)のようなことは、このライブラリを使うユーザスペースで実装されるでしょう。 その他の素晴らしいアイディアは、ユーザスペースデーモンで探すことでユーザごとの基盤上でパケットをコントロールします。 これはとても簡単でなければなりません。 SPF: ステートフルパケットフィルタリングftp://ftp.interlinx.bc.ca/pub/spf 上記は、 Brian Murrell の SPF プロジェクトのサイトで、それはユーザスペースで接続の追跡をします。 低バンド幅のサイトに重要なセキュリティを追加しています。 現在、SPF についての文書はほとんどありませんが、次のものは Brian が質問に答えたものをメーリングリストに投稿したものです。
Michael Hasenstein の ftp-data ハックSuSE の Michael Hasenstein は ipchains に ftp 接続の追跡機能を追加するカーネルパッチを書いています。 次のところにあります。 http://www.suse.de/~mha/patch.ftp-data-2.gz 5.9 今後の課題ファイアウォールと NAT は 2.4 で再設計されています。 計画と議論は netfilter のメーリングリストで利用できます。 ( http://lists.samba.orgを見て下さい) このような強化は多くの利便性の問題を解決し、(実際、ファイアウォールやマスカレードはこのような困難 はないはずです)、そしてもっとはるかに柔軟性のあるファイアウォールの発展を促すはずです。 次のページ 前のページ 目次へ |
[ |