形式 - マニュアルページセクション 5: 標準、環境、マクロ

ドキュメントの品質向上のためのご意見をください

Your rating has been updated

貴重なご意見を有り難うございました!

あなたの貴重なご意見はより良いドキュメント作成の手助けとなります内容の品質向上と追加コメントのためのアンケートに参加されますか？

audit_remote

- リモートサーバーへの Solaris 監査ログの送信

形式

/usr/lib/security/audit_remote.so

機能説明

Solaris 監査の audit_remote プラグインモジュール (/usr/lib/security/audit_remote.so) は、auditconfig(1M) で構成されたとおりに、バイナリ形式の監査レコード (audit.log(4)) を監査サーバーに送信します。

audit_remote プラグインが auditconfig によってアクティブとして構成されている場合は、auditd(1M) によってロードされます。プラグイン関連のすべての構成パラメータを変更するには、auditconfig -setplugin オプションを使用します。

audit_remote で送信されるバイナリ形式の監査レコードを受信するように、auditconfig を使用して Solaris 監査サービスデーモンの監査リモートサービス (ars(5)) が構成されている場合があります。

オブジェクト属性

次の属性は、audit_remote プラグインの構成を指定します:

p_hosts

host1[:[port1][:mech1]][,host2[:[port2][:mech2]],... \
    hostn[:[portn][:mechn]]]

監査ホストおよびサーバーのリストです。監査レコードは、最初に到達可能なホストに送信されます。ホストに到達できない場合や、データの送信中にタイムアウトが発生した場合は、リスト内の次のホストが試されます。すべてのホストへの接続に失敗した場合は、リストの先頭から再試行されます。

p_hosts エントリの host 部分は、getipnodebyname(3SOCKET) に受け入れられる任意の形式で指定できます。

p_hosts エントリの port 部分は、監査サーバー接続を開始するためにアクセスされるホスト上のポートです。指定しない場合は、solaris-audit サービスに割り当てられたポート番号になります。getservbyname(3XNET) を参照してください。

p_host エントリの mech 部分は GSS-API メカニズム名 (mech(4)) です。指定しない場合は、ローカルホストのデフォルトメカニズムが使用されます。推奨されるメカニズムは kerberos_v5 です。

p_retries

サーバーに接続してデータを送信する再試行の回数です。

デフォルト値は 3 です。

p_timeout

接続およびデータ送信がタイムアウトになるまでの秒数です。

デフォルト値は 5 秒です。

qsize

未処理の監査レコードが保持される最大数です。

デフォルト値は、カーネルキュー制御の高位境界値です。auditconfig(1M) を参照してください。

0 に設定した場合、デフォルト値はカーネルキュー制御の高位境界値になります。auditconfig(1M) を参照してください。

GSS SESSION

audit_remote plugin は、構成された監査サーバーを GSS-API (libgss(3LIB)) を使用して認証する TCP クライアントです。Binary Solaris Audit レコードは、gss_wrap(3GSS) でメッセージトークンが生成されるたびに、完全性と機密性が保護された状態で送信されます。

このプラグインは、適切なセキュリティーメカニズム (mech(4)) を使用して、監査サーバー (host:port:mech) への TCP接続を開始し、GSS のセキュリティーコンテキスト (gss_init_sec_context(3GSS)) を確立します。

ポートが指定されなかった場合は、TCP ポート番号を取得するためにサービス名 solaris-audit が検索されます。メカニズムが指定されなかった場合は、GSS_C_NO_OID が gss_init_sec_context(3GSS) の mech_type パラメータとして使用されるため、ベースとなる GSS-API ではローカルのデフォルトメカニズムが使用されます。

gss_init_sec_context(3GSS) では、イニシエータの資格ハンドルとして GSS_C_NO_CREDENTIAL が使用され、audit@<host_fqdn> 形式のターゲット名が使用されます。サーバーは gss_accept_sec_context(3GSS) を使用して、コンテキストの確立を完了することが想定されています。

