※お知らせ
本稿のタイトルを「止められない基幹業務サーバの管理対策」としておりましたが、UNIXに特化した記事内容の範囲より「止められないUNIXサーバのセキュリティ対策」とタイトルの変更をさせていただきました。(2003/10/25、編集局)
「第3回 サービスをセキュアにするための利用制限」は業務サーバの利用制限によるセキュリティの向上として、稼働中のサービスに対するアクセス制限を紹介した。今回は、機密性と安定稼働が義務付けられている基幹業務サーバなどの運用において、注意すべき重要な事項の1つとして、すべてのコマンドが使用できてしまう管理者=特権ユーザー(スーパーユーザー)の利用制限について説明する。
UNIXサーバの運用管理を行うためには、運用管理を行うユーザーアカウントに管理者特権(スーパーユーザー権限)が付与されている必要がある。UNIXでは、スーパーユーザー権限を持つユーザーとして、UID 0のアカウント――多くの場合rootが該当する。
スーパーユーザー権限を得るためには、UNIXシステムにrootでログインするか、もしくは一般ユーザーでログインした後に、後述のsuやsudoを使ってrootの権限を得る方法がある。前者は、後述の「rootログインの危険性」で説明するとおり、セキュリティ上あまり好ましくない。そのため通常は、後者の方法を使ってスーパーユーザー権限を得ることをお勧めする。特に、ネットワーク経由でログインする場合は、前者のrootログインによる方法は避けた方がよいだろう。
ユーザーrootで直接UNIXシステムにログインした場合、少なくとも次に示す危険性が伴う。
●バックドアの作動
ログインと同時に、自動的にバックドアが起動するような仕掛けがされていた場合、管理者特権を持つが故に、システムファイルの削除など、影響範囲がシステム全体に及ぶ恐れがある*1。
●操作ミスによるシステム破壊
ログインと同時に入力するコマンドすべてが管理者特権で実行される。管理者特権で作業する時間が長ければ長いほど、操作ミスによるシステム破壊の可能性も高くなる。
rootログインは、セキュリティ上あまり好ましくないことを述べたが、rootログイン以外で管理者特権を得る方法としては、suやsudo(詳細は後述)といったコマンド(ツール)がよく知られている。
本稿では、suやsudoの使用を前提として、root権限を得る方法、さらにはsuやsudoの利用者を制限する方法について説明する。
一般ユーザーアカウントからsuやsudoを使ってroot権限を得る場合は、サーバへのrootログインの必要性はなくなる。デフォルトはrootログインを禁止にすることをお勧めする。
最近の各UNIXでは、telnetによるrootログインはデフォルトで禁止されているので設定の必要はないかもしれないが、念のため確認しておくこと。
例えばSolaris 2.xの場合は、/etc/default/loginのCONSOLEの値がコンソールからのみ root ログインが許可されていることを確認する。
CONSOLE=/dev/console
リモートメンテナンスにssh(OpenSSH)を使っている場合、sshd_config(例:/etc/ssh/sshd_config)のPermitRootLoginに「no」を設定するか、無効(先頭に#を付加)にすればよい。
PermitRootLogin no
ftpもtelnet同様、デフォルトでは無効になっていることが多い。OS標準のftpサーバの場合、/etc/ftpusersのrootの1行を確認する。/etc/ftpusersにrootのみ記述、またはroot denyとなっていればrootログインが禁止されていることが分かる。
root deny
ftpusersの記述は、各ftpサーバによって異なる場合があるので、「man 5 ftpusers」などで確認するとよい。
suコマンドは、一般ユーザーからrootへなど、現在のユーザーアカウントから別のユーザーアカウントに権限を切り替える(スイッチする)ためのコマンドだ。UNIXでは古くから利用されており、ほとんどのUNIX系OSに標準でインストールされている。
suコマンドで一般ユーザーからroot権限にスイッチしたい場合は、単にsuを実行すればよい。
% id uid=1003(kimu) gid=100(users) groups=100(users) % su Password: rootのパスワードを入力 # id uid=0(root) gid=0(wheel) groups=0(wheel),2(kmem),3(sys),4(tty),5(operator),20(staff),31(guest)
rootにスイッチしたことはidコマンドで確認できる。
また、rootではなく、別のあるユーザー(仮にyasu)にスイッチしたい場合は、suの後にスイッチ後のユーザー名を指定する。
% su yasu Password:yasuのパスワードを入力
さらには、-cオプションで特定コマンドのみを実行させることも可能だ。例えば、lessコマンドを使って、/var/log/secureファイルの内容をroot権限で読む場合は以下のとおりとなる。
% su root -c "less /var/log/secure"
suコマンドでrootにスイッチできるユーザーを制限する。suコマンドはシステム内部からのみ実行可能であるため、一見すると前回のようなアクセス制限は必要ないように思える。しかし、例えば対象となるサーバが100?1000以上のログインシェルを持つユーザーを抱えていた場合はどうなるだろうか。基幹業務サーバともなれば、それぐらいの規模は珍しくないだろう。そして、そういった大勢の一般ユーザーの中には、悪意はないにしろ、rootのパスワードが容易なものに設定されていないかどうかを試すありがた迷惑なユーザーや、ある一般ユーザーを乗っ取り、そこからさらにsuコマンドでroot権限を奪おうとする攻撃者が中にはいるかもしれない。
前置きが長くなってしまったが、そういったケースを想定し、suコマンドでrootになれるユーザーを限定してしまった方が、セキュリティをより向上させることにつながる。
それでは、各UNIX上でsu rootを制限する方法について説明しよう。
●*BSDの場合
BSD系UNIXの多くは、デフォルトでsu rootの利用がグループID(GID)が 0(通常はwheel)に属するユーザーにのみ許可されている。wheelグループに属していないユーザーがsu rootを実行すると、ターミナル上に次のような拒否メッセージが表示される。
% susu: you are not listed in the correct secondary group (wheel) to su root.
特定ユーザーにsu rootを許可したい場合は、wheelグループに追加するだけでよい。wheelグループに追加する場合は、viで/etc/groupを編集するのが簡単だ。
例:wheelグループにユーザーkimuを追加する
# vi /etc/group
保存した後、ユーザーkimuよりsuコマンドを実行して、rootになれるかどうかを確認する。正常に追加されている場合は、先の拒否メッセージが表示されずに、su rootコマンドを実行できる。
●Linux(Red Hat Linux 7.3)の場合
Red Hat Linux 7.3のsuコマンドには、*BSDのようなsu rootを制限する機能は備わっていない。そのためLinuxでsu rootを制限するためには、PAM(Pluggable Authentication Module)を用いることになる。PAMは、既存のコマンドやサービスを変更することなく、新たな認証のプラグインを実現する機能で、多くのUNIXで採用されている。PAMは各認証機能をモジュールとして提供しており、今回のsu rootの制限もpam_wheel.soというモジュールを利用する。
まずはpam_wheel.soが存在するかどうかを確認する。ほとんどの場合がRPMとして標準インストールされているはずだ(rpm -qa | grep pamで確認) 。
% ls -l /lib/security/pam_wheel.so -rwxr-xr-x 1 root root 9566 Apr 10 2002 /lib/security/pam_wheel.so
インストール済みの場合は、続いてsuコマンドのPAMの設定(/etc/pam.d/su)を変更する。/etc/pam.d/suにpam_wheel.soの設定を追加する。
#%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth …… 省略 ……
#%PAM-1.0 auth sufficient /lib/security/pam_rootok.so auth required /lib/security/pam_wheel.so group=wheel auth required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth …… 省略 ……
最後に/etc/login.defsに以下の1行を追加する。
SU_WHEEL_ONLY yes
/etc/login.defsの内容は、ユーザーが次にログインした時点で有効となる。確認する場合は、設定により万が一ログインが不能になることを考え、作業中のターミナルとは別のターミナルから行うこと。
許可されていないユーザーがsu rootを実行すると、以下のとおり拒否される。
% su Password: su: incorrect password
●Solaris 8の場合
Linux同様、Solarisの場合もPAMが採用されているので、pam_wheel.soモジュールを利用すればよいのだが、以前提供されていたSolaris用のpam_wheel.soはすでにメンテナンスされていないため、何かあった場合の対処ができない。そのためSolarisでsu rootの制限を行う場合の最良策はいまのところないといってよいだろう*2。
それでもsu rootの制限を行いたい場合は、先に述べたpam_wheel.soモジュールを使う方法と、次のsuコマンドの実行権限を制限する方法がある。
●suコマンドの実行権限を制限
suコマンドの実行できるユーザーを、所有者およびグループに属するユー ザーのみに制限する。
# cp -p /usr/bin/su /usr/bin/su.bak # chgrp wheel /usr/bin/su # chmod 4750 /usr/bin/su
この時点で、suコマンドはrootとwheelグループに属するユーザーのみが利用可能となる。もちろんのことだが、wheelグループには、suコマンドを実行させたいユーザーを追加しておく必要がある。
最後にバックアップ用にコピーしたsu.bakを削除しておく。
# rm /usr/bin/su.bak
しかし、この方法はオリジナルファイルに手を加えることになり、かつ許可されていないユーザーはsuコマンドをまったく使えなくなってしまうという副作用がある。
●PAM(pam_wheel.so)による制限
もう1つの手法は、PAM(pam_wheel.so)を使う方法だ。ただし、これは先ほど述べたとおり、現在メンテナンスされていない状態のため、何か問題があった場合には自分で対処しなければならなくなる。
使用する場合は、pam_wheel-1.3.tar.gz(MD5)を展開し、ソースをコンパイルしてインストールする必要がある。
% gunzip -cd pam_wheel-1.3.tar.gz | tar xvf - % cd pam_wheel-1.3 % make # install-wheel.sh
install-wheel.shを実行すると、pam_wheelのオンラインマニュアルやライブラリが/usr/local/man/man5に、ライブラリモジュールのpam_wheel.so.1が/usr/lib/securityにコピーされる。さらに、GID 0のwheelグループの追加と/etc/pam.confファイルに以下の設定の追加も行われる。
su auth requisite /usr/lib/security/pam_wheel.so.1 debug su auth required /usr/lib/security/pam_UNIX.so.1 debug su account required /usr/lib/security/pam_UNIX.so.1 su session required /usr/lib/security/pam_UNIX.so.1
install-wheel.shの実行が終了したら、あとはsu rootを許可していないユーザー(wheelグループに属さないユーザー)から、suコマンドを実行して確認してみる。
% su su: Sorry
“su: Sorry”の1行が出力されれば、適切に制限されているということが分かる。
次回は、suのセキュリティ上の問題点やsudoの基本的な使い方について紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.