Bug #14754
closed
Snort security issue bug within tcp/UDP scan detection blocking tool DoS event
0%
Description
Version:
Snort 4.1.6_8 built on pfSense plus Netgate 2100 appliance running an ARM processor. Package is prebuilt for use with this firewall.
Rules Enabled:
Emerging Threats (ET) Rules
Snort Subscriber Rules
Suspected Bug within Wan Preprocs:
Bug abused within Portscan Detection Enabled
Bug Details:
I thought I should report this, I have witnessed this DoS attack several times. The Snort package can not determine the difference between a decoy scan using the hosts WAN ISP issued IP address, as well as the hosts DNS address in use over a regular non decoy Nmap scan. This causes issues when snort has portscan detection and blocking enabled on the WAN Preproces. This results in degraded performance of the external DNS resolvers or a full off-lined system event. When the host running Snort has a decoy scan such as this Snort will block the hosts WAN ip address it is running on-top of.
Steps to reproduce:
Use the hosts WAN IP address and perform a decoy TCP/IP scan Nmap with it from an 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 that host uses such as 8.8.8.8 forcing the DNS to be also be blocked. Keep in mind the Nmap scan ran will have to use the hosts wan address for its decoy address.I have had this occur several times already with my pfSense firewall.
Possible Resolve:
What I want to happen when a Nmap scan occurs from your firewalls WANs IP address externally with such “decoys” is the firewall should black hole it hence create an auto reply custom reply/response. The Snort system can be preconfigured to auto reply for when a scan occurs from a decoy address of its own WAN address. Again, Snort should be pre configured for when such decoy scans are detected and have a packet crafted response should this be seen with the IPD/IDS. Packet crafting can be done for the hosts WAN and DNS ip addresses.
Ending Notes:
This is a major concern. I have also showcased this with Palo Alto during my cyber security class at Sierra College. I have also reported this to Netgate pfSense team seen below. PfSense Netgate security team has asked me to send this upstream to Snort. (See below)
WARNING:
Several invasive actors have found this Zero Day does create a DoS event and has been testing it on my home network and off-lined my system several times. When I review the blocks it shows my own WAN IP address ran Nmap scans and IPS/IDS blocks it right after. Snort does not know the difference at this point.
Side Note:
This has been reported upstream to bugs@snort.org and security@netgate.com, security at netgate asked me to post in Netgate forum and to report to Snort. I have also added this information to Redmine for more visibility as this team could also provide a possible solution and or contact someone at bugs@snort to also report this. Thos DoS has occurred several times now. My IP address is not listed on any of the lists in this blocked event.
Files
| snort_blocked_2023-09-06-07-11-41.tar.gz (372 Bytes) snort_blocked_2023-09-06-07-11-41.tar.gz | DoS event | ||
| 947C78F9-9BD9-4CB7-A183-F9019ED422CD.PNG (551 KB) 947C78F9-9BD9-4CB7-A183-F9019ED422CD.PNG | Line 1 is my IP | ||
| Screenshot 2023-09-07 150042.jpg (253 KB) Screenshot 2023-09-07 150042.jpg | DNS BLOCKED decoy scan event | ||
| bugtest.PNG (209 KB) bugtest.PNG | port scan ran | ||
| Screenshot 2023-09-29 at 9.45.25 AM.png (177 KB) Screenshot 2023-09-29 at 9.45.25 AM.png | blocked | ||
| Screenshot 2023-09-29 at 11.42.26 AM.png (319 KB) Screenshot 2023-09-29 at 11.42.26 AM.png |
Related issues
Updated by Jonathan Lee 8 months ago
Per Netgate Security Team on August 25, 2023 at 5:17:05 AM PDT:
Hello,
The Snort package for pfSense software is maintained by a community member, not by Netgate. This doesn't appear to be a critical security issue and may even be a configuration problem. It's also possible it's a problem it Snort itself and not the package, in which case it would be reported upstream to Snort and not to us.
You can raise the issue with the package maintainer on the forum in the IDS/IPS category and see what his thoughts are.
Thanks
Updated by Jonathan Lee 8 months ago
Please Note:
bugs@snort.org does not respond to any emails with the report listed above. If you are reading this and have a Snort upstream contact please report this DoS.
Updated by Jonathan Lee 8 months ago
Again this is another example where the DNS resolver IP address that is set on the firewall is being used as a decoy to perform scanning of my own networks. Several times the invasive actor will use all 4 DNS servers IP addresses as decoys in a row to degrade the system. Snort will spot this as a scan and block the DNS resolver's address also.
8.8.8.8 was used.
Possible resolution to this would be a pre crafted packet that could reply with random ports open or closed without blocking.
Updated by Bill Meeks 8 months ago
This bug report makes absolutely no sense to me. I can't follow the logic trail here. All of the blocks shown in the attached screenshots are from rules that are simply lists of "bad actor or poor reputation" IP addresses. They have nothing at all to do with a portscan or the portscan preprocessor.
Of the IP addresses shown in the attached lists, which one is your WAN IP? I suspect none of them. Snort is behaving as designed by blocking external IPs and not the internal WAN IP. I'm not following your claim of DoS here.
There is no way on Earth that 8.8.8.8 is your internal DNS Resolvers IP address. That IP belongs to Google. If you have your pfSense box set to the 8.8.8.8 IP address, that is totally wrong. Perhaps you mean you have the pfSense unbound resolver set to "forwarding mode" and you are using 8.8.8.8 as the forwarder destination. If so, then you need to edit this bug report to accurately report the true configuration.
This seems to be either a misconfiguration or a complete misunderstanding by you of what you are actually testing/doing. The description currently in this bug report is not at all clear to me.
Updated by Jonathan Lee 8 months ago
P: pfSense is forwarding it's DNS to 8.8.8.8 and Snort is set to block port scans seen on the WAN interface.
Q: the IP address of 8.8.8.8 DNS is used by an invasive actor to perform a decoy nmap port scan.
R: Snort blocks the DNS now PfSense has no DNS access to 8.8.8.8
(P @ Q) = R
Or
P: pfSense has snort set to block port scans enabled.
Q: invasive actor uses the WANs IP address in a decoy nmap scan
R: SNORT blocks the wan IP address and now there is no Internet.
Updated by Jonathan Lee 8 months ago
64.113.111.129 is my IP this block occurs when this IP is used by an invasive actor to perform a port scan of my network with it.
P: my IP is 64.113.111.129 snort is set to block port scans
Q: invasive actor performs a decoy port scan with 64.113.111.129 to scan 64.113.111.129
R: Snort blocks it's own WAN IP address.
(P@Q) = R
Updated by Jonathan Lee 8 months ago
This denial of service attack occurs only when
P: snort is on wan and has port scan detection and blocking enabled.
Q: an invasive actor uses any the IP addresses for the DNS that PfSense forwards to. or the wan IP address.
R: snort blocks the decoy nmap scan and you now have no DNS or no wan IP as they are listed under blocked addresses.
One side note it seems like when snort detects a decoy port scan with the actual wan IP address it adds it to everything all at once the last item is the port scan and that's what occurs
R: a degraded system or no Internet access until blocks are removed.
This occurs one a month, two months or even 6 months before this invasive actor does another decoy scan.
I have tested this in a lab environment in college with Palo Alto firewalls also, same results. Any decoy scans with such a condition will result in a denial of service.
Updated by Jonathan Lee 8 months ago
Durring testing this condition with Palo Alto
Command used was
Nmap -sS -D decoyIP targetIP
This will send the decoy or fake IP for syn ack.
The decoy could be the DNS or the IP address your scanning.
Nmap -sS -D 8.8.8.8 targetIP 64.113.111.129
Or
Nmap -sS -D 64.113.111.129 targetIP 64.113.111.129
Snort should have a pre crafted packet reply that is a decoy reply for such an event and not just block.
Updated by Jonathan Lee 8 months ago
Thus this is what is occuring for my system and creates the DoS event.
Nmap -sS -D 8.8.8.8 64.113.111.129
Results in snort blocking the dns IP address for me
Or
Nmap -sS -D 64.113.111.129 64.113.111.129
Results in snort blocking the wan IP address.
P: if snort port scan is enabled on wan and blocking
Q: IP or itself of DNS used in decoy port scan
R: should be send a pre packet crafted reply with decoy responses and not disable the system.
Updated by Jonathan Lee 8 months ago
- File bugtest.PNG bugtest.PNG added
- File Screenshot 2023-09-29 at 9.45.25 AM.png Screenshot 2023-09-29 at 9.45.25 AM.png added
Example of detection and block of standard nmap scan.
Kali OS has decoy scanning abilities for lan tests that are being abused such that a port scan target is utilizing the target IP as the decoy IP creating a snort block on its own wan IP
P: WAN ISP Issued IP or DNS pfSense forwards to, or P = IP of WAN interface snort resides on/DNS unbound uses
Q: snort set to block port scans or Q(source IP of port scans)
A: a decoy IP or A(any decoy IP needed)
R: result block the source IP of a detected port scan
therefore equation can be
(Q(A(P))) = R
Q of A of P = resulting block
this is the equivalent of Q(P) = R
This condition should always be Q(~P) = R
now suppose Q(P) = R
or where q is from the universe of all blocked port scans
and a is from the universe of the decoy scans.
and p is from the universe WAN ISP Issued IP address or DNS that pfSense forwards to for this system that snort resides on
∀q∃a(p)
This should be ∀q ¬ ∃a(p)
Updated by Jonathan Lee 8 months ago
Please let me know if that helps with the logic if not I can boot up Kali to offline my system again. That is already shown in the original post above. 8.8.8.8 blocked and my IP blocked as they were used as a decoy address for a port scan of my network externally.
This is being abused and creating DoS events on my system
Updated by Marcos M 8 months ago
- Status changed from New to Not a Bug
This isn't a bug. To avoid the issue, relevant IP addresses can be added to a passlist. There also likely exist rules for Snort/Suricata to detect spoofed scans, further details here:
https://www.snort.org/faq/readme-sfportscan
Updated by Marcos M 8 months ago
- Related to Bug #14514: SNORT randomly starts blocking the IP address on the interface that it is residing on added
Updated by Jonathan Lee 8 months ago
Thanks Marcos I am aware of the passlist area this would resolve this. Again, that would allow backdoor conditional port scans as they are marked to pass them.
Can this be changed to a feature request for a pre configured packet crafted response for specific IP addresses such that the reply would automatically show all closed/filtered on ports? This way it would not have any backdoor to scan any system within a passlist.
Updated by Jonathan Lee 8 months ago
Related Feature Request
Updated by Jonathan Lee 8 months ago
@Marcos M
They are automatically added to pass list and this still occurs.
Unless this was changed recently.
Please see attached this might be a bug. . .
the auto add pass list is not working
Updated by Jonathan Lee 8 months ago
I opened a new bug for that I forgot that I have that already set as pass listed