| Oracle Enterprise Manager Configuration Change Consoleインストレーション・ガイド 10gリリース5（10.2.0.5） for Microsoft Windows or UNIX Systems B55859-01 |
|
 戻る |
 次へ |
| Oracle Enterprise Manager Configuration Change Consoleインストレーション・ガイド 10gリリース5（10.2.0.5） for Microsoft Windows or UNIX Systems B55859-01 |
|
戻る |
次へ |
ここでは、UNIXにエージェントをインストールする手順について説明します。また、特定のオペレーティング・システムの特定の要件については、本マニュアルで後述します。それらの項も必ず読むようにしてください。
ここでは、コンソール・モードまたはグラフィカル・モードでUNIXエージェントをインストールするプロセスを説明します。オペレーティング・システムによっては、標準のUNIXインストール手順に加えて特別の手順を実行する必要があります。
コンソール・ベースのインストール・プロセス中、直前のプロンプトに戻るには、任意の時点でBackと入力します。
エージェントをインストールするには、rootとしてログインする必要があります。後からエージェントを実行するときには、任意のユーザーとして実行することもできます。その場合は、この章の後で説明する特定の手順を実行してください。
Configuration Change Consoleインストール・メディアからagent-x.binファイルをコピーします。-xは、エージェント・インストーラが対応しているオペレーティング・システムを表します。
次のコマンドを使用してこのファイルが実行可能であることを確認します。<agent executable>は、特定のプラットフォームのインストール・ファイルです。
chmod +x <agent executable>
例: chmod +x agent-linux-32bit.bin
Configuration Change Consoleインストール・メディアに対して、次のコマンドを入力します。<agent executable>は、上に示した各プラットフォームに対応するインストール・ファイルです。
コマンドラインからインストーラを実行するには、次のようにします。
./<agent executable> -i console
グラフィカル・インストーラを使用してX-windowsでインストーラを実行するには、次のようにします。
./<agentexecutable>
初期画面が表示されます。[Enter]を押して進みます。
次に、エージェントのインストール・ディレクトリの指定を求められます。
[Enter]を押してデフォルトのインストール・ディレクトリを受け入れるか、独自のインストール・パスを入力します。
Configuration Change ConsoleサーバーのURLを入力します。URLの形式はt3s://hostname:portです。hostnameは、非クラスタ環境を使用する場合は、プライマリ・サーバーが配置されているホストです。クラスタ環境を使用する場合は、たとえば、t3s://hostname1:port1,hostname2:port2,hostname3:port3を使用し、各メッセージング・ブローカ・サーバーのホスト名とポートを指定します。「次へ」をクリックします。
次は、インストール後にエージェントを自動的に起動するかどうかが確認されます。インストール後にエージェントを自動的に起動するには、[Enter]を押します。エージェントを自動的に起動しない場合は、2を入力します。[Enter]を押します。エージェントを自動的に起動するように設定しない場合は、手動で起動する必要があります。/etc/init.d/arprobeを使用してエージェントを起動する手順は、この章で後述します。
Configuration Change Consoleサーバーの管理者のユーザー名（デフォルトはadministrator）とパスワードを入力するように求められます。これは、エージェントをインストールしているユーザーにその権限があることを確認するために使用されます。このユーザー名とパスワードの組合せは、エージェントのインストール時にのみ使用され、エージェントのインストール後に、ユーザーを無効にするか、ユーザーのパスワードを変更しても問題ありません。
次に、サーバーの監査機能が有効か否かを尋ねられます。監査の要件は、オペレーティング・システムごとに異なります。Linuxの場合は、必要なカーネル・ファイルが使用可能な状態にあり、カーネル・モジュールをコンパイルできることを意味します。Solarisの場合は、Solaris BSMがインストールおよび構成され、エージェントで使用できることを意味します。この質問でnoを選択した場合、リアルタイムでのファイル変更の監視は行われず、ポーリング・ファイル監視機能が使用されます。各オペレーティング・システムに固有の要件を一読し、適切な監査設定を有効にして、エージェントのインストールの際にこの質問にyesと返答することをお薦めします。
「サマリー」画面が表示されます。インストール・フォルダが正しいことを確認し、インストールをクリックしてインストールを進めます。
「インストール完了」画面が表示されたら「完了」をクリックして、インストーラを終了します。
エージェントが自動的に起動されるのは、起動するようにインストール時に選択した場合です。自動的に起動しない場合は、コマンド・プロンプトで次のコマンドを入力します。
cd /etc/init.d/
./arprobe start
エージェントを停止するには、./arprobe stopと入力します。
|
注意: エージェントを起動するにはrootユーザーであることが必要です。ただし、後で説明するように、非rootユーザーとしてのエージェントの稼働を設定する手順を実行した場合は除きます。 |
各UNIXオペレーティング・システムでは、エージェントがインストールされている場合、オペレーティング・システムとともにサービスが起動されるように設定されています。該当するrcX.dディレクトリ下に、起動および停止スクリプトのリンクがあります。オペレーティング・システムの起動/停止の際の起動または停止の動作を変更する場合以外は、手動によるメンテナンスの必要はありません。
エージェントをアンインストールするには、rootとしてログインする必要があります。エージェントをアンインストールする手動の手順は次のとおりです。
コマンド・プロンプトで、エージェント・アンインストーラのディレクトリに移動します。たとえば、rootとしてインストールした場合は、次のように入力します。
cd /root/oracle/ConfigurationChangeConsoleAgent/UninstallerData
次のように入力してアンインストーラを実行します。
./Uninstall_Configuration_Change_Console_Agent
デフォルトでは、UNIXではエージェントはrootユーザーとして実行すると想定されています。ただし、次に示す手順を実行すると、非rootユーザーとして実行するようにエージェントをインストール後に構成することができます。
ファイル権限
まず変更する必要があるのは、エージェント・ファイルのファイル所有権です。インストーラによって、エージェントのすべてのファイルとディレクトリはroot（インストールを実行するユーザー）が所有するように設定され、GROUPおよびOTHER USERSの権限は完全に無効化されます。別のユーザーがこれらのファイルを表示する場合は、ファイルとディレクトリの所有権をrootから、そのユーザー（新たな所有者）に変更する必要があります。次に変更方法の例を示します。newuserは、エージェントを所有するユーザーのログイン名、{agent_install_dir}は、エージェントがインストールされている場所のフルパスに置き換えます。
chown -R newuser {agent_install_dir}
ファイルを表示するためにGROUPまたはOTHER USERSの権限を追加することはお薦めしません。これらのディレクトリのファイルにはセキュリティ関連の情報が含まれるためです。
バイナリの実行設定
エージェントに含まれる2つのバイナリを実行して必要なデータを収集するには、高い権限が必要です。このためには、次の手順を実行します。
エージェントが実行している場合は停止します。
ディレクトリをエージェントをインストールした{agent_install_dir}/binに変更します。
次のコマンドを実行します。
chown root filewatcha
chown root filewatchp
chmod a+s filewatcha
chmod a+s filewatchp
ファイル/etc/rc.d/init.d/arprobeを編集して、$PROBE_HOME/bin/probeのすべてのインスタンスをsudo -u newuser "$PROBE_HOME/bin/probe"で置き換えます。
エージェントを起動します。この時点で、エージェントはユーザーnewuserとして実行しています。
エージェントのインストール時に指定した認可の資格証明が、なんらかの理由で正しくない場合、認可の再実行を強制的に手動で行う必要があります。サーバーで「管理」→「デバイス」→「デバイス」画面を調べたときに、エージェントがサーバーに登録されていないために、認可の失敗に気づくことがあります。
再認可を強制するには、次の手順を実行します。
シェル・ウィンドウを開きます。
ディレクトリを{agent_install_dir}/binに変更します。
スクリプトresetauth.shを実行します。
プロンプトが表示されたら、Configuration Change Consoleサーバーの管理者ロール・ユーザーのユーザー名とパスワードを入力します。
セキュリティの理由から、認証が失敗しても、失敗を知らせるメッセージはエージェントに返されません。
ここでは、Linuxエージェントのインストール手順について説明します。
Linuxエージェントをインストールするには、Linuxのカーネル・バージョンと正確に一致するKernel Developmentパッケージがインストールされている必要があります。これを確認するには、最初に、uname -aを実行して、カーネル・バージョン（2.4.21-37.0.0.4.ELhugememなど）を記録しておきます。次に、この特定バージョンのカーネル・レベルのパッケージがインストールされているかをRPMレジストリで確認します。開発パッケージとバージョン番号が正確に一致していることは非常に重要です。カーネルにモジュールを挿入する際にバージョンが一致していないと、コンパイル済のカーネル・モジュールが失敗します。
また、使用するgccのバージョンと、カーネルを構築した際のgccのバージョンが一致している必要があります。これを調べるには、カーネルを構築した際のgccのバージョンを/proc/versionで確認した後、gcc -versionを実行して使用中のgccのバージョンを確認します。これらのバージョンは、一致している必要があります。
また、エージェントの操作には、/boot/System.map-{version}ファイルが存在する必要があり、{version}は、uname -aコマンドを実行した際のカーネル・バージョンと一致する必要があります。リアルタイムの変更を監視するには、このファイルに含まれるシステム・シンボルが、カーネル・シンボルのデコードのために必要です。このファイルがない場合、リアルタイムのファイル監視は機能しません。このファイルは、すべてのデフォルトのLinuxインストールで標準となっています。
Linuxエージェントをインストールする際にこれらのすべての依存性をチェックするスクリプトが実行され、要件が欠けている場合は通知されます。インストールは機能し続けますが、モジュールを手動で構築するまで、リアルタイムのファイル監視は機能しません。このリカバリに関する詳細は、「カーネル・モジュールのコンパイルの問題」で後述します。
将来Linuxカーネルのバージョンを変更する場合は、サーバーのカーネルとバージョンが一致するように、ロード可能なカーネル・モジュールを再コンパイルする必要があります。モジュールの再コンパイルの手順は、「カーネル・モジュールのコンパイルの問題」で後述します。
Linuxエージェントをインストールするには、次の手順を実行します。エージェントをインストールする前には、標準パッケージおよび最新パッケージをすべてインストールしておく必要があります。
管理対象サーバーでターミナル・ウィンドウを開きます。rootとしてログインする必要があります。
Configuration Change Consoleインストール・メディアをCD ROMドライブに挿入します。ディスクをマウントします。
プロンプトで、サーバーのプロセッサのタイプに応じて、CDのagent-linux-x86-32bit.binファイルまたはagent-linux-x86-64bit.binを/tmpディレクトリにコピーします。
プロンプトで、サーバーのプロセッサ・タイプに応じて次のいずれかのコマンドを入力して、インストーラを起動します。
/tmp/agent-linux-x86-32bit.bin -i console
/tmp/agent-linux-x86-64bit.bin -i console
X-Windowsでグラフィカル・インストーラを起動する場合は、コマンドの-i console部分を省略してください。
インストールが終了する前の追加の手順として、リアルタイム・ファイル監視のためのロード可能なカーネル・モジュールがコンパイルされます。コンパイルが成功したかどうかを示すステータス・メッセージが表示される場合があります。失敗した場合、またはlogs/FileRunning.logにエラーが存在してリアルタイム・ファイル監視モジュールを起動できない場合は、「カーネル・モジュールのコンパイルの問題」を参照してください。
インストールが終了したら、次のコマンドを使用してtmpディレクトリのインストール・ファイルを削除します。
rm -i agent-lin*
次の3つの状況は、Linuxカーネル・モジュールのロードで問題があったことを示している可能性があります。Linuxエージェントのインストール時、インストールの終わり頃に、カーネル・モジュールのコンパイルが失敗したというエラー・メッセージを受け取る場合があります。また、ファイルが明らかに変更された場合でも、Configuration Change ConsoleサーバーのUIにリアルタイムのファイル変更が出力されない場合もあります。あるいは、{agent install directory}/logs下のFileRunning.logファイルを確認すると、様々な理由でカーネル・モジュールをロードまたは使用できなかったというエラーが出力されている場合もあります。これらの問題が発生した場合、ほとんどは、実行時のLinuxカーネル・モジュールのコンパイルまたは挿入で問題が発生しています。
次のコマンドを実行すると、監査モジュールが適切にロードされたかどうかを確認できます。
grep -i auditmodule /proc/modules
出力がない場合は、監査モジュールがロードされていないため、エージェントはリアルタイム・ファイル監視を実行できません。
次の手順を実行すると、監査モジュールの強制的な再構築を試行することができます。
シェルを開き、エージェントをインストールしたディレクトリ（たとえば/root/oracle/ConfigurationChangeConsoleAgent/bin）に移動します。
プロンプトで./compmod.shと入力します。
{agent install directory}/logsでmake.logおよびbuild.logファイルを調べて、解決可能なエラーがあるかを確認します。
compmod.shの実行でエラーがなかった場合は、binディレクトリを確認して、compmod.shの実行後にauditmodule*.koファイルが作成されたかどうかを調べます。作成されている場合は、モジュールを手動でロードしてエラーを確認できます。次のコマンドを使用します（{audit module file name}は、compmod.shから作成された.koファイルの名前に置き換えます）。
insmod {audit module file name}
このときエラーが発生しなかった場合は、前述のgrepコマンドを使用して、モジュール・リストを再び確認します。監査モジュールが表示されている場合、エージェントを再起動した後にファイル監査機能が動作します。
まだモジュールをロードできず、問題についてOracleサポート・サービスに問い合せる必要がある場合は、サポート・チケットに次の情報を含めてください。
コマンドの出力: uname -a
コマンドの出力: grep –i /proc/modules
コマンドの出力: rpm –q –a │grep –i kernel-devel
{agent install dir}/logsディレクトリのmake.logおよびbuild.logファイル
{agent install dir}/logs/FileRunning.logファイル
この情報は、使用環境でエージェントのリアルタイム・ファイル監視の監査モジュールを構築できるかどうかをオラクル社が判断する際に役立ちます。OSのカーネルにパッチを適用した場合は、新しいカーネルのバージョンと一致するように、前述の手順を使用してauditmoduleカーネル・モジュールを再コンパイルする必要があります。また、パッチを適用したカーネルと同じバージョンのkernel-develパッケージをインストールする必要があります。
次の手順を実行して、Solarisエージェントをインストールします。
rootユーザーとしてSolarisサーバーにログインします。
Configuration Change Consoleインストール・メディアから、agent-solaris-sparc.binファイルを/tmpディレクトリにコピーし、インストーラが実行可能であることを確認します。次のように入力します。
chmod +x agent-solaris-sparc.bin
この後のインストール手順については、「UNIXエージェントのインストール」のコンソール・モードの手順2以降を参照してください。
エージェントは自動的に起動します。自動的に起動しない場合は、コマンド・プロンプトで次のコマンドを入力します。
cd /etc/init.d/
./arprobe start
|
注意: プローブを停止するには、./arprobe stopと入力します。 |
Solaris Auditは、Solaris TM SHIELD Basic Security Model（BSM）に含まれており、追加のセキュリティ機能を提供します。システム管理者は監査を行って、イベントを監視し、ユーザー・アカウントのログインおよびログアウトやファイルの変更を検出することができます。
監査がサーバーですでに有効になっている場合は、次に詳しく示す構成と監査システム構成が一致することを確認してください。
監査ファイルを構成して、特定のイベントを含めることができます。/etc/security/audit_controlファイルを使用して、監査ファイルに含まれるイベントを制御します。この項では構成の概要について説明します。詳細は、Sun Product Online Documentationサイトを参照してください。
FileRunning/Userrunningについて、ファイル/etc/security/audit_controlのflags行は次のように設定されます。
flags: +fw,+fc,+fd,+lo
この構成では、ファイルの書込み（fw）、ファイルの作成（fc）、ファイルの削除（fd）およびログイン/ログアウト・イベント（lo）の成功と失敗の監査が有効になります。+は、成功したイベントのみのロギングを意味します。ログイン/ログアウト・イベントはFileRunningでは使用されませんが、UserRunningで使用されます。FileRunningでは、失敗したイベントや組込みと除外の基準を満たさないファイルを省くことで、イベントをフィルタ処理しています。ただし、失敗したイベントのロギングも行う場合は、フラグの各イベントの前の+符号を外します。
audit_controlファイルには、監査ログの格納場所や監査システムで使用されるディスク領域の最大容量を制御するためのエントリもあります。FileRunningの最小要件は、5分間（または構成されている報告間隔）でハード・ドライブに格納されるデータの容量にほぼ相当します。
audit_userファイルでは、監査対象のユーザーが制御されます。このファイルの設定は特定のユーザーに対応し、すべてのユーザーに適用されるaudit_controlファイルの設定を上書きします。
FileRunningは監査ログを読み取るだけです。ログの削除は行いません。このため、システムのログ・ファイルが一杯になり、それ以降のイベントのロギングができなくなることがあります。最小限のFileRunnning/UserRunning要件を維持しながら、古い監査イベントの管理および削除を行うには、次の手順を実行します。
監査ポリシーを設定して、すべてのプロセスを一時停止するのではなく、新しいイベントを自動的に削除することができます（削除イベントの件数のみを記録）。これには、次のコマンドを実行します。
# auditconfig -setpolicy cnt
次のコマンドを実行すると、監査デーモンが現在の監査ログ・ファイルを閉じて、新しいログ・ファイルを使用するように強制されます。
/usr/sbin/audit -s
次のコマンドを実行すると、閉じている既存の監査ログ・ファイルがマージされて、.trashという拡張子の1つのファイルになります。監査ログ・ファイルは削除されます。
/usr/sbin/auditreduce -D trash
crontabコマンドを実行して、上の手順2と3のコマンドを定期的に実行します。これらの2つのコマンドを実行する頻度は、予測されるイベント件数と監査に割り当てられているディスク領域の容量に基づいて調整できます。このときの要件は、audit -sコマンドとauditreduce - D trashコマンドの間隔を、FileRunningおよびUserRunningの報告間隔の2倍以上の時間（分）にすることだけです。
ここでは、HP-UXサーバー上にエージェントをインストールする手順を説明します。Configuration Change Consoleエージェントは、32ビットまたは64ビットPA-RISCおよびIA64プロセッサでのHP-UX 11.23をサポートします。前提条件をよく読んで、インストールを開始する前に必要なソフトウェアおよびパッチを入手してください。HPUX 11.11でのHPUX 32ビットPA-RISCエージェントの使用の詳細は、次の項で説明します。
HP-UXエージェントは、ファイルとプロセスの変更、システム・リソースの使用率およびサーバー構成に関連するデータを収集して報告します。デフォルトでは、HP-UXプラットフォームのエージェントによってファイル変更に関連するユーザーが報告されることはありませんが、Intrusion Detection System（HIDS）アプリケーションがシステムにインストールされている場合は異なります。HIDSによって提供される監査機能により、ファイル変更とそれらの報告対象の変更に関連するユーザーが記録されます。
Configuration Change Consoleエージェントは、HIDS 2.x、3.xおよび4.xをサポートします。最新の4.xバージョンをインストールすることをお薦めします。
このドキュメントでは、『HP-UX HIDS System Administrator's Guide』のHIDSに関する項の基本的な情報を示します。
HIDS監査機能は、Configuration Change Consoleエージェントと連携して、ファイルの未認可アクセスに関連するユーザー名や、ファイルの追加、作成、変更、削除などのファイル・イベントのリストを提供します。
HP-UXプラットフォームのエージェントによって、ファイル変更に関連するユーザーが報告されることはありません。ただし、Intrusion Detection System（HIDS）アプリケーションがシステムにインストールおよび構成されている場合は異なります。
HIDSアプリケーションは、エージェントをインストールする前にインストールしておく必要があります。HIDSアプリケーションでは、サポートされているHP-UXバージョンごとに固有のパッチが必要です。基本的な前提条件は、前述の「前提条件」を参照してください。
HIDSアプリケーションのディレクトリ構造は次のとおりです。
IDSアプリケーション・ファイル: /opt/ids
構成ファイル: /etc/opt/ids
ログ・ファイル: /var/opt/ids
各HP-UXバージョンのインストールおよび構成の手順は、HP.comのHIDSドキュメント、Host Intrusion Systemを参照してください。
インストールを開始する前に、前述の「前提条件」に記載されている必要なすべてのパッチがシステムにインストールされていることを確認します。hostnameはすべて、システム管理者から提供される実際のサーバーのホスト名で置き換える必要があります。
次の手順に従います。
コマンド・プロンプトでrootとしてログインします。
次のコマンドを入力します。
mkdir /var/depot [Enter]
mkdir /var/depot/ids_11.i_admin+agent [Enter]
mkdir /var/tmp/idspatch_11.i [Enter]
mkdir /var/tmp/idsprod [Enter]
次のパッチを/idspatch_11.iディレクトリにコピーします。
PHKL_34798 s700_800 11.23 HIDS累積パッチ（HPUX 11i v2）
パッチ・ファイル・セットをそれぞれ別の保管庫に解凍します。
sh -c 'for i in /var/tmp/idspatch_11.i/PH*; do sh $i; done'
次のコマンドを改行せずに入力し、パッチ保管庫をids_11.i_admin+agent保管庫にコピーします。
sh -c 'for i in /var/tmp/idspatch_11.i/PH*.depot; do swcopy -s $i \* @ /var/depot/ids_11.i_admin+agent; done'
11.i IDS製品保管庫を次のディレクトリにダウンロードします。
var/tmp/idsprod/J5083AA_11.i.depot
11.i製品全体をids_11.i_admin+agent保管庫にコピーします。
swcopy -s /var/tmp/idsprod/J5083AA_11.i.depot \* \@ /var/depot/ids_11.i_admin+agent
次のコマンドを入力してIDSソフトウェアをインストールします。インストール後にシステムを再起動する必要があることに注意してください。
# swinstall -x autoreboot=true -s hostname:/var/depot/ids_11.i_admin+agent \*
|
注意: IDSを起動するには、コマンド/sbin/init.d/idsagent startを実行します。
IDSを停止するには、コマンド |
ここでは、HIDSアプリケーションをサーバーにインストールした後で実行する必要がある手順を説明します。
システムが再起動したら、IDS_checkInstallスクリプトを実行してHIDSアプリケーションのインストールを確認します。
/opt/ids/bin/IDS_checkInstall
ユーザーidsとしてログインし、コマンド・プロンプトで次のように入力して管理者キーを生成します。
./IDS_genAdminKeys install
コマンド・プロンプトで次のように入力してエージェントのキーを生成します。
./IDS_genAgentCerts
キーを生成する対象のホストを指定するように求められたら、ホスト名を入力します。
キー・ファイルは、/var/opt/ids/tmp/hostname.tar.Zに生成されます。
次のコマンドを入力してエージェント・キーをインストールします。
./IDS_importAgentKeys /var/opt/ids/tmp/hostname.tar.Z hostname
次のコマンドを入力してエージェント・プログラムを起動します。
/opt/ids/bin/idsagent
HIDSログ・ファイルは急速にサイズが大きくなります。ただし、Configuration Change Consoleエージェントによって、ディスク領域を節約するためにログ・ファイルの切捨てが行われます。エージェントが実行していないときにログ・ファイルのファイル・サイズが増加しないようにするには、スクリプトを実行して定期的にHIDSログ・ファイルを切り捨てます。
ログ・ファイルを管理するサンプル・スクリプトを次に示します。環境に合せてこのスクリプトをカスタマイズすることをお薦めします。このスクリプトはcrontabから実行する必要があります。また、trunclog.shは実行可能ファイルであることが必要です。
trunclog.shファイルの内容の例:
#!/bin/sh
filesize=`/bin/ls -l /var/opt/ids/alert.log │ /bin/awk '{print $5}'`
if [ "$filesize" -gt "5000000" ]
then
rm /var/opt/ids/alert.log
fi
rm /var/opt/ids/ids_1*
crontabが1時間おきに実行されるように構成するサンプル・エントリです。< >内はtrunclog.shファイルの実際のパスで置き換えてください。
0 * * * * /<location of script>/trunclog.sh
.
ここでは、AIXエージェントをインストールするプロセスを説明します。AIXの旧バージョンではJava JVM1.5が使用可能でないため、現在のエージェントはAIX5.3のみをサポートします。
システム・パフォーマンスの向上のため、AIX 5.3エージェントをインストールする前にAIX 5.3 5300-08 Service Pack 5以上をインストールします。メンテナンス・パッケージはIBMから入手できます。
AIXエージェントのインストール、構成およびアンインストールの手順は、「UNIXエージェントのインストール」のコンソール・モードの説明を参照してください。
サービスの開始および停止には、コマンドラインで次のコマンドを実行します。AIXでは、前述の全般的なUNIXの項で説明している/etc/init.dフォルダは使用されません。
/usr/sbin/arprobe start
/usr/sbin/arprobe stop
AIX監査サブシステムを使用すると、管理者は、既存のセキュリティ・ポリシーに対する分析やセキュリティ違反の検出のために、ユーザーのログインやログアウトおよびファイルの変更といったセキュリティ関連の情報を記録できます。
監査の設定では、既存の監査構成ファイルを変更します。監査を設定するには、次のようにします。
rootユーザーとしてAIXマシンにログインします。
ターミナル・ウィンドウを開いて、ディレクトリを/etc/security/auditに変更します。
viでconfigファイルを開きます。
次のセクションを探して、ここに示す値を更新または追加します。
start:
binmode = off
streammode = on
…
classes:
…
filewatch = PROC_Create,PROC_Delete,FILE_Open,FILE_Write,FILE_Close,FILE_
Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Fchmod,FILE_Fchown,FS_
Chdir,FS_Fchdir,FS_Chroot,FS_Mkdir,FS_Rmdir,FILE_Symlink,FILE_Dupfd,FILE_
Mknod,FILE_Utimes
users:
root = filewatch
default = filewatch
|
注意: この場合、defaultはroot以外のすべてのユーザーを意味します。また、configファイルの最後の行は空白行にする必要があります。 |
変更を保存して、viを終了します。
同じディレクトリ（/etc/security/audit/）にあるファイルstreamcmdsをviで開きます。
このファイルのすべてのテキストを消去します。FileRunningエージェント・モジュールが直接監査リーダーとして機能するため、このファイルのデフォルト構成は不要です。このファイルの内容を消去すると、CPU使用率が低減し、監査パフォーマンスが全体的に向上します。
ファイルを保存し、viを終了します。
ターミナル・プロンプトで、次のコマンドを入力してシステム起動時に監査を初期化します。
mkitab "audit:2:once:/usr/sbin/audit start"
この項では、32ビットまたは64ビットPA-RISCプロセッサでのHP-UX 11.11サーバーへのエージェントのインストール手順について説明します。前提条件をよく読んで、インストールを開始する前に必要なソフトウェアおよびパッチを入手してください。
HP-UXエージェントは、ファイルとプロセスの変更、システム・リソースの使用率およびサーバー構成に関連するデータを収集して報告します。デフォルトでは、HP-UXプラットフォームのエージェントによってファイル変更に関連するユーザーが報告されることはありませんが、Intrusion Detection System（HIDS）アプリケーションがシステムにインストールされている場合は異なります。HIDSによって提供される監査機能により、ファイル変更とそれらの報告対象の変更に関連するユーザーが記録されます。
Configuration Change Consoleエージェントは、HIDS 2.x、3.xおよび4.xをサポートします。最新の4.xバージョンをインストールすることをお薦めします。
このドキュメントでは、『HP-UX HIDS System Administrator's Guide』のHIDSに関する項の基本的な情報を示します。
HIDS監査機能は、Configuration Change Consoleエージェントと連携して、ファイルの未認可アクセスに関連するユーザー名や、ファイルの追加、作成、変更、削除などのファイル・イベントのリストを提供します。HP-UXプラットフォームのエージェントによって、ファイル変更に関連するユーザーが報告されることはありません。ただし、Intrusion Detection System（HIDS）アプリケーションがシステムにインストールおよび構成されている場合は異なります。
HIDSアプリケーションは、エージェントをインストールする前にインストールしておく必要があります。HIDSアプリケーションでは、サポートされているHP-UXバージョンごとに固有のパッチが必要です。基本的な前提条件は、前述の「前提条件」を参照してください。HIDSアプリケーションのディレクトリ構造は次のとおりです。
IDSアプリケーション・ファイル: /opt/ids
構成ファイル: /etc/opt/ids
ログ・ファイル: /var/opt/ids
各HP-UXバージョンのインストールおよび構成の手順は、HP.comのHIDSドキュメント、Host Intrusion Systemを参照してください。
表10-5 HP Javaランタイムのパッチ
| パッチ | 説明 |
|---|---|
|
PHKL_25367 |
カーネル・スレッドの優先順位逆転の問題を解決します。 |
|
PHCO_25452 |
Javaアプリケーションの劣化を引き起こすlibcの問題を解決します。 |
|
PHKL_25614 |
Javaのパフォーマンスに影響するメモリーとスレッドのいくつかの問題を解決します。 |
|
PHKL_25728 |
多数のスレッドを含むJavaアプリケーションでのハングを解決します。 |
|
PHKL_25729 |
スレッドの取消を妨げるシグナルとスレッドの問題を解決します。 |
|
PHKL_25840 |
多数のスレッドを含むJavaアプリケーションでのスレッド・パフォーマンスの深刻な問題を解決します。 |
|
PHKL_25871 |
Solarisに類似した同時クローズのためのセマンティックをサポートします（kernel_dscrpt）。 |
|
PHKL_27091 |
多数のスレッドを含むJavaアプリケーションを劣化させるスレッドの問題を解決します。 |
|
PHKL_28489 |
fork()の後でハングを引き起こすカーネル・トラップ・ハンドラの問題を解決します。 |
|
PHNE_29887 |
Solarisに類似した同時クローズのためのセマンティックをサポートします（transport）。 |
|
PHCO_29960 |
ハングの原因となるpthreadの同期を解決します。このパッチはJREバージョン1.3.1.11以上にインストールする必要があります。 |
|
PHSS_30049 |
クラスServerSocketのネイティブ・ライブラリをロードする際のdldの問題を解決します。 |
インストールを開始する前に、前述の「前提条件」に記載されている必要なすべてのパッチがシステムにインストールされていることを確認します。hostnameはすべて、システム管理者から提供される実際のサーバーのホスト名で置き換える必要があります。
次の手順に従います。
コマンド・プロンプトでrootとしてログインします。
次のコマンドを入力します。
mkdir /var/depot [Enter]
mkdir /var/depot/ids_11.i_admin+agent [Enter]
mkdir /var/tmp/idspatch_11.i [Enter]
mkdir /var/tmp/idsprod [Enter]
次のパッチを/idspatch_11.iディレクトリにコピーします。
PHKL_26074 s700_800 11.11 libaudit.a累積パッチ
|
注意: HP-UX 11i v1.6および11i v2ではこのパッチは必要ありません。 |
パッチ・ファイル・セットをそれぞれ別の保管庫に解凍します。
sh -c 'for i in /var/tmp/idspatch_11.i/PH*; do sh $i; done'
次のコマンドを改行せずに入力し、パッチ保管庫をids_11.i_admin+agent保管庫にコピーします。
sh -c 'for i in /var/tmp/idspatch_11.i/PH*.depot; do swcopy -s $i \* @ /var/depot/ids_11.i_admin+agent; done'
11.i IDS製品保管庫を次のディレクトリにダウンロードします。
var/tmp/idsprod/J5083AA_11.i.depot
11.i製品全体をids_11.i_admin+agent保管庫にコピーします。
swcopy -s /var/tmp/idsprod/J5083AA_11.i.depot \* \@ /var/depot/ids_11.i_admin+agent
次のコマンドを入力してIDSソフトウェアをインストールします。インストール後にシステムを再起動する必要があることに注意してください。
# swinstall -x autoreboot=true -s hostname:/var/depot/ids_11.i_admin+agent \*
|
注意: IDSを起動するには、コマンド/sbin/init.d/idsagent startを実行します。
IDSを停止するには、コマンド |
ここでは、HIDSアプリケーションをサーバーにインストールした後で実行する必要がある手順を説明します。
システムが再起動したら、IDS_checkInstallスクリプトを実行してHIDSアプリケーションのインストールを確認します。
/opt/ids/bin/IDS_checkInstall
ユーザーidsとしてログインし、コマンド・プロンプトで次のように入力して管理者キーを生成します。
./IDS_genAdminKeys install
コマンド・プロンプトで次のように入力してエージェントのキーを生成します。
./IDS_genAgentCerts
キーを生成する対象のホストを指定するように求められたら、ホスト名を入力します。
キー・ファイルは、/var/opt/ids/tmp/hostname.tar.Zに生成されます。
次のコマンドを入力してエージェント・キーをインストールします。
./IDS_importAgentKeys /var/opt/ids/tmp/hostname.tar.Z hostname
次のコマンドを入力してエージェント・プログラムを起動します。
/opt/ids/bin/idsagent
HIDSログ・ファイルは急速にサイズが大きくなります。ただし、Configuration Change Consoleエージェントによって、ディスク領域を節約するためにログ・ファイルの切捨てが行われます。エージェントが実行していないときにログ・ファイルのファイル・サイズが増加しないようにするには、スクリプトを実行して定期的にHIDSログ・ファイルを切り捨てます。
ログ・ファイルを管理するサンプル・スクリプトを次に示します。環境に合せてこのスクリプトをカスタマイズすることをお薦めします。このスクリプトはcrontabから実行する必要があります。また、trunclog.shファイルは実行可能ファイルであることが必要です。
trunclog.shファイルの内容の例:
#!/bin/sh
filesize=`/bin/ls -l /var/opt/ids/alert.log │ /bin/awk '{print $5}'`
if [ "$filesize" -gt "5000000" ]
then
rm /var/opt/ids/alert.log
fi
rm /var/opt/ids/ids_1*
Sample entry to configure the crontab to run every hour:
0 * * * * /<location of script>/trunclog.sh
.
