このドキュメントでは、本当にインストール直後の
簡単な対策を書いて見た。
なんのことはない、
inetd
を止めるとか、
sendmail
は動かさないとかいった、
専門家からすれば
馬鹿々々しいようなことしか書いていない。
/etc/inetd.conf の編集
最初に行うのが
/etc/inetd.conf
の設定。
このファイルは
ネットワーク越しのログインやネットワーク越しのファイル転送
などを司るプログラムを起動するために必要データが書いてある。
大部分のインターネット越しのサービスはこのファイルに書かれていると
考えても良い。
もちろん、この他にもある。
この他にもあるが、まずはこのファイルを何とかしないで
先に進むことは出来ない。
更に、個々のプログラムはプログラム固有の
設定ファイルを参照する場合がある。
それは一応覚えていた方が良い。
このファイルは私の場合次のようになっている。
# $FreeBSD: src/etc/inetd.conf,v 1.44.2.3 2000/10/04 07:58:51 kris Exp $ # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l telnet stream tcp nowait root /usr/libexec/telnetd telnetd shell stream tcp nowait root /usr/libexec/rshd rshd #login stream tcp nowait root /usr/libexec/rlogind rlogind #finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s #exec stream tcp nowait root /usr/libexec/rexecd rexecd #uucpd stream tcp nowait root /usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp wait tty:tty /usr/libexec/comsat comsat #ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp wait nobody /usr/libexec/tftpd tftpd /tftpboot #bootps dgram udp wait root /usr/libexec/bootpd bootpd # # "Small servers" -- used to be standard on, but we're more conservative # about things due to Internet security concerns. Only turn on what you # need. # #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal (以下略)
上の場合、行の先頭に
#
がついている行とついてない行がある。
ついてない行で何かが書いてある行は
その先頭のサービスが有効になっているということである。
例えば、
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l telnet stream tcp nowait root /usr/libexec/telnetd telnetd shell stream tcp nowait root /usr/libexec/rshd rshd
というのは全部有効になっている。
つまり私のマシンでは
ftp,
telnet,
shell
というサービスを提供していることになる。
最後の
shell
というのは
rsh
というものと同じで、
私がこれを有効にしているのは
CVS を使っているからである。
一方で、
finger
というのは行の頭に
#
がついている。
これは
finger
というサービスを停止していることになる。
とにかくすることはただ一つ。
/etc/inetd.conf
のすべての行の先頭に
#
をつけること。
大抵の人はこれだけでも構わないだろう。
上の私の例では、たまたま
telnet
が有効になっているがそれは承知の上でしていることなので、
telnet
が何かを分からないぐらいなら、
行の先頭に
#
をつけても全然困らない。
最初にするのはエディタで上のファイルを編集して
全部の行に
#
をつけるということである。
編集が終っても、その設定は反映されてない。 それを反映させるためには 再起動するか、 次のようにする。
# ps -aux | grep inetd ageha 910 0.0 0.5 1056 640 p2 S+ 3:06AM 0:00.01 grep inetd root 103 0.0 0.5 1032 672 ?? Is 11:07PM 0:00.02 inetd -wW # kill -HUP 103
inetd
というプロセスに再起動のための
HUP
というシグナル(合図程度に思って良い)を送る。
これで、
inetd
というプログラムは再起動して、設定ファイルを読み直す。
この時点で設定が有効になる。
これが面倒なら、再起動すれば良い。
ps
というコマンドは現在実行中のすべてのプロセスの状態を表示する。
実行中のプロセスはプロセス番号 (PID) を持っていて、
この番号でプロセスを指定する。
だから、このプロセスに再起動の合図を送るには
このプロセスの番号を調べてその番号を指定しないといけない。
私のシステムの場合
103
という番号が
inetd
に割り振られていたのである。
そして
kill -HUP 103
によって 103 番のプロセス、すなわち
inetd
に再起動の合図を送ったのである。
inetd 自体を止める
これで
inetd
から起動されるような代表的なインターネットサーバは停止できるが
inetd
自体は動いている。
ただ、外から来たリクエストを如何なるプログラムにも引き継がない
だけである。
私はそれでも
inetd
は動かしている。
kill -HUP
でいつでもサービスの停止・開始が出来るからだ。
これはパソコンが何台かあるので、
別のパソコンをつないで
telnet
や
ftp
を使えるようにしておきたいからである。
しかし、それが気に入らない、あるいはパソコンが
一台しかないのであれば最初から動かす必要すらない。
だからそんなものは止めてしまうに限る。
以下は FreeBSD の場合の設定なので、
Linux の人の場合には
/etc/rc.d
あたりの設定ファイルを見て設定して欲しい。
(最近 Linux は使っていないので、具体的な設定が思い出せない。)
FreeBSD の場合
inetd
の起動は
/etc/rc.conf
でコントロールする。
rc.conf
というファイルがなければ作ってしまって構わない。
そのファイルに
inetd_enable="NO"
と入れれば良い。
参考までに私の
/etc/rc.conf
は次のようになっている。
# This file now contains just the overrides from /etc/defaults/rc.conf # please make all changes to this file. # Enable network daemons for user convenience. # -- sysinstall generated deltas -- # moused_flags="" linux_enable="YES" sendmail_enable="NO" moused_enable="YES" saver="logo" keymap="jp.106x" sshd_enable="NO" inetd_enable="YES" network_interfaces="dc0 lo0" ifconfig_dc0="inet 192.168.0.1 netmask 255.255.255.0" defaultrouter="" hostname="localhost.localdomain" usbd_enable="NO" apm_enable="YES" # Set to YES to enable APM BIOS functions (or NO). apmd_enable="NO" # Run apmd to handle APM event from userland. apmd_flags="" # Flags to apmd (if enabled). dumpdev="/dev/ad0s1b" # Device name to crashdump to (or NO). # -- sysinstall generated deltas -- # nfs_client_enable="NO" portmap_enable="NO" # Run the portmapper service (or NO). # -- sysinstall generated deltas -- # blanktime="300"
繰り返すが、私は自分自身の判断で
あえて
inetd
は動かしている。
だから、上では
inetd_enable="YES"
となっている。
以上の他に、
sendmail,
ssh,
usbd,
ampd,
nfs
は止めている。
ちなみに、
ampd
というのは
Advaned Power Management
つまり電源管理システムの使い勝手をあげるための daemon
で、
usbd
というのは
USB
管理のための daemon である。
これらはインターネットサーバとは違う種類の
サーバプログラムで、今回のセキュリティの話とは関係ない。
インターネットを介して提供できるサービスの
大部分は
inetd
から起動されるが、
そうでないものもある。
だから、
inetd
を止めるのが基本だとしても
それですべてという訳でもない。
これは念頭に入れておいた方が良い。
例えば
httpd
は、
inetd
から起動も出来るが大部分の場合
スタンドアロンでクライアントの要求を待ち受けるべく
常駐している。
sshd
のように
inetd
からは起動できない種類のプログラムもある。
sshd
の場合乱数の初期化の関係上どうしても最初から
起動していないといけないからだ。
そういったサービスの中で
結構危ういものが多数存在する。
代表各は
NIS
とか
nfs
とかいったサービスだ。
nfs
はともかくとしても、
最初に想定したような個人ユーザが
NIS
を動かす必然性なんて全く考えられないし、
更にパソコンが一台しかない人が
nfs
を動かす必要も全然ない。
さらにメール配送システムの
sendmail
なんてシステムの脅威となることは最近は
あまりなくなったが、
下手に動かすとあなたの社会的な立場に決定的な打撃を与えることもある。
そういったものを以下で考えていくことにする。
まずはメールサービスの停止。 ただ誤解しないで欲しい。 ここで言っているメールサービスというのは、 メールの到着を待ち、受け取り、あるいは別のコンピュータへ転送する ためのサービスである。 簡単に言ってしまうと、 あなたが利用している ISP のメールサーバと同等のサービスである。 だから、考えるまでもなく個人レベルでしかも www の閲覧程度しかしていない人には無縁の代物である。
最近はもっともセキュリティホールの多かった、
sendmail
ですら致命的なバグの話を聞かない
(ただたまに Linux あたりでバグの話は出るようだ)。
しかし、この場合に問題になるのは
メールの中継をしてしまうことである。
広告メール、脅迫メール、いやがらせメール、
果てはメールボムの送信を手伝うことになり兼ねない。
あなた自身が被害者にならなくても、
あなたは確実に犯罪の共犯として疑いを受ける可能性があるし、
民事上は責任を追及される可能性もある。
そういった意味で、
このドキュメントで想定しているような
個人がこのサービスを動かす必要など
絶対に考えられないので、
議論の余地なく止めてしまった方が良い。
FreeBSD なら上の
/etc/rc.conf
に
sendmail_enable="NO"
と入れておけば良い。
他のシステムだと分からないが、
ps -auxw | grep sendmail
してみて、
何も表示されないか、
# ps -auxw | grep sendmail ageha 970 0.0 0.7 1380 904 p3 RV 4:03AM 0:00.00 grep sendmail
となるのなら、問題はない。
もしも、
/usr/sbin/sendmail -bd -q30m
なんて表示が出たら止めてしまった方が良い。
もっとも、最近の多くのシステムはデフォルトで
sendmail
は動作はするが、人のメールの中継を行うようには
なっていないシステムの方が多い。
しかし、だからこそ、要らないのだから止めてしまった方が
あとくされがない。
sendmail
を止めてしまってもメールを出すことは出来る。
最近では多くの MUA が送信と受信を自前で処理してくれるからだ。
例えば、
Mew
なんかを使えば、直接 ISP のメールサーバと交信して
メールを ISP のメールサーバに渡してくれる。
メールを受け取る場合にも、同様で、
ISP の POP サーバと通信してメールをとって来るようになっている。
だから、個人レベルで電子メールのやりとりをするのに
sendmail
やら
qmail
やらを動かす必然性は全くない。
nfs というのはネットワーク越しのマシンのディスクを マウントする機能である。 これを使えば地球の裏側のマシンのディスクも あなたのシステムの一部としてマウントできる。 共通の仕組みなので、 OS の差異は問題にならない。 逆に言うと、相当に開放的な仕組みなので、 下手な設定で動かすとあなたのファイルシステムは 地球の裏側からもマウントできることになる。
何をするものかが分かったなら、話は早い。
これはパソコン一台なら関係ない仕組みである。
更に、パソコンが複数でも
ftp
を使えば済むことも多い。
だから普通の人がこんなものを動かす必要性はどこにもない。
これも
FreeBSD
なら
/etc/rc.conf
で設定すれば起動しない。
4.1-RELEASE
以降だとデフォルトではサービスは有効にならないが、
念のために
デフォルトの設定の
/etc/defaults/rc.conf
を見た方が良い。
私の場合 FreeBSD 4.2-BETA を使っているが、
設定は次のような感じになっている。
nfs_client_enable="NO" # This host is an NFS client (or NO). nfs_client_flags="-n 4" # Flags to nfsiod (if enabled). nfs_access_cache="2" # Client cache timeout in seconds nfs_server_enable="NO" # This host is an NFS server (or NO). nfs_server_flags="-u -t -n 4" # Flags to nfsd (if enabled). single_mountd_enable="NO" # Run mountd only (or NO). mountd_flags="-r" # Flags to mountd (if NFS server enabled). weak_mountd_authentication="NO" # Allow non-root mount requests to be served. nfs_reserved_port_only="NO" # Provide NFS only on secure port (or NO). nfs_bufpackets="DEFAULT" # bufspace (in packets) for client (or DEFAULT) rpc_lockd_enable="NO" # Run NFS rpc.lockd (*broken!*) if nfs_server. rpc_statd_enable="YES" # Run NFS rpc.statd if nfs_server (or NO). portmap_enable="YES" # Run the portmapper service (or NO).
RELEASE
によっては分からないので、
/etc/rc.conf
で明示的に
NO
として起動しないようにする必要がある。
なお、
/etc/defaults/rc.conf
は直接に編集しないこと。
このファイルの中の設定を変えるには
/etc/rc.conf
を作ってその中で設定を変える。
(だから、
/etc/defaults/rc.conf
を
/etc/rc.conf
にコピーして書き直せば良い。)
この他にも、
amd
とか
mountd
もチェックしておいた方が良い。
なお、
NIS や nfs を止めてしまったら
portmap
なんていうものは必要ない。
だからついでに止めてしまって構わない。
一般に動作しているサーバプログラムの確認には
ps
コマンドを使う。
このプログラムは
動作中のすべてのプログラムの情報を表示するので、
不審なプログラムが実行されていないかをチェックするのにも
使える。
通常は
ps -aux
で良いが、大抵の場合プログラム名が途中で切られたりする。
これは、特定のプログラムの動作を
grep
コマンドとともに調べる場合に致命的な間違いを起こすことが多いので、
プログラム名はきちんと表示させた方が理想的と言える。
なるべくプログラム名を切らないで表示させるようにするには
ps -auxw
とするといい。
比較すると次のようになる。
% ps -aux root 133 0.0 0.3 884 420 ?? Ss 11:07PM 0:06.99 moused -p /dev/ps bin 161 0.0 1.3 2028 1648 ?? I 11:07PM 0:02.78 /usr/local/sbin/c ageha 172 0.0 0.7 1380 880 v0 Is 11:07PM 0:00.10 -csh (csh) root 173 0.0 0.4 924 528 v1 Is+ 11:07PM 0:00.01 /usr/libexec/gett % ps -auxw root 133 0.0 0.3 884 420 ?? Ss 11:07PM 0:07.20 moused -p /dev/psm0 -t auto bin 161 0.0 1.3 2028 1648 ?? I 11:07PM 0:02.94 /usr/local/sbin/cannaserver ageha 172 0.0 0.7 1380 880 v0 Is 11:07PM 0:00.10 -csh (csh) root 173 0.0 0.4 924 528 v1 Is+ 11:07PM 0:00.01 /usr/libexec/getty Pc ttyv1
例えば、
cannaserver
の動作を見たくても
ps -aux | grep canna
としても何も引っかからない。
しかし、
ps -auxw | grep canna
とすれば引っかかって来る。
この違いは決定的なので、覚えておくと役に立つ。
ちなみに私の場合には
ps
コマンドの出力は次のようになっている。
なお、サーバなどの動作状況が問題になっているので、
一般ユーザ分の出力は省いてある。
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.2 528 204 ?? ILs 11:07PM 0:00.01 /sbin/init -- root 2 0.0 0.0 0 0 ?? DL 11:07PM 0:00.11 (pagedaemon) root 3 0.0 0.0 0 0 ?? DL 11:07PM 0:00.00 (vmdaemon) root 4 0.0 0.0 0 0 ?? DL 11:07PM 0:00.18 (bufdaemon) root 5 0.0 0.0 0 0 ?? DL 11:07PM 0:03.88 (syncer) root 79 0.0 0.4 916 548 ?? Is 11:07PM 0:00.16 syslogd -s root 103 0.0 0.5 1032 672 ?? Is 11:07PM 0:00.02 inetd -wW root 105 0.0 0.5 952 624 ?? Is 11:07PM 0:00.21 cron root 133 0.0 0.3 884 420 ?? Is 11:07PM 0:11.14 moused -p /dev/psm0 bin 161 0.0 1.3 2028 1648 ?? S 11:07PM 0:02.97 /usr/local/sbin/can root 173 0.0 0.4 924 528 v1 Is+ 11:07PM 0:00.01 /usr/libexec/getty root 174 0.0 0.4 924 528 v2 Is+ 11:07PM 0:00.01 /usr/libexec/getty root 175 0.0 0.4 924 528 v3 Is+ 11:07PM 0:00.01 /usr/libexec/getty root 176 0.0 0.4 924 528 v4 Is+ 11:07PM 0:00.01 /usr/libexec/getty root 190 0.0 18.1 27716 23168 ?? S 11:08PM 4:11.08 /usr/X11R6/bin/X :0 root 311 0.0 1.7 3028 2216 v0 S 12:35AM 0:09.52 kterm -geometry 80x root 886 0.0 1.7 2896 2152 v0 I 2:56AM 0:00.10 kterm -geometry 80x root 959 0.0 1.9 3028 2380 v0 I 4:03AM 0:00.41 kterm -geometry 80x root 1056 0.0 1.8 2932 2284 v0 I 5:19AM 0:00.17 kterm -geometry 80x root 0 0.0 0.0 0 0 ?? DLs 11:07PM 0:00.02 (swapper)
上で root が
kterm
を実行している部分があるが、
一般ユーザが
kterm
を実行すると上のように
root
で実行されたように表示されるので、
これらはサーバプロセスではないことに注意。
それから
X window
を使っている関係で、
/usr/X11R6/bin/X :0
なんていうのも見られる。
いずれにしてもこれらのプロセスは動いていても不審はない。
この他に、
上の表示では途中で切れている
(だから
ps -auxw
でチェックする方がいい)
が、
/usr/local/sbin/cannaserver
というのが動いている。
これは、かな漢字変換のためのサーバプログラムである。
はっきり言えば、
これは動いていない方が安全だ。
しかし、いくら安全だからと言って、
日本語の入力をあきらめようという人はいないはずだ。
だから、これは動かす。
安全を確保するとは言っても、
コンピュータが使いものにならなくなるのでは、
コンピュータの安全性を考えること自体が無意味になる。
同様に、
/usr/X11R6/bin/X
もサーバである。
これも動かさないですむのなら、動かさない方が絶対に安全だ。
しかし、個人が作業するのに使っているのに
ウィンドウシステムが使えないのなら、
ほとんど意味をなさない。
これも必要なので、動かすしかない。
かな漢字変換とウィンドウシステムを放棄するぐらいなら、
コンピュータの電源を切っていた方が安全だ。
だれも、安全のためにコンピュータの使用をあきらめようとは思わないだろう。
時々
ps
コマンドの出力を確認してみて
余計なプログラムが動作していたら止めることを
検討した方が良い。
なお、上で表示されているもののうち
/sbin/init
だとか
かっこで括ってあるような
(swapper)
などというのは止めてはいけない。
かっこで括ってあるのはカーネルプロセスと言うもので、
これがないとシステムが動作できない。
試して見たことはないので、何とも言えないが、
kill
出来るようなものなのかどうかは私は知らない。
/usr/libexec/getty
なんていうプロセスが 4 つ程動いているが、
これは仮想端末へのログインを待ち構えているプロセスだ。
Netscape なんかが X window を巻き添えにして
凍り付いた時でも別の仮想端末からログインして
X window
を
kill
して状況の収拾を図ると言ったことも可能なので、
4 つ程度は動かしていた方が無難だ。
それに、これはネットワーク越しのログインとは関係のない
プロセスなので、動かしていてもさほど問題はない。
moused
は syscon
でマウスを使うためのプロセスで、
なくても構わないが、通常 X window の設定の際に
楽が出来るので動かしていた方が便利だ。
cron
は時間指定でプロセスを動作させるための
daemon
である。
午前 2 時にセキュリティチェックなどが行われるが
これは
cron
を介して行われる。
だから、これは動かしておいて損はない。
逆にセキュリティチェックの自動化の際になくてはならないものなので、
とりあえず動かしておこう。
それから、
syslogd
なんかも必要なものだ。
基本的にはそれ以外のもので、
d
で終っているコマンドがサーバプログラムの仲間になる。
d
というのは
daemon
の略だろうと思う。
実質的にサーバプログラムだと思って構わない。
すると私の場合、本質的に動かしているサーバプログラムは
inetd
だけになる。
しかも、これはパソコンが何台かある関係で動かしているだけなので、
もしもパソコン一台という人なら動かす必要もない。
パソコン数台ある場合でも、
面倒臭いがその都度
inetd
を起動・停止すると言う方法だってある。
だから、
これがなくても、
web の閲覧も出来るし、ファイルのダウンロードも出来るし、
電子メールを出すことだって出来る。
以上を整理してみると
/sbin/initcronmousedgettysyslogdこれだけのプロセスだけがあれば Windows 95/98/2000 ユーザと同じことは支障なく行える。 つまり、 いわゆる 『クライアント用途』 には十分だと言うことだ。