The SMTP Security Server

The SMTP Security Server is used to prevent certain types of mail from passing your gateway. The SMTP Security Server is enabled when the following situations are true.

• There is a line that permits in.asmtpd to start up in $FWDIR/conf/fwauthd.conf. This line is present by default.

• A valid resource is defined and used in your security 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

If this line is not present or is commented out, the SMTP Security Server will not run, and any process that relies on it will fail.

The SMTP Security Server acts a bit differently than the other Security Servers. There are actually two separate processes involved: in.asmtpd and mdq. in.asmtpd intercepts SMTP connections and spools the messages to disk. That is all they do. The mdq process periodically scans the spool directory and delivers the messages to their final destinations, performing the necessary filtering, header rewriting, and content rewriting. This is more secure than attempting to do everything in one process. Figure 9.22 shows a diagram of this.

SMTP Security Server Parameters

Aside from using resources, the SMTP Security Server has parameters that are configured in $FWDIR/conf/objects_5_0.C. Descriptions of these parameters and their default settings follow, using their names as shown in objects_5_0.C. A few of these parameters can be modified via the gateway object definition in the SMTP frame (under the Advanced frame; see Figure 9.23).

The items you can modify in objects_5_0.C include those listed below.

timeout: This is the amount of time (in seconds) FireWall-1 will spend on CVP scanning a message and delivering it to the Mail Transfer Agent (MTA). It is recommended that this value be at least 90 seconds (the default setting), if not longer. If you change this parameter, it is recommended that you reboot in order for it to take effect. (Corresponds to "Connection timeout" in Figure 9.23.)

scan_period: This is the amount of time (in seconds) that mdq will check the spool directory for e-mail to be delivered. By default, mdq checks for mail every 2 seconds. Mail found during this scan is delivered. mdq will take a number of e-mails based on the max_conns and max_conns_per_site parameters. Once max_load is reached, mdq stops taking mail messages from the spool directory. (Corresponds to "Dequeuer scan period" in Figure 9.23.)

resend_period: This is the amount of time (in seconds) that a message that previously failed to be delivered will be resent from the SMTP Security Server. The default is 600 seconds (10 minutes). (Corresponds to "Mail resend period" in Figure 9.23.)

abandon_time: This is the amount of time (in seconds) that a message is allowed to live in the spool directory before FireWall-1 returns the message to the sender. The default is 432,000 seconds (5 days). The error server defined in the specific resource matched by the rule the message was accepted under is used to deliver the message. (Corresponds to "Mail abandon time" in Figure 9.23.)

rundir: This is the location where FireWall-1 spools incoming e-mail. The default is $FWDIR/spool. If you expect to process lots of e-mail, make sure this is on a partition with lots of disk space. Specify a path to the new spool directory (this must exist). (Corresponds to "Spool Directory" in Figure 9.23.)

spool_limit: This allows you to specify the maximum number of messages allowed in the spool directory. Incoming messages that exceed this limit will be rejected. (Corresponds to "Maximum number of mail messages in spool" in Figure 9.23.)

spool_limit_scan_period: This specifies how frequently to check to see that the spool_limit has been reached. (Corresponds to "Check if spool goes over/under the limit every" in Figure 9.23.)

detailed_smtp_err_mail: If this parameter is set to a value other than 0 (the default), an error mail will be generated when the SMTP Security Server cannot deliver the e-mail to some of the recipients. The error mail includes information regarding which users could not receive the original mail and a reason for each recipient. This mail message is sent only when the "Notify sender on error" flag (see the SMTP Resources subsection) is enabled in the resource that matches the incoming message. (As of NG FP3, can be tweaked only via dbedit.)

detailed_av_err_mail: When this parameter is set to a value other than 0 (the default) and a mail fails a Content Security check, the generated error mail will include a notification of the failure as well as the explanation message received from the Content Security Server. Note that in case of a malicious attempt to insert a virus into an organization, it may be preferable not to use this flag because it allows the generator of the mail containing the virus to receive feedback on the malicious attempt. This error mail is sent only when the "Notify sender on error" flag is enabled in the resource that matches the incoming message. (As of NG FP3, can be tweaked only via dbedit.)

