Outgoing TCP checked, but not incoming TCP!

Hey guys. I need an explanation, can you help me out?

I have CIS 3.8.65951.477 on Win XP SP3. I’m playing with the firewall, and I’m setting up rules for some apps.

These apps do the following things:

  1. Set up listening ports on localhost (in this case, solely intended for internal use by other localhost apps).

  2. Make TCP connections to those listening ports (internally, from localhost to localhost). Some of the apps connect to another app’s listener, and also some of the apps connect to their own listeners (like Firefox (and others) do… never did understand why apps do this, anyone know why?)

  3. Because of #2, obviously the “receiving” app (the one running the listener) experiences an incoming TCP connection on the listening port.

  4. Connect via TCP to outside hosts on the Internet.

Comodo Firewall only seems to notice, check, care about, ask about, log, block (etc. as the case may be) the number 2 and 4 actions above. And for #2, only when the connection is from one app to another app’s listener, not when the same app is connecting to itself.

In other words, when one of the apps wants to make an (outgoing) TCP connection to another app’s localhost listener, or to some machine on the Internet, Comodo’s firewall will behave correctly: it will check the firewall policy for that app, allow or block (and/or log) the outgoing TCP attempt as the rules dictate, and if there is no applicable rule, it will ask me what to do, and make a rule based on my answer. This is fine, and is exactly what I’d expect.

However, when one of the apps sets up a listener, or accepts an incoming TCP connection to that listening port (localhost to localhost), Comodo’s firewall seems to do NOTHING. These actions are silently allowed. The firewall rules I have for the receiving app (the one running the listener that’s being connected to) are apparently not consulted, not obeyed, etc. If the rules say to block the action, it’s not blocked. If logging is supposed to happen, it doesn’t. If there’s no rule and I’m thus supposed to be asked, I’m not. The listener is set up, and/or the Incoming TCP connection to it is allowed, successfully and without any apparent action being taken.

For example, one of these “receiving” apps (that’s running a listener) has this firewall policy (#1 is because this app also happens to do outgoing TCP to localhost ports for other purposes):

  1. Allow TCP Out From Any To [Loopback Zone] where Source Port is Any and Destination Port is Any.
  2. Block and Log All Unmatching Requests.

If this app tries to receive an incoming TCP connection (from localhost) to its listening port, rule #1 is irrelevant (it handles outgoing TCP, not incoming), so we should fall through to rule #2, which says to block and log the attempt. However, no blocking or logging (or anything else!) occurs, and the connection is successful. It should’ve been blocked and logged under rule #2! If rule #2 didn’t exist, I should’ve been asked (and I tested it that way too, and was NOT asked), etc. It’s just blind, silent success, as if Comodo never even checked it.

Shouldn’t I need a rule between 1 and 2 above (or before 1) that says “Allow TCP In From [Loopback Zone] To [Loopback Zone] where Source Port is Any and Destination Port is Any.” ?

My initial guess was that Comodo doesn’t enforce the rules for localhost-to-localhost activity, however it DOES in the OUTGOING direction! When an app tries to make a TCP connection to another app’s listener (localhost-to-localhost), Comodo does follow the rules, and asks me if there isn’t a rule, etc. Why is Comodo ignoring and allowing localhost-to-localhost INCOMING connections, but is checking/enforcing the rules for localhost-to-localhost OUTGOING connections? Why this asymmetry? It seems very wrong!

As an additional quirk, why does Comodo check/enforce the rules for localhost-to-localhost outgoing TCP connections from one app to another app’s listener, but not when the same app is connecting to itself (like Firefox, etc. does?) This exception I can sort of understand (it’s the same app!), but not the serious unexplained asymmetry above.

This is troubling to me. I want to be able to understand my firewall, but right now I can’t. Can anyone explain this?

Thanks guys!

I’ve made two posts to these forums so far, and I get people viewing them, but not a single response yet.

Perhaps it’s because they’re both long posts. So, here’s the short form of the post above:

================ BEGIN ==================

I have CIS 3.8.65951.477 on Win XP SP3. I’m playing with the firewall, and I’m setting up rules for some apps. These apps do the following things:

  1. Set up listening ports on localhost (in this case, solely intended for internal use by other localhost apps).

  2. Make TCP connections to those listening ports (internally, from localhost to localhost). Some of the apps connect to another app’s listener, and also some of the apps connect to their own listeners (like Firefox (and others) do… never did understand why apps do this, anyone know why?)

  3. Because of #2, obviously the “receiving” app (the one running the listener) experiences an incoming TCP connection on the listening port.

  4. Connect via TCP to outside hosts on the Internet.

Comodo Firewall only seems to notice, check, care about, ask about, log, block (etc. as the case may be) the number 2 and 4 actions above. Numbers 1 and 3 it blindly allows. It does not seem to consult the rules or enforce them, or take any other action, at all. They are simply allowed.

Why?

================ END ===================

Is that better, being shorter? Can someone answer this? It’s pretty serious when your firewall is allowing incoming TCP connections to an app, even though the firewall rule for that app say NOT to!

Thanks.

Thx for making your topic start shorter. That surely helps.

Can you show screenshots of your Global Rules and Application Rules for the applications involved?

Part of the answer is understanding what localhost is: it’s your machine talking to itself.

What you’re seeing as an inbound connection, happens to be also an outbound connection from your machine. It’s just that the inbound point is also your machine. So a rule that says “block unmatched” recognizes that the other side of the connection is already the match, and so the packet passes the rule.

Does that help?