Applies To:

Show Versions Show Versions

Manual Chapter: FirePass Controller Administrator Guide: 3 - Configuring Endpoint Security
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


3

Configuring Endpoint Security


Understanding endpoint security

Endpoint security is a centrally managed method of monitoring and maintaining client-system security. The FirePass controller provides three mechanisms for accomplishing endpoint security:

  • A pre-logon sequence, which defines a set of actions that need to be taken in order to evaluate the client system or device.
  • A protected configuration, which takes information gathered by the pre-logon sequence and instructs the system to respond based on the result.
  • Resource protection, which uses a protected configuration to protect a set of resources you have defined.

Endpoint security performs three basic tasks:

  • Collects information about the client system
    For example, whether the user is operating from a company-issued computer, what antivirus software is present on the machine, what operating system the computer is running, and others. This is accomplished by the pre-logon sequence.
  • Performs remediation, if possible
    For example, puts the system into the protected workspace, prompts the user to download antivirus software, and others. This is a function of the FirePass controller, based on information gathered by the pre-logon sequence.
  • Protects resources based on the collected information
    For example, prevents access to a resource until the user downloads and installs the antivirus software requested, and others. This is accomplished by creating protected configurations and assigning them to protect resources.

Collecting information

The FirePass controller collects various types of information about the client system using ActiveX controls or Java plug-ins. In clientless mode, that is, when the inspection process does not download any controls or plug-ins, the endpoint security process inspects the HTTP headers to gather the information.

The FirePass controller provides checking primarily for Windows-based systems, and some of the checking is not supported on Mac OS X or Linux systems. The FirePass controller does support file checking on Mac OS X and Linux systems. Table 3.1 , following, shows the complete list of inspectors.

Using the inspectors

Inspectors are the basic working functionality for sequences. An inspector is an ActiveX control or Java plug-in that gathers information about the user's computer, evaluating factors such as the presence of viruses or antivirus software, operating system version, running processes, and others. The pre-logon sequence determines which inspectors to activate, and the inspectors evaluate the system of the user logging on. Depending on the outcome of evaluation, the FirePass controller permits the logon to continue, initiates an action, presents a message, or rejects the attempt. The FirePass controller supports the following inspectors.

Table 3.1 contains information about each inspector. You can find more information about session variable usage and operating system requirements for each inspector in the online help.

