I was administrating a family member’s PC (running XP) today, which I recently installed Comodo Firewall on (Defense+ and Sandbox disabled) and found it was blocking various programs (Flash updater, Virtualbox update checker) even though there were no rules to do so. It was on Custom Policy mode, so should have been producing alerts for any programs without rules, but it wasn’t and I’ve had to deactivate it for now until I can find out why it’s not working.
Has this come up before? If not, please advise what logs I can provide that might help someone diagnose the problem. It is a two-user PC and often both users are logged in at the same time, but only one user was logged on when I was testing. I saw in the Firewall Events logs that svchost to various IP address on port 443 was being blocked, despite the only svchost rule Allowing All on LAN and then blocking incoming on port 3389 (to prevent external RDP access). If user 2 had created some blocking rules, would they apply to user 1 but not show up in his rule list?
It may be easier if you could post screen shots of your firewall application rules and any firewall logs. Out of interest, what happens if you manually check for updates in Virtualbox?
Home #1 contains 192.168.11.2:255.255.255.0 and 127.0.0.1:255.0.0.0. There doesn’t appear to be any rules that would explain what’s happening. I tried switching to the second user and checking the rules under that account, but they looked the same to me, so that rules out the idea that the second user might have created blocking rules that were affecting user 1.
There’s nothing obvious in the rules, however, I notice you’re using Avira, which, if remember, uses a web proxy for all HTTP traffic. As Virtualbox and Flash use standard HTTP ports for updates, it may be worth disabling Avira temporally, whilst you try another manual update.
Failing that, manually create a rule, with logging, for virtualbox.exe and run the update again, see what entries are generated in the firewall log.
It might be that other versions of Avira use a Web Proxy, but we’re only using Antivir Free here which doesn’t appear to. I use it on my own system with Comodo without any problems anyway.
I will try what you suggest and get back to you, thanks.
As I mentioned, looking at the logs I could see svchost outgoing to port 443 was being blocked, which might explain the problem if those programs are trying to update using that port. I can’t see any rule that would account for this blocking however.
Can you write down here the complete rule for svchost.exe you made describing both the Allow Lan and the Block RDP Internet rules it is made of?
Is the traffic on port 443 by svchost.exe outgoing traffic? I assume it is but I don’t recall seeing it mentioned.
If during the Window session an alert would have occurred that was not answered then that action would have been blocked. It would show up in the logs. And if the computer is switched on for long stretches of time one might miss it in the logs.
Another thing to consider is that CIS does not always seem to work well with fast user switch. Logging off and logging in as a different user is known to work.
Yeah, I’m pretty sure it was outgoing traffic on port 443 with svchost.exe that was blocked.
I’ll double-check but as I recall the svchost ruleset was basically:
Allow LAN = Allow all from Zone: Home #1 to Zone: Home #1
Block RDP - Block all on port 3389
It could well be that an alert was not answered earlier in the day before I got on the PC and as a result that action was blocked without any rule. I’ll double-check by rebooting next time, which I presume will reset this.
Perhaps fast-user switching was involved as well. I’m planning to prevent cfp.exe loading when user 2 logs in anyway, so it will only load for user 1 and he will have to deal with any alerts for both users. It’s a two user household, where generally user 2 logs on to their account over RDP from their own terminal but sometimes uses the main PC and fast-user switching if they can’t be bothered to boot their terminal, but hopefully preventing cfp.exe loading for user 2 will avoid fast-user switching causing any problems.
If svchost is being blocked, then it probably is due to switching users. In your rules you have ‘Windows System Applications’ above your custom svchost rule. The Windows System Applications includes svchost and some other system services and the rule allows all outbound connections. In reality, the only part of your custom svchost rule that may be doing anything is the RDP section.
I recall I had to add the svchost allow rule because RDP from the other terminal wasn’t working. I’m pretty sure the Windows System Applications rules were already present but I still had to add it.
I’ll try removing it and see if RDP still works though.
I’m not sure how that would help? It’s only allowing incoming traffic on the LAN (to allow RDP to work) and blocking external access to port 3389 so surely it doesn’t matter whether it’s above or below.
What does your rules for svchost.exe look like when written in the following format:
Until I can double-check, from memory the Allow LAN rule was:
Action: Allow
Protocol: IP
Direction: In/Out
Source Zone: Home #1
Destination Zone Home #1
Whilst the Block RDP one was:
Action: Block
Protocol: TCP or UDP
Direction: In
Source Address Any
Destination Zone: Home #1
Source Port: Any
Destination Port: 3389
OK, I got on the machine today and tried updating Virtualbox and it popped up a request, so it seems to be OK now. Maybe there was a missed request that was blocking it and rebooting reset it.
I’ve also set it so that cfp.exe only loads for user1 now to avoid any issues with it loading for both users.
