Policy Management
From UntangleWiki
Please Note: Most of the features discussed in this User Guide are available in the Open Source version of the Untangle Server software; however, some features are only available in the Professional Package. For a current listing of features and pricing, have a look at the Untangle Price List.
Advanced Policy Management with 'Custom Racks' is currently only available in the Professional Package. You can, however, create 'No Rack' and 'Default Rack' policies in the Open Source version.
About Policy Manager
The Policy Manager is a powerful and advanced feature of the Untangle Server. Advanced Policy Management with 'Custom Racks' is currently only available in the Professional Package. You can, however, create 'No Rack' and 'Default Rack' policies in the Open Source version.
The Policy Manager works by creating rules, or policies. Using policies, you can route traffic based on the network interface and/or endpoints. A policy binds traffic that matches certain criteria to a Virtual Rack. Policy Manager enables you to:
- Use multiple, but distinct, copies (instances) of any Virtual Rack Product, though not for services.
- Install and configure each instance into a different rack.
- Assign each rack a policy.
- Route a particular type of traffic to the Software Product that the rack contains.
Launching the Policy Manager
To launch the Policy Manager:
- Go to the Virtual Rack that you want to manage.
- In the Rack drop-down list, select Show Policy Manager as shown in Figure, Launching the Policy Manager. The Virtual Rack appears in the Untangle Client.
About Routing and Virtual Racks
As discussed in Reinstalling Software Products, Software Products are not installed into an Untangle Server but into a virtual rack. The Untangle Server ships with a single Virtual Rack called Default Rack. You cannot remove this rack. The Default Rack serves companies that have basic protection needs. You can also create custom virtual racks.
Your Untangle Server can have many virtual racks and each virtual rack can contain zero or more Software Products. The virtual racks are custom in that you can apply different rules for any Virtual Rack Product, though not for services.
In addition to rules enforced by the Software Products, you can control your network further by using network traffic policies. Traffic arrives at one network interface of your Untangle Server and leaves on another. After the traffic enters and before it exits the Untangle Server, several Software Products can scan and/or modify the traffic. To illustrate how the Untangle Server handles traffic, go to Routing Behind a Simple Web Page Request.
Routing Behind a Simple Web Page Request
The Untangle Server uses the following pieces of information to process a web page request:
- The IP address of the requester (client) and the IP address and port of the requestee (server) These IP addresses are called endpoints. The client and server is defined by client-server architecture.
- Two network interfaces—the client's interface and the server's interface.
To make routing easier to visualize, consider this scenario:
Emma is sitting at her desktop on the protected network (connected to the internal interface). Emma decides she wants to learn more about networking so she visits Google in her web browser. Since Emma's computer is behind an Untangle Server running NAT, the IP address of her computer is 10.0.0.129. When Emma opens the Google home page in her browser, the Untangle Server sees a TCP traffic request from IP address 10.0.0.129 (Emma's computer) to IP address 66.102.7.99 on port 80 (66.102.7.99 is one of the many IP addresses of Google).
After Emma makes the page request from her desktop and until that request arrives at Google, the following sequence of events occur:
- A request is sent from Emma's machine (10.0.0.129) to the Untangle Server (which acts as the network gateway) where it is received on the your Untangle Server's internal interface. The Untangle Server now considers this request's client interface to be the internal interface.
- The Untangle Server inspects the request, and finds the source/client IP address to be 10.0.0.129.
- Using the destination name of www.google.com, the Untangle Server sends a request to a DNS server, who returns the IP address 66.102.7.99.
- It adds the Google web server port number onto the destination address (66.102.7.99:80).
- The Untangle Server routes the traffic to Virtual Racks for inspection.
- One or more Software Products inspects this traffic. In this case, the Web Filter inspects the request and finds no malicious or flagged content.
- The Untangle Server consults its policies to determine the server interface of the traffic to that server IP:port, 66.102.7.99:80. In this case, the Untangle Server determines that the server is connected to the external interface.
- The request is sent from the Untangle Server to 66.102.7.99:80, exiting the Untangle Server on the external interface.
In this example, Emma's request had two endpoints: Emma's machine and Google's Web Server.
Using Policies To Route Traffic To Virtual Racks
The Untangle Server routes traffic to a Virtual Rack by consulting its list of policies. Think of policies as rules, binding a type of traffic to a Virtual Rack. A given policy can be expressed as:
If the traffic looks like X, route it to Virtual Rack Y
where Y is the name of the Virtual Rack, and X defines the type of traffic. The simplest way to differentiate traffic is by its:
- Interfaces. Client's and server's Internal, External, DMZ, VPN interface. The list of interfaces depends on the network interfaces that you have installed in the Untangle Server.
- Endpoints. IP address of client and server. Partition traffic based on one or both endpoints enables you to target a set—a rack of Software Products between locations as granular as specific computers.
Deciding When To Use Multiple Virtual Racks
Are you wondering if you need more than one virtual rack — the Default Rack? Normally, you don't. However, if you cannot configure a given Software Product to meet all of your needs, you might need more than one virtual rack. Here are some common use cases for virtual racks:
- Applying very different requirements to different sets of users. If your organization is a large school, you might need two different racks: one for students and one for teachers. There are many websites that you want teachers and librarians to access, but you do not want students to access those same websites. For an example, go to Example: Creating a Custom Policy for a School.
Tip: If you only have a few users that need to bypass web content controls, consider using pass lists in Web Content Control, not a separate virtual rack. In this case, a pass list is an easier solution to implement and maintain.
- Setting up a DMZ to host an Internet-facing web server. The policies associated with web traffic to your own web server (filtering, scanning) should be different than those for employees browsing the web. Simply create a DMZ Rack, then apply a custom policy that handles the traffic from the External interface to DMZ interface.
- Setting up a special file transfer relationship between your organization and an external business partner. File transfers between these two groups may permit certain file types (executable code), yet these file type transfers are blocked for the general Internet. Simply create a Partner Rack and a Company Rack.
- Setting up a VPN. Since many users use VPN to access the protected network from home (where their home networks might not be as secure), you might want to restrict access to critical internal systems by VPN users.
The previous list highlights cases where a single Software Product cannot be configured for all situations (for example, Web Content Control should scan for traffic from desktops yet not to a company's own web server). Virtual Racks let you install and configure instances of just those Software Products that you need for the type of traffic that you will encounter.
Creating Special Racks for Servers
Use a special rack called a No rack to apply policies to servers, not users. The most common case where you might need to use a No rack is if you want two Microsoft Exchange Servers to communicate with each other. This way, the Microsoft Exchange Servers' traffic will not be filtered by any Software Product.
As discussed in About Routing and Virtual Racks, the Untangle Server ships with a single virtual rack called Default Rack, and you can install additional, custom virtual racks. However, all virtual racks contain default Software Products. In many cases you can remove these Software Products, but if that Software Product is a Service, the Untangle Server removes that Software Product from all racks. More importantly, for basic protection, Software Products inherently filter traffic. If you want to bypass these restrictions, use a No rack. For minimal protection, the No rack does enable NAT.
As shown in Figure, Creating a Special Rack for Servers The No rack virtual rack does not appear in the virtual rack drop-down list (in the main interface). It is not a rack—because it is not designed to contain Software Products. Because the No rack is not a rack, you do not need to create it. No rack is available by default from within the Policy Manager. When you modify a default policy or create a custom policy for the No rack, simply specify No rack from the drop-down list of virtual racks.
Adding a Virtual Rack To Untangle Server
To learn about virtual racks, go to Deciding When To Use Multiple Virtual Racks.
To add a new virtual rack:
- From the Policy Manager, click the Rack List tab. To launch the Policy Manager, go to Launching the Policy Manager.
- Click the add (plus) button to the left of the table. A new row appears in the table.
- Specify the rack name, and provide a description to state the purpose of the rack.
- Click the Save Settings button.
- From the Rack drop-down list as shown in Figure, Creating Virtual Racks, select the rack that you just created. By default, this new virtual rack contains default Software Products.
Next Step: Install, configure, and turn on Software Products to your new rack. Go to Installing Software Products.
Preparing To Assign Users To Policies
Normally you'd simply configure your router for DHCP, allowing the router to automatically assign IP addresses to users' computers. In order to assign users to a policy, you need to do so using each users' IP address. If the router assigns the IP address automatically to a user's computer and that IP address changes (which is inevitable), the Policy Manager can no longer enforce policies for that user. Therefore, Policy Manager requires that you assign static IP addresses to virtual rack users. After all, you're asking the Policy Manager to keep track of users and their activity. When you assign static IP addresses, group users into logical IP address ranges.
In a 255.255.255.0 network, where you have IP address 192.168.1.1-192.168.1.254 and using the example in Example: Creating a Custom Policy for a School, create the following ranges on your router — whether that router is an Untangle Server or not:
- 192.168.1.51-192.168.1.150 (Teachers & Staff)
- 192.168.1.151-192.168.1.254 (Students)
To assign a static IP address to a computer when your router is an Untangle Server, go to Assigning Network Computers Static IP Addresses.
Creating Custom Policies
As mentioned in About Routing and Virtual Racks, most deployments do not need to create custom policies. However, you need to create a custom policy to do any of the following:
- Differentiate traffic both on network interfaces and endpoints.
- Create a policy that applies to one user in a virtual rack.
- Create policies that apply to specific times during the day or week.
For performance reasons, it's not a good idea to scan outbound email traffic. Because an Untangle Server policy operates on both outbound and inbound by default, Untangle Server provides one, default custom policy to stop Untangle Server from scanning outbound email traffic. The custom policy achieves its goal by directing the traffic through the No Rack. Only edit this rule if want Untangle Server to scan outbound traffic and overwrite this custom rule; otherwise, PLEASE DON'T EDIT IT! This default policy also ensures that outbound emails are never quarantined. This default policy appears as #1, but as you add policies, this number changes. Default custom policies have lower priority than user custom policies—the policies that you create—and default custom policies are handled after user custom policies.
To add a new virtual rack:
Before You Begin:
- Review the example in Example: Creating a Custom Policy for a School.
- Create a Virtual Rack other than Default Rack. Go to Adding a Virtual Rack To Untangle Server.
- For each virtual rack user, assign a static IP address. Go to Preparing To Assign Users To Policies.
- To launch the Policy Manager, go to Launching the Policy Manager.
- From the Policy Manager, click the Policy-To-Rack Map, then click the Custom Policies tab.
- Click the add (plus) button to the left of the table. The Policy Wizard launches.
- Specify the endpoints, interfaces, and virtual rack for the new custom policy, and click Continue. A new row appears in the table.
- If you do not want to scan certain types of traffic, do not create an empty virtual rack. Instead, select No rack from the drop-down list.
- The Enable this Policy check box enables you to activate or deactivate a policy. If you clear the checkbox, you deactivate the policy without deleting the policy settings.
- If you added more than one custom policy, use the up and down arrow buttons in the # (number) column to specify the priority of one custom policy relative to another. Policy #1 has the highest priority and is evaluated first, followed by Policy #2, et cetera.
Protocol The network protocol of the traffic that you want the Untangle Server to scan. Valid values are TCP, UDP, PING or TCP & UDP. Interface The network interfaces on which the traffic travels. Your choices are Internal, External, DMZ, any other network interface that is installed, and Less Trusted or More Trusted Interfaces. Address The IP address to which you want the policy to apply. A comma-separated list (for example, 192.168.1.100, 192.168.1.101) of IP addresses, or a range (for example, 192.168.1.100-192.168.1.200) of IP addresses of the traffic. Any is a valid value, and means that the client address is removed as a traffic selection criteria. See also Preparing To Assign Users To Policies. Port The port on which you want the policy to apply. Valid values are in Port Matcher format. Note that Port Matcher supports the value any. Specifying a value of any means that the server port is effectively removed as a traffic selection criteria. Tip: If you don't wish to scan certain types of traffic, do not create an empty Virtual Rack. Instead, select No rack as the rack in your custom policy.
Users The user to whom you want this policy to apply. The users from your Active Directory are listed as (Active Directory). The users from your Local LDAP directory are listed as (local). Time of Day The range of time, based on a 24-hr clock (also called military/army/railway time), that you want to policy to be active. In 24-hour time clock, the day begins at midnight, 00:00, and the day ends at 23:59. Days of Week The days that you want the policy to be active. Rack A list of available virtual racks. Select one of these virtual racks for each policy.
Example: Creating a Custom Policy for a School
Imagine that you are the Network Administrator at a public school. Let's assume that you need to create policies that enforce the following workplace environment:
- No web content restrictions for teachers and other staff. In this case, use the Default Rack for teachers and administrators.
- Many web content restrictions for students when they are (or should be) in class. For example, they cannot access www.myspace.com during class. In this case, create a virtual rack called Student Work Rack.
- Some web content restrictions for students when they are on break. For example, they can access www.myspace.com during break. In this case, create a virtual rack called Student Play Rack.
This example assumes a 255.255.255.0 network that provides an IP address range of 192.168.1.1-192.168.1.254. The router has the following IP addresses assigned, as described in Preparing To Assign Users To Policies:
- 192.168.1.51-192.168.1.150 (Teachers & Staff)
- 192.168.1.151-192.168.1.254 (Students)
The following example shows these two policies:
- Policy #1. Uses Student Play Rack to enable students to visit www.myspace.com during lunch.
- Policy #2. Uses Student Work Rack to block students from visiting www.myspace.com during class.
NOTE: policies are evaluated in the order they are listed and the FIRST policy that matches a network event is the one that is applied to the event. Thus, in this example, we want the 'Student Play' policy to come first, so when it matches an event access to the controlled site is permitted. Then, we want the 'Student Work' policy to come second so the controlled site is denied otherwise. Then, we want the 'Default' policy to come last in the list, so any default rules are enforced as a fail safe, i.e., should a teacher be accessing the web from a student computer but not necessarily accessing myspace.
Policy #1
Policy #2
