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

[SteveITS]

@JonathanLee tagging @bmeeks

Usually one wants to run it on LAN so it doesn’t waste time scanning packets the firewall will immediately drop. Since it runs outside the firewall. LAN also shows private IPs in alerts.

[JonathanLee]

@SteveITS Thanks for the reply,

I agree many only use snort on the LAN interface today, again many also use WAN.

Regardless the Auto-Generated Pass items is not being recognized under certain conditions for some reason. Or the decoy/spoofed scan is being interpreted incorrectly by snort for some reason. Would you agree it should never block the interface address itself thinking that it is a valid port scan?

2 conditions cause an offlined system

1. Spoofed DNS port scan
2. Spoofed interface IP address port scan

This occurs every once and a while. I would I could have a crafted packet that just sends back a reply saying all ports closed or filtered. Solves it all, no one could scan it as that is not part of the pass list it has a pre configured reply and it has a response that says nothing is open thus more protections.

[SteveITS]

@JonathanLee I tagged the maintainer because he’s posted before about random times IPs in pass lists are ignored but he couldn’t duplicate. Try searching the forum, I see one thread a year or so. (Not being snarky, I don’t have any links handy) But I see Bill’s already seen at least one of the Redmines.

Should it happen? No. But moving to LAN seems a way around it if you’re being attacked.

[bmeeks]

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

I would I could have a crafted packet that just sends back a reply saying all ports closed or filtered.

What exactly would that packet say? You do realize that the standard reply for unwanted traffic on the WAN is to say nothing? No reply at all. That way the attacker does not know if something is residing at the IP address he scanned or not.

If you reply in any form or fashion, you've just told him somebody is indeed "home", and he can throw all manner of traffic at you to look for a vulnerability. If nothing else he now knows there is "something" there and he can launch a DDoS against the IP that just said "sorry, but there is nobody home here".

[JonathanLee]

@bmeeks The crafted packet, could say what ever you want or yes ignore. I agree ignore is the better option. The main issue here is this kind of spoofed port scan and Snorts response to it. Snort is not passlisting and Snort is configured to do so again, the address is getting blocked. Snort actually shuts down my WAN or the DNS IP addresses. It disables the Internet, I delete the IP blocks for my DNS or IP and I am good to go until this invasive actor does the decoy scan again. It occurs with decoy port scans. Every couple months this type of scan occurs. Automatically passlist configuration of WAN, and DNS is not working for me.

[bmeeks]

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

Snort is not passlisting and Snort is configured to do so again, the address is getting blocked.

Go to the WAN Interface Settings tab, scroll down to the Pass List assignment drop-down, and then click the View List button out to the right. Copy and post back here the contents of the pop-up modal dialog that appears. Let's verify the content of any pass list Snort is using. Is the 8.8.8.8 IP address present in the dialog?

If you assign a different Pass List to Snort, you must save the change on the Interface Settings tab and then restart the Snort instance on the interface. Make sure you do that for any Pass List changes.

[JonathanLee]

@bmeeks Thanks for the reply,

Here is what is listed in my pass list.

1.0.0.1 //dns
1.1.1.1 //dns
8.8.4.4 //dns
8.8.8.8 //dns
64.113.111.1
64.113.111.129
127.0.0.1
192.168.1.0/27
::1
fe80::92ec:77ff:fe0d:da25
fe80::92ec:77ff:fe0d:da26

[JonathanLee]

@bmeeks

I changed this to include my custom list "passlist_64815" per your notes above. As of now now so it is . . .
Thanks for that note I assumed it was automatically added and applied and that was not the case for my alias.

Again the DNS was listed in the original list seen above.

1.0.0.1
1.1.1.1
8.8.4.4
8.8.8.8
64.113.111.1
64.113.111.129
127.0.0.1
192.168.1.0/27
::1
DO_NOT_BLOCK
IMAP_US_SERVER
ROBLOX
SMTP_US_SERVER
fe80::92ec:77ff:fe0d:da25
fe80::92ec:77ff:fe0d:da26

I wonder what type of scan they are using, I tried to replicate with Zenmap, Nmap, and used decoy options it would detect me not the decoy, however what ever port scan that invasive actor uses is interpreted as a valid scan.

I was perplexed to see that the whole block page was full for my wan interface IP address that one day with the port scan blocked listed. I went to double check to see if my IP was listed in any of the snort lists that day and it is not, so I was very confused with that block. That only occurred 2 times in the last 6 months. Most often my DNS that Unbound forwards to is being used with the spoofed address and that is what gets blocked.

Random right? I want to catch it with a pcap file but you never know when it occurs. If I had a Cisco Mars I could just go right to that date and time and grab the packets. Again, I do not have a Mars security appliance or I would have the packets listed on how it was done. I got the perfect time stamps for it too.

[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