Can someone explain why this rule gets triggered by Snort 3:19187?
-
@Gertjan Sorry for the late reply. Whenever I turn on my TV I see these entries now
1 UDP Attempted User Privilege Gain 8.8.8.8 53 10.0.10.2 41746 3:19187 PROTOCOL-DNS TMG Firewall Client long host entry exploit attemptI am also seeing this now from my work computer
2 UDP Potentially Bad Traffic 192.168.1.50 64776 192.168.1.1 53 1:2027757 ET DNS Query for .to TLD2 UDP Potentially Bad Traffic 192.168.1.50 59869 10.0.170.10 53 1:2027757 ET DNS Query for .to TLMy pfsenes is 192.168.1.1. Since I see a lot of weird DNS blocks I am getting concerned if it could be a MITM attack or something like this? Since it is UDP and some .to Domain when I am not even visiting a .to Domain. I happens when turning on the computer.
I also setup my smart TV not to use google but the gateway instead. Or is there a conflict with my DNS settings. I enabled DoT with Cloudflare but the VLAN for my Smart TV was set to 8.8.8.8 as DNS server?
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
t could be a MITM attack
Between your PC and pfSense you can have a LAN cable, maybe a switch.
Hard to MITM that ^^Btw : You use snort. I'm not using it myself, as it would take me way to much time to learn about the rules, how to interpret the results, and so on.
From what you've shown, snort is probably listing the rule that matched so the message shows up.
What is that rule ?@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
I happens when turning on the computer.
Oh ...
Be ware : before you start typing on the keyboard of your PC, it has, during initial boot, already visited dozens of "sites" on the internet.
Same for Pads, phones etc.@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
I also setup my smart TV not to use google but the gateway instead. Or is there a conflict with my DNS settings. I enabled DoT with Cloudflare but the VLAN for my Smart TV was set to 8.8.8.8 as DNS server?
Explain again ?
VLAN ?? -
@Gertjan Ok so my VLAN is on 10.0.10.1/24 and in the DHCP server settings I had 8.8.8.8 setup as DNS server. On my TV I then had to set a static IP with 10.0.10.1 as gateway and DNS server. But for pfSense I have configured DoT with Cloudflare in the Generals Setup and under Services -> DNS Resolver. I assume something gets mixed up here and that is why I am seeing the alert.
-
Despite removing 8.8.8.8 as DNS server in my VLAN I still see this message:
1 UDP Attempted User Privilege Gain 8.8.8.8 53 10.0.10.2 46563 3:19187 PROTOCOL-DNS TMG Firewall Client long host entry exploit attemptI found this old thread were people saw something similar
https://www.reddit.com/r/PFSENSE/comments/2u09v4/hijack_for_people_using_google_dns/It's a little concerning. Can my TV be hijacked?
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
It's a little concerning. Can my TV be hijacked?
No, your TV is not hijacked. Why on earth would someone want to do that anyway?
You are experiencing one of the times an IDS/IPS can generate a false alert. In my opinion that is a very poorly written Snort rule. It is simply triggering because of a long host name DNS query. Notice the alert message says "long host entry". The rule authors love to put in extra words to make it sound sinister like "exploit attempt"
, but 9 times out of 10 it is not sinister and is instead just expected behavior for the client.As @Gertjan demonstrated in a post earlier in this thread, the streaming providers love to embed all kinds of extra "stuff" in requests so they can both track what you are watching and where you might be within the stream's time window (so they can display the "resume viewing" option and reliably return you to the same spot in the stream later).
If you are genuinely concerned about this alert and want to know if your TV has been hacked, then you will need to enable packet capture on the firewall, capture all the packets flowing to and from your TV, then load them into a Wireshark session and start rebuilding the frame-by-frame data flow to see what all is happening and what explicit data is being exchanged. If you actually go to that much trouble, I'm pretty sure you will be disappointed as you are most likely going to come up empty and see that it is just normal traffic.
-
@bmeeks Maybe it is nothing but I am also seeing DNS queries for .to addresses from two other devices. When I am in my firms VPN it goes to 10.0.170.10 but also to my pfsense IP 192.168.1.1 directly. I am not sure how interpret these entries. I have a total of 66 entries like this in 2 weeks since I enabled DNS rules to show up in Snort. I mean it gets blocked which is good but I am still not sure what it could be.
2025-03-26 08:03:51 2 UDP Potentially Bad Traffic 192.168.1.50 49918 192.168.1.1 53 1:2027757 ET DNS Query for .to TLD 2025-03-26 08:03:51 2 UDP Potentially Bad Traffic 192.168.1.50 49918 10.0.170.10 53 1:2027757 ET DNS Query for .to TLD2 UDP Potentially Bad Traffic 192.168.1.12 60705 192.168.1.1 53 1:2027757 ET DNS Query for .to TLD -
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
@bmeeks Maybe it is nothing but I am also seeing DNS queries for .to addresses from two other devices. When I am in my firms VPN it goes to 10.0.170.10 but also to my pfsense IP 192.168.1.1 directly. I am not sure how interpret these entries. I have a total of 66 entries like this in 2 weeks since I enabled DNS rules to show up in Snort. I mean it gets blocked which is good but I am still not sure what it could be.
2025-03-26 08:03:51 2 UDP Potentially Bad Traffic 192.168.1.50 49918 192.168.1.1 53 1:2027757 ET DNS Query for .to TLD 2025-03-26 08:03:51 2 UDP Potentially Bad Traffic 192.168.1.50 49918 10.0.170.10 53 1:2027757 ET DNS Query for .to TLD2 UDP Potentially Bad Traffic 192.168.1.12 60705 192.168.1.1 53 1:2027757 ET DNS Query for .to TLDYou seem to have very little experience administering an IDS/IPS. They are very complicated animals and require a lot of experience to properly evaluate what is an actual threat versus what is just false positive "noise". Don't let yourself become paranoid. Every alert is not a hack. There will be thousands of times more false positive alerts than there ever will be of a valid actual "bad traffic" alert. That's the nature of IDS/IPS, especially one where the rules enabled have not been tailored to the vulnerabilities and threats present in the protected network. Simply enabling a bunch of rules without knowledge of what each rule is designed to detect (and why) is a recipe for frustration.
In your case, you have enabled DNS query rules that are simply triggering on certain top-level-domains (TLDs) being queried. There is absolutely nothing inherently sinister in queries to those TLDs these days -- especially with the explosion of new TLDs in addition to the old .com, .edu, and .gov TLDs the Internet began with. The DNS query could have been triggered from nothing more than some ad embedded on a website, for example. Your browser needs to do DNS lookup to convert the fully qualified hostname in the HTML code of the web page into an IP address. That lookup could trigger that rule, but the actual DNS query is completely benign and expected.
-
@bmeeks I have no experience to be honest but I am learning through it. I enabled the DNS rules because I had websites resolve very slowly or only after doing a refresh. So I am investigating what could be the cause. I already learned that a lot of the stuff is noise but I am checking blocked IPs on abuseipdb.com and sometimes they have bad reputation. Worst I saw was like 45% likelyhood of abuse but it seemed to be Firefox related services.
A little off topic question but I am using a double nat setup because of ISP router. Is it necessary to set up DoT on both devices or is it sufficient to do it only on the ISP or only in pfsense?
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
Is it necessary to set up DoT on both devices or is it sufficient to do it only on the ISP or only in pfsense?
Why do you want DoT? Why not simply leave the DNS Resolver on pfSense in its default state of "resolving and not forwarding", then point your LAN clients to pfSense as their DNS server. The DNS Resolver on pfSense would then go directly to the DNS root servers, find the applicable root server for the queried TLD, and then from there find the assigned DNS server for the domain in question. No need for DoT and all that overhead that you incur from forwarding. And Google or Cloudflare or NextDNS or OpenDNS would not get your DNS queries handed to them on a silver platter.
And once you enable DoT, your IDS/IPS is blind to DNS traffic as it will then be encrypted and all the IDS/IPS can see is random bits of encrypted data. So, if you are paranoid about your DNS traffic and want to know what every lookup is doing, then switching to DoT means you can then see nothing in the DNS traffic.
-
@rasputinthegreatest: not trying to be hard on you, but do want to encourage you to think through carefully what you wish to do in terms of cybersecurity
.On the topic of DoT, I ask "why" because what is your actual goal with DoT? Is it to hide your DNS query from someone like your ISP? That is usually everyone's first answer when asked that question. But are you effectively hiding anything when you consider it this way --
- Your LAN client performs a DNS lookup for (let's be naughty here
) say pornhub.com. DoT will let you hide that DNS query from your ISP. - But what is the next thing that happens? Your LAN client receives a reply via DoT that says "you can find pornhub.com at this IP address, x.x.x.x".
- What is the next thing your client does? Yep, it connects to that IP address. So, all your ISP has to do is log the IP addresses you connect to and they know where you are going via a simple reverse DNS query or matching the IP with ASN lists.
- The only time the above scenario would not be true is if you routed all traffic through a VPN. And in that case, why not just leave DNS unencrypted and use your VPN provider's DNS? Many of them attempt to force that on you anyway. That VPN provider is for sure going to know exactly what IP address you visited as well. You are just trusting them to keep that confidential. Some may, but many won't when push comes to shove and they receive a request from law enforcement "they can't turn down".
Many IDS/IPS users fail to think through fully the impact of all the encryption on the Internet today. Hardly anything is cleartext any more. DoT, DoH, HTTPS, SSH, SMTPS, POP3S, IMAPS, QUIC, etc., all totally hide the packet payload behind encryption. An IDS/IPS sees nothing but un-decipherable random data bits in those protocols unless you do a MITM (man-in-the-middle) interception of the encryption chain. And doing that is both complicated and not really possible with some devices such as Smartphones.
I managed cyber systems for several years, and I've heard all the arguments and justifications for "defense in depth". But frankly, the almost total domination of encryption has rendered the old IDS/IPS on the perimeter model obsolete or at the least highly inefficient as you will spend a huge amount of time and energy chasing false positives. The glory days of the past where most network perimeter traffic was in the clear and could be sniffed and analyzed are gone never to return. In fact, many of the rules packages today are little more than lists of IP addresses the IDS/IPS will alert on when detected as source or destination addresses of a packet. But why use all the other IDS/IPS overhead for simple IP matching/detection? The firewall can already do that just fine and much faster than the IDS/IPS can.
Much better and more effective to concentrate your cybersecurity efforts on the endpoints (servers, workstations, tablets, etc.) and on user training (teach them to not be dumb and click on everything with wild abandon).
- Your LAN client performs a DNS lookup for (let's be naughty here
-
@bmeeks I can't tell you how thankful I am for your thorough explanation. So all I am doing right now is wasting resources basically. But isn't DNSSEC and DoT a protection againt MITM attacks? The whole reason I got this pfsense box was because I was having massive upload issues almost daily that only stopped after a reset of my ISP router. Sometimes it was 2 days, 3 days fine but then it dropped. So far I have been up and running for 2 weeks with no drops in upload speed since I setup DoT which might just be coincidence but it is a little strange for sure. I was trying to find the culprit but never was able to pinpoint to any device hogging my upload speed. I was worried that maybe the ISP router itself is the issue and got compromised becaues for a while I was not able to receive updates for the OS through my ISP. It always timed out according to the system log. But let's not open a whole other can of worms here
@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
The DNS Resolver on pfSense would then go directly to the DNS root servers, find the applicable root server for the queried TLD, and then from there find the assigned DNS server for the domain in question. No need for DoT and all that overhead that you incur from forwarding. And Google or Cloudflare or NextDNS or OpenDNS would not get your DNS queries handed to them on a silver platter.
I don't understand this part. How is Unbound hiding my requests from Cloudflare etc.
And that means I don't put Cloudflare as my DNS provider in the General Setup? Since I running a double NAT does it matter what the DNS setup is inside my ISP router? Unfortunately I don't have a bridge option.Would you mind sharing your DNS settings how you set them up? Do you have DNSSEC enabled in System -> DNS Resolver?
Also I am definitely focused on protecting my endpoints first and foremost.
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
How is Unbound hiding my requests from Cloudflare etc.
When you install pfSense, 'CloudFlare' isn't known to pfSense, neither by hos name, or any of the IPs is uses.
So, pfSense will never contact cloudflare ....pfSense, the resolver, or unbound (the name of the process) uses this : How DNS Works - Computerphile.
After looking at the video twice ( ! ) you can test for yourself :
On pfSEnse, console or SSH :dig facebook.com +traceor better, as DNSSEC is polluting the story a bit :
dig facebook.com +trace +nodnssecThis is what the info means :
First, unbound knows about the 13 'official' DNS root servers. Their IP addresses (IPv4 and IPv6) are build in.
These servers can only tell unbound where to find a Top Level Domain server.
Note that the root servers will noit receive the full host name : "facebook.com.", it will only receive the requested TLS : "com."In this case, a dot com server is needed, so, unbound will ask to one ( 1 ) of the roots servers :
Give me the address (IPv4 and IPv6) a dot com server = a TLD server that handles the dto com domain names.
unbound will get the IP.
It will contact this TLS, and ask : give me the domain name servers (always at least two !) that handle "facebook.com."
Unbound will get the IPs back of the domain name servers that handle the domain name "facebook.com.".
Now, unbound can ask to one of these 'facebook.com' domain name servers : what is the IPv4, (a) or IPv6 (aaaa) or the mail server (mx) of facebook?com.
As our dig command didn't specify what we were asking for, 'a' or the IPv4 is default.The facebook domain name server will return the IPv4 of facebook.com.
At this moment, unbound will give this answer tio the LAN device that was asking for "facebook.com", and the, for example, browser ion that device can now connect to that IP, and load the 'webpage' that comes from facebook.com.
No*-where in this process, Cloudflare is used or needed.
With pfSense, you don't need your :
ISP DNS servers
Google DN servers,
or Cloudflare DNS servers.
pfSense, with unbound, the resolver, can do everything for you.Note : only the facebook domain name servers will receive the fully requested host name.
So only facebook will know that you probably are going to visit facebook.
And yes, yours ISP has also access to this info if you are not using a VPN.About DNSSEC : because facebook uses DNSSEC : https://dnsviz.net/d/facebook.com/dnssec/ unbound (resolver) will also validate the entire DNS sequence from top to bottom, so when you ask pfSense to resolve facebook.com, you will receive a certificated answer that guarantees that you got the right IP back ( and not a spoofed one ).
Imagine : you type or use the URL (host name) of your bank.
The DNS of your ban was spoofed.
You connect to a site that looks like your bank, smells like your bank, and it ask you for your credentials - of course.
You'll type them in, and then ... "some error" and then nothing.
And from now, the guy who spoofed your bank DNS records has now your login credentials ....
DNS Spoofing => DNS Cache Poisoning.Imho : you want to use DNSSEC.
Or you forward to some one else (Cloudflare, Google DNS, 1.1.1.1 etc) and you do not do DNSSEC ....Remember : when you forward, you don't do DNSSEC.
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
Would you mind sharing your DNS settings how you set them up? Do you have DNSSEC enabled in System -> DNS Resolver?
Here are my settings:
All of my LAN clients are told to use pfSense for their DNS server. I'm using the DNS Resolver in pfSense set to resolve (meaning it does not forward requests, it resolves them on its own).
I think maybe you do not have a clear picture of the distinction between resolving and forwarding. DNS servers can either look things up on their own via resolving (which @Gertjan explained very well in his post above) or they can simply forward the request on to another DNS server and let that server do the resolving work. Back in the days before more capable router software such as pfSense, forwarding was required and you usually sent the request to a DNS server that your ISP maintained and provided you the IP address for. Then later the giant DNS providers came forth such as Google, Cloudflare, and others. They are "forwarding destinations" for those folks who choose that path. But if you have a very high function tool such as pfSense that offers the
unboundDNS Resolver package, then use that tool and let it resolve on its own and dispense with forwarding requests to an external resolver altogether.DoT and DNSSEC are different things for different purposes. DoT stands for DNS over TLS (transport layer security) and it describes a process where the actual DNS traffic (the data) is encrypted so it is not readable by anyone except the precise two devices swapping data with each other (a client and a server). DNSSEC, on the other hand, is not encryption of the payload at all. It is instead a certificate-based security handshake that authenticates or validates the identity of the DNS server. The DNS server presents a certificate that attests to the validity of the server much the same as a website's SSL certificate attests to the identity of a web server. Note that not all DNS servers out on the Internet support DNSSEC, so don't assume it will always be used if enabled.
The DNS Resolver in pfSense can utilize DNSSEC when the other server being queried offers it. So, I would enable it for resolving mode. But do NOT enable DNSSEC when forwarding all your requests to someone else such as Cloudflare or Google for them to resolve for you. DNSSEC when used with forwarders is known to cause problems.
The only way to convert a hostname to an IP address is through DNS resolution (or resolving). But the key difference between "resolving" and "forwarding" in the context of the DNS service in pfSense is who does that resolving. It can be either the
unboundDNS program within pfSense, or if you elect to forward to somone such as Google or Cloudflare (by entering those servers' IP addresses in the DNS configuration on the firewall), then that other server will do the actual work of resolving and then send the answer back tounboundwhich then returns it to your LAN client that made the initial request. Butunboundcan do all the resolving work on its own just fine without any connection to Google or Cloudflare or any other DNS provider. It knows how to follow the resolving trail from the 13 DNS root servers all the way to the authoritative DNS server for the domain you are seeking. -
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
I was having massive upload issues almost daily that only stopped after a reset of my ISP router. Sometimes it was 2 days, 3 days fine but then it dropped.
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?
Problems accessing particular websites could be caused by two different things. First, you must be sure you are connecting to the correct IP address because everything in the end must be one IP address directly to another IP address. Names are simply for human convenience and that's where DNS is used to look up the IP address for a given hostname. If your ISP's DNS server was having problems resolving, that can manifest as "not able to connect" because your LAN client could not obtain the correct IP. If your ISP was having temporary routing issues in their network, that can also manifest as "not able to connect" because even though your LAN client knows the correct destination IP address the traffic does not get there because of routing problems that are your ISP's issue.. You need to know which it was.
Double-NAT is not the ideal situation, but there is nothing inherently evil about it. But it does mean that any performance bottleneck in your ISP provided router will be the limiting factor in your network no matter how powerful and whiz-bang your pfSense firewall is.
I take it you are a residential user protecting his home network. First thing to consider in that case is no matter how proud we might be of our home network, it has pretty much zero value to a criminal hacker or a state-sponsored blackhat group. Those guys (criminals and nation-states) are after huge fish with tons of money to be stolen like corporations or big public sector targets. You and I just don't have anything worthy in our home network that interests them. The worst thing that might happen to us is an occasional phishing attempt or a script kiddie trying to use ransomware on our photos library. That's why I said the best defensive strategy for a home network is installing all software security updates and hotfixes immediately upon their release, and run an anti-virus client on your endpoints where possible. In my view, the free tools in Windows 10 and 11 are perfectly fine for that and there is no need for any paid product. A basic default pfSense install will totally secure a typical home network. I run exactly one package on my pfSense firewall -
apcupsd- to let my UPS gracefully shutdown the firewall upon loss of AC power and when the UPS battery is expiring. I maintain the Snort package and I wrote the Suricata package for pfSense, and I don't use either of them in my home firewall because they add complexity and chew up resources for essentially no gain in my home network scenario. -
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
@Gertjan @bmeeks Thanks a lot for taking the time to explain all this. I am learning a lot thanks to you both. I will process the information and come back to you.
@bmeeks This needs to be disabled if I follow your setup, correct?
Correct. You do not want to use forwarding (in my opinion). Unchecking that box lets
unbound(the DNS Resolver in pfSense) do the resolving on its own. It will then return the IP address it finds to your local LAN clients.The only time forwarding to someone like Cloudflare or Quad9 makes sense in my view is if you want to take advantage of their DNS filtering services where they screen out "bad" or "NSFW" (not safe for work) results for sites such as porn and other similar content.
-
@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.
