Can someone explain why this rule gets triggered by Snort 3:19187?
-
@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
Problems accessing particular websites could be caused by two different things.
I often have the problem that I search something through the address bar and google just doesn't resolve. I just see the website trying to load.
@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
My first instinct here is that your ISP's router is not very powerful and may have simply run out of states or memory to support the number of sessions. Restarting the router would have cleared out memory and started things over from scratch. Who is your ISP?
It's Vodafone. A colleague of mine has the same issues with them as well so I am starting to think it's just the ISP being shitty. It could also be the Fritzbox running out of memory after a while. In theory I could buy a modem for 230€ but it seems a little unnecessary.
Earlier I had the situation that I tried to type in Firefox address bar for a search and it just kept loading. On a different machine at the same time it worked with Firefox and the same search query. But my ISP's DNS servers are not used because everything was set to Cloudflare so far.@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
I take it you are a residential user protecting his home network.
Yeah I am and I am very cautious in everything I do. I am learning all this because I wanted to setup a camera to watch my cat when I am at work and one thing lead to the other and now here I am
I just did the dig traceroute and it seems to work as intended. Very cool :)
; <<>> DiG 9.18.19 <<>> facebook.com +trace +nodnssec
;; global options: +cmd
. 82947 IN NS f.root-servers.net.
. 82947 IN NS g.root-servers.net.
. 82947 IN NS m.root-servers.net.
. 82947 IN NS j.root-servers.net.
. 82947 IN NS k.root-servers.net.
. 82947 IN NS c.root-servers.net.
. 82947 IN NS i.root-servers.net.
. 82947 IN NS b.root-servers.net.
. 82947 IN NS l.root-servers.net.
. 82947 IN NS a.root-servers.net.
. 82947 IN NS e.root-servers.net.
. 82947 IN NS d.root-servers.net.
. 82947 IN NS h.root-servers.net.
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 mscom. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 837 bytes from 198.97.190.53#53(h.root-servers.net) in 16 msfacebook.com. 172800 IN NS a.ns.facebook.com.
facebook.com. 172800 IN NS b.ns.facebook.com.
facebook.com. 172800 IN NS c.ns.facebook.com.
facebook.com. 172800 IN NS d.ns.facebook.com.
;; Received 284 bytes from 192.52.178.30#53(k.gtld-servers.net) in 125 msfacebook.com. 60 IN A 157.240.0.35
;; Received 57 bytes from 2a03:2880:f1fc:c:face:b00c:0:35#53(c.ns.facebook.com) in 22 ms -
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
I often have the problem that I search something through the address bar and google just doesn't resolve. I just see the website trying to load.
Do you have any extensions enabled in your browsers such as ad blockers or auto-play video stoppers? Those can cause weird issues and will be machine specific because machine "A" might have the extension enabled while machine "B" does not.
If you have one of the IDS/IPS packages installed and blocking mode is enabled, that is a high-risk of causing network operability issues due to the false positives we have been discussing in this thread. When using Legacy Blocking Mode, every alert can result in a complete block of the IP address.
How you have the DHCP service configured can also impact DNS behavior because if running CE and you enable the option for DNS registration of DHCP leases, that will result in
unboundbeing restarted each time a DHCP lease is renewed. Lots of IoT devices renew their lease every few minutes. DHCP will automatically renew a lease at 50% of the lease lifetime. This can result in a lot of DNS Resolver restarts. The resolver can't resolve when it is restarting, and thus DNS can appear to be "dead" during the restart interval and so things like web browsing slow to a stall because the DNS lookups are failing. -
@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 attemptCan 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?
-
@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.
-
@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!
-
@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?
-
@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
unbounddaemon 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.
-
@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. -
@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?
-
@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. -
@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.
