Security Quick-Start HOWTO for Red Hat Linux
Prev		Next

3. ステップ１：本当に必要なのはどのサーヴィスか？

この章では、新しくインストールした我々のシステムで、どのサーヴィスが動いているかを見て、どれが本当に必要なものかを決め、それ以外のものを切り捨てましょう。どのようにサーバと TCP 接続が働いているかに詳しくない方は、まず補遺のサーバとポートについての章を読むと良いでしょう。また netstat ユーティリティに馴染みがないなら、あらかじめその簡単な概説を読むと良いでしょう。さらに補遺にはポートについての章と、それに対応するサーヴィスの章がありますので、参考になるかもしれません。

ここでの目的は可能な限り多くのサーヴィスを停止することです。もし、その全部を停止できるなら、または少なくとも外部に接続しているものを止められるなら、大変に結構なことです。以下に手引きにする簡単なルールを挙げましょう：

外部からアクセス可能であるようなサーヴィスが一つも走っていなくても、十分完全なインターネット接続を持つことは完璧に可能です。可能であるだけでなく、多くの場合それが望ましくもあります。ここでの原則は、そもそも開いていないポートを通って首尾よく侵入することは決して出来ないということです。なぜなら、開いていなければ、どのサーバもそこで listen して（耳をすませて）いないからです。サーバなし、開いているポートなし、弱点もなし、です。すくなくとも外部からの接続に関してはそうです。
もしあなたがあるサーヴィスを認識していないとすると、本当にはそれを必要としていない可能性はかなりあります。そう仮定して、それを停止してしまうことにしましょう。これは危険に聞こえるかもしれませんが、頼るに足るなかなか良いルールです。
いくつかのサーヴィスはそもそも、インターネット上を走らせるように設計されていません。もしあなたがそれを本当に必要なものだと決定したとしても。これらについては危険だと旗を立てておいて、後の章で取り組むことにしますので、それらが本当に必要なサーヴィスで、他に良い代替策がない場合には、そちらを見てください。

3.1. システム検査

それで、結局このシステムでは実際に何が走っているのでしょうか？動いているに"違いない"ものや、または、"そう思っている"ものが実際に動いているかどうか、何もかも当然のことだと思うのはやめましょう。

どのサーヴィスがインストールされていて、実際動いているかは、 Red Hat のどのバージョンが選ばれているか、どのインストールオプションが選択されているかに強く依存します。初期のリリースでは多くのサーヴィスをスタートさせる傾向が大いにありましたし、それゆえにユーザにどれが必要でどれがそうでないかを考えさせていました。最近のバージョンでははるかに用心深くなっています。しかし、これによって、動いているであろうサーヴィスを事前に数え上げることが不可能になっています。しかし、ご心配なく。そもそも、動いているであろう、などと勝手に決め付けたサーヴィスを信用すべきでないからです。しなければならないことは、動作中の全てのサーヴィスのリストを作ることです。

さあ、xterm を開いて、 su でルートになりましょう。行が折り返されないようにウィンドウを広げる必要があるでしょう。コマンド、netstat -tap |grep LISTEN を使ってください。これによって、LISTEN というキーワードが示されている全ての現在動作中のサーバが、各サーヴィスをスタートさせた "PID" と "プログラム名" とともに、リストアップされます：

Red Hat 7.x と Mandrake 8.x とそれ以降のバージョンのユーザは inetd のところが xinetd になっているでしょう。上では、はじめの三つのコラムは見やすいように省いてあることに注意してください。もしあなたが得たリストが上の例と同じくらい長いものなら、これから少なからぬ仕事が待ち構えていますよ！これに近い数のサーバが実際に動いている必要があることは、まったくありそうにないことですから。

上の例はたくさんのシステム設定のほんの一つの例に過ぎない、ということに注意してください。あなたの場合にはずいぶんと違ったものであるかも知れません。

このどれも何のことやら分らない？補遺のnetstat のチュートリアルを読んで、その働きを理解してくれていることと思いますが、上に挙げた例で各サーバが何なのか、何をするものかを、正確に理解することは、この文書の範囲に含まれません。もし、そのサーヴィスが実際に重要なものならば、個々のシステムについての文書（例えば、インストールガイドや、 man ページなど）を調べなければならないでしょう。例えば、"exec", "login", "shell" は重要そうに見えますか？もちろんそうです。しかし、これらは実際はその見かけ通りのものではありません。実のところ、それらは rexec, rlogin, rsh といった"r" コマンド、つまりリモート用のコマンドです。これらは古臭くて、不必要で、実際のところ、インターネットにさらしていると非常に危険です。

