Audit configuration

The Snare configuration is stored as /etc/security/snare.conf. This file contains all the details required by Snare to configure the audit subsystem to successfully execute. Failure to specify a correct configuration file will prevent Snare from running.
The configuration of /etc/security/snare.conf can either be changed directly, or by modifying the objectives via the web server embedded within Snare, i.e. Remote Control Interface. The most effective and simplest way to configure /etc/security/snare.conf is to use the Remote Control Interface. It operates completely in memory, and does not rely on any external files, other than the /etc/audit/snare.conf file. The Remote Control Interface component is turned on by default.
The Remote Control Interface provides a number of capabilities including:

• Network Configuration
• Remote Control Configuration
• Objectives Configuration
• Viewing Recent Events
• User and Group meta-data

Tip: Manual editing of the snare.conf configuration file is possible, but care should be taken to ensure that it conforms to the required format for the audit daemon. Also, any use of the Remote Control Interface to modify security objectives or selected events, may result in manual configuration file changes being overwritten. Details on the configuration file format can be viewed in Appendix A – Configuration File Description.

Network Configuration

The audit configuration parameters to use are found in the 'Network Configuration' link in the Remote Control Interface of the Snare for OSX agent, displayed in Figure 2.
The network configuration parameters available are as follows:

• Clientname: Can be used to override the name that is given to the host. Unless a different name is required to be sent in the processed event log record, leave this field blank. The default is to use the fully qualified name for the machine.
• Destination: Snare for OSX can send audit events to one or more network destinations. Enter a DNS name, or IP address for each planned destination. Snare can send data either to a Snare-compatible server, or a SYSLOG compatible destination. Please be aware that most SYSLOG servers are incompatible with the extremely high volumes of data Snare is capable of generating.

Port: Select the port when sending events. Snare Server users should only send events to port 6161 in native UDP or TCP, or 6163 for TLS/SSL. To send data via Syslog port 514 is recommended unless the destination is configured differently to receive on a non standard UDP port. Note: The agent will override the specified format in some cases. Specifying port 6161 will force the use of Snare format. Specifying a port of 514 will force the use of the Syslog format.
Protocol: Select the protocol you would like Snare to use when sending events. Using TCP or SSL will guarantee message delivery. Using SSL will use an encrypted connection to the server.
Format: Select this option if the requirement is that the event records need to be in a specific format. This feature will allow the event log record to be formatted so it is accepted by a SYSLOG or a Snare server.

• Destination FileName (optional): Output logging to disk as well as the network.
• Audit to STDOUT: This option is useful for debugging and allows audit events to be sent to STDOUT, useful if you run the snarecore binary manually from the console.
• Cache size: Allow Snare to store messages that could not be sent. Combined with the TCP, this option will allow the agent to cache messages if there is a network failure or the Snare Server is otherwise unavailable. Any cached message is kept until it is sent or the size of the cache exceeds the specified allotment, in which case the oldest message is removed. If the agent is restarted, any cached messages are lost.
• SYSLOG Facility (optional): If you are sending your data to a SYSLOG server, specifies the subsystem that produced the message. The list displays default facility levels.
• SYSLOG Priority (optional): If you are sending your data to a SYSLOG server, the agent can be configured to use a static or dynamic priority level.
• Use UTC time reporting: Enables UTC (Coordinated Universal Time) timestamp format for events instead of local machine time zone format.

Remote Control Configuration

The Snare for OSX agent can be controlled remotely by administrators, if required. Remote control is enabled by default, but can be disabled by modifying the file /etc/security/snare.conf as per instructions in section 4.1 of this guide. The remote control page is shown in Error: Reference source not found below.
The parameters which may be set for remote control operation include:

• Restrict remote control of SNARE agent to certain hosts: By default SNARE allows any IP address to connect to the remote control interface. Enabling this option restricts connections to the remote control interface to the ip given in the following option.
• IP Address allowed to remote control SNARE: Remote control actions may be limited to a given host. This host, entered as an IP address will only allow remote connections to be effected from the stated IP address. Application-level firewall capabilities are also available, which block users from accessing the Remote Control Interface from any IP address other than the one specified.
• Require a password for remote control?: Indicate whether a password will be set so that only authorised individuals may access the remote control functions. Highly recommended.
• Password to allow remote control of SNARE: If above checkbox is checked, password must be set. A password of appropriate strength should be set for the remote control facility.
• Web Server Port: An optional port that the Remote Control Interface listens on, can be specified. Users of the Snare Server should generally leave this as 6161, in order to take advantage of the Snare Server's user and group audit capabilities.

Objectives configuration

A major function of the Snare system is to filter events. This is accomplished via the auditing 'objectives' capability. The term 'objective' is used within Snare Agents to describe an 'auditing goal'. It is generally made up of events that Snare should watch for, a filter term containing a 'token' and a criticality level.

