The WinSuricata Operations Console provides a centralized administrative interface for managing the operational components of a WinSuricata installation. Rather than requiring administrators to manually locate individual utilities, scheduled tasks, configuration files, and maintenance tools, the Operations Console brings these functions together into a single interface.

The console is also deployment-aware. Its available functions are determined by the components and options present in the particular WinSuricata installation. This allows the same Operations Console to be used on a standalone sensor, a centralized Host, or a Host configured for Remote Node deployment without presenting functions that are not applicable to that installation.

Email Notifications

The Enable Email Notifications option provides configuration for automated email reporting from the WinSuricata rule-update system.

Administrators can configure the SMTP server, port, sender address, recipient address, username, and password. SMTP credentials are protected using machine-scope Windows DPAPI rather than being stored as plain-text credentials.

The console also provides the Suppress "No Change" Emails option. When enabled, routine rule-update checks that produce no changes do not generate an email. Notifications are instead reserved for actual rule updates or errors.

The Test SMTP Settings function allows the configured email settings to be tested directly from the Operations Console.

ET Pro / Custom Rule Key

The Use ET Pro / Custom Rule Key option allows administrators to configure a private rule-feed key for Emerging Threats Pro or another supported custom rule source.

The key is stored using protected machine-scope configuration rather than being retained as unprotected plain text. This allows the rule updater to use the configured key while keeping the credential protected within the Windows installation.

Rule Update Scheduling

The Set Rule Update Schedule option provides automated scheduling for Suricata rule updates.

Administrators can specify the update interval using the available hour and minute selections. When enabled, the Operations Console creates and manages the Windows Scheduled Task used to execute the WinSuricata rule updater.

The scheduled task operates under the SYSTEM account with the required elevated execution level, allowing rule maintenance to continue without requiring an administrator to remain logged on.

Execute Immediate Rule Update

The Execute Immediate Rule Update function allows an administrator to manually initiate a rule update without waiting for the scheduled update interval.

The update utility is launched without displaying a separate console window, while its output is captured and displayed directly within the Operations Console. This gives the administrator immediate visibility into the update process and its results.

Manual execution also prevents the normal automated email notification process from generating a duplicate notification for the manually initiated update.

System & Environment Diagnostics

The System & Environment Diagnostics function performs a series of checks against the WinSuricata installation and its operating environment.

The diagnostic process verifies items including:

• Administrative privileges
• The configured WinSuricata root path
• Registry configuration
• Log write access
• The Suricata executable
• The Suricata configuration file

The results are reported directly in the Operations Console, providing an initial troubleshooting mechanism before more advanced investigation is required.

Remove Scheduled Task & Settings

The Remove Scheduled Task & Settings function removes the WinSuricata rule-update scheduled task and its associated configuration.

This provides administrators with a controlled method of returning the rule-update configuration to an unconfigured state without manually navigating through Windows Task Scheduler or deleting configuration files themselves.

The Operations Console also resets its displayed configuration to the appropriate default state following removal.

Service Monitor

The Activate Service Monitor function installs and activates the WinSuricata Service Monitor utility.

The monitor provides ongoing awareness of the WinSuricata service environment and allows the installation to automatically monitor the required components.

The Operations Console verifies the resulting installation by checking the relevant service, process, and registry state and reports the status through the integrated interface.

Cleanup and Restore

The Cleanup and Restore function provides access to the WinSuricata cleanup and restoration utility.

This capability is different from the Host-dependent functions described later in this document. Cleanup and Restore does not require OpenSearch or a Host installation.

Instead, its availability is determined by the Cleanup and Restore option selected during the original WinSuricata Headless Installer deployment.

If the option was enabled during the initial deployment, the Cleanup and Restore utility is made available through the Operations Console. If the option was not enabled, the corresponding utility is not made available.

This allows the original deployment configuration to determine whether the installation includes the additional cleanup and restoration capability.

OpenSearch PKI Checker

The OpenSearch-PKI-Checker provides a dedicated administrative utility for installations using the centralized WinSuricata Host and OpenSearch environment.

The checker is used to examine the certificate and trust configuration associated with the OpenSearch environment and provides a troubleshooting mechanism for identifying PKI-related configuration problems.

