5. ステップ3:ファイアーウォールとアクセスポリシーの設定

さて、"ファイアーウォール"とは何でしょう? これは漠然とした用語で、 我々と外の世界との間の保護バリアーとして働くものなら何でも意味しています。 これは専用のシステムを指す時もあるでしょうし、 これを機能として果たす特定のアプリケーションのことかもしれません。 または、様々なハードウェアとソフトウェアを含む要素の組み合わせ ということもあるでしょう。 ファイアーウォールは与えられたシステムへの情報の出入りについて、 何を許可するかを定義する"ルール"から成っています。 では、Linux で簡単に使えるその構成要素をいくつかを見てみましょう。 そして、どのようにして適正に安全なファイアーウォール戦略を 実現するかを見てみましょう。

上のステップ1では、必要でないサーヴィスを全て停止しました。 上の例では、走らせておく必要があるものはわずかでした。 この章では、次のステップに進み、どれを表の世界に開いておくか、 何らかの方法で制限することができるのはどれかを決定します。 もし全てをブロックできれば大変結構なことですが、 これは多くの場合、現実的ではありません。

5.1. 戦略

ここでの目的は、固有の状況が何であれ、 そのために必要最小限だけを許可するように、接続と通信を制限することです。 ある場合には、外から入ってくる全ての"新たな"接続試行を ブロックしたいということもありえます。 例えば、X を走らせたいが、 誰も外からはそれにアクセスしようとは思っていないならば、 外部からの接続を完全にブロックすることになるでしょう。 他の状況では、外から入ってくる接続を信用できる出所のものだけに 制限したいかもしれません。制限が強いほど、より良いと言えます。 例えば、外から我々のシステムに ssh で入りたいのですが、 実際のところ我々は自分たちの仕事場からしかこの接続をしないとします。 それなら、sshd 接続を仕事場の アドレスの範囲からのものに制限しておくことになるでしょう。 このための方法は色々ありますが、一番普通のやり方を見てみましょう。

また、我々は、ファイアーウォールを一つのアプリケーションに限定 しようとは思っていません。 "層になった"、つまり、 深さに応じた多重の防御のアプローチをとるのに悪いことは何もありません。 前線の防御はパケットフィルタリング、 ipchainsiptables (以下を参照してください)のどちらかになるでしょう。 さらに、ファイアーウォールを補強するための、 追加的なツールやメカニズムを利用することができます。

いくつか簡単な例を紹介しましょう。 単純な方針として、デフォルトのポリシーは全てを拒否し、 必要なものだけを開くことにします。 この問題は込み入った複雑なものになりえますから、 可能な限り単純に保ち、 最も基本的なコンセプトのいくつかに集中することを心がけましょう。 このトピックについてのより進んだ内容については、 リンクの章を参照してください。

5.2. パケットフィルター ― ipchains と iptables

ipchains のような) "パケットフィルタ"は個々のパケットを見て、 その内容に基づいて判断をすることができ、 様々な目的に使うことができます。 一つのよくある目的はファイアーウォールの設置です。

Linux で普通のパケットフィルタは ipchains で、 これは 2.2 カーネルで標準になっています。 iptables もそうですが、 これはより最近の 2.4 カーネルで使えるようになっています。 iptables はさらに進んだ パケットフィルタの能力を持ち、 2.4 カーネルを走らせているなら誰にでもお勧めです。 しかし、どちらも今の目的には充分に効果的です。 ipfwadm は 2.0 カーネルのための 同様のユーティリティですが、ここでは議論しません。

もし自分の ipchains または iptables ファイアーウォールの規則の 設定が少し厄介に思えるようでしたら、 この過程を自動化できるさまざまなサイトがあります。 リンクの章 を参照してください。 また、そこで挙げられている例を出発点として 用いることができるかもしれません。 Red Hat 7.1 以降では、 Red Hat はファイアーウォールの規則のごく基本的なセットを 生成してくれる、 ipchainsiptables, と gnome-lokkit のための init スクリプト を用意しています。 (以下を参照してください。) これはまずまずの働きをしてくれますが、 このようなツールは非常に単純な二、三の規則を設定する以上 のことは滅多にしてくれませんので、 適切な文法と様々なメカニズムがどのように働くか を知ることをお勧めします。

Note: 以下に様々な例が挙げられています。これらはここで議論した いくつかの概念を示すための実例として挙げたものです。 これはあなた自身のスクリプトを書くための出発点としても 役立つことと思いますが、 全ての場合を含んでいるわけではないことに注意してください。 そのスクリプトがどのように働くかを 自分自身で理解するように強く勧めたいと思います。 これによって、自分自身の状況にぴったりとあう スクリプトを作れるようになるでしょう。

例に挙げたスクリプトは単に一つのインターフェース (インターネットに接続されたもの) への内側への接続を防御するだけのものです。 これは多くの自宅ユーザの状況には充分なものかも知れませんが、 逆に言えば、これは全ての 状況に妥当なわけではありません。

5.2.1. ipchains

ipchains は 2.2 または 2.4 カーネルで 用いることができます。ipchains が働いている時は、 このシステムを通って行く全てのパケットがチェックされます。 パケットはそれらがどこを出発して、どこに行くかによって、 異なる"チェイン(鎖)"を通って移動します。 "チェイン"を規則の集まりと考えてください。 より進んだ設定においては、 我々は自分自身用にあつらえたチェインを定義することになるでしょう。 デフォルトで組み込み済みの三つのチェインは、 入ってくるトラフィック input, 出て行くトラフィック output, そしてあるインターフェースから別のどこかへフォワードされる (典型的には"マスカレーディング"に用いられます) トラフィック forward です。 チェインはシステムに出入りする通信の流れの制御をするために、 様々な方法で操作することができます。 規則は望みの結果を達成するために自分の判断で付け加えることもできます。

全ての"チェイン"の終端は"ターゲット"です。 ターゲットはコマンドに -j オプションをつけて特定します。 ターゲットはパケットの運命を決めるもので、 その特定のチェインを本質的に終わらせるものです。 最も普通に見られるターゲットは、 以下のようにほとんどその名前から意味がわかります: ACCEPT, DENY, REJECT, そして MASQ です。 MASQ"IPマスカレーディング"のため のものです。 DENYREJECT は そのやり方は違いますが、本質的には同じことをします。 では、このどちらがいいでしょうか? これには山ほど議論があるところなのですが、 この文書の範囲を超える他のファクターに依存します。 我々の目的にはどちらでも充分でしょう。

