WiFi Direct, Hotspot Tethering, and other P2P WiFi connetions - how to secure them?

E

EnthusiastXYZ

Limp Gawd
Joined
Jun 26, 2020
Messages
221
Some WiFi devices use WiFi Direct / P2P for required TV remote connections and other devices just don't give you the option to disable P2P. How do you secure your network in such cases? Even if you are lucky and your router lets you disable TDLS to prevent P2P/Direct connections to any access points, it doesn't prevent individual devices from launching Hotspots, Tethering, and/or using WiFi Direct.

How can I find out the IP address that my WiFi Direct remote uses when it connects to my Smart TV?
 
You cannot do much of a thing, really. Mostly, Wi-FI Direct is more ad-hoc without an AP/TDLS. Point to point, non-multi-hopping from like your cell to a printer, or a remote to the TV. Funny how they want to encrypt your voice from the remote to the TV, but not tell you much about the data you just sent to them. TDLS is about as "secure" as it gets within the protocol from device to device tunneling through both station's link with the AP. They add some other refinements to the protocol, but makes you start to wonder more about how they are RFC'ing the protocol. This makes you wonder if there is an ulterior motive due to the fact that within the AP's communication and protocols there is "encryption" to the stations already, or that it can bypass possibly particular segmentations of the WLAN. Similar to DoH-which is a fucking abomination. That remote will not TDLS to the other station, IMO. It will most likely be through direct/ad-hoc. If it had an IP, I would laugh and possibly throw it at someone that created the monster. I have been keeping some of my old tech for a reason-kind of Adama'ish.

Makes you feel a little less safe doesn't it? Welcome, to networking 101. It was cool to think in the day how things will communicate, and then you start to learn about "communication" and then think: That is a back door, isn't? The worst is when "they" think of the security for you.
 
Why do you think DoH is an abomination? It doesn't come with backdoors, SSL/TLS is a open-source encryption protocol.
 
EnthusiastXYZ said:
Why do you think DoH is an abomination? It doesn't come with backdoors, SSL/TLS is a open-source encryption protocol.
Click to expand...
Then answer what are the difference between DoH, and DoT? Then you may find the reason that it is an abomination. Note, that I never said anything about DoT. But even DoT has it's downsides, and therefore I rather still resolve with roots. BTW, I will help just a little-What is the purpose of having a port?
 
HTTPS = HTTP + TLS
DoT = DNS over TLS
DoH = DNS over HTTPS = DNS over HTTP + TLS

I am not sure, but I think the main advantage of DoH over DoT is that both HTTPS and DoH use TCP port 443. Many secure networks allow only port 80 and port 443, preventing use of DoT, but allowing DoH.

There is plenty of information about DoH and how it works, but I can't find as much information about how WiFi Direct works. I can only find general information, but nothing specific to help me secure it... Some WiFi Direct uses old WPS, but newer WiFi Direct uses WPA2. That's about the only useful information I can find.
 
You will always want DNS to be local, redirecting external resolvers through NAT, and filtered/sink holed for any security. Sending out requests to "other" DNS providers is not really faster, nor safe. It is a luring technique to get people to send meta data for their usage and to be profitable by making them think that they are "safer". Similar to all the VPN bullshit now by capitalizing on the ignorant user.

The real issue is that by obfuscating the resolutions creates a few problems. You cannot filter/separate the interactions since 443 is very particular to most internet usage now. You cannot see when a resolution or redirection takes place since the traffic will be the port 443 and not segregated like 53 and 853. DoH would have 853 socket indications, and NAT redirection can still happen with 853 and 53, and can be blocked for "safer" browsing. Once you merge that DNS traffic with 443, well shit can happen.

I redirect DNS through NAT, therefore any request from an IoT device that is going to send to externally to X.X.X.X is redirected to the firewall, and then to the root servers. If these devices change to external resolution via DoH, I will lose that ability of control for safer networking. You get to see the activity on your network, which is very important I would say. With 443 bundled traffic, you will mainly think that it is HTTPS and resolutions will be hidden within the encryption. Also, if the IoT device or host is compromised usually security practices can prevent some of the attacks by not allowing their programmed resolution to be injected. DoH makes this impossible and is nothing better for the user therefore it is an abomination of the internet.

As for Wi-Fi direct welcome to the insecurities of ubiquitous connectivity-especially the later shit protocols that were "secure". Unless the station allows the configuration of Wi-Fi direct you will not be able to do much. Most is not managed by admin control, or just not exposed for administration with OTS routers. OS controls are there and can be disabled and even removed. I do not like not being given much control either (cant tell that by now?). Usually, the argument is most users blah,blah. If you ever been around a shit protocol like Bluetooth, and how long it took for them to implement securities-fuck me. Makes you wonder if these people in power want the exposure to take place, rather than prevent......

