Desktop Security

In This Section: The Need for Desktop Security Desktop Security Solution Desktop Security Considerations Configuring Desktop Security

The Need for Desktop Security

A Security Gateway protects a network by enforcing a Security Policy on the traffic to and from that network that passes through the Security Gateway. A remote client, located outside the protected network, is vulnerable to attack because traffic to the remote client does not pass through the Security Gateway. No Security Policy is enforced on this traffic.

There is a further danger: An attacker might gain access to a protected network by compromising a remote client, which can then compromise the protected network (for example, by relaying a virus through the VPN tunnel). Even if the Security Gateway enforces a very restrictive Security Policy, the LAN remains vulnerable to attacks routed through unprotected remote clients.

Desktop Security Solution

Introducing Desktop Security

Check Point clients that include Desktop Security, such as Endpoint Security VPN, protect remote clients by enforcing a Desktop Security Policy on the client. The administrator defines the Desktop Security Policy in the Desktop Rule Base in SmartDashboard. Rules can be assigned either to specific user groups or to all users, enabling the definition of flexible policies.

The Desktop Security Policy is downloaded by the Security Management Server to a Policy Server, a module installed on a Security Gateway, which serves as a repository for the Desktop Security Policy. Client machines download their Desktop Security Policies from the Policy Server.

When a client connects to the organization's Security Gateway to establish a VPN, it can connect to a Policy Server as well and retrieve its Desktop Security Policy and begin enforcing it. Clients can accept, encrypt or drop connections depending on their Source, Destination, and Service.

The Desktop Security Policy

The Desktop Security Policy is divided into two parts:

• Inbound rules — Enforced on connections destined to the client machine.
• Outbound rules — Enforced on connections originating from the client machine.

A rule in a Desktop Security Policy specifies the following:

• Source
• Destination
• Service
• Action (Accept, Drop, Encrypt)
• Track (log, Alert)

Connections to machine inside the organization (i.e. all the machines in the VPN domain of the Security Gateway) are automatically encrypted, even if the rule allowing them to pass is an accept rule.

Implied Rules

In addition to the inbound and outbound rules explicitly defined by the administrator, implicit "cleanup" rules are automatically appended at the end of both the inbound and outbound policies:

• The outbound implicit rule allows all connections originating from the client machine, thus allowing connections which do not match any of the previous rules.
• The inbound implicit rule blocks all connections destined to the client machine which do not match any of the previous rules, on the assumption that what is not explicitly allowed is to be rejected.

User Granularity

You can define different rules for remote users based on location and user groups:

• Location — You can define a less restrictive policy for a user connecting from within the organization and a more restrictive policy for the same user connecting from outside the organization. For example, a user with Endpoint Security VPN installed on his laptop who connects from within the organization is less restricted and the same user connecting from outside from a hotel room is more has more restrictions. This is done in the user's security Rule Base by configuring the location of the users for which the rule should be implemented.
• User Groups — Define different rules for users in different user groups. For example, you can define restrictive rules for ordinary users, but allow 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 do not specify individual users but rather user groups. Because the client does not know in which groups the currently logged-in user belongs, it must get this information from the Policy Server. After the client authenticates itself to the Policy Server, the Policy Server resolves the user groups to which the user belongs and sends this information to the client. Then the client is able to enforce the rules defined for that user. 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.

Policy Server

What is a Policy Server?

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

High Availability and Load Balancing

For load balancing and High Availability, you can configure multiple Policy Servers. Load balancing can be especially important at times of high load, for example, when a large number of users log in at the beginning of the work day.

Connect Mode

• High Availability between all Policy Servers, trying selected first — Clients always try the specified Policy Server first. If this server is unavailable, the client randomly chooses a different server from among the remaining servers.
• High Availability only among selected Policy Servers — Clients randomly choose a Policy Server from the specified group. This option provides Load Balancing as well, since the load will be more equally distributed among the Policy Servers.

Policy Download

When is a Policy Downloaded?

When a user creates a VPN site on the client, a list of Policy Servers is downloaded to the client machine. If the user is using Connect mode (the default mode), a policy will be automatically downloaded from a Policy Server when the client machine connects to the site. The automatic policy download can also be disabled from the user's profile.

Logs and Alerts

Logs and alert specified Desktop Security Policy can be viewed using the SecureClient Diagnostics. In addition, all alerts are saved and uploaded to the Security Management Server. When the client connects to a Policy Server, it uploads the alerts to a spooling process, which passes the alerts to the Security Management Server, where they can be viewed by the SmartView Tracker.

Desktop Security Considerations

Desktop Security Considerations

You should carefully plan your users policy, properly balancing considerations of security and convenience. The policy should allow the desktop users to work as freely as possible, but at the same time make it hard to attack the remote user's desktop. Here are some points to consider:

• You should not explicitly allow any service to be opened to clients (i.e. allow a service in the inbound policy), unless the user has a specific server running on that port. Even if you do allow connections to be opened to the client, be very careful about who is allowed to open the connection, and from where.
• A restrictive policy (e.g., 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 specific services in the outbound policy and block all the rest, every time you will find out that a certain service is needed by your users, you will have to change the outbound policy and make sure the clients poll the new policy. The best way to implement the outbound policy is to use rules only to block specific problematic services (such as Netbus) and allow the rest.
• Outbound connections to the encryption domain of the organization are always encrypted, even if the outbound rule for the service specifies "accept".
• Keep in mind that the implied rules (see Implied Rules) may allow or block services which were not explicitly handled in previous rules. For example, if your client runs a server on his machine, you must create an explicit rule allowing the connection to the client's machine. If you do not, the connection will be blocked by the inbound implicit block rule.

Avoiding Double Authentication for Policy Server

When using Policy Server High Availability, it is possible that users will connect to the organization through one Security Gateway and to a Policy Server which is installed on a different module. In this case they will be prompted twice for authentication — once for the Security Gateway module and the other for the Policy Server. If a user usually connects to the organization through a specific Security Gateway, and this Security Gateway has a Policy Server module installed on it, this double authentication can be avoided by configuring the user's profile to use the High Availability among all Policy Servers, trying selected first option, and selecting the primary Policy Server as that one the Security Gateway through which the user usually connects to the organization. This way, after the user authenticates to the Security Gateway, he will automatically be authorized to download the security policy from the Policy Server installed on that Security Gateway.

Configuring Desktop Security

Desktop Security must be configured on the server and on the client machine.

Server Side Configuration

To install desktop security on the server:

1. Install the Policy Server add-on module.

   The Policy Server add-on should be installed only on machines that have Security Gateway modules installed on them.

2. Open the Security Gateway object on which you have installed a Policy Server and select the General Properties tab. In the Check Point Products section select SecureClient Policy Server.
3. Go to the Authentication tab. In the Policy Server > Users section select a group of users that is allowed to retrieve policies from this Policy Server.
4. Repeat steps 2 and 3 for each additional Policy Server.
5. Go to Policy > Global Properties and select the Remote Access tab. In Revert to Default Policy after, select the time-out for desktop security policies (see Policy Renewal).
6. In the policy selection toolbar, select Desktop Security.
7. Configure the inbound rules. Using the Rules>Add Rule menu item, you can add rules to the policy.

   In inbound rules, the SecureClient (the desktop) is the destination, and you can specify the users to which the rule is to be applied.

8. Configure the outbound rules.

   In outbound rules, the SecureClient (the desktop) is the source, and you can specify the users to which the rule is to be applied.

9. Install the policy. Be sure to install both the Advanced Security policy on the Security Gateways and the Desktop Security policy on your Policy Servers.

Client Side Configuration

1. Double click the SecureClient icon at the bottom right side of your desktop and press Properties.
2. Choose Logon to Policy Server if you wish to logon to a Policy Server automatically after connecting to a site.
3. Select Support Policy Server High Availability if your site has several Policy Servers and you want SecureClient to attempt to load balance between them. If you choose to use this feature you must select one of the following:
   • High Availability among all servers, trying selected first — Select the primary Policy Server.
   • High Availability only among selected servers — Select the servers to which you wish to connect.

As an administrator, you can eliminate the user's need to configure these steps by creating a custom profile for them.