Recommended Minimal Configuration

From Opendium Documentation
Jump to navigation Jump to search

Following installation, we recommend configuring the system as described on this page.

Firewall zones

The Firewall: Zones come preconfigured to consider all private addresses to be part of the LAN. This should be reconfigured to match the real layout of your internal networks.

Opendium Web Gateway does not support multiple internal network zones, so all of the internal networks must be added to the LAN zone.

Opendium UTM can segregate the internal networks, so the Bring Your Own Device wifi network can be isolated from the wired network, for example. Networks which should be isolated from each other should be placed in different zones, whereas networks that need no isolation should be placed in the same zone.

Group configuration

Opendium systems have a powerful grouping mechanism which is configured on the Users & Groups page, with groups organised into a tree, and users, networks and individual computers assigned to one or more of the groups. Settings, such as web filtering, permissions, etc. can be set on each group and by default are inherited by the groups, users and networks within. Please refer to the Group Inheritance knowledgebase article for more in depth information about how group inheritance works.

There are very few restrictions placed on the groups and you are therefore free to arrange the groups as you wish, but the recommendations below provide a good starting point and are formed by many years of experience. This is a typical structure for a secondary school:

  • GROUP: Everyone
    • GROUP: Administrators
    • GROUP: Anonymous
    • GROUP: Networks
      • NETWORK: 10.0.0.0/8
      • NETWORK: 2001:DB8:c0ff:ee00::/56
      • GROUP: LAN
        • NETWORK: 10.0.0.0/16
        • NETWORK: 2001:DB8:c0ff:ee00::/58
        • GROUP: Servers
          • NETWORK: 10.0.254.0/24
          • NETWORK: 2001:DB8:c0ff:ee3f::/64
      • GROUP: Wifi
        • GROUP: Staff wifi
          • NETWORK: 10.1.0.0/16
          • NETWORK: 2001:DB8:c0ff:ee40::/64
        • GROUP: Student wifi
          • NETWORK: 10.2.0.0/16
          • NETWORK: 2001:DB8:c0ff:ee41::/64
        • GROUP: Guest wifi
          • NETWORK: 10.3.0.0/16
          • NETWORK: 2001:DB8:c0ff:ee42::/64
        • GROUP: Unfiltered wifi
          • NETWORK: 10.4.0.0/16
          • NETWORK: 2001:DB8:c0ff:ee43::/64
    • GROUP: Users
      • GROUP: Staff
      • GROUP: Students
        • GROUP: Lower school
          • GROUP: Year7
          • GROUP: Year8
          • GROUP: Year9
        • GROUP: Upper school
          • GROUP: Year10
          • GROUP: Year11
        • GROUP: Sixth form
          • GROUP: Year12
          • GROUP: Year13

There are a few special groups - Everyone is always at the root of the tree. Users within the Administrators group have administrative access to the system. The Anonymous group is also a special case and is used in situations where no other groups are applicable. Typically, the Anonymous group is left empty.

Whilst there are no restrictions regarding mixing users and networks within a group, we recommend keeping them separate in most cases by placing networks under the Networks group and users under the Users group.

The system comes preconfigured with all of the standard private addresses in the Networks group, but it is a good idea to trim this down to better match your network's configuration. Often the overarching network will be a single entry for the IPv4 network, such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, and a single entry for the IPv6 prefix (if there is one). However, some schools may have more complex networks that require multiple network objects to be created. In the example above, we have defined a single 10.0.0.0/8 IPv4 network and a single 2001:DB8:c0ff:ee00::/56 IPv6 network.

You can create subgroups for specific parts of your network. In the example above, we have created groups for LAN, and Wifi and subdivided the Wifi group into Staff wifi, Student wifi, Guest wifi and Unfiltered wifi, with appropriate networks within each. This allows us to set specific configuration for those networks. For example, we may want to set the web proxy's User Identification profile to RADIUS for the Wifi group, and disable User Identification and switch HTTPS Decryption into Passive mode for Guest wifi. We've also added a Servers group within the LAN, since servers often need different settings compared to the rest of the LAN.

We recommend setting up a completely unfiltered wifi network, to be only used for temporary testing and device onboarding. Since such a network is a potential risk, ensure that the password is kept secure, and consider restricting it only to certain parts of the school, such as the ICT office.

If your LAN is divided into subnets geographically - e.g. a separate subnet for each classroom - configuring each subnet here will also allow you to use Virtual Groups to apply custom configuration based on location. For example, you may want to relax the filtering in locations which will always be supervised.

The Users group will contain your users. Some schools may choose to create subgroups within the Staff group in order to subdivide the staff, whilst primary / prep schools often organise all of the students under a single Students group rather than dividing them into year groups. There is a balance to be struck between the flexibility of a group tree that is subdivided into many groups versus the management overhead of maintaining that structure, and this will vary from school to school.

