Comodo Firewall is only good on default settings?

Help for v2
#1

This is an attemtp to get a refreshed appreciation on the content of my 2 previous threads, which i will post here, summarized.

1. Comodo Firewall takes quite some time - up to 10-20 seconds - to apply changes made to the rules, to the running firewall process. This can lead users into thinking their rules are not being applied, or that their machine is not safe. If not a security risk, adding an “Apply Rules” button to the graphical interface could solve this.

2. There may be some bugs or misconceptions implemented in the firewall process itself.
P2P and online gaming applications do not work properly - the default set of rules hinders or does not allow these applications to work properly and therefore the default set of rules needs to be changed by the user:

…2a. Adding a TCP/UDP allow in rule with specified ports with higher priority than the standard “IP block all in” should solve this problem for P2P applications. But from the tests made, at least Emule’s UDP functionality - concerning kadmelia network - was still severely hindered.

…2a. In order for online gaming applications to work, normally a allow tcp/udp rule, with unspecified ports must be added above the standard “IP block all in”. But, for some online games that have parallel anti-hacking processes run with them, the firewall can produce undesired effects - the game freezing, or not running at all. For these to start the firewall has to be entirely or partially disabled. This implies stopping the firewall process or at least the Component Monitor functionality.

The above was also verified with the “allow invisible invisble connection” and “skip advanced security tests” options checked for the tested applications.

3. The effects of adding allow tcp/udp rule, with unspecified ports are suspect and may indicate faulty firewall functionality:

Shields Up online security test, common ports scan results.
URL: https://www.grc.com/x/ne.dll?bh0bkyd2

http://mega.ist.utl.pt/~nemat/imgs/Clipboard02.gif

~Standard rules with result.~

http://mega.ist.utl.pt/~nemat/imgs/Clipboard01.gif

http://mega.ist.utl.pt/~nemat/imgs/Clipboard03.gif

http://mega.ist.utl.pt/~nemat/imgs/clipboard04.gif

~Altered rules with results.~

The allow tcp/udp rule, with unspecified ports added to network monitor allows a ping reply? Why?!

All windows services that were detected through the “scan for known applications” task were blocked for this test (alg.exe lsass.exe services.exe svchost.exe system.exe, etc), and the advanced options are set to default except for disabled “automatically approve safe applications” and “secure the host while booting”.

If understood correctly, for In communications the network monitor is the first line of defense. On default rules it blocks everything. But if one adds a rule above the standard IP block all in rule that partially disallows it - like allow tcp/udp in - the traffic is then analysed by the second and third lines of defense- Application Monitor and Component Monitor. Now… i did not allow any process to respond to that ping. What exactly is responding to it?
My guess is that the firewall allows for it to pass inadvertently.

Plus, if i remember correctly ping is part of icmp protocol - ICMP “echo request”, which should be blocked by the default IP block all in rule, so this whole thing gets even more bleak.

An added indication of a hole created by this is the fact that Avast! Anti Virus network shield starts to report attempts to use DCom exploits from different IP addresses soon after adding this rule.

On my previous threads i have pointed out that it could be a virus or a trojan, or other bad software in this system. But i’ve performed 1 offline antivirus test, 2 online security and antivirus tests, spyware s&d scan, hijack this! scan and log; and the fact that recently i’ve formated this machine and had disabled most of the uneeded winxp services, and applied most changes from SafeXP and xpy. So i’m rather doubting that.

Plus, my firewall should report it, no?

Thanks for the attention. Comodo Firewall is still great software. Feel free to refute any of the contents in this text.
fullmooninu

#2

No. The changes are instantenous. Why do you think so?

[b]2[/b]. There may be some bugs or misconceptions implemented in the firewall process itself. [b]2a[/b]. Adding a [b]TCP/UDP allow in rule with specified ports[/b] with higher priority than the standard "[b]IP block all in[/b]" should solve this problem for P2P applications. But from the tests made, at least Emule's UDP functionality - concerning kadmelia network - was still severely hindered.

You should never create such a rule. Always follow the tutorial pandolouk created for P2P applications. So you will remain stealth always.

.....[b]2a[/b]. In order for online gaming applications to work, normally a [b]allow tcp/udp rule, with unspecified ports[/b] must be added above the standard "[b]IP block all in[/b]". But, for some online games that have parallel anti-hacking processes run with them, the firewall can produce undesired effects - the game freezing, or not running at all. For these to start the firewall has to be entirely or partially disabled. This implies stopping the firewall process or at least the [i]Component Monitor[/i] functionality.

The above was also verified with the “allow invisible invisble connection” and “skip advanced security tests” options checked for the tested applications.
The allow tcp/udp rule, with unspecified ports added to network monitor allows a ping reply? Why?!

It does not allow. Shields up site is giving you wrong results.

If understood correctly, for [b][i]In[/i] communications[/b] the network monitor is the first line of defense. On default rules it blocks everything. But if one adds a rule above the standard [b]IP block all in[/b] rule that partially disallows it - like [b]allow tcp/udp in[/b] - the traffic is then analysed by the second and third lines of defense- Application Monitor and Component Monitor. Now... i [u]did not[/u] allow any process to respond to that ping. What exactly is responding to it? My guess is that the firewall allows for it to pass inadvertently.

