(*) 上記はLinuxマシンからSolaris 9マシンに接続を行っている。 初回時のみ「The authenticity ... 」という警告が現れるが、「yes」を選択することで、後はrloginとほぼ同様にパスワードを入力することでログインが可能である。
Solaris 9のセキュリティ強化点については、「Solaris[tm] 9 オペレーティング環境のセキュリティ」に一覧がある。実際のところ、このうち幾つかのものは、Solaris 8へのバックポートという形で、Solaris 8の途中のリリースから実装されている。またSolaris 9の途中のリリースから強化された点もある。詳細は「Solaris 各バージョン比較表)」やそこからたどれる「アップデート比較表」などを確認してほしい。 管理面からみたSolaris 9のセキュリティ機能の主なものを、筆者の判断による有用性とともに表xx1に示した。 以下、これらについて順に紹介していく。なお以下の説明ではSunのドキュメントサイトにある「Solarisシステム管理(セキュリティサービス)」をマニュアルと称する。
| ネットワークのセキュリティ | システムのセキュリティ | セキュリティ運用 | ||||||
|---|---|---|---|---|---|---|---|---|
| ssh(Secure Shell)のサポート | ◎ | RBAC | △ | Solaris Patch マネージャ / PatchPro | ◎ | |||
| inetdのTCP_Wrapper機能 | ○ | ACL | △ | ASET | ○ | |||
| その他 | その他 | その他 | ||||||
| IPsec/IKEの実装 | △ | 乱数発生デバイス | △ | logadmコマンド | ◎ | |||
| SEAM | △ | 拡張ファイル属性 | △ | 柔軟なインストール | ○ | |||
| SunScreen 3.2 | △ | |||||||
sshは、TELNETやrlogin/rshと同様に遠隔のホストへのログインを可能とするプロトコルである。ただし、パスワードが平文でネットワーク上を流れるTELNETや認証機構が脆弱なrlogin/rshと異なり、強力な通信の暗号化機能が実装されている他、認証についても従来のパスワード認証の他に、RSA公開鍵を使った強固な認証が実現されている。 Solaris 9のsshは一応Sun独自のものになっているが、オープンソースなsshの実装としてはデファクトスタンダードといえるOpenSSHベースのものとなっており、設定方法などもOpenSSHと同等である。
とりあえず接続するだけであれば、図xx2のようにすればよい。Solaris 9同士、LinuxやFreeBSDなどのOpenSSHベースのマシンとであれば、問題なく接続できる筈である。 もちろんrshコマンドと同様にしてリモートマシン上でコマンドを実行することも可能である。またrcpコマンドに相当するscpコマンドを利用することで、リモートホストとの間でファイルコピーを行うことも可能である。
この状態でも伝送路上は暗号化されているため、万一盗聴されても通信内容を読みとることはできない。ただし、パスワード認証を用いているため、いわゆる総当たり攻撃に対する脆弱性はTELNETなどと変わらない。
RSA認証を利用することで、総当たり攻撃に対処するとともに、公開鍵を登録していないホストからの接続を拒否することが可能であるため、インターネット環境では是非とも導入したい。 導入には図xx3のようにユーザごとにssh-keygenコマンドを実行して公開鍵と秘密鍵の対を作成する必要がある。
> ssh-keygen Enter file in which to save the key(/home/local/.ssh/id_rsa): Generating public/private rsa key pair. Enter passphrase(empty for no passphrase): ← パスフレーズを入力 Enter same passphrase again: ← もう一度パスフレーズを入力 Your identification has been saved in /home/local/.ssh/id_rsa. ← 秘密鍵ファイル Your public key has been saved in /home/local/.ssh/id_rsa.pub. ← 公開鍵ファイル The key fingerprint is: md5 1024 d8:af:35:3f:4d:26:80:d8:ed:03:3e:b2:85:2d:2c:63 local@marine >
パスフレーズの長さはできれば30文字程度はあった方がよい。 最後に公開鍵ファイルの内容を、リモートホストの~/.ssh/authorized_keysファイルに追加する。このファイルには接続を許可するすべてのホストの公開鍵が格納される。これで図xx4のようにパスワードの代わりにパスフレーズの入力を求められるようになる。
[megu:/home/monyo/.ssh]ssh 192.168.230.29 Enter passphrase for key '/home/monyo/.ssh/id_dsa': ← パスフレーズの入力 Last login: Sat May 31 11:58:22 2003 from 192.168.230.28 Sun Microsystems Inc. SunOS 5.9 Generic_112234-03 November 2002(*) クライアントの環境によってはRSA認証を行わせるためにオプションの設定が必要な場合もある。
RSA認証が利用可能になったら、パスワード認証は無効にした方がよいであろう。設定する際には/etc/ssh/sshd_configでPasswordAuthenticationオプションをnoに設定する。
パスフレーズを非常に長いものとした場合、セキュリティは向上するが、毎回入力するのはかなり繁雑な作業となる。この作業を自動化するのがssh-agentである。
> eval `ssh-agent` Agent pid 667 > ssh-add Enter passphrase for /home/monyo/.ssh/id_dsa: ← パスフレーズの入力 Identity added: /home/monyo/.ssh/id_dsa (/home/monyo/.ssh/id_dsa) > ssh 192.168.230.29 ← パスフレーズの入力を求められない Last login: Sat May 31 12:09:36 2003 from 192.168.230.28 Sun Microsystems Inc. SunOS 5.9 Generic_112234-03 November 2002 %
図xx5のようにしてevalコマンドを用いてssh-agentを起動する。ついでssh-addコマンドを用いて予めパスフレーズを入力しておく。これにより実際にsshやscpなどのコマンドを発行する際に毎回パスフレーズを入力する必要がなくなる。 なお、実はssh-agentコマンドは図xx6のような環境変数の出力を行っている。
> ssh-agent setenv SSH_AUTH_SOCK /tmp/ssh-lupab903/agent.903; setenv SSH_AGENT_PID 904; echo Agent pid 904;
この環境変数の設定をファイルにリダイレクトして複数端末間で共有するようにすれば、端末毎にssh-agentコマンドを起動する必要はなくなる。
Windows環境からsshを利用する際に一般的なのは、著名な端末ソフトウェアであるTeraTerm Pro 2.3にttsshを組み合わせる方式であろう。これらのソフトウェアは窓の杜など著名なWindows向けのフリーソフトウェアサイトから入手できる。ところがSolaris 9のデフォルト設定のままでは、この組み合わせから接続できない。実は、sshのプロトコルには大きくバージョン1(v1)とバージョン2(v2)とがあるが、Solaris 9のデフォルトではv2のみが有効となっているためである。ttsshではv1しか利用できない。v1も有効にするには、/etc/ssh/sshd_configで図xx7のように設定を変更した上で、図xx8のようにssh-keygenコマンドを用いてv1用のホスト鍵を作成する必要がある。
# Only v2 (recommended) #Protocol 2 ← コメントにする # Both v1 and v2 (not recommended) Protocol 2,1 ← コメントを外す (中略) HostKey /etc/ssh/ssh_host_rsa_key-v1 ←キーファイル名 ↑この行を追加
# ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key-v1 -N '' ← キーファイル名は図xx7と合わせる Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_rsa_key-v1. Your public key has been saved in /etc/ssh/ssh_host_rsa_key-v1.pub. The key fingerprint is: md5 1024 04:3a:e2:65:ad:70:20:c3:84:ff:71:17:67:62:b9:c9 root@marine
これで/etc/init.d/sshd/restartコマンドでsshdを再起動することで設定が反映される。 無論v1を有効にするのはセキュリティ上推奨できる設定ではない。特にインターネットサーバなどであれば、v2が利用可能な英語クライアント(注xx9)で接続するか、一度社内のLinuxマシンなどにログインした後で、そこからv2で接続するといった対応を行うことを推奨する。
この他にもsshには機能はポートフォワードやsftpなど多くの機能がある。詳細はマニュアルの「Secure Shell の使用」や「Secure Shellの管理」といった箇所を参照してほしい。 TELNETやrshで実現している遠隔マシンへのログインやコマンド実行などは、基本的にすべてsshで代替できる筈である。標準でsshが実装された以上、セキュリティ的に脆弱なTELNETを使う必然性はなく、TELNETしかサポートしていない機器への接続などやむを得ない場合を除き、積極的にsshの活用、置換えを進めていくべきであろう。
TCP_Wrappersはinetdと組み合わせて利用することで、inetd経由で起動するプログラムにホストベースのアクセス制御機能などを付加する定番のソフトウェアである。 Solaris 9では、従来と同様に/etc/inetd.confに設定を行うことでTCP_Wrappersを利用することも可能であるが、/etc/default/inetdで図xx10のような設定を行い、in.inetdを再起動することで、inetd.confで設定を行わなくてもこの機能が有効になる。
有効な場合は、/etc/hosts.allowや/etc/hosts.denyに記述を行うことで、アクセス制御が可能になる。通常はhosts.denyで図xx11のようにすべてのサービスを拒否する設定を行った上で、図xx11.5のように必要なサービス毎にhosts.allowで必要なアクセスを許可する設定を行えばよいだろう。詳細は、inetd(1M)やhosts_options(5)などのマニュアルページを参照してほしい。
in.telnetd: 192.168.1.0/255.255.255.0 ↑ in.telnetd(TELNETサービス)について、192.168.1.0/24からのアクセスのみを許可
フリーソフトウェアのTCP_Wrappersのインストールが不要になるため、フリーソフトウェアの利用がポリシー上行えなかったような環境では有用なこともあるだろう。しかし、近年ではinetd(もしくは同等の機能)を利用するサーバサービスは減少傾向にある。TELNETやFTPなどを前述したsshで置き換えてしまうと、inetd自体の利用が不要な場合も少なくない。
Solaris 9では、IKEが実装されたことで、ようやくIPSecとして必要な実装が行われた、筈である。しかし筆者の周辺で(注xx12)確認した限り、SolarisのIPSecの実装は癖があるようでWindows 2000やWindows XPなどとの相互接続がどうやっても行えなかった。 今後企業内でのIPSecの需要は増えると思われるが、以上のような理由により、今回は説明対象から外さざるを得なかった。
なおIPSecに関する詳細は、ipsec(7P)や「Solaris のシステム管理(IPサービス)」などを参照してほしい。
SEAMはいわゆるKerberos V5の実装であり、MIT Kerberos5と設定ファイルなどに互換性がある。Solaris 8まではクライアントのみの実装であり、サーバは別プロダクトやアドオンであったが、Solaris 9からはサーバ部分もOSに同梱されている。 ただ、現在のエンタープライズでの認証のトレンドはLDAPであり、Kerberos認証を明示的に利用するケースは稀であろう(筆者は一度も見たことがない。Active DirectoryはKerberos認証を利用しているが、Kerberos部分は隠蔽されており、ユーザが意識することは通常ない)。 このため、せっかくの機能であるが利用場面がないと判断し、今回の説明から省いた。詳細についてはマニュアルのSEAMに関する章を参照してほしい。
SunScreen 3.2は、いわゆるファイアウォール製品である。Solaris 8ではコネクション数などの機能が制限されたSunScreen Lite 3.1が添付されていたが、Solaris 9からはフル機能版が付属している。 ただし、エンタープライズにおいては、Solarisマシンをファイアウォールとして利用することは稀であり、通常は別途ファイアウォールを導入するか、専用の製品を導入するのが一般的である。また、本製品はOSの一部ではなくバンドル製品の扱いであることに加え、本格的なファイアウォール製品であり、本記事の範疇から逸脱すると思われるため、今回は説明を見送った。
まずは、従来からの機能であるが、あまり使われていないSolarisの独自機能がいくつか存在するので紹介したい。
デフォルトではコンソール以外からのrootログインは禁止されている。これはセキュリティ上変更しないことが望ましいが、どうしてもrootログオンを許可する必要がある場合は、/etc/default/loginの以下に示す行をコメントにする。
Solarisではuseraddもしくはusermodコマンドで図xx13のように-eオプションを指定することで、各アカウントに有効期限を設定することが可能である。
その他、パスワード変更までに最低限経過が必要な日数やパスワードが有効な最長期限などを設定することも可能である。詳細はshadow(4)やusermod(1M)などのマニュアルページを参照してほしい。
高いセキュリティが求められる環境では、システムの日常管理を行なうユーザについても、必要な権限以外は与えないという運用が求められることも多いであろう。しかし、伝統的なUNIXのすべての権利をもつroot(uid=0)とそれ以外のユーザという仕組みでは、特定のユーザに限定的な権限を与えることはできない。 これに対して、Solaris 8 01/01 以降では、ロール(役割)という概念が追加され、従来rootユーザで行なわざるを得なかった管理作業の一部を特定のユーザに委任することが可能となっている。sudoというフリーソフトウェアを知っていれば、その機能を包含する機能だと考えると理解の助けになろう。
RBACは柔軟性が高い反面、複雑である。 概念図を図xx14に示すので理解の助けにしてほしい。RBACを理解するにはロール(役割)と権利プロファイルの概念や承認などの意味とそれらの関係を理解することが必須である。
権利プロファイルにはPrinter Managementのような個別の管理タスクを示す名称が付与されている。 各権利プロファイルには、例えばlpdをユーザlpで実行することができるといった「コマンド」を割り当てることができる。この指定は/etc/security/exec_attrファイルで行う。この機構により、例えばPrinter Management権利プロファイルを持っているユーザは、rootアカウントでなくても、プリンタ関連のコマンドを特定のユーザ権限(多くはroot)で実行するといったことが可能になる。 更に、「承認」という情報を割り当てることも可能である。こちらはアプリケーション側で明示的にユーザが特定の「承認」を持っている場合に限り、特定の処理を可能とするようなコードを記述する(注xx15)ことで意味を持つ情報であり、一部のSolarisコマンドが承認に対応している。
ロールは、権利プロファイルの上位の概念であり、ユーザが実際に特定の管理タスクを行う際に必要な権利プロファイルや承認をいくつかまとめた概念である。 ロールは特殊なユーザとして機能する。一般のユーザと大きく異なるのは、ロールになるにはsuコマンドを利用するしかなく、直接ログインすることができない点と、ロールを機能させるため、シェルとしてはpfsh/pfcsh/pfkshという特殊なシェルを割り当てる必要があることである。 ロールはユーザに対して設定されるが、これはそのユーザがsuでそのロールになれることを指定するものであり、ログインした瞬間からロールに割り当てられた各種能力を持つわけではない。つまり、一般ユーザは管理作業を行う時だけsuで特定のロールとなり、管理作業終了後には元のユーザに戻るような運用を想定している。伝統的なUNIXでrootで作業する場合と対比すると理解しやすいであろう。
ロールへの権利プロファイルの割り当てや、ユーザへのロールの割り当ては、ともに/etc/user_attrファイルで行う。 一つのファイルが複数の役割を持っているように見えるが、これは「承認」を直接ロールやユーザに割り当てたり、権利プロファイルを直接ユーザに割り当てることが可能であるためである。ユーザへ直接割り当てた場合は、あるユーザがログインした時点で、即座にある権利プロファイルや承認が与えられる。 もう一つ、/etc/security/policy.confというファイルも存在する。このファイルは全ユーザに対して、ログインした時点で与えたいロール、権利プロファイル、承認などを指定するためのファイルであり、デフォルトではロール、権利などに関するすべての情報が読みとり可能となる設定がされている。
RBACは複雑であるため、最初はGUIを経由で操作し、ある程度機構を理解した上で、徐々に導入していった方がよいだろう。RBACの設定はSolaris Management Console(smc)上の図xx16の画面から行なえる。
コマンドラインから設定を行なうには、/usr/sadm/bin以下にあるsmrole, smprofileといったコマンドを利用するか、/etc/user_attrおよび/etc/security以下の関連するファイルを直接編集する。例えば図xx17のようにすることで、passmgrというロールを新規に作成することが可能である。
# smrole add -- -n passmgr -a monyo -p "User Security" Authenticating as user: root Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password :: ← rootのパスワード Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from uranus Login to uranus as user root was successful. Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from uranus was successful. Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password :: ← rootのパスワード # passwd passmgr← passmgrロールのパスワード設定 New Password: Re-enter new Password: passwd: password successfully changed for passmgr(*) ここでは「User Security」権利プロファイルをもったpassmgrというロールを作成している。初期のメンバはmonyoである。
では実際にロールが有効となっていることを確認しよう。図xx18をみてほしい。suで先ほど作成したpassmgrロールになると所持している権利プロファイルが増えている。「User Security」権利プロファイルを所持していると、別アカウントのパスワード変更が可能となるため、通常は不可能である別ユーザのパスワード変更を実行することが可能になっていることが確認できる(注xx19)。
monyo@uranus%profiles Basic Solaris User All monyo@uranus%su - passmgr Password: ← passmgrロールのパスワード Sun Microsystems Inc. SunOS 5.9 Generic May 2002 $ id uid=103(passmgr) gid=14(sysadmin) ← passmgrロールになっている $ profiles ←現在の権利プロファイルの確認 >User Security All Basic Solaris User $passwd test1 New Password: Re-enter new Password: passwd: password successfully changed for test1
なお、許可されている以外のユーザからpassmgrロールになろうとしても、図xx20のように警告がでるだけである。
other@uranus% su - passmgr Password: Roles can only be assumed by authorized users su: Sorry
図xx21のようにして、特定のユーザに直接権利プロファイルや承認を割り当てることも可能である。
# usermod -P "System Administrator" local(*) localユーザに「System Administrator」権利プロファイルを割り当てている
この場合、図xx22のように、そのユーザとしてログインするだけで権利プロファイルの権利を行使できる。
%ssh solaris9 -l local local@solaris9's password: Last login: Sat Jun 7 13:45:41 2003 from omoikane.home.m Sun Microsystems Inc. SunOS 5.9 Generic May 2002 > profiles System Administrator Audit Review Cron Management ← Cron Management権利プロファイルが割り当てられている Printer Management Device Management File System Management Mail Management Maintenance and Repair Media Backup Media Restore Name Service Management Network Management Object Access Management Process Management Software Installation User Management Basic Solaris User All > crontab -l sys ← sysユーザのcrontabの内容表示 #ident "@(#)sys 1.5 92/07/14 SMI" /* SVr4.0 1.2 */ #(以下sysユーザのcrontabの内容が表示される。通常別ユーザのcrontabの内容を参照することはできない)
RBAC により、エンタープライズで必要な柔軟性な管理権限の委任が可能となるが、その一方で、かなり複雑な機能となってしまっていることも事実である。 実際にRBACの適用を検討する場合は、運用、RBAC自身の管理コストなども念頭におき、本当にこうした詳細な管理権限の分割が必要かを検討した方がよいであろう。 本機能については、紙面の関係上、これ以上の具体的な説明は割愛する。 実際に利用を検討する際はドキュメントを熟読して、機能を理解した上で判断してほしい。数個のタスクを委任したい程度であれば、スクリプトとsetuidを活用した方が良いかも知れない。またフリーソフトウェアであるが、sudoの利用も考えられる。
セキュリティを維持する上では、万一の際にシステム上でどのような活動が行われたかを確認するための監査機能は必須である。無論Solaris 9にも監査機能は実装されている。 Solaris 9の監査機能を有効にするには、図xx23のように/etc/security/bsmconvコマンドを実行すれば良い。反対に監査機能を停止するためには/etc/security/bsmunconvコマンドを実行する。注意点として、これらのコマンドは必ずシングルユーザモードで実行し、実行後再起動する必要がある点が挙げられる。試しにマルチユーザモードで実行してみたがうまく機能しなかった。
# ./bsmconv This script is used to enable the Basic Security Module (BSM). Shall we continue with the conversion now? [y/n] y bsmconv: INFO: checking startup file. bsmconv: INFO: move aside /etc/rc3.d/S81volmgt. bsmconv: INFO: turning on audit module. bsmconv: INFO: initializing device allocation files. The Basic Security Module is ready. If there were any errors, please fix them now. Configure BSM by editing files located in /etc/security. Reboot this system now to come up with BSM enabled.
監査機能の設定は、基本的に/etc/security以下のファイルで行う。 audit_controlシステム全体の設定を行い、audit_userファイルでユーザ毎の設定を行う。audit_controlにおける監査対象の設定は、図xx24のようにflags行で行う。
利用可能なフラグの一覧は、図xx24.5(audit_control(4))を参照してほしい。
| short name | long name | short description |
|---|---|---|
| no | no_class | null value for turning off event preselection |
| fr | file_read | Read of data, open for reading, etc. |
| fw | file_write | Write of data, open for writing, etc. |
| fa | file_attr_acc | Access of object attributes: stat, pathconf, etc. |
| fm | file_attr_mod | Change of object attributes: chown, flock, etc. |
| fc | file_creation | Creation of object |
| fd | file_deletion | Deletion of object |
| cl | file_close | close(2) system call |
| pc | process | Process operations: fork, exec, exit, etc. |
| nt | network | Network events: bind, connect, accept, etc. |
| ip | ipc | System V IPC operations |
| na | non_attrib | non-attributable events |
| ad | administrative | administrative actions: mount, exportfs, etc. |
| lo | login_logout | Login and logout events |
| ap | application | Application auditing |
| io | ioctl | ioctl(2) system call |
| ex | exec | exec(2) system call |
| ot | other | Everything else |
| all | all | All flags set |
一方特定のユーザのみ監査を行いたいという場合は、audit_userファイルで図xx25のように指定する。
監査の結果は、デフォルトで/var/audit以下に格納される。しかしこのファイルはバイナリファイルであるため、そのままでは内容をみることができない。 そのため、通常は図xx26のようにprauditコマンドを組み合わせて表示することが必要となる。
#auditreduce -c lo | praudit file,Sun Jun 01 03:45:48 2003, + 0 msec, header,81,2,login - local,,Sun Jun 01 03:45:48 2003, + 924 msec subject,root,root,other,root,other,434,434,0 0 marine text,successful login return,success,0 header,86,2,su,,Sun Jun 01 03:58:13 2003, + 281 msec subject,monyo,root,other,monyo,other,493,489,0 1159 omoikane.home.monyo.com text,success for user root return,success,0 file,Sun Jun 01 07:17:52 2003, + 0 msec,(*)-c loはログインクラスのみを表示する設定
あまりが見やすい形式ではないため、実際の運用ではスクリプトなどで後処理を行なうことが必要だろう。 このようにSolaris 9ではさまざまな情報を監査することが可能である。しかしprauditコマンドの出力を直接参照するだけでは実質監査を行なうことは難しい。本機能を利用するにあたっては運用体制や監査ログの解析体制などを整えることが必須であろう。
セキュアなファイルサーバを構築しようとすると、Windows 2000などのNTFSのように、ユーザやグループに対して細かくアクセス権を付与することも必要となってくる。またSambaでファイルサーバを構築している場合なども、WindowsユーザからWindows 2000 Serverと同じように細かくアクセス権を付与したいという場合もあるだろう。 Solaris を始めとする商用UNIXでこの機能を実現しているのがACLになる。 ACLは基本的に図xx27の記法で表される。
u:monyo:rwx g:staff:r-x | | | | | +--- アクセス権 | +--- ユーザ/グループ名 +--- u(ser) = ユーザ/ g(roup) = グループ(*) userと記述してもuと短縮名で指定してもよい。
例外として、図xx28のようにユーザ名フィールドを空欄にした場合は、従来のUNIXのアクセス権を表す。
更にディレクトリに対しては、ディレクトリ内に新規作成されたファイルに付与するデフォルトのACLエントリを設定することも可能である。デフォルトのACLエントリは図xx29のように先頭に「d(efault):」を付与した形になる。
また詳細は後述するが、ACLで許可可能な最大限のアクセス権を示すものとして、ACLマスクという機能もある。 実際にACLを設定する際は、setfaclコマンド、ACL設定を確認する際はgetfaclコマンドを各々図xx30のようにして用いる。
> setfacl -m u:monyo:rw-,g:staff:r--,mask:rwx test.tar.gz > getfacl test.tar.gz # file: test.tar.gz # owner: monyo # group: other user::rwx user:monyo:rw- #effective:rw- group::--- #effective:--- group:staff:r-- #effective:r-- mask:rwx other:---(*) -mオプションはACLの追加/変更を示す(ACLを置き換える場合は-sオプション)。
ここで「mask:rwx」というエントリが、ACLで設定できる最大のアクセス権を示すACLマスクになる。例えば、「mask:r--」の場合は、「user:monyo:rw-」というエントリについても事実上「user:monyo:r--」と同等になる。各ACLにACLマスクの値を加味した最終的なACLのアクセス権がeffective欄に示されている。
なお、ACLが設定されているファイルをls -lコマンドで確認すると図xx31のようにパーミッションの横に「+」が付加されているため、ACLの存在を確認することはできるが、内容を確認するには、getfaclコマンドを用いるしかない。
-rw-r--r--+ 1 passmgr root 136 Jun 7 14:04 test1 -rw-r--r-- 1 passmgr root 157 Jun 7 14:04 test2(*) test1ファイルにACLが設定されていることを確認できる。
このようにACLを利用すれば詳細なアクセス権設定が可能となる。しかしWindowsサーバでも同様だが、あまり詳細なアクセス権を付与すると管理性が非常に低下する。ACLを利用する場合は管理面も充分考慮して設計を行うべきであろう。
暗号化を行なう際などに利用する乱数を生成する機能として、Linuxの/dev/randomや/dev/urandom相当のデバイスが標準で実装されている(注xx32)。
このデバイスは、主にOpenSSHのようなセキュリティのプログラムが内部的に用いることが多く、運用面で直接的に恩恵を感じることは少ないかも知れないが、使用済のハードディスクを初期化する際に図xx33のようにして確実に消去するのに利用したり、あるいはパスフレーズをランダムに生成したりする用途などで用いることも可能である。
# dd if=/dev/random of=/dev/rdsk/c0t0d0(*) 同一の値(00など)で上書きするよりも乱数で上書きした方がより安全である。
利用に関する詳細は、random(7D)を参照してほしい。
runatというコマンドにより、個々のファイルに対して、拡張属性という形で任意のファイルを関連づけて作成することが可能となる。 NTFSのストリーム機能のような用途を想定しているようだが、正直具体的な用途がはっきりしない機能である。 詳細は、runat(1)などを参照してほしい。
これまでパッチを適用するには、管理者がSunSolveを始めとする各種リソースを確認して、必要なパッチを判断、ダウンロードして適用するという作業が必要であった。Solaris 9では、Patch Managerというツール群により改善されて、システムに必要なパッチの自動解析や、一括ダウンロードが可能となっている。このツールの機能を充分に利用するためには、PatchProというパッチ管理を支援するツールが別途必要となるが、Solaris 9には(なぜか)同梱されておらず、別途インストールする必要があるため、以下あわせて説明する。
まず、PatchProを入手する。「Patch Manager Downloads(http://www.sun.com/PatchPro)」より「PatchPro Application for Solaris 9」というリンクをたどり、Solaris 9用のpproSunOSsparc5.9jre2.1.tar.gzというアーカイブをダウンロードする。 ダウンロード後は図xx34のようにしてインストールを行なう。途中の質問は、y/n形式はyを、キーストアのパスワードとしては「changeit」を指定する。詳細については、pproSunOSsparc5.9jre2.1ディレクトリ直下にあるREADMEを適宜参照してほしい。
# gunzip -c pproSunOSsparc5.9jre2.1.tar.gz | tar xf -
# cd pproSunOSsparc5.9jre2.1
# ./setup
# PATH=/opt/SUNWppro/bin:/usr/sadm/bin:${PATH} ; export PATH ← sh 系
# setenv /opt/SUNWppro/bin:/usr/sadm/bin:${PATH} ← csh系
(中略)
# /usr/j2se/jre/bin/keytool -import -alias smicacert \
-file /etc/certs/SUNW/smicacert.b64 \
-keystore /usr/j2se/jre/lib/security/cacerts
Enter keystore password: changeit ← changeit を入力
Owner: O=Sun Microsystems Inc, CN=Sun Microsystems Inc CA (Class B)
Issuer: CN=Sun Microsystems Inc Root CA, O=Sun Microsystems Inc, C=US
Serial number: 1000006
Valid from: Mon Nov 13 11:23:10 PST 2000 until: Fri Nov 13 11:23:10 PST 2009
Certificate fingerprints:
MD5: B4:1F:E1:0D:80:7D:B1:AB:15:5C:78:CB:C8:8F:CE:37
SHA1: 1E:38:11:02:F0:5D:A3:27:5C:F9:6E:B1:1F:C4:79:95:E9:6E:D6:DF
Trust this certificate? [no]: yes ← yes を入力
Certificate was added to keystore
# /usr/j2se/jre/bin/keytool -import -alias smirootcacert \
-file /etc/certs/SUNW/smirootcacert.b64 \
-keystore /usr/j2se/jre/lib/security/cacerts
# /usr/j2se/bin/keytool -import -alias patchsigning -file \
/opt/SUNWppro/etc/certs/patchsigningcert.b64 -keystore \
/usr/j2se/jre/lib/security/cacerts
Enter keystore password: changeit ← changeit を入力
Owner: CN=Sun Microsystems Inc Root CA, O=Sun Microsystems Inc, C=US
Issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US
Serial number: 200014a
Valid from: Tue Nov 07 14:39:00 PST 2000 until: Thu Nov 07 15:59:00 PST 2002
Certificate fingerprints:
MD5: D8:B6:68:D4:6B:04:B9:5A:EB:34:23:54:B8:F3:97:8C
SHA1: BD:D9:0B:DA:AE:91:5F:33:C4:3D:10:E3:77:F0:45:09:4A:E8:A2:98
Trust this certificate? [no]: yes ← yesを入力
Certificate was added to keystore
↓ 以下の2行はSunSolveのアカウントを持っている場合のみ
# /opt/SUNWppro/bin/pprosetup -u <user_id>
# echo <passwd> > /opt/SUNWppro/lib/.sunsolvepw
↓ プロキシが必要な環境のみ
# /opt/SUNWppro/bin/pprosetup -x <プロキシサーバ>:<ポート番号>
# /opt/SUNWppro/bin/pprosetup -P https://japan.patchmanager.sun.com/patchmanager/
これで、/opt/SUNWppro以下にPatchProがインストールされた。 なお、キーストアのパスワードのデフォルトが「changeit」となっているため、図xx35のコマンドで変更しておくこと。
# /usr/j2se/jre/bin/keytool -storepasswd -keystore /usr/j2se/jre/lib/security/cacerts
以下、具体的な機能について説明する。なお以下で説明する機能は、図xx36のPatch ManagerというGUIで操作することも可能だが、基本的にはコマンドラインからバッチ処理的に起動する方が有用だと思われるため、以下コマンドラインでの操作を取り上げる。
図xx37のようにanalyzeサブコマンドを指定することで、システムに不足している推奨パッチの一覧が出力される。管理者は、これを元にパッチの適用計画を策定すれば良い。
#smpatch analyze -p <rootのパスワード> -u root
Loading Tool: com.sun.admin.patchmgr.cli.PatchMgrCli from marine
Login to marine as user root was successful.
Download of com.sun.admin.patchmgr.cli.PatchMgrCli from marine was
successful.
Assessing required patches for machine marine. Please wait...
114483-02 SunOS 5.9_x86: Product Registry CLI Revision
114196-05 SunOS 5.9_x86: /usr/snadm/lib Library and Differential
Flash Patch
114145-01 SunOS 5.9_x86: Apache Security Patch
114613-01 SunOS 5.9_x86: ANSI-1251 encodings file errors
114277-01 SunOS 5.9_x86: Adds extended Arabic support
114194-02 SunOS 5.9_x86: patchadd and patchrm Patch
114568-02 SunOS 5.9_x86: usr/sadm/install/bin/pkginstall Patch
113176-02 PatchPro patch engine corrections
113196-01 Java SimpleDatabase corrections
(*)上記は一切パッチを適用していないmarineというホスト名のSolaris 9 for Intelマシンでの出力例
必要なパッチをダウンロードするには、analyzeではなくdownloadオプションを指定する。これにより図xx38のように/var/sadm/patch以下に必要なパッチがダウンロードされる。
# smpatch download
Authenticating as user: root
Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: ← パスワード
Loading Tool: com.sun.admin.patchmgr.cli.PatchMgrCli from marine.megumi-in.home.
monyo.com
Login to marine.megumi-in.home.monyo.com as user root was successful.
Download of com.sun.admin.patchmgr.cli.PatchMgrCli from marine.megumi-in.home.mo
nyo.com was successful.
Assessing required patches for machine marine.megumi-in.home.monyo.com.
Please wait...
114483-02 SunOS 5.9_x86: Product Registry CLI Revision
114196-05 SunOS 5.9_x86: /usr/snadm/lib Library and Differential Flash Patch
114145-01 SunOS 5.9_x86: Apache Security Patch
114613-01 SunOS 5.9_x86: ANSI-1251 encodings file errors
114277-01 SunOS 5.9_x86: Adds extended Arabic support
114194-02 SunOS 5.9_x86: patchadd and patchrm Patch
114568-02 SunOS 5.9_x86: usr/sadm/install/bin/pkginstall Patch
113176-02 PatchPro patch engine corrections
113196-01 Java SimpleDatabase corrections
Downloading the required patches for machine marine.megumi-in.home.monyo
.com ...
The following patches were excluded due to patch dependencies:
114194-02
114568-02
113176-02
113196-01
The following patches were not downloaded. Contact your Sun Microsystems support
provider for more information.
114483-02
114196-05
114613-01
For downloaded patch(es) see /var/sadm/spool.
この他smpatchには上記リストによらず、特定のパッチを取得して複数マシンにインストールできるaddサブコマンドやパッチを(単一マシンから)アンインストールするremoveコマンドがある。詳細はsmpatch(1M)を参照してほしい。
システムのセキュリティの設定は、単調で繁雑な作業であるが、Solaris 8以降で同梱されたASET(自動セキュリティ拡張ツール)を用いることで、これらの設定を半自動的に設定することが可能となった。 このツールを実行することで、以下の作業を自動的に行うことが可能である(括弧内は識別子)。
ASETを実行するには図xx39のように-lオプションの後にセキュリティ強度を示すlow, med, highいずれかのキーワードを指定してasetコマンドを実行すればよい。
# /usr/aset/aset -l low
======= ASET Execution Log =======
ASET running at security level low
Machine = marine; Current time = 0531_16:55
aset: Using /usr/aset as working directory
Executing task list ...
firewall
env
sysconf
usrgrp
tune
cklist
eeprom
All tasks executed. Some background tasks may still be running.
Run /usr/aset/util/taskstat to check their status:
/usr/aset/util/taskstat [aset_dir]
where aset_dir is ASET's operating directory,currently=/usr/aset.
When the tasks complete, the reports can be found in:
/usr/aset/reports/latest/*.rpt
You can view them by:
more /usr/aset/reports/latest/*.rpt
最終的に/usr/aset/reports/lates以下に図xx40のような実行結果が保存される。必ず何がどのような状態に変更されたかを確認し、システムの動作に影響がでないようにすること。なお元の状態に戻すには、/usr/aset/aset.restoreコマンドを用いる。
*** Begin System Scripts Check *** Warning! finger has poor authentication mechanism not recommended on a secure system. (/etc/inetd.conf) Entry fixed. finger entry is commented out. Warning! rusersd has poor authentication mechanism not recommended on a secure system. (/etc/inetd.conf) Entry fixed. rusersd entry is commented out. World writability for /var/adm/utmpx has been removed. World writability for /var/adm/wtmpx has been removed. /usr/aset/tasks/sysconf: -s: not found Warning! /etc/ftpd/ftpusers should contain root at high security level. Root entry has been appended in /etc/ftpd/ftpusers. *** End System Scripts Check ***
この他asetコマンドには-pオプションによりcronでの自動実行の設定を行うなど、幾つかのオプションがある。詳細はaset(1M)などを参照してほしい。
システムの要件によっては、ASETのデフォルトの設定とは異なる設定を行いたい場合も多いだろう。設定の変更は/usr/aset/masters以下にあるマスターファイルで行う。 tune.*というファイルはasetコマンド実行時に確認、設定されるべきファイルとその属性を図xx41のような形式で記述したものである。
# Format: # pathname mode owner group type /.cshrc 0600 root ? file /.login 0600 root ? file /.profile 0600 root ? file /.logout 0600 root ? file
コメント中に記載があるように、ファイル毎にファイルのあるべき属性を定義していく。同じディレクトリ中にあるuid_aliasesファイルでは、uidが重複しても警告の対象としないアカウントを指定する。 これ以上のカスタマイズを行う場合は、/usr/aset/tasks以下にある各タスクの実体のシェルスクリプトファイルを修正すればよい。ASETを構成するファイルの大半はシェルスクリプトのため、ユーザの環境に応じて柔軟にカスタマイズすることが可能となっている。 システムのセキュリティ用件を満たすカスタマイズが完了したら、cronなどで定期的に実行し、結果をメールなどで通知するようにすればよいであろう。
本機能は決して目新しいものではなく、今までも管理者が個々に行なってきたシステムのセキュリティ確認作業のテンプレートとなるものを提供しているに過ぎないが、逆に考えると、同等の機能を管理者が一から作成する作業を軽減し、Sunとしての指針を提供したという点で評価できる。
従来よりLinuxではlogrotateというプロダクトを利用して、一定期間毎のログのローテーションを簡単に行なうことができたが、Solarisでは同等の機能がなく、スクリプトなどを作成して対処する必要があった。 Solaris 9ではlogadmというコマンドにより、こうしたログの管理を簡単に行なうことが可能である。図xx42に例を示す。
#logadm -w mylog -C 8 -a 'kill -HUP `pgrep myapp`' /var/log/mylog(*)/var/log/mylogというファイルをローテーションする。その際過去8世代分のログを残し、ローテーションした後で、「kill -HUP `pgrep myapp`」というコマンドを実行するというエントリを追加する。
設定は/etc/logadm.confに書き込まれる。デフォルトでは1日1度logadm.confファイルの内容が参照され、ローテーションが行なわれる。 logadmコマンドは是非とも使いこなしたい。
Solaris 9ではこれまでシステムのコアコンポーネントに含まれていたTELNETやftpなどをアンインストールすることが可能となっている。
ここまで、Solaris 9のセキュリティ機能について駆け足だが紹介した。詳細な使用方法などについてはSunの製品文書(http://docs.sun.com/?l=ja)中のマニュアルや、各種のWebサイト、雑誌などを参照してほしい。 これらの機能を利用することで、かなり強固なシステムを構築することが可能である。 しかし、ここで紹介した機能のほとんどは、あくまでオプションであり、基本的な設定や運用を行なった上で適用することで、はじめて有効に機能するものである。そこで、最後になあるが、実際のシステムを運用していくにあたっての基本的な注意点やポイントについて簡単に説明する。
当たり前であるが、基本的なセキュリティ対策がおざなりでは、たとえ高度な機能を利用しても有効性が半減してしまう。
インストール直後のSolarisに対してまず行なうべきことは不要サービスの削減である。筆者の手元の環境で、インストール直後にnetstat -an| を行なった結果を図xx43に示す。
% netstat -a -f inet -P tcp | grep LISTEN
*.sunrpc *.* 0 0 24576 0 LISTEN
localhost.domain *.* 0 0 24576 0 LISTEN
marine.home.local.domain *.* 0 0 24576 0 LISTEN
*.ftp *.* 0 0 24576 0 LISTEN
*.telnet *.* 0 0 24576 0 LISTEN
*.shell *.* 0 0 24576 0 LISTEN
(以下略)
% netstat -a -f inet -P udp | grep Idle
*.sunrpc Idle
*.32774 Idle
localhost.domain Idle
marine.home.local.domain Idle
(以下略)
ここで、実行例xx44のようにして行数を計算してみる。
% netstat -a -f inet -P tcp | grep LISTEN | wc -l % netstat -a -f inet -P udp | grep Idle | wc -l
筆者の環境ではTCP41行、UDP30行で全部で70行以上となった。 大雑把にいうと各行が起動しているサービスを示すため、インストールした直後の状態ではいかに多くのサービスが起動しているかがわかるだろう。 セキュアな運用を行なう上では、どのプロセスが何のためにどのポートをオープンしているかを確認し、不要なポートをオープンしているサービスはすべて停止させることが必要である。 GUIを利用しなくてよければ、管理上必要なポートは先に説明したsshのポート(22/tcp)だけで充分であろう(注xx45)。これにWebサーバとして利用するのであれば80/tcp、メールを利用するのであれば25/tcpといった各サーバサービスが利用するポートのオープンが必要となってくることになる。
rsh/FTP/TELNETなどを利用していないのであれば、/etc/inetd.confのエントリはすべて無効にしてしまえばよい。その他各サービスについて表xx46に筆者が行なっている対処をまとめてみた。
| 検討 | スクリプト名 | 説明 |
|---|---|---|
| - | S72slpd | SLPデーモン |
| - | S74xntpd | NTPデーモン |
| S88sendmail | sendmail | |
| x | S90loc.ja.cssd | 日本語入力(Sun純正) |
| x | S90wbem | WindowsからSolarisを管理する為のサービス |
| x | S94Wnn6 | 日本語入力(Wnn6) |
| x | S95IIim | 日本語入力(ATOK12) |
| x | S99atsv | 日本語入力(ATOK12) |
| 検討 | スクリプト名 | 説明 |
|---|---|---|
| - | S13kdc.master | Kerberosサーバ |
| - | S14kdc | Kerberosサーバ |
| S15nfs.server | NFSサーバ | |
| - | S16boot.server | BOOTPサーバ |
| x | S34dhcp | DHCPサーバ |
| x | S42ehttpd | SMC(Sun Management Console) |
| - | S50apache | Apache |
| x | S76snmpdx | SNMPサービス |
| x | S77dmi | DMIサービス |
| - | S90samba | Sambaデーモン |
また、デフォルトではsyslogdが外部からのリクエストを受け付けるようになっているため、/etc/init.d/syslogファイルを開き、27行目を図xx47のように修正することで外部からの接続を受け付けなくしたほうがよい。
次に、必要なサービスについても無関係なネットワークからのアクセスを防止する。inetdを利用しているサービスであれば、前述したTCP_Wrapeers機能を利用できる。 Apacheのように独自にデーモンとして起動しているサービスについては、個々のサービスの機能を利用して制御を行なう。 また、可能であれば明らかに不要なパッケージはアンインストールしておいた方がよい。Solaris 9からは、「柔軟なインストール」と称して、これまで外すことができなかったTELNETなどの基本コンポーネントも個別にアンインストールすることが可能になっている。 更に、パケットのフィルタリングなどを行ないたい場合は、SunScreen 3.2などの導入を検討していけばよい。
システムのセキュリティを維持する上では、インストール後も日々メンテナンスを行なっていくことが必要である。
システムのセキュリティを維持する上で、パッチの適用は必須である。セキュリティパッチの他最低でも推奨パッチは適用を検討すべきだろう。推奨パッチについては、SunSolveより、Recommended and Security Patchesより、その時点での最新のものが図xx48のように取得できる。
また、前述したPatchProを利用し、定期的にanalyzeを行なうことで、不足しているパッチを確認することも可能である。 パッチ情報を含むセキュリティ情報は、SunSolveにて提供されているため。適宜確認してほしい。セキュリティ情報の取得についてはメールマガジンなどを利用するのもよいだろう。
万一のことがあった場合に備え、ログの設定を行なっておくことは重要である。syslog経由でログを出力するプロダクトは/etc/syslog.confの設定を、独自のログを出力するものについては各々設定を行なう。 更に、前述したlogadmコマンドなどを用いてローテーションの設定も行なっておきたい。もちろん出しっぱなしではなく内容の監視も必要である。最低でも/var/adm/messagesや/var/adm/sulogおよびlastlogは監視すべきであろう。 通常のSolaris 9の機能で満足できない場合は、監査機能の導入を検討する。 なにをどう監視するかについては、システム依存の部分が多くなってしまうため、具体例が出しにくい点であるが、システムのセキュリティの観点からは、最低限誰がいつログインしたか、suしたかについてはきちんと把握しておくべきであろう。
ここまで、Solaris 9のセキュリティ機能について、新規機能と運用のポイントについて簡単に紹介した。 前半で紹介したRBACや監査機能をはじめとする各種機能を駆使することで、従来のUNIXでは困難だった詳細なセキュリティ管理や、管理権限の分散が実現される。またsshの同梱は、遠隔からSolarisマシンを管理する管理者にとっては非常に嬉しい機能である。 しかし、実際のところ最後に紹介した不要サービスの停止と適切なパッチ適用を行なうことで、ネットワーク経由の攻撃に対しては簡単に侵入されない程度のセキュリティは実現される。逆にいうと、システムのセキュリティを維持する上では基本的な運用をしっかりと行なっていくことは地味ではあるがやはり重要であるといえる。 最後になるが、本記事がSolarisシステムのセキュリティ維持を行なっている管理者の方々にとって何らかの役に立てば幸いである。
