audit_remote - リモートサーバーへの Solaris 監査ログの送信
/usr/lib/security/audit_remote.so
Solaris 監査のための audit_remote プラグインモジュール (/usr/lib/security/audit_remote.so) は、auditconfig(8) で構成されているとおりにバイナリ監査レコード (audit.log(5)) を監査サーバーに送信します。
The audit_remote plugin is loaded by auditd(8) if the plugin is configured as active via auditconfig.プラグイン関連のすべての構成パラメータを変更するには、auditconfig –setplugin オプションを使用します。
The Solaris audit service daemon's audit remote service, ars(7), may be configured with auditconfig to receive the binary audit records sent by audit_remote.
次の属性は、audit_remote プラグインの構成を指定します:
audit_remote プラグインによって監査される監査クラス。監査フラグを指定するための構文は、audit_flags(7) に定義されています。The default value for p_flags in audit_remote is all.
host1[:[port1][:mech1]][,host2[:[port2][:mech2]],... \
hostn[:[portn][:mechn]]]
監査ホストおよびサーバーのリストです。監査レコードは、最初に到達可能なホストに送信されます。ホストに到達できない場合や、データの送信中にタイムアウトが発生した場合は、リスト内の次のホストが試されます。すべてのホストへの接続に失敗した場合は、リストの先頭から再試行されます。
p_hosts エントリの host 部分は、getipnodebyname(3C) に受け入れられる任意の形式で指定できます。
p_hosts エントリの port 部分は、監査サーバー接続を開始するためにアクセスされるホスト上のポートです。指定しない場合は、solaris-audit サービスに割り当てられたポート番号になります。See getservbyname(3C).
p_host エントリの mech 部分は GSS-API メカニズム名 (mech(5)) です。指定しない場合は、ローカルホストのデフォルトメカニズムが使用されます。推奨されるメカニズムは kerberos_v5 です。
サーバーに接続してデータを送信する再試行の回数です。
デフォルト値は 3 です。
接続およびデータ送信がタイムアウトになるまでの秒数です。
デフォルト値は 5 秒です。
未処理の監査レコードが保持される最大数です。
デフォルト値は、カーネルキュー制御の高位境界値です。See auditconfig(8).
0 に設定した場合、デフォルト値はカーネルキュー制御の高位境界値になります。See auditconfig(8).
audit_remote プラグインは、構成された監査サーバーを GSS-API (libgss) を使用して認証する TCP クライアントです。Binary Solaris Audit レコードは、gss_wrap(3GSS) でメッセージトークンが生成されるたびに、完全性と機密性が保護された状態で送信されます。
このプラグインは、適切なセキュリティーメカニズム (mech(5)) を使用して、監査サーバー (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) uses GSS_C_NO_CREDENTIAL as the initiator credential handle and a target name of the form audit@<host_fqdn>.サーバーは gss_accept_sec_context(3GSS) を使用して、コンテキストの確立を完了することが想定されています。
セキュリティーコンテキストが確立されると、クライアント (audit_remote) は gss_wrap(3GSS) を呼び出し、転送済みのペイロードと監査レコードとの機密性を保ちます。サーバーは gss_unwrap(3GSS) を使用して、受信されたデータのラップを解除し、gss_get_mic(3GSS) を使用して、あとでメッセージ取得の肯定応答としてプラグインに返信される MIC (Message Integrity Code) を取得することが想定されています。
For example, if the kerberos_v5 mechanism is configured as GSS_API mechanism on the client and both sides agree on using this mechanism, the client side has to be eligible to non-interactively gain session keys for the audit/<host_fqdn>@<REALM> principal from the Kerberos KDC/TGS.At the same time the identity running the audit server application has to have the long term keys associated with the audit/<host_fqdn>@<REALM> principal stored in the keytab file (krb5.conf) to be able to decrypt the session keys.
audit_remote プラグインは、p_hosts リスト内の 1 番目のサーバーへの接続を開始します。接続に失敗した場合、または p_timeout 秒以内に監査レコードの送信が応答しない場合は、p_retries 回の試行後に、プラグインは次のサーバーへの接続を試みます。If the connection to the last server fails, the plugin retries to connect to the first host in the list. audit_warn(8) is executed at every unsuccessful attempt to connect to the server or send timeout with the plugin option plugin audit_remote.so retry <count> <error>.<error> is connection <host:port> <the network error>.EPROTO ネットワークエラーは、クライアントプラグインがプロトコルバージョンのハンドシェイクに成功しなかったことを示します。
すべてのプロトコルメッセージの先頭には、4 オクテットのサイズのデータが付加されています。このサイズは、ネットワークバイト順です。
このプロトコルではバージョンのネゴシエーションで始まり、GSS-API セキュリティーコンテキストトークンの交換が続きます。エラー発生時には、接続が閉じられます (オプションで出力トークンが送信されます)。
バージョンのネゴシエーションは、サポートされるバージョンをコンマ (,) で区切ったリストのオクテット配列を送信するプラグインを使用して、平文で実行されます。現在のバージョン番号は文字 01 です。受信側は受け入れたバージョンで応答することが想定されています (現在の場合は文字 01)。不一致はエラーとみなされ、接続が閉じられます。
プラグインで送信されるバージョンのオクテット配列と受信側で受け入れられるバージョン文字を互いに連結すると、GSS セキュリティーコンテキスト確立のチャネルバインディングのアプリケーションデータフィールドが形成されます。
<plugin version characters> || <server accepted version characters> "||" represents concatenation
以降のトークンには、ネットワークバイトオーダーで並んだ 64 ビットのシーケンス番号と単一の監査レコード (audit.log(5)) が含まれます。クライアントは機密性保護ラップ (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
次の指令では、audit_remote.so がロードされ、監査レコードが送信されるリモート監査サーバーが指定されます。kerberos_v5 セキュリティーメカニズムは、サーバーとの通信時に使用されるように定義されています。
auditconfig -setplugin audit_remote active \
"p_timeout=90;p_retries=2;
p_hosts=eggplant.eng.example.com::kerberos_v5,
purple.ebay.example.com:4592:kerberos_v5"
使用例 2 Using the Default Security Mechanism
The following example shows the configuration using the default security mechanism.It also shows use of the default port on one of the configured servers:
auditconfig -setplugin audit_remote active \
"p_timeout=10;p_retries=2;
p_hosts=jedger.eng.example.com, jbadams.ebay.example.com:4592"
使用例 3 内部プラグインのキューサイズの設定
特定の状況 (たとえば、サーバーとクライアント間の通信回線が低速になることに加えて、監査データトラフィック量が増加したり、バーストしたりする状況) では、audit_remote プラグインによってキューに入れられた未処理の監査レコードの数が、構成された最大数に到達する可能性があります。次の例では、キューサイズのパラメータを設定する方法を示します。
auditconfig -setplugin audit_remote "" 1000
属性についての詳細は、attributes(7) を参照してください。
|
プラグイン構成パラメータは「確実」です。クライアント/サーバープロトコル (バージョン "01") は「契約済みプロジェクト非公開」です。監査レコードの形式と内容の安定性については、audit.log(5) を参照してください。
getipnodebyname(3C), getservbyname(3C), gss_accept_sec_context(3GSS), gss_get_mic(3GSS), gss_init_sec_context(3GSS), gss_unwrap(3GSS), gss_wrap(3GSS), libgss(3LIB), tcp(4P), audit.log(5), mech(5), ars(7), attributes(7), audit_warn(8), auditconfig(8), auditd(8)
Managing Auditing in Oracle Solaris 11.4
audit_remote authenticates itself to the remote audit service by way of GSS-API (libgss).Kerberos などの gss 実装メカニズムで提供されるデフォルトの gss 資格情報が使用されます。
IANA で割り当てられた solaris-audit サービスポートは 16162 です。