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

    Snort unblocks IPs when it shouldn't

    pfSense Packages
    4
    29
    7.5k
    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.
    • bmeeksB
      bmeeks
      last edited by

      @ConfusedUser:

      Hi Bill,

      I currently got three virtual test installs of pfSense with snort on different IPs and all three keep blocking everything since I removed the cron entries manually. Probably that was the bug that I experienced with all test installs… I will keep monitoring for a few days.

      Btw, make sure you read your PMs!  :)

      I did see you PM and replied.  Thank you… :)

      I will push a fix soon for the cron bug.

      Bill

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

        @ConfusedUser:

        Hi Bill,

        I didn't find anything special in the output that I would immediately consider as bug but like I wrote earlier, I'm a lousy programmer (if I do programming then only vb.NET).

        But… I found something in the package that is 99.9% a bug and I can re-produce it any time: The aging adds entries in /etc/crontab but never removes old entries. Maybe this is related to the issue I experience -  not sure yet.
        I was changing the aging in the snort/pfSense web GUI entries from "never" to "28 days", to "7 days", etc. See my /etc/crontab below:

        SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
#minute hour    mday    month   wday    who      command
#
#
# pfSense specific crontab entries
# Created: April 29, 2014, 1:55 pm
#

1,31	0-5	*	*	*	root	/usr/bin/nice -n20 adjkerntz -a
1	3	*	*	0	root	/usr/bin/nice -n20 /etc/rc.update_bogons.sh
*/60	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout
1	1	*	*	*	root	/usr/bin/nice -n20 /etc/rc.dyndns.update
*/60	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot
30	12	*	*	*	root	/usr/bin/nice -n20 /etc/rc.update_urltables
*/5	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_cron_misc.inc
*/15	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 10800 snort2c
30	11,23	*	*	*	root	/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/www/snort/snort_check_for_rule_updates.php
*/30	*	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 21600 snort2c
2	*/1	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 43200 snort2c
2	0	*/2	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 2419200 snort2c
2	*/14	*	*	*	root	/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 604800 snort2c
#
# If possible do not add items to this file manually.
# If you do so, this file must be terminated with a blank line (e.g. new line)
#

        There are now five entries for expiretable snort2c. That can't be right?!

        Thanks,
        Mike

        The fix for this bug has been posted in a Pull Request here: https://github.com/pfsense/pfsense-packages/pull/653/files

        As soon as the Core Team Developers approve and merge the request, an updated Snort package will appear under System…Packages for installation.

        Bill

        1 Reply Last reply Reply Quote 0
        • C
          ConfusedUser
          last edited by

          Hi Bill,

          Many thanks!

          For now I manually modified the crontab and config.xml and I removed all expiretable entries for snort.
          Now I can see that everything that should be blocked is blocked really. But there might be another issue with expiretable (and I might be wrong): I was running a command to remove entries older than 6 hrs manually and the result was that also an entry disappeared which was alerted only two hours ago.

          I will look closer into it and properly document it and post it here if I find out that's another issue (and not my fault by typing something wrong).

          Mike

          1 Reply Last reply Reply Quote 0
          • S
            simby
            last edited by

            Can you please update snort to 2.9.6.1 ? :)

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

              @simby:

              Can you please update snort to 2.9.6.1 ? :)

              Yes, I will put that on my TODO list.  My goal is to stay as close to current as possible with Snort.  Sometimes for various reasons the package may lag behind for one minor version for a while.

              Bill

              1 Reply Last reply Reply Quote 0
              • C
                ConfusedUser
                last edited by

                Hi Bill,
                Do you know if the cron bug fix for Snort is already live?

                In the meantime I found the second issue with the blocking feature.
                Even after manually fixing the Cron entries there were still IPs unblocked that shouldn't be. I found out that this is caused by the "expiretable" command. This command cleans up IPs by the time they were entered in the snort2c table. That means if I set the blocking time to 6 hrs an IP address that was creating an alert only 10 minutes ago will be unblocked if it also created an alert 6 hours ago.

                The blocking time should always depend on the last generated alert - not on the first one.

                This might not sound like a real issue but I was monitoring 3 test systems in 3 different WANs for one week and in total it happened 5 times that packets were allowed to pass to the PBX even they should be blocked by Snort. I was first surprised how this could happen but this is caused by the behavior that I described above.
                I have several senders from a big country in Asia  ;) that try to get access to SIP for example. These frequent talkers get blocked for example because they are on a bad reputation IP list. Now they still continue trying but Snort doesn't create an alert every time a packet is sent (which makes sense of course).
                And this combination (frequent sender + suppressed alerts) causes IPs to be removed from the block lists and then being able to reach the VoIP PBX because expiretable unblocks them even they are still sending - just because they have an older timestamp on the snort2c table.

                Is there any way to get this fixed or any idea for a workaround?

                Thanks,
                Mike

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

                  @ConfusedUser:

                  Hi Bill,
                  Do you know if the cron bug fix for Snort is already live?

                  In the meantime I found the second issue with the blocking feature.
                  Even after manually fixing the Cron entries there were still IPs unblocked that shouldn't be. I found out that this is caused by the "expiretable" command. This command cleans up IPs by the time they were entered in the snort2c table. That means if I set the blocking time to 6 hrs an IP address that was creating an alert only 10 minutes ago will be unblocked if it also created an alert 6 hours ago.

                  The blocking time should always depend on the last generated alert - not on the first one.

                  This might not sound like a real issue but I was monitoring 3 test systems in 3 different WANs for one week and in total it happened 5 times that packets were allowed to pass to the PBX even they should be blocked by Snort. I was first surprised how this could happen but this is caused by the behavior that I described above.
                  I have several senders from a big country in Asia  ;) that try to get access to SIP for example. These frequent talkers get blocked for example because they are on a bad reputation IP list. Now they still continue trying but Snort doesn't create an alert every time a packet is sent (which makes sense of course).
                  And this combination (frequent sender + suppressed alerts) causes IPs to be removed from the block lists and then being able to reach the VoIP PBX because expiretable unblocks them even they are still sending - just because they have an older timestamp on the snort2c table.

                  Is there any way to get this fixed or any idea for a workaround?

                  Thanks,
                  Mike

                  Yes, the cron fix should be "live" in the current package, v3.0.8.

                  As for the expiretable command, it may have a bug as you say.  That binary is actually quite old and its functionality can now be duplicated directly with pfctl itself.  Suricata uses this new technique, but within Snort I did not change it from how it was when I inherited it.  Perhaps it's now time to make the change.  I will do that in the next update.

                  In the meantime, since you have an easily reproducible case for testing, try this for me.

                  Edit the cron job command so that instead of using this string:

                  /usr/local/sbin/expiretable -t 21600 snort2c

                  it uses this one:

                  /sbin/pfctl -t snort2c -T expire 21600

                  Leave the part with "/usr/bin/nice -n20" alone.

                  Supposedly this utility clears all IP addresses from the specified table if the statistics for the entry have not been cleared in the time interval specified (in seconds).  So 21,600 seconds equals 6 hours.  Here is what the FreeBSD man page says about the -T expire sub-command:

                  Delete addresses which had their statistics cleared more than number seconds ago.  For entries which have never had their statistics cleared, number refers to the time they were added to the table.

                  Bill

                  1 Reply Last reply Reply Quote 0
                  • C
                    ConfusedUser
                    last edited by

                    Tried that already a while ago - didn't work. Well, it works exactly the same way as expiretable. So changing it will not make a difference.

                    The command looks at the time when the statistics for an IP were last cleared. When an IP is already in the snort2c table and an alert is triggered again for the IP the date/time doesn't change.

                    One good example (currently I got block time set to 24 hours):
                    IP address 210.22.81.89 triggered an alert at the following times:
                    05/14/14 20:23:38
                    05/14/14 06:04:58

                    So this IP was still blocked. In "pfctl -t snort2c -T show -v" I can see the following details:
                    210.22.81.89
                    Cleared: Wed May 14 06:04:59 2014

                    After running "/sbin/pfctl -t snort2c -T expire 21600" at 21:30 the IP disappeared from snort2c even last alert was triggered at 20:23 (only a bit more than one hour ago).

                    So… unfortunately no. Changing to pfctl expire won't fix that issue.

                    1 Reply Last reply Reply Quote 0
                    • C
                      ConfusedUser
                      last edited by

                      Btw, I have tried several things to get the statistics cleared for one single IP address in the snort2c table - I didn't get it done. The command "-T zero" works only for the whole table.

                      The only way I have managed to do to get it cleared is to
                      pfctl -t snort2c -T delete 1.2.3.4
                      pfctl -t snort2c -T add 1.2.3.4

                      So whenever an alert is triggered and both commands are run it would allow a correct expiry of entries. But… I don't consider this to be a good idea to remove an entry first.
                      I have not found any other way to clear the statistics of an IP (but it does't mean it is not possible, I just didn't find anything).

                      A possible workaround would be to use two tables for snort in an alternating order.
                      Example:

                      IP 1.2.3.4 triggers an alert.
                      pfctl -t snort2c1 -T add 1.2.3.4
                      pfctl -t snort2c2 -T delete 1.2.3.4

                      Next IP 5.6.7.8 triggers an alert.
                      pfctl -t snort2c2 -T add 5.6.7.8
                      pfctl -t snort2c1 -T delete 5.6.7.8

                      Next IP 5.6.7.8 triggers another alert.
                      pfctl -t snort2c1 -T add 5.6.7.8
                      pfctl -t snort2c2 -T delete 5.6.7.8

                      So whatever comes in - the tables would need to be used in an alternating order. And of course a second set of block rules would need to be added and the expire commands would need to run for both tables.
                      Not sure if that is any practical (especially with the "blocked" tab in the GUI which would require some extra coding) but it would allow the expiry function to work properly.

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

                        Hmm…I was sort of afraid you might find that both worked the same way.  I originally thought (due to not carefully reading the MAN page) that anytime a packet arrived for an IP in the table that would "update" the stats and thus reset the timer.  Turns out that's not true when I read the MAN page more thoroughly.

                        I don't know if there is any easy way out of this problem with the current setup.  Unless there is some other command available via the system call to the packet filter used by the Snort plugin, this may not be fixable.  At least not without a patch to the packet filter code itself, and I doubt there is much appetite for that with the Core Team developers.

                        Bill

                        1 Reply Last reply Reply Quote 0
                        • C
                          ConfusedUser
                          last edited by

                          Thanks Bill!

                          Well, for me a reliable blocking is the main reason why I use Snort and currently the blocking is not completely reliable (unless I switch to "never unblock").
                          But I will find a workaround.

                          Current idea: I will add another output to the snort.conf using alert_csv that only has timestamp and both IP address pairs. Then I will run a script via cron that regularly searches for old entries in this alert file, removes them from the alert file and for each IP that has been removed and that doesn't still have a newer entry in the alert file run a "pfctl -t snort2c - T delete x.x.x.x".
                          That should make the unblocking reliable.

                          Might take a few days though and maybe I find a better solution on the way. Anyway, I will post the code here if/when I manage to get this running.

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

                            @ConfusedUser:

                            Thanks Bill!

                            Well, for me a reliable blocking is the main reason why I use Snort and currently the blocking is not completely reliable (unless I switch to "never unblock").
                            But I will find a workaround.

                            Current idea: I will add another output to the snort.conf using alert_csv that only has timestamp and both IP address pairs. Then I will run a script via cron that regularly searches for old entries in this alert file, removes them from the alert file and for each IP that has been removed and that doesn't still have a newer entry in the alert file run a "pfctl -t snort2c - T delete x.x.x.x".
                            That should make the unblocking reliable.

                            Might take a few days though and maybe I find a better solution on the way. Anyway, I will post the code here if/when I manage to get this running.

                            Post back with what you come up with.  I will keep looking for some other potential solution.

                            Bill

                            1 Reply Last reply Reply Quote 0
                            • BBcan177B
                              BBcan177 Moderator
                              last edited by

                              Hi ConfusedUser,

                              Out of curiosity why do you need to remove the blocks from snort on such a regular basis? For me, fine tuning of the rules prevents a lot of the false positives. Even if a rule blocks an ip, and you clear the block in an hour interval, without modifying the rules, most likely Snort will block the ip again?

                              If you do need to write a script, I would be willing to help out, but I think there are other options available to fix your concerns.

                              "Experience is something you don't get until just after you need it."

                              Website: http://pfBlockerNG.com
                              Twitter: @BBcan177  #pfBlockerNG
                              Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                              1 Reply Last reply Reply Quote 0
                              • C
                                ConfusedUser
                                last edited by

                                Hi BBcan17,

                                Thanks for offering your help! I might come back to it if (when  ;) ) I find out I can't get a script done myself. Currently I'm still working on it and I'm testing a few options.

                                I currently unblock the IPs with the 24 hr setting (as written in my earlier posts) but I rather like to go to 6 hrs or 12 hrs but due to the limitions in the current design that causes "old" IPs to be unblocked even if they caused an alert minutes ago I went to 24 hrs which prevents most IPs from reaching my internal network.

                                When you say "why do you need to remove the blocks from snort on such a regular basis?" what would you recommend then? I thought 6 to 12 hrs is pretty reasonable. I hardly get any false positives (probably one every two weeks or so but I eliminate them as soon as I see them) but I don't want IPs to be blocked forever to prevent dynamic (dial-up) IPs to be blocked with no reason.
                                So if you consider my current 24 hrs as such a regular basis how much longer would you go then and why? Would you rather simply ignore dynamic IPs?

                                Thanks,
                                Mike

                                1 Reply Last reply Reply Quote 0
                                • BBcan177B
                                  BBcan177 Moderator
                                  last edited by

                                  Hi Mike,

                                  If you tune the rules, you shouldn't get too many False Positives (as you said, "probably one every two weeks or so").

                                  With that said, I run Snort with the "Never Clear" setting, and just remove the ones as they come.

                                  I like this approach better because if you leave the Blocks alone, you will see a lot of repeat offenders and it will Block faster as its already in the Snort2c table.
                                  Snort is not a true-inline IPS so removing IPs will let some packets thru if they weren't already blocked.

                                  So tuning Snort is the best approach to managing a good IPS system.

                                  What kind of Dynamic IPs are you seeing?

                                  I submitted a post to add more Search Lookups to the DNS lookup page which can make it easier to diagnose IP addresses.. See below..

                                  https://forum.pfsense.org/index.php?topic=73406.msg404649#msg404649

                                  "Experience is something you don't get until just after you need it."

                                  Website: http://pfBlockerNG.com
                                  Twitter: @BBcan177  #pfBlockerNG
                                  Reddit: https://www.reddit.com/r/pfBlockerNG/new/

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