In order to use the SMTP security server, you first need to enable it through the FireWall-1 Configuration utility. We discussed how to enable this server in the section on the FireWall-1 Configuration utility and even showed this feature enabled in Figure 7.5. Once the SMTP security server is enabled, you will need to define SMTP resources with the Security Policy-1 tab.
For the main menu of the Security Policy-1 tab, select Manage ¾ Resources. This will produce the Resource Management screen. If this is the first time you have run the Resource Manager, it will contain no entries. Click New and select SMTP. You should now be looking at the SMTP Definition box, as shown in Figure 7.15.
Figure 7.15: The SMTP Definition box General tab
Start by configuring the resource to handle inbound mail that has been sent to foobar.com. You could use a descriptive name, such as inbound_foobar, so that this definition would be easy to recognize once it has been added to the security policy. Within the mail server field, enter the IP address of the mail server to which you want to forward mail. (Use the IP address to expedite mail delivery: the firewall does not have to resolve the host name.) Within the Error Handling Server field, enter the IP address of the mail system to which you want to forward error messages. This can be the same IP address you defined in the Mail Server field.
Exception tracking defines whether you wish to log all e-mail messages that this resource processes. You also have the option of sending an alert. Finally, you have the option to select the Notify Sender On Error check box. If the resource matches an inbound mail message, but the security server is unable to deliver the message, checking this box means an error message will be returned to the original sender.
Figure 7.16: The Match tab of the SMTP Definition box
The configuration of the Match tab is pretty straightforward. Enter the text you wish this resource to match within either the Sender or the Recipient field. An asterisk (*) acts as a wildcard and will match any character string. Note that you have told the resource to match any sender, but the Recipient field within the e-mail message must end in @foobar.com. This will match all inbound mail for the foobar.com domain.
Since you are not looking to rewrite any of your e-mail headers, you are done configuring this particular resource. Simply click OK to save this entry.
You must now create entries for the domains you wish to alias. From the Resource Management screen, again click New and select SMTP. This will create a new SMTP Definition box, like the one shown in Figure 7.17. Select the General tab and give this resource a descriptive name (such as inbound-fubar.com). Since mail addressed to fubar.com will be delivered to the same mail system as foobar.com, enter the same Mail Server and Error Handling Server IP address that you used for the foobar.com entry.
Under the Match tab, you will again use an asterisk to pattern match the Sender field, but the Recipient field will contain the entry *@fubar.com. This will allow you to pattern-match inbound e-mail addresses sent to this alternative domain name. Since this is one of the domain names that you want to rewrite, you must modify the Action1 tab, shown in Figure 7.17.
Figure 7.17: The Action1 tab of the SMTP Definition box
The only fields you need to fill in on the Action1 tab are the fields you wish to have rewritten. Any field left blank will remain untouched. The fields on the left attempt to match text within the specified portion of the e-mail header. The fields on the right contain what this text should be changed to if a pattern match occurs.
The first Recipient field contains the character string *@fubar.com. This is the portion of the address that you want to rewrite. The right-hand Recipient field contains the character string &@foobar.com. The ampersand (&) tells the resource, "Copy the value of the asterisk in the previous field and paste it here." This allows you to maintain the same user name in your new recipient header. The remaining text simply tells the resource to replace fubar.com with foobar.com.
This completes the configuration of the SMTP resource for inbound fubar.com mail. You can click OK and return to the Resource Management screen. You also need to create an SMTP resource for bofh.com. Follow the same steps you took for the fubar.com resource, but replace the name and pattern match information with bofh.com. Once you have finished, you can close the Resource Management screen and return to the Security Policy-1 tab in order to incorporate these resources into your security policy.
Figure 7.18 shows your SMTP resources added to a very simple security policy. Row 1 blocks all traffic that you do not want passing the firewall in either direction. Row 2 defines a very loose security policy, which allows all internal systems to access any services located on the Internet (except for those explicitly dropped in row 1).
Figure 7.18: A security policy using SMTP resources
Row 3 is the entry which includes the SMTP resources. The rule states that any system can connect to Skylar (the firewall) and attempt to deliver SMTP messages. All SMTP messages will then be processed by the three SMTP resources you created. Each resource was added to this rule by right-clicking in row 3’s Service box and selecting Add With Resource ¾ SMTP, then selecting the name of the resource, which is shown in the Resource drop-down list.
Since your mail server has full Internet access per row 2, you do not need to configure an outbound SMTP resource. The mail system should be fully capable of delivering all outbound mail directly.
Tip A side benefit of the current rule base is that it prevents your mail systems from being used as spam relays. The firewall will only accept messages going to one of your three domains. The internal mail system cannot be reached directly from the Internet. This means that neither of your mail systems could be used by a spammer to relay advertisements to multiple recipients.
Installing the Rules
Once you have configured the firewall to reflect your security policy, you should save your settings. You should always do a File ¾ Save As from the Security Policy-1 tab menu in order to create a unique policy name. This will provide you with some revision control in case you later need to restore an older policy.
You now need to install this policy on the firewall in order to activate your changes. Select Policy ¾ Install from the Security Policy-1 tab menu. This will produce a dialog box that displays all the hosts where your firewall policy will be installed. At a minimum, you should see the object for your firewall. If you are managing multiple firewalls, or if you will be installing access control lists on specific routers, these devices should appear in this dialog box, as well. When you have verified the information, click OK to install your policy on the selected hosts. This will bring up the Install Security Policy dialog box shown in Figure 7.19. The information in this dialog box should report that a policy script was compiled without errors and that it was installed successfully to the firewall. If no errors occurred, click Close. Your firewall should be ready for use.
Figure 7.19: The Install Security Policy dialog box
If errors were reported, look at the error messages closely. Typically, errors are due to conflicts in the rules. For example, you may have created one rule stating that a particular system has full Internet access, only to later define that the same system is not allowed to use FTP.
When you install your rule base, the firewall first checks that there are no conflicts. If you wish to verify that there are no rule conflicts before you attempt to install your rules, you can select the Policy ¾ Verify option instead. In my experience, however, this check is not exhaustive. It is possible for a rule set to pass the Verify check, only to show problems during installation.
Summary
This completes our review of Check Point FireWall-1. In this chapter, you saw why FireWall-1 is one of the most popular firewalling products and became aware of a number of caveats. You also went through the installation and setup procedure on a Windows NT server. You should now have a good idea of how to deploy this product within your network environment.
In the next chapter, we will evaluate methods of controlling security within your network perimeters. We will look at intrusion detection systems that can be combined with a firewall solution to produce an extremely secure environment.
Chapter 8: Intrusion Detection Systems
Intrusion detection systems (IDS) (as a generic term) represent a fairly new technology that has been receiving a lot of recent press. While the technology is only three or four years old, it brings vendors’ promises of revolutionizing the network security market. In fact, one vendor has ventured to say that its IDS completely removes the need for a firewall. Clearly, someone in marketing must be writing this company’s technical documents, because IDS is a way to augment—not replace— your existing security mechanisms.