Event Objectives

The following parameters may be set on the Filtering Objective Configuration page as show in Figure 4:

• Identify the high level event: Each of the objectives provides a high level of control over which events are selected and reported. Events are selected from a group of high level requirements, and further refined using selected filters. Events are generally grouped into the following:
• User Logon or logoff: login, logout, telnet, rlogin, su, rexecd, passwd, rexd, ftpd, admin_authenticate, ssh
• Modify system, file or directory attributes: chmod, fchmod, chown, fchown, mctl, fcntl, lchown, aclset, faclset
• Change user or group identity: setgroups, setpgrp, setuid, setgid, setauid, setreuid, setregid, setuid, osetpgrp
• Open a file/dir for reading only: open_r, readlink
• Remove a file or directory: rmdir, unlink
• Establish an outgoing network connection: connect, shutdown, setsockopt
• Write or create a file or directory: open_rc, open_rt, open_w, open_wc, open_wtc, open_rw, open_rwt, create, mkdir,mknod,xmknod,link,symlink,rmdir,unlink,rename,truncate,ftruncate
• Start or stop program execution: exec,execve

In addition, any event that can be generated by the OSX audit subsystem can be specified (comma separated) by using the 'Any Event(s)' high level group.
Tip: Turning on file-related events can produce a very high volume of audit events on some systems, and therefore result in a considerable amount of CPU time being used by Snare and the audit subsystem.

• Event ID Search Term: If 'Any Event(s)' is selected as the high level event, then add a comma separated list of OSX audit events to search for.
• Search Term: A filter term containing a 'token' which appears within the events of interest, and the search criteria that Snare should use to include or exclude the event. For example, a search term of: /etc/.* Would match any event which mentions any file in /etc
• User Search Term: A filter term containing a users the objective should match. For example using: root,snare would cause the objective to match if users root or snare caused the event. Additionally the value .* may be used to match any user.
• Identify the event types to be captured: Select from Success Audit or Failure Audit.
• Select the Alert Level: A criticality level may be assigned to enable the Snare user to designate events to their most pressing business security objectives, and to quickly identify the level of importance.

The order of the objectives is not important. Once the above settings have been finalized, the configuration may be saved to the configuration file, via the Change Configuration button. However, to ensure the audit daemon has received the new configuration, the Apply the Latest Audit Configuration menu item should be selected.
The objective configuration page supplied as part of the web based remote control is intended as a way to enable users to commence audit functions reasonably quickly. It is not intended for power users. A far more powerful and functional way is to manually control the /etc/security/snare.conf file. This is described in more detail in Appendix A, and is intended for users who have a very detailed knowledge of OSX administration and security. It is NOT recommended for novice users.

Display of Latest Events / Destination Status

A small rotating cache of audit events is kept by the Snare for OSX web server. Clicking on the Latest Events menu item will display twenty of the most recent events.

Additionally this page shows the status for each Destination that was configured for logging. An example of this destination status is:
TCPDestination: 10.1.1.30:6161:CONNECTED:Available:1:ReadyToSend:1
This information can be used to help debug potential logging issues. The status can be explained as follows:

• Log destination Type: ie: TCPDestination The protocol of the remote connection. Possible values are TCPDestination, UDPDestination, SSLDestination or FileDestination
• Host/Port: ie: 10.1.1.30:6161 The host ip/name and port that logs will be sent too.
• The current State of the connection: ie: CONNECTED This field indicates what snare is currently doing with the connection. You will see many different states including:
  • INITIAL The remote log location is about to begin setup
  • RESOLVING DNS resolution for a hostname is occurring
  • RESOLVE_DELAY DNS resolution failed, a retry will occur in X seconds
  • CONNECTING Snare is trying to connect to the destination
  • CONNECT_FAILED The connection to the destination failed
  • CONNECT_DELAY Connecting to the remote end failed, it will be retried again in X seconds
  • CONNECTED Snare has an active connection to the destination
  • SENDING Snare is currently sending logs to the destination
  • DISCONNECTED The destination has disconnected the snare agent.. a reconnection will occur automatically.
  • HANDSHAKE A SSL/TLS Handshake is in progress
  • HANDSHAKE_FAILED The SSL/TLS Handshake failed
  • OPENING Opening a a file destination is inprogress
  • WRITING Writing is occurring to a file
  • WRITE_FAILED A write to file failed
  • CLOSED A file has been closed

Additionally two other statuses give instant feedback about what Snare's status is:

• Available
  • Indicates if Snare can use the destination to send logs. A value of 1 indicates that logs can be sent. A value of 0 indicates logs can't be sent
• ReadyToSend
  • Indicates if the destination is setup in a state where logs can be sent. For instance if Snare is already sending to the destination, ReadyToSend will be 0.