Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    snort: restarting needed if IP list edited?

    Scheduled Pinned Locked Moved
    IDS/IPS
    2
    10
    803
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      digidax
      last edited by digidax

      Hello,
      With a honey pot, I generate a IP text file list with bad IPs. With cron job and curl I download the file into the snort ip reputation folder. The file is setup in the IP File list and used by the interfaces successfully. Bad hosts are blocked.

      Question:
      After downloading a new txt file with same filename (overwrite), do I have to restart snort? If so, I would add after curl command this:

      && sleep(1) && /usr/local/etc/rc.d/snort.sh restart

      Is this prodcedure right or is there a better way?

      all the best, Frank

      bmeeksB 1 Reply Last reply Reply Quote 0
      • D digidax referenced this topic on
      • D digidax referenced this topic on
      • stephenw10S stephenw10 moved this topic from General pfSense Questions on
      • bmeeksB
        bmeeks @digidax
        last edited by bmeeks

        @digidax said in snort: restarting needed if IP list edited?:

        Hello,
        With a honey pot, I generate a IP text file list with bad IPs. With cron job and curl I download the file into the snort ip reputation folder. The file is setup in the IP File list and used by the interfaces successfully. Bad hosts are blocked.

        Question:
        After downloading a new txt file with same filename (overwrite), do I have to restart snort? If so, I would add after curl command this:

        && sleep(1) && /usr/local/etc/rc.d/snort.sh restart

        Is this prodcedure right or is there a better way?

        all the best, Frank

        That command you have will work. It will just restart Snort on all the configured interfaces (which may be what you want).

        You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

        D 1 Reply Last reply Reply Quote 0
        • D
          digidax @bmeeks
          last edited by

          @bmeeks said in snort: restarting needed if IP list edited?:

          You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

          IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

          So how can I find out, which compiling options are used for snort?

          Thanks for your help, Frank

          D bmeeksB 2 Replies Last reply Reply Quote 0
          • D
            digidax @digidax
            last edited by

            @digidax said in snort: restarting needed if IP list edited?:

            @bmeeks said in snort: restarting needed if IP list edited?:

            You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

            IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

            So how can I find out, which compiling options are used for snort?

            Thanks for your help, Frank

            When I execute

            pkill -SIGHUP snort

            then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?

            bmeeksB 1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks @digidax
              last edited by bmeeks

              @digidax said in snort: restarting needed if IP list edited?:

              So how can I find out, which compiling options are used for snort?

              Thanks for your help, Frank

              You would look in the Makefile of the associated binary in the FreeBSD ports tree on GitHub. Here is a direct link: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/snort/Makefile.

              I don't recall offhand if there is a command-line option to print out the compile options in the binary.

              The "reload" option is enabled in the pfSense package.

              1 Reply Last reply Reply Quote 0
              • bmeeksB
                bmeeks @digidax
                last edited by bmeeks

                @digidax said in snort: restarting needed if IP list edited?:

                @digidax said in snort: restarting needed if IP list edited?:

                @bmeeks said in snort: restarting needed if IP list edited?:

                You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

                IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

                So how can I find out, which compiling options are used for snort?

                Thanks for your help, Frank

                When I execute

                pkill -SIGHUP snort

                then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?

                Since you did not post the log, I can only assume that the reload configuration worked if you saw messages in the pfSense system log. That's where Snort logs its startup and shutdown (and error) messages.

                Be aware that the command you indicated is somewhat global -- meaning it is not restricting itself to a single PID. If you only have Snort running on one interface, then it does not really matter. But if you have multiple Snort instances configured on different interfaces, you may want to be more specific with the instance to signal with the "reload" command by using the process ID (PID) of the Snort process on that interface.

                D 1 Reply Last reply Reply Quote 0
                • D
                  digidax @bmeeks
                  last edited by

                  @bmeeks said in snort: restarting needed if IP list edited?:

                  @digidax said in snort: restarting needed if IP list edited?:

                  @digidax said in snort: restarting needed if IP list edited?:

                  @bmeeks said in snort: restarting needed if IP list edited?:

                  You can also send the running Snort process a SIGHUP signal to tell it to reload its configuration. That will prompt the running process to read the snort.conf file again and reload the configuration including rules and IP reputation files. In order to do thisk, you will need to identify the PID of the running Snort process that you want to send the signal to. Then use the pkill command to send SIGHUP to the running Snort PID.

                  IIn reference to https://www.snort.org/faq/readme-reload and the procedure you wrote above, it's based on the fact, that snort was compiled with the "–enable-reload" option a configure stage.

                  So how can I find out, which compiling options are used for snort?

                  Thanks for your help, Frank

                  When I execute

                  pkill -SIGHUP snort

                  then the system log of snort facility begin to displaying redefined addresses. Does this indicated a successful reload?

                  Since you did not post the log, I can only assume that the reload configuration worked if you saw messages in the pfSense system log. That's where Snort logs its startup and shutdown (and error) messages.

                  Be aware that the command you indicated is somewhat global -- meaning it is not restricting itself to a single PID. If you only have Snort running on one interface, then it does not really matter. But if you have multiple Snort instances configured on different interfaces, you may want to be more specific with the instance to signal with the "reload" command by using the process ID (PID) of the Snort process on that interface.

                  Yes I know, but at the moment snort is used on 3 WAN interfaces and the block IP list is also used on all of them. When I add snort to other interfaces, I will do force the reload only on that interfaces which are needed reloaded after changing the IP list from which is reading after the download of the update.

                  Here is the log after sending a SIGHUP at Feb 1 06:15:00 time order is DESCending.

                  Feb 1 06:15:07 	snort 	16581 	[136:1:1] (spp_reputation) packets block-list [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 185.181.102.18:11747 -> 94.100.xxx.xxx:179
Feb 1 06:15:02 	snort 	17766 	Additional duplicate addresses were not listed.
Feb 1 06:15:02 	snort 	17245 	Additional duplicate addresses were not listed.
Feb 1 06:15:02 	snort 	17766 	(1309) => Re-defined address: '107.189.6.161'
Feb 1 06:15:02 	snort 	17766 	(1304) => Re-defined address: '107.189.31.191'
Feb 1 06:15:02 	snort 	17766 	(1297) => Re-defined address: '107.189.29.142'
Feb 1 06:15:02 	snort 	17766 	(1291) => Re-defined address: '107.189.14.34'
Feb 1 06:15:02 	snort 	17766 	(1289) => Re-defined address: '107.189.14.180'
Feb 1 06:15:02 	snort 	17766 	(1288) => Re-defined address: '107.189.12.34'
Feb 1 06:15:02 	snort 	17766 	(1280) => Re-defined address: '107.189.1.92'
Feb 1 06:15:02 	snort 	17766 	(1258) => Re-defined address: '107.174.138.172'
Feb 1 06:15:02 	snort 	17766 	(1219) => Re-defined address: '106.75.79.172'
Feb 1 06:15:02 	snort 	17766 	(1216) => Re-defined address: '106.75.64.59'
Feb 1 06:15:02 	snort 	17766 	(1202) => Re-defined address: '106.75.223.50'
Feb 1 06:15:02 	snort 	17766 	(1198) => Re-defined address: '106.75.22.49'
Feb 1 06:15:02 	snort 	17766 	(1190) => Re-defined address: '106.75.184.237'
Feb 1 06:15:02 	snort 	17766 	(1182) => Re-defined address: '106.75.154.53'
Feb 1 06:15:02 	snort 	17766 	(898) => Re-defined address: '104.248.82.49'
Feb 1 06:15:02 	snort 	17766 	(863) => Re-defined address: '104.244.79.120'
Feb 1 06:15:02 	snort 	17766 	(861) => Re-defined address: '104.244.78.148'
Feb 1 06:15:02 	snort 	17766 	(848) => Re-defined address: '104.244.74.28'
Feb 1 06:15:02 	snort 	17766 	(847) => Re-defined address: '104.244.74.253'
Feb 1 06:15:02 	snort 	17766 	(321) => Re-defined address: '101.35.6.240'
Feb 1 06:15:02 	snort 	17245 	(1309) => Re-defined address: '107.189.6.161'
Feb 1 06:15:02 	snort 	17245 	(1304) => Re-defined address: '107.189.31.191'
Feb 1 06:15:02 	snort 	17245 	(1297) => Re-defined address: '107.189.29.142'
Feb 1 06:15:02 	snort 	17245 	(1291) => Re-defined address: '107.189.14.34'
Feb 1 06:15:02 	snort 	17245 	(1289) => Re-defined address: '107.189.14.180'
Feb 1 06:15:02 	snort 	17245 	(1288) => Re-defined address: '107.189.12.34'
Feb 1 06:15:02 	snort 	17245 	(1280) => Re-defined address: '107.189.1.92'
Feb 1 06:15:02 	snort 	17245 	(1258) => Re-defined address: '107.174.138.172'
Feb 1 06:15:02 	snort 	17245 	(1219) => Re-defined address: '106.75.79.172'
Feb 1 06:15:02 	snort 	17245 	(1216) => Re-defined address: '106.75.64.59'
Feb 1 06:15:02 	snort 	17245 	(1202) => Re-defined address: '106.75.223.50'
Feb 1 06:15:02 	snort 	17245 	(1198) => Re-defined address: '106.75.22.49'
Feb 1 06:15:02 	snort 	17245 	(1190) => Re-defined address: '106.75.184.237'
Feb 1 06:15:02 	snort 	17245 	(1182) => Re-defined address: '106.75.154.53'
Feb 1 06:15:02 	snort 	17245 	(898) => Re-defined address: '104.248.82.49'
Feb 1 06:15:02 	snort 	17245 	(863) => Re-defined address: '104.244.79.120'
Feb 1 06:15:02 	snort 	17245 	(861) => Re-defined address: '104.244.78.148'
Feb 1 06:15:02 	snort 	17245 	(848) => Re-defined address: '104.244.74.28'
Feb 1 06:15:02 	snort 	17245 	(847) => Re-defined address: '104.244.74.253'
Feb 1 06:15:02 	snort 	17245 	(321) => Re-defined address: '101.35.6.240'
Feb 1 06:15:01 	snort 	16581 	Additional duplicate addresses were not listed.
Feb 1 06:15:01 	snort 	16581 	(42) => Re-defined address: '107.189.6.161'
Feb 1 06:15:01 	snort 	16581 	(41) => Re-defined address: '107.189.31.191'
Feb 1 06:15:01 	snort 	16581 	(39) => Re-defined address: '107.189.29.142'
Feb 1 06:15:01 	snort 	16581 	(38) => Re-defined address: '107.189.1.92'
Feb 1 06:15:01 	snort 	16581 	(37) => Re-defined address: '107.189.14.34'
Feb 1 06:15:01 	snort 	16581 	(36) => Re-defined address: '107.189.14.180'
Feb 1 06:15:01 	snort 	16581 	(34) => Re-defined address: '107.189.12.34'
Feb 1 06:15:01 	snort 	16581 	(31) => Re-defined address: '107.174.138.172'
Feb 1 06:15:01 	snort 	16581 	(30) => Re-defined address: '106.75.79.172'
Feb 1 06:15:01 	snort 	16581 	(29) => Re-defined address: '106.75.64.59'
Feb 1 06:15:01 	snort 	16581 	(27) => Re-defined address: '106.75.22.49'
Feb 1 06:15:01 	snort 	16581 	(26) => Re-defined address: '106.75.223.50'
Feb 1 06:15:01 	snort 	16581 	(24) => Re-defined address: '106.75.184.237'
Feb 1 06:15:01 	snort 	16581 	(22) => Re-defined address: '106.75.154.53'
Feb 1 06:15:01 	snort 	16581 	(20) => Re-defined address: '104.248.82.49'
Feb 1 06:15:01 	snort 	16581 	(12) => Re-defined address: '104.244.79.120'
Feb 1 06:15:01 	snort 	16581 	(11) => Re-defined address: '104.244.78.148'
Feb 1 06:15:01 	snort 	16581 	(9) => Re-defined address: '104.244.74.28'
Feb 1 06:15:01 	snort 	16581 	(8) => Re-defined address: '104.244.74.253'
Feb 1 06:15:01 	snort 	16581 	(1) => Re-defined address: '101.35.6.240'

                  When I do comapre it with a "snort restart" command, the lines are identical, additional "SnortStartup 17114 Snort START for WAN1STM(em0)" and the other interfaces where snort is activated are seen with the restart command.

                  Thanks for your help,
                  Frank

                  bmeeksB 1 Reply Last reply Reply Quote 0
                  • bmeeksB
                    bmeeks @digidax
                    last edited by

                    @digidax:
                    You are getting those messages because you have multiple Snort instances running on what amounts to the same interface (your WAN). I see you have VLANs defined there, but for Snort or any other IDS/IPS, you should instead put a single Snort instance on the parent interface. That will save lots of CPU and RAM resources. Snort runs the NIC in promiscuous mode, so each instance is seeing all traffic (including the other VLANs). Same thing would happen if you just ran a single instance on the parent physical interface.

                    When Snort starts, it queries pfSense for all of the local addresses and networks defined on the firewall. It adds those to the various HOME_NET and default Pass List settings. Due to you have three WAN interfaces (via the VLANs, I assume), Snort is collecting the same addresses multiple times and adding them to HOME_NET. That's triggering the "re-defined address" warnings. They are harmless messages, though.

                    And to answer your original question, "yes", those messages show that Snort is reloading its configuration when it receives the SIGHUP command.

                    D 1 Reply Last reply Reply Quote 1
                    • D
                      digidax @bmeeks
                      last edited by

                      @bmeeks
                      OK, will take a look into the logs to see, if the updates of the list are imported successful.

                      OT Question: in the blocked tab, I see the "Last 500 Hosts Blocked by Snort ". In the browser, I can use CTRL+f to search for an IP.

                      a) is it possible, as a future feature, to get a search filed for an IP when the list is larger, > 2000 entries?

                      b) can I use a command line command to search for a blocked IP and remove it from snort's blocklist?

                      Thanks, Frank

                      bmeeksB 1 Reply Last reply Reply Quote 0
                      • bmeeksB
                        bmeeks @digidax
                        last edited by

                        @digidax said in snort: restarting needed if IP list edited?:

                        @bmeeks
                        OK, will take a look into the logs to see, if the updates of the list are imported successful.

                        OT Question: in the blocked tab, I see the "Last 500 Hosts Blocked by Snort ". In the browser, I can use CTRL+f to search for an IP.

                        a) is it possible, as a future feature, to get a search filed for an IP when the list is larger, > 2000 entries?

                        I don't really understand why you would want the block list to grow like that. The suggested setup is to enable the automatic cron task (on the GENERAL SETTINGS tab) that clears blocked hosts who have seen no traffic for the interval specified in the parameter on that tab. For example, if you choose 1 hour, then any IP in the block list that has seen no traffic for the last hour will be automatically removed from the block list after the interval has expired.

                        There is really no point in maintaining huge block lists. If the same host attacks again, then Snort will detect and block it again. It is usually sufficient to block a host for 15 minutes to an hour. If you have not already, I strongly recommend you enable that setting and configure it for either 30 minutes or 1 hour max.

                        Snort blocks by making a pfSense system call and inserting the offending IP into a pf table called snort2c. That table is created by pfSense during bootup, and it is a RAM construct. So when the firewall is restarted, that table is recreated from scratch.

                        b) can I use a command line command to search for a blocked IP and remove it from snort's blocklist?

                        You can manage the pf firewall engine using the pfctl utility. Here is a link to its documentation: https://www.freebsd.org/cgi/man.cgi?query=pfctl&sektion=8.

                        Thanks, Frank

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.