/
The Remote Control Interface

The Remote Control Interface

Owned by Steve Challans
Feb 20, 2019

The Remote Control Interface is accessible by entering http://localhost:6161 in the web browser as shown inFigure 1. The Remote Control Interface is turned on by default, and also password protected for security reasons. The default username and password are:
Username: snare Password: snare
NOTE: The default password is not encrypted in the configuration file. Ensure you change the default password immediately after installation as the new password will be encrypted for security purposes. Update the password via the Remote Control Configuration page.

{_}Figure 1: The Remote Control Interface-View Status_The Remote Control Interface provides a number of capabilities including:

  • Network Configuration
  • Remote Control Configuration
  • Objectives Configuration
  • Viewing Recent Events
  • Displaying User and Group metadata.


Network Configuration

To set the network configuration parameters, select the 'Network Configuration' link.
Figure 2: Configure the network settings
The configuration parameters available are as follows, as displayed inFigure 2:

  • Override detected hostname with: 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 can send audit events to one or more network destinations. 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.

Server Details: Enter a DNS name, or IP address for each planned destination.
Port: Select the port you would like Snare to use when sending events.
Protocol: Select the protocol you would like Snare to use when sending events, UDP,TCP,SSL. 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 Snare server. Note: A warning message will be given if the format selected does not match the normal format for a port.
Click Change Configuration to add another destination. Likewise, to remove a destination, then delete the entry in the Server Details and click Change Configuration.

  • File Output: Log events to a file. Please note the log files are to be managed, since Snare does not rotate the files. See Note.

FileName: Log the output to disk as well as the network to a path with appropriate permissions.
Format: Select the format for the file.
Click Change Configuration to add another entry for file output.
Note on Log Rotation: Depending on the Snare configuration the log file may be small or large. In any case it is normal housekeeping practice that loges either be rotated or archived. Depending on the site requirements, a rotation scheme that keeps old copies of the last 7 days may be sufficient. In this case, it may be sufficient to include a CRON job and use a program such as logrotate to ensure the current log file does not grow to an unmanageable size. Alternatively you may wish to archive all log files to backup media. This may be scheduled using CRON or undertaken manually. In either case, it's important to note that the audit daemon should restart so that it opens the new log file for writing the events.

  • Cache size: Allow Snare to store messages that could not be sent. Combined with the TCP or SSL 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 cached messages are first saved to disk and reloaded upon restart.
  • Use UTC time reporting: Enables UTC (Coordinated Universal Time) timestamp format for events instead of local machine time zone format.
  • 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.


To save and set changes to these settings, and to ensure the audit daemon has received the new configuration, perform the following:

  1. Click on Change Configuration to save any changes.
  2. Click on the Apply the Latest Audit Configuration menu item. There will be a quick notice that Snare is restarting as displayed below.

Remote Control Configuration

The Snare for Solaris agent can be controlled remotely by administrators, if required. Remote control is enabled by default. The remote control page is displayed in Figure 3.

Figure 3: Configure the Remote Control
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. It is recommended you use a strong complex password of at least 12 characters. The password is not encrypted when being transmitted via the http session, but is encrypted when stored in the snare.conf file.
  • 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. If the web server port conflicts with an established web server then this may be changed. However care should be taken to note the new server port, as it will need to be placed in the URL to access the Snare agent.

To save and set changes to these settings, and to ensure the audit daemon has received the new configuration, perform the following:

  1. Click on Change Configuration to save any changes.
  2. Click on the Apply the Latest Audit Configuration menu item.

To revert your changes to the last saved configuration click Reset Form.

Objectives configuration

Snare's ability to filter events 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. A number of default objectives are available with the agent to aid you with PCI compliance. See Figure 4.
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.
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 Configuration File Description, and is intended for users who have a very detailed knowledge of Solaris administration and security. It is NOT recommended for novice users.
Figure 4: Display the Set objectives

Event Objectives

From the Objectives Configuration page, select 'Add' to insert an objective or 'Modify' to edit an existing objective. You may also select 'Delete' to remove any existing objectives. Generally, the order of objectives is not important, though it is good practice to have any objectives with exclusions at the top of the list.