detailed_rb_err_mail: When this parameter is set to a value other than 0 (the default) and mail message would not be allowed by the rulebase, the sender is notified. (As of NG FP3, can be tweaked only via dbedit.)

max_conns: This is the maximum number of connections that the SMTP Security Server will generate to SMTP servers to deliver e-mail. (Corresponds to "Maximum generated concurrent connections" in Figure 9.23.)

max_conns_per_site: This is the maximum number of connections that the SMTP Security Server will generate to a single SMTP server to deliver e-mail. (Corresponds to "Maximum generated concurrent connections per site" in Figure 9.23.)

max_mail_size: This is the maximum number of kilobytes that the SMTP Security Server will allow a message to be. (Corresponds to "Don't accept mail larger than" in Figure 9.23.)

max_mails_per_conn: This is the maximum number of e-mails the SMTP Security Server will attempt to send on a single connection to a remote SMTP server. (As of NG FP3, can be tweaked only via dbedit.)

max_mx_node_per_mail: A domain can have multiple MX records associated with it. This property tells the SMTP Security Server how many MX records to attempt to use to deliver a message. (As of NG FP3, can be tweaked only via dbedit.)

max_ips_per_mx_node: An MX record for a domain may have more than one IP associated with it. For each MX record processed by the SMTP Security Server, this is the maximum number of IP addresses it will attempt to use per MX record. (As of NG FP3, can be tweaked only via dbedit.)

maxrecipients: This is the maximum number of recipients an e-mail message can contain. The SMTP Security Server will reject messages that contain more recipients than specified in this parameter. (Corresponds to "Maximum number of recipients" in Figure 9.23.)

postmaster: This specifies the e-mail address of the postmaster. This e-mail address is sent copes of any messages returned for nondelivery. (Corresponds to "Postmaster Name" in Figure 9.23.)

WARNING!

In FireWall-1 4.1, these parameters were changed by editing $FWDIR/conf/smtp.conf on the firewall module. On an NG module, this file will be overwritten on a policy installation. It is not recommended that you edit smtp.conf any longer.

To modify any of these parameters, you can either edit $FWDIR/conf/objects_5_0.C manually on the management console, use dbedit, or use Database Tool. To edit the properties in dbedit, use the following commands:

dbedit> modify network_objects craig
               firewall_settings:smtp:detailed_smtp_err_email
               true
dbedit> update network_objects craig

In the preceding example, craig is the relevant firewall object, detailed_smtp_err_mail is the property, and true is the value it was set to.

SMTP Resources

To filter SMTP, you need to create a resource of type SMTP. From SmartDashboard/Policy Editor, select Manage and choose Resources. Next select New, and then choose SMTP. You may also click on the icon in the objects tree, right-click on SMTP, and select New SMTP. You are presented with the window shown in Figure 9.24.

The options on this tab are described below.

Name: Enter the name of the SMTP resource object (must be unique).

Comment: In this field, you can describe the resource in more detail.

Color: Select whichever color you like.

Mail Delivery Server: If the server in this field is specified and this resource is matched, the e-mail will be forwarded to this server. If nothing is specified, the e-mail will be forwarded to the server the message was originally being sent to. To specify multiple mail servers to attempt, use the form { mailserver1,mailserver2,...}.

Error Mail Delivery Server: If the SMTP Security Server is not able to deliver the message within the abandon time and "Notify sender on error" is selected, the message will be sent through this e-mail server. If nothing is specified, the e-mail will be forwarded to the server the message was originally being sent to. To specify multiple mail servers to attempt, use the form { mailserver1,mailserver2,...}.

Notify sender on error: This setting indicates whether or not to notify the originator of the message when a delivery problem occurs. If this option is enabled, "bounce" messages will be generated if an e-mail is not successfully delivered. The level of detail of these error reports depends on objects_5_0.C modifications discussed in the previous subsection.

Deliver messages using DNS/MX records: This option exists for both the Mail Delivery Server and the Error Mail Delivery Server. If this option is enabled under the Mail Delivery section, Check Point will attempt to look up the MX record for the destination address and deliver to the IP(s) specified there. If this option is enabled under the Error Mail Delivery section, error messages will be sent to the originating e-mail via the domain's MX record. The operating system of the firewall must be configured with DNS enabled. This option should be used for e-mail being delivered to the Internet. For e-mail coming in from the Internet, this option may not be necessary.

