COMODO ignores DNS records TTL when using Host name in firewall rules

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

This is a following to https://forums.comodo.com/firewall_help/dynamic_hosts_in_policies-t39626.0.html
(read this before asking any question since they all have been answered there)

The conclusion of the above thread is that:

There is a bug in Comodo it does not respect DNS record TTL when it resolves host-names used in the firewall rules.
The result is that host names from no-ip.org of dyndns.org or any similar service is unreliable when used in Comodo firewall rules (DNS records from these services usually have a TTL of 60s).

Right now I’m using a trusted computer behind a dynamic host, I could access my main computer yesterday. Today I can’t because its IP was reset by the ISP, the no-ip.org DNS has been updated automatically but Comodo did not update the associated IP…

This is a really annoying issue, a quick search on the forum seems to tell that this issue exist from the beginning… each time users found a dirty workaround to elude the issue… Unless I allow the whole town to access my main computer there is no workaround for me.

Please do report this to the devs.

Thanks.

2

You’re rehashing a problem that you could have used the other thread for.

If you have your firewall rules set correctly, there should be no problem. To be honest I don’t believe anything in CIS has an effect on the TTL, as it has no cache. You’d be better off looking at changing the cache value TTL in your browser or windows.

3

please… read what I’ve written, read the conlusion of grue155 (another GLOBAL MODERATOR):

please do consider this because this IS a issue, there is nothing I can “set corretcly” in my rules… what could I do appart from putting the hostname I want to allow???

You're rehashing a problem that you could have used the other thread for.

the other thread was ‘moved’ to the help section giving the impression that the fact that COMODO only resolves a HOSTNAME once and for all is a user issue but I’m sorry… really… this is a BUG and belongs to the BUG forum.

If you have your firewall rules set correctly, there should be no problem. To be honest I don't believe anything in CIS has an effect on the TTL, as it has no cache. You'd be better off looking at changing the cache value TTL in your browser or windows.

Sorry if my english is not understandable but as I have explained the problem is COMODO not using the TTL value returned by the DNS, this has nothing to do with WIndows.

4

2072’s report might have revealed a misunderstanding. The way that TTL is used for IP packets and DNS queries is fundamentally different. For IP packets, 60 would equate to 60 hops before the packet expired. However, for DNS replies a TTL of 60 would actually mean 60 seconds before it expired (which is very, very short). So, you would expect the TTL for DNS replies to be fairly large (eg. 43200 & 86400 for 12 and 24 hours is not uncommon), reflecting the time that the DNS response is valid for. The TTL value for DNS replies is defined by an authoritative Name Server. Could this be the issue?

5

CIS doesn’t, as far as I know cache DNS queries. Your browser will and if you have the dNS client service enabled, Windows will too.

Look, CIS is just a barrier between you and the Internet, It allows what you tell it to and blocks what you tell it to.

I would say your problem is with your dns provider

6

I’m afraid you do not understand the problem…
When a computer tries to connect with your computer Comodo will see that a connection attempt is being made by the IP ADDRESS of the said computer.

Now, in Comodo firewall rules, you can set HOSTNAMES, for example 2072.no-ip.org.

Comodo will need to translate this to an IP Address in order to detect, allow or block a connection from/to this host.

Comodo only resolves the adress once. so if the associated ip changes then Comdo won’t know it and then, it’s like your rule for 2072.no-ip.org does not exist…

Idon’t know how else I can explain this…

if some other moderator does understand and have a clearer explanation…

A host -v command on freebsd returns this for 2072.no-ip.org:


host -v 2072.no-ip.org

Trying "2072.no-ip.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18020
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;2072.no-ip.org.			IN	A

;; ANSWER SECTION:
2072.no-ip.org.		60	IN	A	90.46.207.30

;; AUTHORITY SECTION:
no-ip.org.		60	IN	NS	nf4.no-ip.com.
no-ip.org.		60	IN	NS	nf1.no-ip.com.
no-ip.org.		60	IN	NS	nf3.no-ip.com.
no-ip.org.		60	IN	NS	nf2.no-ip.com.

;; ADDITIONAL SECTION:
nf4.no-ip.com.		80292	IN	A	69.65.5.122
nf2.no-ip.com.		80292	IN	A	69.72.255.8
nf3.no-ip.com.		80292	IN	A	72.5.169.8
nf1.no-ip.com.		80292	IN	A	204.16.252.8

Received 193 bytes from 213.162.49.1#53 in 174 ms
Trying "2072.no-ip.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34755
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2072.no-ip.org.			IN	AAAA

;; AUTHORITY SECTION:
no-ip.org.		60	IN	SOA	nf1.no-ip.com. hostmaster.no-ip.com. 2064465930 18000 1800 604800 1800

Received 92 bytes from 213.162.49.1#53 in 165 ms
Trying "2072.no-ip.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20370
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2072.no-ip.org.			IN	MX

;; AUTHORITY SECTION:
no-ip.org.		60	IN	SOA	nf1.no-ip.com. hostmaster.no-ip.com. 2064465930 18000 1800 604800 1800

Received 92 bytes from 213.162.49.1#53 in 99 ms

in comparison here is what it returns for comodo.com


%front1.mut.teaser.net: /s/home/_j2/j2072/pub/www.2072productions.com>host -v  comodo.com
Trying "comodo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59894
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;comodo.com.			IN	A

;; ANSWER SECTION:
comodo.com.		1062	IN	A	91.199.212.132

;; AUTHORITY SECTION:
comodo.com.		1062	IN	NS	ns0.comododns.com.
comodo.com.		1062	IN	NS	ns1.comododns.com.
comodo.com.		1062	IN	NS	ns1.comododns.net.
comodo.com.		1062	IN	NS	ns0.comododns.net.

;; ADDITIONAL SECTION:
ns1.comododns.net.	42343	IN	A	91.209.196.5
ns0.comododns.net.	42343	IN	A	149.5.128.4
ns0.comododns.com.	42343	IN	A	91.209.196.4
ns1.comododns.com.	42343	IN	A	67.51.175.4

Received 203 bytes from 213.162.49.1#53 in 1 ms
Trying "comodo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8469
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;comodo.com.			IN	AAAA

;; AUTHORITY SECTION:
comodo.com.		515	IN	SOA	ns0.comododns.com. hostmaster.comodogroup.com. 2009080401 1800 1200 2592000 5400

Received 101 bytes from 213.162.49.1#53 in 0 ms
Trying "comodo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10730
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;comodo.com.			IN	MX

;; ANSWER SECTION:
comodo.com.		515	IN	MX	10 mail1.comodogroup.com.

;; AUTHORITY SECTION:
comodo.com.		1062	IN	NS	ns0.comododns.com.
comodo.com.		1062	IN	NS	ns1.comododns.com.
comodo.com.		1062	IN	NS	ns0.comododns.net.
comodo.com.		1062	IN	NS	ns1.comododns.net.

;; ADDITIONAL SECTION:
ns1.comododns.net.	42343	IN	A	91.209.196.5
ns0.comododns.net.	42343	IN	A	149.5.128.4
ns0.comododns.com.	42343	IN	A	91.209.196.4
ns1.comododns.com.	42343	IN	A	67.51.175.4

Received 221 bytes from 213.162.49.1#53 in 1 ms
7

I apologise, I’m too dim to answer your problem

8

To clarify the problem, here is a typical problematic situation (mine actually):

2 computers at 2 different locations.

Computer 1 (C1): Static IP address with Comodo installed

Computer 2: (C2) Dynamic IP address changing every 24 hours - no Comodo installed

C2 needs to connect to C1 using Remote Desktop.

C1 want to allow only C2 to connect —> “simply” make a rule then?

  • First problem: C1 IP address changes every 24 hours…

  • Fortunately Comodo allows us to set HOSTNAMES instead of IP addresses :slight_smile:
    ---------> register a dynamic hostname at no-ip.org
    ---------> then create our allow rule for c2.no-ip.org

  • Done … C2 can connect to C1 and no other computer can. Great!

  • you are enjoying using C1 through Remote Desktop connection on C2

  • When suddenly C2 address is reset. :o
    - Comodo on C1 no longer recognises C2.no-ip.org as allowed to access it…

Why?

Simply because COMODO does not renew C2.no-ip.org associated ip address and thus does not allow your attempts to connect from C2 since the IP address has changed.

no-ip.org set a TTL of 60 seconds for its DNS records… then this TTL is returned by any DNS server. Comodo could renew its HOSTNAME <–> IP association according to this TTL. The fact is that it doesn’t and use a fix value of (at least) 24 hours.

9
;; AUTHORITY SECTION: no-ip.org. 60 IN SOA nf1.no-ip.com. hostmaster.no-ip.com. 2064465930 18000 1800 604800 1800
The highlighted TTL of 60 is for that specific SOA record reply, not the DNS reply itself. That's indicated by the SOA record Expiry field which is 604800 or 7 days. This is why I'm confused.

PS I’m no expert either. So, after saying that… I’ll shut up now. :slight_smile:

10

The line that matters is this one:


;; ANSWER SECTION:
2072.no-ip.org.		60	IN	A	90.46.207.30

90.46.207.30 is the associated IP addresse (type nslookup 2072.no-ip.org note that it will change when 2072.no-ip.org is reset)

11

have you tried this without using CIS?

12

why would I do that? It would work, since CIS wouldn’t be there to block these legitimate requests.

(blocked requests are logged so I know it’s COMODO blocking them)

13

This is a known issue. There is also another known issue related to hostname based firewall rules in CIS. If a DNS address resolves to more than one IP address then it will be treated as an IP scope instead of a list of IPs. Really, I would avoid creating hostname based firewall rules in CIS untill these issues will be solved.

If you need this hostname based firewall rule to use Remote Desktop on the other computer then you can always establish VPN tunnel between these computers. And then use Remote Desktop over secure and encrypted VPN tunnel which is a lot safer anyway.

14

Ok, thank you for the information, let’s hope the devs are aware of the issue and haven’t given up :confused:

I’ve just noticed a strange issue with Remote Desktop: when I got back to my main computer, I wanted to look at Comodo logs to see the blocked requests.
I couldn’t because the logs stopped working when I logged using remote desktop, I can only see the original accept on port 3389 and 10s later no log… until I physically got back to the computer and unlock the computer as usual (by locked I mean session-locked - WIndows-L).

During this 2.5 days period, no logs were recorder but the computer worked normally, I know it for sure for several reasons:

  • I used the computer through Remote Desktop for more than 8 hours (I could leave and reconnect until the IP of the client changed)
  • I let an IRC program run 24h/24h and I have complete logs over this period of time with no hole.
  • This computer also executes daily over-Internet backup tasks, they were all completed successfully during the log hole.

So there is also a issue with Remote Desktop where Comodo enters a “strange state” and stop logging (and probably other things). This is a different issue though.

I don’t know anything about VPN. I suppose I need to have to run a server of some kind on the computer I wish to connect to via VPN?