何が必要で何が必要でないか、そして何を捨てて何をこの bigcat においておくかについて簡単な仮説を二、三、用意しておきましょう。 bigcat はデスクトップで走らせていますから、もちろん X11 は残す必要があります。もし bigcat が何かのサーバ専門に使われていたなら、 X11 は不要だったでしょう。もし物理的につながったプリンタがあるなら、プリンタ (lp) デーモンは残すべきです。そうでないなら要りません。プリントサーバは無害そうに見えますが、ポートを開いたままに出来るので、やはり潜在的なターゲットになります。もし他のホストから bigcat の中に ログインする予定があるなら、 sshd （セキュアシェルデーモン）が必要でしょう。我々の LAN に Microsoft のホストがあるならば、 Samba が欲しいかもしれません。でしたら、smbd は残さなくてはいけませんが、そうでなければ全く不必要です。この例ではその他のものは全部、（選択するのは自由ですが、）通常の機能のシステムなら不必要で、おそらく切り捨てるべきでしょう。あなたが認識していないものがある？あやふやなものがある？それは切りましょう！

結論：bigcat はプリンタがつながっているデスクトップマシンですから、 "x11" と "printer" が必要になるでしょう。 bigcat は MS ホストとともに LAN 上にあって、ファイルを共有したり、それらから印刷したりしますから、 "netbios-ssn" (smbd) が必要です。また他のマシンからログインできるように、 "ssh" も必要です。この特定の場合においては、その他のものは全て不必要です。

これが心配ですか？そうなら、自分が行った変更を書き留めておくか、または、コマンド： netstat -tap |grep LISTEN > ~/services.lstを使って、 netstat から得たサーバのリストを保存しておくのがよいでしょう。このコマンドで将来に参照するためのリストが "services.lst" の名前でホームディレクトリに保存されます。

ここで残すことに決めたものも、そもそも安全なものだとは言えません。単に、これらが必要であろう、というだけです。ですから、ファイアーウォールや（以下にあるような）他の方法を通して、これらを扱わなければいけません。

上の例の中の telnet と ftp デーモンはサーバであり、 "リスナー"（ポートで耳をすませているもの）だということは、注意しておく価値があるでしょう。これらはあなたのマシンに入ってくる接続を受け付けます。あなたが単に ftp または telnet クライアントを使うためには、これらは必要ないし、望んでもいないことです。例えば、あなたは単に ftp クライアントを用いて、 FTP サイトからファイルをダウンロードすることができます。あなたの側で ftp サーバを走らせる必要はまったくありませんし、深刻なセキュリティ上の問題を持つことになります。

個々の事情によっては、上で得た結論に例外を設けた方が良いこともあるでしょう。後の章を参照してください。

3.2. 危険地帯（または r00t m3 pl34s3）

以下はインターネット上で走らせるべきでないサーヴィスのリストです。これらは動かないようにしておくか（以下を見てください）、アンインストールしてください。または、もし本当にこれらのサーヴィスをローカルで走らせたいなら、それらが最新のパッチを当てたバージョンであり、かつ、効果的にファイアーウォールで守られていることを確認してください。そして、今のところファイアーウォールを持っていないというなら、ファイアーウォールが立ち上がって適切に動いていることが検証されるまで、それらのサーヴィスを止めておいてください。これらはその性質からして潜在的に危険であり、クラッカーの一番の標的になります。

NFS (Network File System ネットワークファイルシステム)と、 nfsd, lockd, mountd, statd, portmapper などの、その関連サーヴィス。 NFS はネットワークを経由してファイルシステムを共有する標準の Unix サーヴィスです。LAN で用いるには素晴らしいシステムですが、インターネット上では危険です。そして、スタンドアローンのシステムではまったく不要なものです。
rpc.* サーヴィス、リモートプロシージャ Call.*, など。典型的なのは NFS と NIS に関係したもの（上を参照）です。
プリンタサーヴィス（lpd）
いわゆる r* サーヴィス（"remote" つまり、Remote SHell の r ）： rsh, rlogin, rexec, rcp など。不必要で、安全でなく、潜在的に危険で、もしこれらの機能が必要なときにはより良いユーティリティがあります。 ssh はこれらのコマンドに出来ることは何でも出来るでしょうし、しかもはるかに健全な方法でできます。興味があるならそれぞれの man ページを見てください。これらは多分、 "r" 抜きで netstat 出力に示されているでしょう：例えば、rlogin は単に "login" など。
telnet サーバ。もはやこれを用いる理由はありません。代わりに sshd を使ってください。
ftp サーバ。ほとんどのシステムには、 scp や、http 経由などの（以下を参照のこと）、ファイルを交換するためのより良い、もっと安全な方法があります。 ftp は専用の ftp サーバを走らせていて、ちゃんとその面倒を見る時間とスキルのある人にとってだけ適切なプロトコルです。そうでなければ、潜在的に大きなトラブルの原因になります。
BIND (named), DNS パッケージ。いくらか手をかければ、これは大きなリスクなしに使えますが、多くの場合には必要のないものですし、それをどう使うにせよ特別な扱いが要求されます。例外の章と、個別のアプリケーションの特別な扱い方を参照してください。
メイル配送エージェント、つまり "MTA" (sendmail, exim, postfix, qmail)。一台のコンピュータ上のインストールではほとんどの場合、これらが本当に必要になることはないでしょう。あなたが、インターネットホストから（指定された MX box として）直接にメイルを受け取るのではなく、プロバイダの POP サーバを使うのなら必要ありません。 LAN 上の他のホストから直接メイルを受け取っているのならば、必要かもしれませんが、最初はこれを動かさない方が安全です。後に、ファイアーウォールとアクセスポリシーが設定されてから、ローカルインターフェース上で動かすことができますから。

