Complete Host Recovery and Remote Node Reconnection Procedure

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.

If a WinSuricata Host is reinstalled, the Host will generate a new registration key causing the Remote Node's to stop communicating with the newly installed Host.

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.

Keeping Suricata rules current is an important part of maintaining an effective intrusion detection system. WinSuricata performs an initial rule update during the installation process so that the system begins operation with a current ruleset. After the initial installation, however, Windows users can encounter a significant limitation when attempting to run the Suricata suricata-update utility again.

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.

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, recipientaddress, 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.

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

Two Operations Console functions are specifically dependent on detection of the WinSuricata Host/OpenSearch environment:

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.

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.

Function	Standalone Sensor	Host Sensor	Availability Condition
Email Notifications	Available	Available	None
ET Pro / Custom Rule Key	Available	Available	None
Rule Update Scheduling	Available	Available	None
Immediate Rule Update	Available	Available	None
System & Environment Diagnostics	Available	Available	None
Scheduled Task & Settings Removal	Available	Available	None
Service Monitor	Available	Available	None
Cleanup and Restore	If enabled	If enabled	Initial Headless Installer option
OpenSearch PKI Checker	Not available	Available	Host/OpenSearch detection
Add Remote Node	Not available	Available	Host/OpenSearch detection

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.

You failed to follow the tutorial and made this an install that cannot be supported. Go back and start over following the tutorial and this will work so much better. 

You failed to follow the tutorial and made this an install that cannot be supported. Go back and start over following the tutorial and this will work so much better. 

You will need to supply more information and what exactly is not working?

Following requests for enhanced event management, the DB-Maintenance Utility has been updated to include a time-based purge feature. Administrators can now automatically clear database events older than (X) days.

Happy WinSnorting...

This is the execution log output for the Automated Installation Framework of a WinSnort Windows Intrusion Detection System (WinIDS) configured as a remote node sensor. The deployment process is virtually identical for Windows Workstation or Windows Server environments.

MySQL-Output.log PGSQL-Output.log

Opening the Master sensor will display the total number of connected nodes. If a node is missing, it simply means it hasn’t connected yet—this process can take a few minutes.

(Note: MySQL handles this initial connection noticeably faster than PostgreSQL.)

 

 

 

 

This is the execution log output for the Automated Installation Framework of a WinSnort Windows Intrusion Detection System (WinIDS) configured as a Master/Standalone sensor. The deployment process is virtually identical for Windows Workstation or Windows Server environments, with the exception that Server architecture requires a distinct Internet Information Services (IIS) feature provisioning step.

Output.log

This is the execution log output for the Automated Installation Framework of a WinSnort Windows Intrusion Detection System (WinIDS) configured as a Master/Standalone sensor. The deployment process is virtually identical for Windows Workstation or Windows Server environments, with the exception that Server architecture requires a distinct Internet Information Services (IIS) feature provisioning step.

Output.log

This is the execution log output for the Automated Installation Framework of a WinSnort Windows Intrusion Detection System (WinIDS) configured as a Master/Standalone sensor. The deployment process is virtually identical for Windows Workstation or Windows Server environments, with the exception that Server architecture requires a distinct Internet Information Services (IIS) feature provisioning step.

Output.log

This is the execution log output for the Automated Installation Framework of a WinSnort Windows Intrusion Detection System (WinIDS) configured as a Master/Standalone sensor. The deployment process is virtually identical for Windows Workstation or Windows Server environments, with the exception that Server architecture requires a distinct Internet Information Services (IIS) feature provisioning step.

 

output.log

WinSnort.com is a premier resource dedicated to the advancement of network security through the WinIDS (Windows Intrusion Detection System) stack. Our mission is to provide the security community with the tools, documentation, and automation necessary to deploy professional-grade intrusion detection and prevention systems on Windows platforms.

At the core of our platform is the WinIDS Automated Deployment Framework, a comprehensive suite designed to streamline the installation and configuration of industry-standard security tools. We focus on the seamless integration of:

• Snort: The world's most widely deployed IDS/IPS engine.

• Barnyard2: For efficient spooling and processing of security event data.

• Database Integration: Optimized configurations for MySQL and PostgreSQL backends.

• PulledPork: Automated rule management and synchronization.

• Web Consoles: Professional deployment of Apache2 and IIS environments for real-time monitoring.

Our Mission

