Snort security issue bug within TCP/UDP scan detection blocking tool
-
I thought I should report this, I have noticed a couple times that the Snort package cannot determine the difference between a decoy scan of the hosts actually WAN IPS IP address, DNS address versus a non-decoy nmpa scan. This is when snort has scan detection and blocking is enabled on the wan interface and it results in a degrading of external DNS resolvers or an offlined system.
Steps to reproduce use the hosts WAN IP address and perform a decoy TCP/IP scan nmap of the WAN address with it from a external system. Snort will detect the scan and block its own WAN address creating a denial-of-service event. This can also be done with DNS address such as 8.8.8.8 forcing the DNS to be blocked.
Keep in mind the nmap ran would have to use the hosts wan address for its decoy address.
I have had this occur several times already.
Possibly for Resolve: when a nmap scan occurs from your firewall's WANs IP address externally a "decoy" the firewall should black hole it hence creates an auto reply custom TCP response.
The snort system can be preconfigured to auto reply for when a scan occurs from a decoy address of it's own WAN address.
This is a concern. I have also showcased this with Palo Alto during my cyber security class at Sierra College.
How can this be fixed without changing interfaces?
Jonathan Lee
-
Packet crafting could in theory be used to auto reply to the invasive decoy nmap scan when it is ran with your own WAN ip address.
-
These types of issues should be reported to Snort upstream. There is nothing to be done on the pfSense end. All pfSense does is take the stock binary from upstream and wrap it with a PHP GUI for ease of administration. All of the actual work of detection is done by the binary daemon running under FreeBSD. That binary daemon code comes directly from Snort upstream.
I've also mentioned in another thread you visited that the port scan preprocessor in Snort is virtually worthless these days and really should not be used. It is prone to very frequent false positives.
By the way, the same is true for Suricata as well.
-
@bmeeks thanks for the reply, how can I submit this upstream to them? I actually use the preprocessors it works for me, again it took a lot to get it right.
-
@bmeeks what do the multiple preprocessors do?
-
@michmoor said in Snort security issue bug within TCP/UDP scan detection blocking tool:
@bmeeks what do the multiple preprocessors do?