ipchains は非常に柔軟な設定ができます。 ポート(またはポートレンジ)、インターフェース、行き先のアドレス、 出発アドレスを他の様々なオプション同様に特定することができます。 これらは man ページで充分詳しく説明されていますので、 ここでは詳細に立ち入らないことにしましょう。

インターネットから我々のシステムに入ってくる通信は、 input のチェインを通して入ってきます。 これこそ我々が出来る限り制限する必要があるものです。

以下は仮想的なシステムのための短いスクリプトの例です。 このスクリプトが何をするかはコメント文で説明されています。 "#" で始まっている行は全てコメント文です。 ipchains の規則は一般に シェルスクリプトに取り込まれ、 ファイアーウォールのロジックの設定を助けるために シェル変数を用います。


#!/bin/sh
#
# ipchains.sh
#
# An example of a simple ipchains configuration. 
# 単純な ipchains 設定例
#
# This script allows ALL outbound traffic, and denies 
# ALL inbound connection attempts from the outside.
# このスクリプトは全ての外へのトラフィックを許可し、
# 全ての中への接続試行を拒否します。
#
###################################################################
# Begin variable declarations and user configuration options ######
# 変数の宣言とユーザ設定オプションの始まり
#
IPCHAINS=/sbin/ipchains
# This is the WAN interface, that is our link to the outside world.
# これは WAN インターフェース、つまり外部につながっている我々のリンク。
# For pppd and pppoe users.
# pppd と pppoe ユーザのために。
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"

## end user configuration options #################################
### エンドユーザ設定オプション    #################################
###################################################################
# The high ports used mostly for connections we initiate and return
# traffic.
# 高い番号のポートはトラフィックの初期化と応答の設定のために
# 主に用いられる。
LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\
`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2`

# Any and all addresses from anywhere.
# 任意の場所からの任意の全てのアドレス
ANYWHERE="0/0"

# Let's start clean and flush all chains to an empty state.
# 全てのチェインをすっかり空の状態に。
$IPCHAINS -F  

# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that ipchains uses.
# 組み込みのチェインをデフォルトのポリシーにセット。以下のルールのどれにも
# マッチしないなら、これらは ipchains が用いるデフォルトになる。
$IPCHAINS -P forward DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P input DENY 

# Accept localhost/loopback traffic.
# localhost/loopback トラフィックは受け入れる。
$IPCHAINS -A input -i lo -j ACCEPT

