pfSense » pfSense Packages

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

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.

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.

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.

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

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.

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.

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.

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

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.

Related Feature Request

https://redmine.pfsense.org/issues/14821

I opened a new bug for that I forgot that I have that already set as pass listed