- 1. root のパスワードが適切か
- root のパスワードはちゃんと付いていますか。
OSをインストールすると途中で聞いてくるので、一応付けている
とは思いますが念のため。
# passwd
WSの納入業者がパスワードを付けているかもしれませんが、
そのまま使い続けるのは絶対にやめましょう。 パスワードに
規則性があったりすれば、あっさりと予測されて狙われる
ことになります。(初期パスワードだからって、案外簡単な
ものを付けていく業者は多いものです。)
root のパスワードが root だったり、ホスト名や研究室名という
のは論外です。 数字だけのパスワードや、辞書に載っている単語、
または単語を少しだけ変えたものはあっさり破られるので、
使ってはいけません。 英字の小文字大文字を使い、数字と記号を
混在させるようにしましょう。
- 2. 業者やゲストのアカウントが登録されていないか
- 幸い、Solarisでは初期の状態でゲストアカウントは存在しません。
念のため、/etc/shadow の中でコロン(:)で区切られた2番目の
フィールドが空になっているものがないかどうか確認しましょう。
rootの行には root のパスワードを暗号化したものが、その他に
は NP とか *LK* とか書いてあるはずです。
業者がWSの設定の際に一時的にアカウントを作成している場合が
あります。もし業者にリモートでその計算機を管理してもらう
必要がなければ、業者のアカウントは削除するか、ロックして
ログインできないようにしましょう。 rootで共通デスクトップ環境(CDE)
でログインして、コマンドプロンプトを出して、
# admintool &
とすれば、アカウントの作成、削除、ロックなどが簡単にできます。
業者にリモートで計算機を管理してもらう場合、
Secure Shell (SSH)
などを使った暗号通信でログインしてもらうように強く依頼
しましょう。
万一ネットワークが盗聴された場合でも、root や業者のパスワード、
作業内容が
漏洩しにくくなります。
- 3. rootのリモートログインの禁止
- 万一rootのパスワードが漏洩しても、リモートでログインできな
ければシェルを奪うのが難しくなります。 rootのリモートログインを
禁止しておけば、一般ユーザのパスワードも一つ手に入れなければ、
リモートログインができません。
幸い、Solaris2.x 以降では初期の状態で root のログインがコンソール
に限定されています。 telnet や rlogin ではログインできません。
しかし、業者が一時的に、あるいは管理のために root の
リモートログインをできるように設定していることがあります。
余計なお世話です!!
/etc/default/login というファイルの中に、
# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
CONSOLE=/dev/console
という行があります。 もし CONSOLE=... の前に # が付いていたら
外しましょう。 この行がない場合は、追加しましょう。
他の計算機から telnet で root ではログインできないことを
確認しておきましょう。滅多にないとは思いますが、この時に
パスワードが盗聴されているかも
しれないので、試した後はコンソールでパスワードを変更して
おくと良いです。
- 4. passwd, shadow の各ファイルのオーナとパーミッションを確認
- 導入作業中やWS運用中に /etc/passwd と /etc/shadow のオーナ
やパーミッションをうっかり変更していないかどうか、時々
確認しましょう。 導入直後の確認は必須です。
正しいオーナ、グループ、パーミッションは以下のとおりです。
# ls -l /etc/passwd /etc/shadow
-rw-r--r-- 1 root sys 459 Apr 2 09:53 /etc/passwd
-r-------- 1 root sys 265 Apr 2 09:54 /etc/shadow
(ファイルサイズはサイトによって異なります)
shadow ファイルには暗号化されたパスワードが書かれています。
暗号化されているとは言え、最近の高速な計算機では、そこそこの
時間をかければ元のパスワードに戻すことができます。
もし shadow が一般ユーザから読み取り可能であれば、一般ユーザが
root のパスワードを盗める可能性が高くなります。 Webサーバを
動かしていて、CGIにセキュリティホールがあれば、外部の者に
パスワードを盗まれることもあります。 もしパーミッションが違って
いたら必ず直しておきましょう。
# chown root:sys /etc/passwd /etc/shadow
# chmod 644 /etc/passwd
# chmod 400 /etc/shadow
- 5. passwd ファイルにパスワードが入っていないか
- /etc/passwd は一般ユーザが誰でも覗けるファイルです。
いくら暗号化されていても、このファイルにパスワードが格納
されているのは好ましくありません。
例えば他のOSからアカウントの情報をコピーしたい時など、
/etc/passwd にパスワード入りの行をそのまま付け足すかも
しれません。 このような場合は、パスワードの部分を /etc/shadow
に移して、一般ユーザから読めないようにしておく必要があります。
/etc/passwd の中のパスワードを /etc/shadow にコピーして
両ファイルの整合をとるには、
# pwconv
を実行します。
- 6. NISに root が入っていないことを確認
- NISを使用してユーザ情報を管理している(passwdのデータを共有している)
場合は、NISの passwd マップに root が登録されていないことを
確認します。 NISでは一般ユーザが暗号化されたパスワードを
取得でき、root のパスワードが漏れる危険性があります。
# ypcat passwd
として、root のエントリがないことを確認します。
念のため、
コロン(:)で区切られた3番目のフィールドが0のエントリがないことも
確認しておきます。
- 7. passwdファイルやNISに ftp が入っていないことを確認
- Solarisでは、初期の状態で ftp というアカウントは存在しません。
もし ftp というアカウントが存在すると、そのWSは
Anonymous FTP(匿名FTP)サーバとして機能します。
詳しくは man in.tftpd を見てください。
/etc/passwd に ftp というアカウントが登録されていないかどうか
を確認します。 また、NISのpasswdマップも調べます。
# grep ftp /etc/passwd
# ypcat passwd | grep ftp
もし ftp が存在する時は、そのエントリを削除します。
Anonymous FTPサーバは悪用の対象になりやすく、設定の
不備によって致命的なセキュリティホールが生じやすい
ものです。 違法なファイルなどを配布するために、
ゲストが誰でもファイルを書き込めるような
FTPサーバを探し廻っている悪い連中がいます。
Anonymous FTPサーバは安易に立ち上げないようにしましょう。
- 8. パッチを当てておく
- WSに新規にOSをインストールしたり、プリインストールのWSを
導入したら、あれこれと設定をする前に最新のパッチを当ててお
きましょう。 設定をやってからでは、せっかく変更したファイルが
初期化されてしまったり、入れ換えたコマンドが上書きされたりする
ので、当てるべきパッチを選択するのが大変になります。
(ありがちなのが sendmail や sendmail.cf を上書きされて
泣くこと; 汗)
最新のPublicパッチは SunSolve などで入手できます。
Recommended and Security Solaris Patch Clusters をダウンロードして
一括して当てておきましょう。 やむを得ずSolaris2.6以前を使う場合は
パッチの量は覚悟するように :)
なお、設定後も時々セキュリティパッチをチェックしておき、
必要な物を選別して当てるようにしましょう。
- 9. MTA(sendmail) を止める
- 普通は、研究室や講座でメールサーバを置き、そこで一括して
メールを受け取るようにしていると思います。 その方が監視の
目が行き届いて安全でしょう。
クライアントのWSは、自分自身でメールを受け取る必要はない
はずです。 メールを受け取らないWSでは、MTA(Mail Transport Agent)
を常時動かしておく必要はありません。 Solaris ではMTA
として sendmail が標準的に使われます。
Solaris2.6以前では、OSに付属の sendmail をそのまま使うと、
第三者間*のリレーが許可されてしまうようです。
このような sendmail が常時WSで動いていると、悪質なダイレクト
メール業者が大量のメールを配送するのに利用したり、
個人でもSPAMをばらまくのに悪用したりします。
学内のネットワークや計算機に負荷はかかるし、苦情の鉾先は
研究室や大学を向くし、非常に困ったことになります。
リレーが禁止されているsendmailでも、将来新たな悪用の手口が
見つからないとも限りません。
真っ先にsendmail は止めておきましょう。
現在動いている sendmail は、次のようにして止めます。
# /etc/rc2.d/S88sendmail stop
このままではリブートした時にまたsendmailが動いてしまうので、
起動用のスクリプトをリネームしておきます。(例えば
_S88sendmail に)
# mv /etc/rc2.d/S88sendmail /etc/rc2.d/_S88sendmail
/usr/lib/sendmail をリネームすると、そのWSから mail コマンド
でメールが出せなくなります。 /usr/lib/sendmail はそのままに
しておきます。
設定をしたクライアントのWSでは、/etc/hosts にメールサーバ
を登録しておきます。 Solarisでは、mailhost というホスト名の
計算機が登録されていれば、メールの送信の時に無条件にその
計算機にメールの配送を依頼するようになります。 例えばメールサーバ
が mserv というホスト名で、192.168.1.1 というIPアドレス
を持っていれば、/etc/hosts に
192.168.1.1 mserv mailhost
と書いておけば良いです。 メールサーバ(mserv)の方では、
クライアントのWSからのリレーを許可し、そのWSのホスト名
を指定して送られてきたメールを代りにメールサーバで
受け取れるように設定しておきます。(DNSのMXレコードをいじる
必要あり)
メールサーバの管理者に設定を依頼しましょう。
第三者間*のメールのリレーを
容認するような研究室は、ネットワーク犯罪を助長している
と言われても仕方ありません。
* ここで言う第三者とは学校や学部、講座、研究室
などと無関係な人を指します。 例えば研究室発や研究室内
向けのメールのリレーは必要です。
- 10. ログを集約する
- WSの不正使用やアタックを早急に見つけるためにも、種々の
ログを日々チェックすることは重要です。様々なログが
個々のWSに分散しているよりも一括していた方が
チェック作業がやりやすく、また、万一クライアントのWS
に不正に侵入された場合でも、侵入者が足跡を消すのが
困難になります。(ログを収集しているWSに入られたら終り
ですが)
Solaris では、loghost というホスト名が登録されていると、
syslog で収集されるログを loghost に集約できます。
ログを収集している計算機が log-1 というホスト名で、
192.168.1.2 というIPアドレスを持っている場合は、/etc/hosts
に
192.168.1.2 log-1 loghost
のように記述します。log-1 の /var/log (Solaris以外では
/var/adm など) の下のファイル
に、クライアントのWSのログが書き込まれることを確認
しておきましょう。
- 11. /etc/hosts.equiv や /.rhosts は大丈夫か
- 幸いなことに、Solaris2 では初期の状態でこれらのファイルは
存在しません。 もし存在するようならば、変な設定をしていない
か、十分に気をつけましょう。
Solaris2以外のとあるOSでは、/etc/hosts.equiv に + だけの
エントリが含まれていることがあります。 これは危険なので
必ず外すこと。
/etc/hosts.equiv でホストの部分に + が指定されていると、
ユーザ名さえ一致すればどの計算機からも rlogin や rsh で
侵入されてしまいます!!
できれば /etc/hosts.equiv と /.rhosts は使わない (削除する)
ようにしましょう。 どうしても必要な場合は、最低限のホストと
ユーザのみを登録すること。 よくわからない時は + は使わないように。
これらのファイルのオーナが root であること、そして、group や other
に対して書き込み不可になっていることも確認します。(特にSolaris7)