Morpheus

===========================================================
WinIDS v4.1 Deployment Framework - Remote Node & Host Conversion Install Guide Copyright © 2026 WinSnort.com | Michael Steele ===========================================================

OPERATIONAL OVERVIEW
This toolkit provides the automated framework required to convert a standalone sensor into a Master Host and facilitate the deployment of WinIDS Remote Nodes. This architecture enables decentralized packet inspection paired with centralized database logging.

ARCHITECTURAL PREREQUISITES
* Active Instance : A functional Standalone WinIDS Sensor is required. * Node Conversion : This process upgrades a Standalone Sensor to a Master Management Server role and initializes the Remote Node environment. -------------------------------------------------------------------------------
PHASE I: PRE-DEPLOYMENT SPECIFICATIONS
-------------------------------------------------------------------------------
* Target Environment : Optimized for clean OS installations. * Archive Integrity : Extract all package contents to a dedicated directory. * Archive Security : w1nsn03t.c0m -------------------------------------------------------------------------------
PHASE II: MASTER SERVER PROVISIONING
-------------------------------------------------------------------------------
To allow inbound database traffic, the Master Management Server must be provisioned prior to remote node initialization. Ensure you have the Remote Node IP address ready before beginning.

Access the $WinIDSRoot/tools directory on the Master Host.

Right-click 'InitializeNode.exe' and select "Run as Administrator" and enter the IP of the remote Node at the input prompt.

TECHNICAL IMPACT: This utility automates Windows Firewall scoping and configures database permissions for that specified $RemoteIP. Upon completion, the executable will display the Master Host’s IP Address and Database Port. Record these values; they are required for Phases III and IV.

Note: Run this process for every new remote node added to the environment.

-------------------------------------------------------------------------------
PHASE III: CONNECTIVITY & VALIDATION
-------------------------------------------------------------------------------
Perform these steps on the Remote Node. You will need the Master Host IP and Database Port recorded during Phase II.

Access the local extraction directory on the Remote Node.

Right-click 'Node2Host.exe' and select "Run as Administrator" and enter the IP of the Master Host. Next it will ask for the Database port. If using the default port, press [Enter] to initiate an automated port scan. If using a custom port, type the port number and press [Enter].

CRITICAL: Connection verification is mandatory. If the handshake fails, troubleshoot the network path before proceeding to Phase IV.

-------------------------------------------------------------------------------
PHASE IV: REMOTE SENSOR DEPLOYMENT
-------------------------------------------------------------------------------
Locate the config.conf file in the local extraction directory on the Remote Node.

Open it with a text editor (such as Notepad) and configure the following variables:
$TempDir = "" # Path for temporary installation/download files (e.g., "D:\files") $WinIDSRoot = "" # Primary home directory for WinIDS installation (e.g., "D:\home") $Oinkcode = "" # Your 40-character Snort.org Oinkcode for rule updates $SensorName = "" # A unique name for this Node Sensor (e.g., "NodeName") $EnableAllRules = $true # Set to $false to disable rule testing and high-volume logging $EnableRestorePoint = $true # Set to $false to skip System Restore point creation The credentials below must match the SnortUser and SnortPass defined during the Master Host configuration. These allow Barnyard2 to authenticate with the Master ALERT database.
$SnortUser = "snort" # Master Host ALERT Database Username $SnortPass = "l0gg3r" # Master Host ALERT Database Password Input the MasterHostIP and MasterHostPort acquired in Phase II to establish the network link between the Remote Node and the Master Host.
$MasterHostIP = "" # Master Host IP Address (e.g., "192.168.1.50") $MasterHostPort = "" # Master Host Database Port (e.g., "3306") Save all changes to config.conf and close the editor.

Right-click Installer.exe and select "Run as Administrator" to begin the installation.

DEPLOYMENT DURATION ESTIMATES
Completion times vary based on the selected database engine and host operating system. The following estimates are based on standard network throughput and hardware resource availability. Workstation standalone or node deployments generally complete in ~15 minutes. Server host deployments generally complete in ~40 minutes. Performance is directly influenced by available system resources and network bandwidth.

RECOVERY AND RESILIENCY LOGIC
The WinIDS framework is designed with automated resume capability. In the event of a package acquisition failure, you will need to manually download the required asset to your defined $TempDir and re-initialize the installer. The framework will automatically detect the local file and resume the deployment. Do not terminate the installer during active system modifications or registry updates to prevent system corruption.

SYSTEM RESTORE OPERATIONS
In workstation environments, when EnableRestorePoint is active, the installer generates a system restore point prior to setup. This process initializes the required snapshot services, clears existing restore points, and creates a fresh baseline snapshot before cycling the services back to manual. This specific sequence ensures the "first-run" pre-installation snapshot remains protected from automatic purging.

If a valid "first-run" snapshot is already present—often the result of a previous removal via the RestorePoint utility—the installer will bypass the creation step to preserve the original baseline for the new installation.

SYSTEM RECOVERY PROCESS
The RestorePoint utility relies on the initial "first-run" snapshot to execute a rollback. If this snapshot is detected, the utility will revert the system to its original pre-installation state. However, if the snapshot is missing, the process will automatically terminate to prevent system instability.

Without a valid snapshot, a clean rollback cannot be performed. In this scenario, you must manually resolve the conflict, restore from a full system backup, or initiate a fresh installation. Note that while the recovery process leaves $WinIDSRoot and $TempDir untouched, performing a new installation will permanently delete all data within the $WinIDSRoot directory.

DATA INTEGRITY
The System Restore feature is intended for configuration recovery and is not a replacement for a comprehensive backup solution. System Restore services are set to manual and toggled as needed. Windows Restore Points are transient and may be purged during routine maintenance cycles if those services are running.

