@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.