Figure 5: Adding/Modifying an Objective
The following parameters may be set as displayed inFigure 5:

  • 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. The following groups are provided to service the most common security tasks required by a system or security administrator and are grouped as follows:
  • Login/Logout events
  • Open a file/dir for reading only
  • Write or create a file or directory
  • Modify system, file or directory attributes
  • Remove a file or directory
  • Start or stop program execution
  • Change user or group identity
  • Establish an outgoing network connection
  • Any Event(s): any event that can be generated by the audit subsystem can be specified (comma separated).

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.
The following filters may then be applied to incoming audit events:

  • Event ID Search Term: If 'Any Event(s)' is selected as the high level event, then add a comma separated list of audit events to search for.
  • Select the General Match Type: The search criteria that Snare should use to include or exclude the general search term event.
  • General 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. Regular expressions may be used which are an advanced form of specifying filters. For example, a search term of: /etc/.* would match any event which mentions any file in /etc.

For example, '.[Pp]ass(word|wd).' would match the following:
/etc/passwd
/tmp/PasswordFile
but would not match
/etc/PASSWD/
/home/red/PaSsWoRd.txt
Regular expression exclusions for example, /etc/[(passwd)] would match the following:
/etc/shadow
/etc/group
/etc/PASSWD
but would not match
/etc/passwd
To search for socketcalls enter the regular expression of socket to monitor connects, accepts etc.

  • Select the User Match Type: The search criteria that Snare should use to include or exclude the user search term event.
  • User Search Term: A comma separated filter term containing 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. If no users are entered, all users are assumed to be audited. If the user exclusion function is selected, then Snare will only report users that DO NOT match the supplied list of users.
  • Identify the event types to be captured: Select the audit event types to capture, and includes Success Audit and Failure Audit.
  • Select the Alert Level: The criticality levels are Critical, Priority, Warning, Information and Clear. These security levels are provided to enable the Snare user to map audit events to their most pressing business security objectives.

To save and set changes to these settings, and to ensure the audit daemon has received the new configuration, perform the following:

  1. Click on Change Configuration to save any changes.
  2. Click on the Apply the Latest Audit Configuration menu item.

Display of Latest Events / Destination Status

A small rotating cache of audit events is kept by the Snare for Solaris web server. Clicking on the Latest Events menu item will display twenty of the most recent events as displayed in Figure 7.

Figure 7: Display the latest events
Additionally this page shows the status for each Destination that was configured for logging. An example of this destination status is: 10.1.1.30:6161 (TCP), status: CONNECTED This information can be used to help debug potential logging issues. The status can be explained as follows:

  • Host/Port: e.g.: 10.1.1.30:6161 The host ip/name and port that logs will be sent too.
  • Log destination Type: e.g.: TCP The protocol of the remote connection. Possible values are TCP, UDP, SSL or File
  • The current State of the connection: e.g.: 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(error) - 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(error) - 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 in progress
    • WRITING - Writing is occurring to a file
    • WRITE_FAILED - A write to file failed
    • CLOSED - A file has been closed


Retrieving User and Group Information

Snare has the ability to retrieve users, groups and group membership from accounts local to the host that is running the agent. In those cases where the primary authentication source is defined as a NIS+ domain or an LDAP directory, then the users, groups and group membership retrieved will be those defined in the remote domain.
Accessed from the menu items, selecting any of the items will then display the relevant details. For exampleFigure 8 displays the output of selecting 'Display a list of Users'. The output from these commands is designed with no HTML markup to assist automated services, such as the Snare Server, to interrogate the users, groups and groups membership.
The output shows a number of tab delimited entries per line. The entries may be interpreted as follows:
Username; UID; Description; Password Expired (token PASSWD_EXPIRED); Account Inactive (token ACCOUNT_INACTIVE); Account Expired (ACCOUNT_EXPIRED); Account Disabled (token ACCOUNT_DISABLED); Account Locked (token ACCOUNT_LOCKED); No Password (token NO_PASSWD).
The first three fields of Username, UID and Description will be displayed and tab delimited. The remaining tokens are only visible if they exist on a particular account.
Figure 8: Output of Display a list of Users_In the case of Groups and Group Membership, the attributes displayed are _Groupname, GID and Group Members. The remaining tokens are only visible if they exist on a particular account.