Web など一部のサービスを除けば， 不特定多数からのアクセスを許可する必要があるサービスはほとんどない。 例えば不特定多数からのtelnet login を許可する必要はまずないだろう。 ほとんどの場合， 特定少数がアクセスしたいだけであり， したがって全世界からのパケットを受け付ける必要はまったくない。 telnet の場合であれば login を許可している人達が普段利用しているプロバイダからの アクセスだけを許可すれば十分である。
そこで最初の砦の役割は， ソースIPアドレス（アクセス元，telnet の場合であれば telnet クライアント・プログラムを実行しているマシンのIPアドレス） やポート番号があらかじめ登録した範囲のものでないパケットを廃棄することである。 登録していない範囲のIPアドレスからのアクセスは， サーバー・プログラムへ伝わらずに排除される。
これだけの対策で， 世界中にいるクラッカー予備軍からの攻撃のほとんどを 未然に防ぐことができるのであるから， 多少の不便さ（例えば，ふらり立ち寄ったインターネット・カフェから telnet できないなど） は我慢すべきだろう。 ただし， ソースIPアドレスは偽装可能だから， この砦は万全ではない。 どちらかと言えば， レベルの低いクラッカーからの煩わしい攻撃を無視するための砦と言える。
ではあまり意味がない砦かというとそうではない。 ほとんどすべての攻撃は幼稚なものであるから， この最初の砦だけで撃退できるのである。 いわば雑魚を無視するための砦である。 この砦を破ったクラッカーは， それなりに高度な技術力を持っている可能性があるから， それなりの敬意を持ってじっくり監視すべきである。
最初の砦を構成する方法は次の３つに分類できる。
ほとんどすべてのルーターにはIPフィルタリングの機能が搭載されている。 したがって， 不要なパケットをすべてルーターで遮断してしまえば LAN 内へ入ってくることさえないので， LAN に接続したマシンにそのパケットが届くことはない。 最も安全確実な方法と言えるが， 安価なルーターの場合機能が最小限であることも多いので注意が必要である。 ルーターによっては， フィルタリング条件の柔軟性に欠けていたり， 設定変更が面倒だったり， フィルタリングしたパケットのログを残すことができなかったりする。
高機能高価なルーターを使っている場合は， ルーターだけで最初の砦を構成しても良いのだが， そうでなければ次に説明するカーネルのIPフィルタリング機能を 併用する方が良いだろう。 そしてルーターでのフィルタリングは基本的なものだけに限定する。
例えば， LAN 内のIPアドレスをソースIPアドレスとするパケットが LAN の外から来るはずはない。 もし来たらソースIPアドレスを偽装したパケットである可能性が高い。 LAN に接続されたマシンは， 同じLAN から来た（ように見える）パケットは信頼するだろうから， こんなパケットをLAN 内に入れては大変である。 したがってルーターのIPフィルタリング機能を使って このようなパケットを排除すべきである（図1）。
蛇足だが， ルーターのパスワードは忘れずに設定してほしい。 せっかくフィルタリングの設定をしていても， パスワードを設定していなければ， 攻撃者によって真っ先にフィルタリングの設定を解除されてしまうだろう。
多くのルーターの設定の際の認証方法は， 再生攻撃可能（「第２の砦」参照） で信用できないので， ルーター自体へあてたインターネットからのパケットはフィルタリングすべきである。 当然， 外部から直接ルーターへアクセスして設定を変更することは出来なくなるが， 一度LAN内の（信頼できる）マシンへlogin した後 そこからルーターへアクセスすれば変更できるので問題ない。
カーネルにIPフィルタリング機能が実装されている場合は， この機能を使って最初の砦を構成できる。 もちろん， LinuxカーネルにはIPフィルタリング機能がある。 安物ルーターよりは柔軟な設定ができるし， Linux のように世界中の人によって使い込まれているカーネルならば バグが少ないことが期待できるのでお勧めである。
Linux 2.0.37など， 2.1.102より前のバージョンではipfwadm （http://www.xos.nl/linux/ipfwadm/参照）を， Linux2.2.12 など2.1.102 以降のバージョンでは ipchains （http://netfilter.filewatcher.org/ipchains/参照）を使って， フィルタリングの設定を行なう。
NIC（Network Interface Card。例えばEthernet アダプタ等） を２枚以上装備しているマシンでは， インタフェースごとに送受信および転送するパケットの条件を指定することができる。
フィルタリング用ツールとして有名なものにtcpwrapper がある。 inetd と組み合わせて使ったり， あるいはライブラリとしてサーバー・プログラムにリンクして使う。 アプリケーション・レベルのフィルタリングであるから柔軟性はかなり高いが， 反面DoS（Denial of Service）攻撃に弱く， ルーターやカーネル・レベルのフィルタリングに比べれば， バグが残っている危険性も高い。
パケットが未知のマシンから届いたら任意のコマンドを実行する機能があるので， 例えばfinger コマンドで送信元の素性を探る等の芸当ができるが， この機能がどれだけ役に立つかは疑問である。 実際， finger コマンドで攻撃者に関する有益な情報が得られるようでは， 極めて幼稚な攻撃者と言えるだろう。
したがってこのような設定は意味がない。 むしろ第３者のマシンを攻撃する道具として 悪用されるのがオチだからやめたほうがましである。 結局， 柔軟性が高いことによるメリットは何もないので， tcpwrapperはお勧めではない。 可能な限り(2)のカーネル・レベルのフィルタリングか， 次に説明するucspi-tcpを利用すべきだろう。
ucspi はUNIX Client-Server Program Interfaceの略であり， 「うくすぱい」と発音する。 ucspi-tcp （http://pobox.com/~djb/ucspi-tcp.html参照）は UNIX 上でTCP クライアント/サーバー・プログラムを構成するための ツール群である。 そしてこれに含まれるtcpserverは， inetd +tcpwrapperの代わりに使うツールである。 inetd +tcpwrapperが持つ無用な機能を廃し， 徹底してプログラムの構造をシンプルにすることによって セキュリティ・ホールが生じる可能性を防いでいる。 inetd がクラッカーが存在しなかった牧歌的時代にデザインされたのに対し， tcpserverはDoS 攻撃を受けることを前提に設計されている。 したがって， 特に理由がない限りinetd は走らせるべきではなく， 代わりにtcpserver を使うべきである。
tcpserver はソースIPアドレスの許可/不許可の設定に ハッシュ・テーブルを用いるため 設定するアドレスの数が大量にあっても性能劣化の問題はない。 サイトごとにサービス提供の許可不許可を きめ細かく設定したいときなどに適している。
tcpserver を使ってPOP サービスを行う例を図2に示す。
/bin/tcpserver -x/etc/tcprules.dat -u0 -g2107 -pS 0 pop \
/bin/qmail-popup toyokawa.gcd.org \
/bin/checkpassword \
/bin/qmail-pop3d Maildir &
（注：行末の\は継続行を意味する）
図2 tcpserverを使ってPOPサービスを行う例
/etc/tcprules.dat は， ソースIPアドレスによってアクセスの許可/不許可を指定する ハッシュ・ファイルである。 tcpserver はポート110番（POP）にアクセスがあると/bin/qmail-popup を呼び出す。 qmail-popup はPOP サービスのうち PASS コマンドでパスワードを受け取るところまでを担当し， 次の/bin/checkpassword を呼び出す。 checkpassword はその名の通りqmail-popup から引き継いだ パスワードを検証するプログラムである。 パスワードが正しければ， 処理がqmail-pop3d に引き継がれる。 メールの一覧や転送はこのqmail-pop3d が担当する。
このように複数のプログラムを組み合わせてPOP サーバーの機能を実現するため， 一つひとつのプログラムの機能は極めて単純になっている。 このためセキュリティ・ホールが生じる可能性を最小限に抑えられる。 また， サーバーの機能のうち危険な部分のみ犠牲パーティション （第３の砦で説明する）で走らせる， という設定も可能になる。
ちなみに， 上記qmail-pop3d はqmail （http://www.jp.qmail.org/参照） 用なので， MTA としてsendmail 等を使っている場合は適用することができない。 qmail が前述したPOP サーバー・プログラムと同様， 単機能の小さいプログラムを組み合わせて メール・サーバーの機能を実現するのに対し， sendmail は一つの大きく複雑なサーバー・プログラムを用いる。 したがって，sendmailはセキュリティ的にはあまりお勧めではない。 inetd からucspi-tcp へ移行する機会に sendmail をやめてqmail へ乗り換えてはどうだろうか。
(第２の砦)
本稿は日経Linux 創刊 2 号 (1999 年 11 月号) に掲載された、 特集 2: Linux サーバのセキュリティを高める, PART 2「フリーの定番ソフトを利用した 4 段階 Linux サーバ防御法 ---4 つの砦でクラッカーを撃退せよ---」を日経BP 社の許可を得て転載したものです。
Copyright(C)1999 by 仙石浩明 <sengoku@gcd.org>
無断転載を禁じます