New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Best way to secure connection between 2 servers?
dodheimsgard
Member
in Help
Hey guys
I have few servers that need to communicate, servers are in different datacenters.
Server1 is postgresql database server with nginx + python on "frontend" (so database is accessible only locally).
Server2 is just server performing post/get requests to server1
So far i have self-signed ssl certificate on server1
Im planning to transfer data between servers as aes encrypted strings.
What else i can do to be sure this data transfer between servers is as secure as possible?
P.S.
Yes this data is sensitive.
Yes im paranoid lol 
Comments
Wireguard...
It depends how you are transferring data, but you can check "SSH tunnel".
Create an SSH Port forwarding between both servers and connect through this tunnel to your database?
Stunnel. You could also only allow access to server1 from server2's IP address.
If you are really paranoid just modify an existing open source encryption. No one will know what they are dealing with.
IPSec in Transport mode, then you don't have to do anything crazy with NAT/Port Forward/etc. In transport mode, you can just use the same IP address from each other and the traffic will be encrypted via IPSec. Make sure to block connections from
eth0or other external interfaces via the IP so you don't accidentally connect via cleartext channel.If you need something less sophisticated, NetCat + OpenSSL should do the job sufficiently (No PFS in this method): https://gist.github.com/leonklingele/d5bd28ee51a4b8e49baa
You can use a simple SSH tunnel, Wireguard or Tinc.
1) SSH Tunnel is simple, but done in user space (read: slower)
2) Oh boy Wireguard...
3) Tinc is not only done in user space, but it is also complicated to setup
@zllovesuki
Did you ever had a wife? thats complicated.
Ad hominem is never the solution, friend. Dare you assume everyone on this forum is male and straight.
openvpn in p2p mode should be enough for that and you can use any other cipher but default (AES) such as Camellia if you are paranoid.
Wireguard, tinc, ssh tunnel; in this order of preference.
"no"
PeerVPN / MeshVPN?
I hope this is a joke
the first rule of crypto: never roll your own crypto, if you do, you're gonna have a bad time.
I'd first setup host restrictions and whitelists so you can be sure from an external/perimeter perspective you are "safe". I would consider the above options of wireguard, ssh tunnels, use an existing, proven safe, mechanism to have the best support and chances of being able to deal with any issues as they come up, as well as an active development team.
The main attack vector for you is probably a local attack or an exposed remote access service being bruteforced or cracked open. Do the usual hardening (key auth instead of pw auth etc), if you're running OpenVZ, kiss goodbye to privacy, I would create a partition on the disk that you must manually mount and decrypt, of which you can do on each reboot as required (this isn't full disk encryption, but may be a viable option for you for "data at rest" protection. If these are dedicated machines, you may still want to do the latter option since VNC'ing into a KVM every time you reboot the box will be a pain in the arse.
I'm serious.
EDIT:
This time.
OpenVPN:
SSH tunnel:
IPsec:
WireGuard:
Hilariously accurate
Meshvpn:
I prefer this one:
Which VPN would that be?
Ps. geez you got "我叫RM.香港"
you're the first one I know who has a domain in that idn cctld.
Looks to be simple, functional, but not very fast. So that would be Tinc, which I didn't list in my post. It lets you do things WireGuard can't, such as full mesh with resilience to loss of any direct link, and L2 VPN. The only issue is that it's not as fast, due to being entirely in userspace and not in kernel like WG.
Yes, they give it out with .hk for free :)
https://www.wireguard.com/#about-the-project
Those suggesting WG... it’s not been properly audited yet and should NOT be used for anything sensitive. OP suggests that the data they are looking to send across the tunnel is sensitive and therefore they should do their own research before going ahead with unaudited code.
Having said that, I’ve heard WG is very performant and there are some big advantages of using it over alternatives. Personally, I’d rather wait for it to be properly reviewed by an external security auditing company. Who knows what kind of security flaws they could have missed...
Security through obsceurity only works for so long :P Always assume that there is someone out there who is infinitely more clever than you
IPsec. There's a reason it has been used in the enterprise for the past 2 decades or so.
Yep, just like COBOL and Lisp: tragic inertia.
In security, older stuff usually means better - more battle tested.
Completely new stuff is frowned upon in the meantime.
Nobody's mentioned ZeroTier. Something wrong with it?
I've used it in some places; seems to work well for me.
Hint: crypto experts are not worried about symmetric crypto (like AES). What they are worried about is public key crypto because if quantum computers come all current PK algorithms go belly up.
Plus PK crypto is (computationally) very expensive and slow too. Plus it's main purpose is to do with parties not knowing each other and/or key exchange. That's why SSH etc. use PK crypto only for the startup. Once a shared secret key is established sym. crypto is used.
So, using symmetric crypto would be the best solution in your clear cut case. But you should change the key from time to time (each connection ... once a week, depending on your needs). OTPs could be a practical way.
On the other hand the SSH (and similar) proponents are correct in that you still must manage those servers.
And btw, even @eol is partly right because yes that is possible (without going against the "never roll your own crypto" rule). One example is "nothing up my sleeve" numbers which are almost everywhere in crypto and which are almost never selected specifically for a given algorithm. And yes, it would actually work against certain attacks. But it wouldn't make a lot of sense anyway because a good sym. crypto algorithm creates random looking output anyway.
There is one thing you could and should do with SSH: you should make sure to have a good and sensible ssh config and limit it to well selected algos/ciphers and also generally tighten it as in most distros quite some values are on the very generous side.
Don't forget PFS is a thing