Sample Configurations

The following subsections present three situations that build on each other as the network and the needs of the enterprise change.

SMTP Content Security

The Situation

Your company wants to gradually roll in Content Security throughout its enterprise. One of the most prevalent sources of viruses has been incoming e-mail, so the managers decide to start with e-mail. Both incoming and outgoing e-mail will be scanned. HTTP and FTP traffic will eventually be scanned. (This functionality will be added in the next two situations.) The CVP and UFP servers are sitting in the DMZ. Figure 9.33 shows the network diagram for this company.

Figure 9.33. Network diagram for sample configuration

graphics/09fig33.gif

The Goals
  • The Web server in the DMZ will be accessible via HTTP from anywhere.

  • The e-mail server in the DMZ will be accessible via SMTP from anywhere and can send e-mail to anywhere on the Internet.

  • The e-mail server in the DMZ can talk to the internal e-mail server via SMTP and vice versa. In either case, all traffic will be scanned for viruses.

  • Clients on the internal network can talk to any host via HTTP and FTP.

  • The UFP and CVP servers need to access their respective vendors' Web sites via HTTP to download updates (www.cvp-vendor.com and www.ufp-vendor.com).

  • All other traffic should be denied.

The Checklist
  • Create the necessary network objects.

  • Ensure that the SMTP Security Server is enabled in $FWDIR/conf/fwauthd.conf.

  • Create two SMTP resources to handle inbound and outbound e-mail between the internal and the DMZ e-mail servers and scan viruses.

  • Create the appropriate rule(s) in the rulebase.

  • Verify and install the policy.

The Implementation