セキュリティーコンテキストが確立されると、クライアント (audit_remote) は gss_wrap(3GSS) を呼び出し、転送済みのペイロードと監査レコードとの機密性を保ちます。サーバーは gss_unwrap(3GSS) を使用して、受信されたデータのラップを解除し、gss_get_mic(3GSS) を使用して、あとでメッセージ取得の肯定応答としてプラグインに返信される MIC (Message Integrity Code) を取得することが想定されています。

たとえば、kerberos_v5 メカニズムがクライアント上の GSS_API メカニズムとして構成され、どちらの側もこのメカニズムを使用することに同意している場合は、クライアント側が audit/<host_fqdn>@<REALM> 主体のセッションキーを Kerberos KDC/TGS から非対話形式で取得できる必要があります。同時に、監査サーバーアプリケーションを実行しているアイデンティティーは、keytab ファイル (krb5.conf(4)) に格納された audit/<host_fqdn>@<REALM> 主体に関連付けられた長期間のキーでセッションキーを復号化できる必要があります。

audit_remote プラグインは、p_hosts リスト内の 1 番目のサーバーへの接続を開始します。接続に失敗した場合、または p_timeout 秒以内に監査レコードの送信が応答しない場合は、p_retries 回の試行後に、プラグインは次のサーバーへの接続を試みます。最後のサーバーへの接続に失敗すると、プラグインはリストの最初のホストへの接続を再度試します。サーバーへの接続の試行が失敗するたびに、audit_warn(1M) が実行されるか、プラグインオプション audit_remote.so retry <count> <error> が付いたタイムアウトを送信します。<error> は接続 <host:port> <the network error> です。EPROTO ネットワークエラーは、クライアントプラグインがプロトコルバージョンのハンドシェイクに成功しなかったことを示します。

プロトコルの説明

すべてのプロトコルメッセージの先頭には、4 オクテットのサイズのデータが付加されています。このサイズは、ネットワークバイト順です。

このプロトコルではバージョンのネゴシエーションで始まり、GSS-API セキュリティーコンテキストトークンの交換が続きます。エラー発生時には、接続が閉じられます (オプションで出力トークンが送信されます)。

バージョンのネゴシエーションは、サポートされるバージョンをコンマ (,) で区切ったリストのオクテット配列を送信するプラグインを使用して、平文で実行されます。現在のバージョン番号は文字 01 です。受信側は受け入れたバージョンで応答することが想定されています (現在の場合は文字 01)。不一致はエラーとみなされ、接続が閉じられます。

プラグインで送信されるバージョンのオクテット配列と受信側で受け入れられるバージョン文字を互いに連結すると、GSS セキュリティーコンテキスト確立のチャネルバインディングのアプリケーションデータフィールドが形成されます。

<plugin version characters> || <server accepted version characters>
"||" represents concatenation

以降のトークンには、ネットワークバイトオーダーで並んだ 64 ビットのシーケンス番号と単一の監査レコード (audit.log(4)) が含まれます。クライアントは機密性保護ラップ (64 ビットのシーケンス番号 || 監査レコード) を使用します。

サーバーは、受信した 64 ビットのシーケンス番号、ラップされていない 64 ビットのシーケンス番号が付いた MIC トークン、および監査レコードによって、受領したことを肯定応答します (その後、データ損失の対応をします)。クライアント側の MIC 検証によって、監査レコードは解放できるが、再転送のために保存できないことが肯定応答されます。

64 bit sequence number || mic (64 bit sequence number || audit record)

セキュアなリモート監査クライアントとサーバー間の通信フロー:

1) Client <--> Server - TCP handshake

2) Client <--> Server - protocol version negotiation:
   a) Client  --> Server - send data size - uint32_t value (2)
   b) Client  --> Server - send clear text message of the versions
                           supported comma separated, e.g.,
                           "01,02,03" for versions 1 and 2 and 3.
                           The only version supported at present is
                           "01"
   c) Client <--  Server - send data size - uint32_t value (2)
   d) Client <--  Server - send clear text version selected
                           ("01")
   :no version match; close connection; try next host

