Services/Snort/Pass List/Edit Auto-Generated IP Addresses has degraded performance on passing

[JonathanLee]

I tested the LAN and Snort no longer recognized the TCP scan ignore list inside the preprocessors also. As soon as Roblox started it blocked it and it normally is set to ignore that UDP scan block or IP address as its listed. I don't know if that is occuring on others systems too.

[bmeeks]

@JonathanLee said in Services/Snort/Pass List/Edit Auto-Generated IP Addresses has degraded performance on passing:

I tested the LAN and Snort no longer recognized the TCP scan ignore list inside the preprocessors also. As soon as Roblox started it blocked it and it normally is set to ignore that UDP scan block or IP address as its listed. I don't know if that is occuring on others systems too.

Did you recreate the same configuration on the LAN as you had on the WAN?

I just repeated your test with a pair of virtual machines: one running pfSense CE 2.7 and the other a Kali Linux VM. I was unable to get the WAN IP of my pfSense CE virtual machine to be blocked. I repeated the test dozens of times, and only the Kali Linux VM's IP address was blocked. The pfSense CE machine's interfaces' IP addresses were never blocked.

I'm trying to understand your two Redmine tickets, but to be perfectly honest and frank with you - they read like gibberish. I have no idea what you are trying to say in either of those tickets. And the mumbo-jumbo with the set theory formulas is just adding to the confusion. In some of the attached screenshots you say you are scanning from a T-Mobile hotspot and then point to two different IP addresses and call them both your WAN IP. How is that possible? At the time you did those tests, what was the exact IP address on your WAN interface on pfSense as shown in the STATUS > INTERFACES screen in pfSense?

I'm leaning toward this being a user error. And that opinion is buttressed by the fact you did not know to assign, save, and then restart the Snort binary after pass list changes.

[JonathanLee]

@bmeeks

Thanks for the reply and testing. I could not get it to repeat also. It frustrates me a lot. I want to know how this invasive actor is doing this to me.

The T-mobile test was done only to showcase that port scan blocking is normally successful on my system. Please ignore that if it causes some confusion. I repeated this too with Ubuntu, Windows 10 nmap zenmap I can't get it to repeat. What is being used to create this ?

Now going forward and looking at this from a scientific perspective.

1. The WAN IP seen in image below is blocked it is also shown on the right side of the image. Let's agree this should not happen as this is part of the auto configured items, thus has nothing to do with any custom pass list use. Meaning that feature is having a issue this should never occur.

2. The DNS IP seen in the image below is blocked also shown on the right side of the image in red. Let's agree this should not happen as this is part of the auto configured items, thus has nothing to do with custom pass list use. equates to the feature is having an issue.

Therefore it is by scientific fact a intermittent bug with evidence I have shown here.

Both IP addresses were listed inside the auto generated pass list and were applied already in the auto generated pass list see below.

The math you have seen is to help my understanding of discrete math class this week so just ignore that part also if it causes confusion .

Snort has blocked my WAN IP and my DNS I forward to. I do not know how.

Let's agree it is flat out frustrating.

[bmeeks]

Unless the problem is repeatable, it makes it extremely diffficult to troubleshoot. The only course of investigation is to just guess. Snort is single-threaded, so it is unlikely to be any kind of shared data contention issue.

The blocking function is not native to Snort. Neither is the concept of Pass Lists. Those are all provided by a custom blocking module used exclusively on pfSense.

The entire source code patch file for the custom blocking plugin used with Snort on pfSense can be found here: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/snort/files/patch-spoink-integration.diff. Feel free to have a look. You can easily apply the patch file to a locally extracted Snort 2.9.20 source code tree so that you have a complete C source file tree with the custom blocking module to examine.

[JonathanLee]

@bmeeks

Is it possible the invasive actor can craft a packet that looks like a decoy of a decoy? With something like boolean algebra? Creating a manipulated negated event.

A new Crafted packet starts a scan just like a decoy scan however it is crafted such that the actual part that Snort searches for inside of the decoy port scans is where the spoofed wan IP is inserted. So the crafted scan they just reversed it. Hping can packet craft pings in theory port scans can be crafted also.