The proper line for the SMTP Security Server in $FWDIR/conf/fwauthd.conf looks like this (with no comment character, #, at the beginning of the line):

25              fwssd            in.asmtpd       wait    0

On most systems, this line is enabled by default, but it never hurts to make sure that this line exists and is not commented out.

The two resources then need to be created. The first resource is for e-mail coming from the DMZ-based e-mail server that forwards it to the internal e-mail server. All incoming e-mail should be forwarded to the internal SMTP server. Any errors generated should go to the DMZ-based e-mail server so they can be sent to the sender. Figure 9.34 shows how this resource looks.

Figure 9.34. Incoming e-mail SMTP resource, General tab

graphics/09fig34.gif

You can leave the Match tab blank if you want because the internal and DMZ-based e-mail servers can do address checking on their own. For this example, let's leave the Action1 tab alone as well because there is no need to do any address rewriting.

In the Action2 tab, shown in Figure 9.35, strip out all messages of MIME type message/partial because it is used for sending a file across more than one message. This makes it difficult, if not impossible, to scan the file for viruses. The default message size should also be increased from 1,000KB to 5,000KB as a courtesy to users. However, I generally do not recommend sending large files by e-mail because e-mailed files are actually bigger than they are if downloaded from an FTP or HTTP server. In order to e-mail binary files, they must be turned into a nonbinary format, which increases the overall file size.

Figure 9.35. Incoming e-mail SMTP resource, Action2 tab

graphics/09fig35.gif

Configure the CVP tab as shown in Figure 9.36.

Figure 9.36. Incoming e-mail SMTP resource, CVP tab

graphics/09fig36.gif

Then create the outbound resource as shown in Figure 9.37.

Figure 9.37. Outgoing e-mail SMTP resource, General tab

graphics/09fig37.gif

It might also be nice to strip out the "received" lines of messages being sent from the inside to the outside. This is done on the Action1 tab (see Figure 9.38).

Figure 9.38. Outgoing e-mail SMTP resource, Action1 tab

graphics/09fig38.gif

The Action2 and CVP tabs should look identical to what was used for the inbound resource. In the end, the rulebase should look similar to the one shown in Figure 9.39.

Figure 9.39. Rulebase for SMTP Security Server sample configuration

graphics/09fig39.gif

Once this configuration is set up, verify and install the security policy.

FTP Content Security

The Situation

The next step in the company's Content Security plan is to turn on Content Security for FTP. Additionally, the company wants to use the FTP Security Server to allow people to upload files only to a specific directory on the Web server.

The Goal
  • Create and implement resources to perform the necessary Content Security for FTP.

The Checklist
  • Ensure that the FTP Security Server is enabled in $FWDIR/conf/fwauthd.conf.

  • Create an FTP resource to scan for viruses.

  • Create an FTP resource to scan for viruses and restrict access to a specific directory on the Web server.

  • Create an FTP resource to allow people to download files from the Web server.

  • Modify the rulebase to use these FTP resources.

  • Verify and install the policy.

The Implementation

The proper line for the FTP Security Server in $FWDIR/conf/fwauthd.conf looks like this (with no comment character, #, at the beginning of the line):

25              fwssd            in.aftpd       wait    0

On most systems, this line is enabled by default, but it never hurts to check.

The first resource you need to create is the more general one to match everything and allow users to upload and download as they please, with the exception that all file transfers will be scanned for viruses. This configuration is shown in Figure 9.40.

Figure 9.40. FTP scan resource, General tab

graphics/09fig40.gif

The Match tab should match all actions and paths as shown in Figure 9.41.

Figure 9.41. FTP scan resource, Match tab

graphics/09fig41.gif

The CVP tab, of course, should scan for viruses (see Figure 9.42).

Figure 9.42. FTP scan resource, CVP tab

graphics/09fig42.gif

The Web server upload resource needs to match a specific path. Use the Match tab as shown in Figure 9.43.

Figure 9.43. FTP Web server upload resource, Match tab

graphics/09fig43.gif

You are going to virus scan anything uploaded to make sure you do not pass any viruses to the outside world. The CVP tab for this configuration is shown in Figure 9.42.

Finally, you need to create a resource to allow the internal users to download from the Web server. Because you are not terribly concerned about where on that server users download from, the Match tab should match any path for GET commands, as shown in Figure 9.44.

Figure 9.44. FTP Web server download resource, Match tab

graphics/09fig44.gif

Once the resources are created, you can modify the existing policy to use them. The rulebase should look similar to the one shown in Figure 9.45. Rules 6, 7, and 8 were added to the previous rulebase (pushing the original Rules 6 through 9 shown in Figure 9.39 into their new positions as Rules 9 through 12 in Figure 9.45).

Figure 9.45. Rulebase with SMTP and FTP Security Server sample configuration

graphics/09fig45.gif

After updating the rulebase, verify and install the security policy.

HTTP Content Security

The Situation

The final step in implementing the company's Content Security plan is to implement both virus scanning and URL filtering for HTTP traffic.

The Goals
  • Create and implement a resource for URL filtering and Content Security for HTTP.

  • Make sure Content Security is not performed for internal users accessing the DMZ.

The Checklist
  • Ensure that the HTTP Security Server is enabled in $FWDIR/conf/fwauthd.conf.

  • Create a resource of type URI for URL filtering for HTTP.

  • Create a resource of type URI that matches all URLs and does virus scanning.

  • Modify the rulebase to use the HTTP resources.

  • Verify and install the policy.

The Implementation

The proper line for the HTTP Security Server in $FWDIR/conf/fwauthd.conf looks like this (with no comment character, #, at the beginning of the line):

25              fwssd            in.ahttpd       wait    0

On most systems, this line is enabled by default, but it never hurts to check.

You first need to create a resource to filter URLs, as shown in Figure 9.46.

Figure 9.46. URI-filtering resource, General tab

graphics/09fig46.gif

The Match tab should match the categories of Web sites you do not want the employees to view (see Figure 9.47).

Figure 9.47. URI-filtering resource, Match tab

graphics/09fig47.gif

Configure the settings on the Action tab (see Figure 9.48) to redirect rejected URLs to a policy page.

Figure 9.48. URI-filtering resource, Action tab

graphics/09fig48.gif

This completes the setup for the URL filtering resource. You then need to do virus scanning on any URL that is accepted. A second resource must be created, as shown in Figure 9.49.

Figure 9.49. HTTP virus-scanning resource, General tab

graphics/09fig49.gif

The Match tab settings should match all URLs, and the CVP tab settings should filter viruses (see Figures 9.50 and 9.51, respectively).

Figure 9.50. HTTP virus-scanning resource, Match tab

graphics/09fig50.gif

Figure 9.51. HTTP virus-scanning resource, CVP tab

graphics/09fig51.gif

You then implement these resources in the rulebase, as shown in Figure 9.52. Rule 9 in the previous rulebase was replaced by a different Rule 9, and a new rule was added in the Rule 10 position, shifting down the remaining rules.

Figure 9.52. Rulebase with SMTP, FTP, and HTTP Security Servers sample configuration

graphics/09fig52.gif

After making these changes, verify and install the policy.

Notes

Rule 1 also matches internal users' attempts to access the Web server on the DMZ.