Check Rule Base with new destination: This option is also available under both Delivery sections. Normally, any e-mail initially accepted by the SMTP Security Server will be delivered by the firewall without being matched against the rulebase. You can force this delivery connection to go through the rulebase for either normal or error delivery by checking the appropriate box.

Exception Tracking: If the resource finds anomalous behavior, you can either log that information, generate an alert, or do nothing.

The Match tab is shown in Figure 9.25. The Sender and Recipient fields can be matched with any of the wildcards listed earlier in the chapter.

The Action1 tab, shown in Figure 9.26, allows you to rewrite the e-mail headers. The left part of each line is what is matched (the original); the right part is its replacement (what you are changing it to). On the original side, you can use normal wildcards. If you want to make what you matched part of what you translate it to, use the & wildcard to signify that. For example, if you want to rewrite all addresses of the form user@smtp.weirdal.com to user@weirdal.com, on the left side you would specify *@smtp.weirdal.com, and on the right, you would specify &@weirdal.com.

You can do this for a custom field as well. If you want to eliminate a field (say, the Received: lines), on the left enter *, and leave the right side blank.

Figure 9.27 shows the Action2 tab. If you do not want to allow certain MIME types or files with certain extensions, you can specify them on the Action2 tab. You can specify multiple MIME types or files using the normal wildcards (see Table 9.1 earlier in the chapter). Filtering on MIME types or file extensions is an inexact science at best because the e-mail client can use any MIME type it wants, and different e-mail clients use different MIME types for the same type of document. For instance, application/msword can be used for Microsoft Word documents. UNIX machines often send these kinds of documents as application/octet-stream, which can also be used for applications or any binary file. On the Action 2 tab you can also restrict message size and strip out undesirable HTML tags from e-mails.

Some examples of how to use the SMTP Security Server are described in the next subsection.

Frequently Asked Questions about the SMTP Security Server

The following FAQs are provided for events that may occur with the SMTP Security Server.

9.21 When I Use the SMTP Security Server, to What Should the MX for My Domain Point?

Your MX records should point to your normal SMTP server. Provided your rules are set up correctly, FireWall-1 will intercept this traffic automatically. You do not have to change anything with respect to your MX records for your domain.

9.22 Can I Have the Firewall Be the MX for My Domain?

Usually, the SMTP Security Server intercepts communications destined for an internal SMTP server. In some cases you may want to have the firewall be the mail exchanger. You can do this with the proper SMTP resource, making sure the following fields are defined.

• Mail Delivery Server (on the General tab): Enter the IP address of your inbound server in this field. If you have more than one SMTP server, enter each in the format { ip-address-1,ip-address-2,...} . If your DNS is correctly defined, you can use the DNS/MX records option instead.

• Error Mail Delivery Server (on the General tab): Select this option if you want to notify the sender that his or her message has been rejected or in case of some other problem. If your DNS is correctly defined, you can use the DNS/MX records option instead.

• Don't accept mail larger than (on the SMTP frame): This option should be set appropriately. The default is 1,000KB (or roughly 1MB).

Once you have defined the resource, add a rule similar to the one shown in Figure 9.28, and reinstall the security policy.

Note that your SMTP Server should be responsible for delivering outbound messages. See the next question for more details.

9.23 Why Won't the SMTP Security Server Use the MX Records?

You might think this FAQ was meant for the previous version of my book, where I covered FireWall-1 4.1 and earlier. It's true that the SMTP Security Server did not use MX records and thus was unsuitable for use in delivering outbound e-mail. Sadly, even if the MX record option is enabled, it may not work correctly for all domains. Check Point released hotfixes for this issue in NG FP2 and possibly other releases.

A workaround, and what I consider to be "best practice," is to use a "smart" SMTP server?that is, a conventional SMTP server that knows how to properly handle MX records. This SMTP server should probably be in your DMZ. You have to make sure that any SMTP traffic from this host destined to the Internet does not get processed by any SMTP resources. To ensure that this does not happen and to have the most secure setup, use the rules shown in Figure 9.29.

The first rule matches all SMTP traffic from the Internet to the smart SMTP server (which is the MX for your domain). The second rule forces all SMTP traffic from the smart SMTP server to the internal network through the SMTP Security Server using the smtp_inbound_from_dmz resource. This resource should have the mail server configured to point to the internal SMTP server(s) and perform any necessary checking. The third rule allows the smart SMTP server to communicate to any SMTP server without going through the SMTP Security Server. The fourth rule forces your internal SMTP server to communicate through the SMTP Security Server. This last rule is optional, but you should use it if you want to perform virus scanning on any outbound e-mail.

9.24 Can I Use the SMTP Security Server to Help Fight Incoming Spam?

Spam is a notoriously difficult nuisance to filter properly. Many individuals and companies have written various programs to attempt to filter spam. Although not specifically designed to handle this task, FireWall-1 does have some features that can be used to help, namely, the SMTP Security Server.

Your inbound SMTP server is likely to be a better tool to stop spam. Most SMTP servers (with the notable exception of Microsoft Exchange 5.0 and earlier) have the capability to turn off unauthorized relaying and/or implement some checks to prevent unauthorized use. You can even subscribe to the Mail Abuse Prevention System (MAPS) or a similar system that maintains a blacklist of known bad sites.

If you are going to use the SMTP Security Server to filter spam, your SMTP resources should have the recipient and the sender defined. The recipient should be *@yourdomain.com. If you have multiple domains, it should read *@{ yourdomain.com,yourotherdomain.com,...} . The send should be configured with a * to match all incoming mail.

9.25 Can the SMTP Security Server Accept E-mails of Any Size?

You should be able to type a number into the appropriate field. Keep in mind that you need to have sufficient disk space on your firewalls to accept these e-mails.

Personally, if a user wants to e-mail a large file, I feel he or she should use FTP or something similar. All e-mailed files are encoded in a 6-bit format for transmission over SMTP, which expands the file size by at least 33%.

9.26 When Does CVP Get Performed on E-mails in the SMTP Security Server?

This action is actually done as the SMTP message is being delivered to the remote SMTP server. This means the timeout value specified in the SMTP configuration on the gateway object is long enough for both tasks to occur.

Troubleshooting the SMTP Security Server

The following solutions are provided for problems that occur with the SMTP Security Server.

9.27 I See the Message "Connection to Final MTA Failed" in the SmartView Tracker/Log Viewer

This message shows up when the SMTP Security Server is unable to connect to the remote MTA (i.e., the SMTP server) to deliver that message. This may simply be a transient problem, or the remote SMTP server may simply no longer exist. The next subsection shows you how to resolve that problem.

9.28 Mail Appears to Get Stuck in the SMTP Security Server Spool Directory

Make sure your rules are ordered in such a way as to not use the SMTP Security Server when not necessary. The following subsections contain some other events that will cause messages to back up.

Maximum Concurrent Sent Mails Limit Reached

You might see the following message in the mdq.elg file. It means that the number of recipients specified in the mail header has exceeded the limit.

[195@firewall] max concurrent sent mails limit reached ?
 spool scanning stops

The number of messages that can be sent at one time is specified with the max_conns and max_conns_per_site parameters, described in the SMTP Security Server Parameters subsection earlier in this chapter.

Messages Continue to Fail on Delivery Attempts

If sending an e-mail continues to fail (or takes a long time), the whole spool will be held up until the troubled e-mail times out. Decreasing the abandon_time parameter from its default of 432,000 seconds (5 days) to 3,600 seconds (1 hour) clears out the spool more quickly, returning error messages to the sender stating that the e-mail could not be delivered. (See the SMTP Security Server Parameters subsection earlier in the chapter.)

Forcing the Queue to Empty Out

You can force a queue run by using the command fw mdq. However, the only way to fix this (short of letting FireWall-1 attempt to deliver these messages until they expire) is to edit each individual file in $FWDIR/spool (or whatever rundir is set to), so that the destination it tries to contact is an SMTP server that will deliver the message. There are actually three directories under $FWDIR/spool, which contain the individual files.

• D_resend: This directory contains all the messages that the SMTP Security Server had problems delivering in the initial attempt. The SMTP Security Server attempts to resend messages from this directory until the message has been around longer than the abandon_time. Files in this directory are of the form Rxxxxxxxx (for messages not yet expired) or Exxxxxxxx (for messages that have expired).