Because this function is specifically associated with the centralized Host/OpenSearch architecture, it is not presented on a standalone WinSuricata sensor.

Host Detected — Add Remote Node

The Host Detected - Add Remote Node function provides Host administrators with a direct method of initiating Remote Node deployment.

When the Operations Console detects the WinSuricata Host/OpenSearch environment, the option becomes available. Selecting it expands the interface to provide fields for:

• Remote Node Alias

The console validates the supplied information and then launches the WinSuricata Node Setup utility with the configured node information.

This allows a Host administrator to begin Remote Node provisioning directly from the Operations Console rather than manually locating and launching the Node Setup utility.

Node Recovery

Objective: Restore the required configuration for multiple Remote Nodes after the Host's authentication infrastructure has been reset or reinitialized.

When authentication packages are generated, a recovery ZIP package containing the Node configuration files required for recovery can be created for later use. To initiate recovery, copy the previously generated package into the new Host's <WinIDSRoot>\Temp directory and launch the WinSuricata Management Console. When the package is detected, the console makes the Node Recovery option available. Run the recovery utility to restore the Node configurations and facilitate reconnection to the Host.

The Node Recovery option is available only while the required package is present in the designated directory. After the package has been used, it is purged.

Node Key Updates

Objective: Update authentication credentials for an individual Remote Node and restore its connection to the Host without reinstalling the Node.

Obtain a new authentication ZIP package for the affected Node from the Host and copy it into that Node's <WinIDSRoot>\Temp directory. Launch the WinSuricata Management Console on the Node. When the package is detected, the console makes the Node Key Update option available. Run the utility to update the Node's authentication configuration and facilitate reconnection to the Host.

The Node Key Update option is available only while the required package is present in the designated directory. After the package has been used, it is purged.

Dynamic Operations Interface

The Operations Console does not use a fixed interface for every WinSuricata deployment.

When additional configuration sections are enabled, the interface dynamically adjusts itself to accommodate the expanded controls. For example, enabling Email Notifications or Remote Node provisioning changes the available form area and integrated log display so that the additional controls can be presented without unnecessarily enlarging the overall interface.

This provides a consistent management experience while allowing additional functionality to appear only when required.

Installation-Dependent Operations

The Operations Console automatically adapts its available functions based on the components and options configured during the original WinSuricata deployment.

This prevents functions from being presented when the required underlying component or installation option is not available.

Host-Dependent Functions

The following Operations Console functions are associated with the WinSuricata Host/Remote Node deployment. Their availability depends on the detected installation and, for recovery operations, the presence of the required package:

OpenSearch-PKI-Checker

The OpenSearch-PKI-Checker is displayed when the Operations Console detects the WinSuricata OpenSearch Host environment.

It provides access to the dedicated PKI verification utility used to examine the certificate and trust configuration supporting centralized OpenSearch.

A standalone WinSuricata sensor without the Host/OpenSearch installation does not display this function.

Host Detected — Add Remote Node

The Host Detected - Add Remote Node function is also displayed only when a WinSuricata Host/OpenSearch installation is detected.

When selected, the Operations Console provides the Remote Node Alias and Remote Node IP Address fields required to initiate node provisioning.

After validation, the console launches the WinSuricata Node Setup utility and passes the supplied information to the provisioning process.

A standalone WinSuricata sensor therefore does not display the Remote Node provisioning controls.

Node Recovery

This option is displayed on the Host when the required recovery ZIP package is present in <WinIDSRoot>\Temp. Its objective is to restore configuration for multiple Remote Nodes following a Host authentication reset. The package is purged after use.

Node Key Updates

This option is displayed on a Remote Node when its authentication ZIP package is present in <WinIDSRoot>\Temp. Its objective is to update that Node's authentication configuration and restore connectivity without reinstalling the Node. The package is purged after use.

Deployment-Option-Dependent Functions

Cleanup and Restore demonstrates a different type of availability condition.

It is not dependent on Host detection. Instead, it depends on whether the feature was selected during the original Headless Installer deployment.

This means that a standalone sensor can have Cleanup and Restore available, while another standalone sensor may not, depending on the options selected during its initial installation.

The Operations Console therefore reflects the original deployment decision rather than assuming that the feature exists on every installation.

