What is meant by "source" and "destination"?

Comodo Internet Security - CIS Firewall Help - CIS
#1

This probably sounds like a very basic question, but I can’t find the answer for it in the help file or the forum:

When I set up a new firewall rule (under "Network Seciruty Policy - Network Control Rule), I get to choose which destination port, destination address, source port and source address for which the rule shall apply. But what is meant by “destination” and “source”?

By just considering what the words say, I at first assumed that destination equals my PC for inbound rules, and source equals my PC for outbound rules. That’s the way I set it up so far.

But then I read this in the help file, under “Firewall Tasks > Advanced - Network Security Policy”: “Destination Port : States the port(s) on the remote entity that the application must be attempting to send to.”

One reason why I’m rather awake on this subject is that I used to use Kerio 2.1.5, and there the ports and address ranges were named “local” and “remote” instead of “destination” and “source”. Judging by the help file, it would seem “Destination” equals “remote”, which would mean most of my present rules are incorrectly set up. Most people probably don’t give this a second thought, but it’s rather crucial to get this right!

BTW, I like Comodo, I just use the basic firewall part (rules set) combined with Avira and Spyware Terminator, it’s a very good replacement for the old Kerio 2.1.5. Besides the question at hand, there’s only one thing that bothers me: That it very easily happens that Comodo itself adds a rule “allow all” for the process svchost. This removes much of the point in having a firewall, since then any DLL can access the web via svchost.

#2

Welcome to the Forum, DavidGGG.

Correct. Source is the originating point, Destination is the Ending point.

For incoming transmissions, source would be the remote server.
For outgoing transmissions, source would be your computer.

#3

Thanks for making it clear. :slight_smile:

Then maybe you’d like to re-phrase the help file text mentioned. Using the word “remote” implies it’s the PC which isn’t mine. I think you should change that word to e g “non-initiating”.

#4

It is just a matter of getting used to the way how CIS names the traffic. It looked a bit odd to me as well when I first started using it. Once you get the logic it is a no brainer.

#5
there's only one thing that bothers me: That it very easily happens that Comodo itself adds a rule "allow all" for the process svchost. This removes much of the point in having a firewall, since then any DLL can access the web via svchost.

That’ll happen for any application alert if you click allow and “remember this” is checked; it ends up adding a universal Allow ALL rule. However, that’s the easiest way to get the app defined automatically. What I do is immediately go into the Network Security page and change the Allow ALL rule to ask & log. Then you get alerted for each new situation, i.e., connection attempt. Now the IP & port src & dest are readily apparent in the log. Its easy to set up specific rules for the app based on what is getting logged.

Usually the SVCHOST access attempts are related to fundamental OS processes, e.g., Win Update, Anti-virus defs, Adobe, spyware updates, etc; the Java JRE updates are mind numbingly complicated. What you’ll see is that an application wants out, you allow it, and immediately thereafter SVCHOST wants to hit the same IP. What I found is really useful is to find a reverse DNS lookup site. Any IP that a trusted app wants to hit, I allow, but lookup to find the domain name of the IP. I then create a zone by app by domain name.

Often the IP can be resolved to domain name, but sometimes not. In that case I just create a zone for the app and specify IP ??? as part of the title. as time goes on you get less and less alerts as the prexisting zones get updated with the newly encountered IPS. The first IP encountered gets put into the zone as a single IP. When multiple IPS appear within the same domain, e.g., x.y.z.5, x.y.z.70, x.y.z.128, x.y.z168, x.y.z.201, then I create a rule in the zone using a mask: x.y.z.0/255.255.255.0 and CIS is happy and goes away (now he has 255 host IP on the x.y.z. he can hit), Of course if the next IP is x.y.h.215, you have to create a new entry in that zone. Now there’ll be two rules in that zone: x.y.z.0/255.255.255.0 & x.y.h.215 (and the process repeats).

You’ll also find that over time there’s hits to prot 443 (SSL) and then a hit to port 80 (TCP) for different IPS, I create seperate zones for the app for port 80 & 443. Eventually it becomes obvious that over time the app is shareing IPs between port 80 & 443. Then I create a common zone of IPs for ports 80 & 443 and then create a port profile 80 /443 and adjust the rules for the app appropriatesly.

If you use zones in your rules, by maintaining the zones you maintain ALL of the apps simultaneously; and you don’t have to rewrite all of the app rules all the stinkin’ times. The rules I have for SVCHOST are:

UDP out NIC to DNS src ANY to 53
TCP out NIC to Lavasoft_server_IP src ANY to 80
TCP out NIC to AAW_Service src ANY to 80
TCP out NIC to AAW - ILNW.net src ANY to 80
TCP out NIC to Akamaitech src ANY to 80
TCP out NIC to PCCWGlobal src ANY to 80
TCP out NIC to Bosch src ANY to 80
TCP out NIC to MSECN.net - 80 src ANY to 80
TCP out NIC to [MS Update] src ANY to 80
TCP out NIC to [WU - host ???] src ANY to 80
TCP out NIC to [MSECN.net 80 / 443] src ANY to [80 / 443]
TCP out NIC to [NSECN.net - 443] src ANY to 443
TCP out NIC to [Akamaitech - 443] src ANY to 443
TCP out NIC to [WU IP - 443] src ANY to 443

SVCHOST virtually never bothers me; these zones are already being maintained by the app access attempts. The zones applicable to SVCHOST are attributable to the various and separate apps that use those zones individually. Of course each app has its own set of zones (some of which aren’t shared by anything else - and SVCHOST will never attempt access to them either). All it takes is housecleaning of the zones, i.e., you may notice an app IP should be part of a range or mask domain in some other zone already defined.

For example, if an app wants to TCP out IP port 80 and the IP is found in the [WU IP - 443] zone, I remove it from that zone and create a [WU IP - 80 / 443] zone and put the IP in there. Then I create a rule allowing access to that zone using port profile [80 / 443]. Guess what 'll happen next? SVCHOST will want to hit that IP (either port 80 or 443). Don’t matter, I’ll add the rule for SVCHost for that zone & port profile and the problem goes away.