We believe in empowering security administrators and researchers with automated, reliable, and high-performance security solutions. By moving away from complex manual setups, WinSnort allows users to focus on what matters most: identifying threats and securing their network infrastructure.

The WinIDS Framework

Our latest project, WinIDS v4.1, represents a ground-up rewrite of our deployment scripts, utilizing PowerShell and advanced automation to ensure a "plug-and-play" experience for complex security environments. From local sensor management to remote node initialization, we provide the technical blueprints for a robust defense-in-depth strategy.

Community & Innovation

Beyond software, WinSnort.com serves as a hub for tutorials, technical documentation, and community support. Whether you are a seasoned systems administrator or a security enthusiast, our resources are crafted to help you master the intricacies of the Snort ecosystem.

The WinIDS installation includes a Rules Updater utility (located in the WinSnort group in the Start Menu). By default, this utility performs a standard rule sync with Sourcefire and applies updates automatically.

For administrators who require remote monitoring, the utility includes an optional Email Utility. When activated, it sends a status report to a designated email address, confirming whether rules were updated, already current, or if a validation error occurred.

Configuration Procedure

To activate and configure the email notification system, follow these steps:

1. Open the Script for Editing

Navigate to your WinIDS installation directory and locate the PowerShell script:

• Path: \scripts\rules-update.ps1
• Action: Right-click the file and select Edit (or open it with Notepad/VS Code).

2. Enable the Mail Utility

Locate the User Configuration section at the top of the script. Change the $sendmail value from 0 to 1:

$sendmail = 1  # Activates the email reporting feature

3. Configure SMTP Settings

Input your mail server details between the quotes in the configuration block:

• $smtpServer: Your mail server address (e.g., smtp.gmail.com or internal relay IP).
• $smtpPort: Use 587 for SSL/TLS or 25 for standard internal relays.
• $smtpUser / $smtpPassword: Enter valid credentials if your server requires authentication.
• $from / $to: Enter the sender and recipient email addresses.

4. Save and Test

1. Save the file.
2. Open the Start Menu and navigate to the WinSnort group.
3. Click the Rules Updater link to execute the script.
4. Observe the console output. If successful, you will see:

An Email report of the Rules update has been sent...

Troubleshooting & Support

• Execution Policy: Ensure the script is run with Administrative privileges.
• Port Blocking: If using Port 25, ensure your antivirus or firewall is not blocking outbound SMTP traffic from PowerShell.
• Logs: Check the \pulledpork\log\ folder for detailed execution logs if an update fails.

Technical Support:

Issues during setup, please visit the WinSnort.com Forums under the Auto-Installer section for community-led support and troubleshooting tips.

You will need to bridge the two NIC's and in Windows 10 do it as below:

Bridging Your Internet Connections on Windows 10

Step 1: Go to your Control Panel from the Start menu.

Step 2: Navigate to Network Connections.

Step 3: Click on the first NIC that you want to bridge.

Step 4: Hold down the CTRL key while clicking on the second NIC that you want to bridge.

Step 5: Right-click on one of the selected NICs and click "Bridge Connections."

I have not tested the above on anything other than Windows 10.

To test the MySQL database server and authentications open a CMD window with Administrator access and type d:\activators\db_tools\test_mysql-php7.php

The problem is that it is not finding the base.php file, or possibly the base_conf.php file? It has to find the file first before trying to execute it.

Not sure if it could be the problem but make sure the config file is correctly named: base_conf.php

Maybe some sort of a permission problem with the files in the base folder?

Not sure how a permission problem could be the problem when the test.php file is working.

You are going to have issues with WinPcap and Npcap both installed. Use either one but not both.

Note: Uninstall both and then install the one you are going to use. Make sure Snort is not running when you uninstall.

Does this work: http://winids/base.php

I'm not sur but there appears to be a formatting error with the Apache config. Try the attached one.

Also try moving the test.php file to the base folder and then try http://winids/test.php

httpd.conf

On 11/25/2019 at 5:22 PM, 7rrivera7 said:

It turned out to be permissions to test.php. I had to grant permission to the DefaultAppPool from the top of the INETPUB folder

 

That is not normal?

The only thing I can tell is that it's not allowing you to access the test.php because you don't have sufficient permissions?

What happens if you remove the test.php file and try accessing it when it is missing. You should get the same error?

Do you have a space in the word base?

Look at your Physical Path - It appears you have a space in base -> ba se