Table 3.1 Endpoint inspectors
Inspector
Description
Decision
The decision box allows you to present a user options to select from a list. You can use a rule containing the variable session.user_decision.last.check==1 to match the first option selected by user. Default options are Yes and No, but you can modify these options, and you can add other options from which the user can select.
Define custom variable
Defines a new variable and assigns a value to an existing one. For more information about the custom variable, see the section Using variables generated by inspectors for Action Rule expressions in the online help for the Pre-logon Sequence screen.
Extended Windows information
Gets version information about the Windows operating system, such as version and hotfix information from the remote system. This inspector uses the session.win_info.os_version, session.win_info.hotfixes.count, and session.win_info.hotfixes.hf_<hotfixname>, which you can then use to define a rule for a specific action in a sequence.
Far-End Security Integration
Provides integration with third-party endpoint security products using the session.external_security_check.result session variable. A match to session.external_security_check.result == 1 indicates that the check completed successfully.
You can use this inspector to detect WholeSecurity's Confidence Online™ Server, which automatically identifies and eliminates both known and unknown threats without requiring users to install or update signatures. For more information about how to use this feature, see the deployment guides for FirePass controller integration with Whole Security, available on the F5 Networks Solution Center at http://www.f5.com/solutions/.
Google Desktop Search Inspector
Checks for the presence of Google Desktop Search software using the session.google_desktop_check.result session variable. A match to session.google_desktop_check.result != 1 indicates that Google Desktop Search is running.
Internet Explorer information
Collects version information about the Internet Explorer software, such as version and hotfix information, from the remote system. This inspector generates the variables session.ie_info.version, session.ie_info.hotfixes.count, and session.ie_info.hotfixes.hf_<hotfixname>, which you can then use to define a rule for a specific action in a sequence.
Linux file checker
Checks for the presence of certain Linux files and uses MD5 to authenticate files. This inspector uses the session.file_check_linux.<filename>.result session variable. A match to
session.file_check_linux.<filename>.result ==1 indicates the presence of the file with all associated parameters.
Logger
Writes user-defined information to the logon and system logs. For the string, you can use a session variable name enclosed in percent symbols (%) to have the system substitute the appropriate information. For example, typing Logon from %session.network.client.ip% creates an entry containing the IP address for the client system where the logon operation originated.
Mac OS X file checker
Checks for the presence of certain Mac OS X files and uses MD5 to authenticate files. This inspector uses the session.file_check_macosx.<filename>.result session variable. A match to session.file_check_macosx.<filename>.result ==1 indicates the presence of the file with all associated parameters.
Mailer (Sending email action)
Sends email to the specified address during the pre-logon operation. For the string, you can use a session variable name enclosed in percent symbols (%) to have the system substitute the appropriate information.
For example, you can type the following message text:
Antivirus: %session.detected_av.av_1.name%, %session.detected_av.av_1.engine_version%, %session.detected_av.av_1.monitor%, %session.detected_av.av_1.database_time%, %session.detected_av.av_1.last_scan%
The following is a sample message constructed using these session variables.
pre-logon: Antivirus: McAfeeAV, 4400, enabled, 2005.08.01.00.00, 2005.07.29.00.00
For a list of session variables, see Using variables generated by inspectors for Action Rule expressions in the online help for the Pre-logon Sequence screen.
Important! A busy or incorrectly configured email server can cause an extended delay in a pre-logon process. You can configure the email server on the Device Management : Configuration : SMTP Server screen.
Message
Presents a message to the user during the pre-logon check and prompts the user to click the Continue button to continue with the pre-logon check. This inspector does not return any session variables.
You can use the Endpoint Inspector Details screen to create the message you want to present. In addition to the content you enter, you can select left alignment, center alignment, or right alignment of the message text.
Protected Workspace inspector
Controls various aspects of switching Windows 2000 and Windows XP users to run inside the F5 Networks protected workspace (PWS). Running inside the PWS, you can restrict users from printing, saving files, or storing information on a Windows file share. Placing users inside the PWS is especially useful when your users are working on devices that are outside of company control.
Running inside the PWS only reduces the risk of unintentional or accidental information leaks, but does not eliminate that risk. The PWS restricts users to a temporary workspace, which is created fresh at the beginning of each session. This workspace contains temporary Desktop and My Documents folders. In protected mode, the user cannot unintentionally or accidentally write files to locations outside the temporary folders, unless you specify additional allowed locations. The PWS control deletes the temporary workspace and all of the folder contents at the end of a session. For additional security, when users enter the PWS, the operation closes any third-party toolbars that are running.
Note that running inside the PWS does not prevent information leaks from Internet mail, web blogs, or web chat.
Important! Although the protected workspace control does attempt to remove temporary files after a hard reboot, users who perform a hard reboot of their remote systems could allow viewing of and operations on the temporary files.
This inspector uses the session.pws.active == 1 variable to indicate that the user is currently running inside the protected workspace. Available settings include requesting a confirmation before entering the protected workspace, allowing the user to temporarily exit the protected workspace, allow use of printers while the user is in the protected workspace, closing Google Desktop Search before placing the user into the protected workspace, and specifying Windows share locations to which the user can write.
Virtual keyboard enabler
Toggles use of the virtual keyboard for client logon operations. Activating this inspector presents a graphical representation of a keyboard and requires users to type their password using mouse clicking on the graphical keyboard. This helps prevent keyboard loggers from harvesting users logon names and passwords. In addition to presenting the virtual keyboard, you can elect to have the keyboard graphic reposition itself randomly with each mouse click. Randomly repositioning prevents captured mouse movements from revealing password information.
Windows antivirus checker
Enforces antivirus protection and performs endpoint checks for viruses. This inspector uses a number of session variables. The online help contains a list of them all.
This inspector uses the following rules:
Monitor is running
(session.av.summary.monitor >= 1) AND (NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)))
AV installed
(session.av.summary.count>0)AND (NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)))
Virus detected
EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)
Using one instance of this inspector, you can scan for up to three antivirus packages. To find the list of supported antivirus packages, see the online help for the Windows antivirus checker.
Windows file checker
Checks for the presence of certain Windows files using the session.file_check.<filename>.result session variable. A match to
session.file_check.<filename>.result ==1 indicates the presence of the file with all associated parameters.
Windows firewall checker
Checks for the presence of a firewall on the remote system. This inspector uses the following rules:
running
session.fw.summary.enabled == 1
installed
session.fw.summary.count>0
You can enable the Windows firewall if other firewalls are not enabled. To find the list of supported firewalls, see the online help for the Windows firewall checker.
Windows process checker
Collects information about the running Windows processes using the session.process_check.<process>.result session variable. A match to session.process_check.<process>.result == 1 indicates that the process is running.
Windows registry checker
Collects information about Windows registry keys using the session.process_check.<registry_check_ID>.result session variable. A match to session.process_check.<registry_check_ID>.result == 1 indicates the presence of the registry item specified on the details page for this inspector.

 

Using session variables

You can use session variables to direct users to a specific master group and assign them specific resource groups based on session variables. FirePass controller session variables consist of two main sets:

  • Session variables defined during pre-logon sequence
    The FirePass controller defines these variables while the system performs pre-logon checking. These variables contain information about the client, or information that you define for custom variables.
  • You can find a complete list of these variables in the online help for the Users : Endpoint Security : Pre-Logon Sequence screen and in the online help for the Define custom variable inspector.

  • Session variables defined during group mapping and user authentication
    During dynamic group mapping and user authentication, the FirePass controller retrieves user attributes from the external Active Directory and LDAP servers. The system then converts these attributes to session variables.
Note

The FirePass controller does not convert to session variables attributes received from external RADIUS servers.

The FirePass controller names the session variables in the following manner:

session.ad.groupmapping.attribute_name = attribute_value

session.ldap.groupmapping.attribute_name = attribute_value

session.ad.auth.attribute_name = attribute_value

session.ldap.auth.attribute_name = attribute_value

If the attribute contains multiple values, the FirePass controller forms a space-separated string containing all values, and uses that as the attribute value.

session.ad.groupmapping.attribute_name = "attribute_value1 attribute_value2..."

session.ldap.groupmapping.attribute_name = "attribute_value1 attribute_value2..."

session.ad.auth.attribute_name = "attribute_value1 attribute_value2..."

session.ldap.auth.attribute_name = "attribute_value1 attribute_value2..."

You can use session variables in the following ways:

  • To configure Network Access favorites. For example, you might specify session.ldap.auth.SubNetAddress in the LAN address space box for a Network Access favorite. Then, when a user is authenticated, the FirePass controller substitutes the user's SubNetAddress value. You can configure this option in a favorite definition, available on the Network Access : Resources screen.
  • To configure protection criteria when defining a protected configuration. For example, in the Custom check expression box you might specify %session.ldap.auth.NetworkAccessAllowed%=YES
    AND
    %session.ldap.auth.OU%=Sales
    Then, when the user matching these specifications logs on, the FirePass controller allows access to the resources protected by that configuration. You can configure this option in a protected configuration definition, available on the Users : Endpoint Security : Protected Configuration screen.
  • To configure various rules in pre-logon sequences, which you can then use for defining protected configuration. You can configure this option in a pre-logon sequence, available on the Users : Endpoint Security : Pre-Logon Sequence screen.
  • To direct different users to different webtops based on the landing URI they request. For example, you can use the session variable %session.userdef.my-dynamic-webtop% for different master groups on the Portal Access : Web Applications : Intranet Webtop screen. Then, you create a pre-logon sequence to initialize this custom variable to appropriate values based on landing URI information.

