Morpheus

Administrators
 View profile  See their activity

  • Content count

    603

  • Joined

  • Last visited

  • Days Won

    101

Everything posted by Morpheus

  1. We are pleased to provide updated guidance on utilizing the PulledPork rule updater for your Windows Intrusion Detection systems. Whether you are managing a standalone sensor or a fleet of remote nodes, following these best practices will help ensure your detection rules remain current and reliable. Deployment Scenarios Standalone Sensors For standalone installations, the updater can be executed directly from the desktop shortcut. Note: While the script may function without elevated permissions, we recommend selecting Run as Administrator to ensure the utility has the necessary access to update system files successfully. Remotely Managed Nodes While the updater is fully compatible with standalone sensors, it is optimized for remotely managed environments. For these deployments, we recommend enabling all three configuration options (Silent Mode, Email Notifications, and Task Scheduling) to ensure seamless, automated maintenance. Recommended Configurations You can optimize the script by adjusting the following variables within the configuration file: Silent Mode ($silent): Set to 1 to mute console output. This reduces overhead and is recommended for remote, automated nodes. Email Notifications ($sendmail): Set to 1 to receive status alerts, requires SMTP setting added. Failsafe Mechanism: If an update fails, the script will automatically roll back to the previous stable ruleset and send a notification detailing the cause of the failure. Scheduling: For instructions on automating your update cycles, please refer to our dedicated tutorial: Scheduling and Updating Windows IDS Rules. Feedback & Continuous Improvement Several fail-safes have been built-in; the process is constantly looking to improve the stability and performance. We welcome your input! If you have any recommendations or encounter issues, please submit your feedback.

  2. Version

    1 download

    =============================================================================== 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 ===============================================================================
  3. 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 Save the file. Open the Start Menu and navigate to the WinSnort group. Click the Rules Updater link to execute the script. 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.
  4. If the High-Volume Logging/Testing option was enabled during the initial Auto-Installer setup, the system likely generated a significant number of events. While this setting is an excellent diagnostic tool to verify that the Windows Intrusion Detection System (WinIDS) is actively receiving data—especially in environments where default traffic might take hours to trigger an alert—it is recommended to revert to the default policy once connectivity is confirmed. Procedure to Restore Default Rule Policy Follow these steps to deactivate the testing rules and return to the standard configuration: Modify Configuration: Navigate to the Pulledpork\etc folder via File Explorer. Right-click enablesid.conf and open it with Notepad. Locate the line beginning with pcre:. Comment out the line by adding a # at the start (e.g., # pcre:.) Save and exit. Clear Temporary Files: Navigate to the Pulledpork\temp folder. Delete the two files located in this directory. Close File Explorer. Update Rule Set: Open the Start Menu and locate and open the WinSnort folder. Run the Rules Updater. This process will fetch the latest rule definitions and reconfigure Snort to the default policy setting, ensuring optimal performance and manageable log volumes.

  5. Version

    0 downloads

    =============================================================================== 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 ===============================================================================

  6. Version

    0 downloads

    =============================================================================== 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 ===============================================================================

  7. Version

    3 downloads

    =============================================================================== 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 ===============================================================================

  8. Version

    2 downloads

    =============================================================================== 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 ===============================================================================

  9. Snort Cheat Sheet

    Morpheus posted a file in Windows Security Tools

    Version 1.0.0

    11 downloads

    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
  10. 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.
  11. 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
  12. 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.
  13. Does this work: http://winids/base.php
  14. 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
  15. That is not normal?
  16. 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
  17. All the files look good. Attached id my config for IIS, try it. You will need to stop IIS, replace the file, and then restart IIS. applicationHost.config
  18. Go back in and verify the PHP setting in IIS. For some reason the setting sometime does not save and the settings need to be re-applied. No need to reinstall because the same problem could come back. I checked your setting and the php.ini file is good but the IIS files are for version 10 and I don't have that set of configs to match yours with. I would need to install IIS 10 to get it. What OS version are you running?
  19. Go back to the section below and do over. Configuring IIS for PHP, and the Windows Intrusion Detection Systems security console If that fails then zip up all the files in the Windows\System32\inetsrv\config folder and attach. Also attach the php.ini file
  20. No, you are supposed to enable the lines by removing the # (hash tags).
  21. No you don't need to do anything. What you are seeing is correct. I made an error in the tutorial and have since corrected it. Check out the tutorial, and it should match your install.
  22. All fixed, thanks...
  23. What is the process you used and I'll check it on another build. Did you just add the below to your local.rules file? alert ( msg: "ARPSPOOF_ARP_CACHE_OVERWRITE_ATTACK"; sid: 4; gid: 112; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; ) Did you use something to generate the alert?
  24. Try here
  25. Do as the topic instructs to remove it.