Go to main content

Managing Auditing in Oracle® Solaris 11.3

Exit Print View

Updated: December 2018
 
 

How to Configure a Remote Repository for Audit Files

In this procedure, you configure a remote system, the Audit Remote Server (ARS), to receive and store audit records from one or more audited systems. Then, you activate the audit daemon on the remote server.

The configuration is twofold. First, you configure the underlying security mechanisms to securely transport the audit data, that is, you configure the KDC. Second, you configure the audit service on both the audited system and the ARS. This procedure illustrates a scenario with one audited client and one ARS, where the ARS and the KDC are on the same server. More complex scenarios can be configured similarly. The first four steps describe the configuration of the KDC, while the final step describes the configuration of the audit service.

Before You Begin

Ensure that you have completed the following:

  1. If your site has not yet configured a KDC, configure one.

    You need a KDC on a system that both the audited system and the ARS can use, a host principal for each system, and an audit service principal. The following example illustrates a KDC configuration strategy:

    arstore # kdcmgr -a audr/admin -r EXAMPLE.COM create master
    

    This command uses the administrative principal audr/admin to create a master KDC in the EXAMPLE.COM realm, enables the master KDC, and starts the Kerberos service.

  2. Verify that the KDC is available.

    For more information, see the kdcmgr(1M) man page.

    # kdcmgr status
    
    KDC Status Information
    --------------------------------------------
    svc:/network/security/krb5kdc:default (Kerberos key distribution center)
    State: online since Wed Feb 29 01:59:27 2012
    See: man -M /usr/share/man -s 1M krb5kdc
    See: /var/svc/log/network-security-krb5kdc:default.log
    Impact: None.
    
    KDC Master Status Information
    --------------------------------------------
    svc:/network/security/kadmin:default (Kerberos administration daemon)
    State: online since Wed Feb 29 01:59:28 2012
    See: man -M /usr/share/man -s 1M kadmind
    See: /var/svc/log/network-security-kadmin:default.log
    Impact: None.
    
    Transaction Log Information
    --------------------------------------------
    
    Kerberos update log (/var/krb5/principal.ulog)
    Update log dump :
    Log version # : 1
    Log state : Stable
    Entry block size : 2048
    Number of entries : 13
    First serial # : 1
    Last serial # : 13
    First time stamp : Wed Feb 29 01:59:27 2012
    Last time stamp : Mon Mar 5 19:29:28 2012
    
    
    Kerberos Related File Information
    --------------------------------------------
    (Displays any missing files)
  3. Add the audit service principal to the KDC keytab file.

    You can add the principal by typing the kadmin.local command on the KDC system. Or, you can remotely add the principal by using the kadmin command and providing a password. In this example, the arstore system is running the KDC.

    # kadmin -p audr/admin
    
    kadmin: addprinc -randkey audit/arstore.example.com@EXAMPLE.COM
    
    kadmin: ktadd audit/arstore.example.com@EXAMPLE.COM
    
  4. On each audited system, add keys.

    The receiver and the sender must have keys.

    enigma # kclient
    
    .. Enter the Kerberos realm: 
    EXAMPLE.COM
    
    .. KDC hostname for the above realm: 
    arstore.example.com
    
    .. Will this client need service keys ? [y/n]: 
    y
    
  5. Configure the audit service on the ARS.
    • Create and name a connection group that accepts audit records from any audited system in the Kerberos realm.
      # auditconfig -setremote group create Bank_A
      

      Bank_A is a connection group. Because the hosts attribute is not defined, this group accepts all connections, which means that it is a wildcard group. Any audited system in this Kerberos realm whose audit_remote plugin is correctly configured can reach this ARS.

    • To limit connections to this group, specify the audited systems that can use this repository.
      # auditconfig -setremote group Bank_A "hosts=enigma.example.com"
      

      Connection group Bank_A now accepts only connections from the enigma system. A connection from any other host is refused.

    • To prevent an audit file in this group from growing too large, set a maximum size.
      # auditconfig -setremote group Bank_A "binfile_fsize=4GB"
      
      # auditconfig -getremote
      Audit Remote Server
      Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0;
      Connection group: Bank_A (inactive)
      Attributes: binfile_dir=/var/audit;binfile_fsize=4GB;binfile_minfree=1;
      hosts=enigma.example.com;
  6. Configure the audit service on the audited system.

    To specify the ARS, use the p_hosts attribute.

    enigma # auditconfig -setplugin audit_remote \
         active p_hosts=arstore.example.com
    
    enigma # auditconfig -getplugin audit_remote
    Plugin: audit_remote
    Attributes: p_retries=3;p_timeout=5;p_hosts=arstore.example.com;
  7. Refresh the audit service.

    The audit service reads the audit plugin change upon refresh.

    # audit -s

    The KDC now manages the connection between the audited system enigma and the ARS.

Example 27  Streaming Audit Records to Different File Locations on the Same ARS

This example extends the example in the procedure. The administrator separates audit records by host on the ARS by creating two connection groups.

Audit files from audsys1 stream to the Bank_A connection group on this ARS.

arstore # auditconfig -setremote group create Bank_A

arstore # auditconfig -setremote group active Bank_A "hosts=audsys1" \
   "hosts=audsys1;binfile_dir=/var/audit/audsys1;binfile_fsize=4M;"

Audit files from audsys2 stream to the Bank_B connection group.

arstore # auditconfig -setremote group create Bank_B

arstore # auditconfig -setremote group active Bank_B \
"hosts=audsys2;binfile_dir=/var/audit/audsys2;binfile_fsize=4M;"

For easier maintenance, the administrator sets other attribute values identically.

arstore # auditconfig -getremote
Audit Remote Server
Attributes: listen_address=;login_grace_time=30;max_startups=10;listen_port=0;

Connection group: Bank_A
Attributes: binfile_dir=/var/audit/audsys1;binfile_fsize=4M;binfile_minfree=1;
hosts=audsys1

Connection group: Bank_B
Attributes: binfile_dir=/var/audit/audsys2;binfile_fsize=4M;binfile_minfree=1;
hosts=audsys2
Example 28  Placing the ARS on a Different System From the KDC

In this example, the administrator places the ARS on a different system from the KDC. First, the administrator creates and configures the master KDC.

kserv # kdcmgr -a audr/admin -r EXAMPLE.COM create master

kserv # kadmin.local -p audr/admin

kadmin: addprinc -randkey \
audit/arstore.example.com@EXAMPLE.COM

kadmin: ktadd -k /var/user/root/krb5.keytab.audit \
     audit/arstore.example.com@EXAMPLE.COM

After securely transmitting the /tmp/krb5.keytab.audit file to the ARS, arstore, the administrator moves the file to the correct location.

arstore # chown root:root krb5.keytab.audit

arstore # chmod 600 krb5.keytab.audit

arstore # mv krb5.keytab.audit /etc/krb5/krb5.keytab

Rather than rewrite the file, the administrator also has the option to use the ktutil command on the ARS to merge the KDC krb5.keytab.audit file with existing keys in the arstore 's /etc/krb5/krb5.keytab file.

Finally, the administrator generates keys on the audited system.

enigma # kclient

.. Enter the Kerberos realm: EXAMPLE.COM

.. KDC hostname for the above realm: kserv.example.com

.. Will this client need service keys ? [y/n]: y