Content Security with Check Point Firewall-1
This chapter is from the book
This chapter is from the book
This chapter is from the book
In the last chapter, I talked about restricting access based on the user; in this chapter, I talk about restricting access to certain kinds of content. Such restrictions include not allowing people to access certain kinds of sites (e.g., pornography, news), preventing people from accessing specific types of content (e.g., RealAudio, MP3), and scanning content for viruses. I also discuss the various Security Servers for HTTP, FTP, SMTP, and TCP in some detail.
By the end of this chapter, you should be able to:
-
Know what CVP and UFP are used for
-
Restrict content for HTTP, FTP, SMTP, and generic TCP services
-
Understand the performance issues inherent in Content Security
-
Understand how to tune your FireWall-1 installation to perform well
-
Troubleshoot problems with Content Security
The Security Servers
FireWall-1 normally relies on Stateful Inspection. However, like authentication, the business of virus and content filtering requires more capabilities than can be provided by Stateful Inspection alone. In these cases, FireWall-1 uses the various Security Servers to perform the necessary tasks. In the last chapter, I discussed how they were used for authentication. In this chapter, I look at each individual Security Server a bit more closely and explain how to configure them.
A Word about Licensing and Third-Party Products
All firewall modules can use Content Security. Certain kinds of embedded firewalls cannot use Content Security. However, in order to use more than the rudimentary functions of Content Security in FireWall-1, third-party software is required. Check Point maintains a list of compatible applications and software vendors at http://www.opsec.com.
CVP and UFP
Inevitably, Check Point recognized that it could not do everything in terms of providing security. Consequently, Check Point created a program called Open Platform for Security (OPSEC), which allows third-party products to "hook in" to Check Point FireWall-1 and provide services. Two of these protocols, Content Vectoring Protocol (CVP) and URL Filtering Protocol (UFP), are discussed in this section. Some of the other OPSEC functions include the following:
-
Suspicious Activity Monitoring Protocol (SAMP): Provides for intrusion detection
-
Log Export API (LEA): Offers the ability to analyze firewall logs
-
Event Log API (ELA): Helps other applications tie into Check Point's alerting mechanisms
-
OPSEC Management Interface (OMI): Allows third-party products to access the security policy
-
Public Key Infrastructure (PKI): Enables Check Point to use third-party certificate authorities for authentication and encryption
-
Secure Authentication API (SAA): Allows Check Point to use a variety of authentication mechanisms such as hardware-based tokens and biometric authentication
-
High Availability (HA): Provides for highly available firewall servers
-
User-to-Address Mapping (UAM): Helps authenticate and track users more effectively
-
User Authority API (UAA): Offers the ability to pass authentication information to other servers in order to reduce the number of authentication prompts
CVP is used to scan content. It is typically used to scan for viruses, but it can also be used to scan for malicious Java applets or ActiveX controls, depending on which CVP server you decide to use. CVP works this way: A content stream is intercepted by one of the Security Servers. FireWall-1 determines that the content needs to be scanned by the CVP server before allowing the content to be given to the end user. As the content is downloaded through the firewall, it is sent to the CVP server, which typically runs on a separate server from the firewall. The CVP server then takes one of three actions toward the content (this action is configured in the security policy).
-
Send the content as is, without any modifications.
-
Send corrected content, with the virus or other offending content removed.
-
Do not send the content at all.
Table 9.1. Wildcards usable in all resources
|
Character |
Description |
|---|---|
|
* |
Matches any string of any length. For example, *@phoneboy.com matches all e-mail addresses at phoneboy.com. |
|
+ |
Matches any single character. For example, pink+@acmelabs.com would match pinky@acmelabs.com but not pinkie@acmelabs.com. |
|
{ ,} |
Matches any of the listed strings. For example, brain@{ acmelabs,animaniacs} .com would match both brain@acmelabs.com and brain@animaniacs.com. |
UFP is used to filter HTTP traffic destined for the Internet based on URLs and the categories under which they fall. As a user requests a URL in his or her Web browser, FireWall-1 uses the HTTP Security Server to check that URL against a UFP server, which returns the category for the URL. Based on that category and the defined security policy, FireWall-1 either permits the connection to the URL or rejects it. This allows, say, Christian organizations to filter non-Christian content or for workplaces to filter pornography.
Resources and Wildcards
Resources are simply a way to match a specific kind of content and then perform some action on it. Some resources are matched based on a query to a UFP server. Others are matched based on specific resources that you define.
The wildcards listed in Table 9.1 can be used in all resources. SMTP provides an additional wildcard, which is discussed in the SMTP Security Server section later in this chapter.