Good Job glifford :-TU . Your help & effort is appreciated 
Yep good job, but are they going to implement any of this? or the whishlist is going to be like the last years? nobody cares the opinion of the users.
Everybody would like to have the same experience than Melih:
https://forums.comodo.com/general-discussion-off-topic-anything-and-everything/the-reason-why-i-left-experience-t55867.0.html;msg393991#msg393991
But the only important thing is the Melih eXPerience, not the costumers eXPerience.
That and the endlessly repetitive sound of self trumpeting. 88)
I’m back! I should have some new stuff up next week for you guys.
Consider proposing the fixed prioritization of network rules in order to remove the useless global rules: Some rules should be marked as always in first priority, some rules always in last priority. That will make global rules redundant.
Considering fixing the NETWORK CONTROL RULE screenshot. It displays an IPv6 address but the mask is from IPv4.
Finally, the APPLICATION SYSTEM ACTIVITY CONTROL proposal is good but still far from perfect. Having worked a lot lately with advanced Defense+ controls, I can tell you that the main problem is that you still don’t have a comprehensive look on all permissions but rather you use a “Modify” button for any change (and there are many). The “Ask” default action is misleading. In many cases it isn’t “Ask” but Block * (which is effectively block) or Allow *.
So I would propose that the “Ask”, “Deny” or “Allow” is removed and replaced by small textboxes which display all the rules inside.
Too complex for the average user, even a savvy one. There should be a choice between your detailed proposal (“expert mode”?) and the current behavior (“guided mode”?)
It is a complex issue; Tweaking Defense+ requires knowledge and patience but it is rewarding in ensuring a practically 100% secure system.
The current UI on Defense+ settings is deceptively simple. It cloaks the inherent difficulty with a veil of simplicity but in reality it complicates things even more. In the following example (attached image), according to image 1 the Windows/WinEvent Hooks policy defaults on Ask, right ? Wrong. It defaults on block according to image 3. And what is the cascade for image 2 ? Does Allow rules precede Block rules ?
It’s unclear and it’s unhelpful. I find it much more clear to have a UI such as image 4 which looks plain enough to me (as plain as it can be) and which would lead to much more interesting scenarios in the future such as image 5…
[attachment deleted by admin]
I’m gonna try banging out a full-fledged prototype of your idea vix. It strikes me as interesting, and more consistent with network rule management.
And with regard for maintaining a basic-user’s options, such basic settings could be found in the rule edit/creation window. And since the APPLICATION SYSTEM ACTIVITY CONTROL window and the (I guess we’ll call it) SYSTEM CONTROL RULE window would go hand in hand, I suppose I’ll look at banging one of those out too.
In the meantime, if you can think of some more advanced operations/ variables to add into the mix for rule creation, don’t hesitate to mention them. And I think your idea is big enough the warrant its own thread.
Also, nice catch on the network control rule window. And I agree with you on replacing global rules with first priority and last priority rules.
ATM Global rules appear to have different priorities based on traffic direction.
The result is that Global rules seemingly have “top priority” for inbound traffic and “last priority” for oudbound traffic.
Global rules also apply to applicationless traffic which might not be trapped by “All applications” Network policy
I find difficult to imagine how the above mentioned aspects would be retained in the different design.
It is not unlikely I misunderstood how it is supposed to work and I would appreciate an eventual clarification:
eg: Would an High priority rule for Outbound traffic be applied before any application policy?
What would be the steps needed to apply additional filtering for all outbound (including applicationless) traffic after application policies have been enforced?
[attachment deleted by admin]
I believe this is perfectly within glifford’s intention for a complete UI overhaul and it is in particular an issue where a better UI could help more users realize the power Comodo is already offering them.
In order to reply to Endymion, I first need to point to the default Global Rules policies:
However, these policies can already be redundant by applying the cascade Comodo is already using. In particular, my own Global Rules policy is simply:
And that rule is because it is currently impossible to have the same application twice in the Application Rules. The reason of this simplicity is that my application rules have been conceived based on my old experience with Kerio Firewall 2.1.5. As you can see:
All applications, even those who are blocked by later rules, can communicate freely on my trusted network. (255.255.255.255 is the local broadcast address). Then Comodo’s default incoming Global Rules (the various ICMP) denyings kick in.
The rest of the applications have their own specific rules. For example, Outlook is not allowed to connect to e-mail tracking web sites, but it does download e-Mail without issues. However, Outlook would still be able to display images coming from my local webserver if I wished to.
Mediacoder is a very good example in this configuration. This very useful application has some suspicious adware features built-in while at the same time requiring localhost access. That’s no problem here because my LOCAL network zone includes localhost. Thus Mediacoder can run its localhost server but it is still unable to communicate with the broader internet.
All thanks to the cascade.
The problem with the current implementation is that new rules go above the current ones and I need to manually place them in the right order (under the first All Applications rule). Fortunately this happens very rarely.
Another issue is that since I can’t place a second rule for All Applications in the bottom (Comodo complains that “this entry already exists”) I still need the Global Rules for that PROTOCOL UNREACHABLE issue.
Now, my proposal to glifford is this:
Design a network security policy without the Global Rules tab
- Provide some means to make the cascade clear (I believe Glifford will be using numbering for this)
- Allow some rules to stick on the top.
- Allow some rules to stick to the bottom (in most normal scenarios the last rule of these would be “Ask”.
- And the rest of the rules would be inserted under the top ones.
[attachment deleted by admin]
The ICMP rules in the picture do not have a logging flag set so it would be expected to not have such packets logged.
[s]I might be wrong but AFAIK “All applications” policy cannot be used to trap Inbound ICMP which is applicationless traffic. ???
Did you confirm if those rule worked by enabling Logging?[/s]
Did a quick test with traceroute and logging ICMP 11.0/In and it worked. :-[
Guess this applies only to unrecognized applications whereas new policies (created by alerts) for those applications are added on top and the policies for safelisted applications are added at the bottom (If create rules for safe applications is enabled) without alerts.
The alternate GUI design will have also to amend this behavior.
In the “All application” policy scenario you provided the allow LOCAL connection will prevent the need to create policies for unrecognized applications that are limited to the local zone.
Guess it should be possible to add a different Group eg “2nd All applications” that match all applications paths (*). Never tested eventual uses though.
If I understood correctly the above paradigm would somewhat apply also to a “Block all incoming connections - stealth my ports to everyone” scenario albeit using a different set of rules (ie removing all allow rules ) for a topmost "All applications " policy
The core of the new paradigm is seemingly based on a new behavior/design for policy placement (eg top/bottom sticky policies) and special purpose policies (to fill in for some aspects of Global rules)
As far I see it would be potentially feasible supersede “Global Rules” hope tough it would be still possible to leverage on the current approach as an option (perhaps disabled by default)
[attachment deleted by admin]
This is getting fun! Ok. So with regard to implementing the high/low priority rules…
If we remove the tabs and put everything in one list, such that “High Priority” behaves somewhat like a file group that always stays up top, and “Low Priority” always on the bottom, the scrolling or navigation to get to each one becomes kind of tedious. - Though I guess, no more tedious than finding a specific application.
The other option would be to add another tree-level to the list, such that applications are all shoved into an Application Rules group, which sits sandwiched between the High Priority and Low Priority groups.
The last option I can think of is just adding tabs, in the correct order, for High Priority, Applications, and Low Priority. If people get confused there’s always a help link.
I think I actually rather prefer option 2.
Though Endymion jogged my memory. Back when I was using outpost, there were high priority, low priority, and low-level rules (which applied to non-application specific traffic).
I think renaming High and Low Priority to Before and After Application would be more intuitive (and I think the way its labeled in outpost). And either from left to right or top to bottom: Low Level > Before Applications > Applications > After Applications
Yes, endymion is right. ICMP rules make sense only in global rules. I fixed that on my configuration.
Glifford, tabs are better than a long list but it would still make sense to merge global rules in the first and the last tab since they do have a cascading function themselves. Naturally global rules would have no applications attached to them.
I’ve read all your work and it is absolutely amazing. I love ALL your suggestions and they shorely can push Comodo further.
I really hope to see this implemented in a nearby future!
Totally agree, and i also think this post should be “Sticky” =)
@glifford
you’ve done a great job here,
we can just hope your these get implemented soon
@mods
why isn’t this topic “sticky”
This is more like a thread in the Usability Study Group, currently in the wishlist. Very good thread, mind you, a lot of thought went into this, but it is not something to sticky, imo.
mr. glifford you/Comodo can use CIDR instead subnets, so you can get rid completely of subnet mask addresses space in GUI…
more about CIDR here: Classless Inter-Domain Routing - Wikipedia
example of my local network address range with subnet mask:
192.168.0.2/255.255.255.0
example of my local network address range with CIDR (in just one line):
192.168.0.2/24