Skip to main content

Flat Group and Zone Configuration

This page discusses the best way to configure rWeb with a relatively flat hierarchy of Groups and Zones. It will be helpful for users who don't need to impose strict limits on children groups.

When to Use​

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

  • Expected users, with some exceptions, are mostly admin level and are given broad authority to make changes. Along these lines, your rWeb is likely on a private network accessible to only these users.
  • Services being protected by filter devices are largely relevant to the infrastructure of your organization (e.g. your websites, DNS servers, and so on).
  • Protection of any communal or customer-oriented services are managed by your organization, and not your customers. For example, you provide website hosting which your customers can build themselves, but you are managing the protection of those sites.
  • Reporting considerations are largely driven at a higher level, by different service components.

Group Configuration​

Groups will typically be nested directly under the Default Group. Groups should be created to reflect the service offerings or infrastructure of your organization.

Example

Default (Group)

  • East Coast Webservers (Group)
  • West Coast Webservers (Group)
  • Mail Servers (Group)
  • DNS Servers (Group)

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

  • Groups can be set to inherit their Group Subnets from the Default Group. This means each group can have zones from anywhere within IPv4 or IPv6 address space, as long as zones don't try to assign identical subnets. This reduces the effort of managing and assigning routes to Groups, and allows rapid creation of new Zones on an ad-hoc basis.
  • Groups should use all available devices in their Group Device list. As a result, any new zones will automatically be pushed to your devices. If your groups are based by location (e.g. East Coast data center versus West Coast), you can remove the devices irrelevant to that location.
  • Unless you have a need for restricted permissions on your users, most of your users should be created under the Default Group using one of the default roles. This will enable them to make changes in any group or zone.
  • Reports can be scheduled against each of these groups as required.

Zone Configuration​

Zones should be created that reflect their owning group's services. Zones can contain larger or smaller aggregations of destination addresses, depending on requirements or user preference.

Example

Default (Group)

  • East Coast Webservers (Group)
    • NYC Datacenter (Zone)
    • Raleigh Datacenter (Zone)
  • West Coast Webservers (Group)
    • Seattle Datacenter (Zone)
    • LA Datacenter (Zone)
  • Mail Servers (Group)
    • Primary Mail Servers (Zone)
    • Secondary Mail Servers (Zone)
  • DNS Servers (Group)
    • DNS Servers (Zone)

When creating zones, the following techniques typically apply:

  • Zones should contain similar network traffic and services to make designing mitigation profiles easier.
  • Zones can contain larger routing subnets initially, unless you have specific addresses that need tweaks to mitigation. Ideally, you want your network's subnets assigned across all zones so that only unexpected traffic ends up in the Default Zone.
  • You can also 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.