The nomad's map of networking on Linux

Introduction

There are a lot of solutions for this problem and I can't cover all of them. I'll go over the popular solutions and show you the one I'm currently using, hence the "map" in the title. If you know of a better solution I've missed that adheres to the criterion bellow, please send me an email.

Use case

  1. Connecting to an open wifi network
  2. Disconnecting and possibly connecting to other networks elsewhere

Attack surface

  1. Leaking of identifying information to the local network

    This is the most obvious way in which you can be uncloaked. It includes:

    1. Information used by DHCP

      ClientID, previous IP addresses obtained from the network, etc.

    2. MAC address

  2. Leaking of local information to a remote server

    If a remote server can identify you and knows where you are connecting from, you are uncloaked. The usual information that leaks to remote server is:

    1. IP address of the local network
    2. MAC address of your machine (from IPv6)

  3. Time correlation

  4. Usage patterns

    If you have a mail/home server, for example, and fetch your email from it every time you connect to the network, it will be arbitrary to identify you. Because 1.) it is consistent and 2.) the IP of your mail server leads directly to you. But if you consistently connect to the same servers, it only takes one link from one of the connections to trace them all back to you! The same is true of DHCP and MAC leaks but most people have those linked to themselves in the first place (unless you buy computer with cash or XMR but even then they are probably still linked and you should assume that).

Analysis

MAC addresses

Most people focus on randomizing MAC addresses when they want to use wifi anonymously and with good reason. The MAC address is the first and most obvious place to look at if you want to identify someone and a lot of captive portals rely on it for billing or surveillance.

There are usually two approaches to randomizing MAC addresses - per network or per connection. I personally see no advantage of randomizing your MAC per network, at least for this use case. At its worse, randomizing per connection is as good as per network so I don't really see the point. Having to keep track of what MAC to use for what network also adds more complexity to the software.

Ok, now that we know what method to use, how exactly are we going to randomize it? There are a few options but I decided to go with macchanger. It has a built-in database for the manufacturers and it can change a MAC address to the same type of interface.

Unfortunately, when changing to something other than a completely random address, the locally-administered bit is set. This indicates that the address was changed. Since we are limiting all transmitted information, there are other ways to figure out we are not a regular device but it still sucks that it's explicitly broadcasted. This is not a huge issue since many phones set that bit by default when connecting to open networks so it doesn't stand out that much.

A survey of the local traffic is the only way to verify if setting the bit or not is better but we will take the built-in default for now.

DHCP

DHCP has the same consideration as MAC addresses regarding the per network or per connection randomization but luckily the smart people that created the anonymity profile found a way to mirror the decision taken in MAC address randomization. So long as you use the anonymity profile, you don't have to worry about that.

Talking to the DHCP server can be done in a few ways:

Whatever you end up choosing, it's vital that you find and enable the option to use the anonymity profile specified by RFC 7844! If you can't find or enable it, use something else. I don't trust internal implementations and find network managers that have them bloated. The popular NetworkManager program has such an implementation and uses it as fall-back. I couldn't find any mention of the anonymity profile from its documentation and will not just assume that it uses it. I don't recommend NetworkManager because it doesn't work with dhcpcd above v9 and when I had it setup with dhcpcd, it only produced a warning message in syslog and proceeded to connect using its own implementation of dhcp, giving me a false sense of security.

dhclient is said to be highly configurable and a good alternative to dhcpcd but I couldn't easily find the documentation and still haven't found the option to use the anonymity profile. If you find it or disagree with me, please do send me an email but otherwise I would recommend using dhcpcd instead.

dhcpcd is very well documented (man 5 dhcpcd.conf). All you need to do is append "anonymous" to the end of /etc/dhcpcd.conf and you're done! You shouldn't run it as a daemon yourself but let the network manager or scripts call it on an individual interface.

Leaking of local information to a remote server

Tor is your only option here if you want to access clearnet. I don't trust exit nodes and 2 hops are too little to rely on so I wouldn't think accessing clearnet can be done in an anonymous way no matter what others may want you to believe. Not directly anyway. If you want to download a youtube video, for example, I wouldn't consider running youtube-dl through torsocks anonymous but I would consider it so if you download that same video through a hidden service hosting an invidious instance. In that case you would be staying in the darknet and only the server will be interfacing with clearnet.

If you want true and absolute anonymity, you shouldn't leave the darknet at all. May the day come when we're all there.

Time correlation & Usage patterns

