0

Sometimes one has to work with software that hasn't built in security-features for non-local connections. In fact, some client-libraries are sending credentials in clear text over the wire. On the other side these applications might be powerful and serve their purpose very well - so there is almost no reason to replace them.

How can I secure "unsecure" connections between nodes within my cluster and hide these tunnels from the actual application? In what way will it impact performance for small requests/responses or larger ones? What trade offs are to be made?

Please, note: I am relatively new to the Linux world and I'd like to learn more about securing environments etc.. The above question raised to my mind when I read a paper about the security-features of some early versions of NoSQL-databases. One example of security-leaks was that the credentials were sent in cleartext over the wire, as well as all the data between the nodes. So I wondered how it might be possible to use such valuable technology, even if it has a lack of some built in security-features.

Regards, Ems

2
  • Are you trying to secure traffic on a single LAN? Or across a WAN? Or across multiple LANs connected by the Internet? May 19, 2012 at 11:57
  • Well, the primary use case would be to secure connections within a datacentre. If and when the network becomes compromised in any way, I want to prevent an attacker from gaining direct access to datastreams between the cluster nodes. I am interested in any kind of solution where some statement regarding the above questions is given. The solutions shouldn't have a single point of failure by design or a one-node-bottleneck. A P2P-VPN would be kind of a solution, although I never heard of it.
    – Ems
    May 19, 2012 at 13:25

2 Answers 2

4

What you really need to do is send the traffic over some sort of private network. It's really quite expensive to build your own private wide-area network, so it'd be good if we could utilise the Internet somehow... but then, the private network wouldn't be a physical one, but would instead be "virtual". In fact, that sounds like a really snappy name for a product... a "virtual private network". You could make it even more marketing-friendly with a catchy acronym, "VPN". If only someone had thought of this already...

4
  • Thanks Womble,that's what I thought about in the first place. However it does not completely answers my question. I have no experience with the scalability of a VPN in a larger cluster, how it impacts the workload and so on.
    – Ems
    May 19, 2012 at 11:11
  • 1
    It depends on the VPN technology, the workload, the size of the cluster, the network, and the phase of the moon.
    – womble
    May 19, 2012 at 13:21
  • Could you give me some examples of VPN softwares that meet the above requirements?
    – Ems
    May 19, 2012 at 16:46
  • VPN is not meant for LAN traffic. Please see my response below. Also, what protocol is being used between the nodes? Since you mention "cluster", I'm going to assume HPC and advise you to be very cautious about encrypting inter-node comms as the latency can completely negate the advantages of parallel computing for many applications.
    – bab
    May 24, 2012 at 3:41
-2

Look into SSH tunnels. You can pipe any sort of network connection over them, use key-based auth to eliminate passwords, and script their construction at boot. Plus, SSH is free. Unless you need full L2 tunneling - which it sounds like you don't, nothing more complicated is required.

For example:

ssh -L8080:server.example.com:80 otherendpoint.example.com

will forward port 8080 on your local machine to port 80 on server.example.com, through an encrypted SSH tunnel to otherendpoint.example.com (which could also be server.example.com). Just tell your application to use "localhost:8080" as the other endpoint, and it won't even know the difference.

3
  • Wondering why the downvote? Did I misunderstand the question?
    – bab
    May 24, 2012 at 3:47
  • The OP asked about encryption every connection between two points. SSH tunneling is great for dealing with one or two TCP port numbers, but is completely impractical for dealing with more than that. In this situation, IPsec (most likely in transport mode) is the answer.
    – EEAA
    May 24, 2012 at 12:53
  • Fair enough. Please see my comment about about the impacts of encryption upon HPC applications.
    – bab
    May 24, 2012 at 14:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .