Category Archives: Administration Guides

Email – File-type based filters

File-type based filters

File-type based email filters can be used to filter out emails which are undesired due to a file-type attachment that the network admin qualifies as non-compatible with their business environment. The admin can define the undesired filetypes within the email filter profile and can associate an action to be taken for each file-type (for example: block or log).

To configure file-type email filtering in the CLI:

config emailfilter profile edit “myEmailFileFilter” config file-filter config entries edit “compressedFiles” set action block set file-type “7z” “rar” “zip”

next

end

end

set spam-filtering enable

next end

To configure file-type email filtering in the GUI:

  1. Go to Security Profiles > Email Filter.
  2. Enable File Filter.
  3. Customize which files are scanned (Log/Scan Archived Contents) or click Create New to add a new entry.

Email – FortiGuard-based filters

FortiGuard-based filters

FortiGate consults FortiGuard servers to help identify the spammers IP address or emails, known phishing URLs, known spam URLs, known spam email checksums, etc. FortiGuard servers have maintained databases that contain black lists which are fed from Fortinet sensors and labs distributed all over the world.

To configure the FortiGuard filters in the CLI:

config emailfilter profile edit “myEmailFilterProfile” set spam-filtering enable

set options spamfsip spamfssubmit spamfschksum spamfsurl spamrbl spamhdrcheck spamfsphish next

end

To configure the FortiGuard filters in the GUI:

  1. Go to Security Profiles > Email Filter.
  2. In the FortiGuard Spam Filtering Spam Filtering section, you can enable or disable the following filters:
    • IP Address Check l URL Check
    • Detect Phising URLs in Email l Email Checksum Check
    • Spam Submission

Email – Local-based filters

Local-based filters

To configure the local-based AntiSpam filter in the CLI: config emailfilter bwl

FGT-300D-SPAM (bwl) # edit 1 new entry ‘1’ added

FGT-300D-SPAM (1) # set name myBWL

FGT-300D-SPAM (1) # config entries config entries

edit 1

set status enable set type ip set action spam set addr-type ipv4 set ip4-subnet 10.1.100.0 255.255.255.0

next

end

config emailfilter profile edit “myLocalEmailFilter” set spam-filtering enable set options spambwl spamhelodns spamraddrdns config smtp

set action tag

end set spam-bwl-table 1

next

end config firewall policy

edit 1 …..

set inspection-mode proxy set emailfilter-profile “myLocalEmailFilter”

next end

To configure the local-based AntiSpam filter in the GUI:

  1. Go to Security Profiles > Email Filter.
  2. Click Create or select an existing profile and click Edit.
  3. In the Firewall policy, create or edit a rule.
  4. Set the inspection-mode to Proxy-based.
  5. Enable the Email Filter option and select the profile previously created.
  6. Set SSL Inspection to a profile that has deep SSL inspection enabled.
    • Deep inspection is required if you intend to filter SMTP, POP3, IMAP, or any SSL/TLS encapsulated protocol.
    • Below is an example of a profile with deep SSL inspection enabled.

To configure bannedwords in the CLI:

config emailfilter bword edit 1 set name “banned” config entries

edit 1 set pattern “undesired_word”

next

end

next

end

config emailfilter profile edit “myBannedWordsProfile” config file-filter set status disable

end set spam-filtering enable set options bannedword set spam-bword-table 1

next

end

Email – Filtering types

Filtering types

Local-based:

  • BWL, black orwhite list: These lists can be made from emails or IP subnets to forbid OR allow them to sending/receiving emails.

When referring to the IP address or email listed under a black or white list, email refers to the “From:” address, and IP refers to the IP address of the source of the email. In an SMTP case, the IP refers to the client’s IP address, while in a POP3 and IMAP case, it refers to the server’s IP address.

  • Bannedwords: The admin can define a list of banned words. Emails that contain any of these banned words are considered as spam.
  • DNS check: With spamhelodns and spamraddrdns, the FortiGate performs a standard DNS check on the machine name used in the helo SMTP message, and/or the return-to field to determine if these names belong to a registered domain. The FortiGate does not check the FortiGuard service during these operations. FortiGuard-based:
  • FortiGuard based options: FortiGate consults FortiGuard servers to help identify the spammers IP address or emails, known phishing URLs, known spam URLs, known spam email checksums, etc. Protocol tuning:
  • Protocol tuning: In a profile, there are sections for SMTP, POP3, and IMAP. In each section, you can set an action to either discard, tag, or pass the log for that protocol. Webmail:
  • Webmail detector: The email filter can also be configured to detect and log emails sent via Gmail and MSNHotmail. Although these two interfaces do not use the standard email protocols (SMTP, POP3, or IMAP) and instead use HTTPS, the email filter can still be configured to detect the emails sent and passed through the