ENVIRONMENTAL CONSTRAINTS & BEST PRACTICES
Server Deployments: Since Windows Server architectures do not natively support System Restore points, this feature is automatically bypassed during Server OS deployments.

PULLEDPORK RULE MAINTENANCE
The original PulledPork by Shirkdog is housed within a sophisticated wrapper, accessible via the WinSnort Start Menu. While the utility is designed for "out-of-the-box" functionality with no manual configuration required, the wrapper offers a highly verbose interface with integrated system checks. Every update attempt is documented in the PulledPork log folder. To maintain system stability, the utility automatically rolls back to the last known-good rule set if an update fails.

The Rule Updater includes a built-in scheduler with configurable intervals ranging from 15 to 60 minutes. It supports automated retention of successful updates and SMTP email notifications. While "Silent Mode" is available for remote or unmanaged sensors, the updater will default to a verbose display if launched manually from the desktop while in "Silent Mode". If executed in silent mode without SMTP, the system continues to capture errors and failures within the local log files.

-------------------------------------------------------------------------------
PHASE V: POST-DEPLOYMENT MANAGEMENT
-------------------------------------------------------------------------------
Upon successful completion, the WinIDS Management Suite will be accessible via Start Menu > WinSnort. Core utilities include:
* Rules Updater : PulledPork-driven rule-set synchronization. * System Restore : System Restore Point (SRP) Utility (Workstation Only). Although a system reboot is not strictly mandatory, it is recommended to ensure all environment variables are refreshed. Please note that the WinSnort Start Menu group may not appear in the Start Menu until a system restart has been completed.

-------------------------------------------------------------------------------
PHASE VI: POST-DEPLOYMENT VERIFICATION
-------------------------------------------------------------------------------
Management Server Validation:
1. Launch the WinIDS Console on the Master Management Server.
2. Monitor the "Sensors/Total" telemetry indicator.
3. A successful link displays "2/2" (or greater). Verify that "$SensorName" is actively reporting logs to the centralized dashboard.

===============================================================================
TECHNICAL DOCUMENTATION & SUPPORT: http://winsnort.com ===============================================================================

============================================================
WinIDS v4.1 Deployment Framework - Standalone Sensor Install Guide Copyright © 2026 WinSnort.com | Michael Steele ============================================================

OPERATIONAL OVERVIEW
This package contains a specialized deployment framework for the Windows Intrusion Detection System (WinIDS). It is engineered for high-performance installations on Windows 10/11 and Windows Server (2016-2025) 64-bit.

-------------------------------------------------------------------------------
PHASE I: PRE-DEPLOYMENT SPECIFICATIONS
-------------------------------------------------------------------------------
* Target Environment : Optimized for clean OS installations. * Archive Integrity : Extract all package contents to a dedicated directory. * Archive Security : w1nsn03t.c0m -------------------------------------------------------------------------------
PHASE II: STANDALONE SENSOR DEPLOYMENT
-------------------------------------------------------------------------------
Locate the config.conf file in the local extraction directory on the Host.

Open it with a text editor (such as Notepad) and configure the following variables:
$TempDir = "" # Path for temporary installation/download files (e.g., "D:\files") $WinIDSRoot = "" # Primary home directory for WinIDS installation (e.g., "D:\home") $Oinkcode = "" # Your 40-character Snort.org Oinkcode for rule updates $SensorName = "" # A unique name for this Host Sensor (e.g., "HostName") $EnableAllRules = $true # Set to $false to disable rule testing and high-volume logging $EnableRestorePoint = $true # Set to $false to skip System Restore point creation $SnortUser = "snort" # Master Host ALERT Database Username $SnortPass = "l0gg3r" # Master Host ALERT Database Password $RootUser = "root" # Master Host (Root) MySQL/PostgreSQL Database Username $RootPass = "d1ngd0ng" # Master Host (Root) MySQL/PostgreSQL Database Password Save all changes to config.conf and close the editor.

Right-click Installer.exe and select "Run as Administrator" to begin the installation.

-------------------------------------------------------------------------------
PHASE III: PARAMETER CONFIGURATION
-------------------------------------------------------------------------------
SECURITY RECOMMENDATIONS
The Username and password values above are defaults. For production environments, it is strongly advised to update these credentials to enhance network security but if there is any doubt, leave them as is.

DATABASE Roles
The SnortUser/Pass credentials are used by Barnyard2 to authenticate with the ALERT database. These credentials also facilitate the connection between remote nodes and the Master Host across the LAN/WAN.

The RootUser/Pass credentials are administrative and used for command-line database management post-installation and also used for the Database manager utility.

DOCUMENTATION
Use caution when modifying default settings. Ensure all changes are recorded for future administrative reference.

DEPLOYMENT DURATION ESTIMATES
Completion times vary based on the selected database engine and host operating system. The following estimates are based on standard network throughput and hardware resource availability. Workstation standalone or node deployments generally complete in ~15 minutes. Server host deployments generally complete in ~40 minutes. Performance is directly influenced by available system resources and network bandwidth.

RECOVERY AND RESILIENCY LOGIC
The WinIDS framework is designed with automated resume capability. In the event of a package acquisition failure, you will need to manually download the required asset to your defined $TempDir and re-initialize the installer. The framework will automatically detect the local file and resume the deployment. Do not terminate the installer during active system modifications or registry updates to prevent system corruption.

SYSTEM RESTORE OPERATIONS
In workstation environments, when EnableRestorePoint is active, the installer generates a system restore point prior to setup. This process initializes the required snapshot services, clears existing restore points, and creates a fresh baseline snapshot before cycling the services back to manual. This specific sequence ensures the "first-run" pre-installation snapshot remains protected from automatic purging.