If the stations are associated with the AP then you will have WPA2/3 encapsulating the direct communication. Also within the WLAN it will also bypass some of the layers of the IEEE, to be more direct, more bandwidth, and less latency-supposedly. As for the ad-hoc, I assume if the options are there to disable (if exposed like mobiles, operating system controls, et al), and even perhaps WPS then these may be the only forms of locking it down. Doing a scan in my MDU area I have only two direct stations available to me. One printer and one FireTV, lol.
 
Last edited by a moderator:
Correctly-configured local DNS server running AdGuard Home or Pi-Hole would show you every correctly-configured client that connects to it over assigned port for DNS resolution, but clients that directly connect to DoH would only be shown in local DNS server logs during their initial boot up, initial connection to WiFi, initial connection to VPN providers, and/or when in sleep mode. Once direct DoH connection is esablished by whichever client, local DNS servers stop showing their traffic. This is good for WiFi clients not running VPN because WiFi encrypts traffic only via WEP/WPS/WPA/RADIUS, but DNS requests to local DNS server are plaintext. If someone intercepts WiFi packets/frames and decrypts WiFi password, then they can perform DNS MITM attack before client DNS requests reach local DNS server. When WiFi clients create direct DoH connections, they are protected by WiFi encryption and by DoH encryption. They can also be protected by the app that creates that on-device DoH connection. That is why I am a fan of AdGuard App, which creates an on-device local VPN and establishes direct DoH connection on client devices to AdGuard public DNS and filters on-device requests via on-device app-based filters. You can customize those filters, create your own, disable WebRTC, etc. It is basically uBlock Origin for mobile devices that filters all apps, not just browsers. AdGuard public DNS server owners even scanned the internet for current CNAME records to filter them better, but AdGuard App doesn't isolate devices and doesn't control ports, like Netfilter/IPTables...

I think DoH is the best better for clients running VPN because they can resolve initial VPN connection over DoH that provides at least some encryption. DoH is only partial encryption, but I can't think of more secure method than to use DoH for initial VPN connection and then maintain VPN tunnel. If you use OpenVPN over TCP port 443 + OpenVPN XOR Obfuscated servers + DoH, your ISP know very little about what you do online and you can use most public WiFi services that tend to block all ports other than TCP port 80, UDP port 53, and TCP port 443.

For WiFi, router-based network isolation is very limited because it can drop/block packets only when packets reach the actual router, but those packets still travel over-the-air before being dropped. The same applies to local DNS servers. WiFi MITM attacks can be performed before any domains are resolved by local DNS server. You have to control actual devices and create on-device firewalls and on-device DNS filters to prevent needless packets from travel over-the-air to your router and to your local DNS server. That is one aspect I dislike about Apple devices. They are generally more secure than Android devices, but without an isolating VPN app you can barely control packets and requests Apple devices send over-the-air because iOS is not open-source. You can't do much with it. Android devices may be less secure, but you can root most of them and apply your own Netfilter rules.

VPN on mobile devices is a mess, regardless of VPN provider. Many devices in sleep mode ignore VPN tunnels and utilize WiFi-assigned DNS. They tend to try to connect to Google domains to detect captive portals, but they also try to connect to Google Accounts domains and Google Playstore API services. That defeats the idea of having a VPN, but not all devices do that. On my network, none of the Apple devices do that and none of the unrooted (and rooted) Google Pixel devices do that, but all unrooted Android Samsung devices ignore VPN in sleep mode, regardless of settings, even if you de-bloat them.

In summary, a combination of on-device DNS filters, on-device firewall, on-device DoH enablement, VPN encryption, local DNS server, secure router firewall + settings, you can protect your WiFi clients relatively well, except for WiFi Direct. You can't disable WiFi Direct/Ad-Hoc on some devices and all your neighbors can see them, just like you can see their WiFi Direct/Ad-Hoc devices. It doesn't matter what WiFi encryption method you use. It is so intrusive. If your mobile phone has permanently-enabled WiFi Direct/Ad-Hoc without a way to disable it and you keep it with you all the time, you can be easily tracked with almost 0 effort without having to connect to any WiFi networks.
 
An issue with networking is that data leaving, and data coming in are something that you never really know what the intent of it is. You may be able to monitor and know some things, but how exactly was the data digested in the upper stack; and where exactly did it go to? There is a lot of trust involved, but in a Gary Gygax'ian way of putting it, an astute player (admin), will be skeptical and would want to roll for detection of secret doors. DNS, unfortunately is a very big issue, and until then all should be thinking about how the requests are resolved. This is because a lot of DNS's shit ain't as good as people think it can be:

Make you wonder who is trying to hack your traffic: https://www.cisa.gov/sites/default/...g_DNS_Resolution_on_Federal_Networks_Memo.pdf

https://www.zdnet.com/article/irani...st-known-apt-to-weaponize-dns-over-https-doh/

https://arstechnica.com/information...ve-kaminskys-2008-dns-cache-poisoning-attack/

https://github.com/Arno0x/DNSExfiltrator
 
You must log in or register to reply here.
Back
Top