Blocking port 135

Shouldn’t network monitor block any incoming requests by default? There are no rules allowing port 135 so it shouldn’t have reached application rules. That is my understanding of how the firewall works. Maybe I’ll create a network rule (similar to the application rule) and see if that gets logged as a network rule. Thanks for your help with this, appreciated.

:slight_smile:

Correct. Network monitor wont pass any packets directed to port 135 unless explcitly stated. If Create an alert… option is enabled for BLOCK IP … rule, it will show blocked attempts.

To block RPC(135), you dont have to add anything to default setup. It will always block.
svchost.exe can try to act as a server but this doe not mean any packet is received. Such packets first pass network monitor anaylysis before being allowed.

Am I right is saying that this option isn’t set as default then? Regarding the network monitor section, I haven’t changed anything.

To block RPC(135), you dont have to add anything to default setup. It will always block. svchost.exe can try to act as a server but this doe not mean any packet is received. Such packets first pass network monitor anaylysis before being allowed.

It would seem that the last rule (block and alert) is passing this connection through to application rules (using the default setup).

:slight_smile:

No. With default settings CPF will not allow incoming RPC connections. If you dont see anything blocked by network monitor in the logs, this may be because there is no connection attempts.

It would seem that the last rule (block and alert) is passing this connection through to application rules (using the default setup).

svchost.exe acting as a server on port 135, does not mean you received something. It means, svchost.exe is getting ready to receive connections on port 135 if it receives. Since network monitor will not pass anything, i wont receive any packets. So even if you give full access rights to svchost.exe, network monitor wont allow it to receive any packets.

If I delete the application rule denying access, then I will be prompted for the connection again.

svchost.exe acting as a server on port 135, does not mean you received something. It means, svchost.exe is getting ready to receive connections on port 135 if it receives. Since network monitor will not pass anything, i wont receive any packets. So even if you give full access rights to svchost.exe, network monitor wont allow it to receive any packets.

If I’m receiving an alert (application rule), doesn’t that mean that something is trying to connect to this port. The odd thing is that my hardware firewall/router should be denying such connections before reaching CPF ???.

:slight_smile:

let me try this again…

if you didn’t have an App rule for svchost.exe,
you would get a pop-up alert because svchost.exe wants (even needs) to start listening to the internet

this does not mean a packet has broken through the network rules and got to the application - this simply means that svchost.exe has made an operating system call to PREPARE to listen for whatever incoming packets it might expect to receive in future

remember that this will be of no use to svchost.exe, since you have DEFAULT network rules which will NOT ALLOW any such packets into the TCP/IP stack of your computer - if any outside system had tried to connect to svchost.exe on a port, you would see a log entry about the last network rule (but you haven’t seen any such entry, so nothing is trying to connect) - nothing is violating your network rules - because no packets have arrived

to specifically answer your question “If I’m receiving an alert (application rule), doesn’t that mean that something is trying to connect to this port” - then YES, BUT NOT “something” from outside your PC - just svchost.exe - your network rules (and indeed your external router) will definitely prevent ANY external entity from sending a packet through

OK, I think I get what your saying :). So if this is the case, I should expect an alert for port 445 too or any other listening ports on my system. I still find this way of working very confusing compared to say Kerio. I guess once I fully understand how everything works, I’ll see the clearer picture. Thank for your patience magic144 (and egemen).

:slight_smile:

if there’s a process on your system
and it is trying to attempt to listen to a port (any port)
and you haven’t explicitly granted that process the necessary “IN” access rule (TCP and/or UDP)
(and you’ve not told COMODO to “not show any alerts for the applications certified by COMODO”)

then you can indeed expect a popup when that application tries to start listening for potential future incoming traffic (or “act as a server” if you prefer that terminology)

remember - this doesn’t mean traffic is arriving, nor does it mean traffic may ever be allowed to arrive because of your separate network rules

hope this has helped

Thanks magic144, I understand now ;D.

:slight_smile: