Whatever you do, keep in mind that tinc will always trust all nodes as long as they are part of the graph. It is not currently designed to deal with insider threats. Most importantly, that means anyone can impersonate any Subnet on a tinc network, just by changing the Subnet declaration in their node file. The only way around that is to use StrictSubnets, but that requires every node to be statically configured with the subnet of every other node. On 4 May 2015 at 20:42, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote:> And we'll take a look at Pf & IPTables :) > > Good evening! > >>> There is no centralized way to remove a subnet or block a user. A user >>> is authorized to be on the network by other nodes that have his/her >>> public key. If you delete the offending host config files and let tinc >>> reload its configuration, you can remove a bad node from the network. >>> >>> If you have one or a few central nodes where all other nodes ConnectTo, >>> then it is easy to do. Another option is to use a tool like ChaosVPN to >>> centrally manage your tinc configuration and host config files. See: >>> >>> https://github.com/ryd/chaosvpn >>> >>> You can adapt it for your own VPN. Windows support is lacking though. >>> >>> >>> >>> _______________________________________________ >>> tinc mailing list >>> tinc at tinc-vpn.org >>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >>> >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
We started to take a look about that, and apparently, it seems that the IP in the public key is taken into account when a client connects to a gateway. Spoofing at that level doesn't seem easy, because the IP address seems to be part of the authentication process. Dealing with inside threats seems however a good feature for future versions ;) Le 04/05/2015 21:50, Etienne Dechamps a ?crit :> Whatever you do, keep in mind that tinc will always trust all nodes as > long as they are part of the graph. It is not currently designed to > deal with insider threats. Most importantly, that means anyone can > impersonate any Subnet on a tinc network, just by changing the Subnet > declaration in their node file. > > The only way around that is to use StrictSubnets, but that requires > every node to be statically configured with the subnet of every other > node.
On 4 May 2015 at 20:53, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote:> We started to take a look about that, and apparently, it seems that the IP > in the public key is taken into account when a client connects to a gateway. > Spoofing at that level doesn't seem easy, because the IP address seems to be > part of the authentication process.I'm having trouble understanding what you mean by "gateway", "authentication process" and "IP address" especially when you say it's part of the "public key" (it's not). Can you clarify? I am pretty sure tinc doesn't use IP addresses in any of its security mechanisms, except when StrictSubnets is enabled.> Dealing with inside threats seems however a good feature for future versionsAccording to http://tinc-vpn.org/goals/ it's planned for tinc 2.0, which AFAIK won't arrive anytime soon. I have some ideas about implementing some crude form of Subnet access controls for centralized graphs in tinc 1.1 - it would basically look like StrictSubnets, but more flexible - I have not started on that yet.> ;) > > > Le 04/05/2015 21:50, Etienne Dechamps a ?crit : >> >> Whatever you do, keep in mind that tinc will always trust all nodes as >> long as they are part of the graph. It is not currently designed to >> deal with insider threats. Most importantly, that means anyone can >> impersonate any Subnet on a tinc network, just by changing the Subnet >> declaration in their node file. >> >> The only way around that is to use StrictSubnets, but that requires >> every node to be statically configured with the subnet of every other >> node.