Can someone explain why this rule gets triggered by Snort 3:19187?

bmeeks

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

Can Google not loading be related to Snort being in legacy mode and blocking 8.8.8.8? It always gets put on my block list when this alert pops up and I manually remove it.

Of course! That will impact anything that wants to communicate with IP address 8.8.8.8. Isn't that why you are running Snort in blocking mode in the first place -- to block stuff it thinks is bad? When you run Snort in blocking mode, then it certainly is going to block stuff. And everything that is blocked is most likely going to impact something on your network that was trying to communicate with the IP address Snort decided to block.

But as I've mentioned, 9 times out of 10 Snort gets it wrong and blocks stuff that is not malicious at all! Thus you have broken apps on your network because Snort is falsely blocking things that should not in reality be blocked. My recommendation to you is to immediately turn off the blocking mode in Snort. Go to the INTERFACE SETTINGS tab and uncheck the option to Block Hosts. Save that change and restart Snort on the interface. Then go to the BLOCKS tab and clear all the blocks. I bet things work better then. Just let Snort run in IDS mode (non-blocking) for several weeks to get a feel for what is normal traffic on your network. But I do not recommend running the package at all on a home network.

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

I also manually added 8.8.8.8 to the Pass List in Snort but it still ends up there again. Doesn't seem to work or maybe the Pass List must be activated somewhere else to work?

When you create a Pass List, you must manually assign it to an interface, save that change, then restart Snort on the interface so it sees the change. The Pass List is assigned on the INTERFACE SETTINGS tab.

But you are being tripped up by false positives, and the resulting unnecessary blocks inserted by Snort are breaking your network functionality. Turn it off and just relax!

rasputinthegreatest

@Gertjan said in Can someone explain why this rule gets triggered by Snort 3:19187?:

?

Even if you undid all you've done, a samsung TV will probably also use 8.8.8.8.

I removed 8.8.8.8 in pfsense DHCP server. I thought I mentioned it in the thread somewhere. So I found it strange that I am still seeing 8.8.8.8. Also checked the IP settings on the TV and DNS server is set to 10.0.10.1
And why is 8.8.8.8 the Source IP aka incoming connection? I also see Amazon and Akami IPs trying to get to my TVs IP. You can see it in the log here:

2025-03-28
15:13:38 		3 	TCP 	Unknown Traffic 	13.32.99.109
     	80 	10.0.10.2
   	42980 	120:3
     	(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
2025-03-28
15:13:36 		3 	TCP 	Unknown Traffic 	184.24.77.155
     	80 	10.0.10.2
   	39331 	120:3
     	(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
2025-03-28
15:13:07 		1 	UDP 	Attempted User Privilege Gain 	8.8.8.8
     	53 	10.0.10.2
   	51187 	3:19187
     	PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt
2025-03-28
15:13:07 		1 	UDP 	Attempted User Privilege Gain 	8.8.8.8
     	53 	10.0.10.2VLAN.
   	51187 	3:19187
     	PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt

@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:

But as I've mentioned, 9 times out of 10 Snort gets it wrong and blocks stuff that is not malicious at all!

I usually manually remove the IPs on the blocklist if they have a good reputation. But a few I left in there since they had bad reputation. For example this one. Would you unblock it?
https://otx.alienvault.com/indicator/ip/142.250.186.78
https://www.abuseipdb.com/check/142.250.186.78
Or this one which shows as a worm from January 25th and is located in Moscow
https://otx.alienvault.com/indicator/ip/2.16.168.118

@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:

My recommendation to you is to immediately turn off the blocking mode in Snort. Go to the INTERFACE SETTINGS tab and uncheck the option to Block Hosts. Save that change and restart Snort on the interface. Then go to the BLOCKS tab and clear all the blocks. I bet things work better then. Just let Snort run in IDS mode (non-blocking) for several weeks to get a feel for what is normal traffic on your network. But I do not recommend running the package at all on a home netwo

This is what I actually did. I let it run for about 3 weeks in non blocking mode. So things were broken before I even turned on the Block Mode. But maybe I should just turn it off. I just find it strange what I am seeing on my Samsung TV.

@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:

Of course! That will impact anything that wants to communicate with IP address 8.8.8.8.

When I am using Google with Cloudflare set as my DNS in Firefox. Would 8.8.8.8 being on my blocked host list impact my search or prevent google search from loading?

bmeeks

@rasputinthegreatest: what interface are running Snort on? If your WAN, then you will see all kinds of noise there that can safely be ignored. The default configuration of pfSense is to DENY ALL on the WAN interface. That means it will accept no incoming unsolicited connection attempts at all. That is 100% secure and nobody from the Internet can initiate a connection unsolicited to your LAN. By "unsolicited", I mean without a device on your LAN first starting the conversation by sending a SYN packet. Research how stateful inspection firewalls operate to understand better.

But when you run Snort on an interface, it sees traffic on that interface before any firewall rules have been applied. So, when running on the WAN, it's going to see and alert on all the Internet noise but your default firewall rules are going to deny that traffic entry into pfSense and thus your LAN. So, Snort on the WAN will block needlessly because the firewall was already going to drop that traffic.

It sounds to me like you have tweaked too many things in your pfSense setup without fully understanding the implications of tweaking them. And that's why you are having issues. For example, you should not do anything to the DNS Resolver settings. Leave them at their default. Do NOT put any DNS servers in the SYSTEM > GENERAL SETTINGS box. Leave those blank and pfSense will default to using the local unbound daemon in resolver mode. Do not put any DNS servers in the DHCP settings. pfSense will default to handing out itself as the DNS server your LAN clients should use. And lastly, uninstall Snort and forget about using it. It is obviously not helping and is in fact making the situation worse.

If you do a fresh pfSense install and don't change a single thing except maybe the IP subnet to use on your LAN, then things will just work. You do not have to add anything else -- no extra packages, don't touch any DNS settings, and generally don't touch DHCP except to enable it on the LAN if desired.

rasputinthegreatest

@bmeeks It's only my LAN interface since I heard WAN makes no sense.
I have reversed all these settings already to a vanilla pfsense install. So far I don't feel a difference in speed or website resolving unfortunately. Sometimes I need to refresh a page for it to properly load since it won't on first try. I also disabled Snorts blocking mode for now and just use it to monitor stuff. I was a lot more paranoid when I started getting into this stuff and seeing all these connections but pfsense at least gives me a peace of mind. Like you said. It's probably a set and forget situation for a home user.

bmeeks

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

So far I don't feel a difference in speed or website resolving unfortunately.

Well, if you have reset pfSense to more or less its default settings and are still having issues, the next thing to check is your physical connection with your ISP. You may have problems with traffic flow down at layer 2 or perhaps layer 3 on your ISP's side.

You can post the content of your pfSense system log (under STATUS > SYSTEM LOGS) around the time you are experiencing issues with speeds or DNS resolution. Are all your LAN clients pointed to your pfSense firewall's IP address as their DNS Server?

rasputinthegreatest

@bmeeks Sorry for the late response. Some devices I don't trust are directly connected to the ISP router on a guest wifi. For example FireTV stick. Any client that sits behind the pfsense firewall has the DNS set to 192.168.1.1
I am using Proxmox on a server and noticed that in my VMs Mozilla Firefox struggles to load websites. If I switch to a Chromium based browser everything resolves instantly. I am starting to think the issue migh be Firefox itself.

bmeeks

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

If I switch to a Chromium based browser everything resolves instantly. I am starting to think the issue migh be Firefox itself.

Be aware that Firefox defaults to using DoH, I believe, and it will attempt to communicate with a trusted partner DNS server over HTTPS. If you have something in your security setup that interferes with Firefox's ability to communicate with the DoH server that Firefox chooses on its own, then it will have trouble resolving hostnames and thus websites will appear slow or timeout completely.

When using a browser that supports DoH, and when that option is enabled, the browser chooses its own DNS server and ignores any DNS servers you attempt to provide. If that chosen server is blocked, the websites will be sluggish or timeout.

rasputinthegreatest

@bmeeks I never actively blocked anything regarding FIrefox and have no IPs blocked that belong to Firefox. It only happens in a VM so it must be the Proxmox layer that blocks something but couldn't find anything online about it.

Gertjan

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

o it must be the Proxmox layer that blocks something but couldn't find anything online about it.

Read again :
Virtualizing with Proxmox VE
Did you notice that no where it's said that "Proxmox passes some traffic and block other traffic", or that it contains a hidden, "not-known" firewall.
So, I tend to think that, ones set up correcly, traffic passes. Proxmox doesn't handle UDP and TCP traffic that has a destination port 53 - also know as DNS traffic - differently.

That said, imho, first, set up pfSense on a bare metal device. Ones that's done, works fine, you can go ahead and add a 'VM' into the mix.
Bare metal == way simpler.

bmeeks

@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:

@bmeeks I never actively blocked anything regarding FIrefox and have no IPs blocked that belong to Firefox. It only happens in a VM so it must be the Proxmox layer that blocks something but couldn't find anything online about it.

I don't think you understood my point. Firefox, unless the "use secure DNS" option is disabled, will use the DNS services of trusted partners (meaning they have a deal with eath other) for IP resolution using DoH (DNS over port 443 using SSL). If you have anything on your firewall (Snort, Suricata, pfBlockerNG, etc.) that is blocking DoH destination IPs or is attempting to do that, it would confuse the DoH lookups the Firefox browser attempts. It has nothing to do with IP addresses specifically related to FireFox itself.

@Gertjan did a good job explaining how Proxmox is pretty much going to be agnostic in terms of traffic. It is not going to be selectively blocking things unless you have have something misconfigured.