• D_state: This directory contains all the messages currently being received by the SMTP Security Server, that is, partial e-mails. Once the messages are received fully, they are copied into the D_sender directory.

• D_sender: This directory contains messages that the SMTP Security Server has fully received and is about to send for the first time. If a message is not successfully sent, it is copied over to the D_resend directory.

In all cases, the beginning of a spool file looks like this:

AV_SETTING:     none
AV_IPADDR:      0.0.0.0
AV_PORT:        0
AV_HEADERS:     0
COMPOUND:       0
SRC:    192.168.230.24
SPORT:  3446
DST:    10.158.5.2
DPORT:  25
ERR_SERVER:     10.158.5.2
RULE:   11
RULEACT:        16
ERRMAIL:        0
ACCT:   0
LOG_OK:          MDQ_LOG
LOG_BAD:         MDQ_LOG
LOG_ERR:         MDQ_ALERT

The headers are described as follows.

AV_SETTING (none|check|cure): A header that indicates whether or not this message will be checked for viruses. none means do not scan, check means do not send if it contains a known virus, and cure means clean out any known viruses in the message before sending.

AV_IPADDR (a.b.c.d): The IP address of the antivirus scanner. This should list 0.0.0.0 if no virus checking is to be done.

AV_PORT (n): The port used for CVP, normally 18181 or 0.

AV_HEADERS (0|1): A header that indicates whether or not the CVP server is to be sent the SMTP headers. If so, then this is set to 1, otherwise 0.

COMPOUND (?): Unknown, but usually set to 0.

SRC (a.b.c.d): The source IP address of the machine that sent the e-mail.

SPORT (n): The source port used for the connection to the SMTP Security Server from the source IP address listed.

DST (a.b.c.d): The destination IP address of the machine to send the e-mail to. This is the IP address of the mail server that the source IP was originally trying to send to unless the matching resource or the default_server parameter is set to some other value, in which case, this value reflects that instead. This is the IP address that FireWall-1 will use to deliver this message.

DPORT (n): The destination port that will be used to send the mail to. Normally this is 25.

ERR_SERVER (a.b.c.d): The SMTP server that will be used to attempt to deliver the failure notice if a message has been in $FWDIR/spool beyond the abandon_time. If no error_server is defined in the appropriate resource, this will be the same as the SRC setting.

RULE (n): The rule number by which this message was originally accepted. When the message is actually delivered, this is the rule number that will be logged.

RULEACT (?): Unknown. The value of this is usually 16.

ERRMAIL (0|1): A header that determines whether an actual error e-mail is sent out if the mail errors out. This corresponds to the "Notify sender on error" checkbox in the appropriate resource. The value of this header is 1 if it will attempt to deliver an error, 0 if not.

ACCT (0|1): A header that indicates whether to perform accounting tracking on this connection (value of 1) or not (value of 0).

LOG_OK (MDQ_LOG|MDQ_ALERT): A header that specifies how to log the successful delivery of a message.

LOG_BAD (MDQ_LOG|MDQ_ALERT): A header that specifies how to log an unsuccessful delivery attempt (e.g., a transient failure). This corresponds to Exception Tracking on the appropriate resource (see Figure 9.23 earlier in the chapter). This line will not exist in the file if Exception Tracking is set to None.

LOG_ERR (MDQ_LOG|MDQ_ALERT): A header that specifies how to log that an error mail needs to be sent (because the message has passed the abandon time). This corresponds to the "Notify sender on error" checkbox in the appropriate resource.

Below these entries in the spool file, you will find two sets of e-mail headers: the original headers (as they were sent with the message) and the modified headers, which are what FireWall-1 will actually send to the remote SMTP server.

You can move the R file with the lowest numerical value of the spool directory, enabling the mdq process to work with the next file. The idea is that you can either modify or relocate the problem files, enabling the forwarding of the rest of the spool directory.

Once you have done this to all the files, you can type either

# fw mdq

or

# fw kill fwd

to force the SMTP Security Server to reprocess the mail spool.

WARNING!

fw kill fwd kills the fwd process, which will prevent FireWall-1 from logging, using the Security Servers, or performing encryption tasks. The cpwatchdog process should restart fwd within a minute or so of executing this command.