On Saturday, January 27, 2018 at 3:45:28 PM UTC+1, Yoganandam Marava wrote: > by adding forward rules at sysfirewall we can ping each other VM through ip > address but not using VM name. > Is this some thing possible with Qubes 4? I am naive in networking.please > suggest if there is a way? > > Thanks
As far as I can tell, it's pretty much the exact same thing in Qubes 4. Although I did not verify it, but it looks like it works the same way in Qubes 4. I did not quite follow what you meant by using the VM name in the Qubes internal networking. Are you not referring to the various Qubes-core-agent-* tools here? Like sending files between VM's? Sending files between VM's by a VM's name is not networking however. Rather it's a process that happens in dom0 outside the VM's, transfering the files between the VM's .img files without allowing any moved content to touch dom0 (roughly said). I assume this is the kind of process you meant by "name"? Generally you'd need something like a DNS server between the networked VM's in Qubes if you want to replace IP's with names. But I don't think this was ever included in Qubes by default or encouraged by the developers? By default Qubes discourages any kind of inter-VM networking. Even the Qubes tools are not using networking, they're services executed outside the VM's reach, which include any kind of networking. As for the inter-VM networking concept itself, you may want to create a separate "network" for any VM's you allow to talk together though, and a separate firewall VM for it too. At least in PV virtualization mode sophisticated attacks are possible if attacking while two or more VM's running at the same time, which becomes more easy if they are networked together. But now on HVM/PVH modes, I'm not sure if this particular kind of attack is possible, probably not, but it's advanced stuff. Some of these kind of attacks have not even been observed in the "wilds" but have been deemed "possible" through research. But maybe there are other attack vectors that discourage networked VM's to talk to each others. For example any attacker may more easily gain access to other VM's after having successfully exploited a protocol through the firewall-port, of the many or few internet services going through. Here it may not be desirable to make it easier for any attacker, although disallowing network between VM's probably doesn't make you immune to get attacked in other VM's, but at the very least it minimizes possible attack vectors. It's also important that both VM's have proper secured firewalls in place between them. So by that logic, it may be desirable to create a separate network/firewall for any VM's that talk to each others, and consider possible attacks to be an increased attack vector for any VM's you added to this parallel Qubes inter-VM network. However someone more knowledgeable should probably confirm first if this is something useful, redundant or pointless, or perhaps downright dangerous to do. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6d0c76f5-9b97-4def-a498-7f9092ab4b3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