If a valid "first-run" snapshot is already present—often the result of a previous removal via the RestorePoint utility—the installer will bypass the creation step to preserve the original baseline for the new installation.

SYSTEM RECOVERY PROCESS
The RestorePoint utility relies on the initial "first-run" snapshot to execute a rollback. If this snapshot is detected, the utility will revert the system to its original pre-installation state. However, if the snapshot is missing, the process will automatically terminate to prevent system instability.

Without a valid snapshot, a clean rollback cannot be performed. In this scenario, you must manually resolve the conflict, restore from a full system backup, or initiate a fresh installation. Note that while the recovery process leaves $WinIDSRoot and $TempDir untouched, performing a new installation will permanently delete all data within the $WinIDSRoot directory.

DATA INTEGRITY
The System Restore feature is intended for configuration recovery and is not a replacement for a comprehensive backup solution. System Restore services are set to manual and toggled as needed. Windows Restore Points are transient and may be purged during routine maintenance cycles if those services are running.

ENVIRONMENTAL CONSTRAINTS & BEST PRACTICES
Server Deployments: Since Windows Server architectures do not natively support System Restore points, this feature is automatically bypassed during Server OS deployments.

PULLEDPORK RULE MAINTENANCE
The original PulledPork by Shirkdog is housed within a sophisticated wrapper, accessible via the WinSnort Start Menu. While the utility is designed for "out-of-the-box" functionality with no manual configuration required, the wrapper offers a highly verbose interface with integrated system checks. Every update attempt is documented in the PulledPork log folder. To maintain system stability, the utility automatically rolls back to the last known-good rule set if an update fails.

The Rule Updater includes a built-in scheduler with configurable intervals ranging from 15 to 60 minutes. It supports automated retention of successful updates and SMTP email notifications. While "Silent Mode" is available for remote or unmanaged sensors, the updater will default to a verbose display if launched manually from the desktop while in "Silent Mode". If executed in silent mode without SMTP, the system continues to capture errors and failures within the local log files.

-------------------------------------------------------------------------------
PHASE IV: POST-DEPLOYMENT MANAGEMENT
-------------------------------------------------------------------------------
Upon successful completion, the WinIDS Management Suite will be accessible via Start Menu > WinSnort. Core utilities include:
* WinIDS Console : Real-time telemetry, event monitoring, and analysis. * Rules Updater : PulledPork-driven rule-set synchronization. * System Restore : System Restore Point (SRP) Utility (Workstation Only). * Database Utility : Database maintenance utility. Although a system reboot is not strictly mandatory, it is recommended to ensure all environment variables are refreshed. Please note that the WinSnort Start Menu group may not appear in the Start Menu until a system restart has been completed.

===============================================================================
TECHNICAL DOCUMENTATION & SUPPORT: http://winsnort.com ===============================================================================

============================================================
WinIDS v4.1 Deployment Framework - Standalone Sensor Install Guide Copyright © 2026 WinSnort.com | Michael Steele ============================================================

OPERATIONAL OVERVIEW
This package contains a specialized deployment framework for the Windows Intrusion Detection System (WinIDS). It is engineered for high-performance installations on Windows 10/11 and Windows Server (2016-2025) 64-bit.

-------------------------------------------------------------------------------
PHASE I: PRE-DEPLOYMENT SPECIFICATIONS
-------------------------------------------------------------------------------
* Target Environment : Optimized for clean OS installations. * Archive Integrity : Extract all package contents to a dedicated directory. * Archive Security : w1nsn03t.c0m -------------------------------------------------------------------------------
PHASE II: STANDALONE SENSOR DEPLOYMENT
-------------------------------------------------------------------------------
Locate the config.conf file in the local extraction directory on the Host.

Open it with a text editor (such as Notepad) and configure the following variables:
$TempDir = "" # Path for temporary installation/download files (e.g., "D:\files") $WinIDSRoot = "" # Primary home directory for WinIDS installation (e.g., "D:\home") $Oinkcode = "" # Your 40-character Snort.org Oinkcode for rule updates $SensorName = "" # A unique name for this Host Sensor (e.g., "HostName") $EnableAllRules = $true # Set to $false to disable rule testing and high-volume logging $EnableRestorePoint = $true # Set to $false to skip System Restore point creation $SnortUser = "snort" # Master Host ALERT Database Username $SnortPass = "l0gg3r" # Master Host ALERT Database Password $RootUser = "root" # Master Host (Root) MySQL/PostgreSQL Database Username $RootPass = "d1ngd0ng" # Master Host (Root) MySQL/PostgreSQL Database Password Save all changes to config.conf and close the editor.

Right-click Installer.exe and select "Run as Administrator" to begin the installation.

-------------------------------------------------------------------------------
PHASE III: PARAMETER CONFIGURATION
-------------------------------------------------------------------------------
SECURITY RECOMMENDATIONS
The Username and password values above are defaults. For production environments, it is strongly advised to update these credentials to enhance network security but if there is any doubt, leave them as is.

DATABASE Roles
The SnortUser/Pass credentials are used by Barnyard2 to authenticate with the ALERT database. These credentials also facilitate the connection between remote nodes and the Master Host across the LAN/WAN.

The RootUser/Pass credentials are administrative and used for command-line database management post-installation and also used for the Database manager utility.

DOCUMENTATION
Use caution when modifying default settings. Ensure all changes are recorded for future administrative reference.

DEPLOYMENT DURATION ESTIMATES
Completion times vary based on the selected database engine and host operating system. The following estimates are based on standard network throughput and hardware resource availability. Workstation standalone or node deployments generally complete in ~15 minutes. Server host deployments generally complete in ~40 minutes. Performance is directly influenced by available system resources and network bandwidth.