HEAVY paranoia and autistic incorporation of randomness in your daily life. All other considerations are dwarfed by this. This is the hill where most if not all people die on. It is the final barrier to ideal anonymity and overcoming it is very difficult. The fact is, with our current technology, it's almost impossible to do all things anonymously. The good news is that you don't require perfect anonymity to achieve effective anonymity. The trick is to assume separate identities for things you can't do anonymously and for things you can and never mix the two. This is still pretty autistic but if you want any protection from the alphabet agencies, you'll need to do this.

Network managers

You could connect to a network manually using iw and dhcpcd but that's too bothersome to do every time so we will enter the twisted realm of network managers. Now I'll look at the popular choices listed by the various wikis and dismiss them until we reach something hackable.

Criterion:

Programs:

The last 3 are good candidates and I myself settled for netifrc. netctl was my previous choice but you should switch to openrc if you can help it. Wicd's codebase is sadly a little too old to be considered relevant, which is a shame as that's the most user friendly option.

Solutions

netifrc

This is a very manual method but it gets the job done. You need to replace wlan0 with your wireless interface name (ip link show).

Add the following to /etc/conf.d/net:

modules_wlan0="wpa_supplicant"
config_wlan0="dhcp"
mac_wlan0="random-samekind"

wpa_supplicant needs to be installed.

We will then need to connect to the network. To do this, we will write a wpa_supplicant configuration directly. For an open network, write the following to /etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

network = {
    ssid="<network name>"
    key_mgmt=NONE
}

If you want to configure multiple networks, I suggest adding disable_scan_offload=1 to limit probe request packets.

Append the following to the end of /etc/dhcpcd.conf to use RFC 7844:

static domain_name_servers=9.9.9.9
anonymous

Instead of 9.9.9.9, DNS over HTTPS/TLS can be used. This shouldn't matter that much if you are connecting directly to tor or other darknets.

You need to make a symbolic link to create the service for wlan0:

ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0

Then to start the service:

rc-service net.wlan0 start

To search for open networks, you can use this:

ip link set wlan0 up
macchanger -a wlan0
iw dev wlan0 scan | grep -B5 SSID | grep -A5 "capability: ESS Short"

netctl

This is the easiest way to achieve anonymity if you are using Arch.

All you need to do is write a configuration file /etc/netct/netname, replacing the angle brackets with the relevant information. (For more details, I recommend reading the arch wiki.)

Interface=<interface name>
Connection=wireless
Security=none
ESSID='<network name>'
IP=dhcp
DNS='9.9.9.9'

Then write a script that changes the MAC address before every connection /etc/netctl/interfaces/<interface name>. Netctl is a little weird in that it doesn't have pre/post connect/disconnect hooks so the interface script is executing both before connecting and before disconnecting, hence the conditional statement.

#!/bin/sh

ip link show <interface name> | grep "DOWN" &&
/usr/bin/macchanger -a <interface name> > /tmp/macchanger.log

Append the following to the end of /etc/dhcpcd.conf to use RFC 7844:

anonymous

To establish a connection you can run

netctl start netname

then to stop it when you finish

netctl stop netname

Note: root is required.

wicd

Wicd was originally written in python 2.7 so now that python has reached end of life, wicd doesn't work. There is a working port available but it's not in my repositories yet. I'll update this section once it's there.

To change the MAC whenever you connect to a network, place this script under /etc/wicd/scripts/preconnect/.

#!/bin/bash

connection_type="$1"

if [[ "${connection_type}" == "wireless" ]]; then
        ip link set <interface name> down
        macchanger -a <interface name>
        ip link set <interface name> up
fi

Umbrella solutions

Some more informed readers might ask why I haven't gone over umbrella solutions like Tails or Heads or Qubes + Whoonix. It's because they're all bloated. A networking problem requires a networking solution, not an operating system solution. Tails had vulnerabilities because of the bloated graphical software it uses by default. Specter, Meltdown and friends show that vitalization is as secure as normal execution. Not to even mention the discovered vulnerabilities within virtualization technology itself or the hardware acceleration vulnerabilities. Another big factor, or I guess the same, is bloat. These umbrella solutions won't run very fast on an x200 or t60 ThinkPad with Libreboot. I don't even know if they can run on SoCs. What would be the point of such a system if it left in the backdoor in the CPU?

Related

Some of you might want to have your own mail server but don't want to be instantly identified when fetching email. For those people, I've written a script to automatically set up such a server on OpenBSD that you can access securely and anonymously (to the local network) by fetching and sending email through tor.