Algo: Separate egress IP address

[dnesting]

I am in the process of adding a second nic on the algo VM with the intention of sending outbound traffic from the VM through a different external IP address than the one I'm establishing the VPN connection with. The goal here is to disassociate the two so as to make it more difficult for an adversary to correlate activity, where they have knowledge that I have a VPN tunnel established to an IP address, and may be able to see traffic leaving the provider's network or arriving at servers originating from that IP address.

It's unclear to me whether this feature fits the algo feature/anti-feature criteria, since this adds complexity for a benefit that most algo users may not care about, so I'm not sure whether I should aim to contribute my changes upstream. Thoughts?

[davidemyers]

It's pretty easy to do this on DigitalOcean using their Floating IP feature. I can post instructions if anyone's interested.

[benturner]

I'd certainly be interested seeing how to do this on DO.

[davidemyers]

Log in to the DigitalOcean web interface and assign a Floating IP to your Droplet.

Log in to your Droplet and determine the Anchor IP associated with the Floating IP:

curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address

This will return something like 10.13.0.7.

Edit /etc/iptables/rules.v4 and replace -j MASQUERADE with -j SNAT --to 10.13.0.7 (using the Anchor IP returned above).

Restart the firewall: systemctl restart netfilter-persistent

Remember to delete or re-assign the Floating IP if you destroy your Droplet or you might get charged for it.

[benturner]

Thanks!

[strogonoff]

I’d appreciate this feature too. I currently run my Algo on AWS, though.

Could we keep this open as a request to perhaps just update docs with corresponding instructions for other deployment targets (DO above is a start), or maybe even add this to the auto-provisioning scenario?

Seems like it could be an important feature within the scope of Algo as far as security goes, although that’s up to maintainers to decide. (Algo is amazingly useful as it is.)

[dguido]

I don’t think I want to support this feature. It provides no security benefits and the privacy benefits are dubious. It complicates setup and increases costs. The scenario you describe where it does provide a benefit sounds contrived. Can you be more specific and describe a concrete use case where this feature provides a strong benefit?

[dnesting]

@dguido, the specific threat that I am mitigating involves an actor with visibility into network activity on both sides of the VPN instance.

On one side, this could look like monitoring my local network, or the cloud provider's network, or anywhere in between. On the other side, this could look like monitoring the network of the servers I'm accessing, the cloud provider's network, and anywhere in between, but also ad networks, or web server logs or other databases that may record my (VPN instance's) IP address and the time of access.

One could imagine, for instance, that nation-states may collect both sides of these connections as they transit a national border, or utilize a hotel or ad network that may be compelled to share data with their government.

I accept your assessment that the benefit/degree of paranoia here for most algo users may exceed the cost of adding this complexity. My question was about upstream contributions, and I think this answers it. Though my original proof-of-concept involved adding a second NIC, I think I can accomplish this with less complexity.

[dguido]

I'm still having trouble parsing your concerns. Can you write out a scenario with a real person, cloud provider, and website?

Is the concern is that a _global passive adversary_ (something we're explicit about being a lost cause to threat model) is capable of identifying that you are visiting a specific website when tunneled through a VPN? IMHO VPNs are not a tool for privacy (my focus here is entirely on security). Even if you did what you described, wouldn't it only be a single query away for an intel service with a massive database of traffic to identify you've got a VM with 2 NICs, one for outgoing and one for incoming? How would this 2 NIC setup be resistant to analysis from a network operator (or someone that compromised a network operator)?

My concern about implementing any of these privacy features is that they're all just flimsy smoke and mirrors that provide a false sense of privacy, since they fall over the second that someone knows you're doing it.

[dguido]

To be clear, I would consider a hidden option somewhere to assist with turning this kind of feature on, but I don't want to lull people into a false sense of privacy with it, hence the intense questioning on what we really gain by it. Feel free to email me directly if necessary: dan trailofbits

[dnesting]

I appreciate the intense questions. The goal here is to raise the cost of collecting the information, not to be impervious to it. This change would not mitigate a compromise of the cloud provider itself, or my account there, or the device I use to manage it. It would also not mitigate a statistical analysis of traffic, but rotating these egress IP addresses might frustrate such an analysis (not something I'm tackling now but potentially in the future).

I'm happy answering further questions, and appreciate the scrutiny (it's possible I've missed something), but it is also not my goal to persuade here, so I don't mind at all if you aren't interested in accepting changes back. I absolutely understand and agree with algo's project goals and non-goals as you've laid them out with respect to security vs privacy.

[dnesting]

Can you write out a scenario with a real person, cloud provider, and website?

Alice is visiting China. She gets to her Hilton and wants to research something she doesn't want the PRC to know about. She fires up her Algo VPN, which is running in AWS us-west, and browses some sites in China and elsewhere, believing her research can't be easily monitored or traced back to her.

China compels the hotel to provide information to the PRC on its guests, and they monitor her connection back to her VPN instance. They observe the same IP address making requests to web sites that China is able to monitor. Some of these sites use an ad network whose logs are collected by the PRC, so even some request details within TLS-encrypted sessions are available. The PRC can correlate connections, and some request details, to the VPN instance to Alice's name and where she is staying.

The change I am researching eliminates the IP address as the fact they can pivot on, requiring an additional compromise of the cloud account or inferring the fact that the IP addresses are part of the same Algo instance through some other method.

Does this help? There are other variants on this that I could come up with, involving internet cafes, or cloud services hosted in China.

[dguido]

I get it now. This makes a lot more sense! We're working on a big port to Ansible 2.5, and holding off on any major new features until after we get it merged (#976). After that is done, I'll see what I can do to add a hidden configuration option for at least one cloud provider (say, AWS) to enable a two IP deployment mode.

[dnesting]

I'm happy letting you run with this with your own design and on your own terms, but I'm still digging in myself if only to learn Ansible and Algo. I have two proofs of concept working here (based on the ansible2.5 branch) and would like feedback. I'm using the GCE provider.

1. Convert to using the new GCE "magic modules" objects (so we can get multiple network interfaces on an instance), and then instantiate a new "egress" network with no firewall rules, a second NIC attached to that network with its own external IP address, and then some ip route setup to get outbound connections working over the second interface. This leaves the default network accepting connections from the user as before. This works, but adds complexity.

2. Add a new gce_eip static IP address used by four gce_lb forwarding rules for SSH and VPN ports, giving them a separate static IP address and using that as our interface into the VPN, leaving the instance's default network and ephemeral external IP address for egress. This works, but leaves SSH and VPN ports open on the egress IP address (would be nice to keep this a "blank slate"), since the forwarding rules don't bypass firewall rules.

Is there a third option I could prove out here?

[nklayman]

Is there a way to do this on Azure via IP routing, or do we have to wait for this to be fixed?

[nklayman]

I got it to work on Azure by creating another public IP and attaching it to the VM's network interface. I followed this guide to add it to the Ubuntu vm. I then assigned thew original IP to the second ip config and the new one to the first. Since the first one is used by default, all outgoing connections use the new IP, and I can still connect through the original IP.

[davidemyers]

It turns out there's an even easier way to do this with DigitalOcean than what I described above when using WireGuard clients:

1. Deploy to DigitalOcean in the normal way and set up your WireGuard clients.
2. Add a Floating IP to the Droplet from the DigitalOcean web interface.
3. In the WireGuard app or config file on each client, replace the Peer Endpoint IP address with the Floating IP.
4. Remember to delete or re-assign the Floating IP when you destroy your Droplet so you don't get charged for it.