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 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 a 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. It also adds more complexity to the software, having to keep track of what MAC to use for what network.

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 without flipping the "locally set" bit. Unfortunately it can't do both at the same time for some reason. Signaling that you're trying to be anonymous to everyone with the "locally set" bit is not very smart so it's a must that we don't. The disadvantage of not using the manufacturers' database is that someone that does can easily discern that we're randomizing the mac address since a random manufacturer is not always a valid one. This calls for a fork but for now we'll stick with the random burned-in address.

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 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:

As you can see, there are no good options, only little devils. Because of this I'm currently working on removing systemd from netctl as well as writing more documentation for it and making the scripts posix compliant. In the meantime, I'll show you how to configure wicd and netctl.

Solutions

netctl

This is the easiest way to achieve anonymity if you are using Arch. Unfortunately Artix doesn't have a fork of the project yet (it will when I finish).

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

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 -rb <interface name> > /tmp/macchanger.log

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 -rb <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 a 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?

Notes

I must mention that, in general, networking varies depending on distribution. This article is written by me so arch based distributions are first class citizens. It, of course, still applies to most other distributions because the programs are the same but there might be subtle differences (e.g. NetworkManager does work with dhcpcd because the distribution uses an older version of dhcpcd). I believe Gentoo does a pretty good job at covering the problem in their handbook with their own methods so I won't go over it here. If you use Gentoo and seek advice from an article like this, I believe you've made the wrong choices.

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.