audit_remote man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]


       audit_remote - send Solaris audit logs to a remote server


       The  audit_remote  plugin  module  for  Solaris	audit,	/usr/lib/secu‐
       rity/, sends  binary  audit  records  (audit.log(4))  to
       audit servers specified in audit_control(4).

       The  audit_remote  plugin is loaded by auditd(1M) if audit_control con‐
       tains a plugin: specification of

   Object Attributes
       The following attributes	 specify  the  configuration  of  audit_remote


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

	   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

	   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

	   The mech part of a p_host  entry  is	 the  GSS-API  mechanism  name
	   (mech(4)).  If not specified, the local host's default mechanism is
	   used.  The recommended mechanism is kerberos_v5.


	   The number of retries for connecting	 to  and  sending  data	 to  a

	   The default value is 3.


	   The number of seconds in which a connection/sending data timeouts.

	   The default value is 5 seconds.


	   The maximum number of outstanding audit records to keep.

	   The	default	 is  the  value of the kernel queue control high water
	   mark. See auditconfig(1M).

       The audit_remote plugin is a TCP client that  authenticates  configured
       audit  servers  using  the GSS-API (libgss(3LIB)). 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

       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

       gss_init_sec_context(3GSS) uses GSS_C_NO_CREDENTIAL  as	the  initiator
       credential  handle  and a target name of the form audit@<ost_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(4)) 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(1M) is executed at every unsuccessful attempt to con‐
       nect  to	 the  server  or  send	timeout	 with the plugin option plugin 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.

       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(4)); 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
	    c) Client <--  Server - send data size - uint32_t value (2)
	    d) Client <--  Server - send clear text version selected
	    :no version match; close connection; try next host

	 3) Security context initiation:
	    a) Client - Construct channel bindings 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

       Example	1  Loading  and  Specifying  the Remote Audit

       The following directives cause 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.


       Example 2 Using the Configuration of Usage Default Security Mechanism

       The following example shows the configuration of usage of default secu‐
       rity mechanism. It also shows use of default port on one of the config‐
       ured servers:


       See attributes(5) for a description of the following attributes:

       │MT Level	    │ MT-Safe	      │
       │Interface Stability │ See below.      │

       The  plugin  configuration  parameters are Committed. The client/server
       protocol (version "01") is Contracted Project Private. See audit.log(4)
       for the audit record format and content stability.

       auditd(1M),  auditconfig(1M), audit_warn(1M), getipnodebyname(3SOCKET),
       getservbyname(3XNET), gss_accept_sec_context(3GSS),  gss_get_mic(3GSS),
       gss_init_sec_context(3GSS),	gss_wrap(3GSS),	     gss_unwrap(3GSS),
       libgss(3LIB),	libsocket(3LIB),    audit_control(4),	 audit.log(4),
       krb5.conf(4), mech(4), attributes(5), kerberos(5), tcp(7P)

       audit_remote authenticates itself to the remote audit service by way of
       GSS-API (libgss(3LIB)). 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.

				  Sep 8, 2009		       AUDIT_REMOTE(5)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net