Can't block local server

I’m doing some basic testing using Comodo Firewall 5.10.228257.2253 and seeing something unexpected.

First test was to verify I could block a LocalClient from attempting to connect to a LocalServer. The LocalClient is marked as D+ Trusted Application and I changed its Network Security Policy rule to a Blocked Application. This caused LocalClient to be blocked from connecting to localhost ports. Good so far, so I changed LocalClient back to a Trusted Application in Network Security Policy.

LocalServer is marked as D+ Trusted Application and I changed its Network Security Policy rule to a Blocked Application (first rule in list too). No errors when it started listening on INADDR_ANY port 9001. Subsequent attempts to connect to it via LocalClient were successful and subsequent client/server communication appeared normal and unaffected. This was the unexpected behavior.

I’ve tried a couple of different LocalClient’s and LocalServer’s, on a fully patched XP computer and a fully patched Windows 7 computer. Maybe there is not enough caffeine in my system at the moment and I’m overlooking something, maybe not, need a sanity check. Shouldn’t I be able to block LocalServer from receiving connections from a LocalClient?

Just to make sure I understand:

  1. You have a server application running locally, listening on port 9001?
  2. You have a some client software, also running locally, that you’re using to connect to the server?
  3. When you connect to the local server, from the local client, the firewall is not working?

Please correct as necessary.

Yes that is basically it. Only I would again point out that I can disrupt the communication between LocalClient and LocalServer by creating a rule to block LocalClient. What doesn’t seem to work correctly is the allow LocalClient block LocalServer combination (the connection and traffic aren’t blocked). Even if the LocalServer application block rule is before the LocalClient application allow rule. I must be missing something, right?

I would really need to test this myself, before answering one way or the other. Would you mind describing the software you’re, using along with specific details of the rules you’ve created.

I’ve tried various client and server programs, same behavior. ATM I’m using telnet as my LocalClient and I’m using TCP/IP Builder 1.8 ( TCP/IP Builder • drkbugs ) as my LocalServer.

The LocalClient is marked as a Trusted Application in D+ and also as a Trusted Application in Network Security Policy.

The LocalServer is marked as a Trusted Application in D+ and as a Blocked Application in Network Security Policy. I make sure this blocked rule is first in the Network Security Policy list hoping that will assure it overrides any other conflicting rules.

Via LocalServer I create a listening socket on port 9001. Via LocalClient I connect to port 9001. The connection and subsequent traffic go through despite the LocalServer having a blocked network security policy.

Are the local server and local client running on the same system?

In this scenario I don’t anticipate the firewall, in isolation, being much use to you, likewise, when you’ve set applications as trusted, you’re basically allowing them to do more or less what they like.

What you’ve essentially got here is two applications, both running on the same system, making localhost connections. As the connection isn’t actually going anywhere, the firewall is not involved. If you wanted to have control over these kinds of interprocess communication, you’d really have to get D+, in Proactive security mode, involved.

EricJH: Yes, the server and client in question are running on the same computer.

Radaghast: Thing is, the firewall does seem to have some visibility and be involved. It detects and as expected prevents LocalClient from making localhost connections when LocalClient is a network Blocked Application. I’ve also tried a “block out to localhost port 9001” followed by “allow all in/out” rule for LocalClient. That blocks connections to localhost port 9001, allows connections to other localhost ports, and also allows connections to remote servers.

From an implementation point of view, there might be differences in how a destination socket is blocked vs how a source socket is blocked. One question would be, does Comodo have the ability to specifically target (apply rules to) destination sockets on the localhost/loopback? Even if it doesn’t have that ability directly, it would seem that is does indirectly. IOW, if it can see and block local clients from connecting to localhost and specific localhost ports, then it could support localhost destination socket rules by checking those against what local clients are attempting to connect to.

I think a LocalServer block rule should override a LocalCient allow rule and if LocalServer has a “block all IP in/out” rule that should if at all possible apply to loopback as well. Even if you wanted “Blocked Application” to allow loopback but block the physical interface for some convenience reason, it would be good if there was some way of configuring an application to be blocked in the fuller and most complete sense or if so desired blocked in a specific way on localhost. Thoughts?

I understand where you’re coming from. With some firewalls, it’s quite possible to block client processes making outbound connections over, but impossible to block a server process from listening and receiving connection on localhost. Right or wrong, I guess this is just down to implementation. In some ways this is understandable, as localhost is not a ‘real’ interface, so it could be argued there’s nothing to block.

Depending upon your point of view, CIS is a bit of a halfway house at the moment, at least with regard to localhost connections. It blocks more than Windows 7 firewall but not as much as some other third-party firewalls. I guess this may change in future versions, but we’ll have to wait and see. Certainly, the Windows 8 beta version of CIS, corrects the problem with the Avast proxy connections but it still doesn’t seem to be able to block server processes receiving connections over, at least with the firewall alone.

To All: It occurs to me that the issue I’m describing might be boiled down to:

  1. Failure to execute Action:Block, Direction:In, Destination:Loopback rules
  2. Failure to execute Action:Block, Direction:Out, Source:Loopback rules

Based on my testing (TCP/IPv4 only, mostly XP, so double check on others), those types of things won’t work in firewall per-application rules or global rules. In terms of specifying a loopback address, I’ve tried both and also [Loopback Zone]. Some preliminary testing suggests that the same limitations apply to scenarios such as a local client communicating with a local server that listens on the IP Address of a physical interface. Presumably because the loopback communications mechanism is still used.

Limited work-arounds that I’ve identified include:

  1. Use Action:Block, Direction:Out, destination loopback:port rules, application or global, to try to prevent local clients from connecting to the loopback:port in question. Such a block rule, if global, does appear to over-ride an application level allow rule.


a) Does not provide server application level control, should that be needed
b) Application rule approach appears to be broken by some local proxy setups. For example, a Firefox application Action:Block, Direction:Out, Destination:LoopbackZone:80 rule does NOT prevent Firefox from connecting to localhost:80 on my XP/Comodo/avast6 box. Hypothesis: because avast changes the destination port to 12080 before Comodo gets a look, all Comodo sees is AvastSvc.exe (rather than Firefox) connecting to localhost:80 and thus allows the Firefox<->LocalServer communications path to be established.

To Radaghast,

I appreciate the exchange. I, I’m embarrassed to say, did not know the limitation we’re discussing existed in Comodo or if I ever did I just forgot about it. I’m inclined to say that because IP communications occur between IPaddress:Port pairs, the question of real vs virtual interfaces shouldn’t matter. However, firewall implementations as well as limitations in OS stack interfaces, etc can make such differences matter.

I’m glad to hear the avast7 type issue is resolved on Windows 8. I hope improvements will continue in general, and I hope some of those will somehow find their way back to earlier systems.