Configuration Wizard

Welcome to the Snare Wizard

The welcome screen will provide you with a general introduction to the Snare Central Wizard, and will highlight any particular information that you should have on hand before continuing.  Click on the Next button.

Organisation

• Enter your organisation name.
• If you wish the login page of Snare Central to display a custom title or notification/warning message, you may enter your custom title or message here.
• Click on the Next button.

Date and Time

• It is recommended that Network Time Protocol be used on Snare Central to provide a reasonable likelihood that the system date/time is less susceptible to hardware clock drift. Snare Central will utilise the NTP server (IP address or DNS name) as a source for time information. If your organisation does not have an NTP server available on the local network, you may wish to choose a server from the list available from http://www.pool.ntp.org/
• Click on the Time Zone input box to select the location where Snare Central is installed.
• Select the day preferences for the weekly tasks.

Network Services

• Select the preferred Snare Central Login mode.

Use HTTPS to force secure web access for Snare Central logins.

• Enter the FQDN (Fully Qualified Domain Name)/DNS name for Snare Central. This name is inserted into web addresses when electronic mails are sent out from Snare Central. As such, users will be able to click a link within their electronic mail message, and can be taken to Snare Central. You should ensure that the name input here matches the name assigned to this server in your Domain Name Server.

The domain name you enter, is used to generate a self-signed SSL certificate. If you have manually installed a certificate from a formal certificate registry, it is recommended that you choose the 'Do NOT regenerate' certificate option, or your existing certificate will be overwritten.

Installation of a custom certificate is covered in the section on 'Expert Configuration' within this guide.

Note that on the first run of the wizard after installation of Snare Central, regardless of the state of the 'Do NOT regenerate' option, the wizard will upgrade the default 1024-bit certificate, with a more robust 2048 bit version at the conclusion of this step.

• Enable or disable the SSH daemon,  FTP daemon or NFS services.
• Enable or disable Samba or SMB (Windows Share) access to the main Snare data store.

The Snare data store is where the event logs are stored in compressed form. This area can be accessed as a read only windows share, via userid/password authentication.

Set a password that your remote Windows machine needs to use, to connect to Snare Central. This will share out the Snare Archive directory in read-only format.

The username is always 'snarearch'.

The Windows share to Snare archive directory can then be accessed from your windows machine (or NAS box) as \\snare_server_IP_or_DNS\SnareArchive. For example, \\10.2.3.4\SnareArchive.

The PDF archive directory may be shared if selected, and is where the objective PDF output files are stored. The PDF archive share can then be accessed from your windows machine (or NAS box) as \\snare_server_IP_or_DNS\PDFArchive. For example, \\10.2.3.4\PDFArchive.

• Click on the Next button.

Security Setup

• HTTPS/TLS Version Support

  • Disable TLSv1.2 - Checking this option will disable TLSv1.2 support. TLSv1.3 is always enabled. TLSv1.3 is more secure than TLSv1.2, however older browsers don't support it. It is recommended to check this option if possible.

    • Restarting Apache server is mandatory for changes to take effect.

  • Anything less than TLS 1.2 is disabled by default.
• Additional login Controls: Enable or disable the enhanced password security functionality for the operating-system-level accounts that are installed by default by Snare Central.

Snare Central enables password complexity controls like account lockout (30 minutes after 5 failed password attempts), and password history checks on the User Interface users only.

Operating system accounts are excluded from the more stringent requirements of an organisational security policy; particularly the requirement for password rotation.

These accounts are generally used for either system administration or automated log transfers, and may not fit in with password rotation policies.

Enhanced security and forced rotation can be enabled, or disabled via this setting, if required.

Note that if LDAP/AD authentication is enabled, these settings do not apply to the Snare Central user interface - controls supplied by the authentication provider, will take priority.

• User Interface Password Control: Enable or disable enhanced password expiry in Snare Central.
• Password Security Controls: PCI, and related regulatory compliance compatible password controls can be enforced by turning on this setting.
• Auto Logout Controls: Enable or Disable Auto Logout time for Snare sessions.

