Unify sentinel navigation

This is a pure UX issue.

In the user documentation and other public channels we try to emphasize two main parts of Sentinel: threat detection and the dynamic firewall. We should reflect this more obviously in reForis.

IMHO there should be three sub-navigation items in Sentinel reForis plugin:

• Overview: with the current state, no setting, maybe some statistics & link to sview
• Threat Detection: EULA, minipots, haas etc. - mainly settings
• Dynamic Firewall - mainly settings + maybe some live changes

This is how I see the final state should like from the technical & user point of view. It assumes some features that are not ready yet but these features are not crucial and the unification should be made even without them.

The overview:

I like it.

I am not sure if we do not duplicate the top-level overview page. I think that it would make it even better to see some statistics in there over having to navigate to the dedicated page.

I would also move the button for viewing statistics in view to the block for threat detection itself.

I am not sure if we do not duplicate the top-level overview page.

I was also thinking about that. Maybe yes and from that perspective there should be no Sentinel Overview at all. But I would rather keep it - I think that Turris Overview should contain only the basic info - whether it Sentinel works or not. Sentinel Overview that should offer more closer look and the statistics.

I would also move the button for viewing statistics in view to the block for threat detection itself.

The Thread Detection and Dynamic Firewall sections than should be there mainly for configuration.

The threat detection:

I like it.

I like the idea of mashing together the license agreement and the configuration.

What I do not like about this is the "hidden" HaaS token. It is now last but user needs to insert token there to get it functional. I would keep it separate. I know that it is threat detection as well but it requires dedicated setup steps, approval of different license and data are not accessible directly in Sentinel View but in its own dedicated page (well that might be just for now). In total this makes it confusing in my eyes.

The last point is the consistency of sentinel device token block. Is it planned that user can insert its old device token? I thought that it is expected and then there should be rather the "Save" button instead of this one. I would just add button (something like refresh) to the right side of input field (for example how "show password" buttons are implemented) that would generate new device token without saving it to the configuration file (that would be done by clicking on save button).

What I do not like about this is the "hidden" HaaS token.

I see your point. HaaS finds itself in ambivalent position a bit. It definitely serves as a threat detector but it's configuration is more complex, it doesn't need Sentinel Proxy and can work without EULA agreed.. On the other hand it's a trap like others and from the users point of view there should be no difference...

I can probably live with a separate section for HaaS. But we would have to solve whether Thread Detection should shine green on yellow when HaaS is deactivated and similar questions. Maybe Sentinel Thread Detection should exclude HaaS completely (as a term).

What about calling Minipots and Firewall Monitoring a Native Thread Detection? - only there where it makes sense to differentiate it from HaaS as an external Thread Detection tool?

Is it planned that user can insert its old device token? I thought that it is expected and then there should be rather the "Save" button

This is a good point.

I would just add button (something like refresh) to the right side of input field (for example how "show password" buttons are implemented) that would generate new device token without saving it to the configuration file (that would be done by clicking on save button).

I'm afraid this is not straightforward enough. But since it's already done this way elsewhere, why not..

The dynamic firewall should probably consist of the little overview, the enable radio button and some basic statistics & live updates & the complete actual greylist.

Isn't the complete greylist too much? I think some basic statistics & live updates would be enough.

Weren't we talking about that we don't want to show stuff that are available on view even when we could? I mean live updates of dynamic firewall are supposed to be part of view and thus I would only provide link to that page.

I agree with basic statics but we have to collect them first. We also have to identify what those would be. It can be the number of blocked IP addresses (set size). There can also be number of blocked connections (if we enable counter on rules that do blocking. That is all I could think of right now so I would appreciate it if we could assemble here a bigger list first.

@kkoci @mhrusecky @agumroian @vmyslivec @mhanak - what do you think guys? You can comment topic-specific issues in the corresponding discussions above

mentioned in issue #14 (closed)

mentioned in issue #15 (closed)

added Backlog Feature labels