Desktop Security

In This Section: The Need for Desktop Security Desktop Security Solution Desktop Security Considerations Letting Users Disable the Firewall Avoiding Double Authentication for Policy Server

The Need for Desktop Security

Security Gateways enforce Security Policies on traffic that passes through the Security Gateways in the network. Remote clients are located outside of the protected network and traffic to the remote clients does not pass through the Security Gateways. Therefore remote clients are vulnerable to attack.

Attackers can also use unprotected remote access clients to access the protected network, through the VPN tunnel.

Desktop Security Solution

Check Point clients that include Desktop Security, such as Endpoint Security VPN, enforce a Desktop Security Policy on the client to give it Firewall protection. The administrator defines the Desktop Security Policy in the Desktop Rule Base in SmartDashboard. You can assign rules to specified user groups or to all users.

The Security Management Server downloads the Desktop Security Policy to a Policy Server, which is a feature that you enable on the Remote Access Security Gateway. Remote Access Client computers download their Desktop Security Policies from the Policy Server when they connect to the Security Gateway.

Clients enforce the Desktop Policy to accept, encrypt, or drop connections based on the Source, Destination, and Service.

Note - If you use Endpoint Security VPN as part of the Check Point Endpoint Security Suite, you can configure if your client Firewall comes from Desktop Security in SmartDashboard or SmartEndpoint.

Item	Description
1	Security Management Server
2	Firewall
3	Internet
4	Gateway and policy server
5	Security Gateway
6	Remote Access Client

The Desktop Security Policy

The Desktop Security Policy has Inbound and Outbound rules.

• Inbound rules - Enforced on connections going to the client computer.
• Outbound rules - Enforced on connections that originate from the client computer.

Each rule defines traffic by source, destination, and service. The rule defines what action to enforce on traffic that matches.

• Source - The network object that initiates the communication.
• Destination - The user group and location for Inbound communications, or the IP address of Outbound communications.
• Service - The service or protocol of the communication.
• Action - Accept, Encrypt, or Block.

Connections to computers inside of the organization, for example, all of the machines in the VPN domain of the Security Gateway, are automatically encrypted, even if the rule that lets them pass is an Accept rule.

Implied Rules

In addition to the rules that you define, the Desktop Security Policy has implicit rules added to the end of the inbound and outbound policies.

• The implicit outbound rule allows all connections that originate from the client to go out, if they do not match previous blocking rules:
  Any Destination, Any Service = Accept.
• The implicit inbound rule blocks all connections coming to the client that do not match previous rules.
  Any Source, Any Service = Block.

User Granularity

You can define different rules for remote users based on locations and user groups.

• Locations - Set rules to be implemented by physical location. For example, a user with a laptop in the office building will have a less restrictive policy than when the same user on the same laptop connects from a public wireless access point.
• User Groups - Set rules to be implemented for some users and not others. For example, define restrictive rules for most users, but give system administrators more access privileges. In addition, you can define rules to be enforced for all remote users, by not specifying a specific user group, but rather all users.

Rules apply to user groups, not individual users. The client does not identify user groups, so it must get group definitions from the gateway when it connects. The gateway resolves the user groups of the authenticated user and sends this information to the client. The client enforces the rules that apply to the user, based on the user groups.

Rules can also be applied to radius groups on the RADIUS server.

Default Policy

When a client is started, and before it connects to the Policy Server, it enforces a "default policy," which consists of the rules defined for all users in the last policy downloaded from the Policy Server. This is because at this point, the client does not know to which groups the user belongs. The default policy is enforced until the user downloads an updated policy (and the current user's group information) from a Policy server.

If a client loses its connection to the Policy Server, it enforces the default policy until the connection is restored and a Policy is downloaded.

Configuring Desktop Security

To enable the gateway to be a Policy Server for Desktop Security:

1. Click Gateways & Servers and double-click the Security Gateway.

   The gateway window opens and shows the General Properties page.

2. On the Network Security tab, select IPsec VPN and Policy Server.
3. Click OK.
4. Publish the changes.

To activate the Desktop Security policy:

1. Click Security Policies and open the Manage Policies window (CTRL + T).
2. Click the All icon.
3. Select the policy to edit and click Edit.

   The policy window opens.

4. Select Desktop Security.
5. Click OK.
6. Install policy.

To configure the Desktop Policy rules:

1. Click Security Policies, and from the navigation tree, click Access Control > Desktop.
2. Click Open Desktop Policy in SmartDashboard.

   SmartDashboard opens and shows the Desktop tab.

3. Configure the inbound rules: Click Rules>Add Rule to add rules to the policy.

   In inbound rules, the client computer (the desktop) is the destination. Select user groups to which the rule applies.

4. Configure the outbound rules. Click Rules>Add Rule to add rules to the policy.

   In outbound rules, the client computer (the desktop) is the source. Select user groups to which the rule applies.

5. Click Save and close SmartDashboard.
6. Install the policy.

   Make sure that you install the Advanced Security policy on the Security Gateways and the Desktop Security policy on your Policy Servers.

Operations on the Rule Base

Define the Desktop Security Policy. Rules are managed in order: what is blocked by a previous rule cannot be allowed later.

The right-click menus of the Rule Base include these options:

• Add Rule - Add a rule above or below the selected rule.
• Delete - Delete rules which are no longer necessary.
• Hide - Hide rules that are irrelevant to your current view, to enhance readability of your Rule Base. Hidden rules are still applied.
• Disable Rule - Rules that are currently not implemented, but might be in the future, can be disabled.
• Where Used - See where the selected network object is included in other rules.
• Copy as Image – Copy a picture of the rule to your clipboard.
• Copy Rule UID – Copy the unique UID for the rule.
• View Rule Logs - See logs for traffic that matched this rule.
• Negate Cell - If a cell is negated, the rule will then be an "all-except" the object or service. For example, if http is negated in the Service column, all services except http are included in the rule.

Making a Rule for FTP

If clients use active FTP, you must add a rule to the Desktop Security Policy to specifically allow the service that you need. Select be one of the active FTP services that is not ftp-pasv.

To add the Active FTP Rule:

1. In SmartDashboard, open the Desktop tab.
2. Right-click the Outbound rules and select Add.
3. In the rule, select one of the FTP services as the service and Accept as the action.

Policy Server

A Policy Server is installed on a Security Gateway, when you enable it in the Gateway General Properties > Network Security tab. It serves as a repository for the Desktop Security Policy. Client machines download their Desktop Security Policies from the Policy Server.

When the client computer connects or re-authenticates to the site, it automatically checks the Policy Server for updates and downloads them.

Location-Based Policies

Location-based policies add location awareness support for the Desktop Firewall using these policies:

• Connected Policy - Enforced when:
  • VPN is connected.
  • VPN is disconnected and Location Awareness determines that the endpoint computer is on an internal network. The Connected Policy is not enforced "as is" but modified according to the feature's mode (the disconnected_in_house_fw_policy_mode property).
• Disconnected Policy - Enforced when the VPN is not connected and Location Awareness sees that the endpoint computer is not on an internal network.

Location-Based Polices for Desktop Firewall are disabled by default.

Configuring Location Awareness

The Location Awareness configuration is based on these properties in the client configuration file:

• disconnected_in_house_fw_policy_enabled - Defines if the feature is enabled or disabled.

  Possible values are:

  • true - enabled
  • false - disabled (default)
• disconnected_in_house_fw_policy_mode - Defines which policy will be enforced after Location Awareness detection.

  Possible values are:

  • encrypt_to_allow - Connected policy will be enforced, based on last connected user. Encrypt rules will be transformed to Allow rules (default).
  • any_any_allow - "Any – Any – Allow" will be enforced.

To enable Location Awareness for desktop firewall:

1. On a gateway, open $FWDIR/conf/trac_client_1.ttm.
2. Add the disconnected_in_house_fw_policy_enabled entry to the file:

   :disconnected_in_house_fw_policy_enabled ( :gateway (disconnected_in_house_fw_policy_enabled :default (true) ) )

3. Save the file and install the policy.

To configure the location based policy:

1. On a gateway, open $FWDIR/conf/trac_client_1.ttm.
2. Add the disconnected_in_house_fw_policy_mode entry to the file:

   :disconnected_in_house_fw_policy_mode ( :gateway (disconnected_in_house_fw_policy_mode :default (encrypt_to_allow) ) )

3. Save the file and install the policy.

Note - It is highly recommended to configure default values for these properties in trac_client_1.ttm for all gateways.

Logs and Alerts

Desktop Security logs are saved locally on the client computer in:

• 32-bit systems - C:\Program Files\CheckPoint\Endpoint Connect\trac_fwpktlog.log
• 64-bit systems - C:\Program Files(x86)\CheckPoint\Endpoint Connect\trac_fwpktlog.log

Alerts are saved and uploaded to the Security Management Server when the client connects. You can see alerts in the Logs tab in the SmartConsole Logs & Monitor view.

Blocking or Allowing IPv6 Traffic

By default, the desktop firewall allows IPv6 traffic to the client.

To block IPv6 traffic to the client:

1. On the Security Gateway, open this file for editing:

   $FWDIR/conf/trac_client_1.ttm

2. Add these lines:

   :allow_ipv6 ( :gateway (allow_ipv6 :default (false) ) )

3. Save and close the file.
4. Install policy.

Wireless Hotspots

Desktop Policy can support wireless hotspots.

A proxy might be required.

Desktop Security Considerations

Plan your Desktop Security policy to balance considerations of security and convenience. You want to let users work as freely as possible, but at the same time, make it hard to attack the remote user's computer. Important points:

• Do not explicitly allow a service in the inbound policy unless the user has a server running on that port. If you do allow a service on inbound connections to the client, define who is allowed to open the connection, and from where.
• The best way to implement the outbound policy is to use rules only to block specified problematic services (such as Netbus) and allow the rest. A restrictive policy (for example, allow only POP3, IMAP and HTTP and block all the rest) will make it more difficult for your users to work. If you allow only specified services in the outbound policy and block all others, you will have to update the policy often when you learn that users need a different service.
• Outbound connections to the encryption domain of the organization are always encrypted automatically , even if the outbound rule for the service specifies Accept.
• Keep in mind that the implied rules (see Implied Rules) might allow or block services which were not explicitly handled in previous rules. For example, if a server runs on a client computer, you must create an explicit rule that allows the connection to the client computer. If you do not, the connection will be blocked by the inbound implicit block rule.