svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
audit_remote(7)
Standards, Environments, Macros, Character Sets, and miscellany
audit_remote(7)
NAME
audit_remote - send Solaris audit logs to a remote server
SYNOPSIS
/usr/lib/security/audit_remote.so
DESCRIPTION
The audit_remote plugin module for Solaris audit, /usr/lib/secu‐
rity/audit_remote.so, sends binary audit records (audit.log(5)) to
audit servers as they are configured with auditconfig(8).
The audit_remote plugin is loaded by auditd(8) if the plugin is config‐
ured as active via auditconfig. Use the auditconfig -setplugin option
to change all the plugin related configuration parameters.
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.
Object Attributes
The following attributes specify the configuration of audit_remote
plugin:
p_flags
The audit classes which are audited by the audit_remote plugin. The
syntax for specifying audit flags is defined in audit_flags(7). The
default value for p_flags in audit_remote is all.
p_hosts
host1[:[port1][:mech1]][,host2[:[port2][:mech2]],... \
hostn[:[portn][:mechn]]]
A list of audit hosts/servers. Audit records are sent to the first
available host. If a host is unreachable or a timeout occurs while
sending data, the next host in the list is tried. If connection to
all hosts fails, the list is tried again from the beginning.
The host part of a p_hosts entry can be in any form acceptable to
getipnodebyname(3C).
The port part of a p_hosts entry is the port on host that is con‐
tacted to initiate an audit server connection. If not specified,
the port number is that assigned to the solaris-audit service. See
getservbyname(3C).
The mech part of a p_host entry is the GSS-API mechanism name
(mech(5)). If not specified, the local host's default mechanism is
used. The recommended mechanism is kerberos_v5.
p_retries
The number of retries for connecting to and sending data to a
server.
The default value is 3.
p_timeout
The number of seconds in which a connection/sending data timeouts.
The default value is 5 seconds.
qsize
The maximum number of outstanding audit records to keep.
The default is the value of the kernel queue control high water
mark. See auditconfig(8).
If set to 0, the default value is the value of the kernel queue control
high water mark. See auditconfig(8).
GSS SESSION
The audit_remote plugin is a TCP client that authenticates configured
audit servers using the GSS-API (libgss). Binary Solaris Audit records
are sent with integrity and confidentiality protection as per-message
tokens generated by gss_wrap(3GSS).
The plugin initiates a TCP connection to an audit server
(host:port:mech) and establishes a GSS security context (with
gss_init_sec_context(3GSS)), with appropriate security mechanism
(mech(5)).
If no port is specified, the service name solaris-audit is looked up to
obtain a TCP port number. If no mechanism is specified, the
GSS_C_NO_OID is used as a mech_type parameter of gss_init_sec_con‐
text(3GSS), and causes the underlying GSS-API to use the local default
mechanism.
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>. The
server is expected to use gss_accept_sec_context(3GSS) to complete the
context establishment.
Once the security context is established, the client (audit_remote
plugin) calls gss_wrap(3GSS) to achieve the confidentiality of the
transferred payload - the audit records. The server is expected to use
gss_unwrap(3GSS) to unwrap the received data and gss_get_mic(3GSS) to
obtain the MIC (Message Integrity Code) to be later sent back to the
plugin as a message retrieval acknowledgment.
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 appli‐
cation 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.
The audit_remote plugin initiates a connection to first server in the
p_hosts list. If the connection fails or audit record sends are not
responded to in p_timeout seconds, after p_retries attempts the plugin
tries to connect to the next server. 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 con‐
nect 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>. An EPROTO network error indicates that the client
plugin did not get a successful protocol version handshake.
PROTOCOL DESCRIPTION
All protocol messages are preceded by the 4 octets of the size of the
data to follow. This size is in network byte order.
The protocol begins with version negotiation followed by a GSS-API
security context token exchange. On error the connection is closed (and
any output token optionally sent).
The version negotiation takes place in the clear with the plugin send‐
ing an octet array of the comma (,) separated list of versions sup‐
ported. The current version number is the characters 01. The receiver
is expected to respond with the version that they accept (in the cur‐
rent case that is the characters 01). A mismatch is considered an error
and the connection is closed.
The version octet array sent by the plugin and the version characters
accepted by the receiver are concatenated together to make up the
application data field of the channel bindings of the GSS security con‐
text establishment.
<plugin version characters> || <server accepted version characters>
"||" represents concatenation
Subsequent tokens contain a 64 bit sequence number in network byte
order and a single audit record (audit.log(5)); the client uses confi‐
dentiality protection. wrap (64 bit sequence number || audit record)
The server acknowledges the receipt (and is then responsible for any
data loss) with the received 64 bit sequence number and a MIC token of
the unwrapped 64 bit sequence number and audit record. MIC verification
on the client side acknowledges the audit record can be freed and not
saved for possible retransmission.
64 bit sequence number || mic (64 bit sequence number || audit record)
Secure remote audit client/server communication flow:
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
EXAMPLES
Example 1 Loading audit_remote.so and Specifying the Remote Audit
Servers
The following directives cause audit_remote.so to be loaded and specify
the remote audit servers to where the audit records are sent. The ker‐
beros_v5 security mechanism is defined to be used when communicating
with the servers.
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"
Example 2 Using the Default Security Mechanism
The following example shows the configuration using the default secu‐
rity 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"
Example 3 Internal plugin queue size settings
Certain conditions (for instance, high or bursty audit data traffic in
combination with slow communication lines between server and client)
may cause the number of outstanding audit records queued by the
audit_remote plugin to reach the maximum number configured. The follow‐
ing example shows how to set the queue size parameter.
auditconfig -setplugin audit_remote "" 1000
ATTRIBUTES
See attributes(7) for a description of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/library _ Interface StabilitySee
below.
The plugin configuration parameters are Committed. The client/server
protocol (version "01") is Contracted Project Private. See audit.log(5)
for the audit record format and content stability.
SEE ALSO
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
NOTES
audit_remote authenticates itself to the remote audit service by way of
GSS-API (libgss). Default gss credentials are used as provided by the
gss implementation mechanism, such as Kerberos.
The solaris-audit service port assigned by IANA is 16162.
Oracle Solaris 11.4 21 Jun 2021 audit_remote(7)