# Get our dynamic IP now from the Inet interface. WAN_IP will be our
# IP address we are protecting from the outside world. Put this
# here, so default policy gets set, even if interface is not up
# yet.
# ここでInet インターフェースから我々の動的な IP を得る。
# WAN_IP は我々が外の世界から守っている IP アドレスになる。
# ここでこれをおいておくと、もしインターフェースがまだ用意されてなくても、
# デフォルトのポリシーがセットされる。
WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \  -f 1`

# Bail out with error message if no IP available! Default policy is 
# already set, so all is not lost here.
# もしどのIP も使えないなら、エラーメッセージを出して抜け出す。
# デフォルトのポリシーが既に設定されているので、全てがここで失われる
# わけではない。
[ -z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1

# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are
# the high, unprivileged ports (1024 to 4999 by default). This will
# allow return connection traffic for connections that we initiate
# to outside sources. TCP connections are opened with 'SYN' packets.
# 非-SYN TCP を受け入れ、LOCAL_PORTS への UDP 接続を受け入れる。
# これらは高い番号で、割り当てのないポート(デフォルトでは1024から4999)。
# これは我々が外部のソースへ通信を始める時の接続の、
# 返答の接続通信を許可する。
# TCP 接続は 'SYN' パケットとともに開かれている。
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT 

# We can't be so selective with UDP since that protocol does not
# know about SYNs.
# UDP はSYNについて知らないので、これと選択しては使えない。
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT 

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out. 
# ICMP の規則、ICMP の最低限の本質的な型だけを許す。
# Ping 要求はブロックされる。つまり、我々は誰かのping には応答せず、
# ping を出すことはできる。
$IPCHAINS -A input  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT

###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-l'.
# Outgoing traffic is allowed as the default policy for the 'output'
# chain. There are no restrictions on that.
# なんでも箱をおき(デフォルトルールは DENY)、全てのログをとる。
# 上のルールで許可されない他の全ての通信は、ここで引き上げ、
# ブロックされてログが取られる。とにかく、これはこのチェインの
# デフォルトのポリシーなので、ここで'-l' オプションでログ能力を付け加えるだけ。
# 外へ出て行く通信は 'output' チェインのデフォルトポリシーとして許可する。
# これについては何の制限もおかない。
$IPCHAINS -A input -l -j DENY

echo "Ipchains firewall is up `date`."

##-- eof ipchains.sh

 

上のスクリプトを使うには、実行可能ファイルになっていなければなりません (つまり、chmod +x ipchains.sh で、実行可能にします)。 そして、root 権限で走らせてチェインをつくり、 ファイアーウォールをつくるわけです。

この例で行ったことをまとめると、 まず始めに頭の部分でいくつかのシェル変数を設定します。 これはこのスクリプトの後の部分で用いられます。 そして、全ての内向きの通信とフォワードの通信を拒否し、 外向きの通信は全て許可するというデフォルトのルール (ipchain はこれらを "policies(ポリシー)" と呼びます) を設定します。 bigcat が外部のアドレスへの通信の初期化を行う接続の返答を受け取るために、 高い番号を持つ、 割り当てされていないポートにいくつか穴を開けなければなりません。 例えば、もし誰かのウェブサーバに接続するならば、 HTML データにはこちらに戻って来てもらいたいわけです。 同じことが他のネットワーク通信にもあてはまります。 さらに ICMP プロトコルの二、三の特定のタイプを許可します (ほとんどは依然ブロックされていますが)。 また設定したルールを破るような、 つまり何をしているのか分らないような内向きの通信は、 すべてログを取ります。 ここでは IP アドレスを用いているだけであって、 どんな種類のホスト名も使っていないことに注意してください。 これは、このファイアーウォールが、 DNS の失敗があるような場合でさえ、 DNS スプーフィングの類のごまかしを避けて、正しく動作するようにです。

文法の完全な説明については ipchains の man ページを参照してください。ここで用いた重要なものは以下のものです:

TT CLASS="LITERAL" >-A input: "input" チェインに規則を追加する。 デフォルトのチェインは input, output, forward.

TT CLASS="LITERAL" >-p udp: このルールは "UDP" "プロトコル" だけに適用。 -p オプションは tcp, udp または icmp プロトコルに 用いることが出来る。

TT CLASS="LITERAL" >-i $WAN_IFACE: このルールは特定のインターフェースのみに適用され、 参照された(input, output または output)チェイン全てに適用される。

TT CLASS="LITERAL" >-s <IP address> [port]: このルールは出発点のアドレスが指定されているときにのみ適用される。 オプションとしてすぐ後にポート番号(例えば22番)、またはポート番号の範囲、 例えば 1023:4999 を持つことが出来る。

TT CLASS="LITERAL" >-d <IP address> [port]: このルールは到着点のアドレスが指定されているときにのみ適用される。 また、ポート番号またはポート番号の範囲を含めることが可能。

TT CLASS="LITERAL" >-l : このオプションのルールにヒットする任意のパケットのログを取る (小文字の"L")。

TT CLASS="LITERAL" >-j ACCEPT: "ACCEPT" "ターゲット" にジャンプする。 これは効果的にこのチェインを終了させ、この特定のパケットの最終的な運命、 この例では "ACCEPT" すること、を決定する。 同じことが DENY のような他の -j ターゲットについても言える。

概して、コマンドラインオプションが置かれる順序は重要ではありませんが、 チェインの名前(例えば、 input) は一番最初にこなくてはなりません。

ステップ1で我々が netstat を走らせた時に、 他のものの中に X とプリントサーバがあったことを思い出してください。 我々は、制限された方法を用いてでさえ、 これらをインターネットにさらしたくありません。 これらは未だ何の問題もなく bigcat 上で走っていますが、いまや ipchains に基づいたファイアーウォールの背後に守られて、 安全かつ正常に働いているのです。 あなたのシステムには、 同じくこのカテゴリーに入る他のサーヴィスもあるかもしれませんね。

上の例は極度に単純化されたオール・オア・ナッシングの方針でした。 つまり、自分自身の外向きの通信は全て許可し (これは必ずしも良いアイデアではありませんが)、 外側から入ってくる全ての接続試行をブロックしました。 これは一つのインターフェースを守っているだけで、 実際にはさらにそのインターフェースの内側を守っているだけです。 しかし、あなたが自分のシステム用にうまく働かせるには、 もう少し詳細なチューニングが必要となることもあるでしょう。 さらに進んだ規則を知るには、補遺 を参照してください。 さらに http://tldp.org/HOWTO/IPCHAINS-HOWTO.html (JF日本語版:http://www.linux.or.jp/JF/JFdocs/IPCHAINS-HOWTO.html) を読むと良いでしょう。

ファイアーウォールに変更を加えた時はいつでも、 その整合性を確認するべきです。 設定したルールが意図したように動いていることを 確認するための一つの方法は、 ipchains がどのようにスクリプトを 解釈しているかを見ることです。 これには xterm を ぐんと大きく開いて、以下のコマンドをたたいてください:


 # ipchains -L -n -v | less

 

この 出力はチェインによってグループ分けされています。 さらに、あなたは自分自身をスキャンする方法も知らねばなりません。 (以下の 検証の章を参照してください )。 そして自分のログから目を離さず、 目指しているものがブロックされていることを確認してください。

5.2.2. iptables

iptables は Linux 用の次世代型の パケットフィルターで、2.4 カーネルを必要とします。 これは ipchains にできることなら何でもできますが、 注意する価値のある拡張機能をたくさん持っています。 文法は多くの面で ipchains に似ています。 詳しくは man ページを参照してください。

最も記す価値がある拡張機能は"コネクション・トラッキング" (接続追跡)でしょう。 これは"ステイトフル・インスペクション" (ステイトフルな検査)という名前でも知られています。 これは iptables に各パケットの状態の さらに豊富な知識を与えるものです。 そのパケットが TCP パケットと UDP パケットのどちらであるかや、 SYN か ACK フラッグのどちらがセットされているかだけではなく、 それが存在している接続の一部であるかどうかや、 存在している接続と何か関係しているかどうかまで知ることができます。 ファイアーウォールの設定との関係は明白でしょう。

結論として、 厳しいファイアーウォールを設定するには、 ipchains を用いるより、 iptables の方が簡単です。 ですから、これがお勧めの方法です。

以下は上に挙げたものと同じスクリプトを iptables 用に書き換えたものです:


#!/bin/sh
#
# iptables.sh
#
# An example of a simple iptables configuration. 
# iptables 設定のシンプルな例
#
# This script allows ALL outbound traffic, and denies 
# ALL inbound connection attempts from the Internet interface only.
# このスクリプトは全ての外向きの通信を許可し、
# 全ての内側への接続試行を拒否します。
###################################################################
# Begin variable declarations and user configuration options ######
# 変数宣言とユーザ設定オプションの開始。
#
IPTABLES=/sbin/iptables
# Local Interfaces
# ローカルインターフェース
# This is the WAN interface that is our link to the outside world.
# これは外の世界へ我々をつなげている WAN インターフェース。
# For pppd and pppoe users.
# ppd と pppoe ユーザのため。
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#

## end user configuration options #################################
## エンドユーザ設定オプション
###################################################################

# Any and all addresses from anywhere.
# 任意の場所からの任意の全てのアドレス
ANYWHERE="0/0"

# This module may need to be loaded:
# このモジュールはロードする必要があるかも知れない
modprobe ip_conntrack_ftp

# Start building chains and rules #################################
# チェインと規則の作成の開始
# Let's start clean and flush all chains to an empty state.
# 全てのチェインを空の状態に初期化
$IPTABLES -F  

# Set the default policies of the built-in chains. If no match for any 
# of the rules below, these will be the defaults that IPTABLES uses.
# 組み込みのチェインのデフォルトのポリシーを設定する。
# もし以下のルールのどれにもマッチしないなら、これらが IPTABLES ユーザの
# デフォルトとなる。
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP

# Accept localhost/loopback traffic.
# localhost/loopback 通信を許可
$IPTABLES -A INPUT -i lo -j ACCEPT

## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
# ICMP ルール。ICMP の最低限の本質的タイプのみを許可。
# ping の要求はブロックされる、つまり、我々は誰か他の ping には
# 応答しないが、ping を出すことは可能。
$IPTABLES -A INPUT  -p icmp  --icmp-type echo-reply \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type destination-unreachable \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT  -p icmp  --icmp-type time-exceeded \
   -s $ANYWHERE -i $WAN_IFACE -j ACCEPT

###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-j
# LOG'. Outgoing traffic is allowed as the default policy for the
# 'output' chain. There are no restrictions on that.
# なんでも箱をおき(デフォルトルールは DENY)、全てのログをとる。
# 上のルールで許可されない他の全ての通信は、ここで引き上げ、
# ブロックされてログが取られる。とにかく、これはこのチェインの
# デフォルトのポリシーなので、ここで'-l' オプションでログ能力を付け加えるだけ。
# 外へ出て行く通信は 'output' チェインのデフォルトポリシーとして許可する。
# これについては何の制限もおかない。
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: "

echo "Iptables firewall is up `date`."

##-- eof iptables.sh

 

同じスクリプトのロジックをここで用いているので、これは、 前の ipchains スクリプトとほぼ 同じことを行います。文法的にはわずかに差がありますが。 チェインの名前の変化がある場合に気をつけてください (例えば、INPUT と input など)。 ログを取ることについても扱いが異なります。 今度は自分自身の"ターゲット"を持ち (-j LOG)、さらに柔軟になっています。

同様にきわめて根本的な違いもいくつかありますが、 それはそんなに明らかなものではないかもしれません。 この章でのipchains スクリプトの 以下の部分を思い出してください:


# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are the high,
# unprivileged ports (1024 to 4999 by default). This will allow return
# connection traffic for connections that we initiate to outside sources.
# TCP connections are opened with 'SYN' packets. We have already opened 
# those services that need to accept SYNs for, so other SYNs are excluded here
# for everything else.
# LOCAL_PORTS への非-SYN TCP と UDP 接続を受け入れる。
# これらは高い番号で、割り当てのないポート(デフォルトでは1024から4999)。
# これは我々が外部のソースへ通信を始める時の接続の、返答の接続通信を許可する。
# TCP 接続は 'SYN' パケットとともに開かれている。
# 我々は既に SYN を受け入れる必要のあるサーヴィスを開いていたので、
# 他のSYN については、それら以外の全てをここで除く。
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT 

# We can't be so selective with UDP since that protocol does not know 
# about SYNs.
# UDP は SYN について知らないので、
# このプロトコルとそれほど選択的にはなれない。
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT 

 

我々は内側に入ってくる望まぬ接続を出来る限り制限するために、 ipchains によって、 ここで輪くぐりの曲芸をしました。実際、少々不調和です。

以上の部分はiptables 版のスクリプトからは抜けています。 この場合はコネクション・トラッキング(接続追跡) がこれをうまく扱ってくれるため不要で、結局なくても同じなのです。 これは iptables"ステイトフルネス" のおかげです。 それは各パケットについて、 ipchains よりも多くのことを知っているのです。 例えば、これはパケットが"新しい"接続の 一部なのか、既に"確立した"接続か、 また"関連した"接続の一部なのかを知っているのです。 これがいわゆる、コネクション・トラッキングにおける "ステイトフル・インスペクション" です。

iptables には、 ここでは触れなかった機能がまだまだたくさんあります。 ネットフィルタープロジェクトと iptables についてのさらなる読み物としては、http://netfilter.samba.org を参照してください。また、より進んだルールの設定については、 補遺を参照してください。

5.2.3. Red Hat ファイアーウォール設定ツール

Red Hat は、GUI ユーティリティ gnome-lokkit の バンドルが開始されたバージョン 7.1 までは、 ファイアーウォール設定ツールを含んでいませんでした。 gnome-lokkitipchains のみ の最小限の規則のセットです。 そのデフォルトのカーネルが 2.4 であるにも関わらず、 iptables 設定の正式なサポートは オプションにありません。

gnome-lokkit は非アップグレードインストールで オプションになっていて、インストール後のいつでもスタンドアローンの アプリケーションとして走らせることもできます。 これはいくつかの簡単な質問をして、その結果を /etc/sysconfig/ipchains に規則セットとして 吐き出してくれます。

既に述べたように、これは全く最小の規則セットですが、 出発点としては充分なものになりえます。以下は、 gnome-lokkit によって生成された /etc/sysconfig/ipchains の例です:


 # Firewall configuration written by lokkit
 # Manual customization of this file is not recommended.
 # Note: ifup-post will punch the current nameservers through the
 #       firewall; such entries will *not* be listed here.
 :input ACCEPT
 :forward ACCEPT
 :output ACCEPT
 -A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 25 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 23 -p tcp -y -j ACCEPT
 -A input -s 0/0 -d 0/0 -i lo -j ACCEPT
 -A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT
 -A input -s 127.0.0.1 53 -d 0/0 -p udp -j ACCEPT
 -A input -s 0/0 -d 0/0 -p tcp -y -j REJECT
 -A input -s 0/0 -d 0/0 -p udp -j REJECT

 

これは ipchains コマンドの ipchains-restore が読むことのできる フォーマットになっています。 結果として、新しい、または変更した規則セットは ipchains-save でアウトプットを このファイルにリダイレクトすることで生成することができます。 実際、ipchains-restore によって、 ipchains init スクリプトが このファイルを処理します。 ですから、これを働かせるには、 ipchains を 以下のように起動しなければなりません:


 # chkconfig ipchains on

 

逆に、もし代わりに自分自身の iptables の規則を走らせたいなら、 ipchains init サーヴィスが 停止されていることを確認すべきです。 iptables init スクリプトもあり、 これは ipchains 版とほとんど同じことをします。 ただ、今のところ、 gnome-lokkit からのサポートはありません。

5.3. Tcpwrappers (libwrap)

tcpwrappers は上の ipchainsiptables とほぼ同じ望みの結果をもたらしてくれますが、その働く仕組みは全く違います。 実際、tcpwrappers は接続試行に割り込んで、 その設定ファイルを調べ、要求を受け入れるか拒否するかを決定するのです。 tcpwrappers は、 iptablesipchains のようにソケットのレベルで制御するのではなく、 アプリケーションのレベルでアクセスを制御します。 これは非常に効果的ですので、 多くの Linux システムで標準のコンポーネントになっています。

tcpwrappers は設定ファイルの /etc/hosts.allow/etc/hosts.deny からなり、 その機能自体は libwrap ライブラリで提供されます。

tcpwrappers はまず、 /etc/hosts.allow ファイルで アクセスが許可されているかどうかを調べて、 許可されていればそのアクセスを認めます。 もし /etc/hosts.allow ファイルになければ、 /etc/hosts.deny ファイルでアクセスが許可されて いないかどうかを調べて、 もし許可されていないなら、そのアクセスを拒否します。 それ以外の場合は、アクセスを許可します。 この仕組みからして、/etc/hosts.deny ファイルには ALL: ALL という一行のみを書くべきです。 これによって、アクセスは /etc/hosts.allow ファイルに エントリーされているものだけが許可されるはずで、 ここには特定のサーヴィスを、 これにアクセスすることが許される特定のホストのアドレスとともに書きます。 ここでホスト名を用いることもできますが、 ホスト名を使用すると、 名前のなりすましというわずかな危険性が残ります。

tcpwrappers は普通、 inetd (または xinetd) を経由して開始される サーヴィスを守るために使われます。 しかし、 libwrap をサポートするように コンパイルされたプログラムも、 同じく tcpwrappers に守ってもらうことができます。 ただ 全てのプログラムがlibwrap サポート のもとビルドされていると仮定してはいけません。 実際、そうでないからです。事実、ほとんどのものはそうではないでしょう。 ですから、我々はここでは、 inetd 経由で開始されたサーヴィスを守る という例にだけ用いることにしましょう。 そして、非(x)inetd サーヴィスを守ることについては、 我々のパケットフィルタリングのファイアーウォールか、 または他の仕組みに頼ることにしましょう。

以下は典型的な inetd.conf ファイルから 一部抜き出したものです:


 # Pop and imap mail services et al
 #
 #pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
 #pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd ipop3d
 #imap    stream  tcp     nowait  root    /usr/sbin/tcpd imapd
 #

 

最後から二番目のコラムが tcpwrappers デーモン、 つまり/usr/sbin/tcpd です。 デーモンのすぐ後ろにあるのが、防御されているもので、 この場合には、POPIMAP メイルサーバです。 ディストリビューションによっては、 既にこの部分が最初から用意されているかもしれません。 libwrap ライブラリによって、 tcpwrapper で組み込みサポートされている 二、三のアプリケーションについては、 上のようにデーモンを指定する必要はありません。

ここでもまた同じ原則を使います: つまり、デフォルトのポリシーとして、全てを拒否し、 必要最小限の通信だけを許可するために穴を開けます。

さて、ここでテキストエディタの出番です。 su で root になり、 /etc/hosts.deny ファイルを開きましょう。 もしそのファイルが存在しないようなら、作ってください。 これはただのプレーンなテキストファイルです。 そこに以下のように書きます:


 ALL: ALL

 

もしそれが既にあれば、結構。もしなければ、これを書き込んで、 保存し、ファイルを閉じてください。簡単ですね。 "ALL"tcpwrapper が 理解してくれるキーワードの一つです。 そのフォーマットは $SERVICE_NAME : $WHO の 形ですので、 ここで全てのサーヴィスへの全ての接続を拒否していることになります。 少なくとも、 tcpwrappers を使っている 全てのサーヴィスについてはそうです。 これが主に inetd サーヴィスであることを 思い出してください。 これらのファイルの文法についての詳細は man 5 hosts_access を参照してください。 ここの "5" に注意してください!

さて今度は、出来る限り制限した、 必要なサーヴィスだけを開きましょう。 以下は簡単な一つの例です:


 ALL: 127.0.0.1
 sshd,ipop3d: 192.168.1.
 sshd: .myworkplace.com, hostess.mymomshouse.com 

 

最初の行は全ての "localhost" 接続を許可しています。 これは必要でしょう。次の行は、 我々の仮想的な自宅内 LANのプライベートアドレスの範囲である 192.168.1. から始まるIP アドレスからの sshdipop3d サーヴィスへの接続を許可します。 後に "." が続いていることに注意してください。 これは重要です。 三行目は .myworkplace.com と続く任意のホストから、 我々の sshd デーモンへの接続だけを許可します。 今度は、前に "." が来ていることに注意してください。 それから、一つのホストである hostess.mymomshouse.com も許可しています。 結果、localhost と我々の全ての LAN 接続は、 bigcat 上の全ての tcpwrapper で守られたサーヴィスへの接続が 許可されています。しかし、 外部から bigcat 上の sshd を使うことができるのは、 我々の仕事場のアドレスからとお母さんの家からだけです。 他の全ては /etc/hosts.deny ファイルのデフォルトポリシーによって拒否されます。

上の .myworkplace.com192.168.1. のようなワイルドカードのタイプは ipchainsiptables や、 この問題についての他の Linux アプリケーションではサポートされていません。 また、 tcpwrappers は IP アドレスのかわりにホスト名を使うことができ、 これはある場合にはとても便利です。 これはipchainsiptables では使えません。

自分で作った tcpwrappers 設定は、 同梱の tcpdchk ユーティリティでチェックすることができます (man ページを見てください)。今度は、 これは xinetd と一緒には働かないこと、 この場合には含まれもしないかもしれないことに注意してください。

tcpwrappersipchains のようなパケットフィルタリングの ファイアーウォールの両方を使うことには何も問題はありません。 実際、このような "多層化された"アプローチを用いることをお勧めします。 これはうっかり設定ミスをしたときの防御にもなります。 この場合、それぞれの接続が、まずパケットフィルタによってチェックされ、 次に tcpwrapper でチェックされます。

忘れずにシステム設定ファイルを編集する前にそのコピーをバックアップし、 デーモンを再スタートさせて、エラーメッセージのログをチェックしてください。

5.3.1. xinetd

既に述べたように、 xinetd は 拡張された inetd です。 Red Hat 7.0 では inetd から 置き換わっています。 これはほぼ同じ機能を果たしますが、いくつかの注目すべき 拡張を持っています。 一つは tcpwrappers のサポートが されていて、 tcpd へのあらわな参照が不要であることです。 これは /etc/hosts.allow/etc/hosts.deny が自動的に有効になる ことを意味します。

xinetd の他の拡張機能には、 耳をすませる IP アドレスを指定すること (これはアクセス制御の非常に有効な方法です)、 内側への接続の割合と同時接続の総数を制限すること、 一日の特定の時間にサーヴィスを制限することなどがあります。 xinetdxinetd.conf についての、 より詳しい情報については man ページを参照してください。

しかし文法はまったく異なります。以下は /etc/xinetd.d/tftp からの一例です:


 service tftp
 {
        socket_type     = dgram
        bind            = 192.168.1.1
        instances       = 2
        protocol        = udp
        wait            = yes
        user            = nobody
        only_from       = 192.168.1.0
        server          = /usr/sbin/in.tftpd
        server_args     = /tftpboot
        disable         = no
 }

 

bind の記述に注意してください。 ここではプライベートの LAN インターフェースに耳をすませているだけ、 または、 "binding" している(結び付けられている)だけです。 外側のポートは開いてさえいないので、外側への接続は全くなされません。 そして 192.168.1.0 と LAN からの接続だけを 許可します。 xinetd の目的のためには、 これは "192.168.1" から始まる全ての IP アドレスを 示しています。文法が inetd と 異なることに注意してください。この場合の server 項目の記述は tftp デーモン、in.tftpd です。 またここでも、libwrap/tcpwrappers サポートが xinetd に組み込み コンパイルされていることを仮定しています。 デーモンを走らせている user 項目は "nobody" になります。 そうです、 "nobody" と呼ばれるユーザアカウントが あるのです。。これは可能ならば、 この種のデーモンを非ルートユーザとして走らせる賢い方法です。 最後に、 disable の項目は サーヴィスをオン、またはオフにする xinetd の方法で、この場合には "on" になっています。 これはここでの一例としてオンになっているだけです。 安全でないなら、 tftp を 公けのサーバとして走らせては「いけません」。

5.4. PortSentry

portsentry はこれまで議論した他のツールとはまったく異なる働きをします。 portsentry はその名の通りのことをします、 つまり、ポートを守ってくれるのです。 portsentry/etc/portsentry/portsentry.conf ファイルで設定します。

上で議論した他のアプリケーションとは違って、 これは実際に自分自身がポートで耳をすませるサーバになることによって、 この仕事をします。これは罠をしかけるのに似ています。 portsentry が走っている間、 root として netstat -taup を走らせると、 portsentry が設定されているポートが何であれ、 その LISTENER として portsentry が示されます。 もし、portsentry が接続試行を感知すると、 それを完全にブロックします。 そして次の段階に進んで、それ以上の通信を全て停止するために、 そのホストへの経路をブロックします。 代わりに、ipchainsiptables を完全にそのホストを ブロックするために用いることができます。 そういうわけでこれは、ある範囲にわたるポートスキャンを やめさせる素晴らしいツールになるのです。

しかし portsentry は 接続を許可するかどうかについては自由が限られていて、 オールオアナッシングで全部許すか全部拒否するかです。 無視したい特定のIPアドレスを /etc/portsentry/portsentry.ignore ファイルで 定義できますが、個々のポートに対して 選択的なアクセスを許可することは出来ません。 その理由は、 同時に特定の一つのポートに結び付けられるのは唯一つのサーバだけだからで、 この場合には portsentry 自身ということになります。 ですから、スタンドアローンのファイアーウォールとしては 有用性が限られます。しかし、 ファイアーウォール全体の戦略の一部としては、そう、 とても有用なのです。ほとんどの場合、 これは防御の最前線に使うべきではなく、 他のツールと結びつけて使うべきでしょう。

どんな時に portsentry が便利に使えるかのアドバイス:

結局、結論としては、 パケットフィルターの方が良いファイアーウォール を作るために役立つということです。

5.5. プロキシ

辞書によれば、"proxy(プロキシ)" という言葉は、 他の人の代わりに行動する権限または力と定義されています。 これはソフトウェアのプロキシについてもなかなか良い説明になっています。 プロキシは通信経路の中間物です。例えば、 我々が "squid" (http://www.squid-cache.org/) のような Web プロキシを用いていたとすれば、 Web サイトを閲覧する度に、 実際のところは、我々がローカルに走らせている squid サーバに接続しているのです。 そして、squid はこの要求を最終点の、本当の目的場所にリレーします。 そして次に squid は Web ページを リレーしてこちらに返してくれるのです。つまりプロキシは仲立ちです。 "ファイアーウォール" のように、 "プロキシ" は他の特定のアプリケーションや、 プロキシ・アプリケーションを走らせている専用サーバも参照できます。

プロキシは様々な仕事を果たしてくれますが、 その全てがセキュリティに深く関係しているわけではありません。 しかし、プロキシは通信の仲介であるために、 アクセス制御のポリシーを実施して ファイアーウォールを通る直接の接続を制限し、 プロキシの背後にあるネットワークが 外部のインターネットからどのように見えるかを 制御する格好の場所になるのです。 これによって、プロキシはファイアーウォール全体戦略の一部として、 強力な候補になります。 そして、事実、時にパケットフィルタリングのファイアーウォール の代わりに用いられることもあります。 多くのユーザが同じファイアーウォールに背後にいるような場合には、 おそらくプロキシに基づいたファイアーウォールの方がより合理的でしょう。 しかし、一般の自宅でのシステムにおいては、 あまり優先順位は高くないかもしれません。

プロキシを設定し管理することは時に複雑で、 この文書の範囲を超えています。 ファイアーウォールとプロキシサーバの HOWTO http://tldp.org/HOWTO/Firewall-HOWTO.htmlJF 日本語訳) にプロキシファイアーウォールを設定する例が載っています。 squid の使い方は http://squid-docs.sourceforge.net/latest/html/book1.htm で議論されています。

5.6. 個別のアプリケーション

サーバの中にはそれ自身のアクセス制御機能を持っているものもあります。 自分が走らせているサーバアプリケーションのそれぞれについて、 これをチェックすべきでしょう。この章では、二、三のよくあるものについて だけ見ることにします。 man ページやアプリケーション個別の文書などが役立ちます。 これは自分のファイアーウォールに自信を持っていてもいなくても、 行うべきことです。再びここでも、 防御の多層化が常にベストなのです。

これまでと同様に、システムに変更を加えたら常に、 まず設定ファイルをバックアップした後で、そのデーモンを再スタートさせ、 当該のログを見てエラーメッセージをチェックしてください。

5.7. 検証

ファイアーウォール設定の最後のステップは、 あなたの目指した通りのことが行われているか検証することです。 あなたのシステム設定に些細な変更を加えたときでさえ、 常にこの検証をすることが賢明でしょう。

さて、どうやってこれをしましょう。 あなたにできることは色々あります。

ipchainsiptables のようなパケットフィルターについては、 我々の規則、チェイン、そして関連した動作の全てを iptables -nvL | less によってリストアップすることができます (必要に応じて ipchains におきかえてください)。 xterm を出来る限り広く開いて、 長い行が折り曲げられないようにしましょう。

これで設定したチェインが、望んだ通りのことをしているかどうか、 ある程度分るはずです。普段行いそうなオンラインの作業、 例えば、Web ページを開くとか、メイルを送受信することなどを、 試してみるべきです。これは、もちろんのことですが、 tcpwrapperportsentry については何の情報も与えてくれません。 tcpwrapper の設定を検証するには (xinetd を除いて)、 tcpdchk を用いることができます。

そして次は、自分自身をスキャンしましょう。 nmap がそのスキャンのためのツールで、 最新の Red Hat リリースに含まれていますし、 http://www.insecure.org/nmap/nmap_download.html からも手に入ります。 nmap は非常に自由度が高く、 本質的には"ポート調査ツール"です。 言い換えれば、これは他のものの中から開いているポートを探します。 詳しくは nmap の man ページを参照してください。

自分自身に対して nmap を 走らせると(例えば、nmap localhost など)、 開いているポートで、ただし、 ローカルに可視的であるもの、を教えてくれるはずです。 いまファイアーウォールがうまくいっていれば、 これは外部から見えているものとは全く違います。 ですから、自分自身をスキャンしたら、次に信用できる友達か、 サイト(リンクを見てください) を見つけ、外部からスキャンしてもらってください。 ただしポートスキャンがプロバイダのサービス規約に 違反していないか確認してください。 趣旨は立派であっても、それは許可されていないことかも知れません。 外部からのスキャンは外の世界から自分のシステムがどのように 見えているかを知る最良の方法です。 これはファイアーウォールがどのように働いているかを教えてくれます。 nmap の使い方の例については 補遺の nmap の章を参照してください。

警告を一つ: プロバイダの中にはいくつかのポートをフィルターしているものがあり、 その場合には、 どのように自分のファイアーウォールが働いているか、 確実には知ることができないでしょう。 逆に言えば、その場合は web やプロキシによって、 あるポートが開いているように見せかけているのです。 スキャンするものは 80 番ポートの web プロキシを見て、 あなたのシステム上の開いたポートとして 誤って報告してしまうかも知れません。

また一つの選択はポートの全範囲の テストを提供している web サイトを見つけることです。 http://www.hackerwhacker.com がそのようなサイトの一つです。 このようなサイトのどれでも、 単に比較的少数のよく知られたポートをスキャンするだけではないことを 確認して、使用してください。

ファイアーウォールの変更やシステムのアップグレード、 また新たなインストールをするたびに、 そしてシステムのどんな重要コンポーネントが変更された時にも、 この手続きを繰り返してください。

また、拒否された全ての通信のログを取れるようにするべきでしょう。 少なくとも、一時的には。と言うのも、一旦、ファイアーウォールが 目指したとおりに動いていることを確認したら、 そして、もしログがとても手に負えないほど圧倒的な量なら、 ログを取るのを停止したくなるかもしれませんから。

全く portsentry に頼っているなら、 その文書を読んでください。設定によっては、 それはスキャナーへの経路を落としてしまうか、 または同じことをする ipchains/iptables のルールを適用するかのどちらかでしょう。 また、それは特定のポートに"耳をすませて"いますから、 これら全てのポートは"開いている"と示されます。 この場合は偽の警報です。

5.8. ログ

Linux はたくさんのログをとります。 普通は複数のファイルにとります。 これらログに記録されているもの全てについて、 良いものなのか悪いものなのか、 またはどうでもよいものなのかは、常に明白なわけではありません。 ファイアーウォールはそれぞれかなりの量のログを作成しがちです。 もちろん、"悪いもの"だけを止めたいのですが、 他の無害な通信も当然ながら同様に捕まえてしまいます。 インターネットはたくさんの背景ノイズにあふれているのです。

多くの場合、入ってくるパケットの目的を知ることはほとんど不可能です。 侵入の試みなのか、間違ったプロトコルなのか、 それとも IP アドレスのミスタイプかも知れません。 結論は行き先ポート、出発したポート、プロトコル、 そのほかの変数などの因子に基づいて導かれます。 しかし、ファイアーウォールのログの解釈については、 経験が何よりです。それは多くの場合、 経験に基づいた「アート」の領域なのです。

それでは、我々は本当にログをとる必要があるのでしょうか? そしてどれくらいたくさんログをとるべきなのでしょうか? ログをとることの利点は、 ファイアーウォールが実際に機能を果たしていることがわかることです。 我々がログの内容のほとんどを理解できないとしても、 それが"何事かを"しているのだ、 ということは知ることができます。 そして、もし必要が生じれば、そのログを掘り起こして、 問題になっているデータを見つけることができるでしょう。

一方では、ログをとることは、もしそれがあまりに過剰で、 適切なデータを見つけることができないほどなら悪ですし、 ハードディスクを一杯にしてしまうようなら、なおさらです。 または、過剰反応のあまり、 全ての最新エントリーが全て襲撃の証拠ととってしまうことも良くありません。 正しいバランス感覚でログを見ることは素晴らしい利益になりますが、 それはその定義からしてほとんどの場合、 新米ユーザに欠けている能力でもあります。 また、ひとたびファイアーウォールが検証されたなら、 しかも莫大なログに混乱して見当を失っているならば、 自宅のデスクトップユーザはログをとることを可能な限り 少なくとどめたいと思うことでしょう。 より大きな責任のある人はログをとるべきで、 異質な情報をフィルターにかけて、 ログから適切なデータを見つけ出すための方法を探さねばなりません。

ログのデータをどこで探せばよいのか、確かでないですか? 目を注ぐべき二つのログファイルは、 /var/log/messages/var/log/secure です。 インストールしたものや使っているものによって、 そのアプリケーション特定のログがあるかもしれません。 例えば、FTP は Red Hat では、 /var/log/xfer ファイルにログをとります。

portsentrytcpwrapper では 一定量のログをとり、それは調整できません。 xinetd では、 ログの拡張機能をオンにすることができます。 一方、ipchainsiptables では、 何のログを取るかについて、非常に柔軟性があります。

ipchains では -l オプションを任意のルールに追加できます。 iptables では -j LOG ターゲットを用います。 これには、それ自身の別の代用のルールが必要です。 iptables はもう少し進んでいて、 ログを取るエントリーをカスタマイズしたり、 制限を見積もることもできます。man ページを参照してください。 おそらく、ブロックされた通信により興味を持っているでしょうから、 DENYREJECT のルールに限ってログを取ることになるでしょう。

あなたが何のログを、どれくらい取るか、 そしてそのログをどうするか、は個々の判断になります。 そしておそらく、ログをうまく扱えるようになるには、 いくらかの試行錯誤が必要になるでしょう。 以下のような、 検査ツールと解析ツールは非常に助けになります:

ログをモニターしてくれ、必要な時に教えてくれるツール。 これらをうまく使うには、いくらか設定の試行錯誤が必要になるでしょう:

5.9. 始まりの場所

ファイアーウォールのスクリプトがどこから開始されるのか、 間単に見てみましょう。

portsentry は他のシステムサーヴィスと同様に、 init プロセスとして走らせることができます。 これがいつ行われるかはそれほど重要ではありません。 tcpwrapperinetdxinetd によって自動的に呼び出されるので、これも心配はありません。

しかし、パケットフィルタリングのスクリプトは、 どこかで開始させる必要があります。 そして、多くのスクリプトは、 そのローカルな IP アドレスを用いる仕組みを持っています。 これはそのスクリプトを、 そのインターフェースが立ち上がって IP アドレスが割り当てられた後で、 スタートしなければならないことを意味しています。 理想的には、これはインターフェースが立ち上がった直後であるべきです。 ですから、これはインターネットに接続している方法に依存します。 また、PPPDHCP のように、割り当てが動的だったり、 再接続の毎に異なる IP になるかもしれないプロトコルについては、 適切なデーモンによってそのスクリプトを走らせるのが最善です。

Red Hat はユーザが定義したローカルな PPP 設定については /etc/ppp/ip-up.local を用います。 もしこのファイルがないようでしたら、 作成して、実行可能にし(chmod +x)、 テキストエディタでファイアーウォールスクリプトへの 参照を加えてください。

DHCP は、そのクライアントに依存します。 dhcpcd は、 IP の割り当てが得られたり更新される時はいつでも、 /etc/dhcpcd/dhcpcd-<interface>.exe (例えば dhcpcd-eth0.exe)を実行します。 ですから、ここがファイアーウォールスクリプトへの 参照を置く場所になります。 pump(Red Hat でのデフォルト)については、 そのメインの設定ファイルは /etc/pump.conf です。 Pump は、 新たな IP の割り当てが得られるか更新されるといつでも、 以下のように、その"スクリプト"ステートメントで 定義された全てのスクリプトを走らせます:


 script /usr/local/bin/ipchains.sh

 

もしあなたが固定のIP アドレスを持っている場合 (つまり、IP アドレスが決して変更されない場合)には、 その場所はそれほど重要でありませんが、 そのインターフェースが立ち上がる前にすべきです。

5.10. ステップ3のまとめと結論

この章では、"ファイアーウォール"を構成するのに 用いられる様々なコンポーネント(構成要素)について見ました。 そしてファイアーウォールは、何かの特定のアプリケーションや コンポーネントであると同時に、一つの戦略であり、 コンポーネントの組み合わせであるということを学びました。 全てではありませんがほとんどの Linux システムで、 最も普通に用いられるアプリケーションについて見ましたが、 これらに限るものではありません。

結局、この章は多くの情報を一度に要約したものであって、 読者の全員にその全てを理解してもらいたいものです。 また出発点として用いることが出来れば、とも思っており、 同様に、より進んだ内容へのリファレンスになることも期待しています。 パケットフィルターによるファイアーウォールの例も、 出発点として用いることができます。 単に、テキストエディタでカットアンドペーストして、 ファイルに適切な名前を書き入れ、 chmod +x として実行可能ファイルにして使えます。 変数をいくつか、少し編集する必要があるかもしれません。 また自分用のスクリプトを作るために用いることのできる サイトやユーティリティについては リンクの章を参照してください。 これで面倒な仕事を省けるかもしれません。

ここまでで我々はステップ1,2,3を果たしました。 ここまでのところで、あなたは既に基本的な手段を設定し、 ネットワークに潜む雑多かつ様々な脅威から システムを守っていることと思います。 まだ上に挙げたどのステップも遂げていないなら、 ここが中断するのによい場所ですから、上に戻ってそうしてください。 一番重要なステップは既に上で挙げた部分なのです。

二、三の短い結論…

"iptables, ipchains, tcpwrapper, また portsentry の中で、どれがベストでしょうか?" 手短かに答えれば、 iptables が 他のものよりも多くのことができます。 ですから、2.4 カーネルを用いているなら、 iptables を使ってください。 そして、2.2 カーネルならば ipchains です。 でも、本当の詳しい答は、 "それは単に、あなたが何をしているか、対象は何かによる" ということになります。すみません。 他のツールはそれぞれに与えられた情況によって利点があり、 また、どれも正しい状況で使えば効果的になりえます。

"これら全てのパッケージが必要でしょうか?" いいえ。しかし、一つのアプローチよりも、 多くを組み合わせて下さい。そして、上の全ての勧めにしたがってください。 iptables 自体良いものですが、 その他の手段をいくつか組み合わせると、もっと強くなります。 安全を確保するのに、一つだけの方法に頼らないでください。 "何層にもなった"防御が常にベストです。 安全な管理の実際がそうであるように。 世界で最高の iptables スクリプトも パズルの単なる一つのピースに過ぎず、 システムの他の弱点を隠すために用いるべきではありません。

"私は小さな家庭内 LAN を持っていますが、各コンピュータ上に ファイアーウォールをおく必要がありますか?" いいえ。LAN ゲートウェイに適切に設定されたファイアーウォールが ありさえすれば、必要ありません。 望まない通信はそこで食い止められるはずです。 そしてこれが望んだ通りに働いている限り、 LAN 内には望まぬ通信は存在しないはずです。 しかし、同じ理由で、 各コンピュータ上にファイアーウォールをおいても、 何も悪くはないことも確かです。 より大きな LAN で、色々なプラットフォームが混じっていたり、 信用できないユーザがいたりする場合には、 そうした方が良いと言えるでしょう。