以上は必ずしも完全なリストではありません。ただ、デフォルトの Red Hat インストールでは時々、最初から動いているサーヴィスとして良く見られるものだということです。そして逆に言えば、このリストに出ていない他のサーヴィスがもとより安全なものだということでもありません。

3.3. サーヴィスの停止

次のステップは我々の「殺しのリスト」に挙がっている各サーバがどこで開始されたのかを調べることです。これが netstat の出力から明らかでないならば、最後のコラムの "Program name" か "PID" の情報から、ps, find, grep, locate などのコマンドを使ってさらなる情報を得てください。この例が補遺の netstat チュートリアルのプロセスの所有者の章に挙げられています。もしサーヴィス名かポート番号が馴染みのないものなら、そのシステムの /etc/services ファイルに簡単な解説があります。

chkconfig は init スクリプトで開始されたサーヴィスをコントロールするには非常に便利なコマンドです（以下の例を見てください）。また、xinetd が使われているなら、同様にそのサーヴィスもコントロールできます。 chkconfig は、どのサーヴィスがそのシステムで走るように設定されているかを教えてくれますが、これは必ずしも本当に、実際に、動作している全てのサーヴィスではありません。つまり、他の方法で、例えば rc.local から、開始されているかもしれないサーヴィスもあるからです。それはリアルタイムのシステム監査ツールというよりも、設定用のツールなのです。

今、我々は自分のシステムを壊しつつあって、覆水盆に返らずなどということにならないか、と心配しているのではないですか？もしそうなら、こうしてみてください：つまり、"危険地帯"で上のリストに挙がった全てを停止し、そしてしばらくの間システムを走らせてみます。大丈夫ですか？上で不必要だと判断したものたちの一つを止めてみましょう。それでしばらくシステムを走らせてみます。この手続きを最小の状態になるまで繰り返します。これがうまくいけば、この変更を採用してそのまま保ちましょう。（以下を参照してください。）

究極の目的は今そのサーヴィスを停止することではなくて、それが恒常的に停止されていることをはっきりさせることです！ですから、あなたがここでどのようなステップをとったにせよ、次にリブートした後には必ず確認してください。

システムのサーヴィスは様々の場所で色々な方法で開始されます。その最も普通の方法を見てみましょう。あなたのシステムもおそらくそのように動いているだろうと思います。ほとんどのディストリビューションにおいて、システムのサーヴィスは典型的には "init" スクリプト、または inetd （またはその代替物である xinetd）のどちらかによって開始されます。

例（ルート権限で）：

# kill 1163

そして、そのプロセスが消えていることを確認するために、もう一度 top か ps を走らせてください。

# kill -KILL 1163

この二番目に出ている "KILL" に注意してください。この命令は、そのプロセスを所有しているユーザか、またはルートのどちらかによって、実行されなければなりません。さて、このプロセスがどこからどうやって開始されたか調べにいきましょう ;-)

/proc ファイルシステムは各プロセスについてのさらなる情報を見つけ出すために用いることもできます。 PID を使って、謎のプロセスへのパスを見つけることができます。

$ /bin/ps ax|grep tcpgate 921 ? S 0:00 tcpgate

# ls -l /proc/921/exe lrwxrwxrwx 1 root root 0 July 21 12:11 /proc/921/exe -> /usr/local/bin/tcpgate

3.4. 例外事項

上では、全ての不必要なサーヴィスを停止する基準を用いましたが、時にそれはそんなに明白なことではありません。そして、時折、ある人の設定で要求されていることは、他の人にとってのものと異なるかも知れません。このようなカテゴリーに入る二、三の一般的なサーヴィスを見てみましょう。

