Skip to main content

Hierarchical Group and Zone Configuration

This page discusses the best way to configure rWeb with a nested hierarchy of Groups and Zones. It will be useful for users who need to configure rWeb to impose stricter control over children groups and their associated users (e.g. allowing paid customers to have control of mitigation for their IPs).

When to Use​

In general, this configuration style is appropriate when most or all of the following conditions apply:

  • There will be many users of rWeb (available on a publicly accessible address), who need strict permissions to only see or use resources assigned to them (groups, zones, and devices).
  • Users largely fall into three groups: admin level with full system access, intermediate administrators responsible for partitioning and creating groups for end users, and the end users themselves, who are managing mitigation for their provided destination IPs.
  • Your IP address space can be divided into addresses used by your organization, and addresses being used by your customers.
  • Reporting is done as needed, though your organization may need to schedule billing reports for your end users.

Group Configuration​

Groups will be layered according to how you are offering services to your users. Groups at the top level should reflect the overall responsible party, with intermediate levels as required, and the lowest level groups should reflect individual customers or stakeholders.

Example

Default (Group)

  • SMB Customer (Group)
    • Division A (Group)
      • Backend (Group)
      • Frontend (Group)
    • Division B (Group)
      • Web Servers (Group)
      • VoIP Servers (Group)
  • Individual Filtering Services (Group)
    • Customer A (Group)
    • Customer B (Group)
    • Customer C (Group)
  • Internal Organization Servers (Group)
    • Web Servers (Group)
    • Mail Servers (Group)
    • DNS Servers (Group)

When creating these groups, here are some additional configuration suggestions that typically apply:

  • Groups should not inherit their Group Subnets from the Default Group. Groups directly under the Default Group should be specifically provisioned with the subnets they will be assigned. Groups after that can either inherit or be specifically assigned, as required. This prevents users from one group creating new configurations that might affect other customers' traffic.
  • Groups should only be assigned devices you expect them to use in their Group Device list. This will require knowledge of your internal network design to correctly identify which subnets (and by extension, groups) are being routed through which devices. If you have a device assigned for sole use by a single customer, it should only be assigned to the Default Group and the Group you create for that customer.
  • Users should have restricted permissions so that they can only see or manipulate settings within their assigned group. Users from your organization should be created within the Default Group to enable all high level admin functionality. Intermediate users should not have Device or rWeb privileges, but should have Read/Write Group privileges so they can create new subgroups and users based on their requirements. End users should only have Zone and Mitigation permissions so they can only affect the Zones within the Group created for them.
  • Reports can be scheduled against each of these groups as required. Reports currently only work against Groups, and collate data from the zones directly in that group, so if you need to run a billing report against a given customer it will need to be done from their Group.

Zone Configuration​

Zones should be created that encapsulate the owning group's traffic, with more refined Zones created as required.

Example

  • Default (Group)

    • SMB Customer (Group)
      • SMB Default Zone (Zone)
    • Division A (Group)
      • Division A Default Zone (Zone)
        • Backend (Group)
          • Database Servers (Zone)
        • Frontend (Group)
          • Frontend Servers (Zone)
          • Web Portal (Zone)
    • Division B (Group)
      • Division B Default Zone (Zone)
        • Web Servers (Group)
          • Web Servers (Zone)
        • VoIP Servers (Group)
          • VoIP East Coast (Zone)
          • VoIP West Coast (Zone)
      • Individual Filtering Services (Group)
        • Filtering Services Default (Zone)
        • Customer A (Group)
          • Customer A (Zone)
        • Customer B (Group)
          • Customer B (Zone)
        • Customer C (Group)
          • Customer C (Zone)
      • Internal Organization Servers (Group)
        • Internal Organization (Zone)
        • Web Servers (Group)
          • Web Servers (Zone)
        • Mail Servers (Group)
          • Mail Servers (Zone)
        • DNS Servers (Group)
          • DNS Servers (Zone)

When creating zones, the following techniques typically apply:

  • Zones should be created at each Group layer, with all associated Group Subnets assigned on the Zone Routing Tab. This ensures that any traffic meant to go to the Group is captured by at least one Zone. If a Group is created but has no Zones with appropriate subnets, traffic will end up in the Zone with the next most specific subnet. If this happens, it means a user at a lower level might not be able to see their traffic, as it will show up in a Zone at a higher Group tier that they won't have permissions to see. Creating these encapsulating Zones is most important for the top level groups under the Default Group, but less so for Groups managed by intermediate users.
  • More specific Zones can be created on an as needed basis. You can create zones with more stringent rules and higher filtering sensitivity that you use to add more specific subnets that are under attack, removing them once the attack is finished.
  • If Group Devices are configured already, newly created zones will be added to all appropriate devices automatically. It is important that they are correctly configured ahead of time when setting up your Groups, as your lower level users will not be able to see devices or change Zone to device mappings.