Hi,
When creating rules, for both IP and port you have tabs for “destination” and “source”. However, these descriptions appear to be incorrect. When working with incoming connections, “source” is still used to refer to the local computer while “destination” is referring to the remote computer. This is obviously incorrect, as the remote computer is the source for an incoming connection.
May I suggest that these tabs are renamed to “Local” and “Remote”.
The ‘Source’ address is the originating device and ‘Destination’ is the target device. For example, you want to allow a remote desktop connection from a device with the IP address 192.168.10.10 to a device with the IP address 192.168.10.11. The rule for the inbound connections would be.
Action - Allow
Protocol - TCP
Direction - In
Source Address - 192.168.10.11
Destination Address - 192.168.10.10
Source Port - Any
Destination Port - 3389
Conversely, to allow the outbound connections you’d have:
Action - Allow
Protocol - TCP
Direction - Out
Source Address - 192.168.10.10
Destination Address - 192.168.10.11
Source Port - Any
Destination Port - 3389
If you’re creating rules based around ‘IP’ instead of TCP or UDP, you cannot specify the ports used.
So, the ARE meant to reverse themselves for incoming rules? I tend not to use this for the local IP (since it is always the current computer), but I do use it for ports. I tried it that way for setting ports for Apache. For incoming connections, setting the destination port to 80 (the only port that Apache listens on for this computer) and source port to Any resulted in the firewall continuing to ask for every single connection. When I swapped them, it worked. Could you perhaps think of why that would be then?
Source is where the traffic is coming from (your PC for outgoing traffic and remote PC for incoming traffic) and
Destination is where the trafic is coming to (remote PC for outgoing traffic and your PC for incoming traffic)
So, if you want appache to recieve traffic on port 80 you’re creating the rule for allow incoming traffic with destination (your) port 80.
If you allowed this port in global rules only then actual appache proccess will ask you should it accept this traffic (since it was allowed by global rule), so you should create the same rule for actual process.
If you allowed port 80 only for appach process, then it will be blocked by global rule (since for incoming traffic global rules are checked first).
You don’t need to use a specific address for the local (in this case, destination) computer, you can use ‘Any’ or even the MAC address, it really depends on preference and what you’re trying to achieve. With regard to Apache, using the method described above, the rules would look like the following:
Global Rule
Action - Allow
Protocol - TCP
Direction - In
Source Address - Any
Destination Address - Any (or local IP/MAC)
Source Port - Any
Destination Port - 80
Application Rule
Application - httpd.exe
Action - Allow
Protocol - TCP
Direction - In
Source Address - Any
Destination Address - Any (or local IP/MAC)
Source Port - Any
Destination Port - 80
As can be seen, the ‘source’ and ‘destination’ regardless of whether it’s IP address or port related, identifies the originating (source) PC and the target (destination) PC.
Creating both Global and Application rules may seem like a duplication of effort and in this case, at least to some extent, it is. However, It’s important to understand the differences between Global and Application rules. One simple way to think about the differences is:
Global rules provide a means to control connections based on protocol and port, for one or many applications
Application rules provide connection control for specific applications
In theory, you don’t need Global rules but they do make certain things a lot easier. I should also point out that the need for inbound Global rules will depend on your configuration. If you’ve installed the full suite, including the AV, or you’ve run Stealth Ports Wizard with the third option, you’ll have a Global rule that Blocks all unsolicited inbound connections. In either of the aforementioned cases, you’ll need to create inbound Global rules.
For a connection to be allowed, it has to pass certain criteria, depending on whether the connection is inbound or outbound the processing logic is:
For Inbound connections:
(Source)Internet/LAN —> Global Rules —> Application Rules —> Process(Destination)
For Outbound connections:
(Source)Process —> Application Rules —> Global Rules —> Internet/LAN(Destination)
Basically, for inbound connections, there has to be a Global rule that allows the protocol/port and there needs to be an application rule, for the specific process, listening on the same protocol/port combination. If either of these conditions is false the connection will fail.
For outbound connections to succeed, the process must have a valid Application rule that allows the request via the appropriate protocol/port and there needs to be a path through Global rules, either via an explicit rule, or via a more general ‘allow all outbound’ type rule.
This has nothing to do with my earlier global rules concern, that’s all for another topic. There are no applicable global rules in effect here. Also, as I said, this has nothing to do with IP settings as I realize that there is no requirement to specify the IP of the local computer.
My simple issue was why, when I set the incoming allow application rule to allow “source” as “any” and “destination” as “80” (also nothing to do with IP settings here, both are set to Any), the rule did not work. By what you’re saying, this is the correct layout. When I swaped it to “source” “80” and “destination” “any”, it worked. This is what made me initially think that the directions had been swapped. There is another application that behaves the same, where the local and remote ports are different (unlike Apache), but setting the local port in “source” for the incoming connection results in it working.
I’m sorry if you feel the information is irrelevant, It was added to aid your understanding, as you appear a little confused, both here and in your Global Rules post. As far as your situation is concerned, you’ll have to post more specific details, as the information you’ve presented thus far makes it impossible to see what you may be doing incorrectly. The rules I’ve posted above are correct, if you’re seeing something else, it’s likely a configuration error.
Could you please take a screenshot of your rule for appache and alert window, and post them here?
Sorry, no, the configuration you posted is the one I was using - and the one that didn’t work. The Global Rules post ended up clarified elsewhere with a moderator. As maniak pointed out in that topic, outgoing global rules are indeed not much use in custom mode, and that was my only issue with that - the confusion stemmed from the fact that, in custom mode for most firewalls, if there is a rule present that matches the traffic, the connection will be allowed. However, the case with CIS appears to be that in custom mode, even if there is a global rule, there must also be an application rule - the documentation leads one to believe that the order that the rules are processed was simply a priority check. My post above, frustration may have shone through, but I was simply clarifying that there were no global rules affecting the access of Apache. In fact, there are no longer any global rules in effect. I’d been on the edge of uninstalling when I learned that this does support wildcards for application rules (something seemingly missing in the relevant documentation pages), which serve my purpose (though I have not yet implemented them, so that is not a contributing factor in this). I’ll post screenshots when I have access to the machine; I’m at work for now.
I’m sorry you couldn’t get the configuration I posted working, I assure you, however, it is correct, even if you just use the Application rule. (image) I guess there’s a configuration somewhere.
The Global Rules post ended up clarified elsewhere with a moderator.
I read that.
As maniak pointed out in that topic, outgoing global rules are indeed not much use in custom mode, and that was my only issue with that
Global rules aren’t really designed to control outbound connections, although some choose to use them for that purpose. The mode of the firewall is also not designed with Global rules in mind.
- the confusion stemmed from the fact that, in custom mode for most firewalls, if there is a rule present that matches the traffic, the connection will be allowed. However, the case with CIS appears to be that in custom mode, even if there is a global rule, there must also be an application rule
As I mentioned in my earlier post, you only need a Global rule if you’ve chosen to block all unsolicited inbound traffic, and then only for applications acting as a server. As I also pointed out, unless you chose specific options during installation, or post installation, the default Global rules simply block some undesirable ICMP types. Nothing more.
With regard to rule matching, what you’ve described is the way CIS works. Basically, if you or the system has created an allow rule and a connection request arrives that matches the rule, the connection will be allowed. Again, a Global rule is only necessary if you’ve chosen a specific type of configuration.
Regardless of which firewall you use, there has to be an endpoint for the connection, whether that’s every process on your system, or a specific process you designate, Both of which you could do using Application rules in CIS, Clearly, however, the former would not be much use it terms of security.
- the documentation leads one to believe that the order that the rules are processed was simply a priority check.
Not exactly. The rules in the firewall are read in the way I described above and also from top to bottom. When a connection request arrives, it must pass all matching rules, whether they be Global, Application or within the hierarchy of the rule list. if at any point a block is encountered, the connection is denied
My post above, frustration may have shone through, but I was simply clarifying that there were no global rules affecting the access of Apache. In fact, there are no longer [i]any[/i] global rules in effect.
Not to worry, if you’re first two posts had made that more obvious I wouldn’t have spent the time explaining.
I'd been on the edge of uninstalling when I learned that this does support wildcards for application rules (something seemingly missing in the relevant documentation pages), which serve my purpose (though I have not yet implemented them, so that is not a contributing factor in this).
Actually, the use of wild cards is referenced, although it could be a little more obvious. It’s covered in this link Protected Files and Folders from the Application Rules page.
I'll post screenshots when I have access to the machine; I'm at work for now.
Thank you.
[attachment deleted by admin]
As I said before, global rules aren’t an issue here. If you’ve read the topic in question, then you know that there’s not really anything else that need be said on the topic. I appreciate your time and help here, so I’m trying to save you from going over a problem that’s already been solved. 
The screenshot you posted there is functionally identical (I use port-sets to allow SSL as well) to what I had originally set up.
Anyway, this is what doesn’t work:
http://brutix.com/img/xlrm/fw-apache.png (all other tabs are “Any”)
Simply changing “Destination Port” to “Any” and “Source Port” to those predefined HTTP ports results in the connection being established without a pop-up asking for permission.
The source ports in “Active Connections” and “Firewall Events” are different because I wasn’t quick enough taking the screenshot of “Active Connections” after the event. :v
I have no global rules set at all. I have one wildcard application rule, which is simply allowing outgoing traffic to my LAN.
Edit: I completely deleted the application filter entry for Apache, and re-added it - just on the off-chance. Unsurprisingly, it didn’t change anything, heh.
I actually have one further question related to my original query on this topic:
For incoming connections, “source” is the remote computer & “destination” is the local computer, but obviously for outgoing connections “source” is the local computer and “destination” is the remote computer. So, when you select “In and out” for connection direction on a rule, which takes precedence? In a two-way connection rule, both are thus technically the source and the destination - so how does CIS handle that? In this instance, which refers to the remote port, and which refers to the local port? This is another case where simply labelling them “local” and “remote” would completely clear up any confusion.
Edit: Okay, so CIS gets one-up on any home firewall that I’ve ever used for the ability to create an entry in a file group with wildcards in the middle of the path (ie: “E:*\GameTrainer.exe”). Those files are located in different directory levels depending on the game type (sometimes I have “E:\GenreA\Sub-GenreB\Game\Trainer.exe”, other times it’s just “E:\GenreC\Game\Trainer.exe”). No other firewall has been able to both handle wildcards in the middle of a path and to have the wildcard act in a recursive manner. CIS gets some serious points for that.
Indeed, I was just making comments to your statemants. I’m glad you now completely understand how how the different components of CIS work together 
The screenshot you posted there is functionally identical (I use port-sets to allow SSL as well) to what I had originally set up.Anyway, this is what doesn’t work:
http://brutix.com/img/xlrm/fw-apache.png (all other tabs are “Any”)
Simply changing “Destination Port” to “Any” and “Source Port” to those predefined HTTP ports results in the connection being established without a pop-up asking for permission.
The source ports in “Active Connections” and “Firewall Events” are different because I wasn’t quick enough taking the screenshot of “Active Connections” after the event. :v
Did you forget to post something in the image, or is this the configuration you can’t get to work? From what I can see, it’s working the way it should. You have HTTP ports defined as the destination, the port set includes port 80, the alert is for port 80 and the connections are against port 80.
I have no global rules set at all. I have one wildcard application rule, which is simply allowing outgoing traffic to my LAN.
So you don’t need to accept inbound traffic from the LAN?
For incoming connections, "source" is the remote computer & "destination" is the local computer, but obviously for outgoing connections "source" is the local computer and "destination" is the remote computer. So, when you select "In and out" for connection direction on a rule, which takes precedence? In a two-way connection rule
It depends where the connection request originates. If the request is for a local resource, it’s inbound. If it’s for a remote resource, it’s outbound. The rule will act accordingly.
Exactly. It’s set up the way it should be, but that’s the configuration that doesn’t work. When I change the “destination” port to be “any” and the “source” port to be the HTTP ports range, it works.
This is the point where I just re-install, right? Heh.
No.
That doesn’t answer the question though. If I set up an in/out rule, where the remote computer is using port (example) 2000 and the local computer is using port 3000, which of “destination” and “source” is then the local port? If they’re not using the same port, then they aren’t interchangeable - for the outgoing connection, it would be connecting to remote (destination) 3000 coming from local port 2000 (source), but on the incoming connection, the remote computer (source) would then be connecting from port 3000 and the local computer (destination) would be receiving on port 2000. By the definitions of just “destination” and “source”, both of those would therefore be port 2000 and port 3000 - which is obviously impossible. Which leads me back to the question: when creating a bi-directional rule with mismatched ports, which of the “destination” and “source” fields acts as the local port, and which acts as the remote? I just wish they were simply labelled “remote” and “local” and acted as such - “destination” and “source” are relative terms, while “local” and “remote” are not; it doesn’t matter which direction you’re using, when talking about local and remote, they are always referring to the same machine. It just seems like such a needless complication.
Can you post a screenshot of the configuration you say works, please. include the active connections and log entries. It would also be helpful if you could remove the existing rule and letting the rule be created by answering the alert.
That doesn't answer the question though. If I set up an in/out rule, where the remote computer is using port (example) 2000 and the local computer is using port 3000, which of "destination" and "source" is then the local port?
If, using your example, the source and destination ports were ‘hard coded’ then:
Local Port = 3000 (source) ----> Remote Port = 2000 (Destination)
Local Port = 2000 (source) ----> Remote Port = 3000 (Destination)
The device on which the connection originates the source. Whichever port is defined in the source field for the rule is the the source, or local port. The device that receives the connection is the destination. Whichever port is defined in the destination field, is the destination, or remote port. If the ports used for sending and receiving are different on the originating and target devices, the source and destination fields would reflect this on the respective device.
...By the definitions of just "destination" and "source", both of those would therefore be port 2000 [i]and[/i] port 3000 - which is obviously impossible.
Actually, this is incorrect. The source and destination are from the perspective of the originating and target devices. In one orientation the source is port 3000 and the destination is 2000 but seen from the opposite end, the source is 2000 and the destination is 3000. The fact you’ve defined a rule that allows both in and out is irreverent. As long as the appropriate values are used in the source and destination fields, on the originating and target devices, everything will work as it should.
Which leads me back to the question: when creating a bi-directional rule with mismatched ports, which of the "destination" and "source" fields acts as the local port, and which acts as the remote?
As I said above, it depends from which end the connection is observed.
I just wish they were simply labelled "remote" and "local" and acted as such - "destination" and "source" are relative terms, while "local" and "remote" are not; it doesn't matter which direction you're using, when talking about local and remote, they are always referring to the same machine. It just seems like such a needless complication.
I guess it just depends what you’re used to. Having used virtually all commercially available firewalls, I can say they all have their ‘quirks’ and when coming form one that does something in a certain way, to another that does things in a slightly different way, it can seem confusing. I personally think using source and destination makes a lot of sense.
I think you’re misunderstanding the scenario that I’m putting forward. There is only one computer with a firewall in this, ie: mine, the local computer. As far as this firewall is concerned, the connection is only observed from one end; that would be true even if there was another computer that I had control over with CIS installed. The connection may be two-way, but CIS has no control over what is going on at the other end; the perspective is only ever from the local machine.
As far as CIS is concerned, the situation would be:
Local Port (source) 2000 ->[outgoing]-> Remote Port (destination) 3000
Local Port (destination) 2000 <-[incoming]<- Remote Port (source) 3000
Note the directions, and that ‘local’ and ‘remote’ never change: the connection is never seen from the other end by CIS. The terms “source” and “destination” are relative to the direction in which the traffic is directed. If you have a single outgoing or single incoming rule, this is simple - each line in the ‘diagram’ above would have it’s own rule, thus the source and destination ports are properly defined within that rule, as there is only one source and one destination value to define. The issue comes when the rule is set to in/out. As with all other rules, you can still only define one source port and one destination port (or range thereof). However, the source and destination ports change depending on the direction of travel, as seen in the above ‘diagram’. If traffic were outgoing, the source would be 2000 and the destination 3000; if incoming, the source is 3000 and the destination 2000. That’s what I’m having trouble understanding - how does CIS resolve this very obvious conflict?
As for Apache, something very interesting happened when I did as you said - deleted the rule, and let it be auto-created by the pop-up. The rule that was created obviously had specific IPs set (which I then set to ‘Any’), but it was created otherwise identical to the rule that I posted in my above screenshot. The only other difference being that the destination port was set to 80 instead of the pre-defined port set. The kicker here is that it worked! Apache traffic is now connecting without the pop-up requesting permission.
Edit: Indeed, if I edit the rule to return it to using the pre-defined port set, the rule stops working and CIS starts asking permission again.
Edit: I deleted the port-set, re-created it and tried again. Once again, it failed. I removed all ports from the set other than 80, however, and it seems to work. I think I’ll just create two rules each way for Apache; one for port 80, the other for 443.
Edit: Actually tried adding 443 into the set and it seems to work. The other two ports were only really there for certain outgoing connections. I don’t fancy pushing my luck, so I’m going to leave them out of it. They are not of immediate concern to me anyway.
What a strange bug. Can anyone reproduce this? Am I still missing something? Am I just straight up cursed? Port 8000 and 8080 were the other two.
I think there’s a fundamental misconception here. Using the rule you describe, when the originating device is making an outbound connection the source port is the originating port and the destination port is the target. When receiving a connection, the destination port is the recipient port.
Outbound Connections
Source port - the port from which the connection is initiated
Destination Port - the port on the target device the connection is being made to
Inbound
Source port - For inbound connections is not relevant
Destination port - The port used to receive inbound connections
Other scenarios are:
Stateful connections, In which the inbound connection will be received on whichever port the originating client specified when making the original outbound connection. In this case we don’t craft specific rules, as the port used is dynamically chosen.
Application needs make outbound connections on one port and receive inbound connections on a different port. In this case you’d generally use two rules for the same application, one for outbound and one for inbound. For example:
Outbound rule - Source port = Any —> Destination port= 3000
Inbound rule - Source port = Any —> Destination port = 2000
I guess you could also make a single completely generic rule :-\
In/Out —> Source port = Any - Destination port = Any
As for Apache, something very interesting happened when I did as you said - deleted the rule, and let it be auto-created by the pop-up. The rule that was created obviously had specific IPs set (which I then set to 'Any'), but it was created otherwise identical to the rule that I posted in my above screenshot.
That’s one of the annoying quirks of inbound auto rule generation. For some reason it always creates a ‘generic’ rule, regardless of settings, which is a contrast to outbound auto rule generation, where the amount of detail is controlled by the Alert frequency.
...What a strange bug. Can anyone reproduce this? Am I still missing something? Am I just straight up cursed? Port 8000 and 8080 were the other two.
I did recreate the rule you described in your image, with the ports defined in the port set, it made no difference to the way the Apache rule worked, which is as it should be.
That’s exactly what I just described though and is the core of my point. “Desintation” in that scenario refers to two different ports, as you just said. With two separate In and Out rules, that’s not a problem, but when you have a single in/out rule, that creates a fundamental conflict.
Yep, I agree and have no problem with that.
Ah-ha! Thank you! You’ve finally answered my question.
So, in that scenario, you have to create two separate rules because CIS cannot handle it within the one in/out rule. I was originally asking how CIS would handle this; I guess it just doesn’t. Can you see how this rule would be possible if the port tabs acted in a “remote” and “local” fashion though?
That’s alright, I’m not actually bothered by that. Normally, I can just hand-edit the rule after it’s created it (as I’d want to add my own description anyway). In this case, I suppose that if it had created a more specific rule, I wouldn’t have noticed this problem.
Yeah, I agree that the rule shown in the the two screenshots that we posted is how it should work. Not quite sure why having certain ports in a port-set caused it to fail. I’ll give a bash at re-installing it. Either way, it’s how it’s set up now (minus a few ports in the set) and is working as it should, so thank you - I wouldn’t have caught this unless I let it recreate the rule itself as you suggested.
Using the ‘generic’ rule I posted would also work. I haven’t tried it, but I think adding the different ports required to the rule would also work. So in the destination field you have 2000 and 3000 listed.