You can enable the Save user's session variables to Logon Report option on the Device Management : Maintenance : Troubleshooting screen to have the system write a user's session variables to the Logon report for that user. Then you can view the variables on the Reports : Logon screen.

Performing remediation

When the endpoint security process is inspecting the client systems, it can take several actions to correct the state or condition of the client computer.

  • Present information to the user
    If the inspection process requires the download of certain controls or plug-ins, and the user does not have sufficient privileges for the download operation, the system can inform the user and present recommendations for making the changes necessary, or prompt the user to download and install a security update. You can present information to the user using the Information box inspector.
  • Perform the action needed
    If the protection configuration needs a specific condition to be met, and it is possible to perform the action, the system takes the remediative action necessary. The following items describe some actions that the system can take to remediate the situation.
    • If the protection configured requires that the computer run in the protected workspace, the system can place the running processes into the protected workspace. The Protected Workspace inspector performs this action automatically.
    • Depending on the action needed, the system can present a list of options from which the user can select. You can write rules tailored to the options that you provide. For example, you can write a set of rules that redirect users to various external logon pages, by defining a Decision box inspector with different External Logon Page endings.
    • If the protection configured requires that a specific process not be running, the system can prompt the user to halt the process.
    • Depending on the protection configured, the system can locate installed antivirus and firewall software, and configure actions based on the results returned.
    • If the protection configured requires a scan for viruses, the system can run virus-scanning operations, using actions associated with the Windows Antivirus Checker Inspector.
    • If the protection configured requires an updated version of an antivirus software package, the system can prompt the user to download and update the package. You can use the External Logon Page ending to send the user to a custom page you create on an external server, or to a page you create in the FirePass controller sandbox. For more information, search for WebDAV in the FirePass controller online help.
  • Request action from the user
    If the protection configured requires any action that the system cannot complete, you can configure a request that the user perform the action instead. For example, if the protection configured requires an updated version of an antivirus software package, and the system cannot automatically download and update the package, you can configure a request that the user download and update the package before continuing.

Protecting resources

The final task of the pre-logon sequence is to protect resources. Protected configurations use information that the inspectors gather to protect the resource you assign them to. Protected configurations use the values that the pre-logon sequence returns in its session variables to determine how to respond to requests for resource access.

Important

If you plan to use protected configurations to grant or deny access to resources, you must construct and activate a pre-logon sequence that collects all necessary information. If you assign protected configurations to your resources, but you do not activate a sequence, users receive the following message: Endpoint check is not activated or pre-logon inspection failed.

You can read more about protected configurations in Creating protected configurations . You can read more about protecting resources in Protecting resources .

Understanding protection options

You can configure protection options based on a number of factors, including operating system, type of browser used, presence of a specific file or process, and others. You can also define custom session variables in pre-logon sequences so that a protected configuration can check whether the user has passed a particular point in the pre-logon sequence. For more information about custom session variables, see the online help for the Endpoint Inspector Details screen for the Define custom variable inspector.

You can select from a wide range of antivirus and firewall software the FirePass controller supports, such as Symantec® (Norton AntiVirusTM), Networks Associates (McAfee®), and Microsoft®. The software supported changes frequently, so the current list is maintained in the FirePass controller release notes that accompany a specific release. In addition to antivirus and firewall detection, inspectors provide information about operating system, file versions, running processes, and others. You can use this information to configure protection options.

Note

You must have an Anti-Virus/Firewall / Inspector license on the FirePass controller to inspect the client system for antivirus and firewall software. If you do not have a license, contact your sales representative to get one.

The inspectors you set up on the FirePass controller evaluate or operate on client systems in several areas:

  • Antivirus and firewall detection
    Detects multiple antivirus and firewall installations on a client computer. You can use the Windows antivirus checker to determine whether the user has antivirus software installed, and to scan processes for the presence of viruses.
  • Operating system detection
    Discovers the version of the operating system running the client computer, so that protected configurations can use the version information.
  • File version checking
    Evaluates the versions of antivirus binaries, DLLs, signature files, and scan engines to determine whether they match the criteria you configure.
  • MD5 signature validation
    Inspects the MD5 signature of a file on a client system to ensure that the file has not been tampered with or corrupted.
  • Scan performance
    Performs scans for viruses on the client machine. You can specify several values to use when scanning for antivirus software:
    • Antivirus vendor
      Represents the maker of the antivirus software.
    • Engine version
      Represents the number assigned to a specific release of the software.
    • Database signature
      Represents an electronic, encryption-based, secure stamp of authentication provided by the antivirus vendor by which you can determine the authenticity of the software.
      You can find database signature information by searching the Internet or checking for the value on a specific product's web site.
    • Database update time
      Represents the timestamp on the antivirus software on the user's computer.
  • Custom inspector usage
    Gathers data related to the custom variable defined.
    For more information, see the Endpoint Inspector Details online help for the Define custom variable inspector.

Understanding protection limitations

For Windows clients, the FirePass controller downloads and installs ActiveX controls or Java plug-ins to gather some information on the client device. To install the controls or plug-ins, the logged on user must have power user rights on the device. You can also preinstall the controls on the client machine using an administrator account, or an account that has power user rights. For more information about installing client components, see Using MSI to preinstall client components, in Chapter 9 and Using the Component Installer, in Chapter 9 .

