When I design someone, critical applications get their own network namespace with only the VPN interface inside anyway. So, yeah.
How do you set this up?
There’s readily available docker containers for it but I wanted to build it by hand. Well, more or less, Extremely hacky but it works, so fine for me.
I started out with cheating and used this wrapper around wg-quick that gives us a persistent network namespace with the tunnel interface in it:
https://github.com/dadevel/wg-netns
cat /etc/systemd/system/wg-qbittorrent.service [Unit] Description=WireGuard Network Namespace for qBittorrent Wants=network-online.target nss-lookup.target After=network-online.target nss-lookup.target [Service] Type=oneshot Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity Environment=WG_VERBOSE=1 ExecStart=/opt/wg-netns/bin/wg-netns up /etc/wireguard/wgconfig.yaml ExecStop=/opt/wg-netns/bin/wg-netns down /etc/wireguard/wgconfig.yaml RemainAfterExit=yes WorkingDirectory=%E/wireguard ConfigurationDirectory=wireguard ConfigurationDirectoryMode=0700 CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN LimitNOFILE=4096 LimitNPROC=512 LockPersonality=true MemoryDenyWriteExecute=true NoNewPrivileges=true ProtectClock=true ProtectHostname=true RemoveIPC=true RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK RestrictNamespaces=mnt net RestrictRealtime=true RestrictSUIDSGID=true SystemCallArchitectures=native [Install] WantedBy=multi-user.targetThen I built a static binary of qbittorrent using this really neat docker image: https://github.com/userdocs/qbittorrent-nox-static
…and stuffed the result into a systemd service that runs it in the namespace wg-netns provides:
cat /etc/systemd/system/qbittorrent-nox.service [Unit] Description=qBittorrent-nox service Wants=network-online.target wg-qbittorrent.service After=local-fs.target network-online.target nss-lookup.target wg-qbittorrent.service [Service] Type=simple PrivateTmp=false #User=qbittorrent ExecStart=/usr/sbin/ip netns exec ns-qbittorrent sudo -u qbittorrent /opt/qbittorrent/qbittorrent-nox TimeoutStopSec=1800 RestartSec=15 RestartMaxDelaySec=600 RestartSteps=10 Restart=always [Install] WantedBy=multi-user.targetTo get the webui out of that I stuck two instances of socat together at the stdout and from there it depends on whatever you want to use as a reverse proxy on the host - or you bind to a network interface if you trust the network:
cat /etc/systemd/system/qbittorrent-webui.service [Unit] Description=qBittorrent-nox webui forwarding into its namespace Wants=network-online.target wg-qbittorrent.service After=local-fs.target network-online.target nss-lookup.target wg-qbittorrent.service [Service] Type=simple PrivateTmp=false ExecStart=/opt/qbittorrent/forward-webinterface.sh TimeoutStopSec=1800 Restart=always RestartSec=10 [Install] WantedBy=multi-user.targetcat /opt/qbittorrent/forward-webinterface.sh #!/bin/sh set -eu exec socat tcp6-listen:"8080",reuseaddr,fork,range=[::1]/128 "exec:ip netns exec ns-qbittorrent socat stdio 'tcp-connect:127.0.0.1:8080',nofork"Works, is reboot safe, stopped caring about beauty at that point.
Do you know how to make it so all the host’s traffic is sent through the VPN namespace? I couldn’t figure out how to do this so I ended up just writing my own firewall. Network namespaces seems like a better solution.
I haven’t found the time to research an answer for you, sorry. The way I’d go is: create a veth of your physical uplink and stuff it into its own namespace with dhcp client and wg userspace tools. Do not configure the original interface in your initial namespace. Use the approach wg-netns uses to spawn the tunnel interface in initial network ns. Done.
i think docker allows for this configuration. i use a gluetun container for the network definition of the torrent container to prevent leaking. the torrent container knows of no other network than the vpn container.
there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.
So . . . unix? Everything-but-Windows?
Everything-but-Windows?
No. Any device that implements a certain DHCP feature is vulnerable. Linux doesn’t support it, because most Linux systems don’t even use DHCP at all let alone this edge case feature. And Android doesn’t support it because it inherited the Linux network stack.
because most Linux systems don’t even use DHCP
This is the dumbest thing I’ve heard all day.
As of this writing, 5 people who don’t know how DHCP works saw this comment
most Linux systems don’t even use DHCP
WTF are you smoking? WTF is wrong with you that you think such a dumb claim would go unscrutinized? I would play Russian roulette on the chances of a random Linux installation on a random network talking DHCP.
Edit, in case being charitable helps: DNS and IP address allocation aren’t the only things that happen over DHCP. And even then the odds are overwhelming that those are being broadcast that way.
Maybe it affects BSD and MacOS.
It also can affect some Linux systems based on configuration. Android doesn’t implement the exploited standard at all and is always immune.
“There are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android.”
So there are ways.
Common Linux w
Android
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
This is the way
Wait so the vulnerability exists on macos and iphone even though those are based on bsd (right?)
Edit: and also Windows, forgot about Windows
Hilariously enough, Windows users can use WSL to run a Linux VPN (but only applications running in WSL are safe if I understand the attack right)
True, if you neg a linux dev online enough for two years, you can make your entire infrastructure vulnerable to attack
That’s why half decent VPN apps also add firewall rules to prevent leakage. Although nothing can beat Linux and shoving the real interface in a namespace so it’s plainly not available to anything except the VPN process.
Yes, I don’t agree with the no way to mitigate statement.
I suspect on windows the only real defence is something like.
- Check if the network has suspicious multiple routes setup from the DHCP
- If so, either use the IP/Mask/Gateway with manual IP config (to not receive the CIDR routes) or steer clear of an at best questionable network entirely.
- Maybe use the windows firewall to block all traffic outbound EXCEPT from the firewall program (with perhaps exceptions for local networks as per below linux example). For whatever reason the windows firewall doesn’t seem to have a way to specify an interface. But you can specify a program.
I did look for some way to control Window’s handling of DHCP options. But it seems there isn’t anything obvious to limit this otherwise. I do not know if the windows firewall has this kind of fine-grained control with its own fire
For linux, I used to have my own blackout firewall rules. That only allowed the specific LAN range (for mobile use you could include all RFC1918 ranges) and the specific VPN IP out of the internet facing interface. Only the VPN interface could otherwise access the internet.
Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It’s really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It’s been a while since I’ve tested this stuff on Windows since obviously I haven’t been paid to do that for 6 years, but yeah I don’t even buy that all providers are affected and that it’s unfixable. We had workarounds for that when I joined PIA already so it’s probably been a known thing for at least a decade.
The issues we had is sometimes you could get the client to forget to remove the firewall rules or to add back the routes and it would break people’s internet entirely. Not great but a good problem to have in context.
To be fair, any proper VPN setup that only relies on the routing table like this is flawed to begin with.
If the VPN program dies or the network interface disappears, the routes are removed aswell, allowing traffic to leave the machine without the VPN.
So it is already a good practice to block traffic where it shouldnt go (or even better, only allowing it where it should).Many VPN-Programs by Providers already have settings to enable this to prevent “leaking”.
aswell
Not a word.
A swell
Removed by mod
Strong argument, anything else?
If i get this right, that attack only works before the tunnel is initiated (i.e. traffic encrypted), if the hosts is compromised, right? No danger from untrusted points inbetween, right?
No, it works at any point and the local network needs to be compromised (untrusted), the host can be secure.
So it is likely not an issue at your home unless you have weak Wi-Fi password. But on any public/untrusted Wi-Fi, it is an issue.
Yes, and also is fine if you’re using a cell hotspot.
Yikes
That being said, it apparently does not affect Mullvad apps on any platform other than iOS (Apple does not allow fixing it on iOS). I suspect other serious VPNs are also not vulnerable outside iOS, since it is prevented by simple leak prevention mechanism.
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.
Ok, so double encrypted and authenticated traffic (TLS inside the VPN) would still be safe, and some stuff requiring an internal network origin via the VPN is safe (because the attacker can’t break into the VPN connection and your client won’t get the right response), but a ton of other traffic is exposed (especially unencrypted internal traffic on corporate networks, especially if it’s also reachable without a VPN or if anything sends credentials in plaintext)
Meh, option 121 shenanigans can be detected and remediated via post connection scripting.
Step one, be in full control of DNS on the network. Not difficult, but not simple.
So…
reject 121;In your dhclient?
But why was this attacking novels? Are comic books safe?
(…) the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.
No. That is not the entire point of a VPN. That’s just what a few shady companies are claiming to scam uninformed users into paying for a useless service. The entire point of a VPN is to join a private network (i.e. a network that is not part of the Internet) over the public internet, such as connecting to your company network from home. Hence the name ‘virtual private network’.
There are very little, if any, benefits to using a VPN service to browse the public internet.
There are very little, if any, benefits to using a VPN service to browse the public internet.
This is why it’s often best to just avoid the comments completely
Well, for one, using one of those VPN providers has kept DMCA takedown notices away from me or the hosting provider of my seed box. So that is useful.
Come to think of it, why do they even call this use case a VPN? I’d call that a proxy.
If someone uses vpns for anything other than region locked content then that’s not very smart
Encrypted VPN tunnels are ubiquitous in many industries for remote connection to private clouds. They are used by virtually every high functioning company in the world, and getting more common for mid and lower tier companies as well.
There’s no real way to know if VPNs intended for the public are run the same as those intended for enterprise. Windows doesn’t have a lot of the same BS in their enterprise versions that are in the personal ones. Even with the same software, it could just be a checkbox that the salesperson can check for big businesses with legal teams that read and enforce contracts.
I am thinking more in the vein of piracy or hacking not some business stuffs
Maybe you can explain what you actually mean then, because I don’t understand your point.
I would say those dollar-store VPN products people use for geo-spoofing is the worst security risk when it comes to VPNs. You are sending your data through some other company that you have no control or insight into. You have no idea what network security they employ, or whether they are willing or obligated to release your data to other parties.
Are you saying it’s smarter to not use a VPN for piracy?
I assume this is definitely the case for free VPNs, if any of those still exist. There might be some willing to donate bandwidth and compute resources for the good of others, but I’m sure there’s more that pretend to do that but actually just sell the data or maybe just spy.
Tbh I wouldn’t be surprised if this is also the case for TOR nodes. I wonder how many entry and exit points are run by the NSA or some other government entity. Or are just monitored. If you can monitor the entry and exit points, you can determine both the source and destination, and just match them together using the middle node address.
Same thing with proxies.
Paid VPNs could go either way. On the one hand, they could make more money if they are willing to sell out their users’ privacy. On the other hand, that risks the entire thing falling apart if word gets out that it’s not private, since that’s the whole point of VPNs. I’m sure there’s some good ones out there but I’m also sure that there’s bad ones and wouldn’t be surprised if some of the ones considered good are actually bad.
Maybe ones that run in Europe would be safer bets. Their business is at least able to run there with the privacy laws. Maybe they are skirting them and haven’t been caught yet, maybe their data sales from other regions are profitable enough to support European operations without data sales, but if they are going for max greed and min risk, maybe they wouldn’t operate there. Or maybe they just run things differently in the different regions to maximize global profits.
This is the best summary I could come up with:
Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.
TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.
The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network.
A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel.
When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The original article contains 903 words, the summary contains 196 words. Saved 78%. I’m a bot and I’m open source!
As a networking engineer using a VPN service where you don’t have any information on the other end of the tunnel or worse install software which can essentially packet mirror your traffic to any location is the worst possible idea and I can’t believe they convinced so many people to do it.
