Can someone explain why this rule gets triggered by Snort 3:19187?
-
@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.
-
@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.
-
@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. -
@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 each 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.
-
@bmeeks another question since I am still seeing something I can't explain. My phone was usually just connected to my guest wifi on my ISP router. I now connected it to an Access Point for the first time and seeing something I can't really make heads or tails of.
1 UDP Attempted User Privilege Gain 192.168.179.1 53 192.168.1.73 49294 3:19187 PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt192.168.179.1 is the guest wifi on my ISP router and my phone is 192.168.1.73 that is connected to my Access Point that sits behind my pfsense box that sits behind the ISP router.
How can a guest wifi be the source if I am on another wifi and those networks should be totally isolated from each other by pfsense default WAN rules that block bogon and private networks.
Is this just happening because my phone has both networks saved but the source is 192.168.179.1 and not the other way around which would make more sense if my phone was reaching out to the guest network. But the guest network tried to reach my phone.
I don't see that behaviour from other phones on my wifi access point that sits behind pfsense but my phone has a lot of foreign IPs as source coming in.
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
@bmeeks another question since I am still seeing something I can't explain. My phone was usually just connected to my guest wifi on my ISP router. I now connected it to an Access Point for the first time and seeing something I can't really make heads or tails of.
1 UDP Attempted User Privilege Gain 192.168.179.1 53 192.168.1.73 49294 3:19187 PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt192.168.179.1 is the guest wifi on my ISP router and my phone is 192.168.1.73 that is connected to my Access Point that sits behind my pfsense box that sits behind the ISP router.
How can a guest wifi be the source if I am on another wifi and those networks should be totally isolated from each other by pfsense default WAN rules that block bogon and private networks.
Is this just happening because my phone has both networks saved but the source is 192.168.179.1 and not the other way around which would make more sense if my phone was reaching out to the guest network. But the guest network tried to reach my phone.
I don't see that behaviour from other phones on my wifi access point that sits behind pfsense but my phone has a lot of foreign IPs as source coming in.
This is a DNS reply back to IP address 192.168.1.73 (which you said is your phone). The addresses listed in a Snort alert are SOURCE IP and PORT followed by DESTINATION IP and PORT.
-
@bmeeks The source is 192.168.179.1 (my ISP guest wifi) and there should be no way it can even reach my phone through the pfsnse firewall since it is a seperate network that should be blocked by the bogon/private networks rule. Maybe I misunderstand something. If I am not even connected to my guest wifi but an access point behind my pfsense. How is there communication between those two networks? I doubt my phone can be connected to both at the same time. Or is my phone periodically checking for availability of my guest wifi and that causes an alert?
-
@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
And Google or Cloudflare or NextDNS or OpenDNS would not get your DNS queries handed to them on a silver platter.
But your ISP will—which already has quite a bit more private information about you to correlate with your lookup data before selling all of the above.
@bmeeks said in Can someone explain why this rule gets triggered by Snort 3:19187?:
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 vast majority of services nowadays, including the naughty ones, make use of worldwide CDNs. So it's quite a bit more difficult (if not outright impossible) than the ISP simply performing a PTR or ASN lookup.
I thought you were going to suggest SNIs being sniffed from SSL handshakes—which currently is a real concern. But 1). it's presumably slightly more resource-intensive (i.e., larger packets, more complex parsing) for the ISP; and 2.) it'll continue to be mitigated by Encrypted Client Hello as adoption spreads.
Gotta ultimately pick your poison. One 'security and privacy'-maximizing solution in the current state of affairs might be to configure both Cloudflare and Quad9's DoT-capable resolvers (making sure to also specify the
cloudflare-dns.comanddns.quad9.netdomains respectively) in pfSense's DNS settings; configure Unbound to forward via DoT; and any/all other outbound UDP/53 and TCP/853 traffic blocked, together with a heavy dose of known-DoH server IP filtering via pfB. -
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
The source is 192.168.179.1 (my ISP guest wifi) and there should be no way it can even reach my phone through the pfsnse firewall since it is a seperate network that should be blocked by the bogon/private networks rule. Maybe I misunderstand something.
A diagram of how your network is connected would be most helpful here. I am not sure what is connected to what.
Where are you running the Snort instance that logged the last posted alert? Be aware that Snort places any interface it runs on in promiscuous mode. This will cause Snort to see all traffic traversing that physical interface.
The Snort alert you last posted is part of a DNS reply sent back to your client (you said this was your phone) by whatever device resides at 192.168.179.1. So, your phone initially sent a request which I assume was a DNS lookup request to somewhere. A state was created for that traffic, and when the targeted host replied its stateful reply was sent back to your phone (or whatever the IP address at 192.168.1.73 is).
Snort runs outside the firewall rules engine. That means Snort sees traffic on interfaces before any firewall rules have been applied.
-
[ Internet ] | | [ FritzBox Router ] Guest Wi-Fi: 192.168.179.1 | | (WAN port) [ pfSense Firewall ] WAN: 192.168.178.40 LAN: 192.168.1.1 | | [ Access Point / Wi-Fi ] | | [ Phone Device ] IP: 192.168.1.73As you can see my Fritzbox guest network is on 192.168.179.1. My WAN is on .178.
My pfsense is on 192.168.1.1I don't know how 179 could reach 178 because the guest wifi in a Fritzbox is completely isolated and I disabled that devices in that network can even communicate with each other.
-
@rasputinthegreatest said in Can someone explain why this rule gets triggered by Snort 3:19187?:
[ Internet ] | | [ FritzBox Router ] Guest Wi-Fi: 192.168.179.1 | | (WAN port) [ pfSense Firewall ] WAN: 192.168.178.40 LAN: 192.168.1.1 | | [ Access Point / Wi-Fi ] | | [ Phone Device ] IP: 192.168.1.73As you can see my Fritzbox guest network is on 192.168.179.1. My WAN is on .178.
My pfsense is on 192.168.1.1I don't know how 179 could reach 178 because the guest wifi in a Fritzbox is completely isolated and I disabled that devices in that network can even communicate with each other.
You did not tell me which interface you are running Snort on, so I still can't give you a concrete answer. But I can tell you that your Snort alert shows the device at IP 192.168.179.1 attempted a communication with a device at 192.168.1.73. Now, whether that communication attempt was successful or not I cannot say because I don't know which pfSense interface Snort was running on when it captured that traffic.
Perhaps things are not configured as you believe ??
-
@bmeeks Sorry for the missing info. Snort is running on the LAN interface on my pfsense port. Behind that port sit a switch and behind that switch is my Access Point. I don't think there is a faulty configuration because those networks are totally separate from each other. I don't know how traffic would be able to pass through that. Here are my settings that might be relevant.
General Setup:
If I am using my Fritzbox without pfsense the network 192.168.178.1 can't even see 192.168.179.1
It's strange that it happend here. I don't have a good explanation. -
@rasputinthegreatest I realized I had packet captures enabled. I found this in Wireshark:
192.168.179.1 192.168.1.73 DNS 158 Standard query response 0x6ffc HTTPS chrome.cloudflare-dns.com HTTPSDoesn't tell me much though. Still makes no sense to me how this connection could happen and be captured.
I saw this IP in the packet capture with an insane AV detection rate and IDS warnings on this website:
https://otx.alienvault.com/indicator/ip/172.64.41.3
