My setup: I have PC (“host”) with WindowsXP (+sp3), CIS (3.9.95478.509) and VMware workstation (6.5.2 b-156735). Inside of VMware I have 1 virtual machine (“guest”) with its virtual network set to “bridged” (using the same eth-adapter of host, with different IP). Guest is running nothing but WindowsXP+sp3, with only build-in “firewall”.
Now, to my big surprise, network traffic from this VMware virtual machine is NOT BEING FILTERED by CIS-firewall running on my host! No matter how I set up CIS-firewall, even with “block all mode” vmware guest is communicating with internet without any restriction. There is not even inbound/outbound connection in active connections list. Now how is THIS possible???
I have always thought CIS-firewall is so close to the network adapter that literaly nothing can pass by. Not even vmware-guest with bridged network adapter. Because the whole vmware (with its guests) is only just another application, running on host (main) system, and even all system services should be affected by CIS-firewall settings. To make problem even more serious, you even do not need admin rights to create vmware-guest! So a common user, with limited rights, can by-pass comodo-firewall just by creating vmware-guest with bridged network!!!
I’m having very similar setup on my linux-based server, with plenty of virtual servers, all with bridged network adapters (same network segment, just different IP’s) and the whole filtering including that for virtual guests is done by host. That is why I’d expect similar behaviour from CIS running on Windows-host…
So how is it possible, that CIS running on host (main) system does not filter communication of vmware-guests? Think about some malware acting like vmware-guest with bridged network, and the worst nightmare of any firewall administrator comes true: an application by-passing firewall, while even staying completely undetected in this activity!
It is likely the OP found out about the other VMware networking modes (there are three whereas the OP was seemingly focused only on a single one) or checked over Firewall Tasks > Advanced >Attack Detection Settings>Miscellaneous tab \ Monitor other NDIS protocols than TCP/IP.
BTW VMware is not really “just another application” like the OP was inclined to assume whereas it is a virtualization platform of many Mb that also leverage on drivers to root deep in the system.
Whereas even if someone could be inclined to assume that a malware would rely on similar drivers for malicious purposes, assuming also that these installation attempts will automatically bypass other layers of protections would be begging the question…
So what’s to prevent malware from just using the drivers vmware created? What’s to prevent malware in a virtual machine from wreaking havoc on the local network, or monitoring local traffic, or infecting the host machine? I’m getting the impression nothing is preventing it, especially not Comodo.
I’m trying to get to the bottom of this problem myself, and I’m quickly losing faith in Comodo’s ability to protect my system. I’ve tried the Monitor other NDIS protocols than TCP/IP as suggested previously and many other things only to have a virtual machine with a bridged network adapter just completely ignore Comodo and have full access to my network. It seems none of the traffic on the Bridged Adapter is being monitored in any manner by Comodo.
I am using version 3.10, maybe I should start a thread there? Before I get badgered with red herring suggestions, I’d like to ask - Is anyone able to block a vm with a bridged adapter or get its activity to show up in the Active Connections window at all?
Go to your network policy and select ADD, Select, Running Process, Chose Windows Operating system.
Now create rules that allow and or block what ever you wish your Bridged host is running on.
And see if it works, it does fine for me, i can block/log/allow traffic from and to my VM host.
Though it looks like you are determined to criticize CIS surely you can point out a reason a malware should be written to abuse something that can be unavailable on the user machine or are you assuming that VMware is bundled along said malware only to possibly prove your point?
If a malware bundle VMware the installation will trigger alerts obviously for the drivers as well…
As for a malware written to abuse something that cannot even be assumed to be generally available…
…are sure that red herring concerns would be appropriate?
I don’t understand why you feel the need to belittle my concern.
My point is not that malware would take advantage of vmware, but that a compromised guest operating system has unfettered access to the network, that no attack detection seems takes place, there is no way to monitor what connections are being made by the guest, there is no way to filter traffic by port or any rule whatsoever.
My question is simple - Has anyone been able to block a guest vm using bridged networking or been able to get it to appear in the Active Connections window?
Thank you. I did create a rule and moved it to the top of the list. Windows Operating System - Block and Log TCP or UDP In/Out from IP Any to IP Any Where Source Port Is Any and Destination Port Is Any.
I can still access this virtual machine from the network and the host, and nothing appears in the log. Although I tried allow all, and one single incoming item did appear in the log. In neither case did I see any of my connections in the Active Connections window. I am also trying this on a different machine altogether same results.
Can anyone else verify that they are able to block traffic for a VMware guest using bridged networking?
I can fully block outgoing traffic.
I did not use a Any rule though but set the IP from the Guest as Source in the rule
Block en Log
Dst = Any
IP = Any
Blocks all outgoing traffic from the VM.
One other thing, you can’t compare the VMWare install so easily with Malware.
If you install VMWare you are allowing the Bridging Service to install and Attach to the Network Adapter.
That’s the reason this service is installed and that’s also the reason CIS does not pick this up by default.
Now if malware try’s to do that you are not in “install mode” for the malware so CIS will alert you like hell if a service try’s to attach to you network adapter, so i wouldn’t be to worried about that.
Default CIS protection should alert for this kind of “hooks”.
This seems like a gaping security hole to me. What’s to stop malware from using this service? I’m obviously not the first person to stumble across this.
And without creating IP based rules, the guest OS seems to have unlimited network access. Something about that doesn’t seem correct.
surely you can point out a reason a malware should be written to abuse something that can be unavailable on the user machine
SQL isn’t available on every machine, but malware writers love to target that one. It seems silly to me to say that since not everyone has VMware, then it shouldn’t be protected. Besides, what about XP mode that might be included with Windows 7? Will that be as unsafe as WMware?
So is a hole a hole, or am I seeing a problem where none exists?
I don’t think malware can easily use the vmware bridging service, vmware protected that.
but i agree it would be nicer if it at least alerted for traffic initiated from these platforms also…
As far as i know that was the case in some previous versions like CFP 3.0.x and 3.5 but somewhere down the line they have changed firewall stuff for Vista and from that moment i needed extra rules to protect my VM.
Not that i ain’t running CIS in the gues OS’es where Windows is concerned that is.
But a agree to the fact that i would prefer CIS to “know” VMWare traffic, We could drop that on the wishlist tough maybe they’ll listen
I don’t think it’s a “big” hole though, D+ should be more than capable enough to prevent abuse of this.
In addition to the malware running it the hosted OS scenario, didn’t you ask what’s to prevent malware from just using the drivers vmware created ?
Then I guess the the misunderstanding should at least have been reciprocal as there was no belittling in pointing out what could be cause of unwarranted concerns.