RECOVERY AND RESILIENCY LOGIC
The WinIDS framework is designed with automated resume capability. In the event of a package acquisition failure, you will need to manually download the required asset to your defined $TempDir and re-initialize the installer. The framework will automatically detect the local file and resume the deployment. Do not terminate the installer during active system modifications or registry updates to prevent system corruption.

SYSTEM RESTORE OPERATIONS
In workstation environments, when EnableRestorePoint is active, the installer generates a system restore point prior to setup. This process initializes the required snapshot services, clears existing restore points, and creates a fresh baseline snapshot before cycling the services back to manual. This specific sequence ensures the "first-run" pre-installation snapshot remains protected from automatic purging.

If a valid "first-run" snapshot is already present—often the result of a previous removal via the RestorePoint utility—the installer will bypass the creation step to preserve the original baseline for the new installation.

SYSTEM RECOVERY PROCESS
The RestorePoint utility relies on the initial "first-run" snapshot to execute a rollback. If this snapshot is detected, the utility will revert the system to its original pre-installation state. However, if the snapshot is missing, the process will automatically terminate to prevent system instability.

Without a valid snapshot, a clean rollback cannot be performed. In this scenario, you must manually resolve the conflict, restore from a full system backup, or initiate a fresh installation. Note that while the recovery process leaves $WinIDSRoot and $TempDir untouched, performing a new installation will permanently delete all data within the $WinIDSRoot directory.

DATA INTEGRITY
The System Restore feature is intended for configuration recovery and is not a replacement for a comprehensive backup solution. System Restore services are set to manual and toggled as needed. Windows Restore Points are transient and may be purged during routine maintenance cycles if those services are running.

ENVIRONMENTAL CONSTRAINTS & BEST PRACTICES
Server Deployments: Since Windows Server architectures do not natively support System Restore points, this feature is automatically bypassed during Server OS deployments.

PULLEDPORK RULE MAINTENANCE
The original PulledPork by Shirkdog is housed within a sophisticated wrapper, accessible via the WinSnort Start Menu. While the utility is designed for "out-of-the-box" functionality with no manual configuration required, the wrapper offers a highly verbose interface with integrated system checks. Every update attempt is documented in the PulledPork log folder. To maintain system stability, the utility automatically rolls back to the last known-good rule set if an update fails.

The Rule Updater includes a built-in scheduler with configurable intervals ranging from 15 to 60 minutes. It supports automated retention of successful updates and SMTP email notifications. While "Silent Mode" is available for remote or unmanaged sensors, the updater will default to a verbose display if launched manually from the desktop while in "Silent Mode". If executed in silent mode without SMTP, the system continues to capture errors and failures within the local log files.

-------------------------------------------------------------------------------
PHASE IV: POST-DEPLOYMENT MANAGEMENT
-------------------------------------------------------------------------------
Upon successful completion, the WinIDS Management Suite will be accessible via Start Menu > WinSnort. Core utilities include:
* WinIDS Console : Real-time telemetry, event monitoring, and analysis. * Rules Updater : PulledPork-driven rule-set synchronization. * System Restore : System Restore Point (SRP) Utility (Workstation Only). * Database Utility : Database maintenance utility. Although a system reboot is not strictly mandatory, it is recommended to ensure all environment variables are refreshed. Please note that the WinSnort Start Menu group may not appear in the Start Menu until a system restart has been completed.

===============================================================================
TECHNICAL DOCUMENTATION & SUPPORT: http://winsnort.com ===============================================================================

============================================================
WinIDS v4.1 Deployment Framework - Standalone Sensor Install Guide Copyright © 2026 WinSnort.com | Michael Steele ============================================================

OPERATIONAL OVERVIEW
This package contains a specialized deployment framework for the Windows Intrusion Detection System (WinIDS). It is engineered for high-performance installations on Windows 10/11 and Windows Server (2016-2025) 64-bit.

-------------------------------------------------------------------------------
PHASE I: PRE-DEPLOYMENT SPECIFICATIONS
-------------------------------------------------------------------------------
* Target Environment : Optimized for clean OS installations. * Archive Integrity : Extract all package contents to a dedicated directory. * Archive Security : w1nsn03t.c0m -------------------------------------------------------------------------------
PHASE II: STANDALONE SENSOR DEPLOYMENT
-------------------------------------------------------------------------------
Locate the config.conf file in the local extraction directory on the Host.

Open it with a text editor (such as Notepad) and configure the following variables:
$TempDir = "" # Path for temporary installation/download files (e.g., "D:\files") $WinIDSRoot = "" # Primary home directory for WinIDS installation (e.g., "D:\home") $Oinkcode = "" # Your 40-character Snort.org Oinkcode for rule updates $SensorName = "" # A unique name for this Host Sensor (e.g., "HostName") $EnableAllRules = $true # Set to $false to disable rule testing and high-volume logging $EnableRestorePoint = $true # Set to $false to skip System Restore point creation $SnortUser = "snort" # Master Host ALERT Database Username $SnortPass = "l0gg3r" # Master Host ALERT Database Password $RootUser = "root" # Master Host (Root) MySQL/PostgreSQL Database Username $RootPass = "d1ngd0ng" # Master Host (Root) MySQL/PostgreSQL Database Password Save all changes to config.conf and close the editor.

Right-click Installer.exe and select "Run as Administrator" to begin the installation.

-------------------------------------------------------------------------------
PHASE III: PARAMETER CONFIGURATION
-------------------------------------------------------------------------------
SECURITY RECOMMENDATIONS
The Username and password values above are defaults. For production environments, it is strongly advised to update these credentials to enhance network security but if there is any doubt, leave them as is.

DATABASE Roles
The SnortUser/Pass credentials are used by Barnyard2 to authenticate with the ALERT database. These credentials also facilitate the connection between remote nodes and the Master Host across the LAN/WAN.

