Snort is blocking our pentesters



  • I’m new to this group and fairly new to pfSense as well. We use Snort as a plugin to pfSense.

    We have an outside company due vulnerability scans of our public-facing IP addresses. The problem is that Snort has been completely blocking their ability to do their scans. I guess that means Snort is working, at least. But we need the reports from this company for our annual audits.

    The testers gave us several ranges of IP addresses that they use, which we whitelisted. This was done by going to Firewall->Aliases and creating a list of the ranges, and then under Services->Snort, the Alias is added to the Pass Lists section.

    They are still unable to do their scans and I don’t know how else to let them through. When they try, I get an Alert SID 105:2 “(spo_bo) Back Orifice Client Traffic detected” and the IP is blocked. The source IP is indeed one in the range that was whitelisted.

    I know I could force-disable the Back Orifice rule, but that would be opening us up to anyone else running that attack against us, which of course we don’t want.

    What might you recommend we do?



  • When you added the alias, did you restart Snort on the interface? A Pass List is only read once during the Snort startup sequence. Changes made while Snort is already running are ignored until the next Snort process restart.

    You could also just put Snort in IDS mode (disable blocking temporarily). If you do this, you must go to the BLOCKS tab and remove all blocked hosts.

    Also remember that once Snort blocks an IP, that IP will remain blocked until one of the following occurs:

    1. You manually remove the block on the BLOCKS tab;
    2. You have periodic flushing of Snort blocks enabled on the GLOBAL SETTINGS tab and the block interval has expired;
    3. You reboot the firewall.


  • Thank you for your reply.

    I wasn't sure if we had restarted the interfaces before, so I did it just now and had them re-run their scan. I got a lot of Alerts on the WAN interface, with the Source IP being one of the ones we have whitelisted. The IP did not, however, show up on the Blocked list. (We do have blocks set to flush after 1 hour, but we are within that window). Does that mean that it worked?

    I'm just surprised to see anything in the Alerts section and not under Blocked. Since we have the Block Offenders interface option checked ("Checking this option will automatically block hosts that generate a Snort alert") I am surprised to see it on the Alerts section but not the Blocked section. But if it's not blocking the testers I guess it's still ok to see an alert about it.

    I think it might be working. What do you think?



  • @jesscanada said in Snort is blocking our pentesters:

    Thank you for your reply.

    I wasn't sure if we had restarted the interfaces before, so I did it just now and had them re-run their scan. I got a lot of Alerts on the WAN interface, with the Source IP being one of the ones we have whitelisted. The IP did not, however, show up on the Blocked list. (We do have blocks set to flush after 1 hour, but we are within that window). Does that mean that it worked?

    I'm just surprised to see anything in the Alerts section and not under Blocked. Since we have the Block Offenders interface option checked ("Checking this option will automatically block hosts that generate a Snort alert") I am surprised to see it on the Alerts section but not the Blocked section. But if it's not blocking the testers I guess it's still ok to see an alert about it.

    I think it might be working. What do you think?

    Yes, it sounds like it is working properly. Putting an IP on a Pass List prevents that IP from being blocked, but it does not prevent the corresponding alerts. If you don't want to see the alert, then you would use a Suppression List entry or else disable the alerting rule. The difference in suppression versus disabling is that when suppressed, a rule is still evaluated and burns CPU cycles for that, but no alert is logged. Disabling a rule prevents it from being evaluated and thus saves those CPU cycles.

    Alerts do in fact generate blocks, but only if the alerting IP is NOT on a Pass List. If the alerting IP is covered by a Pass List entry, then it is not blocked.

    The other setting that has some influence is whether you have the "Which IP to Block" parameter set to SRC, DST or BOTH. The default is BOTH. That setting is on the INTERFACE SETTINGS tab under the section where blocking is enabled. Again, though, if SRC or DST is covered by a Pass List entry, then that IP won't be blocked even though it will generate an alert.


Log in to reply