Snort: Whitelist a vulnerability scanner that scans internal addresses on other interfaces (SOLVED)
-
Hi,
I have a scanner installed in a subnet / interface. My blocking policy is both. I have the scanner in both home and passlists. I have also put in in a whitelist.
I have not found any way to completely whitelist this scanner in such a way that nothing is blocked regardless of if the scanner is src or dest. The scanner scans my other subnets and I need a way make sure that none of the ip's that the scanner scans get blocked.
Any ideas?
-
Am I wrong in assuming someone has already solved this somewhere - it cannot be that nobody uses a vulnerability scanner in their internal network - right?
-
What specific rules are triggering when your internal scanner is scanning another host? I can see how your scanner could trigger an alert, but I don't really see how your "victim host" would trigger one. You should be able to create an IP whitelist on the IP REPUTATION tab and configure the settings there such that any packet where your scanner's IP is the source IP bypasses further inspection. That would prevent blocks of the scanner. A properly implemented IP reputation list exempts a matching IP address from being evaluated by any other rules in the stack.
-
My assumption is, that because I evaluate BOTH src and dest ip for alerts/blocks the whitelist surely does make sure my scanner is never blocked, but all the targets get blocked.
Example: the scanner scans linux servers port 22 and does some trickery. As a results, ssh signatures are triggered and the destination ip's are blocked.
So this is basically what I have for each interface. The only thing in the whitelist is the scancer ip. Is this correctly configured?
edit: i unchecked the top most checkbox before the screencap, so treat that checkbox as selected.
-
Now I run a scan from 10.99.0.41 (scanner machine) to the 10.97.0 subnet and immediately I am getting results that start to block servers in the 10.97 subnet.
-
Wht if I just go ahead and X away that wierd "packets whitelisted" alert?
-
@tsmalmbe said in Snort: Whitelist a scanner (think nmap) that scans internal addresses on other interfaces:
Wht if I just go ahead and X away that wierd "packets whitelisted" alert?
Yes, that should do it. I forgot that Snort will give you a "friendly reminder" that it is whitelisting packets (or exempting them from further examination). The way blocking works in pfSense, any alert equals a block -- even the "friendly reminder" alerts like this one.
So either suppress this alert using the "plus" (+) icon in the SRC IP column or the one in the SID column. I would suggest trying the Source IP column first. That way the rule will only be suppressed when the Source IP is your scanner host. Right now you are getting blocks from this SID due to blocking on BOTH the source and destination IP addresses in an alert. Suppressing the alert based on Source IP will prevent the alert from firing and thus the scanned host should not get blocked either.
I would love to make Snort on pfSense work more like Suricata where you can use ALERT, DROP or PASS in the rules and the actions actually work that way. But the internal structure of the Snort binary does not make this easy with the design of the custom blocking plugin we use on pfSense. Supposedly Snort3 will make imitating true IPS behavior easier once that goes to RELEASE.
-
This seems to do the trick. I decided to actually X away it instead of suppressing it, because whitelisting should always on a principal level mean whitelisting. I do see the point of suppressing just the scanner, but conceptually I have a hard time to grasp a whitelisting alert that essentially is blocking... I may understand that now, but looking at alerts and logs in a month will just simply confuse me.
I think this thread could deserve a FAQ entry of it's own - how to truly add a vulnerability scanner to your network.
-
@tsmalmbe
The confusion stems from the somewhat primitive way the plugin has to handle blocking. The blocking plugin is actually written as a Snort logging output plugin, and it gets a copy of every alert that is triggered. Unfortunately, the rule "action" is not part of the alert data that is sent to the plugin. So it cannot know if the alert it was copied on was from an alert action rule, a drop action rule or a pass action rule. So it has to treat every alert notice it receives as a "block" or "drop" action.So in your case, the alert is actually just a notification, but the blocking plugin does not know that. So it has to assume the alert is something it needs to block.