In addition, the client's browser must be configured to allow the running of ActiveX controls, Java, and JavaScript, otherwise, the inspection operation might not collect all of the information needed.

Pre-logon inspection switches to clientless mode automatically if installation of the required ActiveX control or Java plug-in failed due to insufficient rights, or the operating system does not support the control or plug-in. In clientless mode, information collection and actions that require client components are not performed. The following actions do not require any client components to be downloaded to the client system.

  • Show virtual keyboard
  • Send email
  • Check the time on the system
  • Check the type of device
  • Check the operating system
  • Check the client certificate
  • Write content to the Logon log

Using pre-logon sequences

The FirePass controller collects information from the client system by using inspectors. The various inspectors consist of ActiveX controls or Java plug-ins that collect information about the client system. When a user first accesses the FirePass controller, the browser downloads the inspector control or plug-in needed to check for a specific condition, process, or piece of data.

You can configure inspectors in pre-logon sequences, a named set of inspectors, rules, and actions, which evaluates each endpoint system presented for log on to the FirePass-controlled network.

Protected configurations use information that the inspectors gather. If the system meets the requirements configured in the protected configuration, the user is granted access to the resource requested.

You use the visual policy editor to create pre-logon sequences. The visual policy editor consists of a graphical area in which you click to add and delete actions and rules to use when inspecting the client system to determine whether it meets certain conditions.

You can configure pre-logon sequences using options on the Pre-Logon Sequence screen. To access the screen, click Users, expand Endpoint Security, and click Pre-Logon Sequence.

For step-by-step procedures for creating a pre-logon sequence, see Creating the Google Desktop Check pre-logon sequence, in Appendix A .

Understanding pre-logon sequence flow

When a pre-logon sequence is active and a user logs on, a series of operations occur based on the content of the sequence. Figure 3.1 describes the basic flow.

Figure 3.1 Pre-logon sequence flow

Understanding the visual policy editor

You use the visual policy editor to create and modify the pre-logon sequences you want to use in checking client systems. The layout of the sequence in the visual policy editor window provides visual clues to indicate the flow of the action as it occurs on the client system.

Figure 3.2 , following, contains the Corporate Access Check pre-logon sequence, which you can create by following steps in Denying and allowing logons from specific operating systems and requiring certificates, in Appendix A .

Figure 3.2 Corporate Access Check pre-logon sequence with open CHANGE SEQUENCE pane
Note

The Corporate Access Check pre-logon sequence contains an action named Show virtual keyboard, which is attached to the rule Windows NT and 2000. This action presents a visual representation for Windows NT and Windows 2000 users to protect against key-logger software. For more information about the Show virtual keyboard action, see the online help for the Virtual Keyboard enabler Endpoint Inspector Details screen.

Understanding pre-logon sequence elements

When you construct a pre-logon sequence, you use the visual policy editor to add actions, which are made up of rules. You can use one of the predefined actions, or you can construct one of your own. You can add inspectors to existing or custom actions, and you can build rules for the inspectors to use.

As you construct pre-logon sequences, you can use the elements described in Table 3.2 .

Table 3.2 Pre-logon sequence constituent elements
Element
Description
Action
Represents one or more inspectors associated with one or more rules. Actions provide the context for the inspectors. In the visual policy editor, actions appear inside a rectangle.
Rule
Contains one or more Boolean expressions that describe a specific condition. Rules evaluate what information the inspector collects. Each action has a fallback rule that evaluates to true so you can specify the action to take if the result is not acceptable. For example, the predefined action Check client certificate contains two rules: yes and fallback. The yes rule defines the action to take if the result returned is acceptable. The fallback rule defines the action to take if the result is not acceptable. In the visual policy editor, rules appear along connecting lines as underlined words.
Ending
Indicates the final outcome of the pre-logon inspection. The FirePass controller provides the following endings: Logon Allowed, Logon Denied, External Logon Page (Client data posted), Redirect (No client data posted), and Subsequence. In the visual policy editor, endings appear in a rectangle with a cut-out right edge.
External Logon Page and Redirect perform essentially the same function, except that Redirect uses the GET command for redirecting and does not send any data to the external server.
Subsequence
Represents a collection of actions, rules, and endings that branch off from the main sequence path. In the visual policy editor, subsequences appear in the lower portion of the screen, under the heading Subsequences. In the visual policy editor, a subsequence appears in a rectangle with a pointed-out right edge when it occurs in the sequence
The subsequence appears in a shaded rectangle with a pointed-out right edge when it occurs in the subsequence.

 

For an example of a subsequence, see Figure 3.2 .

Implementing client system checking

You want to make sure that all users accessing your resources are running on computers that meet your security requirements.

The pre-logon sequences you construct gather the information about the client system. The protected configurations you define use the information gathered, and associate safety measures to respond to potential threats. Once you have constructed the pre-logon sequences that gather the client-system information and defined protected configurations that use safety measures to address security risks, you assign the protected configurations to your resources.

In summary, when you implement endpoint security to check client systems, you must complete several tasks.

Important

You must create the pre-logon sequence to gather the information that the protected configurations needs. Otherwise, protected configurations block access.

Creating pre-logon sequences to protect resources

The first task of implementing endpoint security is to create a pre-logon sequence. The FirePass controller uses pre-logon sequences to provide the functionality, available on the Users : Endpoint Security : Pre-Logon Sequence screen.

In a pre-logon sequence, you configure inspectors to gather the information you want to have about the client. The inspectors create session variables containing the detected information. The FirePass controller passes the information to the protected configuration to determine access to protected resources.

The controller ships with several pre-defined sequence templates (for example, Google Desktop Search block, Collect information with no pre-logon actions, and Empty), which you can use or modify. You also can create new sequences, using any of these as your starting point, or an empty sequence with just a starting and ending point, if you prefer.

