Migrating to Snare from NXLog - Securonix
Guide to Migrating from NXLog Enterprise Agent to Snare Enterprise Agent
Migrating from one log management solution to another can be a complex but essential task to ensure your security operations remain efficient and secure. If you are currently using NXLog Enterprise Agent and are transitioning to Snare Enterprise Agent, this guide will provide a structured approach to make the migration process smoother.
1. Initial Considerations
Before proceeding with the migration, it’s important to have a clear understanding of the following:
Log Sources: Ensure you identify all the sources that are currently being monitored and logged by the NXLog agent.
Log Formats and Data Integrity: Be aware of the log formats (e.g., syslog, JSON, CSV, XML) that NXLog uses and how these will map to Snare's configuration.
Existing Processing Rules: Document the existing NXLog configurations, including any log parsing, transformation, and routing rules.
Environment Compatibility: Verify that Snare Enterprise Agent supports the same operating systems, log formats, and applications as NXLog.
Backup Configuration: Back up your existing NXLog configurations and any important log data before you begin.
2. Preparation for Migration
a. Install the Snare Enterprise Agent on a single machine
Download and install the Snare Enterprise Agent appropriate for your environment (Windows, Linux, macOS, etc.) from the Snare License and Download Manager (SLDM) . Ensure that the version you are using is compatible with your target operating system and architecture.
b. Download the Snare MSl Builder
Download the Snare MSI builder from SLDM (on the same machine as the Enterprise agent installed in step a) and ensure the requirements/prerequisites have been met here: Requirements - Snare MSI Documentation v3 - Confluence
c. Install the Snare Central
Download and install the Snare Central server from SLDM and deploy as per the documentation here: Installation Guide for Snare Central - Snare Central v8 Documentation - Confluence
d. Assess Network Requirements
Check the following:
Ensure that the Snare agent can communicate with Snare Central (or SIEM platform).
Configure any necessary firewall rules and port forwarding to allow log traffic and management ports to the Snare Central. Specifically ports 514, 6161 and 6262.
3. Mapping NXLog Configuration to Snare
NXLog and Snare have different configuration syntaxes and log processing models. This is the most critical part of the migration process.
a. Log Collection
NXLog: Typically, NXLog uses
input
andoutput
modules to collect, process, and send logs. Review the NXLog configuration file (usually located here C:\Program Files (x86)\nxlog\conf) to identify existing log collection and destination rules.Snare: Snare also collects various log types and will need to be configured as per the existing NXLog configuration (e.g., file locations or Operating system events).
NXLog configuration file example. | Snare Agent user interface for creating Windows auditing policies. |
Migration Steps:
Identify Sources: Review your current NXLog input sources (e.g., file paths, syslog/Netflow sources & operating system events).
Map Log Sources: Ensure that all log sources currently collected by NXLog are properly configured in Snare. For example:
File (im_file): Map to “Log File” policies. Found under “Log sources” in the left hand navigation menu.
File Monitoring (im_filemon): Map to “Log File” policies (such as Apache web, DNS, DHCP, IIS, etc). Found under “Log sources” in the left hand navigation menu.
Registry Monitoring (im_regmon): Map to “Registry integrity monitoring” policies. Found under “Log sources” in the left hand navigation menu.
Windows Event Logs (im_mseventlog & im_msvistalog): Map to “Audit policies”. Found under “Log sources” in the left hand navigation menu.
Windows Performance Counters (im_winperfcount): Map to “Telemtry” policies. Found under “Log sources”->”Telemetry” in the left hand navigation menu.
b. Log Processing and Filtering
NXLog offers a processing module that allows you to filter, process, and route logs to different destinations. Snare can also offers powerful processing rules to ensure data is sent in the correct format to the correct destinations.
Migration Steps:
Replicate Filters: If you have custom filters in NXLog (e.g., specific regex patterns for parsing logs), you will need to replicate these with Snare Agents.
File (im_file) filters are applied within “Log Files Filters” found under “Log sources” in the left hand navigation menu. Regex filters can be applied on both include or exclude policies to filter data.
File Activity Monitoring (im_filemon) filters are applied within the policy itself. Filters can be applied by event types, inclusion scopes, utilised permissions, general regex matches and user matches.
Registry Activity Monitoring (im_regmon): filters are applied within the policy itself. Filters can be applied by event types, inclusion scopes, utilised permissions, general regex matches and user matches.
Windows Event Logs (im_mseventlog & im_msvistalog): filters are applied within the policy itself. The frequency and collected counters are configured here.
Windows Performance Counters (im_winperfcount): filters are applied within the policy itself. The frequency and collected counters are configured here.
c. Log Forwarding
NXLog: You may be forwarding logs to external destinations like a SIEM or syslog server using the
output
directive.Snare: Similarly, Snare allows you to forward logs to multiple destinations in various formats.
Migration Steps:
Define Output Destinations: Configure destinations under the “Destination Configuration” section of the agent GUI. Set the destination IP as the IP of the Snare reflector, the port as 6161, protocol as TCP and format as “Snare”.
Configure Snare Reflector: Create new destinations within the reflector for the specific log types being collected.
Log type | Format in Reflector | Filter regex (include) | Filter comments | Notes |
---|---|---|---|---|
Apache Web Server | Syslog RFC 3164 (QRadar) | \tApacheLog\t |
| Set “Log Type” in log file policy as “Apache”. |
Microsoft ADFS | Syslog RFC 3164 (QRadar) | AD FS/Admin |
|
|
Microsoft Defender | Syslog RFC 3164 (QRadar) | Microsoft-Windows-Windows Defender\/Operational |
|
|
Microsoft DHCP | Syslog RFC 3164 (QRadar) | \tDHCPLog\t\d+\s\d+,\d{2}\/\d{02}\/\d{02},\d{2}:\d{02}:\d{02}, |
|
|
Microsoft DNS Server | Syslog RFC 3164 (QRadar) | \tMSDNSServer\t|Microsoft-Windows-DNSServer\/Audit |
| Set “Log Type” in log file policy as “DNS”. |
Microsoft Exchange Parser | Syslog RFC 3164 (QRadar) | \tExchangeLog\t |
| “Custom” Log type specified in policy. Set as "ExchangeLog". |
Microsoft IIS Server | Syslog RFC 3164 (QRadar) | \tIISWebLog\t |
| Set “Log Type” in log file policy as “IIS”. |
Microsoft Windows Powershell | Syslog RFC 3164 (QRadar) | Microsoft-Windows-PowerShell\/Operational.*4104 |
|
|
Microsoft Windows Snare Application | Syslog RFC 3164 (QRadar) | \t(Application|Security|System)\t\tMSWinEventLog\t | One desitnation and policy required for Security, Application and System |
|
Microsoft Windows Snare Security | Syslog RFC 3164 (QRadar) | \t(Application|Security|System)\t | See above |
|
Microsoft Windows Snare System | Syslog RFC 3164 (QRadar) | \t(Application|Security|System)\t | See above |
|
Microsoft Windows Sysmon | Syslog RFC 3164 (QRadar) | Microsoft-Windows-Sysmon/Operational |
|
|
Microsoft Windows Sysmon | Syslog RFC 3164 (QRadar) | Microsoft-Windows-Sysmon/Operational |
|
|
RADIUS_NPS | Syslog RFC 3164 (QRadar) | \tRadiusLog\t |
| “Custom” Log type specified in policy. Set as "RadiusLog". |
Windows MSSQL Via Syslog SNARE | Syslog RFC 3164 (QRadar) | MSSQL\$MICROSOFT##WID|MSSQLSERVER |
|
|
Windows MSSQL Via Syslog SNARE | CEF |
|
|
|
Note: A port for ingestion of each type will need to be created in Securonix first.
Test Output Delivery: Log into Securonix and check that logs are being received under the specified “Activities” using the “Spotter”. Ensuring the necessary ports are open for communication.
4. Configuring Management
Snare provides a central management console to manage licensing, configuration and updating of agents remotely called Snare Agent Manager.
a. Snare Agent Manager
Install the Snare agent manager: Either as a standalone deployment for Windows, or an embedded instance within Snare Central.
Upload licenses: Once you have access to the Snare agent manager, get its assigned KeyID’s by slecting “Licenses”->”Key ID’s” in the navigation menu. Copy these key IDs and assign them to your license in the licensing portal (SLDM). Once the Key IDs have been assigned, download the license file and upload it to the SAM by selecting “Licenses”->”Add a new License” in the navigation menu.
Manage agents by following further documentation here:
b. Monitoring agents
Agents can be monitored for last check-in, licensing assigned, version numbers and policies.
5. Testing and Validation
Once you've replicated your NXLog configuration in Snare, it’s time to test the system thoroughly to ensure everything is functioning properly.
a. Test Data Collection
Verify that all logs are being collected correctly from the configured sources.
Check timestamps, log formatting, and data integrity to ensure nothing is missing or malformed.
b. Test Log Forwarding
Test that logs are being forwarded to the correct destinations (SIEM, syslog servers, etc.).
Check for proper delivery of logs, and monitor for any delivery failures or delays.
c. Check agents available in SAM
Review “all agents” section in SAM to confirm agents connected, online and have a license issued.
6. Finalising the Migration
Once testing is successful and you’ve validated the migration, you can proceed with these final steps:
Deploy Snare to Production: If everything is functioning as expected, use the MSI Builder to extract the configuration from the configured Snare agent and generate an .msi file that contains both configuration and installation media. Following steps here: Creating the MSI package - Snare MSI Documentation v3 - Confluence. From there, deploy the Snare agent to your production environment.
Decommission NXLog: After ensuring Snare is working as expected, safely decommission your old NXLog setup.
Monitoring: Continue to monitor the Snare agents via the Snare Agent Manager (SAM) to ensure stability and performance.
7. Additional Considerations
Snare Support: If you encounter any limitations or issues with Snare, consider reaching out to their support team for assistance.
Training: Familiarise your team with Snare’s configuration interface and logging capabilities. This may involve specific training or documentation.
Conclusion
Migrating from NXLog to Snare requires careful planning, configuration, and testing. By following these steps and considering the differences in how each agent handles log collection, processing, and forwarding, you can achieve a seamless migration.