FortiGate. File-type:

  • File-type based filtering: This can include emails which are undesired due to a file-type attachment that the network admin qualifies as non-compatible with their business environment. The admin can define the undesired file-types within the email filter profile and can associate an action to be taken for each file-type (for example: block or log).

Email filtering

Email filtering

The FortiGate Email Filter can be configured to do AntiSpam and file-type based filtering. To enable email filtering, create a profile using either the CLI or GUI, then use this profile in the firewall policy.

To configure the email filter profile in the CLI:

config emailfilter profile edit “ProfileName” set options ?  
bannedword Content block.
spambwl Black/white list.
spamfsip Email IP address FortiGuard AntiSpam black list check.
spamfssubmit Add FortiGuard AntiSpam spam submission text.
spamfschksum Email checksum FortiGuard AntiSpam check.
spamfsurl Email content URL FortiGuard AntiSpam check.
spamhelodns Email helo/ehlo domain DNS check.
spamraddrdns Email return address DNS check.
spamrbl Email DNSBL & ORBL check.
spamhdrcheck Email mime header check.
spamfsphish Email content phishing URL FortiGuard AntiSpam check.

These options can be reorganized according to the source of the decision:

  • Local options: The FortiGate qualifies the email based on local conditions like BWL, bannedwords, or DNS checks (with the use of FortiGuard service).
bannedword Content block.
spambwl Black/white list.
spamhelodns Email helo/ehlo domain DNS check.
spamraddrdns Email return address DNS check.
spamhdrcheck Email mime header check.
  • FortiGuard-based options: The FortiGate qualifies the email based on score or verdict returned from the FortiGuard service.
spamfsip Email IP address FortiGuard AntiSpam black list check.
spamfssubmit Add FortiGuard AntiSpam spam submission text.
spamfschksum Email checksum FortiGuard AntiSpam check.
spamfsurl Email content URL FortiGuard AntiSpam check.
spamfsphish Email content phishing URL FortiGuard AntiSpam check.
  • Third-party options: The FortiGate qualifies the email based on information from a third-party source (like ORB list). spamrbl Email DNSBL & ORBL check.

Local and FortiGuard black/white lists can be enabled and combined in a single profile. When combined, the Local black/white list has a higher priority than the FortiGuard’s black list during a decision making process.

For example: If a client’s IP address is black listed in FortiGuard servers, but the admin wants to override this decision and allow the IP to pass through the filter, they can define the IP address or subnet in a BWL with the clear action. Because the information coming from the Local BWL has a higher priority than the FortiGuard service, the email will be considered clean.

Use FortiGate as a DNS server

Use FortiGate as a DNS server

You can configure and use FortiGate as a DNS server in your network. When you enable DNS Service on a specific interface, FortiGate will listen for DNS Service on that interface.

Depending on the configuration, DNS Service on FortiGate can work in three modes: Recursive, Non-Recursive, or Forward to System DNS (server). For details on how to configure DNS Service on FortiGate, see the FortiGate System Configuration Guide.

You can apply a DNS Filter profile to Recursive Mode and Forward to System DNS Mode. This is the same as FortiGate working as a transparent DNS Proxy for DNS relay traffic.

To configure DNS Service on FortiGate using GUI:

  1. Go to Network > DNS Servers.
  2. In the DNS Service on Interface, click Create New and select an Interface.

The Recursive and Non-Recursive Mode is available only after you configure the DNS database.

To configure DNS Service on FortiGate using CLI:

config system dns-server edit “port10”  <<<==== Enable DNS Serive on Interface set mode forward-only

set dnsfilter-profile “demo”  <<<==== apply DNS Filter Profile for the service

next

end

Sample configuration

In this example, FortiGate port 10 is enabled as a DNS Service with the DNS Filter profile “demo”. Suppose port 10 has an IP address 10.1.100.5 and DNS Filter profile “demo” is set to block category 52 (Information Technology), then from your internal network PC, use a command line tool such as dig or nslookup to do a DNS query. For example:

# dig @10.1.100.5 www.fortinet.com <<<====Specify FortiGate interface address as DNS Server

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52809 ;; Flags: qr rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:

;; www.fortinet.com.           IN     A

;; ANSWER SECTION:

www.fortinet.com.      60     IN    A     208.91.112.55  <<<==== DNS Filter profile will filter the relay DNS traffic based on profile configuration. It blocked with redirect portal IP

;; Received 50 B