For systems which are integrated into a Windows network, the users are automatically synchronised into the groups based on their Active Directory security groups and appropriate group mappings must be configured on the User Sync Configuration page. The user group structure within the Opendium system will therefore also depend on the way users are organised within Active Directory security groups.

Users

Stand alone systems

For Opendium systems which are not integrated into a Windows network, users must be created manually. For a small number of users it is no problem to add them to the system manually using the Create User button on the Users & Groups page. However, for a large number of users, it is often more convenient to import them from a spreadsheet or other application - this can be done by uploading a file in CSV format through the Import Users function.

Systems integrated into a Windows network

If you have integrated your system with a Windows network, the system's internal user database should be synchronised with your Active Directory. The synchronisation settings should have been configured on the User Sync Configuration page during installation, and the users synchronised using the User Sync function.

When integrated into a Windows network, the Opendium system is not responsible for authenticating users and password changes should therefore be made in Active Directory rather than on the Opendium system.

Firewall rules

Egress

The Egress rules control connections from within your network to the internet. The policy should be set to Intercept in the Everyone group, which will cause all traffic between your internal networks and the internet to be blocked, with the exception of:

  • Web traffic will be intercepted and redirected through the Opendium system's transparent web proxy and filter.
  • DNS traffic will be intercepted and redirected to the Opendium system's internal DNS service.
  • NTP traffic will be intercepted and redirected to the Opendium system's internal NTP service.

Depending on the software and equipment in use in the school, you may need to allow additional traffic by adding bundles, either in the Everyone group, or within specific subgroups.

If you have an unfiltered wifi network, we recommend setting the Egress policy for its group to Allow.

Ingress

The Ingress rules control connections from the internet to devices within your network. The policy should be set to Block in the Everyone group, since allowing indiscriminate connections from the internet into your network is a security risk.

If you are operating any internal servers which need to be accessible from the internet, you will need to create appropriate groups and networks for those servers and add suitable ingress bundles and NAT mappings to them.

Internal

The Internal rules on Opendium UTM control traffic between internal networks which are in different Zones. The policy should be set to Block in the Everyone group, to isolate the networks. Additional bundles can be added to allow specific types of traffic between networks.

Opendium Web Gateway does not have this capability.

NAT

A suitable prefix needs to be configured within the NAT page to translate the source addresses of egress (outbound) connections from your network to the internet. This will often be the external IP address of your Opendium system.

Services

The Services page controls which of the Opendium system's services are exposed to the internet.

HTTP (required to renew encryption certificates), Secure Shell (for Opendium engineer access) and ICMP (for connectivity monitoring) should all be enabled.

Web settings

Blocked categories

The Blocked Categories determine which categories of web site are blocked. We highly recommend that at least the following categories are blocked in the Everyone group:

  • Anonymisers / Proxies / VPNs
  • Child Abuse Images
  • Hate
  • Malware
  • Pornography
  • Radicalisation
  • UK Sanctions

You may want to add more categories here, or in more specific subgroups. However, keep in mind that more is not always better. For example, blocking Offensive Language may be desirable for primary school children, but is likely to result in significant overblocking for staff and secondary school children.

Overrides

Web: Overrides allow certain aspects of the web proxy and filter to be disabled for specific websites. The following are the default overrides which we recommend to be applied to the Everyone group:

  • Disable auth
  • Disable HTTP auth
  • Disable HTTPS decryption
  • Essential services
  • Reduced filtering
  • Whitelist

Additional overrides may be required for certain applications to work.

We recommend that you disable web filtering for your own domains by adding them to the Whitelist override.

Permissions & limits

We recommend the following settings are applied to the Everyone group on the Permissions & Limits page:

  • Allow users to override a block: Disabled
  • Bypass all web restrictions: Disabled
  • HTTPS decryption: Active
  • Display splash page for new devices: Disabled
  • Autoconfigure devices to use the proxy: Enabled
  • User identification: Enabled (the most suitable profile to use depends on your network)
  • Restrict requests to IP literals: Block all
  • Allow users to access reports: Disabled

Wifi networks should usually have the following additional settings: on their groups:

  • Display splash page for new devices: Disabled
  • User identification: Enabled (either RADIUS or Single User Devices mode, depending on your network)

If you have a guest wifi network, we recommend the following additional settings the following on its group:

  • HTTPS decryption: Passive
  • User identification: Disabled (however, RADIUS Guest mode may be useful for some wifi systems)

If you have an unfiltered wifi network, we recommend setting the following on its group:

  • Bypass all web restrictions: Enabled
  • HTTPS decryption: Disabled
  • Display splash page for new devices: Disabled
  • Autoconfigure devices to use the proxy: Disabled
  • User identification: Disabled
  • Limit users' bandwidth: Disabled
  • Restrict requests to IP literals: Disabled

Safe search

We recommend that the Enforce Strict Safe Search setting is enabled for the Everyone group on the Safe Search page.