Simple svchost.exe question

Help for v2
#1

Hi, quick question regarding svchost.exe,

I have some application rules set up for svchost for DHCP and DNS. One of these is UDP In, Port 68 for the DHCP. I do not have any network rules set up to ALLOW inbound traffic. All I have is:

All TCP/UDP Out Any/Any
Block IP In/Out Any/Any

So I guess my question is how is getting svchost able to make the inbound connection to UDP 68 with no network rules allowing?

Thanks
Revolute

#2

Hiya,
CPF’s installation default is to “Do not display alerts about Comodo known software” or something to that effect. I only shows the rules you’ve set to allow when CPF has asked you for permission to confirm. Most likely these rules will have been created straight after installing CPF before “Scanning For known applications” because the default is to not show alerts by Comodo Known Programs those items won’t show up in your application monitor. This can be changed by going to Security>>>Advanced>>>Miscellaneous and unchecking the option.

Hope this helps but basically it’s not showing the rules in the Application Monitor because Svchost is a KNOWN program by CPF and it will automatically set rules for it’s inbound communication just won’t display them in the Application Monitor…

Eric

#3

Hi, thanks for the reply,

This is my options page:

So now I’m wondering if Comodo is making the exception for the inbound UDP automatically?

Edit: Here are my svchost rules:

#4

Hiya, that is more than likely the case as it’s a Comodo Known Progra. It probably will have been the one of the first rules it created. Comodo will automatically do the rules for all the softward in it’s database to reduce pop-ups etc… No need to worry about it. I cpf will have automatically created an inbound rule at some point during installation.

That’s as far as my technical knowledge goes when it comes to CPFs automatic rules…

Hope that was helpful…

Eric

#5

Hi Revolute

I’m slightly curious about this issue. Would it be possible for you post your complete NM and AM rules?

Thanks

Toggie

#6

Hi,

Here are my complete rules:

I am a bit confused about this now, as previously I thought anything I set to allow inbound connections in application rules would be allowed through as exceptions to whatever the network rules were.

I noticed this not to be true yesterday when I had to set up a network rule to allow inbound VNC server connections.

Hope you know what I mean by that.

Thanks
Revolute

#7

I also would like to know. NM rules should have the final decision regardless of AM rules; it acts like a router.

#8

Do you reckon the inbound UDP svchost for DHCP rule is being allowed as it is contacting the router for an IP before Windows login? Would that be allowed?

Also I am not having any connectivity issues, my DHCP lease never drops.

EDIT:

Here is a funny thing. If I remove the UDP inbound rule for svchost, I can still renew my IP. Here is the screenshot showing the svchost connection. Even after a reboot I can get an IP, with just the 2 previous svchost rules.

:S

#9

Hi again, sorry for the double post,

I have come to conclusion I don’t need the inbound UDP rule on my network, which is wireless by the way.

I will enable logging and check to see if the router is attempting inbound UDP at all during DHCP session.

#10

Revolute

Do you reckon the inbound UDP svchost for DHCP rule is being allowed as it is contacting the router for an IP before Windows login? Would that be allowed?

I believe this is exactly what’s happening. DHCP Lease Acquisition happens very early in the boot process, in fact it’s one of the first things that happens after the TCP/IP stack is loaded.

One thing, although you may not need rules in CFP for initial acquisition, you may need to cater for lease renewals.

Toggie

#11

Thanks for that, I’ve not had any inbound connection denied logs for a few hours now and the connection is ok, I noticed my lease expiration is in 38 years though so maybe thats why heh.

I get some connection inbounds for other IP’s on the lan, udp port 68, but I think thats something else as the source IP isn’t mine.

Thanks again.
Revolute

#12

DHCP uses two ports for communication:

client port 67 ------------request--------->server port 68
client port 68 <-----------response---------server port 67

The IP address you are seeing, is probably that of the DHCP server.

#13

No it’s not that, the source is 192.168.2.5 and destination is 255.255.255.255. I am 192.168.2.2.

#14

The initial request for an IP Address via DHCP is a Broadcast, as the client doesn’t yet know the IP address or the host name of the DHCP server. A network broadcast address is 255.255.255.255. So you client is trying to find a DHCP server somewhere on your network.

After a lease is given to a client, the client will periodically try to renew the address. However, the client now knows the IP address of the server and can communicate directly.

#15

Yeah, I know that. The 192.168.2.5 address though was from another machine on my LAN, I could see the DHCP request it was making.

Anyway moving on, what exact rule do I need to create for svchost to allow the incoming DHCP and the network rule so I dont get any disconnects in the future (sorry, been a long day, hope you understood the question ok)

Thanks
Revolute

#16

My NM rule is:

Allow & Log
UDP OUT
From IP = ANY
To IP 255.255.255.255
Source Port = 68
Destination Port = 67

AM rules are:

Svchost.exe
Destination = ANY
Port = 68
UDP IN
Allow

svchost.exe
Destination = 255.255.255.255
Port = 67
UDP OUT

I receive no additional prompts.

Hope this helps
Allow