We have learned in the previous article the email filtering mechanisms, including spam filtering and email content control.
These two filtering functions are separately configured on the NGFW and then added to an email filtering profile.
Email Filtering Dependencies
Similar to previously described AV, IPS, and URL filtering features, email filtering also involves several functional modules working together, as shown in the following figure:
The major parts of email filtering are email filtering profile and security policy. An email filtering profile defines spam and email content filtering functions. A security policy references a URL filtering profile and defines the matching conditions (used to identify traffic subject to email filtering) and an action, which must be set to allow. Other modules are described as follows:
Email address set defines the email address matching methods and
strings for email address check.
Email filtering logs help administrators to check whether legitimate
emails are falsely treated as spam. You can view the email filtering logs,
obtain the IP addresses of the mail servers that are falsely blocked, and add
them to the whitelist.
Description of the Web Configuration Page
The following figures are snapshots of the web UIs for configuring email filtering profiles (the USG6000 V100R001C30SPC100 is used as an example). Each configuration item on the UI is subsequently described.
On the spam filtering web configuration UI, you can configure DNS servers, whitelist, blacklist, and RBL query (you can configure multiple RBL servers, but can enable only one at a time), as shown in the following figure.
The following figure shows the email filtering profile configuration web UI.
The email filtering profile configuration page is divided into five areas. In Area 1, you can configure the basic information of the profile. In Area 2, you can enable spam filtering to block spam based on the parameters configured on the web page. You can configure anonymous email check in Area 3, email address check in Area 4, and email attachment control in Area 5.
Email Filtering Configuration Examples
Now let's see some real-world examples.
Example 1: Checking the Sender's Address to Block Emails Sent to Enterprise Intranet from Malicious External Users
As shown in the following figure, a mail server is deployed on an enterprise intranet for enterprise users to receive and send emails. To prevent malicious emails from the internet, the enterprise administrator configures email filtering on the NGFW and blocks emails from specified email addresses through the email address check function.
The first step is to create an email address group, add the email address (attacker@qiangshu.com in this example) of the malicious user to the group, and set the matching method to exact match. The email address group can be referenced in an email filtering profile.
The next step is to configure an email filtering profile to check the sender email addresses of incoming emails. If the sender address of an email matches an email address in the email address group, the email will be blocked.
A configured or modified email filtering profile takes effect only after it is committed. Committing a profile takes time, so it is advised to configure all email filtering profiles before you click Commit.
The email filtering profile is then referenced in a security policy.
After the preceding configurations are complete, the emails sent from attacker@qiangshu.com to user1@huawei.com will be blocked by the NGFW, and email filtering logs will be generated. Emails from other uses, such as user1@qiangshu.com, can be sent to user1@huawei.com.
The configuration script for this example is as follows:
#
mail-address-group name email_address
pattern exact attacker@qiangshu.com
#
profile type mail-filter name email_filter_example1
send-mail sender group name email_address
#
security-policy
rule name policy_email_filter_example1
source-zone untrust
destination-zone dmz
destination-address 192.168.1.0 mask 255.255.255.0
profile mail-filter email_filter_example1
action permit
#
Example 2: Implementing Email Attachment Control to Prevent Enterprise Users from Sending Emails that Have Attachments
As shown in the following figure, a mail server is deployed on an enterprise intranet for enterprise users to receive and send emails. Attachments are not allowed in outgoing emails to protect intellectual property rights and prevent information leaks. The enterprise administrator configures email filtering on the NGFW to block outgoing emails that have attachments using the email attachment control function.
The first step is to configure an email filtering profile and set the maximum number of attachments to 0.
Then, the administrator must click Commit and reference the profile in the security policy.
After the preceding configurations are complete, the emails sent the users on the enterprise intranet will be blocked by the NGFW if the emails have attachments, and email filtering logs will be generated. Outgoing emails without attachments can be sent from the enterprise intranet.
The configuration script for this example is as follows:
#
profile type mail-filter name email_filter_example2
send-mail attachment max-amount 0 action block
#
security-policy
rule name policy_email_filter_example2
source-zone trust
destination-zone dmz
source-address 192.168.0.0 mask 255.255.255.0
profile mail-filter email_filter_example2
action permit
#
Example 3: Configuring Application Identification and URL Filtering to Prevent Enterprise Users from Sending Emails Using Web Email Services
An enterprise does not have its own mail server and uses a webmail service (mail.163.com in this example) to send and receive emails, as shown in the following figure. The employees of a department are allowed to use the webmail service to receive, but not send, emails to ensure information security.
The email filtering feature of the NGFW only supports SMTP, POP3, and IMAP and does not support HTTP (webmail services). Therefore, the administrator must configure application identification to identify webmail applications and URL filtering to block outgoing emails.
The administrator must determine the URL used for sending emails. To do so, the administrator captures the HTTP packets between an employee and the web server and reads the URI in the HTTP POST packet. The following screenshot displays the URI used by the employee for sending emails.
The following screenshot displays the URI used by the employee for receiving emails.
The URIs indicate that URLs for sending emails contain the field of action=deliver and those for receiving emails contain the field of action=read. Therefore, the action keyword indicates whether the action is send or receive.
To ensure filtering effectiveness, the l=compose field can also be used to filter out URLs containing the two fields to prevent employees from sending emails.
Then, the administrator must create a user-defined URL category, configures keyword matching, and add the following URL:
The administrator must then configure a URL filtering profile and set the action to Block for the user-defined category. After the configurations are complete, the administrator must click Commit and reference the profile in the security policy. During security policy configuration, the IP address range of the employees subject to webmail control must be specified and the applications must be set to Netease_Webmail and HTTP so that other employees can normally receive and send emails.
After the preceding configurations are complete, the employees of the specified department are allowed to use the webmail service to receive, but not send, emails.
The configuration script for this example is as follows:
#
url-filter category user-defined name webmail_163_send
add url *l=compose*
add url *action=deliver*
#
profile type url-filter name profile_url_filter_163_send
category user-defined name webmail_163_send action block
#
security-policy
rule name policy_email_filter_example3
source-zone trust
destination-zone untrust
source-address 192.168.0.0 mask 255.255.255.0
application app Netease_Webmail
application app HTTP
profile url-filter profile_url_filter_163_send
action permit
#
