Say I would like to play with Vulnhubs test machines.
So in VirtualBox I have A.IPFireMachine (to protect host), B.LinuxKaliMachine (to use for testing) and C.TestMachine (to test stuff on).
They are connected with a virtual Internal-Network that is not same as host LAN, they can only see each other.
A.IPFireMachine is connected to the virtual Internal-Network with interface Green/DMZ (I do not know if one is safer than the other).
A.IPFireMachine interface Red is connected to Internet with a second virtual adapter via VirtualBox Bridge/NAT via host LAN via “real” un-virtual IPFire. This adapter I can turn off when C.TestMachine is on. And can turn on if needed, like when B.LinuxKaliMachine need updates.
Will IPFire add any more security in this setup? Or will this only feel safer as I have the word IPFire here? Could C.TestMachine still reach the LAN of the host via A.IPFireMachine if I forgett to turn off the virtual Red adapter?
I have probably expressed myself badly, my mother tongue is not English. I try again
I was wondering if a firewall in the virtual environment (A in picture) is able to protect the real computer (Host PC) running the virtual system and the LAN devices in LAN environment from the evil Test Machine (C in picture).
As B and C are connected to Virtual IPFire Green or Orange interface, I do understand that the firewall is “open” like it say in the Wiki.
But some firewalls do NOT forward IP addresses registered by the Internet Assigned Numbers Authority (IANA) as a part of private network to the Red interface. Example like IP numbers 172.30.16.0/24 and 192.168.10.0/24 in the picture.
So if C.TestMachine (or compromised B.LinuxKaliMachine) tries to attack 192.168.10.130 or other LAN devices in 192.168.10.0/24, maybe IPFire will never forward those packets to virtual Red, eg. the LAN? Or will the virtual IPFire A not help at all?
When I activate the Firewall Drop Rule for 192.168.10.0/24 above
I can with virtual B.LinuxKali only connect to Internet, to the virtual A.IPFireMachine and the “real” un-virtual IPFire.
But I can not connect or ping to any other device on 192.168.10.0/24.
If I deactivate the block rule, I can also connect and ping all devices on 192.168.10.0/24.
So to my untrained eyes, it looks like IPFire with the rules above is protecting all devices on 192.168.10.0/24, except the real IPFire, from B.LinuxKali. What am I missing? Is there a way around this from the virtual environment?
Do you mean the sentence “Since resources are being shared between different virtual machines, it is easily possible to break out of one of them into the firewall through the host system”?
If yes, that is an other discussion about “virtual machine escape” vulnerabilities in virtualization products. It is of course the other part of securing the host system, keeping up with new exploits in virtualization products and keeping it patched and avoiding settings that are more easy to exploit. There are also several other ways to try to keep the host secure from malicious virtual machines, like using cascaded hosts with different visualizers. I can also add that here VirtualBox is just an example I am using now to try things easily on the same PC that I use for writing in this forum, I will not use it in the real lab as I will use QEMU (or maybe Xen if I get my new computer in time).
Here I am asking if the virtual IPFire can stop B.LinuxKali reach host LAN with network traffic in the network diagram above, if we assume B.LinuxKali do not use the virtualization products unpached vulnerabilities.
My answer to this would be “probably ,yes it can stop it”.
The reason for the “probably” is that your firewall rule is telling the virtual IPFire to send the communication to the real IPFire and not go to any of the pc’s on the real lan. So a bad actor that has taken over your B pc would not be able to send bits directly to the real lan but that does not mean that he could not write or find software that could do it because once the communication has left the virtual IPFire it is being routed over the 192.168.10.0/24 subnet to the real IPFire. I am not aware of any capability to break out of routing across a subnet but that does not mean it can’t be done.
However a year and a half ago I would have said that being able to bypass your firewall entirely by sending a few bits in a special way was not something I knew of and would have thought it unlikely but then we all heard about NAT Slipstreaming.
I would think that the probability of B or C on your virtual network getting into the real lan, with the right firewall rules would be very low. It would also depend on the likely chance of a bad actor being able to get access to your B or C computers. If they could do that then I would think that your real LAN would also be at risk from the same attacks.
You could separate the real lan and the virtual lan by connecting the Host PC to a dmz Orange zone on your real IPFire but I suspect that you will say that you need to access the real lan with the Host PC.
I just had a thought. If none of your pcs on the virtual lan ever need to access the real lan then you could look at setting up a net to net VPN between the two IPFire orange zones and then block all green outgoing on the virtual lan and only use the vpn and on the real lan have firewall rules that only allow the orange vpn to access the red zone for the internet. Not sure how easy that would be to set up but that would then separate traffic from the virtual lan from the real lan.