The RootUser/Pass credentials are administrative and used for command-line database management post-installation and also used for the Database manager utility.

DOCUMENTATION
Use caution when modifying default settings. Ensure all changes are recorded for future administrative reference.

DEPLOYMENT DURATION ESTIMATES
Completion times vary based on the selected database engine and host operating system. The following estimates are based on standard network throughput and hardware resource availability. Workstation standalone or node deployments generally complete in ~15 minutes. Server host deployments generally complete in ~40 minutes. Performance is directly influenced by available system resources and network bandwidth.

RECOVERY AND RESILIENCY LOGIC
The WinIDS framework is designed with automated resume capability. In the event of a package acquisition failure, you will need to manually download the required asset to your defined $TempDir and re-initialize the installer. The framework will automatically detect the local file and resume the deployment. Do not terminate the installer during active system modifications or registry updates to prevent system corruption.

SYSTEM RESTORE OPERATIONS
In workstation environments, when EnableRestorePoint is active, the installer generates a system restore point prior to setup. This process initializes the required snapshot services, clears existing restore points, and creates a fresh baseline snapshot before cycling the services back to manual. This specific sequence ensures the "first-run" pre-installation snapshot remains protected from automatic purging.

If a valid "first-run" snapshot is already present—often the result of a previous removal via the RestorePoint utility—the installer will bypass the creation step to preserve the original baseline for the new installation.

SYSTEM RECOVERY PROCESS
The RestorePoint utility relies on the initial "first-run" snapshot to execute a rollback. If this snapshot is detected, the utility will revert the system to its original pre-installation state. However, if the snapshot is missing, the process will automatically terminate to prevent system instability.

Without a valid snapshot, a clean rollback cannot be performed. In this scenario, you must manually resolve the conflict, restore from a full system backup, or initiate a fresh installation. Note that while the recovery process leaves $WinIDSRoot and $TempDir untouched, performing a new installation will permanently delete all data within the $WinIDSRoot directory.

DATA INTEGRITY
The System Restore feature is intended for configuration recovery and is not a replacement for a comprehensive backup solution. System Restore services are set to manual and toggled as needed. Windows Restore Points are transient and may be purged during routine maintenance cycles if those services are running.

ENVIRONMENTAL CONSTRAINTS & BEST PRACTICES
Server Deployments: Since Windows Server architectures do not natively support System Restore points, this feature is automatically bypassed during Server OS deployments.

PULLEDPORK RULE MAINTENANCE
The original PulledPork by Shirkdog is housed within a sophisticated wrapper, accessible via the WinSnort Start Menu. While the utility is designed for "out-of-the-box" functionality with no manual configuration required, the wrapper offers a highly verbose interface with integrated system checks. Every update attempt is documented in the PulledPork log folder. To maintain system stability, the utility automatically rolls back to the last known-good rule set if an update fails.

The Rule Updater includes a built-in scheduler with configurable intervals ranging from 15 to 60 minutes. It supports automated retention of successful updates and SMTP email notifications. While "Silent Mode" is available for remote or unmanaged sensors, the updater will default to a verbose display if launched manually from the desktop while in "Silent Mode". If executed in silent mode without SMTP, the system continues to capture errors and failures within the local log files.

-------------------------------------------------------------------------------
PHASE IV: POST-DEPLOYMENT MANAGEMENT
-------------------------------------------------------------------------------
Upon successful completion, the WinIDS Management Suite will be accessible via Start Menu > WinSnort. Core utilities include:
* WinIDS Console : Real-time telemetry, event monitoring, and analysis. * Rules Updater : PulledPork-driven rule-set synchronization. * System Restore : System Restore Point (SRP) Utility (Workstation Only). * Database Utility : Database maintenance utility. Although a system reboot is not strictly mandatory, it is recommended to ensure all environment variables are refreshed. Please note that the WinSnort Start Menu group may not appear in the Start Menu until a system restart has been completed.

===============================================================================
TECHNICAL DOCUMENTATION & SUPPORT: http://winsnort.com ===============================================================================

============================================================
WinIDS v4.1 Deployment Framework - Standalone Sensor Install Guide Copyright © 2026 WinSnort.com | Michael Steele ============================================================

OPERATIONAL OVERVIEW
This package contains a specialized deployment framework for the Windows Intrusion Detection System (WinIDS). It is engineered for high-performance installations on Windows 10/11 and Windows Server (2016-2025) 64-bit.

-------------------------------------------------------------------------------
PHASE I: PRE-DEPLOYMENT SPECIFICATIONS
-------------------------------------------------------------------------------
* Target Environment : Optimized for clean OS installations. * Archive Integrity : Extract all package contents to a dedicated directory. * Archive Security : w1nsn03t.c0m -------------------------------------------------------------------------------
PHASE II: STANDALONE SENSOR DEPLOYMENT
-------------------------------------------------------------------------------
Locate the config.conf file in the local extraction directory on the Host.

Open it with a text editor (such as Notepad) and configure the following variables:
$TempDir = "" # Path for temporary installation/download files (e.g., "D:\files") $WinIDSRoot = "" # Primary home directory for WinIDS installation (e.g., "D:\home") $Oinkcode = "" # Your 40-character Snort.org Oinkcode for rule updates $SensorName = "" # A unique name for this Host Sensor (e.g., "HostName") $EnableAllRules = $true # Set to $false to disable rule testing and high-volume logging $EnableRestorePoint = $true # Set to $false to skip System Restore point creation $SnortUser = "snort" # Master Host ALERT Database Username $SnortPass = "l0gg3r" # Master Host ALERT Database Password $RootUser = "root" # Master Host (Root) MySQL/PostgreSQL Database Username $RootPass = "d1ngd0ng" # Master Host (Root) MySQL/PostgreSQL Database Password Save all changes to config.conf and close the editor.

