Securing tinc config files

[Yazeed Fataar]

Agreed , thanks Graham. My purpose is just for inter-site connectivity in
order to gain access to our central file server. And like you said, it
depends on the assets trying to protect. I think for my purpose a reputable
VPS provider will serve purpose, and I would just need to ensure that my
remote sites are locked down in an event of attempted breach. Thanks all
for inputs.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Regards
Yazeed Fataar
<yazeedfataar at hotmail.com>

On Sun, Jan 24, 2016 at 4:05 PM, Graham Cobb <g+tinc at cobb.uk.net> wrote:

> On 24/01/16 12:19, Yazeed Fataar wrote:
> > I cannot use dynamic dns , the remote sites connect through 4G LTE and
> > get assigned "Private Addresses" that are NATd to a Public Address. The
> > LTE clients can only make connections outward to the Internet and
> > features such as PAT and Dynamic DNS will not work. Therfor for these
> > remote sites I need a Central Server Located on Internet to peer with in
> > order for the Site to Site connection to work. Tinc works perfectly in
> > this and I have tested it thoroughly, I just have concerns now over the
> > Central Server which holds all the tinc configuration data.
>
> The issue with all security is to understand what is the threat (who are
> you trying protect from), how long do you need to resist the threat, and
> how much is the protected asset worth (i.e. how much are you willing to
> spend to protect it).  If you are REALLY serious about your question,
> and are willing to spend money to fix it, you need to pay a security
> consultant to come up with the required design that trades these three
> off in the way you choose.
>
> That said, here are some free thoughts (and I am no expert) - which are
> worth all that you are paying for them :-)
>
> In my experience, in practice, a paid-for VPS, from a reputable
> supplier, is secure enough for most purposes.  Even small businesses.  A
> medium-sized business might prefer a physical co-lo server in a locked
> cage.  In either case, you have a contract with the provider, they have
> a policy (such as the Digital Ocean policy you quoted), and they have a
> reputation to uphold. Of course, that will not protect you from state
> actors (police, spies, etc), and it won't protect you against someone
> who is willing to bribe the VPS staff.  On the other hand, I have run
> tinc with a VPS central node for many years (probably more than 10) and
> have never seen any unexpected node appear (of course, I can't tell if
> someone is decrypting all my traffic).
>
> If you really want to avoid having the keys on the central server, you
> could arrange to run tinc on a server you control (e.g. at home) and
> forward all the (encrypted) tinc traffic from the central server to it.
>  You could, for example, make an outgoing SSH connection from your home
> node to the central server with port forwarding, so that all traffic to
> the tinc port on the central server gets forwarded to the tinc port on
> your home server.  You would have to write some scripts to make sure the
> connection was reconnected whenever it failed, and performance would
> probably be very poor, but it would avoid the keys being on the central
> server.
>
> But, is it worth it?  If you are trying to protect against state actors
> you have probably already lost.  If not, a VPS is probably good enough.
>  If it isn't, you are probably a large corporation with plenty of real
> physical servers visible on the internet.
>
> Just my thoughts.
>
> Graham
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160124/b2d2b0ee/attachment.html>