How the Console Adapts

The result is an Operations Console that can support multiple WinSuricata deployment configurations.

Deployment-Aware Administration

This deployment-aware design is an important part of the Operations Console.

The console does not simply provide a fixed collection of administrative buttons on every system. Instead, it determines which capabilities are appropriate for the particular WinSuricata installation and exposes those functions accordingly.

A standalone sensor receives the tools required to manage its local Suricata deployment, rule updates, diagnostics, monitoring, and other locally configured functions.

A Host installation additionally receives the OpenSearch PKI and Remote Node management capabilities required for centralized operation.

WinSuricata includes a Host Recovery and Node Recovery system designed to simplify recovery of a centralized WinSuricata Host without requiring every Remote Node to be manually rebuilt or individually re-registered.

This is particularly important in larger deployments.

A Host may have dozens or more Remote Nodes communicating with it. If the Host experiences a system failure, system restore, disk replacement, PKI corruption, or another event that requires restoration of the Host environment, rebuilding the Host is only part of the recovery process.

The more significant problem can occur afterward:

Previously deployed Remote Nodes may no longer be able to authenticate to the recovered Host.

Without a centralized recovery mechanism, an administrator could be forced to generate a new authentication package for every Remote Node, transfer those packages individually, and perform a reconnection procedure on every sensor. This could be extremely time-consuming in a larger deployment.

WinSuricata's Host Recovery and Node Recovery system was designed specifically to eliminate that process.

BEFORE USING NODE RECOVERY

There is a Host Recovery Package Detected - Recover Nodes button in the WinSuricata Host Manager.  Follow these instructions and the button will activate.

If you have launched Cleanup & Restore from the WinSuricata Host Manager, the computer has been returned to a state before WinSuricata was installed. The WinSuricata Host must therefore be fully reinstalled before Node Recovery can be performed.

1. Confirm the WinSuricata Host Is Operational

Before starting Node Recovery, confirm that:

• The WinSuricata Host has been fully reinstalled.

• The WinSuricata Host Manager can be accessed normally from the Desktop shortcut.

• The Host has network connectivity so the Remote Nodes can connect.

Do not begin Remote Node recovery until the Host itself is operational.

PROTECT THE HOST RECOVERY FILE

The Host Recovery archive is critical to recovering previously registered Remote Nodes.

After every Remote Node is added, WinSuricata archives the complete recovery files into: $WinIDSRoot\Backup

using the following format: <date>-HostRecovery.zip

For example: D:\WinSuricata\Backup\2026-10-03-HostRecovery.zip

Keep an Additional Up-To-Date Copy Off the Host

Do not rely solely on the copy stored on the WinSuricata Host.

If the Host suffers a catastrophic disk failure, storage failure, or complete system loss, a recovery archive stored on that same system may also be lost.

Maintain a current copy of the HostRecovery ZIP in a secure location outside the WinSuricata Host.

The off-system copy should be protected against unauthorized access because the recovery package contains sensitive Host and Remote Node recovery information.

The external copy should be updated whenever the Host Recovery archive changes so that it represents the current Remote Node deployment.

The goal is to ensure that a catastrophic Host failure does not also destroy the information required to recover the Remote Nodes.

USING THE HOST RECOVERY PACKAGE DETECTED - RECOVER NODES BUTTON

Once the WinSuricata Host has been restored and is fully operational, the current Host Recovery archive must be placed in the Host's Temp folder using the required filename.

1. Prepare the Host Recovery Package

Locate the most recent Host Recovery archive in: $WinIDSRoot\Backup

The file will use the following naming format: <date>-HostRecovery.zip

Copy the current recovery archive to: $WinIDSRoot\Temp

Rename the copied file to: HostRecovery.zip

The final location and filename must be: $WinIDSRoot\Temp\HostRecovery.zip

Do not extract the ZIP file.

The WinSuricata Host Manager is looking for the recovery package using this exact filename and location.

2. Open the WinSuricata Management Console

Launch the WinSuricata Management Console from the desktop shortcut.

Once the Host Recovery package is detected, the following button will become available:

Host Recovery Package Detected - Recover Nodes

Left-click the button to begin the Remote Node recovery process.

If the Button Is Not Displayed

If the Host Recovery Package Detected - Recover Nodes button is not displayed, verify that:

• The file exists in $WinIDSRoot\Temp

• The filename is exactly HostRecovery.zip

• The file has not been extracted.

• The ZIP file is located directly in the $WinIDSRoot\Temp folder

• The WinSuricata Host Manager has been restarted after placing the file in the Temp folder so that the recovery package can be detected.

Do not rename the file to the original <date>-HostRecovery.zip name in the Temp folder. The file must be named exactly HostRecovery.zip for the recovery function to detect it.

3. Start Node Recovery

Once the Host Recovery Package Detected - Recover Nodes button is available, left-click the button.

The recovery process restores the Host-side information required for the previously registered Remote Nodes, including their registration and authentication information.

The Remote Nodes are processed as a bulk recovery operation.

For large deployments, the Node Recovery process is designed to process 100+ Remote Nodes in less than one minute under normal operating conditions.

Allow the recovery process to complete before beginning any individual Remote Node troubleshooting.

AFTER RESTORE NODES COMPLETES

When the Restore Nodes process finishes, allow the recovered Remote Nodes time to reconnect to the Host.

1. Verify the Remote Nodes in EveBox

Open the EveBox console.

As each Remote Node reconnects, it will register in the Sensors drop-down list.

The number of connected Remote Nodes will also be reflected in the Dashboard Overview section.

The recovered nodes should retain their previously established Host Node Alias.

2. Verify Remote Node Telemetry

In EveBox, open the Sensors drop-down and select a recovered Remote Node.

Verify that events from the selected node are being received by the Host.

The recovered Remote Node should begin reporting telemetry normally once its connection to the Host has been re-established.

Repeat this verification with additional Remote Nodes as necessary.

3. Allow Time for All Nodes to Reconnect

If a large number of Remote Nodes are being recovered, allow sufficient time for the individual sensors to reconnect and begin sending telemetry.

Do not immediately begin reinstalling Remote Nodes simply because they do not appear immediately.

First confirm that the bulk Node Recovery completed successfully and allow the Remote Nodes time to reconnect.

IF A NODE DOES NOT RECONNECT

If one or more Remote Nodes remain offline after the Host recovery:

1. Confirm that the Host is operational.

2. Confirm that the Remote Node appears in the recovered Host registration information.

3. Confirm network connectivity between the Host and the Remote Node.

4. Check the affected Remote Node.

5. Restart the WinIDS-EveBoxAgent service on the affected Remote Node.

6. Allow the node time to reconnect.

7. If the node still does not reconnect, troubleshoot that individual node.

In some cases, an individual Remote Node may require a new Node package from the Host to be reapplied to that node. This should only be necessary for the affected Remote Node and does not require rebuilding the entire Remote Node deployment.

The purpose of bulk Node Recovery is to restore the Host-side registration and authentication environment for the previously deployed Remote Nodes as a single recovery operation.

NEW REMOTE NODES

The Restore Nodes function is for Remote Nodes that were previously registered with the Host.

A new Remote Node that has never been registered must still be deployed using the normal WinSuricata Remote Node installation and registration procedure.

Restore Nodes is a recovery function, not the initial Remote Node deployment process.

RECOVERY BEST PRACTICE

For every WinSuricata Host:

Keep the current <date>-HostRecovery.zip both on the Host and in a secure off-system location.

The local copy provides convenient access during normal Host recovery.

The secure off-system copy protects the deployment against a catastrophic failure in which the WinSuricata Host and its local storage are no longer available.

This recovery archive is what allows WinSuricata to restore a large Remote Node deployment without requiring the administrator to manually recreate the registration and authentication information for every sensor.

The WinSuricata Recovery Workflow

1. Recover or reinstall the WinSuricata Host.

2. Confirm the Host is operational.

3. Copy the current <date>-HostRecovery.zip to $WinIDSRoot\Temp.

4. Rename the file to HostRecovery.zip.

5. Open the WinSuricata Management Console.

6. Select Host Recovery Package Detected - Recover Nodes.

7. Allow the bulk Node Recovery process to complete.

8. Open EveBox and verify the recovered Remote Nodes.

9. Verify Remote Node telemetry.

10. Troubleshoot only individual nodes that fail to reconnect.

This is the intended WinSuricata Host Recovery and Bulk Remote Node Recovery workflow.

This does not normally require reinstalling the Remote Node. WinSuricata includes the WinSuricata Node Key Updater in the Host's management console specifically for this situation. The utility allows an existing Remote Node to receive the new registration information from the Host and update its EveBox Agent configuration without performing a complete Node installation.

Important — Each Remote Node Must Be Updated Individually

This procedure demonstrates the complete recovery process for one Remote Node.

If a Host has multiple Remote Nodes that need to be reconnected, this procedure must be completed separately for every Remote Node.

Each Remote Node has its own:

• Remote Node Alias

• Registration key

• EveBox Agent configuration

Updating one Remote Node does not update any other Remote Nodes.

For example, if a Host has Remote-01, Remote-02, and Remote-03, each Node that needs to reconnect must go through its own key-recovery process.

Step 1 — Generate the New Node Registration on the Host

On the newly installed WinSuricata Host, open the WinSuricata Management Console.

Go to the Remote Node configuration area and select:

Host Detected - Add Remote Node

Enter the information for the specific Remote Node being recovered:

• Remote Node Alias: Enter the existing alias assigned to that Node.

The Management Console will generate the new Node registration information using the Host's current registration key.

The generated registration files are stored on the Host under:

$WinIDSRoot\Nodes\<Remote Alias>

For example:

D:\WinSuricata\Nodes\date-Remote-01

The Node-specific folder contains the registration information required to update that particular Remote Node.

Step 2 — Copy the New Registration Files to the Node Temp Folder

Before the Remote Node can reconnect to the Host the new key file must be added.

Transfer the two files below from the Host to the Node:

For example:

D:\WinSuricata\Nodes\Date-Remote-01\
    Remote-01-NodeConfig.json
    root-ca.pem

Copy the required files to:

D:\WinSuricata\Temp\
    Remote-01-NodeConfig.json
    root-ca.pem

Important

The Management Console will not display the option to reinstall/update the Node key until the required registration files have been detected in $WinIDSRoot\Temp folder.

Step 3 — Use the Management Console to Reinstall the Node Key

Once the registration files have been placed in the Node's Temp folder, open or refresh the WinSuricata Management Console.

The Node key reinstallation/update option will now be available because the required registration files have been detected.

Select the option to reinstall/update the Node key.

The Management Console will use the registration information found in the Temp folder to reconnect the Node to the Host.

Step 4 — Verify the Remote Node

After the Node Key Updater completes, verify that the EveBox Agent service is running on the Remote Node.

The Node should now be using the Host's current registration key and should be able to reconnect to the Host.

Allow a few moments for the Node to reconnect and begin sending events.

Step 5 — Repeat the Process for Every Remote Node

If additional Remote Nodes were connected to the Host before the Host was reinstalled, repeat Steps 1 through 6 for every Remote Node that needs to reconnect.

For each Remote Node:

1. On the new Host generate the Node registration information using its existing alias and IP address.

2. Locate its registration files under $WinIDSRoot\Nodes\<Remote Alias>.

3. Copy the required registration files to $WinIDSRoot\Temp on the Node.

4. Run the WinSuricata Node Key Updater from the Management console on that Node.

5. Verify that the EveBox Agent reconnects.

The underlying problem is not with the Suricata detection engine itself. suricata-update is the official Suricata rule-management utility and is the same utility used on Linux and other Unix-based systems. Suricata's documentation recommends suricata-update for downloading, managing, enabling, and disabling rule sources.

The difficulty is the Windows execution environment used by suricata-update. The utility is written in Python, and Windows handles temporary files, open file handles, file replacement, and related filesystem operations differently from Unix/Linux systems. These differences have resulted in longstanding Windows-specific problems with suricata-update. Suricata developers have publicly acknowledged these issues, including problems involving temporary files and Windows file handling, and have stated that Windows support has not been well tested or supported.

The WinSuricata Solution

Rather than attempting to modify or replace the official suricata-update utility, WinSuricata takes a different approach. WinSuricata provides a lightweight Cygwin environment on Windows and uses it as the execution environment for suricata-update.

