DEV Community: BowTiedAztec

How to Code Anonymously, Part 2: Network Security

BowTiedAztec — Mon, 14 Mar 2022 15:37:12 +0000

Introduction

This is part two in a series of posts to teach you, fellow developer, how to better maintain your privacy and security as the world around us grows more digital and dangerous with each passing day.

You can find part one, dealing with multiple git profiles, here.

Background

Many people think of the internet as being "anonymous," but that's never really been true. Let's illustrate why with an example:

You move into a new house and sign up with an ISP to get internet access. At this point, as a subscriber, they know exactly who you are.
You plug in your router, and your ISP assigns it a unique IP address to route all of your traffic.
You connect your computer to that router. The publicly visible IP address when you visit individual sites (like Facebook) will be the IP address assigned to your router.
You do something truly heinous, like organize a peaceful protest on Facebook, so law enforcement asks Facebook for the IP address behind your account. Facebook complies, as they routinely do.
IP address in hand, law enforcement then goes to your ISP to de-anonymize the address. Your ISP complies, as they routinely do.
Prepare to receive an express shipment of freedom and liberty at your doorstep.

While not the only way to de-anonymize you, disguising your true IP address is the most obvious attack vector to minimize. I'm going to spend most of this post teaching you how.

To do that, I'm going to break down opportunities into two groups:

Building blocks : individual pieces of anonymizing technology that you can combine into strategies.
Strategies : combinations of building blocks into more complete systems of defense-in-depth to help preserve your privacy.

Let's get to it.

Building Block: VPN

A VPN is one of the most common ways to retain a degree of anonymity. You can think of it like a virtual version of going to your local coffee shop - many people pool their traffic together into the same IP address, almost as if they were using the same physical router, making it harder to understand which individual is doing what. If your VPN offers many locations around the globe, it becomes possible to spoof your location as well, which may also offer additional legal protection (e.g. it may be harder for US law enforcement to enforce a warrant in Iceland).

That last point is worth unpacking in more detail. You can learn more about different jurisdictions and how they affect privacy here. Most privacy-conscious folks tend to avoid the "5 eye" countries (US, UK, Canada, Australia, NZ) at minimum.

If your VPN is trustworthy and doesn't keep logs, it makes it more difficult for law enforcement to get a usable answer to the question of "who is behind this IP address?"

Emphasis on if they are trustworthy. The downside of a VPN is that it requires faith that your VPN is doing the right thing. For casual privacy, this may be fine, but if your safety depends on it, you should really take stronger precautions.

For extra protection, you can combine multiple VPNs, for example, by using a VPN from one vendor on your physical machine, and another from a different vendor inside a virtual machine.

In theory, your first VPN will know your real IP but not your destination, and your second VPN would know your destination but not your real IP. This is actually similar to how the Tor protocol works.

It's also worth noting that free VPNs are almost never trustworthy. Very commonly, they will monitor your data and sell it to third parties (or happily give it away to law enforcement).

Personally, I use Mullvad (not a referral link), because of their seemingly genuine commitment to freedom of speech and privacy, as well as their location in Sweden. They also accept cryptocurrency as payment, which is helpful as well.

Building Block: Tor Browser

Tor stands for The Onion Router, which is actually a pretty good description of how it works. You can almost think of it as a VPN in series - when you make a network request, it passes through three layers of Tor nodes (each of which has its own IP address) before exiting back to clearnet.

Because of this architecture, the destination of your web traffic (e.g. Google) only has the IP address of the Tor exit node, not the IP address of your router. And because it passes through multiple nodes, no single node has both your source IP address and your destination.

The Tor browser takes some additional steps to protect your privacy, like enforcing a constant window size (e.g. to prevent an attacker from detecting you have a Mac retina screen) and obfuscating some of your machine details to avoid identifying you through a unique hardware signature.

That being said, it's not perfect. If bad actors compromise a substantial number of nodes in the network (and sadly, I put the US government under the "bad actors" umbrella), then the privacy guarantees offered by Tor can become compromised.

Additionally, there is a risk that law enforcement views any Tor activity as inherently suspicious and will start watching you more closely if it sees you use Tor. This is one reason it may be better to avoid accessing easily identified accounts (like your personal Gmail) over Tor.

