New Matousec firewall test, we got new leader...

Iam sorry guys..

You are absolute correct regarding OA and Outpost.. That was a silly post of me. I got nothing to back it up with, and I don't believe what I posted earlier.



I made a mistake and Iam sorry..

Won't happen again. Sorry.

 

Never mind. In any case this didn't look like your own idea, this was more like Melih's idea. Take my advise, put Melih on your twit-list, this will save you from a lot of silly ideas and situations.

 

Maby you are partially right. I presented comodos stance on those tests and made a bad assumption about 2 companies without doing the research.

Anyway lets not get off topic entirely. Iam sorry for what I said some posts earlier I admit it shouldn't have been said.

 

Me too. That's what I like about Mike Nash at Tall Emu, the CEO who makes OnlineArmor.

 

Guys, let's not turn this into a fan boy flame fest

It all depends on the user TBH. If a user get's a pop up and says "Keylogger detected", and say the program was a crack or keygen, that user may still click "Allow" no matter what it says in the leak test.

Secondly it's all up to you on what you prefer in a firewall and/or HIPS. If the firewall/HIPS suits what you want, and protects you the way you want to be protected, there should be no argument as to which firewall/HIPS is better.

Also, Online Armor has NOT been retested, and as for Comodo, I'm sure they have made a wonderful product but that is not to say there are no cons which match the pros of the firewall. And yes, the same can be said for OA and all the other firewalls.

 

In my tests OA public RC passes all the tests previous version failed, so theoretically it should take 100% if tested. But I think they will not release just to take the first spot on Matousec.

 

WTF.
Is it really that important? People will choose their preferred product. Most do not even give a thought to the forums of Wilders, Matousec or Comodo

Just my 10 cents
Xui

 

I think his videos and post are nearly as funny as Monty Python, I am not a Comodo user but, happy to read his blog etc (and have to give Comodo credit to make available a sound FW for free).

Cheers Kees

 

Or use a test like I did ("through the eyes of a keylogger" PoC) and get a Trojan for free, first real infection in five years or so. It is what you say, you know, but you still click okay.

 

Haha. By the way no one has said it is a trojan yet, but oh wells Plus it was a generic detection

But yep, if you trust something (or do not think it is malware), you will most likely click OK, despite the warning, and therefore become infected (if it is malware).

 

I do! Wilders is where I get my education. After only 8 posts how would you know?

 

Please read Egemens answer and than come with arguments if you beleve he is not right. You are welcome on Comodo forums for a discussion with him

But what you are doing now is just trolling

Greetz, Red.

 

I posted the list of the failed tests and my understanding of what can happen because of those fails. I don't think those fails are unnesesary to fix. But, Jeez, why should I go to Comodo forum ? It was said here (about unnesesary tests) and this is why I argue it here. And I would be glad to meet Egemen here. I think he is a nice guy, professional developer and interesting person, but this is his chief who spoils all the party and forces him to say what he probably doesn't want to

For me this is quite obvious, that failed crash test is a security hole. I don't believe anybody can argue it being professional enough and sincere enough.

The only questionable failed test is SSS, but since this is actually questionable I leave it without comments. Though, coming from the fact other products can handle it gracefully, I think they'd better did it.

 

Maby that can be argued.. But according to Egemen CIS still intercepts everything even after such a crash.. So security isn't really bypassed.

This is his own words about it:

 

Do you realy beleve that You are a funny guy

Greetz, Red.

 

How crashed application can do its work. And if that application did nothing security-related, why it is in the pack ? My logic is very plain - every program in a security pack is security related. If it crashes this is potential security hole.

Let us take example with FF. There was issue reported that some tricky style xml can crash FF and POTENTIALLY can cause arbitrary code execution. FF team didn't come with the long explanation that in real world the chance this bug hardly ever can be exploited. Instead they admitted the bug and came with "will be fixed as soon as possible".

Security is a field where there is no space for the words like "real world differs from tests, low chances, crash is not a hole". Professional security can only admit reported bug and immediately fix it. Any other approach kills a trust in a vendor, especially when a vendor tries to explain that "a crash is nothing to be worried about, because this is random and other parts still work". This "explanation" can work for nonprofessional users, but ANY security expert woudl make a laugh of this "explanation" in the best case and would go very angry in the worst case. A crash says there is something wrong, and since developer cannot fix it, this "something" can potentially have unpredictable outcome.

I want that you got me right. This is not a bug that matter, there is not just a single complex application all over the world that would be bugfree. This is vendor's approach that matter. The only approach for professional security is "accept and fix", any other approach is nothing but demagogy and unfair marketing.

Another example of unfair (I'd say dirty) marketing is CMF. Comodo site states this is "Ultimate" protection from BO attacks. But this is not true. For one you can easily bypass CMF just moving malicious code from heap or stack to legitimate memory before calling any API, for two DEP is much more effective because DEP intercepts not only API calls that originates from heap or stack, DEP prevents execution of such a code.

This is what drives me nutes. And which drives me nutes even more this dirty marketing strategy is very effective ! But if product quolity was the same as marketing, I'd say "Kudos, Comodo". Instead I see that it just fools the people. Gosh. I promised to myself not to jump in Comodo related topics, but this appeared to be beyond me. I just cannot stand such things, sorry.

 

Even if no Comodo processes are running all unknown operations will be blocked - there is absoulutely no security risk. And I bet if Comodo wanted to they could easily add "protection" for this test like they could do it for socksniff (U read egemens comment?).

Well, I personally don't need BO potection but it has been updated with ver. 3.9 beta. Maybe it's better now.

And alex_s, you said that Comodo wasn't able to protect other processes because of kill3f...
Does OA or any other HIPS perfectly protect other processes? The reason why CIS "failed" this test is just because it brings with it an optional process which is not even needed anymore for anything, if other HIPS or firewalls would bring optional processes they would maybe also "fail" some tests.

Don't make Comodo products as bad as Melih or some other people in their forum are...

 

Can somone tell me what the memory usage is for Comodo filewall alone and with HIPS enabled? (If there is a difference). Thanks

 

On my setup cfp.exe running at about 4,500k,cmdagent 2,700-4,800k. (Everything enabled)

 

Ufff ... This is not memory usage, this is working set size which can be set programmatically despite of the real memory usage. Real memory usage approximately is virtual memory usage in standard task manager and "private bytes" if you use process explorer, that includes the memory that is really allocated and used by a program but is temporary pushed out to a swap. Also pagefaults and CPU time do matter. To show approximate resource usage you need to show something like this:

 

I got one question: Detects OA it if a programs want to hide something in an ADS?

Btw: You all got just 512MB ram or why concerning about it? I can't get behind this...

 

Yes, ADS makes no difference. I'm not sure does it stress the fact something is in ADS or not (thought it was requested), but operations with ADS are treated like the normal file operations.

 

Of course but I answered the question in the context I feel it was asked.Most average users compare products based on resource usage as shown in task manager,not random,variable usage within specialist software such as the admittedly good Process Explorer.Also throwing out terminology such as CPU time and the likes just flies over the head of most folks.

*Edit*Here's a more detailed appraisal for you.

 

Yep, most users compare the resources coming from taskmanager default picture, but this can be very misleading. When I tested Comodo it took over 50MB of RAM and in TaskManager it showed very low memory usage. I think people want to know real memory usage, not fake. It is possible to set 1 MB working set for a program that really takes 100MB.

SetProcessWorkingSetSize(GetCurrentProcess(), 1024 * 1024, 1024 * 1024);

This call will make ANY program to use 1MB of memory in TM.