The following subsections present three situations that build on each other as the network and the needs of the enterprise change.
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.
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.
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 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.
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.
Configure the CVP tab as shown in Figure 9.36.
Then create the outbound resource as shown in Figure 9.37.
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).
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.
Once this configuration is set up, verify and install the security policy.
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.
Create and implement resources to perform the necessary Content Security for FTP.
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 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.
The Match tab should match all actions and paths as shown in Figure 9.41.
The CVP tab, of course, should scan for viruses (see Figure 9.42).
The Web server upload resource needs to match a specific path. Use the Match tab as shown in Figure 9.43.
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.
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).
After updating the rulebase, verify and install the security policy.
The final step in implementing the company's Content Security plan is to implement both virus scanning and URL filtering for HTTP traffic.
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.
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 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.
The Match tab should match the categories of Web sites you do not want the employees to view (see Figure 9.47).
Configure the settings on the Action tab (see Figure 9.48) to redirect rejected URLs to a policy page.
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.
The Match tab settings should match all URLs, and the CVP tab settings should filter viruses (see Figures 9.50 and 9.51, respectively).
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.
After making these changes, verify and install the policy.
Rule 1 also matches internal users' attempts to access the Web server on the DMZ.