Firewall rules based on hostnames don't work as expected

Comodo Internet Security - CIS Resolved/Outdated Issues - CIS
1

A. The bug/issue

  1. What you did:
    Added a firewall rule, allowing
    “ping.exe”, out any, source any to target pool.ntp.org, source port any, target port any
    “ping.exe”, out any, source any to target crl.verisign.com, source port any, target port any

  2. What actually happened or you actually saw:

  • The hostnames resolve to various IPs. crl.verisign.com resolves to crl.verisign.net in first place
  • In case of pool.ntp.org
    If pool.ntp.org resolved to 23.23.23.23 and 42.42.42.42, ping will be allowed to contact any host in the network range 23.23.23.23 - 42.42.42.42
  • In case of crl.verisign.com
    CIS asks me on every IP change if I would like to allow ping to contact the host after the IP has changed

  1. What you expected to happen or see:
    If the hostname resolves to a certain IP at the moment, the rule should allow ping to communicate exactly with this host - not with more or less!

  2. How you tried to fix it & what happened:

and no, adding 100s of IP adresses to replace the hostname is no workaround!

  1. If its a software compatibility problem have you tried the compatibility fixes (link in format)?:

  1. Details & exact version of any software (execpt CIS) involved (with download link unless malware):
    ping.exe 6.1.7600.16385, contained in Windows 7
    ping.exe 5.1.2600.5512, contained in Windows XP

  2. Whether you can make the problem happen again, and if so exact steps to make it happen:

  • Add a firewall rule, allowing
    “ping.exe”, out any, source any to target pool.ntp.org, source port any, target port any
    “ping.exe”, out any, source any to target crl.verisign.com, source port any, target port any
  • Ping pool.ntp.org and crl.verisign.com several times. Try pinging IPs inside the network range of to IPs, pool.ntp.org resolved to
  1. Any other information (eg your guess regarding the cause, with reasons):
    CIS isn’t able to handle hostnames that resolve to a different hostname in first place (otherwise, ping crl.verisign.com would probably behave as ping pool.ntp.org)
    I have no idea, what causes CIS to behave as strange in the “pool.ntp.org case”

B. Files appended. (Please zip unless screenshots).

  1. Screenshots of the Defense plus Active Processes List (Required for all issues):
    certainly not, but ok…

  2. Screenshots illustrating the bug:

  • Screenshot of rules for ping.exe and ping2.exe (a copy of ping.exe)
  • Screenshot command window, pool.ntp.org resolved to 74.118.152.85; trying ping -n 1 crl.verisign.com results in an alert
  • Screenshot command window, pool.ntp.org resolves to 173.9.142.98 now (this host doesn’t reply to echo requests), can ping2 -n 1 75.0.0.2 now without alert!
  1. Screenshots of related CIS event logs:
  • There are no entries for ping2.exe; one for ping.exe corresponding to the alert from screenshot in 2
  1. A CIS config report or file.
  1. Crash or freeze dump file:
  1. Screenshot of More~About page. Can be used instead of typed product and AV database version.

C. Your set-up

  1. CIS version, AV database version & configuration used:
    CIS 5.9.221665.2197, 1 (AV is disabled), COMODO - Internet Security, but all firewall rules were removed, firewall is set to custom policy mode

  2. a) Have you updated (without uninstall) from from a previous version of CIS:
    No
    b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:

  1. a) Have you imported a config from a previous version of CIS:
    No
    b) if so, have U tried a standard config (without losing settings - if not please do)?:
  1. Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.):
  • Removed the default rules of the firewall config

  1. Defense+, Sandbox, Firewall & AV security levels: D+= , Sandbox= , Firewall = , AV =
    D+=Clean PC Mode, Sandbox off, FW=Custom, AV=off

  2. OS version, service pack, number of bits, UAC setting, & account type:
    XP SP3 32bit; also tested on 7 SP1 32bit, UAC on, admin account in both cases

  3. Other security and utility software currently installed:

  1. Other security software previously installed at any time since Windows was last installed:
  1. Virtual machine used (Please do NOT use Virtual box):
    no

[attachment deleted by admin]

2

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Actually this is a known issue, but this this the best report on it so I will forward to format verified, with many thanks.

Many thanks again

3

Previous non-format report: https://forums.comodo.com/non-format-issue-reports-cis/about-the-blocked-zone-in-firewall-t77734.0.html;msg556040#msg556040