I’ve always blocked port 135 (incoming) when using other firewalls so when prompted for this connection, I denied as usual (as an application monitor rule). How come the network monitor section didn’t deny access as I would have thought the last rule (block IP) would have done this and reported in the logs. I thought that all inbound access (apart from icmp) were denied.
where was the packet coming from?
what app was asking about the connection?
what network rules do you have?
I would have thought that the “Block IP” rule would have caught this before reaching application rules.
out of interest, under Advanced.Miscellaneous
do you have “Do not show any alerts for the apps certified by COMODO” ticked?
(this can mask a few issues)
it would be more useful if you could post the actual alert you saw on the screen
and are you using the latest beta? i.e. 2.3.3.33
could it be that something “SAFE” has already been allowed to establish an outbound connection via this port? I’m not a Comodo expert, I’m just waiting for the experts to chime in here!!
Sorry, forgot to mention that I was using 2.3.3.33 (beta). I have setup CPF so that I am prompted for every connection. I’m at work at the moment but I’ll post a screenshot when I get back home later. Btw, thanks for your help with this.
Thanks for the links TheTOM_SK :). I’m a bit reluctant to use any software that disables port 135. I used DCOMBobulator (GRC) previously but had a few problems with it 
(maybe I was unlucky).
It isn’t that CPF is not doing it’s job (the connection is being denied), it’s just that I would expect it to get blocked at the first level (network) instead of second (application).
yep - that’s what I’d like to know too!
Hi,
You dont need to worry about incoming RPC(135) packets. Because if there are packets, assuming the default rules, CPF will block them. Your case should be the following:
1- CPF sees System trying to act as a server on port 135,
2- CPF sees “Do not show alerts for the applications certified by comodo” option enabled and allows Sytem process
3- CPF does not see any incoming packets to port 135 so there is nothing to block
Note that, acting as a server has no effect unless you create an explicit network monitor rule to allow such traffic.
Hope this helps,
egemen
I have “Do not show any alerts for the applications certified by COMODO” unchecked. All other options are unchecked apart from “enable alerts” and “protect own registry keys…”. Alert frequency level is set to very high.
My log shows the follows:-
Application Monitor, Application Access Denied (svchost.exe:0.0.0.0:ms-rpc(135))
any ideas why this alert is cropping up guys?
when you click on the entry in the log, what are the log’s details (bottom window pane)?
i.e. what is the app/parent/protocol, etc…
At work at the moment, so can’t give the exact details (will later) :). The app is svchost.exe and the connection is tcp. There isn’t a parent application as the connection is inbound. I used to get alot of these connection attempts when I was connected directly to the internet (going through a hardware firewall/router now). Have only started seeing these again since using CPF.
I can only assume you have an application rule which is blocking svchost.exe In access at some level, but if you post the whole log entry tonight, it should become clearer…
check your Application Monitor applications list and see if svchost.exe is in there…
btw, this doesn’t mean any packets are being allowed in,
it presumable just means that the app has tried to listen to a socket with a listen() or subsequent accept() call…
I do have an application rule setup to deny inbound access to port 135 so CPF is doing it’s job by blocking (just at a later stage). Why isn’t the last network rule (block all) picking this up? The details of my log are as follows:-
Description: Application Access Denied (svchost.exe:0.0.0.0:ms-rpc(135))
Application C:\WINDOWS\System32\svchost.exe
Parent: C:\WINDOWS\System32\services.exe
Protocol: TCP In
Remote: 0.0.0.0:ms-rpc(135)
This is tough to say although getting hits on this port is far from unusual , but DCOM will use 135 and if you have it, you will need to disable it which may still not work. 135 can be forced open by other apps also and blocking the port completely is the only way to insure nothing comes through. 135 has many issues as you probably know but some applications may use this to piggyback to access info. As it was stated, it doesn’t mean it’s allowed, Comodo may just be blocking it and letting you know. Even if I set mine to no popups, it still tells me new ones, it just won’t show me the same ones over and over. For the most part, I think it’s fine. Some ISPs , nat, etc…will block this port automatically as well but when running a log it will still show attempted accesses depending what you have.
Cheers,
Paul
CPF is denying the connection due to an application rule that I put in place but I’m just curious as to why this connection isn’t being blocked by the network monitor ???. I thought this would block everything inbound except for the additional (icmp) rules above.
Graham1,
like I said,
I DON’T believe that this pop-up means a packet has hit your application…
it is my opinion/belief that this APPLICATION rule has been triggered because svchost.exe has attempted to bind to a port and attempted to listen for inbound packets - and since you have an explicit rule saying svchost.exe is NOT allowed to attempt such activity, a notification has been fired off
since no network alarm-bells have been ringing, I don’t believe any packets have arrived, otherwise you would certainly have a network log
I leave it to egemem or a.n.other Comodo honcho to confirm or deny this conjecture
m
ps - by extension, if you didn’t have this application rule for svchost.exe, you wouldn’t get this popup message
BUT you could still sleep at night because nothing is allowed through port 135 by virtue of your network rules
another question for you:- how restrictive is your rule on svchost.exe? what options are configured in your rule?
svchost.exe is used by more than just DCOM on port135
in fact svchost.exe is used by a range of normal/safe/useful OS functions, and if you have restricted it too much, you may well break something else you’ve yet to uncover… if I’m not mistaken, for instance, svchost.exe is used in BITS background downloading of Windows automatic updates for one thing
It’s like magic said and is very clear. The only other thing I can think of is that it the port wasn’t being blocked by the network monitor if you have allowed RPC on the network as it can and will use 135 so if you do, it won’t be blocked automatically since it was an allowed port already. Do you use RPC? As magic said, i’ll also leave this to someone else. I would also assume you run XP?
Paul
I can understand that but my understanding of this firewall is that (regarding inbound connections), network rules are action first with application rules second. By default, all inbound connection are denied by default, unless a rule is added above the “block all” rule (network monitor). Of course, any outbound connections are allowed back in but in this case it is just an incoming connection. Why wasn’t the “block and alert” rule fired off?
since no network alarm-bells have been ringing, I don't believe any packets have arrived, otherwise you would certainly have a network log
Unless port 135 is allowed in by default (as a hidden rule), it should never have reached application rules.
ps - by extension, if you didn't have this application rule for svchost.exe, you wouldn't get this popup message
I wouldn’t get the log entry but I would still be prompted for this connection.
another question for you:- how restrictive is your rule on svchost.exe? what options are configured in your rule?
I only block port 135 (for any application). I started doing this after seeing a ton of entries in my Kerio log.
Many thanks for your help with this ;D.
