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 <[email protected]> On Sun, Jan 24, 2016 at 4:05 PM, Graham Cobb <[email protected]> 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 > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
