I have been trying to tighten up the policy for svchost.exe and so I applied a rule to block and log any connection attempts that were not in a specified set of addresses. Today, there was a connection that did not fall in the range of allowed addresses. It was not blocked and there was no log of the event. The address belongs to Level3 communications, so it is not hostile, but I want control of such connections, or at least notification of them. Has this been observed by anyone else? BTW, it would help the observation of these events if there were a log of all connections, preferably sortable by address.
Can you tell us a little more about the connection. Was it UDP or TCP and to what port, outbound or inbound.
It was outbound and I believe that it was TCP and port 80. The last two are not reliable because I had to write fast to just get the IP recorded. I think that I know what the problem is - I had set Microsoft as a trusted vendor. I had thought that that applied to the Defense+ permissions, but maybe it allows connections to the internet also? I would think that the policy for an application would over-ride any connection permission from the “trusted vendor” designation.
PS Is this in the right forum? I don’t have the CIS installed, just the firewall/defense+.
What do your rules actually look like? The connection you list is an http connection to a web server port. How did you block the addresses-by URL or IP. Sometimes a single URL connects to several IPs, and SPI rules may apply? Trusted vendor shouldn’t affect internet connections. Can’t help with logging; it is long on the Comodo wishlist but apparently very low priority.
I just reviewed the rules and there was no rule that allowed ANY connection outside my LAN and a set of multicasting IP’s. The first rule allows IP connection (any protocol) in/out between a set of addresses that includes only my local address range and a set of multicasting IP addresses (239.0.0.0-239.255.255.255 and 224.0.0.0 - 224.0.0.255) and 0.0.0.0 and 255.255.255.255). The target and destination range is the same for both. I then have a rule that does not work that allows ICMP out (any) from (Any) to my LAN range. I still get a failure to connect to 192.168.1.254 at bootup every time. This rule should be unnecessary since the first rule should allow this connection. It was added to try to fix the connect problem, but it did not work. Then I had a rule that went:
Block (log) TCP/UDP out from Any to (Svchost) - this is a set of IP’s that I have logged as normal scvhost.exe connections. Then there was a Block (log) IP any any any. As far as I can see, there should be no connections happening outside my LAN and a few multicasting IP’s. So I have no connection to my router and regular connections to a range of Level3 and Microsoft addresses, despite rules that should allow the first and prevent the second. This does not prevent anything from working, it just bothers me.
Are these all global rules? You might do better splitting the in/out rules into separate in and out to avoid source/destination confusion. Your (svchost) IPs are all WAN (internet) addresses? Do you have a copy of a screen capture utility like hypersnap or snagit? There are also free programs if you search with Google. It is usually much easier to diagnose these issues if we see the actual rules and their order.
You still need to define a network zone.
In my setup I start with svhost as outgoing only. Then I defined a multicast zone and a network zone.
Multicast zone:
224.0.0.0 - 224.0.0.255
229.0.0.0 - 229.255.255.255
Network zone:
192.168.1.70 (network mask: 255.255.255.0)
0.0.0.0.0
255.255.255.255.255
Then I used the stealthport wizzard to add the zones to the general rules.
Yes, when I say “my LAN” it refers to the LAN range: 192.168.1.0-192.168.1.255. These rules are not global. It was simpler in my mind to have communications allowed back and forth between my LAN and the multicasting IP addresses. The rule allows out from my LAN to my LAN (printer, router and modem) and to the multicasting addresses. It also allows incoming data from my LAN and multicasting addresses. One rule does it without any hazards for this set of addresses.
I’m afraid that a screen shot will not tell you much since I am using “Network Zones” to define the rules, so all you will see is the names of those zones. I’ll try to re-phrase the rules:
Allow; IP; in/out; from and to - (LAN and local and special multicasting - addresses as in the previous post and above); Any (protocol)
Allow; ICMP; In/Out; from LAN; to LAN; Any
Allow; IP; Out; from Any; to (Svchost addresses); Any (protocol)
Block and log: IP; In/Out; from Any; to Any; Any (protocol)
I’m not worried about the first rule - it seems to work fine. What I am worried about is the continuing block on attempts to connect to 192.168.1.254 which seems to me to be allowed twice over here and the recent connection to an address that was not on the list of Svchost addresses.
The blocked connection reads as follows in the event log:
Blocked; ICMP; 192.168.1.2; Type ( 8 ); 192.168.1.254; Type ( 0 )
I have not found any reference to what the “Type ( 8 )” source port refers to, but I would guess that it refers to the ICMP message being blocked.
My only guess is that svchost is using permissions derived from a parent program that is using Svchost.exe to connect. Can you confirm this?
The log function seems to work randomly. I have put “log” on all my svchost.exe rules allowing connections and I have just watched a svchost connection run and not get logged (I did use the “Refresh” button just in case). The destination address was possibly the problem - 255.255.255.255 - but that address is included in one of the rules and the log function should presumably catch it. I begin to wonder if any of the allowed connections that I want to control are even being logged. I found them by watching the “Active Connections” page and I did not have the log checkbox ticked back then.
I just got another connection from Svchost.exe that was not on its allowed list. It was not logged either. The normal LAN connections are also not being logged. This strikes me as being a serious flaw unless there is some rule over-riding my set of rules for svchost.exe that I don’t know about. Does anyone have any ideas about the problem??
For reference, the “Log as a firewall event if this rule is fired” is checked for every rule for Svchost.exe and the “Disable Logging” box under the Miscellaneous>Settings>Logging tab is not checked.
I hope referring to the forum of another firewall won’t get me banned…
As a former Outpost user, I’d recommend reading the Outpost Secure Configuration that can be found at the Outpost user forum:
http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=9858
It describes recommended rules for various system files, including the notorious SVCHOST.EXE. I put it to good use tightening up CIS…
edit: Nope, nothing wrong with that. URL made click-able by Mod.
Thanks Passerby, but the rules there are based on a fairly different program design. For instance, DNS resolution on my system is done by the router (192.168.1.254) which has a set of DNS server addresses that it uses for DNS requests. There should be no possibility of spoofed DNS requests going to any other servers. The rules for blocking uPNP and a couple of other Microsoft “features” that leave security holes are nice, but it does not address the question of connections that do not fit in the list of allowed connections which are allowed and not even logged. If I had to guess, I would say that the problem results from a DNS request that is resolved and transferred to an address outside the allowed address set. It is not possible from the information in the “active connections” window to determine the initiating program for such requests and the lack of logs (despite the checking of all the “log” boxes) makes me crazy. There isn’t even a log of the DNS request. It would also account for the regular blocked pair of connections. Presumabaly there is a program that has not got the necessary DNS request or Loopback connection request permission in the Defense+ section and that is logged in the svchost denied connections. Has anyone got some insight about this?
Have you tried one for in rules and another one for out rules for some reason in/out rules do not work as the should I have been told this numerous times in the past with different firewalls please try this.
For some reason CIS/CPF3 will not log all rules I had two rules for Outlook Express one for UDP and one for TCP if I tick both only one is logged even though I can see both connections this worked fine for Kerio but will not for Comodo.
Dennis
I will try that, but the only in/out rule is for my LAN and multicasting addresses and that has not caused any problems - although I think that it is not being logged either.
Another unlogged connection to an IP address not on the allowed list. This one was another Level3 IP address, so no tears, but really, there seems to be a hole here. Details: Svchost from port 1043 from 192.168.1.2 to 192.221.123.123 port 80 TCP protocol. See the SC of the rules below. You can see from the second SC that there is no entry for 192.221.123.123 in Svchost IPs. Network Defense is in Custom Policy mode and Defense+ is in Safe mode. Microsoft is not a trusted vendor for Defense+ and Logging is not disabled under Miscellaneous>Settings>Logging.
[attachment deleted by admin]
It is not possible from the information in the "active connections" window to determine the initiating program for such requestsOne thing that the Outpost document I referenced recommends is to disable the DNS Client system service in Wndows XP, forcing applications to request connections in their own name instead of relying e.g. on SVCHOST to do it on their behalf. This requires separate DNS rules to be created for each application you want to allow, but gives total control over which program is allowed to connect. Also, this way the initiating program would be forced to "come out of hiding."
Hmmm… Thanks for that! I was wondering if there wasn’t a way to avoid the use of Svchost for DNS resolution. That might just solve the problem.
I’m having an issue with svchost.exe that I haven’t been able to figure out. Every so often Comodo logs 6 times that it has blocked an incoming UDP connection from the same source IP and both the source and destination ports are 500. I have it set to Outgoing Only. It’s only started doing this in the past couple days. Does anybody know what would be causing this?
AnotherOne,
Have you managed to resolve the svchost issue?
I think so. I had a report of stray connections, but it only happened after a system glitch which seemed to disable CIS temporarily. When things are normal, I have not seen any disallowed connections, but I am still monitoring it since some connections happen at long intervals. I have had to edit several applications’ rules to allow connection to the router over port 53, but that shows up on the logs when an app needs DNS services and is disallowed. So far it seems like a success!