Once you create the sequence, you must use the data it gathers by creating a protected configuration. A protected configuration is a collection of safety measures or checks that guard the connection and client system against various kinds of attacks or threats.

Creating a pre-logon sequence

Creating pre-logon sequences basically consists of adding actions in the visual policy editor. Each action contains one or more rules that specify the criteria that you plan to evaluate, and an ending that follows depending on the outcome of the evaluation. For more information about actions, see Using actions in pre-logon sequences , and for more information about rules, see Defining rules for actions in pre-logon sequences .

For example, you might want to require that all users operate inside a protected workspace while they access a specific resource. To do so, you create a new sequence, and add the action that switches the user to the protected workspace.

To create a pre-logon sequence that checks whether the user is in the protected workspace

  1. In the navigation pane, click Users, expand Endpoint Security, and click Pre-Logon Sequence.
    The Pre-Logon Sequence screen opens.
  2. In the Create new sequence box in the New Sequence area, type a name for the sequence.
  3. From the Based on list, select template : Empty.
  4. Click Create.
    The new sequence appears in list of sequences in the upper portion of the screen.
  5. Click the edit link next to the sequence you created.
    The visual policy editor screen opens.
  6. Position the cursor along the connecting line between Sequence Start and Logon Allowed Page, until you see the Add Action button .
  7. Click the Add Action button .
    The screen refreshes to show the change sequence pane.
  8. In the list of Predefined actions, select Switch to PWS.
  9. Click the Apply changes button.
    The screen refreshes to show the Switch to PWS action, along with two rules: inside PWS, which continues to the Logon Allowed Page ending, and fallback, which continues to the Logon Denied Page ending. Figure 3.3 shows the completed pre-logon sequence.
Figure 3.3 The completed sequence containing the Switch to PWS action

Next, you use the data the pre-logon sequence gathered in a protected configuration. For more information, see Using data gathered by pre-logon sequences , following.

The active pre-logon sequence runs when a user tries to log on to the FirePass controller. Only one pre-logon sequence is active at any one time. A selected button next to the sequence name on the Users : Endpoint Security : Pre-Logon Sequence screen indicates the active pre-logon sequence.

Using data gathered by pre-logon sequences

In Creating a pre-logon sequence , preceding, you created a pre-logon sequence that inspects client systems for the protected workspace. Now, you can put that data to use in a protected configuration and assign the configuration to a resource favorite.

To create a protected configuration that uses the data collected by the protected workspace pre-logon sequence

  1. In the navigation pane, click Users, expand Endpoint Security, and click Protected Configurations.
    The Protected Configurations screen opens, showing a list of predefined protected configurations.
  2. Click the New Protected Configuration link.
    The Protected Endpoint Configuration definition screen opens.
  3. In the Protected configuration ID box, type a name of up to 30 characters for the protected configuration.
  4. In the Description box, type a description, if you wish.
  5. From Mode, select the type of access you want.
    Check endpoint protection, grant access if check passed is the default. This is the recommended setting for using protected configurations. The Temporary bypass check, grant access always and Temporary bypass check, do not grant access settings are for temporarily troubleshooting configurations and logon problems.
    You do not need to click Cancel or Save at this point.
  6. Click the Protection Criteria tab along the top of the table.
    The Protected Configurations screen opens with the Protection Criteria tab selected.
  7. Click the Information Leaks link.
    The screen refreshes to reveal the safety measures or checks associated with information leaks.
  8. From the list, select Protected Workspace, and then click Add.
    The Required safety measures or checks area refreshes to contain the Protected Workspace criterion.
  9. Click Save.
    The Protected Configurations screen opens, with the protected configuration you created shown at the bottom of the list.
  10. Next, you assign the protected configuration to a resource. For more information, see Assigning a protected configuration , following.

For more information about creating protected configurations, see Creating protected configurations .

Assigning a protected configuration

In Using data gathered by pre-logon sequences , preceding, you created a protected configuration that uses the protected workspace information the pre-logon sequence gathers. Now, you can put that protected configuration to work, by assigning the configuration to the webtop, an entire resource group, a resource type, or an individual favorite.

To assign a protected configuration to a favorite

  1. In the navigation pane, click Portal Access, or Application Access, and click an existing favorite or the Add New Favorite link.
    The favorite definition screen opens.
  2. From the Endpoint protection required list, select the protected configuration you just created.
  3. Click Update.
    The favorite appears in the list with the protected configuration assigned. Now, users clicking the favorite are switched to the protected workspace before being granted access to the associated resource.

You can also use settings on the Users : Endpoint Security : Protect Resources screen to assign a protected configuration to a favorite. For more information, see Protecting resources .

For more information about creating favorites, see Defining favorites for Portal Access Web Applications access, in Chapter 7 , Configuring Windows files, in Chapter 7 , Defining legacy host favorites, in Chapter 6 , or Configuring terminal server favorites, in Chapter 6 .

Using actions in pre-logon sequences

An action, depicted by a rectangle in the pre-logon sequence editor (see Table 3.2 ), is an ordered set of rules for evaluating a remote system. Each action invokes one or more inspectors. The action then uses rules to test the inspectors' findings.

An action invokes rules in the order they appear in the sequence. To change the order, delete the rule you want to move, and recreate it in the desired position. If the inspectors' findings satisfy a rule's conditions, the sequence passes to the element in the sequence specified by the rule. Otherwise, the process moves on to the next rule in the action.

The FirePass controller includes a number of predefined actions. You can see the available actions in the visual policy editor when you click the Add Action button , which is activated by positioning the cursor along the action's connector line. The action pane appears to the right of the visual sequence editor, as shown in Figure 3.2 . You can create your own custom rules in the action pane of the visual policy editor. To follow a step-by-step lesson in creating your own pre-logon sequence, see Appendix A, How-To Examples

