Another HOSTNAME in Rule Bug

  1. CPU 32 bit (Celeron DUO T2400)
  2. XP Proff. Russian SP2 integrated
  3. СIS (Firewall & D+) 3.9…509 Russian , NOD32 2.70.39 Russian - antivirus
  4. incorrect work of Firewall Policy with “Host Name” inside

  5. Firewall = Safe Mode, D+ = Clean PC Mode

Account with Admin. privil.

Our goal - block HTTP traffic to dt00.net
Steps to repeat “bug”:

  1. Create Rule Block TCP Outgoing S:Any, SP:Any, D:HOSTNAME dt00.net DP:80
  2. Create Rule Allow TCP Outgoing s:Any, SP:Any, D:Any, DP:80

So, we should be able to go anywhere via HTTP, except dt00.net
I Fact - we CAN’T go almost nowhere…

Analize of this situation shows me:
During Rules saving COMODO resolves HOSTNAME to IP and in Registry we can see
Name = dt00.net AND
AddrStart=IP (During Rules saving COMODO resolves HOSTNAME to IP and in Registry we can see
Name = icq.xxx.com AND
AddrStart=IP, ( 83.222.4.243)
AddrEnd=IP, (213.186.117.133)

So Rule still works basing on IP, not HOSTNAME, and we can’t reach ANY IP between 83.222.4.243 and 213.186.117.133

It’s not unique hostname.

nslookup google-analytics.com
Server: xxx.net
Address: 10.151.10.15

Non-authoritative answer:
Name: google-analytics.com
Addresses: 209.85.171.99, 72.14.247.99, 64.233.161.99

So, if we would like to block google-analytics.com, we will block all between 72.14.247.99 and 209.85.171.99

My opinion - it IS bug

I’ve already reported similar issue twice (here and here).
Hopefully, someone from Comodo’s staff will notice this thread and they will fix this issue before next major release.

I’ve seen your post. But here is a new release with same bug. Also I wrote possible reason of such behaviour. Anyway - I also hope that such BIG Bug will be resolved as soon as possible.

For developers - this Bug was found in all releases from 3.5… Older version wasn’t tested by me.

Any comments from Comodo staff? I really want to use Hostname in Rules, but I can’t because of this Bug…

More than week passed since my last post in this topic. May be someone want to explain any future steps in resolving this bug?

I made some tests and I can confirm the above scenario exception made for google-analytics.com which I guess should supposedly block the range 64.233.161.99 to 209.85.171.99

It is likely that the hostname was not designed to work with hosts that can resolve to more than one IP nor different hostname that resolve to the same IP.

Though I guess there is no easy way to detect all these cases and warn the users during rule creation.

BTW Did anyone test whenever the rule IP range get updated after the initial setup if nslookup later provide addresses outside the initial range? Or what happens if an hostname that resolve to a single IP that later get changed to another one or multiple ones (eg after a reboot)?

Maybe the hostname should be only provided as an autofill option on IP ranges.

[attachment deleted by admin]

BTW Did anyone test whenever the rule IP range get updated after the initial setup if nslookup later provide addresses outside the initial range? Or what happens if an hostname that resolve to a single IP that later get changed to another one or multiple ones (eg after a reboot)?
During every saving rules COMODO do new resolve job. So, no matter changed to single or to multiple from single - a brand new resolve comes here ;) After reboot COMODO doesn't do new resolving.

Main problem still same - in “hostname” evein with resolving should be EXACT IPs, not RANGE !!!

If there is no new resolve even when the hostname actually map to a different IP/s there could be another potential issue (YMMV).

I’ve not tested this as it is likely that a controlled environment LAN setup(or a Dynamic DNS account) would be needed rather that trying to guess what Internet hostname would be likely to be resolved differently between sessions (eg after a reboot) or after a long timespan (though usually would not, there could be exceptions).

In order to transparently address all possible scenarios I guess the firewall engine ought to inspect/trap DNS resolves (even those addressed by Windows DNS cache) whenever it could be reasonable to enforce rules by IP using dynamically generated Resolved hostname Zones (though in case of IP enforced rules it would still not possible to block a only a specific hostname when two or more different hosts map to the same IP).

Until then maybe a GUI change to point out the limited/restricted hostname support could be a solution (YMMV).

Yes exproff, as it appear that the the rules (and firewall engine) are IP based it is likely that the hostname combo option was not designed to support/work with hosts that can resolve to more than one IP nor different hostname that resolve to the same IP.

If hostname always resolves to a single IP there would be no problem. The mapping to IP range rules would also allow to address the cases where an hostname resolves to a subset of a specific netmask, IP range (an entire ordered set of IP without any discontinuity/hole like eg: 209.85.171.99 to 209.85.171.105).

Thus the issue is limited to cases where an hostname maps to multiple IPs that cannot be correctly represented using IP ranges but listing each specific IP (eg using CIS Zones format) and endusers cannot be assumed to be aware of that.

Such cases could be addressed also by modifying the GUI to point out the rule is enforced using IP ranges and additionally/optionally providing explicit notifications when the generated range is not specific (YMMV).

I believe this issue has been around for a long time. I seem to remember making a post about something similar under v2.

There are a number of areas where host name usage could be better…

btw Endymion, what does YMMV mean?

Indeed full hostname support would be a welcomed addition although making the conversion to IP range rules more explicit through GUI changes could be a way to let users acknowledge the the span of the current design and use it whenever they see fit.

YMMV was meant as an acknowledgement that the posted opinion may not be shared by everyone in the same vein limitations of a specific design may not strictly considered bugs.

IMHO the whole function of hostname recognizing should be reworked. It should store a list of IPs which were returned by DNS lookup and treat it as a list of IPs and not as an IP range like right now. How it would be implemented in CIS (if at all) depends on CIS developers. As an end user of CIS I shouldn’t need to know of or care to how many IPs the hostname/domain resolves which I want to use in firewall rules. The other question is how often hostname/domain based rules should perform DNS lookup to update IPs in the list.

To provide a seamless full hostname support in the firewall engine a timed refresh of eventual IP lists might not be enough whereas it is likely that inspecting/trapping hostname resolves would be needed even though an IP based enforcement in some cases may block multiple hosts (whenever users may not care to know that either).

If the issue is that user should not care whenever they assume that full hostnames based rules are going to be used, then a GUI change to point out IP based rules are actually involved would have them acknowledge that.

Though it would be possible to add support for Zone format static IP rules using using an hostname wizard and removing hostname option check-box for Network control rule dialog altogether (that is until a major feature update would be implemented)

This way the chances of implying automated domain name resolutions or assuming that multiple hosts that map to the same IP are treated differently would be limited whereas non contiguous IP resolves would be addressed too.