So it is like two of the same address could create a Not Not condition and default to true.

Again that would still not be blocked right?

I keep coming back to this section.

switch (data->block) {
+        case SPOINK_BLOCK_DST:
+            ip = GET_DST_IP(p);
+            break;
+        case SPOINK_BLOCK_BOTH:
+            ip = GET_DST_IP(p);
+            if (!s2c_parse_search_wl(data, ip))
+                s2c_pf_block(data, ip); ## -----> HERE 2 conditions
+            /* CONTINUE */
+        case SPOINK_BLOCK_SRC:
+        default:
+            ip = GET_SRC_IP(p); ##---> get source in theory is crafted as destination also
+            break;
+    }
+    if (s2c_parse_search_wl(data, ip)) #----> Here is other
+        return;
+
+    s2c_pf_block(data, ip);
+
+    return;
+}

Probably not I talked to my Professor about this and he said it you know the rules you manipulate the packet before to get your condition you want. It has occured so many times over the last 6 months that I started to wonder if maybe it's generating a double negation and resulting in a block.

"hping3 is a network tool able to send custom ICMP/UDP/TCP packets and to display target replies like ping does with ICMP replies. It handles fragmentation and arbitrary packet body and size, and can be used to transfer files under supported protocols. Using hping3, you can test firewall rules, perform (spoofed) port scanning, test network performance using different protocols, do path MTU discovery, perform traceroute-like actions under different protocols, fingerprint remote operating systems, audit TCP/IP stacks, etc. hping3 is scriptable using the Tcl language" (Kali Tools).

Let's say
A = wan address you don't want blocked
A could also equal the spoof source of scan and the same destination
Thus,

Inverse Law
A+!A = 1 --> always equals 1 wan + !wan = block

A*!A = 0 ---> always equals 0 wan and !wan = no block

I have learned that many conditions will equate to true all the time or false all the time within the programed logic when certain operators are used like OR, AND, NOT operators. Additionally when some operators are used together unintended results can occur. Please see attached I just made this yesterday to help expand my knowledge on this.

Boolean Laws.zip

Ref:
https://www.kali.org/tools/hping3/

[marcosm]

@JonathanLee I don't think that's likely in this case, but admittedly it's more of a presumption than a certainty. What would be most helpful now is repeatable steps for others to test; I'm doubtful progress can be made on the issue otherwise.

[JonathanLee]

@marcosm I have to set it to pcap that alert when it's seen to catch in the act. I have moved to LAN interface currently.

[JonathanLee]

This occurred again however my passlist worked it shows the alert on the wan and did not generate a block on my wan for my DNS for Snort version 4.1.6_11 the update must have corrected the issue. Just wanted to let everyone know. It did show the alert for DNS 8.8.4.4

My DNS I forward to with Unbound . . .

Alerts that just occured . . .

No blocks this time around

Thank you have a good day. That normally would create the denial of service attack on me after they move to each DNS and my WAN IP.

:)

[bmeeks]

@JonathanLee said in Services/Snort/Pass List/Edit Auto-Generated IP Addresses has degraded performance on passing:

Snort version 0.4.46 the update must have corrected the issue.

There is no Snort version by that number. That is a completely invalid version number for the Snort package.

Absolutely nothing was changed in the Snort binary with the last update. In fact, the binary was not even recompiled because it was not touched. Only the GUI PHP code changed, and the section changed has nothing to do with Pass Lists. PHP code does not control blocking. That is handled inside the binary using the custom blocking plugin code I linked somewhere up above in this thead. So, bottom line is there is zero chance that the changes to the ALERTS tab PHP code in Snort package 4.1.6_11 had anything to do with your noticed change in behavior.

[JonathanLee]

@bmeeks

4.1.6_11 sorry I had a mix up.

I do not know if this has anything to do with the intermittent passlist block issue. I noticed this error shortly after the above screen shots. Thanks for all you do and also for sharing the code above.

Fatal error: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown in /usr/local/www/snort/snort_alerts.php on line 858 PHP ERROR: Type: 1, File: /usr/local/www/snort/snort_alerts.php, Line: 858, Message: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown

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