I recently installed the latest beta (2.3.2.21), and had to fight long to figure out why I couldn’t get an IP through the DHCP of my ISP. I ended up in finding the culprit option: I once turned on the “Secure against Trojan protocols”, as as supplemental layer of protection, and this was it that prevented the DHCP lease process!
Didn’t take time to fire up a network analyzer to dig deeper, but after each resuming from hibernation, I had lost my IP and I saw the consequent “limited connectivity” icon in the system tray. Trying to use the “repair” option of the “network connections” applet of the Windows CPL didn’t help: it was stalling while trying to renew the address. And of course, I got the same with the straighter “ipconfig /renew”.
Once I finally identified “Secure against Trojan protocols” as the faulty option, disabled it, and rebooted, all reverted to the normal.
So it sounds that this option has negative effects on the DHCP IP lease process. Moreover, looking at other threads of the forums, I can see it is very often recommended to turn it off. So I wonder if the logic behind this option is actually stable and reliabe, or is this just an experimental feature?
Well… as documented it sounds useful to counter some tricky malware, but would be nice to know what kind of conflicts it can cause, and thus in what situations it could be turned on or not. Otherwise, I can’t see the usefulness of this option, and keeping it in the configuration screen is just a trap for the user trying to improve her/his security… :-\
It is as you said the ultimate protection against malware(I am not aware of any using such a technique). Average user computer does not need that option to be enabled unless it has paranoid security requirements. When you go out of the realm of TCP/IP protocol, non-standard protocol implementations can cause unpredicable conflicts. The name of that option has been changed in the next version and a more clear explanation has been put.
hmm, when I reported bugs with several things, You’ve givin me the same kind of nonsense explaination.
ftp, telnet, dhcp, and other protocols, are REAL base protocols. And not “non standard” are whatever you think, shall I point you to the RFC’s so you understand what a BASE protocol is?
I don’t mean to be a bit rude, but stop treating us all like were computer noobs.
You want beta testing, we’re beta testing, accept the bugs and look into them please. This is a nice product, and doesn’t need that kind of attitude, or your going to chase your customers away.
??? seriously? So you’re telling Comodo is in advance on malware writers, and has already imagined the next generation of attack, hmmm good suggestion for black hats OK, just kidding, but I agree with Scott, let’s be serious: if you provide this option, this is because it is supposedly useful, it is meant to counter some kind of attacks. Consequently, it should not prevent basic networling mechansim (like DHCP) to work, otherwise it is un-usable even if it is a great countermeasure!
What’s this? IS this option meant to protect ourselves or a playground for geeks? BTW, I hate to say but I’m involved in networking and security dev, so let’s consider I’m not an average user, so could you please be more precise and concrete?
Please, as requested by Scott, have a bit of consideration for your beta testers, and accept for a minute that they could have also some knowledge in networking and related security
I guess from time to time, we can be misunderstood. I dont know why you thought my attitude was offensive, but nonetheless, since you get it that way, please accept my apologies. We are all the members of the same comodo family.
Regarding your reports, we did take them into account seriously, For example one of them, about malware tampering resistance, has already been added to the upcoming version. And this is because of your feedback.
Now lets turn our attention to trojan protocols.
Secure against trojan protocols option has nothing to do with those standard TCP/IP based protocols. It is about NDIS protocol drivers. So in this context, protocol does not have to be any RFC defined protocol. Actually those standard protocols are implemented as TCP/IP stack in Windows.
A possible scenario:
A malware creates an NDIS protocol driver and installs it. And then by using that protocol driver, it sends packets by directly accessing the network interface without using TCP/IP protocol thus effectively bypassing the firewall. An example of such a protocol driver is the winpcap protocol driver.
For your case, enabling and disabling of this option have no direct effect on DHCP which is TCP/IP based. The problem you are facing is extremely dependent on your machine’s configuration and hard for us to reproduce.
With the future releases, we are going to replace that option with a better defense mechanism. But since many of our users have experienced similar problems, for the upcoming release, we have changed the misleading name and put a more clear explanation.
Sure. It should not be directly related to this option. Do you have Secure the host while booting option enabled?
What's this? IS this option meant to protect ourselves or a playground for geeks? BTW, I hate to say but I'm involved in networking and security dev, so let's consider I'm not an average user, so could you please be more precise and concrete?
Ok.
We will be replacing that option with a better defense mechanism. That option is about monitoring NDIS protocol driver other than TCP/IP(tcpip.sys). So in your case, if it is not about secure the host while booting option, then it can be because of an improper handling of hibernation(PNP event handler) of NDIS IM driver of the network adapter you are using. That option is too much dependent on the underlying hardware interface.
Non-standard protocol is just that! Non-standard! We are talking about “home-made” protocols by malware in an attempt to go undetected! We don’t assume that all malware will use only the “standard” protocols. Because they can also create their own protocol and not use TCP/IP in an effort to go undetected!
We do appreciate all the help you are providing and noone is mistreating anybody guys! Its just that there is a misunderstanding that some of us thought we are referring to ftp, telnet, dhcp when we say “non-standard”. We are not! when we refer to “non’standard” protocol we mean any protocol that has no standard!
Please keep the feedback coming guys, its been really valuable!
However it is related to this very option: as initially stated, I once enabled it and from that moment (I figured this afterwards of course) I had issues with my IP renewal through DHCP. Yes I have secure while booting enabled, I turned it on at the same time, but from my experiments it is not in cause: I’m currently using CPF with “trojan” (let’s call it as is to simplify ) option off, and “secure while booting” on, and all is fine: DHCP renewal and everything else.
Well… I don’t think so (PNP), indeed as soon as the “trojan” option is on I can’t get an IP after resuming from hibernation, but this is also the case if I retry after boot is complete. The only way to get one (apart from disabling that option and rebooting) is to stop CPF, renew my IP (works fine), and restart CPF. What confirms (FMPOV) that this is not actually an hibernation issue, is that once all of this is done, if I ask again to renew my IP, the process is again freezed, hence the relation with CPF.
And once again, once this “trojan” option is off, everything works like a charm, and without having to tweak CPF.
Anyway you have a great product, and it is really appreciated you are willing to improve it, and you are so reactive on your forums, and above all … for free, thanks guys.
Actaully, I created this thread because I was just surprised of the link between this option and DHCP and find it regrettable, and I thought that by mentioning it, that could possible to ring a bell in your dev team, and highlight an un-estimated bug…
I give my sincere apologies aswell, sorry for any confusion.
I have turned off the trojan protection, and I also use secure host while booting.
Also I understand how mean non standard now, hehe… that is an interesting thing.
I have managed to make most of my programs work now, but I still have a problem with ssl over ftp (sftp). Maybe you can have a look into that. Or is there some explaination , which I can solve by adding a rule. I have already setup to allow the ports, and moved it up in the list.
What do you logs say about this? Logs would show what CPF is blocking while sftp sessions are established.
If u are not using BETA, you need to activate “Create an alert when this rule is fired” option for BLOCK IP IN FROM ANY TO ANY… rule.
But without any rule, you can always force your FTP client software to use PASV(passive mode, a.k.a. firewall friendly mode) to overcome any difficulties.
I am of course, using the beta, or I would not be posting in the beta threads.
I am getting connection attempts shown in the log, but the firewall is blocking it no matter what I do.
I transfer sensitive information to and from work and customers, so I must use a secure connection for this while I am at home. I am not sure I can use passive mode with this configuration.
I will try to setup firing a log on all ip connection and try to track down the problem.
OK, just kidding, but I agree with Scott, let’s be serious: if you provide this option, this is because it is supposedly useful, it is meant to counter some kind of attacks. Consequently, it should not prevent basic networling mechansim (like DHCP) to work, otherwise it is un-usable even if it is a great countermeasure!
CPF, renew my IP (works fine), and restart CPF. What confirms (FMPOV) that this is not actually an hibernation issue, is that once all of this is done, if I ask again to renew my IP, the process is again freezed, hence the relation with CPF.