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. <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 2:39 PM, Michele Perrucci <emmeperrucci at gmail.com> wrote:> 2016-01-24 11:59 GMT+01:00, Yazeed Fataar <yazeedfataar at gmail.com>: > >[cut] > > My situation I face is all my > > remote sites have dynamic addresses ,and in order for me to create a > > connection point between the sites is to have a central server in cloud > > with public address. Therefor the VPS seems like the cheapest option and > it > > works well.. its the security part I have concerns with. > > [cut] > > Same situation for me but I use a dynamic dns provider (there are a > lot out there, free and paid : choose by yourself the best for you) > coupled with dns-o-matic (a free service from opendns that act as a > client for dynamic dns providers, so you gain two propagations of your > addresses). > So, make a dynamic dns provider account, make a dns-o-matic account, > install and configure a ddns client on one or all of your machines or > routers, and you can use FQDN for your tinc configurations. > In according with my experience, spreading worldwide IP changes is in > order of seconds. > Regards > _______________________________________________ > 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/d0c23b38/attachment-0001.html>
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
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>