Right-click Installer.exe and select "Run as Administrator" to begin the installation.

-------------------------------------------------------------------------------
PHASE III: PARAMETER CONFIGURATION
-------------------------------------------------------------------------------
SECURITY RECOMMENDATIONS
The Username and password values above are defaults. For production environments, it is strongly advised to update these credentials to enhance network security but if there is any doubt, leave them as is.

DATABASE Roles
The SnortUser/Pass credentials are used by Barnyard2 to authenticate with the ALERT database. These credentials also facilitate the connection between remote nodes and the Master Host across the LAN/WAN.

The RootUser/Pass credentials are administrative and used for command-line database management post-installation and also used for the Database manager utility.

DOCUMENTATION
Use caution when modifying default settings. Ensure all changes are recorded for future administrative reference.

DEPLOYMENT DURATION ESTIMATES
Completion times vary based on the selected database engine and host operating system. The following estimates are based on standard network throughput and hardware resource availability. Workstation standalone or node deployments generally complete in ~15 minutes. Server host deployments generally complete in ~40 minutes. Performance is directly influenced by available system resources and network bandwidth.

RECOVERY AND RESILIENCY LOGIC
The WinIDS framework is designed with automated resume capability. In the event of a package acquisition failure, you will need to manually download the required asset to your defined $TempDir and re-initialize the installer. The framework will automatically detect the local file and resume the deployment. Do not terminate the installer during active system modifications or registry updates to prevent system corruption.

SYSTEM RESTORE OPERATIONS
In workstation environments, when EnableRestorePoint is active, the installer generates a system restore point prior to setup. This process initializes the required snapshot services, clears existing restore points, and creates a fresh baseline snapshot before cycling the services back to manual. This specific sequence ensures the "first-run" pre-installation snapshot remains protected from automatic purging.

If a valid "first-run" snapshot is already present—often the result of a previous removal via the RestorePoint utility—the installer will bypass the creation step to preserve the original baseline for the new installation.

SYSTEM RECOVERY PROCESS
The RestorePoint utility relies on the initial "first-run" snapshot to execute a rollback. If this snapshot is detected, the utility will revert the system to its original pre-installation state. However, if the snapshot is missing, the process will automatically terminate to prevent system instability.

Without a valid snapshot, a clean rollback cannot be performed. In this scenario, you must manually resolve the conflict, restore from a full system backup, or initiate a fresh installation. Note that while the recovery process leaves $WinIDSRoot and $TempDir untouched, performing a new installation will permanently delete all data within the $WinIDSRoot directory.

DATA INTEGRITY
The System Restore feature is intended for configuration recovery and is not a replacement for a comprehensive backup solution. System Restore services are set to manual and toggled as needed. Windows Restore Points are transient and may be purged during routine maintenance cycles if those services are running.

ENVIRONMENTAL CONSTRAINTS & BEST PRACTICES
Server Deployments: Since Windows Server architectures do not natively support System Restore points, this feature is automatically bypassed during Server OS deployments.

PULLEDPORK RULE MAINTENANCE
The original PulledPork by Shirkdog is housed within a sophisticated wrapper, accessible via the WinSnort Start Menu. While the utility is designed for "out-of-the-box" functionality with no manual configuration required, the wrapper offers a highly verbose interface with integrated system checks. Every update attempt is documented in the PulledPork log folder. To maintain system stability, the utility automatically rolls back to the last known-good rule set if an update fails.

The Rule Updater includes a built-in scheduler with configurable intervals ranging from 15 to 60 minutes. It supports automated retention of successful updates and SMTP email notifications. While "Silent Mode" is available for remote or unmanaged sensors, the updater will default to a verbose display if launched manually from the desktop while in "Silent Mode". If executed in silent mode without SMTP, the system continues to capture errors and failures within the local log files.

-------------------------------------------------------------------------------
PHASE IV: POST-DEPLOYMENT MANAGEMENT
-------------------------------------------------------------------------------
Upon successful completion, the WinIDS Management Suite will be accessible via Start Menu > WinSnort. Core utilities include:
* WinIDS Console : Real-time telemetry, event monitoring, and analysis. * Rules Updater : PulledPork-driven rule-set synchronization. * System Restore : System Restore Point (SRP) Utility (Workstation Only). * Database Utility : Database maintenance utility. Although a system reboot is not strictly mandatory, it is recommended to ensure all environment variables are refreshed. Please note that the WinSnort Start Menu group may not appear in the Start Menu until a system restart has been completed.

===============================================================================
TECHNICAL DOCUMENTATION & SUPPORT: http://winsnort.com ===============================================================================

This is the latest Windows Intrusion Detection System Core Software Support Pack and is required for all Windows Intrusion Detection Systems (WinIDS) installs.
The Windows Intrusion Detection System (WinIDS) Core Software Support Pack has been password protected.
Wrapper Password: w1nsn03t.c0m
Note: It is highly recommended that the SHA-1 value listed below matched the SHA-1 value of the downloaded Windows Intrusion Detection System (WinIDS) Software Support Pack.
SHA-1 Hash value: E97790D486F522F37B6D5C5035D51084D7F63C23
What's New in Version 4.29.2026
Updates to this Core software Pack:
MySQL has been updated from 8.0.44 to 8.0.46 What's New in Version 3.1.2026
Updates to this Core software Pack:
PostgreSQL has been updated from 18.2-1 to 18.3-1 What's New in Version 2.12.2026
Updates to this Core software Pack:
PostgreSQL has been updated from 18.1-1 to 18.2-1 What's New in Version 1.27.2026
Updates to this Core software Pack:
MySQL has been updated from 8.0.44 to 8.0.45 What's New in Version 1.10.2026
Updates to this Core software Pack:
Apache2 has been updated from 2.4.65-250724 (vs17) to 2.4.66-260107 (vs18) FastCGI ASF module from 2.3.10 (vs17) to 2.3.10 (vs18) Npcap has been updated from 1.85 to 1.86 Visual C++ x86/x64 updated from 2015-2022 to 2017-2026  What's New in Version 12.24.2025
Updates to this Core software Pack:
Updated all the scripts PHP has been updated from 8.4.50 to 8.5.1 What's New in Version 11.21.2025
Updates to this Core software Pack:
PostgreSQL has been updated from 18.0 to 18.1 PHP has been updated from 8.4.13 to 8.5.0 Npcap has been updated from 1.83 to 1.84 What's New in Version 10.22.2025
Updates to this Core software Pack:
MySQL has been updated from 8.0.43 to 8.0.44 PHP has been updated from 8.4.13 to 8.4.14 What's New in Version 10.2.2025
Updates to this Core software Pack:
PostgreSQL has been updated from 17.6 to 18.0 PHP has been updated from 8.4.11 to 8.4.13 Strawberry Perl has been updated from 5.41.2.1 to 5.42.0.1 What's New in Version 7.30.2025
Updates to this Core software Pack:
MySQL has been updated from 8.0.42 to 8.0.43 PHP has been updated from 8.4.10 to 8.4.11 Apache2 has been updated from 2.4.65-250207 to 2.4.65-250724 Barnyard2 recompiled for Database update/s What's New in Version 4.23.2025
Updates to this Core software Pack:
MySQL has been updated from 8.0.41 to 8.0.42 PHP has been updated from 8.4.3 to 8.4.6 Barnyard2 recompiled for Database update/s What's New in Version 2.22.2025
Updates to this Core software Pack:
PostGreSQL has been updated from 17.3 to 17.4 Npcap has been updated from 1.80 to 1.81 Barnyard2 recompiled for Database update/s What's New in Version 2.14.2025
Updates to this Core software Pack:
PostGreSQL has been updated from 17.2 to 17.3 PHP has been updated from 8.4.3 to 8.4.4 Barnyard2 recompiled for Database update/s What's New in Version 2.10.2025
Updates to this Core software Pack:
Added a Powershell script to update the rules from the desktop or silent scheduling with optional emailing reporting hat's New in Version 1.24.2025
Updates to this Core software Pack:
Updated Modder Visual Basic to PowerShell  Updated VS C++ to Latest 2015-2022 PostGreSQL has been updated from 16.3 to 17.2 MySQL has been updated from 8.0.40 to 8.0.41 PHP has been updated from 8.3.7 vs16 to 8.4.3 vs17 npcap has been updated from 1.79 to 1.80 Strawberry Perl has been updated from 5.38.1.1 to 5.40.0.1 Apache has been updated from 2.4.55 VS17 to 2.4.62 VS17 What's New in Version 4.8.2024
Updates to this Core software Pack:
VC_redist_2015-2022.x64 has been updated from 14.38.33133 to 14.38.33135 (Required for Apache2) What's New in Version 2.28.2024
Updates to this Core software Pack:
PostGreSQL has been updated from 16.1 to 16.2 PHP has been updated from 8.2.10 to 8.3.3 Strawberry Perl has been updated from 5.38.1.1 to 5.38.2.2 What's New in Version 1.22.2024
Updates to this Core software Pack:
MySQL has been updated from 8.0.35 to 8.0.36 Npcap has been updated from 1.78 to 1.79 What's New in Version 11.18.2023
Updates to this Core software Pack:
PostGreSQL has been updated from 15.5 to 16.1 ADOdb has been updated from 5.22.6 to 5.22.7 npcap has been updated from 1.77 to 1.78 What's New in Version 9.5.2023
Updates to this Core software Pack:
PostGreSQL has been updated from 15.3 to 15.4 PHP has been updated from 8.2.8 to 8.2.10  What's New in Version 7.22.2023
Updates to this Core software Pack:
MySQL has been updated from 8.0.33 to 8.0.34 Npcap has been updated from 1.75 to 1.76 What's New in Version 5.16.2023
Updates to this Core software Pack:
PostGreSQL has been updated from 15.2 to 15.3 What's New in Version 4.30.2023
Updates to this Core software Pack:
MySQL has been updated from 8.0.31 to 8.0.33 What's New in Version 2.15.2023
Updates to this Core software Pack:
PostGreSQL has been updated from 10.23 to 15.2 What's New in Version 1.22.2023
Updates to this Core software Pack:
MySQL has been updated from 8.0.30 to 8.0.31 Apache has been updated from 2.4.54 VS16 to 2.4.55 VS17 What's New in Version 11.13.2022
Updates to this Core software Pack:
PostgreSQL has been updated from 10.22 to 10.23 What's New in Version 8.18.2022
Updates to this Core software Pack:
MySQL has been updated from 8.0.29 to 8.0.30 PostgreSQL has been updated from 10.21 to 10.22 What's New in Version 6.22.2022
Updates to this Core software Pack:
MySQL has been updated from 8.0.28 to 8.0.29 PostgreSQL has been updated from 10.20 to 10.21 Kindest Regards,
Winsnort.com Management