When you create a new action, the sequence editor automatically creates a default rule, called fallback. The fallback rule is always the last rule in the ordered set of rules. It cannot be moved. It governs all cases that do not satisfy a preceding rule. The default next action for the fallback rule is the Logon Denied Page ending. You can change this by editing the ending, inserting additional actions, or adding other rules.

Figure 3.4 shows the internal structure of an action.

 

 

Figure 3.4 The flow of control in a pre-logon sequence action

You can see an example of the action pane for the Check for Antiviruses action in Figure 3.5 , available when you have a license for the Anti-Virus / FireWall Checker inspector. Table 3.3 shows the rules and definitions for the Check for Antiviruses action.

 

Table 3.3 Rules and definitions for the Check for Antiviruses action
Rule
Definition
Monitor is running
(session.av.summary.monitor >= 1) AND (NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)))
AV installed
(session.av.summary.count>0)AND (NOT(EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)))
Virus detected
EXIST(session.av_scan.infected) AND (session.av_scan.infected != 0)
fallback
The default rule for every action

 

The action pane is where you can type a description for the action, add and modify the action's inspectors, and define rules for the action to use. Figure 3.5 contains the Check for Antiviruses's action pane with the rules shown.

Figure 3.5 The action pane for the Check for Antiviruses action

For additional information, see the help for each inspector, and review the rules of the predefined actions shipped with the FirePass controller.

Defining rules for actions in pre-logon sequences

A rule tests the inspectors' findings about a client system. The outcome of the evaluation in a rule grants or denies access or sends the flow to the next action. The order of rules in a pre-logon sequence determines the flow of action.

In a pre-logon sequence, you use predefined actions with already defined rules. You can modify these rules or create new rules to test for a specific condition. You can create custom actions and add your own rules to them. The ending is the last rule applied. Figure 3.4 , shows the flow of a rule-checking operation.

A rule uses data from variables returned by inspectors to determine user access criteria. For more information about variables, see Using session variables in sequence rules .

By default, if the system does not meet the requirements, the FirePass controller denies the user access. You can change the outcome by changing the sequence ending, and by modifying rules to check for different criteria.

Using rule syntax

You can include the following syntax elements in rules:

  • Boolean operators: AND, OR, NOT
  • Operators:
    • less than <
    • less than or equal to <=
    • greater than >
    • greater than or equal to >=
    • equal to =
    • equal to ==
    • not equal to !=
  • Functions: EXIST()
  • Other symbols: (, ), "

Viewing rule examples

Following are some examples of rules. The first rule defines the criterion that a user's system be in the protected workspace.

session.pws.active == 1

The session variable session.pws.active has two possible values: 1, which indicates that the user's computer is operating inside the protected workspace, and 0, which indicates that it is not.

The second example represents a rule that searches for the presence of the McAfee antivirus software that has an engine version greater than or equal to 4.3.20, and checks to make sure that the most recent antivirus scan occurred on or after December 12, 2004, at midnight.

(EXIST(session.av.McAfeeAV))AND(session.av.McAfeeAV.engine_version >= "4.3.20")AND( session.av.McAfeeAV.last_scan >= "2004.12.10 00:00")

You can see an example of the not running rule included with the predefined action Google Desktop Search Checker in Figure A.6, in Appendix A . In this case, the rule description is session.google_desktop_check.result !=1, which indicates that when the session variable is not equal to 1, then the Google Desktop Search application is not running.

You can edit a rule by clicking the rule's link in the visual policy editor. The rules pane appears to the right of the visual sequence editor, as shown in Figure A.15, in Appendix A .

For additional information, see the help for each inspector and review the rules of the predefined actions shipped with the FirePass controller.

Using session variables in sequence rules

The rules in pre-logon sequences use the values that the inspectors return in session variables. A session variable contains a number or string that represents a specific piece of information. You can specify another action or an ending in response to the information returned. To understand how rules operate in sequences, you can view the sequence flow defined in the predefined actions provided with the FirePass controller.

You can use session variables to create your own rules to use in the custom actions you define.

To create a rule

  1. In the navigation pane, click Users, expand Endpoint Security, and click Pre-Logon Sequence.
    The Pre-Logon Sequence screen opens.
  2. Open an existing sequence, or create a new one.
    The visual policy editor opens.
  3. Add an action as described in Creating a pre-logon sequence .
    The action pane opens in the visual policy editor.
  4. From the Using list in the action pane, select New action.
  5. Click Apply changes.
    The sequence refreshes to contain the action New action.
  6. In the Name box in the action pane, change the name to a meaningful title for the action, and add some descriptive text in Description, if you like.
  7. Click Update details.
    The visual policy editor refreshes to show the title you specified.
  8. Position the cursor along the connecting line between the action you added and the fallback rule, until you see the Add Action button .
  9. Click the Add Action button .
    The screen refreshes to show the insert rule pane.
  10. In Name, type a name for the rule.
  11. In the larger box, type the session variable and the other text you want to use for the rule.
    For information about the expression syntax for rules, see Defining rules for actions in pre-logon sequences .

For a list of the session information returned by specific inspectors, see the online help for the Pre-Logon Inspection screen.

Creating subsequences for pre-logon sequences

Subsequences are defined sequences that run when processing encounters a branch in the sequence. Subsequences do not pass control back to the parent sequence from a subsequence; the flow continues through to the subsequence ending, or to another subsequence. However, when you are creating sequences, having subsequences can eliminate duplication in sequences. Using subsequences is particularly useful when you have a number of actions that all run the same series of rules, actions, and endings. For example, the Corporate Access Check sequence, which you can create by following steps in Appendix A, How-To Examples , contains a subsequence named Subsequence: certificate check that runs at the end of the Windows XP, Linux, PocketPC, and Mac OS rules.

The subsequences section of the visual policy editor appears below the main sequence section. You can create and use as many subsequences as you like to support the sequence you want to apply. Figure 3.6 contains an example of a subsequence.

 

 

Figure 3.6 The subsequence certificate check from the Corporate Access Check sequence

Browser requirements for endpoint security

The FirePass controller supports only specific browser versions and functionality. The browser enables communication with the client systems so that the inspectors can access information and perform scans and other operations. For information about browser requirements for client component download, see Downloading client components, in Chapter 9 . You can find the most current browser support list in the release notes. For information about user rights requirements for endpoint inspector support. see Installing client components on Windows systems, in Chapter 9 .

User rights requirements for protected workspace and pre-logon inspectors

Because of how the FirePass controller supports protected workspace and pre-logon inspectors, the user must have certain rights for the process to complete successfully. In most cases, this means the user must have Power User or Admin rights, or you must preinstall the components using an account with such rights. For more information, see Installing client components on Windows systems, in Chapter 9 .

Creating protected configurations

Once you have determined the client information you plan to gather, you create protected configurations, named sets of safety checks and security measures, to assign to resources, applications, and files.

Protected configurations represent the conditions that control access to resources under their protection. Controlled conditions include what antivirus software the endpoint system is running, whether a logon comes from a company-issued computer, what time of day the logon occurs, which certificate the client is using, and others. Protected configurations provide a way for you to collect a set of safety requirements, store it under a name of up to 30 characters, and assign it to a resource to define a very restrictive set of configurations that govern access to the resources presented to end users.

Security measures help guard against factors that put network resources at risk. These are described in the risk-factor/safety-feature associations table on the Protected Configurations configuration screen. To access the screen, click Users, expand Endpoint Security, click Protected Configurations, and click the New Protected Configuration link, or click the name of an existing protected configuration.

In order to use a protected configuration, a pre-logon sequence inspector must gather the necessary information. For information about pre-logon sequences and inspectors, see Using pre-logon sequences .

Important

Protected configurations use the result of the pre-logon and post-logon operations to determine how to respond to requests for resource access. To take advantage of protected configurations, you must define and activate a pre-logon sequence. If you assign a protected configuration without properly configuring a pre-logon sequence, you lock out all access to that resource.

You can assign protected configurations at a very granular level by exempting specific master groups from safety checks configured for a resource. For a very refined accessibility/protection trade-off, you can combine safety checks using Boolean logic, as described in the Defining rules for actions in pre-logon sequences .

Table 3.4 , following, provides a summary of risk factors and associated protection criteria available for protected configuration definitions.

 

Table 3.4 Risk factors and associated protection criteria
Risk factor
Available protection
Unauthorized Access
The following protection criteria are available for preventing unauthorized access:
Client Certificate
Requires that the client certificate meet criteria specified in properties. For this type of protection, you must enable a pre-logon sequence.
Trusted Network
Specifies that logon is restricted to traffic arriving from the networks specified in properties. To access properties, click the [ I ] icon to the right of the Trusted Network entry in the table. For this type of protection, you must enable a pre-logon sequence.
Time Interval
Restricts access to the days and hours specified in properties. This protection requires no pre-logon sequence.
Custom Check
Checks variables collected by the pre-logon sequences (or a variable set by the define custom variable inspector). For this type of protection, you must enable a pre-logon sequence.
Note: Only the Custom Check protection can use the data returned by the user-defined variable in a pre-logon sequence. For more information, see the online help for the Endpoint Inspector Details screen for the Define custom variable inspector.
SSL Encryption Control
Provides options for requiring specific SSL cipher security and SSL protocol versions. You can read more about SSL cipher and protocol settings in the online help for the Device Management : Security : User Access Security screen. For this type of protection, you must enable a pre-logon sequence.
Note: F5 Networks recommends that customers use TLS only protocol option to ensure maximum FIPS cipher compliance. In addition, to ensure maximum FIPS compliance, F5 recommends that SSL certificates that administrators import into the FirePass controller use FIPS-approved SHA1 instead of MD5 as their signing algorithm.
To maximize FIPS compliance, configure FirePass systems to allow only TLS (that is, select the Accept only TLS protocol option), and verify that all RSA private keys for Web Services have been imported into the FIPS card. On systems with imported keys, the Security field lists FIPS instead of Normal in the online help for the Configure SSL Certificates screen, available as a link on the Web Services tab on the Device Management : Configuration : Network Configuration screen.
No Measure or Check Required
Indicates that no protection is configured for the risk factor. For this type of protection, you must enable a pre-logon sequence.
Logon Allowed
Checks that prelogon inspection was done and that logon was allowed. For this type of protection, you must enable a pre-logon sequence.
Information Leaks
In addition to Client Certificate, No Measure or Check Required, and Trusted Network, described above, the following protection criteria are available for preventing information leaks:
Protected Workspace
Requires a user workspace that prevents external access, and deletes any files created before leaving the protected area. When you add the Protected Workspace protection, the user is placed into the protected workspace after logging on successfully. Operating inside the protected workspace restricts access to specific folders, and deletes all files created when the user logs out. You can read more about using the protected workspace inspector in the Endpoint Security : Pre-Logon Sequence online help. For this type of protection, you must use the Protected Workspace inspector in an enabled pre-logon sequence.
Trusted Windows Version
Restricts access to users running specific Windows versions or hot-fixes, as specified in properties. If you specify Trusted Windows version, make sure also to configure the versions you want to accept in properties. To access properties, click the [ I ] icon to the right of the Trusted Windows Version entry in the table. For this type of protection, you must use the Extended Windows information inspector in an enabled pre-logon sequence.
Cache Cleaner
Removes content from the cache when users log out. For this type of protection, you must enable Inject ActiveX/Plugin to clean-up client browser web cache on the Users : Endpoint Security : Post-Logon Actions screen.
Trusted Browser
Requires use of a browser specified in properties. If you specify Trusted Browser, make sure also to configure the browsers you want to accept in properties. To access properties, click the [ I ] icon to the right of the Trusted Browser entry in the table. For this type of protection, you must use the Internet Explorer information inspector in an enabled pre-logon sequence.
You can read more about the inspectors in the online help.
Loggers
In addition to Protected Workspace, Trusted Network, Client Certificate, and No Measure or Check Required, described above, the following protection criteria are available for preventing access by key-logging programs:
Virtual Keyboard
Specifies that passwords be entered using mouse clicks on a screen representation of a keyboard. For this type of protection, you must use the Virtual Keyboard Enabler inspector in an enabled pre-logon sequence.
Registry Control
Associates a result with a specific name generated by a Pre-Logon add Windows registry checker operation. For this type of protection, you must use the Windows registry checker inspector in an enabled pre-logon sequence.
Process Control
Associates a result with a specific name generated by a Pre-Logon add Windows process checker operation. For this type of protection, you must use the Windows process checker inspector in an enabled pre-logon sequence.
File Control
Associates a result with a specific name generated by a Pre-Logon add Windows file checker operation. For this type of protection, you must use the Windows file checker inspector in an enabled pre-logon sequence.
Virus Attack
In addition to Protected Workspace, Virtual Keyboard, Trusted Network, Client Certificate, Registry Control, Process Control, File Control, and No Measure or Check Required, described above, the following protection criteria are available for preventing virus attacks:
Antivirus
Requires the presence of specific antivirus software. You specify the antivirus software in the properties for this type of protection. To access properties, click the [ I ] icon to the right of the entry in the table. For this type of protection, you must use the Windows antivirus checker inspector in an enabled pre-logon sequence.
Firewall
Requires the presence of specific firewall software. You specify the antivirus software in the properties for this type of protection. To access properties, click the [ I ] icon to the right of the entry in the table. For this type of protection, you must use the Windows firewall checker inspector in an enabled pre-logon sequence.
Note: You must have an Anti-Virus/Firewall / Inspector license on the FirePass controller to inspect the client system for antivirus and firewall software. If you do not have a license, contact your sales representative to get one.

 

