Block Apps over Wi-Fi (Facebook-Instagram..)
-
@michmoor @michmoor Hi, thanks for the help.
I'm not using VLANs. Just one network normally.
What I need is when a user opens an APP on their smartphone (Facebook, Instagram..) PfBlocker manages to block this access. Testing on the same network (via WiFi), in browsers the blocking occurs correctly but when we open the Apps, it does not.
-
@michmoor Yes. all via DHCP, correctly, exemple :
IP 10.80.2.xx/22
GW 10.80.0.1
DNS 10.80.0.1The Wi Fi Router is in Access Point Mode. The DHCP is the PfSense.
-
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
But when i use a Smartphone and i open a App ( Facebook, Instagram), the block dont occur.
I don't know for sure if this is the issue, but it might be that those apps are using DOT or DOH to redirect the DNS queries to other providers (8.8.8.8,1.1.1.1, etc.). You could figure that out by doing a packet capture on the smartphone, or log the allowed outbound traffic from your smartphone network then filter the logs for ports 53, 853 and 443. If they redirecting DNS then there might be ways to address that. Let us know what you find out.
Also, those apps might be sending traffic out to a hard coded IPs. In that case the UTI option would not work as there would be no DNS lookup...the traffic would be sent right out. In that case you would need to use option 2 and create firewall rules.
-
@dma_pf Of course, I hope to do it correctly.
Below
%(#1a3e66)[17:39:17.941896 IP 10.80.2.5.49476 > 10.80.0.1.53: UDP, length 33
17:39:17.968887 IP 10.80.0.1.53 > 10.80.2.5.49476: UDP, length 96
17:39:17.976292 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 1232
17:39:17.979722 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.000014 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 1232
17:39:18.002059 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 1232
17:39:18.002132 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 1232
17:39:18.002167 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 1232
17:39:18.002385 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 1033
17:39:18.002458 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 56
17:39:18.006260 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 0
17:39:18.008229 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.013969 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 45
17:39:18.029222 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 218
17:39:18.029346 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 85
17:39:18.029347 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 73
17:39:18.050633 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 42
17:39:18.050640 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 84
17:39:18.050712 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 26
17:39:18.051011 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 250
17:39:18.055308 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 0
17:39:18.056624 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 35
17:39:18.056868 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 1380
17:39:18.056939 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 1380
17:39:18.056941 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 734
17:39:18.059929 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.060977 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.061100 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.068071 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 64
17:39:18.072308 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 1232
17:39:18.072431 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 620
17:39:18.093549 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 0
17:39:18.094099 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 182
17:39:18.094274 IP 157.240.12.52.443 > 10.80.2.5.37642: tcp 80
17:39:18.094350 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 32
17:39:18.116787 IP 10.80.2.5.37642 > 157.240.12.52.443: tcp 0
17:39:18.117802 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 954
17:39:18.139522 IP 157.240.12.52.443 > 10.80.2.5.51801: UDP, length 31
17:39:18.141482 IP 10.80.2.5.51801 > 157.240.12.52.443: UDP, length 35
17:39:18.250613 IP 10.80.2.5.42379 > 10.80.0.1.53: UDP, length 34
17:39:18.250709 IP 10.80.0.1.53 > 10.80.2.5.42379: UDP, length 74
17:39:18.254432 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 0
17:39:18.258263 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 0
17:39:18.269797 IP 10.80.2.5.47534 > 157.240.12.13.443: UDP, length 1232
17:39:18.273434 IP 10.80.2.5.34468 > 157.240.12.13.443: tcp 0
17:39:18.277222 IP 10.80.2.5.47674 > 157.240.12.35.443: tcp 0
17:39:18.279693 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 0
17:39:18.280724 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 0
17:39:18.282448 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 0
17:39:18.283610 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 0
17:39:18.285786 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 407
17:39:18.288802 IP 10.80.2.5.41501 > 10.80.0.1.53: UDP, length 36
17:39:18.288890 IP 10.80.0.1.53 > 10.80.2.5.41501: UDP, length 81
17:39:18.290077 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 405
17:39:18.297160 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 1232
17:39:18.298037 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 1232
17:39:18.298113 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 169
17:39:18.298121 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 55
17:39:18.298948 IP 157.240.12.13.443 > 10.80.2.5.34468: tcp 0
17:39:18.301927 IP 157.240.12.35.443 > 10.80.2.5.47674: tcp 0
17:39:18.304932 IP 10.80.2.5.34468 > 157.240.12.13.443: tcp 0
17:39:18.305054 IP 10.80.2.5.47674 > 157.240.12.35.443: tcp 0
17:39:18.306722 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 0
17:39:18.307177 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 212
17:39:18.307978 IP 10.80.2.5.47534 > 157.240.12.13.443: UDP, length 1232
17:39:18.308147 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 0
17:39:18.316059 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 0
17:39:18.316347 IP 10.80.2.5.59157 > 10.80.0.1.53: UDP, length 38
17:39:18.316369 IP 10.80.0.1.53 > 10.80.2.5.59157: UDP, length 83
17:39:18.316450 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 212
17:39:18.317685 IP 10.80.2.5.34468 > 157.240.12.13.443: tcp 407
17:39:18.326146 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 0
17:39:18.326358 IP 10.80.2.5.47674 > 157.240.12.35.443: tcp 409
17:39:18.326359 IP 10.80.2.5.47534 > 157.240.12.13.443: UDP, length 84
17:39:18.326489 IP 10.80.2.5.47534 > 157.240.12.13.443: UDP, length 72
17:39:18.326491 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 64
17:39:18.326492 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 64
17:39:18.342847 IP 157.240.12.13.443 > 10.80.2.5.34468: tcp 0
17:39:18.342970 IP 157.240.12.13.443 > 10.80.2.5.34468: tcp 212
17:39:18.343898 IP 10.80.2.5.34468 > 157.240.12.13.443: tcp 0
17:39:18.345520 IP 10.80.2.5.34468 > 157.240.12.13.443: tcp 64
17:39:18.347036 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 0
17:39:18.347528 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 179
17:39:18.347765 IP 157.240.12.35.443 > 10.80.2.5.47670: tcp 80
17:39:18.348808 IP 10.80.2.5.47670 > 157.240.12.35.443: tcp 0
17:39:18.350849 IP 157.240.12.35.443 > 10.80.2.5.47674: tcp 0
17:39:18.350949 IP 157.240.12.35.443 > 10.80.2.5.47674: tcp 212
17:39:18.351849 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 0
17:39:18.351899 IP 10.80.2.5.47674 > 157.240.12.35.443: tcp 0
17:39:18.352270 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 42
17:39:18.352340 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 84
17:39:18.352374 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 26
17:39:18.352543 IP 157.240.12.13.443 > 10.80.2.5.47534: UDP, length 247
17:39:18.352622 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 179
17:39:18.352716 IP 157.240.12.13.443 > 10.80.2.5.34464: tcp 80
17:39:18.353532 IP 10.80.2.5.47674 > 157.240.12.35.443: tcp 64
17:39:18.354510 IP 10.80.2.5.34464 > 157.240.12.13.443: tcp 0
17:39:18.355204 IP 10.80.2.5.47534 > 157.240.12.13.443: UDP, length 35
17:39:18.370087 IP 157.240.12.13.443 > 10.80.2.5.34468: tcp 0
17:39:18.370496 IP 157.240.12.13.443 > 10.80.2.5.34468: tcp 179]Note:
The Host 10.80.2.5 is my Smartphone.Test: First iplay the capture.
Open The Instagram APP
Close Instagram APP
Open Facebook APP
Stop the capture. -
@dma_pf agreed on this. Doh/DoT might be in play. You can still block both of those with pfblocker.
-
This:
17:39:17.941896 IP 10.80.2.5.49476 > 10.80.0.1.53: UDP, length 33
17:39:17.968887 IP 10.80.0.1.53 > 10.80.2.5.49476: UDP, length 96and this:
17:39:18.316347 IP 10.80.2.5.59157 > 10.80.0.1.53: UDP, length 38
17:39:18.316369 IP 10.80.0.1.53 > 10.80.2.5.59157: UDP, length 83are definitely DNS queries by your smartphone.
The question is why aren't the being blocked by the UTI list? We won't know for sure unless you look at the packets in wireshark which will show what the domain was that the app queried. It could be that the app is doing DNS query to some CNAME that is not in the UTI list.
Are you using pfblocker in python mode? If so try enabling this setting in Firewall/pfBlockerNG/DNSBL:
Then do a Force/Reload of pfblocker and see if they are then blocked.
-
@michmoor said in Block Apps over Wi-Fi (Facebook-Instagram..):
Doh/DoT might be in play. You can still block both of those with pfblocker.
Definitely!
-
@dma_pf said in Block Apps over Wi-Fi (Facebook-Instagram..):
This:
17:39:17.941896 IP 10.80.2.5.49476 > 10.80.0.1.53: UDP, length 33
17:39:17.968887 IP 10.80.0.1.53 > 10.80.2.5.49476: UDP, length 96and this:
17:39:18.316347 IP 10.80.2.5.59157 > 10.80.0.1.53: UDP, length 38
17:39:18.316369 IP 10.80.0.1.53 > 10.80.2.5.59157: UDP, length 83are definitely DNS queries by your smartphone.
The question is why aren't the being blocked by the UTI list? We won't know for sure unless you look at the packets in wireshark which will show what the domain was that the app queried. It could be that the app is doing DNS query to some CNAME that is not in the UTI list.
Are you using pfblocker in python mode? If so try enabling this setting in Firewall/pfBlockerNG/DNSBL:
Then do a Force/Reload of pfblocker and see if they are then blocked.
-
@dma_pf Yes, the PFBL is using Python mode. I will do what you indicated. I'll try to capture by Wireshark and post here as soon as possible.
-
@dma_pf said in Block Apps over Wi-Fi (Facebook-Instagram..):
This:
17:39:17.941896 IP 10.80.2.5.49476 > 10.80.0.1.53: UDP, length 33
17:39:17.968887 IP 10.80.0.1.53 > 10.80.2.5.49476: UDP, length 96and this:
17:39:18.316347 IP 10.80.2.5.59157 > 10.80.0.1.53: UDP, length 38
17:39:18.316369 IP 10.80.0.1.53 > 10.80.2.5.59157: UDP, length 83are definitely DNS queries by your smartphone.
The question is why aren't the being blocked by the UTI list? We won't know for sure unless you look at the packets in wireshark which will show what the domain was that the app queried. It could be that the app is doing DNS query to some CNAME that is not in the UTI list.
Are you using pfblocker in python mode? If so try enabling this setting in Firewall/pfBlockerNG/DNSBL:
Then do a Force/Reload of pfblocker and see if they are then blocked.
I'll post the results of the tests I did here.
First, the following screen is from Wireshark (PfSense Packet Capture).:
The second is the DNSBL Real Time (Alerts and Unified) screen:
The last one is DNSBL settings:
Thanks
-
@felipepipers Sorry for my delay in getting back to you. I had a very busy evening last night.
I looked over the items in your last post and I have to admit that I'm at a loss of what is happening. The wireshark capture clearly shows that dns requests are being routed to pfsense. I don't see anything that would lead me to believe that this is a DOT or DOH issue. In you packet capture the dns query was asking for the IP address of i.instagram.com.
i.instagram.com is not in the UT1 Social Networks list. It is possible that the dns request might not have gotten caught by a TLD block and therefore the DNS request succeeded thereby providing an IP address to the app. Once that would happen then traffic would be routed using the IP address and (unless there was an IP block rule in the firewall rules) with that Ip address then traffic would continue to instagram.
Can your try this for me? In pfsense go to Diagnostics/DNS Lookup and do a lookup for instagram.com and i.instagram.com. Let me know the results you get, and check the alerts tab in pfblocker and let me know what you see there.
Also, what other lists do you have activated (IP or DNSBL)? I see that there is a Feed/Group in the Alerts picture that you posted called DNS_TLD. What is that?
I'm assuming that the blocked alerts you posted are all from using the browser on the phone. Is that correct, or are you seeing some things blocked in the app?
-
@dma_pf said in Block Apps over Wi-Fi (Facebook-Instagram..):
@felipepipers Sorry for my delay in getting back to you. I had a very busy evening last night.
No problem my friend. You are helping me very much.
I looked over the items in your last post and I have to admit that I'm at a loss of what is happening. The wireshark capture clearly shows that dns requests are being routed to pfsense. I don't see anything that would lead me to believe that this is a DOT or DOH issue. In you packet capture the dns query was asking for the IP address of i.instagram.com.
Ok, understud
i.instagram.com is not in the UT1 Social Networks list. It is possible that the dns request might not have gotten caught by a TLD block and therefore the DNS request succeeded thereby providing an IP address to the app. Once that would happen then traffic would be routed using the IP address and (unless there was an IP block rule in the firewall rules) with that Ip address then traffic would continue to instagram.
Can your try this for me? In pfsense go to Diagnostics/DNS Lookup and do a lookup for instagram.com and i.instagram.com. Let me know the results you get, and check the alerts tab in pfblocker and let me know what you see there.
Here
And i.instagram.com
Also, what other lists do you have activated (IP or DNSBL)? I see that there is a Feed/Group in the Alerts picture that you posted called DNS_TLD. What is that?
I Believe this is the List of DNSBL ( TLD) Domains. Im using in this moment.
Below my settings from my PfBlocker.
I'm assuming that the blocked alerts you posted are all from using the browser on the phone. Is that correct, or are you seeing some things blocked in the app?
No. I wiil sent here screen from my smartphone, using Vysor to extend the screen to Desktop to be possible to me do prints for send here.Updating:
I'd like to report something that got me a little excited. Last night, I did some tests on mobile and monitoring pFsense (DNSBL).After enabling again what you told me, (CNAME validation), and along with this, the DNSBL blacklist (in the answer further up the screen), the behavior of pFblocker has changed positively. Apps opened, but Feed, videos and chat were not loaded! Voila! (is that right?) But no lock screen or error like in browsers, but at least it doesn't load the APPS anymore. On facebook, in Videos, it showed an image of "No internet connection".
Below is the smartphone screens, in the test I did just now to show you: But this time, after I cleared ALL the Cache and saved data, I opened the Apps, one at a time and monitoring the logs in PfBlocker. The evidence follows in the images:
!
"Failed to entry"
Sorry for the long post, but I'm trying to be as detailed as possible, so I don't make mistakes and also help friends.
I await your analysis. Thank you!
-
@felipepipers I'm glad you got it working. It appears to me like something was not reloaded properly, or some DNS entries were cached, or there were some active states that messed up the blocking. With your playing around and reloading things you must have cleared up whatever it was. Your clearly blocking the DNS requests now as you can see from you DNS lookups that did not return an IP address.
There may be other domains that are not in your TLD Blacklists that could also reach out to Facebook/Instagram. Here is a list you can look at: https://raw.githubusercontent.com/jmdugan/blocklists/master/corporations/facebook/all
You could add additional TLD from that list in your TLD blacklist. Or in the alternative you could create a DNSBL Group with that list as a feed and then move your TLD domains from the TLD Blacklist to the DNSBL Custom_List like this:
Now keep in mind that this will only block traffic which is trying to reach facebook by using a domain name. It is still possible that someone could try to reach facebook by using an IP to route the traffic. If you are concerned about that you would need to create an IP alias and then use that alias in a firewall rule to block traffic like this:
IP Alias Setup
Firewall Rule
-
@dma_pf said in Block Apps over Wi-Fi (Facebook-Instagram..):
https://raw.githubusercontent.com/jmdugan/blocklists/master/corporations/facebook/all
First, thanks for your help and suggestions below. I will study about it.
About the functioning of my pfblocker, I still have some doubts. When opening the APP as you can see in the images I sent, it opens the app but does not update.
Is this behavior normal?
Another question, taking advantage of this topic: Is it possible to customize the DNSBL lock screen on desktop sites?
-
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
About the functioning of my pfblocker, I still have some doubts. When opening the APP as you can see in the images I sent, it opens the app but does not update.
That would be the expected behavior if you block the app from communicating with facebook's servers. It wouldn't be able to update.
Pfblocker can't prevent the app from opening. What it will do is prevent the app from communicating with any server that is blocked by either a DNS Blocklist (including TLDs) or IP firewall rules using an IP alias. Think of the app as a browser. It can start up but pfblocker would then prevent it from surfing to facebook (obviously, as long as the phone is connected to your network).
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
Another question, taking advantage of this topic: Is it possible to customize the DNSBL lock screen on desktop sites?
I'm assuming you mean the page that gets displayed when a site is blocked. If so:
You can modify the existing file above or create a new page and upload it to the folder indicated above. Keep in mind that those pages only work for HTTP connections. If the site is encrypted, HTTPS, then that page cannot be displayed. The viewer will see an error message from the browser.
-
@dma_pf said in Block Apps over Wi-Fi (Facebook-Instagram..):
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
About the functioning of my pfblocker, I still have some doubts. When opening the APP as you can see in the images I sent, it opens the app but does not update.
That would be the expected behavior if you block the app from communicating with facebook's servers. It wouldn't be able to update.
Pfblocker can't prevent the app from opening. What it will do is prevent the app from communicating with any server that is blocked by either a DNS Blocklist (including TLDs) or IP firewall rules using an IP alias. Think of the app as a browser. It can start up but pfblocker would then prevent it from surfing to facebook (obviously, as long as the phone is connected to your network).
Sure, understud.
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
Another question, taking advantage of this topic: Is it possible to customize the DNSBL lock screen on desktop sites?
I'm assuming you mean the page that gets displayed when a site is blocked. If so:
Yes, correct.
You can modify the existing file above or create a new page and upload it to the folder indicated above. Keep in mind that those pages only work for HTTP connections. If the site is encrypted, HTTPS, then that page cannot be displayed. The viewer will see an error message from the browser.
So, just will work with http pages. And for HTTPS, some idea?
Grateful
-
@felipepipers said in Block Apps over Wi-Fi (Facebook-Instagram..):
And for HTTPS, some idea?
There is no workaround for HTTPS. It works on HTTP because pfblocker serves up the page when it blocks a site. Since the page is unencrypted the browser just serves up the page it's given. Pfblocker acts as a Man-In-The-Middle between the browser and the intended server and injects a non-asked for page.
By its design, HTTPS works by the browser verifying that the security certificate of the server it is trying to connect to is from the same domain it is intending to reach. So in pfblocker's case if it tries to serve up the blocked page the browser will not display it because it did not come from the validated server it was trying to reach. The browser then displays a security warning and won't load the page that it was served.
As an aside I noticed that there is a Facebook DNSBL feed in pfblocker that I had not noticed before:
