5

We have two hosts, theoretically in the same data center. The two machines are hosted at Online.net. We're having a bit of a debate: should the traffic between the two hosts be encrypted.

The traffic we need to exchange are Redis queries. The data that will be exchange is Twitter and Facebook user IDs, a code to indicate a job to do, and a market ID, which is itself a UUID. A typical query and response would be:

> hgetall Twitter:12345
1) 1) "c4a9c7f0-78d1-0132-b14c-70921c10876c"
   2) "F"

The two implementations we're thinking of:

  1. Use an SSH tunnel with port forwarding to hide the Redis server from the public Internet. On the machine hosting the Redis server, create a separate user with a single aurthorized_keys, with proper securities to not allow running arbitrary programs;

  2. Simply use the firewall to limit traffic to Redis to the single IP address we need, nothing more.

We're not sure which would be "more secure" (or more appropriately, less risky). Adding users and configuring SSH introduces complexity, while adding a firewall rule is much simpler. On the other hand, if an attacker reads in-flight packets, what useful data can they collect?

What I want to protect against is after having gained access to the client machine, an attacker could gain a foothold into the Redis server machine, which hosts many more services.

François Beausoleil
  • 153
  • 5
  • 1
    I'm confused: do you want to protect the data in transit or do you want to protect the server? It looks like you have 2 different questions. – schroeder Jul 13 '15 at 15:09
  • @schroeder, well, I want both? In case someone finds a hole in the client box, I don't want them to escalate to the server machine. I would prefer to protect the in-trasit data, but my colleague thinks it's not worth it. The data is pretty obfuscated, so it might not be worth it that much. – François Beausoleil Jul 13 '15 at 15:58
  • Essentially, would I introduce additional risks by using an SSH tunnel (or stunnel or a VPN), or does using a firewall offer adequate protection? – François Beausoleil Jul 13 '15 at 15:59

3 Answers3

3

If the machines were on your own network (home, your company's datacenter, etc), simple IP-based restriction and/or putting the Redis-related machines on a separate VLAN should be enough.

However, in case of a hosting provider, I recommend considering their networks as hostile and equivalent to the open Internet, in which case you should create your own internal network using IPSec between your machines, and passing whatever unencrypted traffic you want over that.

It won't protect against the hosting company going rogue against you, but at the very least whatever attacker would have to do much more (memory analysis which requires hypervisor or physical access) to get the IPSec keys and make sense of your data than passive packet capturing which is really easy.

Anonymous
  • 31
  • 1
1

I'd say an explicit ACL in the Firewall permitting the traffic to and from the devices in question should be fine in this instance.

It sounds like the information being exchanged is just user IDs? If this is the case and the information isn't necessarily sensitive, I don't see an issue with just ensuring the rules are in place to allow the traffic.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
shift_tab
  • 423
  • 3
  • 13
  • Yes it sounds like allow to only the redis port seems like a solution. You could also use stunnel or some other ssl provider to help with on wire encryption. It probably does not significantly introduce additional risks. – munchkin Jul 13 '15 at 18:06
1

Facebook ended up working on encrypting all data within their own private owned datacenters.

Encrypting traffic provide an overhead... somewhat small in CPU performance if done right, but somewhat non-trivial in administrative time to figure out how to configure it smoothly. I'd recommend an option you haven't listed: SSL with connection pooling and Perfect Forward Secrecy. Most of the overhead in SSL is within the initial asymmetric handshake, so pooling helps performance. PFS means that if the host keys are compromised at a later date, a recorded encrypted transmission won't be of value.

That means eavesdropping even through a network tap would be essentially useless to an attacker if you have good certificate control.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171