3) Security context initiation:
   a) Client - Construct channel bindings:
         initiator address type (GSS_C_AF_NULLADDR)
         acceptor address type (GSS_C_AF_NULLADDR)
         application data value (4 octets  "0101")
   b) Client  --> Server - send token (data) size - uint32_t value
   c) Client  --> Server - GSS-API per-context token
   d) Client <--  Server - send token (data) size
   e) Client <--  Server - GSS-API per-context token
      :repeat a-e until security context is initialized; if unsuccessful,
      close connection; try next host

4) Client - transmit thread, when audit record to be sent:
   a) Client  --> Server - send data size
   b) Client  --> Server - GSS-API per-message token
                  wrap (sequence number || audit record)
      :repeat a-b while less than max (qsize) outstanding records

 5) Client - receive thread:
    a) Client <--  Server - receive data size - uint32_t value
    b) Client <--  Server - receive sequence number - uint64_t value
    c) Client <--  Server - receive MIC
    d) Client             - MIC verification - OK
    e) Client             - remove particular audit record
                            pointed by the sequence number from the
                            retransmit buffer
  :repeat a-e, on error close connection; try next host;
   retransmit unacknowledged audit records

6) Server - receive thread:
    a) Client  --> Server - receive data size
    b) Client  --> Server - GSS-API receive, uwrap, store
                   per-message token

7) Server - transmit thread:
    a) Server - MIC generation - message integrity code
                    mic (sequence number || audit record)
    b) Client <--  Server - send data size
    c) Client < -- Server - send sequence number
    d) Client <--  Server - send MIC

使用例

例 1 audit_remote.so のロードとリモート監査サーバーの指定

次の指令では、audit_remote.so がロードされ、監査レコードが送信されるリモート監査サーバーが指定されます。kerberos_v5 セキュリティーメカニズムは、サーバーとの通信時に使用されるように定義されています。

auditconfig -setplugin audit_remote active \
    "p_timeout=90;p_retries=2;
     p_hosts=eggplant.eng.sun.com::kerberos_v5,
     purple.ebay.sun.com:4592:kerberos_v5"

例 2 デフォルトのセキュリティーメカニズムの使用法の構成

次の例では、デフォルトのセキュリティーメカニズムの使用法の構成を示します。構成されたサーバーのいずれかのデフォルトポートの使用法も示します:

auditconfig -setplugin audit_remote active \
    "p_timeout=10;p_retries=2;
     p_hosts=jedger.eng.sun.com, jbadams.ebay.sun.com:4592"

例 3 内部プラグインのキューサイズの設定

特定の状況 (たとえば、サーバーとクライアント間の通信回線が低速になることに加えて、監査データトラフィック量が増加したり、バーストしたりする状況) では、audit_remote プラグインによってキューに入れられた未処理の監査レコードの数が、構成された最大数に到達する可能性があります。次の例では、キューサイズのパラメータを設定する方法を示します。

auditconfig -setplugin audit_remote "" 1000

属性

属性についての詳細は、attributes(5) を参照してください。

属性タイプ	属性値
MT レベル	MT-安全
インタフェースの安定性	下記を参照。

プラグイン構成パラメータは「確実」です。クライアント/サーバープロトコル (バージョン "01") は「契約済みプロジェクト非公開」です。監査レコードの形式と内容の安定性については、audit.log(4) を参照してください。

注意事項

audit_remote は、GSS-API (libgss(3LIB)) を使用して、リモート監査サービスに対する認証を行います。Kerberos などの gss 実装メカニズムで提供されるデフォルトの gss 資格情報が使用されます。

IANA で割り当てられた solaris-audit サービスポートは 16162 です。

ナビゲーションリンクをスキップ
印刷ビューの終了
	マニュアルページセクション 5: 標準、環境、マクロ Oracle Solaris 11.1 Information Library (日本語)