Thanks Guus So based of this , having your central tinc server in VPS Provider , will allow potentially the provider to replicate your config files and thus exposing all your remote sites connected. 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. There was a option I was thinking of using is creating a encrypted partition that I will need to manually decrypt once the server is booted. This partition will contain the "/etc/tinc" directory. In this case the if someone had to compromise my server they would first need to decrypt my encrypted partition . I will not allow decrypt key files to lie on the server directory , I will have to store them elsewhere. The only downside is that should my server reboot , i would need manual intervention to bring up the partition and tinc... Please let me know what you think about this? <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 1:44 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:> On Sun, Jan 24, 2016 at 12:48:13PM +0300, Yazeed Fataar wrote: > > > Thanks Guus.. So if someone had to gain access to my vm-disk. They > > would not be able to view the contents of the files in ""etc/tinc" if > > I do "sudo chmod go= /etc/tinc" .. My paranoia is around a VPS > > provider who had admin access to all containers. I know that I have > > to create a root password that will allow only myself root access , > > but im just worried about the disk contents if it were mounted on > > another system. > > A VPS provider has access to *everything* on your virtual machines, > regardless of what password you set or whether you use full-disk > encryption or not. There is nothing you can do about it, except for not > using a VPS provider. > > The only thing that is secure is when you have a physical machine that > only you have physical access and root access to. The only exception is > perhaps a colocated physical machine on which you yourself configured > TPM in such a way that it only boots from a trusted OS image. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <guus at tinc-vpn.org> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160124/6c581287/attachment.html>
On Sun, Jan 24, 2016 at 01:59:19PM +0300, Yazeed Fataar wrote:> So based of this , having your central tinc server in VPS Provider , will > allow potentially the provider to replicate your config files and thus > exposing all your remote sites connected. 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.Tinc can work with dynamic addresses as well, as long as you have one node with a fixed domain name, that is fine. Maybe a dynamic DNS service can work for you?> There was a option I was thinking of using is creating a encrypted > partition that I will need to manually decrypt once the server is booted. > This partition will contain the "/etc/tinc" directory. In this case the if > someone had to compromise my server they would first need to decrypt my > encrypted partition.That is only the case when the server is down. If they compromise it while it is running, you will already have unlocked the encrypted partition and they can still read it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160124/2eba0cf8/attachment.sig>
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
Hi Guus Yeah I kinda thought of that only once I hit the "Send" button .... I guess I have two options , 1. Manage my own server with public ip address 2. Trust my VPS provider LOL.... I read this from digitalocean "Privacy Policy" Server Data *DigitalOcean does not have access to its users? server data. The backend is locked away from the users? support staff and only engineering staff has access to the physical servers where users? virtual machines reside. DigitalOcean does not store users? passwords or private SSH keys. DigitalOcean also does not request user login information to their servers. DigitalOcean does not review or audit any user data.* *https://www.digitalocean.com/legal/privacy/ <https://www.digitalocean.com/legal/privacy/>* <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:36 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:> On Sun, Jan 24, 2016 at 01:59:19PM +0300, Yazeed Fataar wrote: > > > So based of this , having your central tinc server in VPS Provider , will > > allow potentially the provider to replicate your config files and thus > > exposing all your remote sites connected. 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. > > Tinc can work with dynamic addresses as well, as long as you have one > node with a fixed domain name, that is fine. Maybe a dynamic DNS service > can work for you? > > > There was a option I was thinking of using is creating a encrypted > > partition that I will need to manually decrypt once the server is booted. > > This partition will contain the "/etc/tinc" directory. In this case the > if > > someone had to compromise my server they would first need to decrypt my > > encrypted partition. > > That is only the case when the server is down. If they compromise it > while it is running, you will already have unlocked the encrypted > partition and they can still read it. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <guus at tinc-vpn.org> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160124/ea12e838/attachment.html>
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>