Done
I really had problem understanding this thread… ???
Why don’t you use Not in range (or zone)?
It would be interesting to export cpf setting before and after rules sorting (maybe the rules are saved the same way but displayed differently)
You’ve lost me gibran ???
Well… you can use block not in zone in app monitor too…
Hmmm… I assumed that Appmon rules were not hierarchical so I would have used allow zone and deny not in zone instead of
Path- C:\windows\ Explorer.exe
Parent- C:\windows\System32\Userinit.exe
Destination- [LAN]
Port- [ANY]
Protocol- TCP/UDP In
Permission- Allow
Path- C:\windows\ Explorer.exe
Parent- C:\windows\System32\Userinit.exe
Destination- [LAN]
Port- [ANY]
Protocol- TCP/UDP Out
Permission- Allow
Path- C:\windows\ Explorer.exe
Parent- C:\windows\System32\Userinit.exe
Destination- [ANY]
Port- [ANY]
Protocol- TCP/UDP In
Permission- Block
Path- C:\windows\ Explorer.exe
Parent- C:\windows\System32\Userinit.exe
Destination- [ANY]
Port- [ANY]
Protocol- TCP/UDP Out
Permission- Block
[attachment deleted by admin]
I can also confirm the speculation on this thread that the AM works in an entirely non-sensible way.
Ideally, I would love to have absolute control over application access rights. If I want my webbrower to access only outbound port 80, and block everything else, then I should be able to do this.
Currently, this is only intermittently possible. AM is not supposed to have a hierarchy, according to what I’ve read. The problem is, is that it DOES have a hierarchy. The rule order DOES effect how the AM behaves. The problem is, the user has no reliable way to control what this hierarchy is.
The AM should have a fully functional hierarchy. This is the way most other firewalls behave. I say, in V3, hierarchy control should be added to AM (similar to what is in NM). Furthermore, it would simplify things immensely if it were possible to “group” applications, to prevent a tediously long AM list from forming.
If those two features were added in V3, all of the major AM problems would go away.
My two cents,
-PW
[li]
The things explained in this thread have a great value in pointing out how cpf works.
AFAIK if you don’t assume AM rules to be hierarchical you can still have control over application connections.
If you want app.exe to connect only to port 80 you need only four rules if alerts are enabled.
[+] Allow tcp-out to port 80 destination any
[+] Block tcp-out to NOT port 80 destination any
[+] Block tcp/udp-in port any destination any
[+] Block udp-out port any destination any
Regarding AM rules evaluation order preferences it would be a great candidate for inclusion in CPF whishlist as an alternative option.
Please keep in mind that if you enable a NM like evaluation order a default ASK rule (Destination ANY, Proto ANY, Port ANY, Direction IN/OUT) in AM will be needed as long as Enable Alerts option is checked (Defalut Setting) in CPF Security|advanced|miscellaneous. But if that option will be unchecked, all those ASK rules are to be converted to BLOCK
Yes. As I mentioned, it is possible. It just seems somewhat convoluted and frustrating. I’m aware that there are ways to make it work without a hierarchy. I’m also aware that AM was designed to operate without a hierarchy.
My point was, the hierarchy DOES exist. Rules that are higher on the list DO take precedent. Regardless of how the AM was designed, the hierarchy does appear to be there. It only takes a marginal amount of testing to figure this out.
Essentially, there is very little the user can do to control the hierarchy unless they are absolutely sure their rules don’t overlap in any way. This is a problem, because if the rules spontaneously change order (as they often do), it can change the behavior of the firewall.
While it is very much possible to get AM to work with further configuration, it is very unintuitive. Most firewalls with application controls (outpost, sunbelt, even back to atguard) have a hierarchical rule system. Its a standard that works quite well, and is time tested. It’s also what people expect when they install a new firewall.
AM is confusing because it gives them the illusion of a working hierarchy, but is actually supposed to work in a non-hierarchal way. I’m noticing from this thread that I’m not the only one who has been confused by the system comodo uses. While I do understand it now, its been a headache up until this point.
I added my request to that thread. I thought I’d mention it here to, since that seemed to be specifically what this thread is about.
Cheers,
-PW
Sorry, I misunderstood this part of your previous post. It seemed to me you were stating cpf was not able to do that permanently.
Hierarchical rule evaluation behaviour is evident when conflicting rules are set. I considered that AM rule evaluation was not hierarchical because there weren’t any move up/down button like NM so I designed AM rules assuming that I was not able to control the evaluation order. When conflicting rules are set is up to the firewall to choose evaluation order. Luckily CPF evaluation order matched the relative AM rules displaying order…
I have nothing against hierarchical rule evaluation but I’m against the elimination of current AM evaluation behaviour because it would be confusing for users tied to this rule handling behaviour.
I can think of no reason why the current system has to be eliminated in order for an hierarchal system to be fully implemented. Realistically, we are only talking about the inclusion of up/down buttons. That would allow for users to creating overlapping hierarchal rules (like blanket policies), but would also allow users to implement a non-overlapping system that is embedded currently.
The two concepts aren’t different enough to have to decide on one or the other.
Cheers,
-PW
gibran
Are you saying AM does NOT have hierarchical rules?
This just in from Comodo Support:
Application monitor follow hierarchy or order only when we have more rules for a single application.Instead of using 4 separate rules for an application as you mentioned in
that thread, you can use exclude option to bring them together into a
single rule.Moreover, we are changing the entire architecture of Application rules
in our next version, Comodo Firewall V3 which is expected to be released
by mid of june 2007. Meanwhile kindly bear with us.
Looks like gibran’s “exclude” option takes the day…! And that v3 will be different…
LM
Nope, I said that hierarchical rule evaluation behaviour is evident when conflicting rules are set.
But if you wish we could add more insight to this thread aiming to find out what led comodo developers to this solution.
We can say stright away that every data in pc has a baseline hierarchical representation (endianness) , even grouped data with each element sharing the same hierarchical value is represented in an ordered (indexed) way. We can also say that concurrent threads aren’r really handled in parallel even in a preemptive multithreading environment using one processing unit.
This means that on order to bypass this intrinsic hierarchical behaviour some overhead is needed. (:NRD)
What about CPF?
[+]CPF rules have an indexed representation
[+]CPF needs to cope with concurrent connections
[+]CPF has Learning Mode (alerts) enabled by default in AM
[+]CPF should have a memory copy and a stored config copy of AM rules
[+]CPF have to sincronize these copies all at once or needed parts only. (Does CPF have all AM rules in memory or load only part of them when needed?)
In order to handle efficiently each connection CPF should have a preferred rule parsing order:
eg: [(Application → Hash → Parent) → (Protocol → Direction → Port → IP)] → Action
This way there is no need to parse an entire rule to verify a match. If no matches are found either an alert is displayed or the connection is blocked (depending on your Miscellaneous Settings)
Then we should consider the in memory ruleset working copy which has to be entirely parsed to handle a connection if it is left unsorted.
When the ruleset is sorted only a subset could be parsed.
With this logic in mind it would be unnecessary to sort the CPF GUI ruleset list when is only needed to sort the in memory ruleset working copy. Maybe the two lists are sorted with different priorities.
Regarding ruleset sorting, only Application → Parent sorting should have been needed, then it could have been possible to archieve a hierarchy within each Application-Parent group but Comodo developers didn’t set a relative priority field for each rule of a group.
So the current behaviour is bound to CPF rule handling behaviour (Sorting, Collapsing, Creation, Modification, Deletion) and its effects on the in memory ruleset working copy.
If it was possible to selectively disable alerts (which results in blocking not explicitely allowed connections) on a per application basis instead of on a global basis then it would be possible to get your desired behaviour (and it would be also safe in case that such option will be maliciously altered)
One thing to note is that using a nonhierarchical ruleset it would be possible to achieve an adaptative (in memory) sorting and let the most frequently evaluated rules to be put on top in the grouped lists. This way CPF will learn day by day the fastest way to handle a complex ruleset.
gibran
Whist I agree with a lot of your comments, I have my doubts about the way CFP handles in memory data. It is my belief that SPI is responsible for determination of the connection and the packets, either allowed or blocked.
I agree there has to be some memory resident portion of the AM rule set, but how that is updated, relative to the way changes can be made to the AM rules, is a little puzzling.
I used CPF in a generic way but you guessed right.
I think that NM (inspector.sys) SPI work on a separate level whereas cmdmon.sys handle the process/component/application side (validation and connections).
Regarding Appmon rules. I think these fields should be relevant for the sorting in cpf gui
Each app-parent has many subkeys
“AddrType”=dword:00000008 type of option (maybe used for optimization too i hope)
“AddrStart”=“0.0.0.0”
“AddrEnd”=“255.255.255.255”
“PortType”=dword:00000002 type of option (maybe used for optimization too i hope)
“PortStart”=dword:00000000
“PortEnd”=dword:0000004f
“Protocol”=dword:00000002 bitmask (0-f) udp out(2^3); udp in;tcp out ;tcp in (2^0)
“Response”=dword:00000001 block rule (allow = 0)
“NumConn”=dword:00000000