This is the latest Windows Intrusion Detection Systems (WinIDS) software for all the Windows Intrusion Detection Systems (WinIDS) companion add-ons.
Only use the Software supplied in the Windows Intrusion Detection Systems (WinIDS) Companion Software Pack. The versions of support files supplied may be old, and outdated. However, they are the last versions that has been fully tested with all the Windows Intrusion Detection Systems (WinIDS) guided installs.
The Windows Intrusion Detection System (WinIDS) Companion Software Development Pack has been password protected.
Wrapper Password: w1nsn03t.c0m
After you have downloaded the Windows Intrusion Detection System (WinIDS) Core Software Support Pack and before you attempt to install it, you should make sure that it is intact and has not been tampered with. Use the SHA-1 Checksums below to verify the integrity.
SHA-1 Hash value: 114F53B88F69BC71F217D22288554892E30675D5
What's New in Version 06.20.2022
Updates to companion software:
Added Visual Syslog 1.6.4.19 Added Event Watch 2.3.3 Kindest Regards,
Winsnort.com Management

This is the latest Windows Intrusion Detection Systems (WinIDS) Barnyard2 Software Development Pack that can be used to compile Barnyard2 for Windows.
The only reason to be compiling Barnyard2 for an existing Windows Intrusion Detection System (WinIDS) is that the MySQL or PostgreSQL database is being updated.
Note: It is highly recommended that whatever version of database being compiled into Barnyard2 be the same version of database running on the live Windows Intrusion Detection System (WinIDS).
The Windows Intrusion Detection System (WinIDS) Barnyard2 Software Development Pack has been password protected.
Wrapper Password: w1nsn03t.c0m
Note: It is highly recommended that the SHA-1 value listed below matches the SHA-1 value of the downloaded Windows Intrusion Detection System (WinIDS) Barnyard2 Software Development Pack.
SHA-1 Hash value: 66D6E944DAB0DFB3EF18715BB357E39A3BA8E1FF
What's New in Version 4.29.2026
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.44 to 8.0.46 Compiling script has major updates What's New in Version 2.15.2026
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 18.1 to 18.2 Converted Compiling script to Powershell Option to keep CYGWin installed What's New in Version 1.16.2026
Updating the compile of Barnyard2 on Windows:
More script revisions What's New in Version 12.24.2025
Updating the compile of Barnyard2 on Windows:
Updated the scripts What's New in Version 11.21.2025
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 18.0 to 18.1 What's New in Version 10.22.2025
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.43 to 8.0.44 What's New in Version 10.2.2025
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 17.6 to 18.0 What's New in Version 8.18.2025
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 17.5 to 17.6 What's New in Version 7.30.2025
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.42 to 8.0.43 What's New in Version 5.14.2025
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 17.4 to 17.5 What's New in Version 4.23.2025
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.41 to 8.0.42 What's New in Version 2.23.2025
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 17.3 to 17.4 What's New in Version 2.19.2025
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.40 to 8.0.41 PostgreSQL has been updated from 17.2 to 17.3 What's New in Version 2.5.2025
Updating the compile of Barnyard2 on Windows:
Updated the scripts What's New in Version 1.24.2025
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.37 to 8.0.40 PostgreSQL has been updated from 16.3 to 17.2 What's New in Version 5.14.2024
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.36 to 8.0.37 PostgreSQL has been updated from 16.2 to 16.3 What's New in Version 1.22.2024
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.35 to 8.0.36 What's New in Version 11.18.2023
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 15.5 to 16.1 What's New in Version 11.7.2023
Updating the compile of Barnyard2 on Windows:
Updated the scripts for step-by-step explanation What's New in Version 10.3.2023
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 15.4 to 15.5 What's New in Version 9.5.2023
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 15.3 to 15.4 What's New in Version 7.22.2023
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.33 to 8.0.34 What's New in Version 5.16.2023
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 15.2 to 15.3 What's New in Version 2.15.2023
Updating the compile of Barnyard2 on Windows:
PostgreSQL has been updated from 10.23 to 15.2 What's New in Version 1.20.2023
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.30 to 8.0.31 What's New in Version 11.13.2022
Updating the compile of Barnyard2 on Windows:
MySQL has been updated from 8.0.30 to 8.0.31 PostgreSQL has been updated from 10.22 to 10.23 What's New in Version 8.18.2022
Updating the compile of Barnyard2 on Windows:
The automated system has been updated with menu options MySQL has been updated from 8.0.29 to 8.0.30 PostgreSQL has been updated from 10.21 to 10.22 What's New in Version 6.22.2022
Updating the compile of Barnyard2 on Windows:
The automated system has been updated with menu options MySQL has been updated from 8.0.28 to 8.0.29 PostgreSQL has been updated from 10.20 to 10.21 Kindest Regards,
Winsnort.com Management

The Snort Cheat Sheet covers:
Sniffer mode, Packet logger mode, and NIDS mode operation Snort rules format Logger mode command line options NIDS mode options Alert and rule examples

Microsoft's Message Analyzer is a tool for capturing, displaying, and analyzing protocol messaging traffic. It is the successor to NetMon 3.x and is a key component in the Protocol Engineering Framework (PEF) that was created by Microsoft for the improvement of protocol design, development, documentation, testing, and support. With Message Analyzer, you can capture live data or retrieve archived message collections from saved files such as traces and logs. Message Analyzer also enables you to display data in a default tree grid view and in selectable graphical views that employ grids, charts, and timeline visualizer components that provide high-level data summaries and other statistics.
Update: Microsoft Message Analyzer (MMA) has been retired as of November 25, 2019. There is currently no Microsoft replacement for Microsoft Message Analyzer in development at this time.
Note: I would say it’s a must have tool for Network administrator since there is so much you can do. There is a new TechNet blog dedicated for Microsoft Message Analyzer.

Wireshark is one of the popular free packet sniffing tools for Windows. This tool can give you an ability to see what’s happening on your network at a microscopic level. =

SmartSniff is yet another free packet sniffing tool that allows you to capture TCP/IP packets that pass through your network adapter, and view the captured data as sequence of conversations between clients and servers. With the help of this network monitoring utility, you can view the TCP/IP conversations in ASCII mode or as hex dump.