Building Block: Torsocks Shell

As developers, we spend much of our time in the shell. How can we take advantage of the privacy offered by the Tor Browser when interacting e.g. with a git remote? Enter torsocks.

On debian based systems, simply install the tor package from the repository:

sudo apt install tor

Then open /etc/tor/torrc and uncomment the following line:

#ControlPort 9051

Finally, restart the service:

sudo service tor restart

And wrap your favorite command in torsocks:

torsocks curl ifconfig.me

You'll notice that ifconfig.me returns a different (tor-ified) IP address than whatever comes back if you curl it normally. Success!

You can also wrap every command in your terminal session in torsocks by using the following command:

. torsocks on

And disable with:

. torsocks off

And if you want every shell on your system to use torsocks by default, simply add . torsocks on to your $HOME/.bashrc or equivalent.

MacOS Note : I tried Torsocks with MacOS at one point and couldn't use certain command line utilities. Apparently MacOS has an extra security layer around certain parts of the filesystem that prevents torsocks from working normally (ironic, isn't it?). You can create copies of these utilities in a less-privileged location, or use my preferred solution, which is to simply start developing on Linux. :)

Building Block: Separate / Virtual Machine

Another dimension you can add to your opsec is doing all of your sensitive work on a separate machine. This helps isolate potentially malicious programs from accessing information about your true identity. It also reduces the chances of contaminating your "safe" network traffic with real information about your identity.

Let's take one example - VSCode. I'm a huge fan and use it every day for my coding, but while the core product is open source, Microsoft adds telemetry and other unknown things as part of its build process. There is an open source fork called VSCodium that attempts to address this, but keeping a separate copy on a separate machine is an extra layer of protection for your activities.

This way, VSCode can report on whatever it wants from your non-sensitive machine, as well as your sensitive machine, but as long as the two machines know nothing about each other, it's not particularly damaging.

A separate physical machine is ideal, but also not always practical. You can achieve a lot of the same protection by using a virtual machine, or machine inside your physical machine.

The default choice for this (at least on Linux), is generally VirtualBox. Many people on Windows or MacOS use VMWare as well.

Strategy: VPN + Tor + Torsocks + VM

Knowing about all of the building blocks above, you can combine them into a fairly compelling privacy stack:

Install your favorite Linux distro using VirtualBox
Use this VM for your sensitive activities
Route your internet traffic on the host through a VPN (and ideally a separate VPN inside the VM)
Use Tor inside the VM for your browsing
Use Torsocks inside the VM for your shell commands

This should go a long way toward isolating and anonymizing your sensitive network traffic from everything else on your machine. To truly isolate, you can also move your personal activities into a separate VM that follows the same strategy.

Building Block / Strategy: Whonix (My Pick)

The previous strategy is great, but it's actually easier and more effective to just use Whonix. Whonix is a Linux distro - designed to be run out of VirtualBox - that implements all the goodness of the previous strategy. Even better, it comes with a novel network architecture that involves two virtual machines for extra protection:

A workstation VM, where you do e.g. your software development
A gateway VM, which exists only as a network proxy for tunneling traffic from the workstation through Tor

This architecture makes it nearly impossible for your network traffic to go anywhere but Tor, and dramatically reduces the risk of IP address or other information leakage.

You can also combine it with a VPN on the host machine for extra protection.

Whonix in VirtualBox with Mullvad VPN on the host machine is the strategy that I personally use. It allows me to have a high degree of privacy when I need it, while retaining the ability to use a more productive OS on the host (Pop! OS in my case).

Building Block / Strategy: QubesOS

Conceptually, Qubes is Whonix on steroids. And, in fact, it uses Whonix under the covers. It's the best option if you want to compartmentalize every profile you have from every other profile.

It makes it relatively simple to utilize a number of strategies, like chaining VPNs or tunneling network traffic through Whonix. It is also built from the ground up with virtualization in mind, so it becomes possible to separate e.g. your side hustle from your main job from your personal profile. But it does this in a way that is much more performant than creating a number of distinct virtual machines.

For these reasons, it's the OS of choice for Edward Snowden.

On the downside:

Qubes has to be a bare metal installation due to its virtualization, so if you don't like some of the choices it makes (like the xfce desktop), your only option is to dual boot with something you like better.
Due to the heavy use of virtualization, Qubes can also be resource heavy. I found it unusable with 8GB of RAM on an older test laptop, for example.
Common developer tools like docker or the android emulator can be difficult to get working due to its architecture.

With more time and maturity, I could see Qubes becoming my daily driver OS. But for my use case today (max productivity 90% of the time, max privacy 10% of the time), running Whonix out of VirtualBox is far more practical.

Honorable Mentions: Tails and Kali Linux

Tails is probably the most famous privacy-oriented OS due to its use by journalists and other dissidents. But it's a much better fit for them than it is for software developers.

Tails is designed to be run without persistent storage, on a device like a flash drive. If you are primarily checking secure email, writing content, and otherwise interacting with cloud services, this is fine, but developers generally need persistent storage (to avoid setting up their development environments every time they boot) as well as better performance than what's available off a thumb drive.

While it is possible to run Tails in a persistent storage mode, even as a bare metal install, at that point I would probably recommend you just use Whonix or Qubes.

Kali Linux, on the other hand, comes up in many discussions around cybersecurity. It's not really designed to be a daily driver OS. That being said, if you're looking to do cybersecurity research (for example, trying to break through one of the strategies we've discussed in this piece), it is one of the most popular platforms to do it.

Conclusion

I hope this was a helpful summary of your options for achieving better privacy as you develop your pseudonymous projects. If you have questions, please don't hesitate to contact me on Twitter @BowTiedAztec.

How to Code Anonymously Part 1: Multiple Git Profiles

BowTiedAztec — Wed, 09 Mar 2022 18:00:00 +0000

Introduction

This is part one in a series of posts to teach you, fellow developer, how to better maintain your privacy and security as the world around us grows more digital and dangerous with each passing day.

Background

I contribute to a number of software projects, some in crypto, some normie, some under my real name, some under a pseudonym. A question I get a lot from developers who want to plug into the pseudonymous economy is how to keep their personal profile separate from their "extracurriculars," without accidentally outing themselves forever.

While there's no absolutely "safe" way to do this, among the safest would involve a separate machine (virtual or otherwise), and a proxy that sends all your traffic through Tor. This is something I'll cover in a future edition of this series.

For now, I want to focus on one of the easiest steps you can take to maintain a degree of separation between your identities: multiple Git / Github profiles on the same machine.

This strategy is appropriate when:

For reasons of privacy or retaliation (e.g. your employer), you want at least one degree of indirection between your real identity and your pseudonym
Your physical or legal safety does not depend on this indirection (if it does, you need something stronger)

With that out of the way, I'll dig into a couple of details about how git works, and proceed to some recommendations.

Git uses SSH

The first thing to realize about Git is that it utilizes SSH for everything involving pushing/pulling files over the network. Anytime you run git push, git pull, git clone, etc., something like the following happens:

Check $HOME/.ssh for default SSH configuration and SSH keys
Use the configuration in $HOME/.ssh/config to route the command to the correct host
Authorize the request using the key (either supplied with the command or the system default)

With this in mind, it becomes relatively easy to create and use a second profile on the same machine.

Step One: Create your new key (and optionally add it to github)

This one should be familiar to everyone. It's the same process you used to create your original key. You can follow the instructions from Github here or run this command and follow the prompts:

ssh-keygen -t ed25519 -C "your_email@example.com"

If you plan on using this key with github, follow their instructions to add your public key (ending in .pub - do not upload your private key!) to your account.

Step Two: Add a new git host

The next step is to update your SSH config to give you an easy way to use this new key. To do this, we are going to create a custom host.

First, open up ~/.ssh/config in your favorite text editor. You're going to add an entry that looks like this.

Make sure to substitute 'github-aztec' for something else, and replace 'id-aztec' with the file name of your new private key from the previous step.

Host github-aztec
    User git
    HostName github.com
    IdentityFile ~/.ssh/id_aztec

Now, when your SSH daemon looks for hosts with which it can connect, 'github-aztec' will be in its virtual list, just like a real domain like github.com. The difference being that this connection, by default, will also pass along the correct SSH key that you created in the previous step.

Step Three: Update your project origin

Now that you have a key and a host, you need to update your project to point to it.

Navigate to your project root and run the following command (substituting 'github-aztec' for the host name you chose in the previous step):

git remote add origin github-aztec:user/repo

This is identical to what you would do with a normal remote, just substituting 'github-aztec' for 'github.com' (remember, 'github-aztec' is now a host like any other from the perspective of SSH on your system).

Now anytime you interact with git in this project, it will be interacting with the host (and therefore, key) from the previous step.

Step Four: Update your commit identity

This one trips up a lot of people. Every time you commit code in git, it writes a commit message that looks something like this:

If you aren't careful, git will pick up any global user/email you set previously and store that in future commit messages.

So make sure you set them like this:

git config user.name "BowTiedAztec"
git config user.email "bowtiedaztec@example.com"

If you previously set these values globally using the --global flag, it may be worth unsetting them globally so you will always be prompted by git to add a user and email for new projects.

Help, I f***ed up!

If you accidentally committed your real info to git, not all hope is lost. Set your git user and email per the previous step and then run the following command to amend the commit:

git commit --amend --reset-author

If you haven't yet pushed your code to a remote, you're done! If you have, you will need to run the following command to erase your info from the repo:

git push origin <branch_name> --force

The --force flag will overwrite previous history in the branch. If you don't have force push access, you will need to contact the owner of the repo.

Bonus: Using a VPN

As I mentioned, I will cover networking opsec in a future post. But one low-cost, high ROI technique for maintaing a bit more anonymity is using a privacy-oriented VPN. This will have the effect of pooling your network traffic with that of many other people, making it that much harder for someone (e.g. GitHub or whomever else you interact with via git) to figure out who is behind the pseudonym.

(Though, again, do not rely on this if your safety depends on it. Seriously.)

Personally, I use Mullvad VPN (not a referral link, I don't roll that way) but there are plenty of options out there. I like Mullvad in large part because of their long history of support for free expression as well as their physical location in Sweden (one of the better jurisdictions for privacy).

Conclusion

I hope this was helpful! If you have any questions, please feel free to contact me on Twitter @BowTiedAztec.

In Soviet Russia, Namecheap register you

BowTiedAztec — Tue, 01 Mar 2022 06:02:24 +0000

I was doing a little evening reading in my Mexico City apartment when I stumbled onto this post on hacker news:

Dear XXXX,

Unfortunately, due to the Russian regime's war crimes and human rights violations in Ukraine, we will no longer be providing services to users registered in Russia. While we sympathize that this war may not affect your own views or opinion on the matter, the fact is, your authoritarian government is committing human rights abuses and engaging in war crimes so this is a policy decision we have made and will stand by.

If you hold any top-level domains with us, we ask that you transfer them to another provider by March 6, 2022.

Additionally, and with immediate effect, you will no longer be able to use Namecheap Hosting, EasyWP, and Private Email with a domain provided by another registrar in zones .ru, .xn--p1ai (рф), .by, .xn--90ais (бел), and .su. All websites will resolve to 403 Forbidden, however, you can contact us to assist you with your transfer to another provider.

Customer Support, Namecheap

I think most people can agree that what Russia is doing is terrible, but that's not the point. And clearly so, since this action will have absolutely no impact aside from annoying people who very likely had nothing to do with the invasion (and, per some of the comments in that HN thread, may in fact be using their sites to oppose Russian policy.)

So allow me condense and rephrase Namecheap's statement to make it clearer:

Must virtue signal. No internet for you.

I'm not going to spend any more time bashing Namecheap, if only because a) they don't really matter, and b) they're not alone. How many examples have we seen now of centralized (dare I say "legacy"?) tech companies banning something because it crosses their delicate Silicon Valley sensibilities?

One more reason to take an inventory of the services you use every day and think about how you would respond if they ever did something like this to you. Do you make your living from....

Youtube? Centralized.

Instagram? Centralized.

Twitter? GTFOH.

Hell, even Substack is centralized. And yeah, they say all the right things about respecting free speech, but so did Twitter. Anyone else remember "the free speech wing of the free speech party?"

Now's the time to take control of your destiny again and host your own shit. I can help, more posts to come in the near future.