Allowing incomming connection on port, only when program listening


I’ve read that when opening a port for incomming connections in comodo, it will only allow the connections when a program is listening on that port.
But if I create a rule to allow incomming connection on a port with no listening program, and tell comodo to log it, I see “Access Granted” on that port in the log, when trying to connect to it. Though when making a Shields Up! test, it shows Stealth.
What is going on?
Is the port open or not? ???


Can you explain more about what you are doing here?

If I understand correctly, you have created in Network Monitor a specific Allow In on Port rule, but you do not have an application (to your knowledge) using that port. You set the rule to log, and are somehow attempting to “connect to it.” What are you doing to “connect” here? What application, steps you are taking, etc?

Can you also post the relevant entries from your log, that show this access granted?



I use a port for my apache server, fx 1234.
I create a rule, allowing in/out connection TCP/UDP from any adress to my adress at port 1234.
I make a scan on Shields UP! - it says Stealh. - But for every attempt from shields Up! to connect to the port, I get this in the log of comodo:

Severity :Low Reporter :Network Monitor Description: Information (Access Granted, IP = *SHIELDSUP IP*, Port = 1234) Protocol: TCP Incoming Source: *SHIELDSUP IP*:64126 Destination: *MY LOCAL IP*:1234 TCP Flags: SYN Reason: Network Control Rule ID = *ID OF THE RULE JUST CREATED*

Trying to access the apache server from the browser gives no result (except of another post in the log)
Then I start my Apache server, and now I can access the Apache server from the browser.
The same log post is visible, and now Shields UP! says Open!

To shields Up! it seems the port is stealth when nothing is listening on that port, but why does comodo says access granted no matter what?

I’m not sure, to be honest. AFAIK, you should still get a blocked response. Let me see if I can get a better answer for you…

As far as the Port being shown Open by GRC when the Apache server is running, that is correct. The rule is present, the application is active, the port is open. That’s why the server needs to be correctly configured to prevent compromise.


Yes, I know it is correct that it should be Open!
But the strange thing is, that the log in comodo says access granted, even when the server is not started, and shields up says Stealth.

I’m still a newbie, but I am going to hazard an educated guess here.

The Network Monitor rule allows the inbound communication on that port, therefore, the log will inform you that there was something on the port and it was allowed IN. Hence, Access Granted is shown in the logs. But after it was allowed IN, there was no application listening to the port, and hence no response generated from the inbound communication on the port, so ShieldsUp does not get a response, effectively making the port “stealth”: Query a port, but no response from port = Stealth.

So, in conclusion, Network Monitor grants inbound access on the port (log as Access Granted), but no application listening and no response, so ShieldsUp classed the port as Stealth.

If an application is listening on the port, it would reply back with something, for example of a FTP server, it will probably send back replies asking for login details, or something like that. That will then make the port Open in ShieldsUP since they received a reply.

Hope that is the correct answer. Experts welcome to correct my reply. Hope that does answer your question.

Yeah, I have thought about that too.
But still if they say comodo has been made so that it only allow access if there is a program listening, it shouldn’t say access granted?
That is what confuses me.

I guess that is how the multi-layer approach works. First layer (Network monitor) grants access, second layer (Application monitor, etc) has another set of rules. So, when you are asking the Network monitor to log the inbound access, that is the first layer, and access is granted, so the log says it is granted. The logging was activated on the first defense layer. What happens next depends on the 2nd layer.

The logging on the Network monitor sort of just lets u know which rule has been triggered, rather than what really happens to the communication within the deeper layers.

Just want to add that I feel that this kind of multi-layer approach is very good. The first layer is sort of independent of the other layers. Logging on that first layer without considering the other layers helps alot in troubleshooting connection problems so that you know exactly which part (network monitor, or application monitor) is blocking or granting access. And it is very reassuring to see that even the first layer is open on particular ports, as long as the nothing is listening, it is still stealthed. I am liking this firewall very much.

I think Jaster has it correct since there is no application rule to allow the traffic when doing a shields up scan the traffic is dropped however when it is an http request it would be passed to the appche server that is listening on
port 80. I think 3.0 will allow log triggering by Application rules, however 2.4 does not.

I think they still have some thing to be improved in v3 at this stage of the Alpha. It still does not tell you what rule was triggered in the log. A must for troublesooting IMHO.


Maybe it’s Shields Up. Have you tried other port scanning sites to see any difference?

But Soya, the problem is, that shields up is showing what I expect it to do, but comodo isn’t.
Comodo says the access is granted, when it shouldn’t be.

Ok then I direct you to file a ticket

Soya, can you confirm that it is behaving wrong?

When no program is listening to a specific port, incomming connetions says “Access Granted” in the log of Comodo?
Or is it correct that it is because it is a network monitor rule, and the connection is first blocked when afterwards going through the application monitor rules?

You want me to stop uTorrent and test this out for you :o? Ok. I tested it for you.

I created a Network Rule: Allow In/Out from any to any on port 1234 with it logged as well as the last block everything rule logged. There are no Application rules or any applications using port 1234 on my pc. Performed the specified-port test at Shields Up! and it states port 1234 is stealth, but the log shows nothing on that port, but rather other ports being blocked ???

[attachment deleted by admin]

So what you are saying is ?
That it also says Access Granted to you, even though the port should be blocked, and is stealth according to shields up?
Or … ?

No. What I’m saying is that GRC states that port is stealthed, but Comodo doesn’t log anything to do with that port. Check my prior post’s picture attachment and see if the Network Rule is the same as yours.

Update: I just ran the test about 4 times again and this time CFP finally logs it as Denied. Must’ve been a delay or something. This makes me suspect that CFP logging has more problems with it than meets the eye.

But what happens if you do not tell it a source port?
ShieldsUp seems to use another port than 1234.
Only set allow on destination port 1234.

Same. Source=Any and it still only shows denied’s, no allowed’s

Oh boy. I can sense I’m starting to worry you with that confirmation ;D. Can anyone else confirm which is which on their system?

My rule says:

Allow and LOG TCP or UDP FROM IP [Any] TO IP [Any] WHERE Source port IS [Any] AND DESTINATION PORT IS 1234

And in my log it says:

Severity: Low Description: Information (Access Granted, IP = ***.***.***.***, Port = 1234) Protocol: TCP Incoming Source: ***.***.***.***:***** Destination: *LOCAL IP*:1234 TCP Flags: SYN Reason: Network Control Rule ID = *ID OF THE RULE ABOVE*

Soya, I think there is some misunderstanding here. amews_aj correct me if I am wrong: amews_aj has opened a port using the Network monitor and set it to log. So it is ALLOW and LOG inbound port 1234 in the Network monitor. Using ShieldsUp to scan that port 1234, there is a log entry in CPF that says that port has been granted access It doesn’t matter if there is an application that is actively listening to the port or not, the log entry is there whenever ShieldsUp is used to scan port 1234. The rule is to ALLOW and LOG, therefore when triggered, the log says ACCESS GRANTED, then it is passed to next layer for further filtering.

I do not think there is anything of concern here. The logging has no problem as it is only logging the Network Monitor’s activity. As I mentioned, this multi-layered approach makes things easier for troubleshooting. True, log triggering on the application rules would have made things easier and less confusing because it would provide a better picture of the situation.

Just my 2cents