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

rasputinthegreatest

@bmeeks Everything is identical between these machines when it comes to browser settings.
In the morning my smart TV was off, but I am still seeing this attempt. So the connection is coming from 8.8.8.8 and going to my VLAN. I don't really understand this behaviour because it must be initialized through pfsense or my switch. It is trying to reach out to my TV. Nowhere in my network I am using 8.8.8.8.

Does the DNS resolver need to be restarted after saving changes?

1 	UDP 	Attempted User Privilege Gain 	8.8.8.8
   	53 	10.0.10.2
   	37844 	3:19187
     	PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt

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. My block list otherwise is very limited with only 6 IPs on it. 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?

Gertjan

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

my Samsung Smart TV and set 8.8.8.8 as the DNS server inside the DHCP server on pfsense

Moments later :

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

Nowhere in my network I am using 8.8.8.8

?

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

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

So the connection is coming from 8.8.8.8 and going to my VLAN

That's new.
8.8.8.8 is a (DNS) server .
Example : The CNN web server won't contact your browser neither. Its your browser contacting the web server, and the web sever will answer back. Ones.
That's how Internet works.

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

Does the DNS resolver need to be restarted after saving changes?

When you change settings, or do nothing and just hit this button :

the config file of the resolver will be regenetared, and the resolver process will be restarted.

You saw this on top of the screen when you saved :

The actual regeneration of the config, and restart will happen as soon as you hit Apply.

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.