本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
※お知らせ
本稿のタイトルを「止められない基幹業務サーバの管理対策」としておりましたが、UNIXに特化した記事内容の範囲より「止められないUNIXサーバのセキュリティ対策」とタイトルの変更をさせていただきました。（2003/10/25、編集局）
「第3回 サービスをセキュアにするための利用制限」は業務サーバの利用制限によるセキュリティの向上として、稼働中のサービスに対するアクセス制限を紹介した。今回は、機密性と安定稼働が義務付けられている基幹業務サーバなどの運用において、注意すべき重要な事項の1つとして、すべてのコマンドが使用できてしまう管理者＝特権ユーザー（スーパーユーザー）の利用制限について説明する。
特権ユーザー（スーパーユーザー）とは
UNIXサーバの運用管理を行うためには、運用管理を行うユーザーアカウントに管理者特権（スーパーユーザー権限）が付与されている必要がある。UNIXでは、スーパーユーザー権限を持つユーザーとして、UID 0のアカウント――多くの場合rootが該当する。
スーパーユーザー権限を得るためには、UNIXシステムにrootでログインするか、もしくは一般ユーザーでログインした後に、後述のsuやsudoを使ってrootの権限を得る方法がある。前者は、後述の「rootログインの危険性」で説明するとおり、セキュリティ上あまり好ましくない。そのため通常は、後者の方法を使ってスーパーユーザー権限を得ることをお勧めする。特に、ネットワーク経由でログインする場合は、前者のrootログインによる方法は避けた方がよいだろう。
rootログインの危険性
ユーザーrootで直接UNIXシステムにログインした場合、少なくとも次に示す危険性が伴う。
●バックドアの作動
ログインと同時に、自動的にバックドアが起動するような仕掛けがされていた場合、管理者特権を持つが故に、システムファイルの削除など、影響範囲がシステム全体に及ぶ恐れがある＊1。
suコマンドの場合も「su -」など、使い方を間違えると、同じような被害に遭う可能性があるので注意が必要だ。
●操作ミスによるシステム破壊
ログインと同時に入力するコマンドすべてが管理者特権で実行される。管理者特権で作業する時間が長ければ長いほど、操作ミスによるシステム破壊の可能性も高くなる。
suとsudoを使う
rootログインは、セキュリティ上あまり好ましくないことを述べたが、rootログイン以外で管理者特権を得る方法としては、suやsudo（詳細は後述）といったコマンド（ツール）がよく知られている。
本稿では、suやsudoの使用を前提として、root権限を得る方法、さらにはsuやsudoの利用者を制限する方法について説明する。
rootログインの禁止
一般ユーザーアカウントからsuやsudoを使ってroot権限を得る場合は、サーバへのrootログインの必要性はなくなる。デフォルトはrootログインを禁止にすることをお勧めする。
telnetを使用している場合
最近の各UNIXでは、telnetによるrootログインはデフォルトで禁止されているので設定の必要はないかもしれないが、念のため確認しておくこと。
例えばSolaris 2.xの場合は、/etc/default/loginのCONSOLEの値がコンソールからのみ root ログインが許可されていることを確認する。
CONSOLE=/dev/console
sshの場合
リモートメンテナンスにssh（OpenSSH）を使っている場合、sshd_config（例：/etc/ssh/sshd_config）のPermitRootLoginに「no」を設定するか、無効（先頭に#を付加）にすればよい。
PermitRootLogin no
ftpの場合
ftpもtelnet同様、デフォルトでは無効になっていることが多い。OS標準のftpサーバの場合、/etc/ftpusersのrootの1行を確認する。/etc/ftpusersにrootのみ記述、またはroot denyとなっていればrootログインが禁止されていることが分かる。
root deny
ftpusersの記述は、各ftpサーバによって異なる場合があるので、「man 5 ftpusers」などで確認するとよい。
suコマンドの使い方と利用制限
suコマンドとは
suコマンドは、一般ユーザーからrootへなど、現在のユーザーアカウントから別のユーザーアカウントに権限を切り替える（スイッチする）ためのコマンドだ。UNIXでは古くから利用されており、ほとんどのUNIX系OSに標準でインストールされている。
suコマンドの使い方
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の利用制限
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
- 変更前：wheel:*:0:root
- 変更後：wheel:*:0:root,kimu
保存した後、ユーザー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。
PAM は API などが公開されているので、自分で作るという手段もあるが、ここでは対象外とする。
それでも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の基本的な使い方について紹介する。
- Tripwireのポリシーを最適化する
- Tripwireでファイルの改ざんを検出せよ〜Tripwireのインストールと初期設定 〜
- 安全性の高いログ・サーバへの乗り換えのススメ（2）〜 ログ管理のセキュリティ強化を実現する方法を知ろう 〜
- 安全性の高いログ・サーバへの乗り換えのススメ（1）〜 syslogサーバからsyslog-ngへの乗り換え 〜
- syslogによるログの一元管理
- UNIXサーバの運用管理で欠かせないログ管理
- 特権ユーザーの安全性向上を行うsudoの設定例
- サービスをセキュアにするための利用制限（3）〜管理者権限の制限のためのsuとsudoの基本〜
- サービスをセキュアにするための利用制限（2）〜管理者特権の利用制限〜
- サービスをセキュアにするための利用制限〜TCP Wrapperによるサービスのアクセス制限〜
- ソフトウェアの現状確認とアップグレード
- 不要なサービスの停止こそ管理の第一歩
Copyright © ITmedia, Inc. All Rights Reserved.