Cygwin provides a Unix-like environment within Windows, allowing the official rule-management utility to operate using the filesystem and command-line environment it was designed to work with. This allows WinSuricata to use the same suricata-update process used on Unix/Linux systems instead of attempting to maintain a separate Windows-specific rule-management implementation. Cygwin is designed to install and maintain individual Unix-like packages on 64-bit Windows systems.

The first time an on-demand rule update is requested, WinSuricata automatically installs Cygwin and the packages required to process Suricata rules. Once this installation has been completed, Cygwin remains installed on the system. It does not need to be reinstalled every time the rules are updated. Subsequent rule updates use the existing Cygwin environment and execute suricata-update directly through that environment.

Full suricata-update Functionality

An important advantage of this approach is that WinSuricata is not creating a limited or proprietary replacement for suricata-update. The official utility is being used to perform the rule update.

This preserves the functionality provided by suricata-update, including rule-source management and the ability to control which rules are enabled or disabled. The Suricata documentation specifically identifies suricata-update as the official mechanism for managing rules and provides functionality for updating sources, enabling sources, disabling rules, and rebuilding the active ruleset.

The result is a practical solution for Windows installations: Suricata continues to run natively on Windows, while the rule-management operation is provided with a Unix-compatible execution environment when an update is required.

On-Demand Rule Updates

After the initial installation of Cygwin, the WinSuricata user can perform subsequent rule updates on demand without reinstalling the supporting environment. The process is therefore divided into two stages:

Initial WinSuricata Installation

• Suricata is installed and configured.

• An initial rules update is performed.

• The system is prepared for normal operation.

First On-Demand Rule Update

• WinSuricata detects that the Cygwin rule-update environment is not yet installed.

• Cygwin is installed.

• Required packages and dependencies are installed.

• The official suricata-update utility is executed through Cygwin.

• The updated Suricata rules are placed into the WinSuricata rules environment.

Future Rule Updates

• The existing Cygwin installation is reused.

• No Cygwin reinstallation is required.

• The official suricata-update utility is executed again.

• The user can perform additional rule updates whenever needed.

Why WinSuricata Uses This Approach

The objective is not to work around Suricata itself. The objective is to provide Windows users with a reliable path to the same rule-management functionality that Suricata users on Unix/Linux systems have available.

The Suricata project continues to recognize Windows rule-management limitations. In a recent developer discussion, the Suricata team specifically identified the Python implementation and the lack of Windows-specific expertise as reasons that suricata-update has not been well supported on Windows, while also noting that work toward a future Rust-based implementation with Windows as a first-class concern is underway.

Until native Windows rule management provides equivalent reliability and functionality, WinSuricata's Cygwin-based approach provides a practical bridge. It allows Windows users to remain on a native Windows Suricata deployment while still having access to the established suricata-update rule-management workflow.

In short, WinSuricata does not replace suricata-update—it provides the environment needed to run it reliably on Windows. This gives WinSuricata users an ongoing, on-demand rule-update capability while preserving the functionality and rule-management model used by the Suricata project on Unix/Linux platforms.

Each log provides a detailed record of the installation process, including initialization, environment validation, prerequisite checks, component downloads, feature provisioning, configuration, service installation, and final deployment status. They also capture console output, installation progress, and any warnings or errors encountered during execution.

The logs are provided for each supported installation configuration to demonstrate the framework's deployment process and provide a reference for reviewing, troubleshooting, and verifying successful installations.

Windows Workstation vs. Windows Server

The deployment process is virtually identical across Windows Workstation and Windows Server environments. 

Installation Guide

The latest available installation guide is also included as an attachment for reference. However, please be aware that the attached copy may not reflect the most current revision of the installer.

Always use the installation guide included in the Docs folder of the extracted installer package. That copy is distributed with the installer and should be considered the authoritative documentation for that particular release.

The attached logs illustrate the deployment procedures all the while demonstrating how the same automated installation framework handles the necessary environment-specific configuration.

These logs are included to provide transparency into the installation process and allow anyone interested in the project to review the actual execution sequence and results rather than relying solely on a description of the installation procedure.

WinSuricata-Host-Install.log WinSuricata-Console-Install.log WinSuricata-Node-Install.log

WinSuricata-AIO-Install-Guide.md