Protecting resources

Once you have created the protected configurations you want, you protect resources, a process of assigning protected configurations to resources, applications, and file stores. The FirePass controller uses protected configurations to control access to network resources.

For example, you may have a general configuration for all Network Access favorites, which require only that the logon arrive from a computer with installed and running antivirus software. In this case, you would create a pre-logon sequence that requires company-provided antivirus software, define a protected configuration that uses the information from the pre-logon sequence, and assign the protected configuration to all Network Access favorites. This prevents access to network resources from computers that are possibly infected, thus protecting your corporate intranet.

The FirePass controller uses protected configurations to control access to network resources. A protected configuration is a definition of criteria that users' systems must meet in order to be granted access to specific resources. Once you define a protected configuration, you must assign it. You can assign resource protection at the following levels:

  • Webtop
    Protects all types of resource favorites.
  • Resource type
    Protects a class of resource favorites (for example, Web Applications or Network Access favorites).
  • Resource group
    Protects all elements defined in resource group including favorites and access control lists.
  • Individual
    Protects a single resource (for example, the Sales Intranet).

Protection is cumulative. That is, each type of protection is combined, so that the effect is additive, affecting all resources at all levels.

Important

Protected configurations use the result of pre-logon and post-logon operations to determine how to respond to requests for resource access. To take advantage of protected configurations, you must define and activate a pre-logon sequence. If you assign a protected configuration without properly configuring a pre-logon sequence, you lock out all access to that resource.

You can define custom session variables in a pre-logon sequence, so protected configurations can check whether a user has passed a particular point in the logon sequence. For more information, see the online help for pre-logon sequences. For information about protected configurations, see Creating protected configurations . For information about pre-logon sequences, see Using pre-logon sequences .

Understanding protection assignment

This is an example of how to implement access control using protected configurations.

The sample company has a general configuration for all Network Access resource favorites, most of which require only that the logon arrive from a computer running antivirus software. In this case, you create a pre-logon sequence that requires company-provided antivirus software. In addition, for the Sales Intranet, the company wants to further require that the employee use a company-issued laptop authenticated with a client certificate, and that only members of the Executive and Sales groups are eligible.

For this configuration, the FirePass controller administrator creates and uses two protected configurations: a general configuration (which allows access to all Network Access resources not otherwise secured) that requires that the user's computer has antivirus protection, and a second configuration (which grants access to Sales and Executive users with certificate-bearing company laptops) that allows certain users also to access the Sales Intranet.

Configuring post-logon protection

For additional security, you can configure protection that runs after the user logs on to the FirePass controller. You can configure to download an ActiveX control or Java plug-in to support the following kinds of post-logon protection.

  • Activate cache cleanup to allow attachment downloads in Mobile E-Mail and downloads from Web Applications.
  • Activate cache cleanup to allow file downloads in Windows Files. If this option is not enabled, the user can only download .zip archives.
  • End the FirePass controller session if the user closes the browser or webtop.
  • Uninstall downloaded FirePass controller components.
  • Remove dial-up entries that Network Access clients use.
  • Uninstall ActiveX components downloaded during the session.
  • Empty the Windows Recycle Bin.
  • Clean forms and passwords autocomplete data.
  • Close Google Desktop Search.
  • Inherit caching policy settings from Portal Access Web Applications configuration.

You can specify different post-logon protection for each master group.

For more information on each of these options, see the help for the Post-Logon Actions screen, available under Users : EndPoint Security.

Using other kinds of protection

In addition to the protected configurations described in Table 3.4 , there are other protections such as:




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)