diff --git a/src/content/en/pages/privacy-guides/creating-a-vm-within-a-hidden-truecrypt-partition.md b/src/content/en/pages/privacy-guides/creating-a-vm-within-a-hidden-truecrypt-partition.md index 0ed1979aa..e2e94f45f 100644 --- a/src/content/en/pages/privacy-guides/creating-a-vm-within-a-hidden-truecrypt-partition.md +++ b/src/content/en/pages/privacy-guides/creating-a-vm-within-a-hidden-truecrypt-partition.md @@ -3,7 +3,7 @@ title: Creating a VM within a hidden veracrypt partition author: Ed Holden url: /privacy-guides/creating-a-vm-within-a-hidden-veracrypt-partition/ section: Misc -weight: 10 +weight: 20 date: 2013-10-23T13:54:43+00:00 layout: guides-details --- diff --git a/src/content/en/pages/privacy-guides/how-to-perform-a-vpn-leak-test.md b/src/content/en/pages/privacy-guides/how-to-perform-a-vpn-leak-test.md deleted file mode 100644 index 6bbaf540a..000000000 --- a/src/content/en/pages/privacy-guides/how-to-perform-a-vpn-leak-test.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: How to perform a VPN leak test -author: mirimir (gpg key 0x17C2E43E) -url: /privacy-guides/how-to-perform-a-vpn-leak-test/ -section: Misc -weight: 20 -date: 2021-12-14T00:00:00+00:00 -layout: guides-details ---- -OK, so you've setup your VPN client. It runs, and there are no error messages. You can reach the Internet. But how can you ensure that all of your traffic is routed through the VPN tunnel? And even if everything seems OK now, what will happen if the machine sleeps, and then resumes? What if there's an interruption in network connectivity? Or what if you're using Wi-Fi, and switch to a new access point and network? Or if you connect to a network that's fully IPv6 capable? This guide demonstrates how you can conduct a comprehensive VPN leak test. - -First, verify that your computer has configured a VPN tunnel. In Windows, open a command prompt, and run `ipconfig /all`. You'll see an ethernet adapter section with the Description "WireGuard Tunnel" or "TAP-Windows Adapter V9". The IPv4 Address will be something like `172.x.y.z` or `10.x.y.z`. In macOS and Linux, open a terminal, and run `ifconfig`. The VPN tunnel adapter is `utun0` in macOS, and `wg0` or `tun0` in Linux. - -## Risks from Browser Fingerprinting and IPv6 Leaks - -The only way to know whether all traffic is using the VPN tunnel is through testing. But there is some risk in testing for VPN leaks. Browsers can be fingerprinted in various ways. And so sites that you use in testing may see the same browser fingerprints from both your ISP-assigned IP address and your VPN exit IP address. Any adversary that learned your browser's fingerprints could later identify you, even if you were connecting through a VPN and/or Tor, as long as you were using the same browser. A [recent W3C draft guidance][1] states: "elimination of the capability of browser fingerprinting by a determined adversary through solely technical means that are widely deployed is implausible". - -WebGL fingerprinting and IPv6 leaks are far worse. WebGL uses the GPU via the OS graphics driver. On a given system, it appears that all browsers with WebGL enabled will have the same WebGL fingerprint. When using VPN services, I recommend blocking WebGL. In Firefox, for example, open "about:config" and toggle "webgl.disabled" to "true". In NoScript options, check "Forbid WebGL" in the "Embeddings" tab. - -It appears that systems using a given graphics driver can have the same WebGL fingerprint on hardware with a given GPU. So reinstalling a given OS, or even switching to another OS that uses the same graphics driver, won't change the WebGL fingerprint. This is clearly the case for VirtualBox VMs using the default virtual GPU. For example, browsers on Debian and Lubuntu VMs have the same WebGL fingerprint. But browsers on other OS (unrelated Linux distros, FreeBSD, Windows and macOS) have different WebGL fingerprints. However, the host and VMs use different GPUs (real vs virtual) so there is no overlap in WebGL fingerprints. - -It's not uncommon for VPN clients to [leak IPv6 traffic][2]. That's serious, because IPv6 addresses are typically device-specific. And so it's prudent to disable IPv6 in both your OS and your LAN router. It's also prudent to use VPN clients that block IPv6 traffic, or block IPv6 in your firewall. And whenever you first connect through a new LAN or Wi-Fi network, [check IPv6 connectivity][3]. - -By the way, WebGL fingerprinting is a crucial issue when compartmentalizing across multiple VMs. It's true that you can easily block WebGL fingerprinting in browsers. But it's also prudent to compartmentalize across VMs with different WebGL fingerprints. Whonix instances are another good option, because Tor browser has been hardened to fully block WebGL fingerprinting. - -## VPN Leak Test - -While doing your VPN leak test, you can use tcpdump to check for traffic that's not using the VPN tunnel. In Windows, you'll need [Wireshark][22] and [wintee][4]. Just put a copy in your user folder. Now list network interface numbers: - -Windows: - - tshark -D - -macOS: - - sudo tcpdump -D - -Linux: - - sudo tcpdump -D - -You want the physical network interface. It's typically "1". So to start capturing: - -Windows: - - tshark -i 1 -n -T text -w "C:\tshark-capture.log" -f "not host a.b.c.d" 2>&1 | wtee tcpdump.log - -macOS: - - sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log - -Linux: - - sudo tcpdump -n -i 1 not host a.b.c.d 2>&1 | tee tcpdump.log - -Host a.b.c.d is the VPN server that you're using. Keep the command/terminal window open while you do the following tests, and look for packets with addresses outside your local LAN and/or Wi-Fi networks. - -Start by checking your IP address. It's safest to use your VPN provider's website. If they don't report IP address, the next safest bet is arguably [check.torproject.org][5]. If you intend to test for VPN leaks using other sites, I recommend using Tor browser, because it's been hardened to block WebGL fingerprinting, and to otherwise report the same fingerprints for all users. But for now, it's OK to use your default browser. Anyway, you should see your VPN exit IP address. - -You also want an ongoing source of network traffic. In a second command/terminal window: - -Windows: - - ping -t a.b.c.d 2>&1 | wtee ping.log - -macOS: - - ping -n a.b.c.d 2>&1 | tee ping.log - -Linux: - - ping -n a.b.c.d 2>&1 | tee ping.log - -If you want pinging with timestamps in Windows or macOS, hacks (more or less ugly) are required: - -[Windows:][6] - - ping -t a.b.c.d | cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!time! !data!)&ping -n 2 localhost>nul" 2>&1 | wtee ping.log - -[macOS:][7] - - ping -n a.b.c.d | while read pong; do echo "$(date): $pong"; done 2>&1 | tee ping.log - -Linux: - - ping -D -n a.b.c.d 2>&1 | tee ping.log - -Custom clients of some VPN providers block pings to their servers through their VPN tunnels. If you see no output, hit Ctrl-C and try pinging a.b.c.1 instead. If that also doesn't work, try 38.229.82.25 (torproject.org). In the traffic capture window, you should see no packets with addresses outside your local LAN and/or Wi-Fi networks (i.e., no non-local traffic captures). - -Now disconnect the machine from the network. That will prevent pings from completing. In Windows, you will see "Request timed out." In macOS and Linux, ping output will just stop. Then reconnect the machine to the network. If all goes well, ping replies should start appearing again. Refresh the IP-check site in your browser. You should still see your VPN exit address. In the traffic capture window, you should still see no non-local captures. In Windows, you may see lots of local traffic. To check more thoroughly, you can view tcpdump.log in a test editor. - -## Failure Modes and Options - -Failure shows up in a few main ways. Most blatantly, the openvpn process (not just the VPN connection) may die after loss of network connectivity. So after network connectivity is restored, the IP-check site will report your ISP-assigned IP address. And you will see numerous non-local traffic captures. Network Manager in Linux is prone to this failure mode, by the way, and should be avoided. - -Less blatantly, but more insidiously, the VPN client may reconnect after network connectivity is restored, and the IP-check site will still report your VPN exit IP address. You might not notice any interruption. But you will see non-local traffic captures, generated by pings that succeeded before the VPN tunnel came back up. Just one leaked packet is enough to reveal your ISP-assigned IP address. - -Plain vanilla OpenVPN tends to fail in a way that's somewhat easier to manage, but still dangerous. If a network interruption lasts long enough to kill the VPN connection, OpenVPN can't reestablish the connection. As long as OpenVPN is running, all traffic is routed through the VPN gateway, which is dead. And so there's no network connectivity. Pings will fail, and you will see no traffic captures. Default routing isn't restored until the openvpn process is killed. So one could close apps accessing sensitive network resources, kill the openvpn process, and then reconnect the VPN. Or one could just reboot. But those are tedious hacks, and prone to error. - -You can use the same approach to see how your VPN client responds to other perturbations. Sleep and resume. Change Wi-Fi access points. Use a network with full IPv6 connectivity. Whatever. Inspection of tcpdump.log and ping.log should reveal any leaks. - -If you find that your VPN client leaks, one option is to try another VPN provider, and test their client. However, blocking leaks in Linux is easy with [adrelanos' vpn-firewall][8]. I recommend using it with the built-in openvpn service, not Network Manager. Basically, it allows all apps to use the VPN tunnel, and blocks everything on the physical interface except for connections to the VPN server. You can use the same firewall logic in Windows and macOS. In Windows, you can just use Windows Firewall. In macOS, you can use [IceFloor][9], which is a GUI front end for OpenBSD's PF firewall. - -## Other Kinds of Leaks - -Even if all traffic is being routed through your VPN, it's possible that [DNS requests][10] are going to a DNS server that's operated by, or associated with, your ISP. Even though your requests are coming from the VPN exit, an adversary observing both the DNS server and your ISP traffic could correlate activity. If the VPN server uses the same IP address for access and exit, correlation becomes trivial. Now the adversary knows what sites you are accessing. - -The HTML5 Geolocation API enables a potentially serious leak. It caches and reports available location data. Perhaps you've provided your location, in order to get local weather information. If you use Wi-Fi, your location can be triangulated from accessible access points. If you're using a smartphone, the ID of the base station locates you approximately. And maybe you have GPS turned on. But there's no problem as long as only IP address information is available. The simplest option is to disable geolocation, as explained the [IVPN knowledge base][11]. - -WebRTC is another indiscreet HTML5 feature. If enabled in the browser, it reports local IP address. And if IPv6 is functional, it reports local IPv6 address, which is typically device-specific. So it's prudent to prevent WebRTC leaks by installing the "WebRTC Control" browser addon. Also, as noted above, it's prudent to disable IPv6 in the OS, and to block all IPv6 traffic in the firewall. - -Sites that you visit can also estimate the number of intervening routers by inspecting received SYN packets. The default initial time to live (TTL) for SYN packets varies by OS. The browser User-Agent string identifies the OS. And the TTL value is decreased each time the packet passes through a router. The difference between expected and observed TTL provides an estimate for the number of intervening routers. - -If you intend to test for leaks using other third-party sites, I recommend using Tor browser, because it's been hardened to block WebGL fingerprinting, and otherwise to report the same fingerprints for all users. But you obviously don't want to use Tor while testing your VPN. First, download [Tor browser][12] for your OS. Do that with your VPN connected, so your ISP doesn't see. After extracting, start Tor browser. You can probably accept all defaults. Go to advanced network settings, and select "No proxy". Browse about:config, and toggle both "extensions.torlauncher.start_tor" and "network.proxy.socks_remote_dns" to "false". Then browse [check.torproject.org][13]. You should see "Sorry. You are not using Tor." and your VPN exit IP address. - -It's true that you can't investigate WebGL and other fingerprinting using Tor browser. If you choose to test using other browsers, you should be very careful. As noted above, all WebGL-capable browsers on a given system will have the same WebGL fingerprint. So you should avoid using the same system with and without a VPN connected. You should also avoid using different VPN services, unless you don't care that the system will be associated with both. Furthermore, if you use VMs, you should not use related operating systems with and without a VPN, or with different VPN services. - -## Summary - -Bottom line, here are the key tests, and the results that you should get: - -* [IPv6 address test][14]: No IPv6 address detected -* [IP address test][15]: expected IP addresses with and without VPN connected -* [Geolocation test][16]: browser doesn't support geolocation API -* [Java test][17]: not found, or disabled -* [WebGL test][18]: WebGL blocked by NoScript -* [WebRTC test][19]: not enabled -* [Panopticlick][20]: browser protects from fingerprinting -* [DNS Leak Test (use extended test)][21]: different DNS server(s) with and without VPN connected - - [1]: https://w3c.github.io/fingerprinting-guidance/ - [2]: https://haddadi.github.io/papers/PETS2015VPN.pdf - [3]: https://test-ipv6.com/ - [4]: https://code.google.com/archive/p/wintee/ - [5]: https://check.torproject.org/ - [6]: https://stackoverflow.com/questions/24906268/ping-with-timestamp - [7]: https://stackoverflow.com/questions/10679807/how-to-timestamp-every-ping-result - [8]: https://github.com/adrelanos/VPN-Firewall - [9]: https://www.hanynet.com/icefloor/ - [10]: https://en.wikipedia.org/wiki/Domain_Name_System - [11]: https://www.ivpn.net/knowledgebase/troubleshooting/my-real-location-is-detected-when-connected-to-vpn-how-to-disable-geolocation/ - [12]: https://www.torproject.org/download/download - [13]: https://check.torproject.org/ - [14]: https://test-ipv6.com/ - [15]: https://www.browserleaks.com/whois - [16]: https://www.browserleaks.com/geo - [17]: https://www.browserleaks.com/java - [18]: https://www.browserleaks.com/webgl - [19]: https://www.browserleaks.com/webrtc - [20]: https://panopticlick.eff.org/ - [21]: https://dnsleaktest.com/ - [22]: https://www.wireshark.org/ diff --git a/src/content/en/pages/privacy-guides/mac-address.md b/src/content/en/pages/privacy-guides/mac-address.md index 7f1c5da64..c91f3f9dd 100755 --- a/src/content/en/pages/privacy-guides/mac-address.md +++ b/src/content/en/pages/privacy-guides/mac-address.md @@ -3,7 +3,7 @@ title: Privacy issues related to MAC addresses author: Solène Rapenne url: /privacy-guides/mac-address-privacy/ section: Misc -weight: 10 +weight: 15 date: 2024-03-08T00:00:15+00:00 layout: guides-details articles: [ diff --git a/src/content/en/pages/privacy-guides/self-audit-part1.md b/src/content/en/pages/privacy-guides/self-audit-part1.md new file mode 100644 index 000000000..9ae310a4c --- /dev/null +++ b/src/content/en/pages/privacy-guides/self-audit-part1.md @@ -0,0 +1,183 @@ +--- +title: Self audit your VPN - Pt1. - Getting started +author: Solène Rapenne +url: /privacy-guides/self-audit-series-part1/ +section: Misc +weight: 10 +date: 2024-06-19T15:00:00+00:00 +aliases: ['/privacy-guides/how-to-perform-a-vpn-leak-test/'] +layout: guides-details +articles: [ + { + title: "Self audit your VPN - Pt2. - WireGuard Configuration and Leaks", + url: "/privacy-guides/self-audit-series-part2/" + }, +] +--- +While it is important to protect your privacy, it is also essential to trust your VPN provider with the proper implementation of its VPN service. While third-party audits by organisations can provide some assurance, it is possible to audit the VPN functionality independently. This series will teach you how to verify that your VPN is functioning as claimed by your VPN provider, as well as how to verify that it is performing at its optimal level with the best settings. + +Verifying the functionality of your VPN is crucial for maintaining your privacy. While some VPN providers publish their apps in open source, not everyone has the time or expertise to thoroughly review them. The most straightforward way to validate your VPN is to analyze network traffic from various angles and ensure it's connected to the intended server, on the correct port, and using the appropriate protocol. Additionally, it's essential to identify any potential data leak. After this series, you will have the knowledge and confidence to assess the quality of your VPN. + +Network traffic analysis technique is an effective method for conducting a self-audit of your VPN. By reviewing the network activity, you can ensure that what you audit is actually occurring on the network. + +Furthermore, this will enable you to investigate privacy issues such as DNS leak or performance VPN issues due to fragmented network packets. + +In this initial section, you will gain an understanding of the tools you will utilize throughout the series, as well as some methodologies that will be pertinent in certain audit scenarios. + +## Self audit method + +For this series, you will use the software [Wireshark](https://www.wireshark.org/) which is the industry standard for capturing and analyzing network packets. + +Wireshark is compatible with the majority of operating systems including Windows, macOS, Linux and *BSD. It has the capability to identify known protocols, limit displayed packets with advanced filters, display TCP by sessions, render packets content and much more. + +Although it is not available on mobile devices, we will provide a method for analyzing network traffic on mobile devices. Wireshark is a graphical application that is not intended for use on remote headless systems. The guides will also cover how to achieve traffic analysis of remote systems. + +## Wireshark usage + +This section will teach you the basics of Wireshark, so you can use it for the series. If you want to learn more about Wireshark features, you are encouraged to look at [its documentation](https://www.wireshark.org/docs/). + +### Quick setup +#### Windows + +In order to install Wireshark on Windows, visit the [Downloads](https://www.wireshark.org/download.html) page and download the file that suits best your system, if you do not know which one you need, download the file "Windows x64 Installer". + +Run the installer and follow the instructions. Windows requires an extra specific installation step to install a component named "Npcap", this is required on Windows to capture packets, it is safe to install. + +#### macOS + +In order to install Wireshark on macOS, visit the [Downloads](https://www.wireshark.org/download.html) page and download the file matching your CPU architecture, if your device CPU name looks like M1, M2, etc., you need the file "arm disk image". If your device is a previous model, download the file "Intel disk image". + +#### Linux + +On [most Linux distributions](https://repology.org/project/wireshark/versions), Wireshark is available in the package manager. Refer to your distribution documentation to learn how to install the Wireshark package. + +Depending on your distribution, you will either need to run Wireshark using sudo, or add your user to a group named `wireguard` before restart your desktop session. + +### How to start capturing packets + +When running Wireshark, below the text "Capture... using this filter" and a text input field, you will find all your network interfaces, if you double-click on an interface, the packet capture will start. + +![Wireshark interface at start time](/img/wireshark_main.png) + +### Filters + +There are two kinds of filters in Wireshark: capture filters and display filters, they use a different syntax. + +When you know exactly what you want to capture, it is better to use a capture filter to make the capture dataset smaller. But when you want to explore the network traffic like you will do in this series, you will need all data in the capture but only dynamically filter the display. + +Wireshark offers auto-completion while typing a filter which makes life easier when searching for a filter. The documentation contains [common examples](https://wiki.wireshark.org/DisplayFilters) of display filters. Do not worry if you do not understand the filters syntax or what they mean. The guides will provide filters and explanations about what they do. + +## Network capture of remote devices + +In some cases, you may not be able to run Wireshark on the device you want to audit. + +The most common cases are IoT devices, smartphones and headless machines (routers, servers). Methods to capture traffic on these devices while keeping the analysis procedure identical to the case where Wireshark is running locally are explained below. + +### Wi-Fi devices / Smartphones network traffic capture + +If you need to capture the network traffic of a smartphone or any IoT devices using Wi-Fi, there is a simple method which is compatible with most devices: set up a Wi-Fi hotspot network on a computer running Wireshark. The computer must have at least two network interfaces for this setup to work: one connected to the Internet and the other to allow connection from devices you want to monitor. + +Once the hotspot is created, start capturing the network traffic of the Wi-Fi network interface in Wireshark. Then, connect the device you want to monitor to the new Wi-Fi access point. + +This will allow you to check all the traffic going from / to the connected Wi-Fi devices without needing any special privileges or jailbreak to run the software like [tcpdump](https://www.tcpdump.org/) which only work on rooted Android devices. + +Check your operating system documentation to learn how to create a Wi-Fi hotspot sharing Internet: + +* [Windows documentation](https://support.microsoft.com/en-us/windows/use-your-windows-pc-as-a-mobile-hotspot-c89b0fad-72d5-41e8-f7ea-406ad9036b85) +* [macOS documentation](https://support.apple.com/guide/mac-help/share-internet-connection-mac-network-users-mchlp1540/mac) +* Linux: the network manager applet should provide a feature to create a Wi-Fi hotspot, or you can do it using the [command line interface](https://wiki.archlinux.org/title/Software_access_point). + +You can use an Ethernet connection instead of a wireless hotspot if your devices support Ethernet. + +### Capturing network traffic on headless machines + +In order to analyze the network traffic passing through a headless server/router, you will need to use the software [tcpdump](https://www.tcpdump.org/) on the remote system. + +As tcpdump works in a terminal and its output is hard to read, you will only use it for [capturing network data into a file](https://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html) on the remote machine, then retrieve the file to open it using Wireshark for a local analysis offline. + +The program usage is simple: as the privileged user (root on Linux and *BSD), run the command `tcpdump -i -s 65535 -w ` where: + +* `` is the name of the network interface from which you want to capture the data. +* `` is the output filename containing the data. + +Wait at least two minutes to have a good sample of network traffic, then press `Ctrl + C` to stop the capture. + +It is important to understand that `` will contain all the data that went through `` during the capture. If you run the capture for a long time or that the network interface had a high bandwidth usage during the capture, the destination file size can be large. + +Once you are done with the network capture, do not forget to retrieve the file on the computer where Wireshark will be used. + +To open the capture file, start Wireshark and click on "File" and then on "Open", select the file and click on the Open button. + +## Force Wireshark to decode packets using a given protocol + +In order to identify the protocol used by network packets independently of its transport protocol port, it is required to configure Wireshark to force using a given protocol to decode the packets. + +This can be achieved using the following instructions: + +- right-click on a packet +- click on "Decode as" +- a popup window with a single line should be displayed +- click on the last cell under the column "Current" +- choose the protocol required, you can type on the keyboard to jump to a letter in the protocol list +- click on "OK" +- the protocol in the display should have changed to the one you selected + +This change will be discarded when exiting Wireshark. + +## Identify the VPN server IP + +In the series, some scenarios will require you to know the IP of the server you are connected to. This section explains different methods to find this IP depending on your setup. + +### VPN configured without a provider App + +If you do not use your VPN provider App, you can find the IP address of the server in the VPN configuration, it should be named like "Endpoint address". Only retain the IP address in case the field contains the VPN port. + +### Using the IVPN App + +By default, the IVPN App does not display the servers IP or hostnames. A parameter must be enabled in the IVPN App settings to allow choosing a specific server instead of automatically choosing a random server when clicking on a country. + +![Enable server list](/img/server_list_enable.png) + +After you enabled this setting, in the server list you will be able to choose a specific server in the hostname list under country names. You need to write down the chosen hostname as you will need it for the next step. + +![Find server](/img/server_list.png) + +Now, you can either resolve the hostname to get the server IP address, or you can search the hostname in [IVPN API server list](https://api.ivpn.net/v5/servers.json) and get the value of `host` related to the hostname. + +If you prefer to resolve the hostname from the command line, on Microsoft Windows, Apple macOS and Linux systems, the command line program `nslookup` can be used to resolve a hostname into an IP address. Here is an example of `nslookup` use: + +``` +user@linux ~ $ nslookup gr1.wg.ivpn.net +Server: 9.9.9.9 +Address: 9.9.9.9#53 + +Non-authoritative answer: +Name: gr1.wg.ivpn.net +Address: 169.150.252.113 +``` + +If you do not know how to use a command line program, you can use [this website](https://iamroot.tech/dns-lookup/): type the hostname and select the query type "A" to obtain the IPv4 address. + +## Identify the VPN server protocol and port + +In the series, some scenarios will require you to know the protocol and the port used to connect to the remote VPN. This section explains different methods to find this information depending on your setup. + +### VPN configured without a provider App + +If you do not use your VPN provider App, you can find the protocol and port used to establish the VPN in its configuration. + +With WireGuard, it is always using the UDP protocol, the port can be found in the "Endpoint address" field of the configuration, after the server IP. + +With OpenVPN, the protocol can be either TCP or UDP. Depending on the client used, you will find the port in a field which could be named "**Gateway**" or "**Remote**", at the right of the server address. The protocol may be indicated on the same line, or on a dedicated line named "**proto**". + +### Using the IVPN App + +The protocol and port used to connect to the VPN server are shown on the App main interface. You can find this information in the bottom left corner. + +![IVPN App screenshot with the protocol and port text highlighted](/img/ivpn-app-protocol-and-port.png) + +In the example above, the protocol is UDP and the port number is 4500. + +# Next step + +If you have read the guide until here, you are ready to [continue to the next part](/privacy-guides/self-audit-series-part2) of the series. diff --git a/src/content/en/pages/privacy-guides/self-audit-part2.md b/src/content/en/pages/privacy-guides/self-audit-part2.md new file mode 100644 index 000000000..a566ba9e7 --- /dev/null +++ b/src/content/en/pages/privacy-guides/self-audit-part2.md @@ -0,0 +1,158 @@ +--- +title: Self audit your VPN - Pt2. - WireGuard Configuration and Leaks +author: Solène Rapenne +url: /privacy-guides/self-audit-series-part2/ +section: Misc +weight: 11 +date: 2024-06-19T15:00:00+00:00 +layout: guides-details +articles: [ + { + title: "Self audit your VPN - Pt1. - Getting started for the series", + url: "/privacy-guides/self-audit-series-part1/" + }, +] +--- +This guide is [part of a series](/privacy-guides/self-audit-series-part1/) that will show you how to self-audit a VPN tunnel for data leak and performance issues. + +## How to verify if the network traffic is going through your WireGuard VPN tunnel + +This section explains how to identify network traffic that does not pass through the VPN tunnel when it should, such case implies a VPN leak and a potential risk for your privacy. At the same time, you will be able to verify the VPN is established with the server of your choice. + +The first step is to identify the IP address of the chosen server, protocol and port used by your VPN, you can refer [to the first part](/privacy-guides/self-audit-series-part1/) of the series to learn how to find this information. + +Using Wireshark, start capturing the network traffic on the physical interface connected to the Internet. Be careful to not capture the network traffic on the VPN interface otherwise the results will not be useful. + +Use the following text into Wireshark display filter input, adapt the variables (written in capital letters): `(ip or ipv6) and not (ip.addr == SERVER_IP and udp.port == SERVER_PORT) and not (icmpv6 or llmnr or dhcp or mdns) and not (ip.host matches ".255$" or ip.addr == 224.0.0.0/4)`. If your VPN is using V2Ray obfuscation using VMESS/TCP, you will need to replace `udp.port` by `tcp.port`. + +Here is the filter explained: + +* `(ip or ipv6)`: match Internet Protocol (IPv4 and IPv6) packets. This discards other protocols such as [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol) or [Ethernet](https://en.wikipedia.org/wiki/Ethernet) that are not relevant for the current scenario. +* `not (ip.addr == SERVER_IP and udp.port == SERVER_PORT)`: + * `not`: match the opposite of the condition following it. + * `ip.addr == SERVER_IP`: matches all packets exchanged with the server with the address SERVER_IP. + * `udp.port == SERVER_PORT`: matches all packets exchanged on the UDP port SERVER_PORT. + * The combination of the two will remove all UDP traffic from your VPN server on the VPN port, it hides all the VPN traffic from the display. +* `not (icmpv6 or llmnr or dhcp or mdns)`: + * `not`: match the opposite of the condition following it. + * `(icmpv6 or llmnr or dhcp or mdns)`: contains a list of protocols. + * The combination of the two removes the packets matching any protocol in the list. These protocols are not meant to be routed to the Internet and will not be carried over the VPN, so we do not need them to appear as false positive. +* `not (ip.host matches ".255$" or ip.addr == 224.0.0.0/4)`: + * `not`: match the opposite of the condition following it. + * `ip.host matches ".255$"`: matches all IP addresses ending with `255`, those are [multicast addresses](https://en.wikipedia.org/wiki/Multicast_address). + * `ip.addr == 224.0.0.0/4`: matches [IPv4 broadcast](https://en.wikipedia.org/wiki/Broadcast_address#IP_networking) traffic. + * The combination of the two removes all broadcast and multicast packets, they are not useful because they are not meant to be tunneled through a VPN, so we do not need them to appear as false positive. + +This display filter restricts the display content to IP traffic that is not from your VPN, it excludes a certain number of packets that are not routable. + +Ideally, with this filter, you should not have lines in the Wireshark packet list (main display). If a line appears in the list, ask yourself the following questions: + +* Is the VPN disconnected and my firewall not blocking non-VPN traffic? +* Is this a local network traffic? If both the source and destination IP belong to your LAN, it is LAN traffic and does not belong to a VPN tunnel. +* Does it occur regularly? If so, close all the programs on your computer and check if you see it again. If not, start the programs one by one until you see the pattern again, one of them may be bound to a configured network interface and bypass the VPN routing rules. +* What protocol is it? Is it expected? At this point, you will need to understand exactly what happens on your system. +* Are there multiple connected VPNs on my system? You may be auditing the one that is encapsulated in another VPN. +* Is SERVER_IP and SERVER_PORT correct? + +Note, after switching to a different VPN server, you may see incoming packets from a previous server up to 3 minutes after disconnection. This is due to how WireGuard is designed ([WireGuard paper: 6.3](https://www.wireguard.com/papers/wireguard.pdf)). + +In the following Wireshark screenshot, you can identify a single DNS request that was not done through the WireGuard tunnel. This was done intentionally to illustrate the case of a packet not matching the filters. + +The first line corresponds to my computer LAN IP `10.137.0.30` querying `9.9.9.9` DNS server about the domain `eff.org`. On the second line, the server `9.9.9.9` is replying to my computer with the query answer. + +![Wireshark screenshot](/img/capture_wg_restricted.png) + +## How to verify your system firewall effectiveness + +In this scenario, you will learn how to ensure the system firewall is working effectively and blocking all traffic when the VPN is not connected. In order to check the firewall, you will monitor the network transmitted from your computer to the Internet. If the firewall is working correctly, there should not any [data egress](https://aviatrix.com/learn-center/cloud-security/egress-and-ingress/). + +For this scenario, you need to find the IP of your computer on the local network, most of the time it looks like `192.168.y.x`. + +If you do not know how to find your computer local network IP, here are guides explaining how to do so: + +* [On Microsoft Windows](https://support.microsoft.com/en-us/windows/find-your-ip-address-in-windows-f21a9bbc-c582-55cd-35e0-73431160a1b9) +* [On Apple macOS](https://www.wikihow.com/Find-Your-IP-Address-on-a-Mac) +* [On Linux](https://www.addictivetips.com/ubuntu-linux-tips/find-ip-address-on-linux/) + +**Disconnect the VPN** and make sure your firewall is enabled before continuing. + +In Wireshark, start the capture on the non-VPN network interface and use the following display filter: `ip and ip.src == YOUR_LAN_IP`. This filter will limit the display to IP packets whose source address is your computer IP. + +If you use IPv6, you need a different filter which must include all your IPv6 addresses in addition to your IPv4 address: `(ip or ipv6) and (ip.src == YOUR_LAN_IPV4 or ipv6.src == YOUR_LAN_IPV6 or ipv6.src == YOUR_PUBLIC_IPV6) and not icmpv6`. This filter will limit the display to IPv4 and IPv6 packets whose source is one of your IPs, and hide the ICMPv6 protocol generating a lot of local traffic. + +While the capture is running, run programs needing a network connection like a web browser, email client or instant messaging software. They should not work and there should be no displayed lines in Wireshark either. + +Now, if you establish the VPN connection, you should not see any change in the Wireshark display. + +If you have lines displayed, this could mean that: + +* the source IP may be allowed by the firewall +* your system firewall is misconfigured +* your VPN app software (if any) configuring the firewall is misconfigured + +If you use the App of your VPN provider, you may see traffic related to the provider API, the App may have a setting to block this traffic. For instance, IVPN users may see network packets addressed to `198.50.177.220` or `2607:5300:203:1735::8` which are the addresses of the server `api.ivpn.net` (as of June 2024). By default, the IVPN App allows traffic to IVPN servers, but this behavior can be disabled in the App firewall settings. + +## How to verify V2Ray obfuscation is enabled + +In this scenario, you will learn how to verify that WireGuard obfuscation [V2Ray](https://www.v2ray.com/en/) is working effectively. Obfuscation algorithms can disguise WireGuard packets as [QUIC](https://en.wikipedia.org/wiki/QUIC) or HTTP traffic, making it much harder to identify as VPN traffic, even using [deep packet inspection](https://en.wikipedia.org/wiki/Deep_content_inspection). + +Both methods have a performance penalty and should only be used when you are not able to connect using a genuine WireGuard tunnel. + +The first step is to identify the IP address of the chosen server, you can refer to [the first part of the series](/privacy-guides/self-audit-series-part1/#identify-the-vpn-server-ip) to learn how to proceed. IVPN users will need to use the server list from the API to find the IP address on which the server is offering V2Ray. + +### V2Ray obfuscation (VMESS/QUIC) + +Start the network traffic capture with Wireshark before enabling the VPN, then use the following filter: `ip.addr == SERVER_IP and udp.port == SERVER_PORT`, replace SERVER_IP and SERVER_PORT by your VPN server connection information. + +This filter restricts the capture display to the packets exchanged with the VPN server. From there, you need to configure Wireshark to force decode packets using the QUIC protocol and see if it succeeds. Upon successful QUIC protocol decoding, it would mean obfuscation works, if it only reports "Protected payload" then it is WireGuard traffic. + +You can find how to configure Wireshark to tag the packets as QUIC in the [first part of the series](/privacy-guides/self-audit-series-part1/#force-wireshark-to-decode-packets-using-a-given-protocol). + +On Wireshark main display with the packets list, if the column "Info" displays "Protected Payload" for all packets, this indicates the packets are using WireGuard, but if you see most packets have the text "Retry" it means you are looking at QUIC packets and obfuscation is working. + +Further verification can be done by looking at the protocol details on a packet, either at the bottom of the display or in a popup window by double-clicking on a packet. + +A QUIC packet should look like the following picture, within "QUIC Connection information" there are some source and destination information. + +![](/img/self-audit-quic-is-quic.png) + +If the packet is a WireGuard packet, there will be no QUIC information. + +![](/img/self-audit-wg-is-quic.png) + +### V2Ray obfuscation (VMESS/TCP) + +Start the network traffic capture with Wireshark before enabling the VPN, then use the following filter: `ip.addr == SERVER_IP and tcp.port == SERVER_PORT`, replace SERVER_IP and SERVER_PORT by your VPN server connection information. + +This filter restricts the capture display to the packets exchanged with the VPN server. + +Now, right-click on a result line, choose **Follow** → **TCP Stream**, this will open a popup window showing the content of all the packets of this TCP session. As this is a plain text HTTP connection, you should see readable text at the top of the data. It should look roughly like the below example (exact format will depend on the obfuscation implementation): + +``` +GET / HTTP/1.1 +Accept-Encoding: gzip, deflate +Connection: keep-alive +Host: www.inet-telecom.com +Pragma: no-cache +User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 +``` + +The data below this is binary data containing the real WireGuard traffic. + +The fact that you exchange HTTP data with the VPN server on the VPN port shows that the obfuscation is working effectively. + +## How to verify the WireGuard tunnel is using a post-quantum resistant encryption? + +In this scenario, you will learn how to verify that your WireGuard VPN is using a [post-quantum resistant encryption](https://www.ivpn.net/knowledgebase/general/quantum-resistant-vpn-connections/). You will not need Wireshark as it is not possible to inspect the encrypted traffic to figure how resistant it is, instead, you will need to install the [WireGuard tools](https://www.wireguard.com/install/). This program is compatible with all major operating systems. + +In WireGuard, post-quantum resistance is achieved by using a [pre-shared key](https://en.wikipedia.org/wiki/Pre-shared_key) (PSK) between the VPN client and VPN provider servers. + +Once the installation is done, run the command `wg` with administrator privileges. This command will display the state of each active WireGuard connections. If you identify the pattern `preshared key: (hidden)` in the command output, it means there is a defined PSK. If there is no `preshared key` line, then the tunnel is not post-quantum resistant. + +You can get access to the PSK with the command `wg showconf INTERFACE_NAME`, where `INTERFACE_NAME` is one of the interfaces reported in the previous command `wg`. If you can identify a line starting by `PresharedKey`, it means the PSK is configured and quantum resistant encryption enabled. + +## Decrypt the tunnel traffic with Wireshark + +If you want to verify the network traffic passing through the WireGuard VPN tunnel, you do not need to decrypt the tunnel as you can use Wireshark directly on the VPN network interface. + +However, based on [Wireshark documentation](https://wiki.wireshark.org/WireGuard#live-capture-with-decryption-support), it should be possible to use the software to decrypt the WireGuard tunnel network traffic in real time with a specific setup. This requires [access to the cryptographic keys](https://git.zx2c4.com/wireguard-tools/tree/contrib/extract-handshakes) used by the VPN client. diff --git a/src/static/img/capture_wg_restricted.png b/src/static/img/capture_wg_restricted.png new file mode 100644 index 000000000..036621bd5 Binary files /dev/null and b/src/static/img/capture_wg_restricted.png differ diff --git a/src/static/img/ivpn-app-protocol-and-port.png b/src/static/img/ivpn-app-protocol-and-port.png new file mode 100644 index 000000000..67be92fc5 Binary files /dev/null and b/src/static/img/ivpn-app-protocol-and-port.png differ diff --git a/src/static/img/self-audit-quic-is-quic.png b/src/static/img/self-audit-quic-is-quic.png new file mode 100644 index 000000000..7f89eca65 Binary files /dev/null and b/src/static/img/self-audit-quic-is-quic.png differ diff --git a/src/static/img/self-audit-wg-is-quic.png b/src/static/img/self-audit-wg-is-quic.png new file mode 100644 index 000000000..ad7fcd7e7 Binary files /dev/null and b/src/static/img/self-audit-wg-is-quic.png differ diff --git a/src/static/img/server_list.png b/src/static/img/server_list.png new file mode 100644 index 000000000..4755efb7d Binary files /dev/null and b/src/static/img/server_list.png differ diff --git a/src/static/img/server_list_enable.png b/src/static/img/server_list_enable.png new file mode 100644 index 000000000..cbe4bad89 Binary files /dev/null and b/src/static/img/server_list_enable.png differ diff --git a/src/static/img/wireshark_main.png b/src/static/img/wireshark_main.png new file mode 100644 index 000000000..6aa263ac8 Binary files /dev/null and b/src/static/img/wireshark_main.png differ