この章では、新しくインストールした我々のシステムで、 どのサーヴィスが動いているかを見て、どれが本当に必要なものかを決め、 それ以外のものを切り捨てましょう。 どのようにサーバと TCP 接続が働いているかに詳しくない方は、 まず補遺のサーバとポートに ついての章を読むと良いでしょう。 また netstat ユーティリティに馴染みがないなら、 あらかじめその簡単な概説 を読むと良いでしょう。 さらに補遺には ポートについての章と、 それに対応するサーヴィスの章がありますので、参考になるかもしれません。
ここでの目的は可能な限り多くのサーヴィスを停止することです。 もし、その全部を停止できるなら、 または少なくとも外部に接続しているものを止められるなら、 大変に結構なことです。 以下に手引きにする簡単なルールを挙げましょう:
外部からアクセス可能であるようなサーヴィスが一つも走っていなくても、 十分完全なインターネット接続を持つことは完璧に可能です。 可能であるだけでなく、多くの場合それが望ましくもあります。 ここでの原則は、 そもそも開いていないポートを通って首尾よく侵入することは 決して出来ないということです。 なぜなら、開いていなければ、 どのサーバもそこで listen して(耳をすませて)いないからです。 サーバなし、開いているポートなし、弱点もなし、です。 すくなくとも外部からの接続に関してはそうです。
もしあなたがあるサーヴィスを認識していないとすると、 本当にはそれを必要としていない可能性はかなりあります。 そう仮定して、それを停止してしまうことにしましょう。 これは危険に聞こえるかもしれませんが、頼るに足るなかなか良いルールです。
いくつかのサーヴィスはそもそも、 インターネット上を走らせるように設計されていません。 もしあなたがそれを本当に必要なものだと決定したとしても。 これらについては危険だと旗を立てておいて、後の章で取り組むことにしますので、 それらが本当に必要なサーヴィスで、 他に良い代替策がない場合には、そちらを見てください。
それで、結局このシステムでは実際に何が走っているのでしょうか? 動いているに"違いない"ものや、 または、"そう思っている"ものが実際に動いているかどうか、 何もかも当然のことだと思うのはやめましょう。
残念ながら、標準の Linux インストールといったものは存在しません。 可能なサーヴィスには幅広いバラエティがあり、 各ディストリビューションにはそれぞれのインストールオプションが伴っていて、 前もってそのリストを準備することは不可能です。 最善のことは、動いている全てのサーヴィスを数え上げる方法を示し、 正しい普遍的な方向へ導くことです。
さあ、xterm を開いて、 su でルートになりましょう。 行が折り返されないようにウィンドウを広げる必要があるでしょう。 コマンド、netstat -tap |grep LISTEN を使ってください。これによって、LISTEN というキーワードが示されている全ての現在動作中のサーバが、 各サーヴィスをスタートさせた "PID" と "プログラム名" とともに、リストアップされます:
# netstat -tap |grep LISTEN *:exec *:* LISTEN 988/inetd *:login *:* LISTEN 988/inetd *:shell *:* LISTEN 988/inetd *:printer *:* LISTEN 988/inetd *:time *:* LISTEN 988/inetd *:x11 *:* LISTEN 1462/X *:http *:* LISTEN 1078/httpd bigcat:domain *:* LISTEN 956/named bigcat:domain *:* LISTEN 956/named *:ssh *:* LISTEN 972/sshd *:auth *:* LISTEN 388/in.identd *:telnet *:* LISTEN 988/inetd *:finger *:* LISTEN 988/inetd *:sunrpc *:* LISTEN 1290/portmap *:ftp *:* LISTEN 988/inetd *:smtp *:* LISTEN 1738/sendmail: accepting connections *:1694 *:* LISTEN 1319/rpc.mountd *:netbios-ssn *:* LISTEN 422/smbd |
上では、 はじめの三つのコラムは見やすいように省いてあることに注意してください。 もしあなたが得たリストが上の例と同じくらい長いものなら、 これから少なからぬ仕事が待ち構えていますよ! これに近い数のサーバが実際に動いている必要があることは、 まったくありそうにないことですから。
上の例はたくさんのシステム設定のほんの一つの例に過ぎない、 ということに注意してください。 あなたの場合にはずいぶんと違ったものであるかも知れません。
このどれも何のことやら分らない? 補遺の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 サーバを走らせる必要はまったくありませんし、 深刻なセキュリティ上の問題を持つことになります。
個々の事情によっては、 上で得た結論に例外を設けた方が良いこともあるでしょう。 後の章を参照してください。
以下はインターネット上で走らせるべきでない サーヴィスのリストです。 これらは動かないようにしておくか(以下を見てください)、 アンインストールしてください。または、 もし本当にこれらのサーヴィスをローカルで走らせたいなら、 それらが最新のパッチを当てたバージョンであり、かつ、 効果的にファイアーウォールで守られていることを確認してください。 そして、今のところファイアーウォールを持っていないというなら、 ファイアーウォールが立ち上がって適切に動いていることが検証されるまで、 それらのサーヴィスを止めておいてください。 これらはその性質からして潜在的に危険であり、 クラッカーの一番の標的になります。
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 上の他のホストから直接 メイルを受け取っているのならば、必要かもしれませんが、 最初はこれを動かさない方が安全です。 後に、ファイアーウォールとアクセスポリシーが設定されてから、 ローカルインターフェース上で動かすことができますから。
以上は必ずしも完全なリストではありません。 ただ、デフォルトの Linux インストールでは時々、 最初から動いているサーヴィスとして良く見られるものだということです。 そして逆に言えば、 このリストに出ていない他のサーヴィスがもとより 安全なものだということでもありません。
次のステップは我々の「殺しのリスト」に挙がっている各サーバが どこで開始されたのかを調べることです。 これが netstat の出力から明らかでないならば、 最後のコラムの "Program name" か "PID" の 情報から、ps, find, grep, locate などのコマンドを 使ってさらなる情報を得てください。 この例が補遺の netstat チュートリアルの プロセスの所有者 の章に挙げられています。 もしサーヴィス名かポート番号が馴染みのないものなら、 そのシステムの /etc/services ファイルに 簡単な解説があります。
今、我々は自分のシステムを壊しつつあって、 覆水盆に返らずなどということにならないか、 と心配しているのではないですか? もしそうなら、こうしてみてください: つまり、"危険地帯"で上のリストに挙がった全てを停止し、 そしてしばらくの間システムを走らせてみます。 大丈夫ですか? 上で不必要だと判断したものたちの一つを止めてみましょう。 それでしばらくシステムを走らせてみます。 この手続きを最小の状態になるまで繰り返します。 これがうまくいけば、この変更を採用してそのまま保ちましょう。 (以下を参照してください。)
究極の目的は今そのサーヴィスを停止することではなくて、 それが恒常的に停止されていることをはっきりさせることです! ですから、あなたがここでどのようなステップをとったにせよ、 次にリブートした後には必ず確認してください。
システムのサーヴィスは様々の場所で色々な方法で開始されます。 その最も普通の方法を見てみましょう。 あなたのシステムもおそらくそのように動いているだろうと思います。 ほとんどのディストリビューションにおいて、 システムのサーヴィスは典型的には "init" スクリプト、または inetd (またはその代替物である xinetd) のどちらかによって開始されます。 (init スクリプトの置かれている場所はディストリビューションによって、 様々かもしれません。)
init サーヴィスは典型的には、ブートプロセス、 またはランレベルの切り替え時に自動的に開始されます。 どのサーヴィスをどのランレベルで開始し、停止するかを決定するためには、 シンボリックリンクを使う方法があります。 スクリプト自身は /etc/init.d/ の中 (または、 /etc/rc.d/init.d/ の中かもしれません) に置かれているはずです。 この init の方式は Red Hat, SuSE, Mandrake, Debian, COnectiva などほとんどの Linux で用いられています。 Slackware は注意すべき例外の一つです! (最近のバージョンではこのオプションを持っていますが。) 典型的には Slackware ではシステムサーヴィスは一つのファイル /etc/rc.d/rc.inet2 で全て設定されます。
以下のようにすれば、 このスクリプトのリストを得ることができます。
# ls -l /etc/init.d/ | less |
または各ディストリビューションで用意されている、 このためのツールを使ってください。
(非常に一般的な SysV init スタイルのシステムでは) 走っているサーヴィスを今、止めるには、 root になって以下のようにします:
# /etc/init.d/<$SERVICE_NAME> stop |
ここで "$SERVICE_NAME" はその init スクリプトの名前で、 常にではありませんが、しばしばそのサーヴィスの名前そのものと同じです。 これはほとんどのディストリビューション上で 使える手です。 古い Red Hat バージョンでは代わりに /etc/rc.d/init.d/ がパスになっているかもしれません。
これはこの特定のサーヴィスを今、停止することができるだけで、 追加的なステップをとらなければ、 次のリブート時、またはランレベル変更時には再スタートしてしまいます。 ですから、init 型のサーヴィスについては、 この作業は実際二段階のプロセスということになります。
各ディストリビューションでは、 様々なランレベルでどのサーヴィスを開始させるかを 制御するためのユーティリティが使えるようになっているでしょう。 Debian に基づいたシステムではこのための update-rc.d がありますし、 Red Hat に基づいたシステムでは chkconfig があります。 これらのツールに慣れ親しんでいるなら、 今それを使って、次のリブートの後に再チェックしてください。 これらのツールに慣れていないのでしたら、 man ページを見て今、勉強しましょう! これは知っていなくてはならないものです。 Debian では次のようにします (以下で、$SERVICE_NAME は init スクリプトの名前です):
# update-rc.d -f $SERVICE_NAME remove |
Red Hat では:
# chkconfig $SERVICE_NAME off |
もしあるサーヴィスが必要でないことがわかっているなら、 また一つの手段はそのパッケージをアンインストールしてしまうことです。 これはなかなか良い、間違いのない方法で、恒常的に停止できます。 またこの方法は、 インストールされているすべてのパッケージをアップデートして 最新のものに保ち続ける(ステップ2)、 という潜在的な問題を解決してくれてもいます。 RPM や DEB といったパッケージ管理システムを使えば、 気が変わったときに パッケージを再インストールするのもとても簡単です。
inetd はサブデーモンを生むために使われるので、 "スーパーデーモン" と呼ばれます。 inetd 自身は一般に init スクリプト経由で開始され、 設定ファイル /etc/inetd.conf で 可能になっているサーヴィスによって決まる様々なポートに "耳をすませる"ことになります。 ここで挙げられているどのサーヴィスも inetd に 制御されます。 同様に、"プログラム名"の後の最後のコラムに "inetd" と書かれている netstat 出力 の中の listen している(つまり、耳をすませている)サーバは皆、 inetd によって開始されることになります。 これらのサーヴィスを停止するためには、 inetd の設定を調整する必要があるでしょう。 xinetd は inetd の の拡張された代替物ですが、設定方法は異なります (以下の次の章を見てください)。
以下は典型的な inetd.conf からの抜粋です。 行の最初に "#" がついているサーヴィスは "コメントアウト"されていて、 inetd には無視されるので、 結果として無効にされます。
# # inetd.conf This file describes the services that will be available # through the INETD TCP/IP super server. To re-configure # the running INETD process, edit this file, then send the # INETD process a SIGHUP signal. # # Version: @(#)/etc/inetd.conf 3.10 05/27/93 # # Authors: Original taken from BSD UNIX 4.3/TAHOE. # Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # # Modified for Debian Linux by Ian A. Murdock <imurdock@shell.portal.com> # # Echo, discard, daytime, and chargen are used primarily for testing. # # To re-read this file after changes, just do a 'killall -HUP inetd' # #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal time stream tcp nowait root internal # # These are standard services. # #ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd #comsat dgram udp wait root /usr/sbin/tcpd in.comsat #talk dgram udp wait root /usr/sbin/tcpd in.talkd #ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd #dtalk stream tcp wait nobody /usr/sbin/tcpd in.dtalkd # # 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 # # The Internet UUCP service. # #uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l # <snip> |
上の例では二つのサーヴィス、 time と pop3 が可能になっています。 これらを無効にするには、 テキストエディタでこのファイルを開いて、 この二つのサーヴィスを "#" でコメントアウトし、 ファイルを保存して、(ルートとして)inetd を 再スタートするだけです:
# /etc/init.d/inetd restart |
エラーがないかログを調べて、 netstat を再び走らせ、 全てがうまく行っているか確かめてください。
同じ情報を手っ取り早く得るには、 以下のように grep を使います。
$ grep -v '^#' /etc/inetd.conf time stream tcp nowait root internal pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d |
またしても、それが何だか知らないものが出てきましたか? でしたら、十中八九あなたはそれを使っていないので、 無効化すべきです。
init サーヴィスの設定とは違って、 これは後まで続く変更なので、必要なのはこのステップ一回だけです。
あちこちに広がっている一つの神話を暴露しましょう: /etc/services ファイルから 項目をコメントアウトしたり削除したりすることで、 サーヴィスを無効化すべきではありません。 これはある場合には、望んだ効果が得られるかもしれませんが、 正しい方法ではなく、他のシステムユーティリティの通常の操作を 邪魔することになるかもしれません。
xinetd は 拡張された機能を持つ inetd の代替物です。 これは本質的に inetd と同じ目的を果たしますが、 設定が異なります。 設定は /etc/xinetd.conf ファイルか、 /etc/xinetd.d/ ディレクトリの個別のファイルで 行うことができます。 xinetd サーヴィスの停止は、 対応する設定箇所かファイルを削除することで可能です。 または、テキストエディタを用いて、単に適当なサーヴィスについて disable = yes と設定することでも可能です。 このとき、xinetd は再スタートする必要があります。 構文と設定オプションについては man xinetd と man xinetd.conf を見てください。以下はxinetd の設定例です:
# default: on # description: The wu-ftpd FTP server serves FTP connections. It uses \ # normal, unencrypted usernames and passwords for authentication. service ftp { disable = no socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION USERID log_on_failure += USERID nice = 10 } |
以下のように、動作しているサーヴィスのリストを簡単に得ることができます。
$ grep disable /etc/xinetd.d/* |grep no /etc/xinetd.d/finger: disable = no /etc/xinetd.d/rexec: disable = no /etc/xinetd.d/rlogin: disable = no /etc/xinetd.d/rsh: disable = no /etc/xinetd.d/telnet: disable = no /etc/xinetd.d/wu-ftpd: disable = no |
ここで、上の出力にはいくつか赤信号が点いています。 圧倒的多数のシステムでは、上のどれも悪影響なしに停止できます。 確かかって?そのサーヴィスを停止して試してみてください。 不必要なサーヴィスを無効化して、xinetd を 再スタートさせてください。
# /etc/init.d/xinetd restart |
もしあなたがサーヴィスを停止する"正しい" 方法を見つけられないとしても、または、 開始されているあるサーヴィスが どうやってどこで開始されたのかわからないとしても、大丈夫。 そのプロセスを"殺す"ことができます。 これを行うには、PID(プロセスI.D.)を知る必要があります。 これは ps, top, fuser といったコマンド、 または他のシステムユーティリティを使って見つけることができます。 top と ps については、 最初のコラムに出ている数字がこれです。 例については、 補遺のポートとプロセスオーナーを見てください。
例(ルート権限で):
# 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 |
上では、全ての不必要なサーヴィスを 停止する基準を用いましたが、 時にそれはそんなに明白なことではありません。 そして、時折、ある人の設定で要求されていることは、 他の人にとってのものと異なるかも知れません。 このようなカテゴリーに入る二、三の一般的なサーヴィスを見てみましょう。
再び、我々の目安となるのは、 必要としていないものはそもそも走らせない、という単純なルールです。 もしそれらのどれも必要としていないなら、 ファイヤーウォールのルールや他の仕組み(以下を見てください) によるこの種の制限ポリシーを運営するにあたって、 一番に停止するべき候補です。
identd - これはかなり年季の入ったプロトコルで、 しばしばデフォルトでインストールされ走っています。 これはサーバにつながっている者についての最小限の情報を得るためのものです。 しかし、これは多くの場合、必要ではありません。 では、どこで必要になるでしょうか? ほとんどの IRC サーバはこれを必要とします。 多くのメイルサーバもこれを使っていますが、実際は必要ありません。 それ抜きでのメイル設定を試してみてください。 もし、identd が問題になるなら、 その理由はサーバがメイルを送ったり受け取ったりする前に タイムアウトすることでしょう。 ですから、 メイルはそれ抜きでもちゃんと動くはずですが、 動作は遅くなるかもしれません。 二、三の ftp サーバはそれを必要とします。 しかし、ほとんどのものでは要りません。
もし、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 は、 "キャッシング" オンリーモードでしばしば用いられていて、 これは大変便利ですが、 インターネットに完全にさらす必要はありません。 つまり、それは適用を制限するか、 ファイアーウォールで守るべきです。 以下の 個別のアプリケーション の 特別な運用法の箇所を参照してください。
この章では、 システム上でどんなサーヴィスが走っているかを同定する方法を学び、 どれが必要なサーヴィスかを決めるためのポイントをいくつか紹介しました。 さらに、そのサーヴィスがどこで開始されたのかを見つけ、 それらを停止する方法を学びました。 もしこれがよく分っていないようなら、今が上を読み返す良いチャンスです。
望むらくは、 あなたは上で示したステップを既にとってくれていることでしょう。 その結果を netstat で再度テストして、 望みの結果が達成されていること、そして、 本当に必要なサーヴィスだけが走っていることを確認してください。
次回のリブート時、パッケージを更新した時 (新しい設定がそっと忍び込んでいないことを確認するためです)、 そしてシステムがアップグレードされた時や新たにインストールされた時は常に、 このようなチェックをすることをお勧めします。