Plus, if i remember correctly ping is part of icmp protocol - ICMP “echo request”, which should be blocked by the default IP block all in rule, so this whole thing gets even more bleak.

An added indication of a hole created by this is the fact that Avast! Anti Virus network shield starts to report attempts to use DCom exploits from different IP addresses soon after adding this rule.

On my previous threads i have pointed out that it could be a virus or a trojan, or other bad software in this system. But i’ve performed 1 offline antivirus test, 2 online security and antivirus tests, spyware s&d scan, hijack this! scan and log; and the fact that recently i’ve formated this machine and had disabled most of the uneeded winxp services, and applied most changes from SafeXP and xpy. So i’m rather doubting that.

Plus, my firewall should report it, no?

Thanks for the attention. Comodo Firewall is still great software. Feel free to refute any of the contents in this text.
fullmooninu

Thank you for taking time to evaluate CPF. But do not use shileds up to test network monitor as the results are not always accurate. It is better for you to use a second networked PC and all known attack tools.

Egemen

#3

My whole observation results were based on Shields Up test results. I can use another online test, if you like. Why is Shields Up test unreliable? Or why is it only reliable to test with a networked pc? I’m sorry but i would prefer to feel safer using this kind of online tests, because i do not connect through simple Ethernet. On my main machine i only use an internet adsl (dial up) modem using PPPoE Multimode, and the device is only running TCP/IP and QoS.

So, before you answer the above, i will only discuss where it does not directly concern Shields Up test.

You should never create such a rule. Always follow the tutorial pandolouk created for P2P applications. So you will remain stealth always.

By Pandolouk:

EMULE A mini tuttorial of how to open ports for emule First you must go at the "Network Monitor" panel. There you should click with the right button of the mouse and choose "Add rule"->"add" at the new window that appear you should put the following rules:
  1. Rule for TCP protocol

Action = Allow
Protocol = TCP
Direction = In
Source IP = Any
Remote IP = your IP adress (you can also use “Any”, if you are using a modem and not a router; by this you won’t have to change the IP address every time you connect in internet )
Source port = Any
Remote port = the port your Emule uses for the TCP connections

  1. Rule for UDP protocol

Action = Allow
Protocol = UDP
Direction = In
Source IP = Any
Remote IP = your IP adress (or “Any” )
Source port = Any
Remote port =the port your Emule uses for the UDP connections

I have read most if not all of the Comodo Firewall’s FAQs section and was aware of this.
I beg your pardon but your recomendation makes almost no sense to me:

The only difference from what i did - i don’t have a static ip - is that he suggests the creation of two separate rules, one for udp in, another for tcp in, both with only with one port.

Like i said above, I would just create one rule, allow tcp/udp with two specified ports. This because i mostly use Shareaza and Emule, so i add an extra port for shareaza traffic, making it allow tcp/udp with 3 specified ports.

Regarding only Emule’s use, admittedly his rule is a bit safer, as he does not allow tcp in traffic on the udp in port and vice-versa. But really, the safety difference seems negligible to me. Is it not?

I would be reported being stealthed by the Shields Up test, if i only use this rule, true. But that is because the ports Emule uses are out of the tested ports range.

Thanks again for the attention. Feel free to refute any of the contents in this thread.
fullmooninu

#4

I dont say it is unreliable. It sometimes produces incorrect results. But this is very rare. I am sure other test sites also produce wrong results from time to time.

By Pandolouk: I have read most if not all of the Comodo Firewall's FAQs section and was aware of this. I beg your pardon but your recomendation makes almost no sense to me:

The only difference from what i did - i don’t have a static ip - is that he suggests the creation of two separate rules, one for udp in, another for tcp in, both with only with one port.
Like i said above, I would just create one rule, allow tcp/udp with two specified ports. This because i mostly use Shareaza and Emule, so i add an extra port for shareaza traffic, making it allow tcp/udp with 3 specified ports.

According to your image snaphot of network rules, I thought you allowed for all ports instead of specified ports. So you are doing right if you allow only specified ports.

I would be reported being stealthed by the Shields Up test, if i only use this rule, true. But that is because the ports Emule uses are out of the tested ports range.

When you allow TCP/UDP IN from shieldup site, it is obvious that you dont want to remain invisible against TCP/UDP probes. But there is no way for CPF to allow ICMP ping requests unless you explicitly allow. If you have previously allowed ICMP IN from shields up site, as you may have noticed, you need to wait for 30 seconds to 3 minutes before the new ICMP rule takes affect. But according to your images, there can not be such a case. Because you did not play with ICMP protocol or any other rule that affects ICMP protocol. Or if you did, you need to wait at most 3 minutes before establishing any other ICMP relationship with that site.

Hope this helps,
Egemen

#5

Yes i agree. There is no way i should be respoding to PING requests. And yet i am. But only if i allow all tcp/udp in traffic. I didnt set any rule relating to icmp, so it should all be blocked, like you said. But it isn’t.