;; Time 2019-04-08 14:36:34 PDT

;; From 10.1.100.5@53(UDP) in 13.6 ms

DNS translation

DNS translation

Using this feature, you can translate a DNS resolved IP address to another IP address you specify.

For example, website A has a public address 1.2.3.4. However, when your internal network users visit this website, you want them to connect to an internal host, say, 192.168.3.4. In this case, you can use DNS translation to translate the DNS resolved address 1.2.3.4 to 192.168.3.4. Reverse use of DNS translation is also applicable, for example, if you want public DNS query of your internal server to get a public IP address, then you can translate a DNS resolved private IP to a public IP address.

Sample configuration

This example configuration forces the DNS Filter profile to translate 93.184.216.34 (www.example.com) to 192.168.3.4. So when internal network users do DNS query for www.example.com, they do not get the original www.example.com IP of 93.184.216.34. It will be replaced with 192.168.3.4.

To configure DNS translation on GUI:

  1. Go to Security Profiles > DNS Filter and edit or create a DNS Filter profile.
  2. Enable DNS Translation and click Create New.
  3. Enter the Original Destination (the domain’s original IP address), the Translated Destination IP address, and the Network Mask (in most cases, it’s 255.255.255.255).

To configure DNS translation on CLI:

config dnsfilter profile edit “demo” set comment ” … config dns-translation  <<<==== edit 1 set src 93.184.216.34 set dst 192.168.3.4

set netmask 255.255.255.255

next

end set redirect-portal 0.0.0.0 set redirect-portal6 ::

set youtube-restrict strict

next

end

To check DNS translation using a command line tool before DNS translation:

# dig www.example.com

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 27030

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0

;; QUESTION SECTION:        
;; www.example.com.

;; ANSWER SECTION:

  IN  A  
www.example.com.

;; AUTHORITY SECTION:

 33946 IN  A 93.184.216.34
example.com.  18578 IN  NS  b.iana-servers.net.
example.com.  18578 IN  NS  a.iana-servers.net.

;; Received 97 B

;; Time 2019-04-08 10:47:26 PDT

;; From 172.16.95.16@53(UDP) in 0.5 ms

To check DNS translation using a command line tool after DNS translation:

# dig www.example.com

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 62060

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0

;; QUESTION SECTION:        
;; www.example.com.

;; ANSWER SECTION:

  IN  A  
www.example.com. into 192.168.3.4

;; AUTHORITY SECTION:

 32491 IN  A 192.168.3.4  <<<==== resolved IP translated
example.com.  17123 IN  NS  b.iana-servers.net.
example.com.  17123 IN  NS  a.iana-servers.net.

;; Received 97 B

;; Time 2019-04-08 11:11:41 PDT

;; From 172.16.95.16@53(UDP) in 0.5 ms

How DNS translation network mask work

The following is an example of DNS translation and result.

config dns-translation edit 1

set src 93.184.216.34

set dst 1.2.3.4

set netmask 255.255.224.0 next

end

# dig www.example.com

;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 6736

;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 0

;; QUESTION SECTION:        
;; www.example.com.

;; ANSWER SECTION:

  IN  A  
www.example.com.

;; AUTHORITY SECTION:

 29322 IN  A 1.2.24.34
example.com.  13954 IN  NS  a.iana-servers.net.
example.com.  13954 IN  NS  b.iana-servers.net.

;; Received 97 B

;; Time 2019-04-08 12:04:30 PDT

;; From 172.16.95.16@53(UDP) in 2.0 ms

  • AND src(Orginal IP) with negative netmask (93.184.216.34 & ~255.255.224.0)

01011101.10111000.11011000.00100010 93.184.216.34 <– ip

00000000.00000000.00011111.11111111 ~255.255.224.0 <– ~netmask

——————————————————– &

00000000.00000000.00011000.00100010 0.0.24.34 <- right bits

  • AND dst(Translated IP) with netmask

00000001.00000010.00000011.00000100 1.2.3.4 <- dst

11111111.11111111.11100000.00000000 255.255.224.0 <- netmask

——————————————————– & 00000001.00000010.00000000.00000000 1.2.0.0 <- left bits

  • Final step 2 bitwise-OR 3:

00000000.00000000.00011000.00100010 0.0.24.34

00000001.00000010.00000000.00000000 1.2.0.0

——————————————————– | 00000001.00000010.00011000.00100010 1.2.24.34

Local domain filter

Local domain filter

In addition to FortiGuard’s category-based domain filter, you can also can define your own local static domain filter to allow or block specific domains.

