Applications
Admin Console
The Nullafi Shield Admin Console provides a graphical user interface for configuring policy, viewing status, and examining event data. It is a web application which can be accessed using any web browser. The Admin Console is available after the Shield container is started. Access is governed by the defined container options (see Deployment). In the simplest case, browsing to the container host’s IP address on the mapped NULLAFI_HTTP_PORT will open the Admin Console login screen, and using the NULLAFI_USERNAME and NULLAFI_PASSWORD will allow the administrator to log in.
Policy
The policy engine is at the heart of Nullafi Shield. It does the work of examining the data being accessed, classifying it, and deciding whether it should be passed through to the user. The Policy section of the Admin Console is where rules are created to control the engine’s behavior.
Applications
Applications are the first consideration when Shield applies policy to a connection. They allow Rules to understand the source of the data when deciding how to behave. The Applications page of the Admin Console displays a list of defined applications along with some basic information about each one.
Applications are made up of three components: - Name (required) – Any name you wish to give. This will be used in Rule creation and will appear on the Activity screen when viewing connection history. - Description (optional) – Any text you would like to record alongside the Application definition to help with recordkeeping or context for future reference - Definitions (required; one or more) – This is where you tell Shield how to identify the Application.
New Application
To define a new application, click on the Add New Application button in the upper right hand corner. The application editing window will slide out from the right. To define the Application: 1. Type the Name and (optionally) Description into the text fields 2. For each Definition, choose a type from the dropdown box and fill in the required text field (see below for further detail on the Definition components), then click on the Add button. 3. Click on Save in the lower right
Edit Application
To edit an existing application, hover your mouse over the Application Name, click on the three-dot menu that appears, and choose Edit. The application editing window will slide out from the right.
Delete Application
To delete an application, hover your mouse over the Application Name, click on the three-dot menu that appears, and choose Delete.
Application Definitions
To determine the Application being accessed by the user, Nullafi Shield examines the browser request URL. Application Definitions can be of various types. Domain and Hostname definitions are by far the most common. The following types are available: - Domain - Matches against the domain portion of the URL. For example, “company.com” matches both https://www.company.com and https://app.company.com - Full URL - Matches the entire URL being accessed by the browser. Full URL is unlikely to be useful by itself, but can be used to fine tune an Application Definition using the advanced settings (see below) - Hostname - Matches against the entire hostname rather than just the domain. For example, “app.company.com” will match https://app.company.com but not https://www.company.com - Object Part - Matches against the object being requested by the browser, regardless of the server, domain, or path involved. - Path - Matches against the folders or subfolders being accessed on the server. - Query String - Matches against any part of the URL that comes after a “?” - Regex - Allows full use of regular expressions to allow for very fine grained control over URL matching
Wildcard usage in definitions
All data types allow the use of wildcards in their definitions. In fact, Object, Path, and Query String definitions would rarely be used without them. Some examples: - For Domain definitions, “company.com” matches www.company.com, www.my-company.com, and www.your-company.com - For Hostname definitions, “server.company.com” matches server1.company.com and server2.company.com, but not www.company.com - Combined with the bypass capability (see Advanced Options below), an Object type of “.jpg” can be used to avoid wasting resources on images. - “data=*” in a Query Path definition would include every query that includes a “data=” statement regardless of what comes before or after it
Advanced Options
By default, each Definition is a matching rule. Once a Definition has been created, it can be edited by hovering over the line item on the Edit Application window, clicking on the three-dot menu that appears, and choosing Edit. Under Advanced Settings in the Edit Definition window, a Definition can be changed from a matching rule to a bypass rule. Fine tuned Application behavior can be achieved by combining match and bypass Definitions. For example, a domain match definition for “company.com” could be combined with a hostname bypass definition for “blog.company.com” to avoid applying rules to the blog section of an App.