By default http sessions will expire after approximately two hours of inactivity. If organisation security controls require a smaller session duration, this control allows you to specify the default (system wide) setting in minutes. A maximum of 120 minutes (2 hours) can be entered. A value of 0 disables Auto Logout.  Per-user session expiry settings are also available in the User Administration objective

• General Security Controls: Some security vulnerability scanners identify links to 'external sites' as reportable vulnerabilities. The Block external links from being clickable, when displayed by Snare setting turns off clickable links in the external link redirect page.

• Enable Security Technical Implementation Guide (STIG) compliance: , to comply with STIG recommendations for the Unix operating system ( https://www.stigviewer.com/stig/unix_srg/ ).

The Snare Linux Agent is automatically installed when the Enable STIG Compliance for Snare Central checkbox is selected. When active, the Snare Linux Agent web user interface (UI) can be accessed by configuring the Snare Central firewall to allow port 6112/TCP. Navigate to Configuration Wizard | Firewall Setup and add the port to the Active Rules if you wish to access the Agent's UI from a workstation on your local network. Note that once the Agent's UI has been made accessible, it is recommended you enable the remote control password on the Linux Agent Access Configuration page and supply a new password.

The Agent audits the following criteria as recommended by STIG (Unix):
V-819 all discretionary access control permission modifications.
V-818 login, logout, and session initiation.
V-816 all administrative, privileged, and security actions.
V-815 file deletions.
V-814 failed attempts to access files and programs.
V-22383 the loading and unloading of dynamic kernel modules.
V-22376 account creation.
V-22377 account modification.
V-22378 account disabling.
V-22382 account termination.

Events are sent via TCP to port 6161 of the local Snare Server with the Log Type "LinuxAudit". The configuration file for the Linux agent is located at /etc/audit/snare.conf.
If the Enable STIG Compliance for Snare Central checkbox is subsequently unchecked, then the Snare Linux Agent is also uninstalled from the system.

Note that enabling STIG compliance may actually reduce the effective security of some aspects of the operating system, by overriding some stricter CIS security controls that are applied by default.

• Click on the Next button.

Identity and Access Management Setup

Starting from version 8.6.0, Snare Central has the capacity to delegate user authentication and authorisation to a third party IAM (Identity and Access Management) service.

By integrating Snare Central with an IAM service, it is possible to streamline the management of user identities, access controls, and security policies within the organisation and provide Single Sign On (SSO) and Multi Factor Authentication (MFA) capabilities to Snare Central

This section of the Configuration Wizard allows to add and configure an IAM service provider into the system and enable SSO and group based authorisation.

Depending on each provider, a set of credentials from your IAM service provider are required. These credentials can include parameters such as API key, client ID, and client secret. These details are necessary for configuring Snare Central to work seamlessly with an IAM service.

Once the IAM service provider has been configured, the Administrator needs to retrieve the groups defined with in the provider that will have access to Snare Central.

For Snare Central to be able to retrieve IAM provider define groups, such groups names shall be prefixed with the “Default Group Prefix” (the default is “Snare_Central.”). This prefix will be used to search for Snare related groups with the IAM service provider and can be customised if needed.

As a general description, the process to configure IAM support for Snare Central involves the following steps:

1. Configure a new Integration for Snare Central in the providers portal. Depending of the provider this may require administrative rights with in the IAM service provider.

2. Configure the Sign-In redirect URL in the providers portal. This URL is provided in the “Sign-In redirect URL” field in this section of the Configuration Wizard.

3. Configure the groups that will have access to Snare Central in the providers portal. The name of the groups must start with the “Default Group Prefix” show in this section of the Configuration Wizard.

4. Once the new integration has been created in the providers portal, get the required credentials. In the case of Okta these credentials include: Domain, Client ID, Client Secret and API Token

5. With the above credentials, add a new IAM Service Provider by clicking the Add button.

6. Retrieve the groups from the provider by clicking the “Retrieve Groups” button.

7. Once the groups have been obtained from the provider, the Administrator needs to grant them permissions in the “Manage Access Control” tool.

8. Logout from Snare Central and a new “LOGIN WITH” button will be available in the login page for users defined in the IAM provider.

LDAP Setup

Snare is capable of delegating authentication to an external LDAP Directory or Active Directory server.

• Enter the IP address (or DNS name, as long as Snare Central has been configured to use your local DNS) of your target LDAP or Active Directory server.
• When the LDAP Groups option is disabled, the user must still have an account on the Snare Server with the same name as the LDAP/AD user, in order to log in. However this requirement is overridden when the LDAP Groups option is enabled.
• If specified, the Domain will be added to the end of the username for authentication purposes. A Test button is available to verify the LDAP setup values.
• There is a known issue when trying to bind Snare Server to an Microsoft Active Directory using LDAPS on a Windows Server 2012 R2. OpenLDAP’s GnuTLS and Microsoft’s SChannel implementations are not compatible with TLS 1.2 negotiation during AD/LDAPS binding. If you need to use a Windows Server 2012 R2 AD, enable the “Compatibility mode for Win Server 2012 R2” setting to force Snare Central to use to a lower TLS version specifically for active directory authentication.
• The LDAP Groups control enables the authorisation of groups defined in the AD server for Snare. Please note that when LDAP Groups option is enabled, all local accounts are temporarily disabled with the exception of the ADMINISTRATOR account. As per Snare Server v8.4.3 support for both kinds of users simultaneously is not supported.
• When the LDAP Groups option is enabled the first time, Snare Server needs to retrieve groups information from the LDAP or AD server. This can be done specifying a valid user and password with enough access rights to retrieve this information. Please note that neither user name or password will be stored by Snare.
• Once Snare Central is aware of existing groups, it is possible to manage Objectives access rights from the System | Administrative Tools | Manage Access Control configuration objective.

Firewall Setup

• Enable or disable the Basic Snare Firewall, which uses the UFW firewall to configure IPTables. For normal Snare Central operation, the firewall should be left enabled; it will only block those ports that do not have an associated snare-related service active.

  • When the Snare Firewall checkbox is enabled, the currently active firewall rules will be shown in the Active Rules section, and the Backup & Restore section is available. It is possible to make a backup of the current rules and restore them if required.

  • Clicking on any active rule will display the "edit rule" form, where you can delete the selected rule or change parameters like destination port number, transport protocol, policy and origin.
  • It is important to note that when adding a new rule, by default UFW will create the same rule for both TCPv4 and TCPv6. However, when deleting a rule you need to delete the TCPv4 and TCPv6 rules separately.
• More information on UFW can be found at:  https://help.ubuntu.com/community/UFW
• Click on the Next button.

Email Setup

• Enter the DNS Name or IP address of an SMTP email server. If you want to use SMTPS (SMTP over SSL or TLS) you can specify the authentication protocol to use as well as the SMTP Username, SMTP password and SMTP port (587 is the default). Please note that SMTP authentication without encryption is not supported.  The "Send a test email" button will attempt to send a test email to the nominated address, and will display any errors returned by the mail server.
• If you set the default address to append for your organisation, Snare will add this on to any email addresses specified in the scheduled task settings associated with each objective.
• For instance, if you add 'dni.gov.au' here, you can specify 'fred.bloggs' in a scheduled task email configuration item, rather than 'fred.blogs@dni.gov.au'.
• Enter the Reply-To address that Snare Central should use to send emails from.
• This will set any email 'reply to' addresses to this entry. If users hit their 'reply' button on a Snare email, this will be the address that email returns to. It is recommended you configure this to be your IT helpdesk, or a member of your security team.
• Select the preferred email distribution mode
• In general, it is recommended that each objective is configured to send out data independently of other objectives. If 'One email per user will go out..' is selected, there may be a delay of up to 15 minutes after an individual objective completes, before the collection of generated objectives is sent to the destination user.
• If your organisation requires a classification header to be included within the electronic mail messages sent with an objective, add it here.
• You may also choose to prepend, or append, the classification message to the subject line.
• If you are using an older mail client that cannot handle inline HTML formatted mail, the option in Mail Format section gives you the chance to turn HTML content off. Objective output will still be included as an attachment to the electronic mail message.
• Should Snare Central generate PDF attachments real time alert emails.
• Click on the Next button.

SNMP Setup

The SNMP (Simple Network Management Protocol) Setup section is divided in three subsections, the first one is for enable, disable and configure the SNMP Agents (snmpd), the second subsection allows to enable, disable and configure the reception of SNMP Traps (snmptrapd) and the third one is used to configure the transmission of SNMP traps for Alerts and Realtime Alerts in Snare Central.

SNMP Agent Configuration

The “Enable SNMP Agent Support (snmpd)” subsection, allows to turn on and off the snmpd service and configure what version of the protocol to use, and the security settings needed as show in the screen shot. Additionally the System Description, the System Contact and the System Location can be specified in this subsection.

SNMPTrap Server Configuration

The “Enable SNMP Trap Reception Support (snmptrapd)” subsection, allows to turn on and off the snmptrapd service and configure what version of the protocol to use for trap reception, and the security settings needed as show in the screen shot:

Snare Central v8.3.0 and above now supports SNMP versions 1, 2c and 3 including the reception and sending of SNMP Traps. SNMP traps are used for logging in a number of older network-related appliances. The Snare Central Server can receive snmptrap data, and make it available for analysis from within the Snare Server interface as SNMPLog event types.

SNMP v1 and v2c

SNMP versions 1 and 2c rely on a single unencrypted "community string" for traps, which made it very insecure on the network (anyone could 'snoop' on the network and detect the unencrypted community strings), this is why even though it is supported, it is not recommended.

SNMPv3

In order to overcome this lack of security, Version 3 uses the same base protocol as earlier versions, but introduces encryption and much improved authentication mechanisms. Depending on how you authorise with the SNMP agent on a device, you may be granted different levels of access.

The security level you use depends on what credentials you must provide to authenticate successfully:

For systems to communicate, both sides must use the same authProtocol (MD5 or SHA) and privProtocol (AES or DES). Some devices do not support all of these combinations, so you must check what can be used to ensure the trap receiver is configured in the same way.

SNMPv3 uses the HMAC-SHA-2 Authentication Protocol for the User-based Security Model (USM). The USM utilizes MD5 and the Secure Hash Algorithm as keyed hashing algorithms for digest computation to provide data integrity to directly protect against data modification attacks, to indirectly provide data origin authentication, and to defend against masquerade attacks. The USM uses the Data Encryption Standard (DES) in the cipher block chaining mode (CBC) to protect against disclosure. So in summary, MD5, SHA and HMAC-SHA-2 authentication protocols and the CBC_DES and CFB_AES_128 privacy protocols are supported in the USM.

Alert SNMPTrap Configuration

For Snare Central to be able to send SNMP traps as alerts to a Central Network Monitoring Server (SNMP Manager) when the "Enable Sending Alerts" option is selected in the Health Checker objective or for use as Realtime Alerts when certain event or combination of events arrive, first it is required to specify where and how to send such traps in this subsection:

• Enter the DNS Name or IP address of a SNMP Management server.
• By default UDP port 162 is used.
• Set the SNMP version, 1, 2c or 3.
  • When Selecting version 1 or 2c an entry to provide the Community Name is enabled.
  • When selecting version 3,  A new form is enabled to provide the Username and Password as well as further authentication and encryption information.
• Specify the full enterprise object identifier for the trap you want to send.
• Click on the Next button to save the values into the database.
• Once the values have been saved, it is possible to use the "Test SNMP Trap" button to send a trap to the server specified.

Alert Manager Setup

Starting with version 8.6.0, the Snare Alert Manager is the service in charge of the immediate and reliable delivery of alerts generated by the monitoring system and by the Realtime Alerts feature to one or many contacts and supports SMS delivery, SMTP (email) delivery and SNMP Traps delivery.

The Administrator needs to specify to the Alert Manager to which contacts the alerts shall be sent, by grouping them together and assigning a unique group name. There are however two default contact groups used by the system. The Administrator can add or remove contacts to these default groups as needed.

Default System Groups

The monitoring subsystem sends the alerts using the default SystemMonitor contact group. By indicating the contact group, the monitoring system lets the Alert Manager know to what contacts the alert shall be delivered. Once the alert it’s received, the Alert Manager default behaviour is to deliver the alerts via SNMP traps to the configured destination server, however the SystemMonitor group can be extended to include other contacts of email and/or SMS type that will also receive the alert.

When Snare HA (High Availability) is enabled, a second default group called HighAvailability is created and is used in the communication between the HA subsystem and the Alert Manager to send alerts when a state transition in the cluster occurs. By default the HighAvailability group sends any alert to the email address specified when configuring Snare HA (see Snare HA configuration in this link Appendix B - Configuring High Availability in Snare Central). Again, this contact group can also be extended to also include SMS contacts or send SNMP Traps if required.

The Realtime Server is also capable of sending alerts when “Realtime Alerts” are enabled and an Objective has the “Realtime Alerts” component added to its configuration. The Realtime Server works in close collaboration with Snare Reflector to trigger alerts via the Alert Manager when certain events are received directly from the network. (see Realtime events here (Real Time Alerts and Threshold Reporting) ). Depending on the group chosen, the real time alerts can be delivered to one or many email recipients, to one or many SMS contacts or as an SNMP Trap or any combination of them.

Internally, the Alert Manager expands the specified group into a series of contact lists of the same type and take care of delivering the alerts to each contact list using the correct delivery method.

The Administrator can configure any number of groups required and also can add and remove contacts to and from any group at any time including the two default system groups SystemMonitor and HighAvailability.

The Alert Manager Setup section in the Configuration Wizard is shown in the following image:

The Alert Manager Setup section is divided in four subsections: Alert Settings, Providers, Contacts  and Groups. Each of these subsections are described next.

Alert Settings

In this subsection, the Administrator can enable or disable the delivery of “System Alerts” and “Realtime Alerts”.

• Enable System Alerts: Disabling “System Alerts” will prevent the delivery of any alert triggered by the monitoring system and by the high availability subsystem as well. This control does not affect the delivery of real time alerts.
• Enable Realtime Alerts: Disabling the “Realtime Alerts” will prevent the Realtime Server to trigger alerts and also will signal the Alert Manager to halt the delivery of real time alerts.

Providers

This subsection lists the available delivery providers configured in the system and allows the Administrator to add, remove, enable, disable and test SMS providers.

When an email server is configured in the “Email Setup” section of the “Configuration Wizard”, a new SMTP delivery provider will appear in the Providers table.

When an alert SNMP Trap destination server is configured in the “SNMP Setup” section of the “Configuration Wizard”, a new provider of type SNMP will appear in the table.

The Providers subsection allows the Administrator to add just one SMS Gateway provider for sending alerts to mobile phones. Out of the box Alert Manager supports the following SMS service providers: Twilio, Vonage, Infobip, ClickSend, Telnyx, SMSGlobal, Routee, Plivo and BurstSMS.

To enable SMS delivery and depending on the provider, credentials in the form of api_key and api_secret are needed. These credentials can be obtained from the SMS Gateway provider portal.

Contacts

This subsection allows the Administrator to add, remove, edit, enable or disable contacts and lists all the existing contacts available for alert delivery, each one is identified by a unique contact name and the list also shows the type of contact and the required email address or phone number. The following table show the types of contacts and the data required:

There is always a default SystemMonitor contact of type SNMP that is created automatically by the system when an email server is configured in the “Email Setup” section of the “Configuration Wizard”,. This contact is used by the SystemMonitor group for the monitoring system and cannot be deleted or altered.

When Snare HA is enabled, there will be a default HighAvailability contact of type SMTP that is created automatically by the system. This contact is used by the HighAvailability group for the HA subsystem and cannot be deleted or altered.

The Administrator can add any number of contacts at any time without restriction. A contact specifies the email address and/or number where alerts are going to be sent via email, via SMS or both. For example a contact could be “Network Operation Center” and be of type email and send alerts to NOC@networkteam.company.com.

Any contact can belong to any number of groups so the same contact can be listed inside one or more groups.

Groups

This subsection allows the Administrator to add, remove, edit, enable or disable contact groups and lists all the existing groups defined in Alert Manager and allows the Administrator to add, remove, enable, disable and test contact groups.

When an email server is configured in the “Email Setup” section of the “Configuration Wizard”, a new default group called SystemMonitor will appear in the Groups table.

When an alert SNMP Trap destination server is configured in the “SNMP Setup” section of the “Configuration Wizard”, a new default group called HighAvailability will appear in the Groups table.

Alert History

Every time an alert is delivered (successfully or not), the Alert Manager sends a SnareServerLog event to the system for archiving. All the Alert Manager activity can be reviewed using the following query in the “Event Search” page:

DATE>='7' AND TABLE = 'SnareServerLog' AND RESOURCE REGEXI 'AlertManager'

High Availability

Starting with version 8.4.0, Snare Central server can be configured to be part of a Snare High Availability (HA) cluster. The server can be configured as Primary (Active) or as Secondary (Passive) in an active/standby setup both sharing the same cluster's virtual IP address and configuration.

Once enabled is selected, the Administrator needs to provide the following information:

• Role of this server in the cluster (Primary/Secondary).

• The local IP address that is going to be used for heartbeat synchronization with the other cluster members.

• The IP address of the remote cluster member.

• The virtual IP address that is going to shared between all cluster members.

• A working email address for sending notifications.

• The common password used between the members of the cluster. The password has to be 8 characters long and contain at least one lowercase letter, one uppercase letter, a number and a symbol.

• The password of the Snare user in the remote node.

It is a requirement that the first node in the cluster to be configured be the Primary node and only one node shall be configured as Primary.

Once both nodes are configured, Snare High Availability feature will automatically synchronize whatever configuration is required from the Primary into the Secondary node and in case of failure of the Primary node, automatic switch to the Secondary will occur instantly.

A detailed description on how to configure High Availability in Snare Central can be found here:   Appendix B - Configuring High Availability in Snare Central

Performance and Hardware Settings

• Date-based discard is a partially deprecated feature, that will be removed in future versions of Snare Central. Previous versions of Snare Central allowed for the removal of log data that arrived at the Snare Central server significantly out of time synchronisation with the Snare Server (for example: from an agent that is configured with a date more than 5 days in the past). Some exceptional circumstances may still cause this setting to be active (eg: When the Snare Central server is rebooted, the boot process may discard files in line with this setting) - however, for normal operation, this setting will no longer apply.

• Event and Memory thresholds should generally not be changed unless otherwise advised by your Snare Central support team.
• Version 8.1 and above of the Snare Server include a new, faster, query engine known as 'SnareStore'. For complete backwards compatibility, the SnareStore interface can be disabled if required. It is recommended that this option be left at the standard setting unless otherwise advised by your Snare Central support team.

• Enable Realtime Alerts - Checking this option enables realtime alerts for the entire Snare Central instance. Unchecking this option will disable realtime alerts instead.

  • Be advised that changing this option will restart the Snare Reflector service. The restart process will take a few seconds. During this time, Snare Central will not be able to receive events.

• Realtime Query Limit - Snare Central limits the number of concurrent realtime queries to 10 by default - any extra active queries will have a significant impact on your event collection rates. Disabling all realtime queries will significantly increase your event collection rates.

• If your server has an optical writer (CD / DVD) installed, you can select the preferred default device here. Click on the Next button. A final screen will be displayed, reminding you of the location of the Snare Central documentation.

  • This setting will be used by the automated data archive objective, if you choose to schedule it.

Additional Objectives

Snare Central comes with baseline Reports and, from version 8.6.0, Analytics Dashboards (AKA objectives) suitable for a wide range of deployments. 

This section allows to import Reports or Analytics Dashboards objectives from a local file or a local snapshot of Snare Objective Store.

In general, the objectives available from this page are either:

• • Associated with the security and audit components of industry regulations such as PCI, NISPOM, or SOX, or
  • Are newly developed, and have not yet been integrated directly into the default objectives distributed as part of a Snare Central release.

Objectives imported during this step, will be added to either 'Reports' or  (from v8.6.0) 'Analytics Dashboards' area of Snare Central, under a new folder called 'Imported Objectives', and tagged with the date/time of import.

Return to Snare Central

• If you have changed the server name, or have forced a regeneration of the Snare Central certificate, choose the 'Restart Apache, and return to Snare Central' option, otherwise click on 'Return to Snare Central'.