再び、我々の目安となるのは、必要としていないものはそもそも走らせない、という単純なルールです。もしそれらのどれも必要としていないなら、ファイヤーウォールのルールや他の仕組み（以下を見てください）によるこの種の制限ポリシーを運営するにあたって、一番に停止するべき候補です。

identd - これはかなり年季の入ったプロトコルで、しばしばデフォルトでインストールされ走っています。これはサーバにつながっている者についての最小限の情報を得るためのものです。しかし、これは多くの場合、必要ではありません。では、どこで必要になるでしょうか？ほとんどの IRC サーバはこれを必要とします。多くのメイルサーバもこれを使っていますが、実際は必要ありません。それ抜きでのメイル設定を試してみてください。もし、identd が問題になるなら、その理由はサーバがメイルを送ったり受け取ったりする前にタイムアウトすることでしょう。ですから、メイルはそれ抜きでもちゃんと動くはずですが、動作は遅くなるかもしれません。二、三の ftp サーバはそれを必要とします。しかし、ほとんどのものでは要りません。 Red Hat の古いバージョンでは identd を inetd 経由で開始していました。最近のバージョンでは init スクリプトで開始します。
もし、identd が必要ならば、以下のように、報せる情報を大いに減らしてくれる設定オプションがあります：
/usr/sbin/in.identd in.identd -l -e -o -n -N
-o フラッグは identd に、その上で走っているOS のタイプを示さず、そのかわりに常に "OTHER" を返すよう伝えます。 -e フラッグは identd に、 "NO-USER" や "INVALID-PORT" エラーの代わりに常に "UNKNOWN-ERROR" を返すよう伝えます。もしあなたがユーザ名を秘密にしておきたいなら、 -n フラッグは identd に、ユーザ名の代わりに常にユーザ番号を返すように伝えます。 -N フラッグは identd に、デーモンがユーザ名を返そうとしているそのユーザのホームディレクトリにある .noident をチェックさせます。そのファイルが存在すれば、デーモンは普通に "USERID" の代わりに "HIDDEN-USER" エラーを返します。
メイルサーバ（sendmail, qmail などのようなMTA）－しばしば sendmail のような完全な機能を持つメイルサーバがデフォルトでインストールされています。これが実際に必要になるのは、ドメインのホストをしていて、直接に入ってくるメイルを受け取るときだけです。あるいは、LAN 上でメイルを交換するときですが、この場合にはインターネットにさらす必要はありませんし、安全にファイアーウォールで守ることができます。プロバイダへの POP メイルアクセスのためには、よく行われている設定ではありますが、メイルサーバを必要としません。この代わりの手段の一つは、ローカルな配送エージェントを -m オプションで指定して fetchmail に POP メイルを取りに行かせることです：例えば、fetchmail -m procmail は sendmail デーモンが全く走っていなくてもちゃんと働きます。 sendmail は走らせておくと便利なものではありますが、ここでのポイントは、それは多くの場合は必要ではなく、停止させるか、またはファイアーウォールで安全に守ることが出来る、ということなのです。
BIND (named) －これはしばしばデフォルトでインストールされていますが、実際に必要になるのは、あるドメインの、オーソライズされたネームサーバを運用するときだけです。もしあなたがこれが何を意味しているのかよくわからないなら、これは絶対に不要です。おそらく、BIND はインターネット上で一番狙われているターゲットでしょう。 BIND は、 "キャッシング" オンリーモードでしばしば用いられていて、これは大変便利ですが、インターネットに完全にさらす必要はありません。つまり、それは適用を制限するか、ファイアーウォールで守るべきです。以下の個別のアプリケーションの特別な運用法の箇所を参照してください。

3.5. ステップ１のまとめと結論

この章では、システム上でどんなサーヴィスが走っているかを同定する方法を学び、どれが必要なサーヴィスかを決めるためのポイントをいくつか紹介しました。さらに、そのサーヴィスがどこで開始されたのかを見つけ、それらを停止する方法を学びました。もしこれがよく分っていないようなら、今が上を読み返す良いチャンスです。

望むらくは、あなたは上で示したステップを既にとってくれていることでしょう。その結果を netstat で再度テストして、望みの結果が達成されていること、そして、本当に必要なサーヴィスだけが走っていることを確認してください。

次回のリブート時、パッケージを更新した時（新しい設定がそっと忍び込んでいないことを確認するためです）、そしてシステムがアップグレードされた時や新たにインストールされた時は常に、このようなチェックをすることをお勧めします。

Prev	Home	Next
はじめに		ステップ２：アップデート作業