To configure DNS local domain filter on GUI:

  1. Go to Security Profiles > DNS Filter and edit or create a DNS Filter.
  2. In the Static Domain Filter section, enable Domain Filter.
  3. Click Create New to create your local domain filter entries.

To configure DNS local domain filter on CLI:

config dnsfilter domain-filter edit 1 set name “demo” set comment ” config entries edit 1 set domain “www.fortinet.com”

set type simple set action allow set status enable

next edit 2 set domain “*.example.com” set type wildcard set action block set status enable

next edit 3 set domain “google” set type regex set action monitor set status enable

next

end

next

end

To check the DNS local domain filter log in the GUI:

  1. Go to Log & Report > DNS Query to view the DNS query log.

Since the local domain list “google” action is Monitor, it’s blocked by FortiGuard category-based domain filter.

To check the DNS local domain filter log in the CLI:

7: date=2019-04-05 time=15:37:06 logid=”1501054803″ type=”utm” subtype=”dns” eventtype=”dnsresponse” level=”warning” vd=”vdom1″ eventtime=1554503826 policyid=1 sessionid=69132 srcipp=10.1.100.18 srcport=49832 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=4612 qname=”www.google.com” qtype=”A” qtypeval=1 qclass=”IN” ipaddr=”208.91.112.55″ msg=”Domain belongs to a denied category in policy” action=”redirect” cat=41 catdesc=”Search Engines and Portals”

8: date=2019-04-05 time=15:37:06 logid=”1500054000″ type=”utm” subtype=”dns” eventtype=”dnsquery” level=”information” vd=”vdom1″ eventtime=1554503826 policyid=1 sessionid=69132 srcipp=10.1.100.18 srcport=49832 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=4612 qname=”www.google.com” qtype=”A” qtypeval=1 qclass=”IN”

9: date=2019-04-05 time=15:36:59 logid=”1501054400″ type=”utm” subtype=”dns” eventtype=”dnsresponse” level=”warning” vd=”vdom1″ eventtime=1554503818 policyid=1 sessionid=69121 srcipp=10.1.100.18 srcport=40659 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=24730 qname=”www.example.com” qtype=”A” qtypeval=1 qclass=”IN” msg=”Domain was blocked because it is in the domain-filter list” action=”redirect” domainfilteridx=1 domainfilterlist=”demo”

10: date=2019-04-05 time=15:36:59 logid=”1500054000″ type=”utm” subtype=”dns” eventtype=”dnsquery” level=”information” vd=”vdom1″ eventtime=1554503818 policyid=1 sessionid=69121 srcipp=10.1.100.18 srcport=40659 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=24730 qname=”www.example.com” qtype=”A” qtypeval=1 qclass=”IN”

11: date=2019-04-05 time=15:36:51 logid=”1501054401″ type=”utm” subtype=”dns” eventtype=”dnsresponse” level=”information” vd=”vdom1″ eventtime=1554503810 policyid=1 sessionid=69118 srcipp=10.1.100.18 srcport=33461 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=53801 qname=”www.fortinet.com” qtype=”A” qtypeval=1 qclass=”IN” ipaddr=”13.56.55.78, 54.183.57.55″ msg=”Domain was allowed because it is in the domain-filter list” action=”pass” domainfilteridx=1 domainfilterlist=”demo”

12: date=2019-04-05 time=15:36:51 logid=”1500054000″ type=”utm” subtype=”dns” eventtype=”dnsquery” level=”information” vd=”vdom1″ eventtime=1554503810 policyid=1 sessionid=69118 srcipp=10.1.100.18 srcport=33461 srcintf=”port10″ srcintfrole=”undefined” dstip=172.16.95.16 dstport=53 dstintf=”port9″ dstintfrole=”undefined” proto=17 profile=”demo” xid=53801 qname=”www.fortinet.com” qtype=”A” qtypeval=1 qclass=”IN”

Sequence and priority

In DNS Filter, local domain filter has a higher priority than FortiGuard category-based domain filter.

A DNS query is scanned and matched with local domain filter first. If an entry matches and the local filter entry’s action is block, then that DNS query is blocked or redirected.

If local domain filter list has no match, then the FortiGuard category-based domain filter is used. If a DNS query domain name rating belongs to the block category, this query is blocked or redirected. If the FortiGuard category-based filter has no match, then the original resolved IP address is returned to the client DNS resolver.

The local domain filter action can be Block, Allow, or Monitor. If the local domain filter action is Allow and an entry matches, it will skip the FortiGuard category-based domain filter and directly return to client DNS resolver. If the local domain filter action is Monitor and an entry matches, it will go to FortiGuard category-based domain filter scanning and matching.