Category Archives: FortiOS 5.4 Handbook

The complete handbook for FortiOS 5.4

Data leak prevention

Leave a reply

Data leak prevention

The FortiGate data leak prevention (DLP) system allows you to prevent sensitive data from leaving your network. When you define sensitive data patterns, data matching these patterns will be blocked, or logged and allowed, when passing through the FortiGate unit. You configure the DLP system by creating individual filters based on file type, file size, a regular expression, an advanced rule, or a compound rule, in a DLP sensor and assign the sensor to a security policy.

Although the primary use of the DLP feature is to stop sensitive data from leaving your network, it can also be used to prevent unwanted data from entering your network and to archive some or all of the content passing through the FortiGate unit.

 

This section describes how to configure the DLP settings. The following topics are included:

  • Data leak prevention concepts
  • Enable data leak prevention
  • Fingerprint
  • File filter
  • DLP archiving
  • DLP examples

Log Only is enabled by default.

Anti-Spam examples

Leave a reply

Anti–Spam examples

 

Configuring simple Anti-Spam protection

Small offices, whether they are small companies, home offices, or satellite offices, often have very simple needs. This example details how to enable Anti-Spam protection on a FortiGate unit located in a satellite office.

 

Creating an email filter profile

Most Anti-Spam settings are configured in an Anti-Spam profile. Anti-Spam profiles are selected in firewall policies. This way, you can create multiple Anti-Spam profiles, and tailor them to the traffic controlled by the security policy in which they are selected. In this example, you will create one Anti-Spam profile.

 

To create an Anti-Spam profile — web-based manager

1. Go to Security Profiles > Anti-Spam.

2. Select the Create New icon in the Edit Anti-Spam Profile window title.

3. In the Name field, enter basic_anti-spam

4. Select Enable Spam Detection and Filtering.

5. Ensure that IMAP, POP3, and SMTP are selected in the header row.

These header row selections enable or disable examination of each Anti-Spam type. When disabled, the email traffic of that type is ignored by the FortiGate unit and no Anti-Spam options are available.

6. Under FortiGuard Spam Filtering, enable IP Address Check.

7. Under FortiGuard Spam Filtering, enable URL Check.

8. Under FortiGuard Spam Filtering, enable E–mail Checksum Check.

9. Select OK to save the email filter profile.

 

To create an Anti-Spam profile — CLI

config spamfilter profile edit basic_anti-spam

set options spamfsip spamfsurl spamfschksum end

 

Selecting the Anti-Spam profile in a security policy

An Anti-Spam profile directs the FortiGate unit to scan network traffic only when it is selected in a security policy. When an Anti-Spam profile is selected in a security policy, its settings are applied to all the traffic the security policy handles.

 

To select the Anti-Spam profile in a security policy — web-based manager

1. Go to Policy & Objects > IPv4 Policy.

2. Create a new or edit a policy.

3. Turn on Anti-Spam.

4. Select the basic_anti-spam profile from the list.

5. Select OK to save the security policy.

 

To select the Anti-Spam profile in a security policy — CLI

config firewall policy edit 1

set utm-status enable

set profile-protocol-options default set spamfilter-profile basic_anti-spam

end

IMAP, POP3, and SMTP email traffic handled by the security policy you modified will be scanned for spam. Spam messages have the text “Spam” added to their subject lines. A small office may have only one security policy configured. If you have multiple policies, consider enabling spam scanning for all of them.

 

Blocking email from a user

Employees of the Example.com corporation have been receiving unwanted email messages from a former client at a company called example.net. The client’s email address is client@example.net. All ties between the company and the client have been severed, but the messages continue. The FortiGate unit can be configured to prevent these messages from being delivered.

 

To enable Anti-Spam

1. Go to Security Profiles > Anti-Spam.

2. Select the Anti-Spam profile that is used by the firewall policies handling email traffic from the Anti-Spam profile drop down list.

3. In the row Tag Location, select Subject for all three mail protocols.

4. In the row Tag Format, enter SPAM: in all three fields.

This means that normal spam will be tagged in the subject line.

5. Select Enable Spam Detection and Filtering.

6. Under Local Spam Filtering, enable Black White List and select Create New.

7. In the Black White List widget, select Create New.

8. Select Email Address Wildcard.

9. Enter client@example.net in the Pattern field.

 

  • If you wanted to prevent everyone’s email from the client’s company from getting through you could have used *@example.net instead.

10. Set the Action as Mark as Reject.

11. Set the Status to Enable.

12. Select OK.

Now that the email address list is created, you must enable the email filter in the Anti-Spam profile.

When this Anti-Spam profile is selected in a security policy, the FortiGate unit will reject any email message from an address ending with @example.net for all email traffic handled by the security policy.

Anti-Spam filter

1 Reply

Anti-Spam filter

This section describes how to configure FortiGate email filtering for IMAP, POP3, and SMTP email. Email filtering includes both spam filtering and filtering for any words or files you want to disallow in email messages. If your FortiGate unit supports SSL content scanning and inspection, you can also configure spam filtering for IMAPS, POP3S, and SMTPS email traffic.

 

The following topics are included in this section:

  • Anti-Spam concepts
  • Enable Anti-Spam
  • Configure email traffic types to inspect
  • Configure the spam action
  • Configure the tag location
  • Configure the tag format
  • Configuring Anti-Spam
  • Configure local email filters
  • Anti-Spam examples

 

Anti–Spam concepts

You can configure the FortiGate unit to manage unsolicited commercial email by detecting and identifying spam messages from known or suspected spam servers.

The FortiGuard Anti-Spam Service uses both a sender IP reputation database and a spam signature database, along with sophisticated spam filtering tools, to detect and block a wide range of spam messages. Using FortiGuard Anti-Spam profile settings, you can enable IP address checking, URL checking, email checksum checking, and spam submission. Updates to the IP reputation and spam signature databases are provided continuously via the global FortiGuard Distribution Network.

From the FortiGuard Anti-Spam Service page in the FortiGuard Center, you can find out whether an IP address is blacklisted in the FortiGuard Anti-Spam IP reputation database, or whether a URL or email address is in the signature database.

 

Anti–Spam techniques

The FortiGate unit has a number of techniques available to help detect spam. Some use the FortiGuard Anti- Spam Service and require a subscription. The remainder use your DNS servers or use lists that you must maintain.

 

Black white list

These are the types of black white lists available. They include:

  • IP/Netmask

The FortiGate unit compares the IP address of the client delivering the email to the addresses in the IP address black/white list specified in the email filter profile. If a match is found, the FortiGate unit will take the action configured for the matching black/white list entry against all delivered email.

The default setting of the smtp-spamhdrip CLI command is disable. If enabled, the FortiGate unit will check all the IP addresses in the header of SMTP email against the specified IP address black/white list.

  • Email Wildcard

The FortiGate unit compares the sender email address, as shown in the message envelope MAIL FROM, to the pattern in the patterned field. The wildcard symbol is used in the patterned to replace the characters in the address that may vary from the pattern. If a match is found, the FortiGate unit will take the action configured for the matching black/white list entry.

  • Email Regular Expression

The FortiGate unit compares the sender email address, as shown in the message envelope MAIL FROM, to the pattern in the patterned field. The regular expression that can be used is much more sophisticated than a simple wildcard variable. If a match is found, the FortiGate unit will take the action configured for the matching black/white list entry.

 

Pattern

The pattern field is for entering the identifying information that will enable the filter to correctly identify the email messages.

  • If the type is IP/Netmask the filter will be an IP address with a subnet mask.
  • If the type is Email Wildcard the filter will be an email address with a wildcard symbol in place of the variable characters. For example *.example.com or fred@*.com.
  • If the type is Email Regular Expression, regular expression can be used to create a more granular filter for email addresses. For example, ^[_a-z0-9-]+(\.[_a-z0-9-]+)*@(example|xmple|examp).(com|org|net) could be used filter based on a number of combinations of email domain names.

 

Action

  • Mark as Spam

If this is the selected action, the email will be allowed through but it will be tagged with an indicator that clearly marks the email as spam.

  • Mark as Clear

If this is the selected action, the email will be allowed to go through to its destination on the assumption that the message is not spam.

  • Mark as Reject

If this is the selected action, the email will be dropped at the before reaching its destination.

 

Status

Indicates whether this particular list is enabled or disabled.

 

Banned word check

When you enable banned word checking, your FortiGate unit will examine the email message for words appearing in the banned word list specified in the Anti-Spam profile. If the total score of the banned word discovered in the email message exceeds the threshold value set in the Anti-Spam profile, your FortiGate unit will treat the message as spam.

When determining the banned word score total for an email message, each banned word score is added once no matter how many times the word appears in the message. Use the command config spamfilter bword to add an email banned word list. Use the command config spamfilter profile to add a banned word list to an Anti-Spam profile.

 

How content is evaluated

Every time the banned word filter detects a pattern in an email message, it adds the pattern score to the sum of scores for the message. You set this score when you create a new pattern to block content. The score can be any number from zero to 99999. Higher scores indicate more offensive content. When the total score equals or exceeds the threshold, the email message is considered as spam and treated according to the spam action configured in the email filter profile. The score for each pattern is counted only once, even if that pattern appears many times in the email message. The default score for banned word patterns is 10 and the default threshold is

10. This means that by default, an email message is blocked by a single match.

A pattern can be part of a word, a whole word, or a phrase. Multiple words entered as a pattern are treated as a phrase. The phrase must appear as entered to match. You can also use wildcards or regular expressions to have a pattern match multiple words or phrases.

For example, the FortiGate unit scans an email message that contains only this sentence: “The score for each word or phrase is counted only once, even if that word or phrase appears many times in the email message.”

Banned word pat- tern  

Pattern type

  

Assign score

  

ed  Score added to the sum for the

entire page

  

 

Comment
 

word

  

Wildcard

  

20

  

20

  

The pattern appears twice but multiple occur-
        rences are only counted once.
         

Although each word in the phrase appears in the
word phrase Wildcard 20 0 message, the words do not appear together as
        they do in the pattern. There are no matches.
 

word*phrase

  

Wildcard

  

20

  

20

  

The wildcard represents any number of any char-
        acter. A match occurs as long as “word” appears
        before “phrase” regardless of what is in between
        them.
         

Since the wildcard character can represent any
mail*age Wildcard 20 20 characters, this pattern is a match because
        “email message” appears in the message.

In this example, the message is treated as spam if the banned word threshold is set to 60 or less.

 

Adding words to a banned word list

When you enter a word, set the Pattern-type to wildcards or regular expressions.

 

Wildcard uses an asterisk (“*”) to match any number of any character. For example, re* will match all words starting with “re”.

Regular expression uses Perl regular expression syntax. See http://perldoc.perl.org/perlretut.html for detailed information about using Perl regular expressions.

DNS–based Blackhole List (DNSBL)

A DNSBL is a list of IP addresses, usually maintained by a third party, which are identified as being associated with spamming.

 

FortiGuard-Antispam Service. FortiGuard IP address check

The FortiGate unit queries the FortiGuard Anti-Spam Service to determine if the IP address of the client delivering the email is blacklisted. A match will cause the FortiGate unit to treat delivered messages as spam.

The default setting of the smtp-spamhdrip CLI command is disable. When you enable FortiGuard IP address checking, your FortiGate unit will submit the IP address of the client to the FortiGuard service for checking. If the IP address exists in the FortiGuard IP address black list, your FortiGate unit will treat the message as spam.

 

FortiGuard URL check

When you enable FortiGuard URL checking, your FortiGate unit will submit all URLs appearing in the email message body to the FortiGuard service for checking. If a URL exists in the FortiGuard URL black list, your FortiGate unit will treat the message as spam.

 

FortiGuard email checksum check

When you enable FortiGuard email checksum checking, your FortiGate unit will submit a checksum of each email message to the FortiGuard service for checking. If a checksum exists in the FortiGuard checksum black list, your FortiGate unit will treat the message as spam.

 

Detect phishing URLs in email

When you enable FortiGuard phishing URL detection, your FortiGate unit will submit all URL hyperlinks appearing in the email message body to the FortiGuard service for checking. If a URL exists in the FortiGuard URL phishing list, your FortiGate unit will remove the hyperlink from the message. The URL will remain in place, but it will no longer be a selectable hyperlink.

 

FortiGuard spam submission

Spam submission is a way you can inform the FortiGuard Anti-Spam service of non-spam messages incorrectly marked as spam. When you enable this setting, the FortiGate unit adds a link to the end of every message marked as spam. You then select this link to inform the FortiGuard Anti-Spam service when a message is incorrectly marked.

 

Trusted IP Addresses

A list of IP addresses that are trusted by the FortiGate is created. Any email traffic coming in from these IP address will be considered to be non-spammers.

If the FortiGate unit sits behind a company’s Mail Transfer Units, it may be unnecessary to check email IP addresses because they are internal and trusted. The only IP addresses that need to be checked are those from outside of the company. In some cases, external IP addresses may be added to the list if it is known that they are not sources of spam.

 

MIME header

This feature filters by the MIME header. MIME header settings are configured in a separate part of the command tree but MIME header filtering is enabled within each profile.

 

HELO DNS lookup

Whenever a client opens an SMTP session with a server, the client sends a HELO command with the client domain name. The FortiGate unit takes the domain name specified by the client in the HELO and does a DNS lookup to determine if the domain exists. If the lookup fails, the FortiGate unit determines that any messages delivered during the SMTP session are spam.

The HELO DNS lookup is available only for SMTP traffic.

 

Return email DNS check

The FortiGate unit performs a DNS lookup on the If no such record exists, the message is treated as spam. When you enable return email DNS checking, your FortiGate unit will take the domain in the reply-to email address and reply-to domain and check the DNS servers to see if there is an A or MX record for the domain. If the domain does not exist, your FortiGate unit will treat the message as spam.

Order of spam filtering

The FortiGate unit checks for spam using various filtering techniques. The order in which the FortiGate unit uses these filters depends on the mail protocol used.

Filters requiring a query to a server and a reply (FortiGuard Antispam Service and DNSBL/ORDBL) are run simultaneously. To avoid delays, queries are sent while other filters are running. The first reply to trigger a spam action takes effect as soon as the reply is received.

Each spam filter passes the email to the next if no matches or problems are found. If the action in the filter is Mark as Spam, the FortiGate unit tags the email as spam according to the settings in the email filter profile. For SMTP and SMTPS, if the action is discard, the email message is discarded or dropped.

If the action in the filter is Mark as Clear, the email is exempt from any remaining filters. If the action in the filter is Mark as Reject, the email session is dropped. Rejected SMTP or SMTPS email messages are substituted with a configurable replacement message.

 

Order of SMTP and SMTPS spam filtering

The FortiGate unit scans SMTP and SMTPS email for spam in the order given below. SMTPS spam filtering is available on FortiGate units that support SSL content scanning and inspection.

1. IP address black/white list (BWL) check on last hop IP

2. DNSBL & ORDBL check on last hop IP, FortiGuard Antispam IP check on last hop IP, HELO DNS lookup

3. MIME headers check, E-mail address BWL check

4. Banned word check on email subject

5. IP address BWL check (for IPs extracted from “Received” headers)

6. Banned word check on email body

7. Return email DNS check, FortiGuard Antispam email checksum check, FortiGuard Antispam URL check, DNSBL & ORDBL check on public IP extracted from header.

 

Order of IMAP, POP3, IMAPS and POP3S spam filtering

The FortiGate unit scans IMAP, POP3, IMAPS and POP3S email for spam in the order given below. IMAPS and POP3S spam filtering is available on FortiGate units that support SSL content scanning and inspection.

1. MIME headers check, E-mail address BWL check

2. Banned word check on email subject

3. IP BWL check

4. Banned word check on email body

5. Return email DNS check, FortiGuard Antispam email checksum check, FortiGuard Antispam URL check, DNSBL & ORDBL check.

 

Spam actions

When spam is detected, the FortiGate unit will deal with it according to the Spam Action setting in the email filter profile. Note that POP3S, IMAPS and SMTPS spam filtering is available only on FortiGate units that support SSL content scanning and inspection. POP3, IMAP, POP3S and IMAPS mail can only be tagged. SMTP and SMTPS mail can be set to Discard or Tagged:

 

Discard

When the spam action is set to Discard, messages detected as spam are deleted. No notification is sent to the sender or recipient.

 

Pass

When the spam action is set to pass, message the spam filter is disabled for this message.

 

Tag

When the spam action is set to Tagged, messages detected as spam are labelled and delivered normally. The text used for the label is set in the Tag Format field and the label is placed in the subject or the message header, as set with the Tag Location option.

 

Email traffic types to inspect

The FortiGate unit examines IMAP, POP3, and SMTP email traffic. If your FortiGate unit supports content inspection, it can also examine IMAPS, POP3S, and SMTPS traffic. The options that you will see in the profile window are IMAP, POP3 and SMTP.

 

Configuring Anti-Spam

FortiGuard email filtering techniques us FortiGuard services to detect the presence of spam among your email. A FortiGuard subscription is required to use the FortiGuard email filters. To enable email filtering an email filter needs to be created and then the filter needs to be associated with a security policy.

 

The filter can be created as follows:

  • Go to Security Profiles > Anti-Spam.
  • Select the Create New icon (a plus symbol in a circle in the upper right hand corner).
  • Select the List icon (a page symbol in the upper right hand corner) and in the new window select Create New. An existing filter can be edited as follows:
  • Go to Security Profiles > Anti-Spam.
  • Select the filter that you wish to edit from the dropdown menu in the upper right corner.
  • Select the List icon (a page symbol in the upper right hand corner) and select the filter that you wish to edit from the list.

Once you are in the proper Edit Email Filter Profile window, you can enter a name in the Name field if it’s a new filter.

The Comments field is for a description or other information that will assist in understanding the function or purpose of the this particular filter.

Using the radio buttons for the Inspection Mode field, select either Proxy or Flow-based.

Before any of the other features or options of the filter appear the checkbox next to Enable Spam Detection and Filtering must be checked.

 

Spam detection by protocol

This matrix includes three rows that represent the email protocols IMAP, POP3 and SMTP. There are also columns for:

Spam Action

 

For the client protocols, IMAP and POP3 the options are:

  • Tag – This action will insert a tag into the email somewhere so that when the recipients view the email they will be warned that it is likely a spam.
  • Pass – This action will allow any emails marked as spam to pass through without change. If this option is chosen, the Tag comments will be greyed out.

For the transfer protocol, SMTP, the options are:

  • Tag – This action will insert a tag into the email somewhere so that when the recipients view the email they will be warned that it is likely a spam.
  • Discard – The action will drop the email before it reaches its destination.
  • Pass – This action will allow any emails marked as spam to pass through without change. If this option is chosen, the Tag comments will be greyed out.

 

Tag Location

  • Subject – The contents of the Tag Format will be inserted into the subject line. The subject line is the most commonly used.
  • MIME – The contents of the Tag Format will be inserted in with the MIME header header.

 

Tag Format

The contents of this field will be entered into the tag location specified. The most common tag is something along the lines of [Spam] or **SPAM**

 

FortiGuard Spam Filtering

The options in the section are ones that require a FortiGuard subscription. The options available in this section, to be selected by checkbox are:

  • IP Address Check
  • URL Check
  • Detect Phishing URLs in Email
  • Email Checksum Check
  • Spam Submission

 

Local Spam Filtering

The options in the section are ones can be managed on the local device without the need for a FortiGuard subscription.

The options available in this section, to be selected by checkbox are:

  • HELO DNS Lookup
  • Return Email DNS Check
  • Black White List – checking this option will produce a table that can be edited to create a number of BWL lists that can be separately configured and enabled.

Creating a custom signature to block files according to the file’s hash value

Leave a reply

Creating a custom signature to block files according to the file’s hash value

In this example, you will create a custom signature that allows you to specify a hash value (or checksum) of a file that you want to block. To block multiple files you can create a custom signature for each file with that file’s hash value in it and then add all of the custom signatures to an IPS sensor and set the action to block for each one. When IPS encounters a file with a matching hash value the file is blocked.

This example uses a CRC32 checksum of the file as the hash value of the file to be blocked. You can use any utility that supports CRC32 checksums to generate the hash value.

1. Enter the custom signature basic format.

All custom signatures have a header and at least one keyword/value pair. The header is always the same: F-SBID( )

The keyword/value pairs appear within the parentheses and each pair is followed by a semicolon.

2. Choose a name for the custom signature

Every custom signature requires a name, so it is a good practice to assign a name before adding any other keywords. Use the –name keyword to assign the custom signature a name. The name value follows the keyword after a space. Enclose the name value in double-quotes:

F-SBID( –name “File.Hash.Example”; )

The signature, as it appears here, will not do anything if you try to use it. It has a name, but does not look for any patterns in network traffic.

3. Specify the traffic type.

Use the  –protocol tcp keyword to limit the effect of the custom signature to only TCP traffic. This will save system resources by not unnecessarily scanning UDP and ICMP traffic.

F-SBID( –name “File.Hash.Example”; –protocol tcp; )

The FortiGate unit will limit its search for the pattern to TCP traffic and ignore UDP and ICMP network traffic.

4. Add the CRC32 hash value.

Use the –crc32 keyword. This indicates that the value that follows is a hexadecimal number that represents the CRC32 checksum of the file. The –crc32 keyword also requires that you include the file length. The syntax is –crc32 <checksum>,<file-length>;. The following example shows the syntax for a file with checksum 51480492 and file length 822.

F-SBID( –name “File.Hash.Example”; –protocol tcp; –crc32 51480492,822; )

Creating a custom signature to block the SMTP “vrfy” command

Leave a reply

Creating a custom signature to block the SMTP “vrfy” command

The SMTP “vrfy” command can be used to verify the existence of a single email address or to list all of the valid email accounts on an email server. A spammer could potentially use this command to obtain a list of all valid email users and direct spam to their inboxes.

In this example, you will create a custom signature to block the use of the vrfy command. Since the custom signature blocks the vrfy command from coming through the FortiGate unit, the administrator can still use the command on the internal network.

This example describes the use of the custom signature syntax to block the vrfy command. To create the custom signature entry in the FortiGate unit web-based manager, see “Creating a custom IPS signature”.

1. Enter the custom signature basic format

All custom signatures have a header and at least one keyword/value pair. The header is always the same:

F-SBID( )

The keyword/value pairs appear within the parentheses and each pair is followed by a semicolon.

2. Choose a name for the custom signature

Every custom signature requires a name, so it is a good practice to assign a name before you add any other keywords.

Use the –name keyword to assign the custom signature a name. The name value follows the keyword after a space. Enclose the name value in double-quotes:

F-SBID( –name “Block.SMTP.VRFY.CMD”; )

The signature, as it appears here, will not do anything if you try to use it. It has a name, but does not look for any patterns in network traffic. You must specify a pattern that the FortiGate unit will search for.

3. Add a signature pattern

Use the –pattern keyword to specify what the FortiGate unit will search for:

F-SBID( –name “Block.SMTP.VRFY.CMD”; –pattern “vrfy”; )

The signature will now detect the vrfy command appearing in network traffic. The custom signature should only detect the command in SMTP traffic, however. Any other traffic with the pattern should be allowed to pass. For example, an email message discussing the vrfy command should not be stopped.

4. Specify the service.

Use the –service keyword to limit the effect of the custom signature to only the HTTP protocol.

F-SBID( –name “Block.SMTP.VRFY.CMD”; –pattern “vrfy”; –service SMTP; )

The FortiGate unit will limit its search for the pattern to the SMTP protocol.

Even though the SMTP protocol uses only TCP traffic, the FortiGate will search for SMTP protocol communication in TCP, UDP, and ICMP traffic. This is a waste of system resources that you can avoid by limiting the search further, as shown below.

5. Specify the traffic type.

Use the –protocol tcp keyword to limit the effect of the custom signature to only TCP traffic. This will save system resources by not unnecessarily scanning UDP and ICMP traffic.

F-SBID( –name “Block.SMTP.VRFY.CMD”; –pattern “vrfy”; –service SMTP; — protocol tcp; )

The FortiGate unit will limit its search for the pattern to TCP traffic and ignore the pattern in UDP and

ICMP network traffic.

6. Ignore case sensitivity.

By default, patterns are case sensitive. If a user directed his or her browser to Example.com, the custom signature would not recognize the URL as a match.

Use the –no_case keyword to make the pattern matching case insensitive.

F-SBID( –name “Block.SMTP.VRFY.CMD”; –pattern “vrfy”; –service SMTP; –no_case; )

Unlike all of the other keywords in this example, the –no_case keyword has no value. Only the keyword is required.

7. Specify the context.

The SMTP vrfy command will appear in the SMTP header. The –context host keyword/value pair allows you to limit the pattern search to only the header.

F-SBID( –name “Block.SMTP.VRFY.CMD”; –pattern “vrfy”; –service SMTP; –no_case; –context header; )

Creating a custom signature to block access to example.com

Leave a reply

Creating a custom signature to block access to example.com

In this first example, you will create a custom signature to block access to the example.com URL.

This example describes the use of the custom signature syntax to block access to a URL. To create the custom signature entry in the FortiGate unit web-based manager, see “Creating a custom IPS signature”.

1. Enter the custom signature basic format.

All custom signatures have a header and at least one keyword/value pair. The header is always the same:

F-SBID( )

The keyword/value pairs appear within the parentheses and each pair is followed by a semicolon.

2. Choose a name for the custom signature

Every custom signature requires a name, so it is a good practice to assign a name before adding any other keywords.Use the –name keyword to assign the custom signature a name. The name value follows the keyword after a space. Enclose the name value in double-quotes:

F-SBID( –name “Block.example.com”; )

The signature, as it appears here, will not do anything if you try to use it. It has a name, but does not look for any patterns in network traffic. You must specify a pattern that the FortiGate unit will search for.

3. Add a signature pattern

Use the –pattern keyword to specify what the FortiGate unit will search for:

F-SBID( –name “Block.example.com”; –pattern “example.com”; )

The signature will now detect the example.com URL appearing in network traffic. The custom signature should only detect the URL in HTTP traffic, however. Any other traffic with the URL should be allowed to pass. For example, an email message to or from example.com should not be stopped.

4. Specify the service

Use the –service keyword to limit the effect of the custom signature to only the HTTP protocol.

F-SBID( –name “Block.example.com”; –pattern “example.com”; –service HTTP; )

The FortiGate unit will limit its search for the pattern to the HTTP protocol. Even though the HTTP protocol uses only TCP traffic, the FortiGate will search for HTTP protocol communication in TCP, UDP, and ICMP traffic. This is a waste of system resources that you can avoid by limiting the search further, as shown below.

5. Specify the traffic type.

Use the  –protocol tcp keyword to limit the effect of the custom signature to only TCP traffic. This will save system resources by not unnecessarily scanning UDP and ICMP traffic.

F-SBID( –name “Block.example.com”; –pattern “example.com”; –service HTTP; — protocol tcp; )

The FortiGate unit will limit its search for the pattern to TCP traffic and ignore UDP and ICMP network traffic.

6. Ignore case sensitivity

By default, patterns are case sensitive. If a user directed his or her browser to Example.com, the custom signature would not recognize the URL as a match.

Use the –no_case keyword to make the pattern matching case insensitive.

F-SBID( –name “Block.example.com”; –pattern “example.com”; –service HTTP; –no_case; )

Unlike all of the other keywords in this example, the –no_case keyword has no value. Only the keyword is required.

7. Limit pattern scans to only traffic sent from the client

The –flow command can be used to further limit the network traffic being scanned to only that send by the client or by the server.

F-SBID( –name “Block.example.com”; –pattern “example.com”; –service HTTP; –no_case; –flow from_client; )

Web servers do not contact clients until clients first open a communication session. Therefore, using the –flow from_client command will force the FortiGate to ignore all traffic from the server. Since the majority of HTTP traffic flows from the server to the client, this will save considerable system resources and still maintain protection.

8. Specify the context

When the client browser tries to contact example.com, a DNS is first consulted to get the example.com server IP address. The IP address is then specified in the URL field of the HTTP communication. The domain name will still appear in the host field, so this custom signature will not function without the –context host keyword/value pair.

F-SBID( –name “Block.example.com”; –pattern “example.com”; –service HTTP; –no_case; –flow from_client; –context host; )

Custom Application & IPS Signatures

Leave a reply

Custom Application & IPS Signatures

 

Creating a custom IPS signature

The FortiGate predefined signatures cover common attacks. If you use an unusual or specialized application or an uncommon platform, add custom signatures based on the security alerts released by the application and platform vendors.

You can add or edit custom signatures using the web-based manager or the CLI.

 

To create a custom signature

1. Go to Security Profiles > Intrusion Protection.

2. Select [View IPS Signatures]

3. Select Creat New to add a new custom signature.

4. Enter a Name for the custom signature.

5. Enter the Signature. For information about completing this field, see “Custom signature syntax and keywords”.

6. Select OK.

 

Custom signature syntax and keywords

All custom signatures follow a particular syntax. Each begins with a header and is followed by one or more keywords. The syntax and keywords are detailed in the next two topics.

 

Custom signature syntax

A custom signature definition is limited to a maximum length of 512 characters. A definition can be a single line or span multiple lines connected by a backslash (\) at the end of each line.

A custom signature definition begins with a header, followed by a set of keyword/value pairs enclosed by parenthesis [( )]. The keyword and value pairs are separated by a semi colon (;) and consist of a keyword and a value separated by a space. The basic format of a definition is HEADER (KEYWORD VALUE;)

You can use as many keyword/value pairs as required within the 512 character limit. To configure a custom signature, go to Security Profiles > Intrusion Protection, select View IPS Signatures, select Create New, and enter the data directly into the Signature field, following the guidance in the next topics.

The table below shows the valid characters and basic structure. For details about each keyword and its associated values, see “Custom signature keywords”.

 

Valid syntax for custom signature fields

Field Valid Characters Usage
 

HEADER

  

F-SBID

  

The header for an attack defin- ition signature. Each custom signature must begin with this header.

Field                        Valid Characters                                                       Usage

KEYWORD

Each keyword must start with a pair of dashes (–), and consist of a string of 1 to 19 characters.

Normally, keywords are an English word or English words connected by an underscore (_). Keywords are case insensitive.

The keyword is used to identify a parameter.

VALUE                       Double quotes (“) must be used around the value if it contains a space and/or a semicolon (;).

If the value is NULL, the space between the KEYWORD and VALUE can be omitted. Values are case sensitive.

Note: If double quotes are used for quoting the value, the double quotes are not considered as part of the value string.

The value is set specifically for a parameter identified by a keyword.

 

Custom signature keywords

 

Information keywords attack_id Syntax: –attack_id <id_int>;

 

Description:

Use this optional value to identify the signature. It cannot be the same value as any other custom rules. If an attack ID is not specified, the FortiGate automatically assigns an attack ID to the signature. If you are using VDOMs, custom signatures appear only in the VDOM in which you create them. You can use the same attack ID for signatures in different VDOMs.

An attack ID you assign must be between 1000 and 9999.

Example: –attack_id 1234;

name

Syntax: –name <name_str>;

Description:

Enter the name of the rule. A rule name must be unique. If you are using VDOMs, custom signatures appear only in the VDOM in which you create them. You can use the same rule name for signatures in different VDOMs. The name you assign must be a string greater than 0 and less than 64 characters in length.

Example: –name “Buffer_Overflow”;

Session keywords flow Syntax: –flow {from_client[,reversed] | from_server[,reversed] | bi_direction };

 

Description:

Specify the traffic direction and state to be inspected. They can be used for all IP traffic.

 

Example: –src_port 41523; –flow bi_direction;

The signature checks traffic to and from port 41523.

If you enable “quarantine attacker”, the optional reversed keyword allows you to change the side of the connection to be quarantined when the signature is detected.

For example, a custom signature written to detect a brute-force log in attack is triggered when “Login Failed” is detected from_server more than 10 times in 5 seconds. If the attacker is quarantined, it is the server that is quarantined in this instance. Adding reversed corrects this problem and quarantines the actual attacker.

Previous FortiOS versions used to_client and to_server values. These are now deprecated, but still function for backwards compatibility.

 

service

Syntax: –service {HTTP | TELNET | FTP | DNS | SMTP | POP3 | IMAP | SNMP | RADIUS | LDAP | MSSQL | RPC | SIP | H323 | NBSS | DCERPC | SSH | SSL};

Description:

Specify the protocol type to be inspected. This keyword allows you to specify the traffic type by protocol rather than by port. If the decoder has the capability to identify the protocol on any port, the signature can be used to detect the attack no matter what port the service is running on. Currently, HTTP, SIP, SSL, and SSH protocols can be identified on any port based on the content.

 

Content keywords byte_extract

Syntax: byte_extract:<bytes_to_extract>, <offset>, <name> \ [, relative][, multiplier <multiplier value>][, <endian>]\ [, string][, hex][, dec][, oct][, align <align value>][, dce];

 

Description:

Use the byte_extract option to write rules against length-encoded protocols. This reads some of the bytes from the packet payload and saves it to a variable.

 

byte_jump

Syntax: –byte_jump <bytes_to_convert>, <offset>[, multiplier][, relative] [, big] [, little] [, string] [, hex] [, dec] [, oct] [, align];

 

Description:

Use the byte_jump option to extract a number of bytes from a packet, convert them to their numeric representation, and jump the match reference up that many bytes (for further pattern matching or byte testing). This keyword allows relative pattern matches to take into account numerical values found in network data. The available keyword options include:

  • <bytes_to_convert>: The number of bytes to examine from the packet.
  • <offset>: The number of bytes into the payload to start processing.
  • [multiplier]: multiplier is optional. It must be a numerical value when present. The converted value multiplied by the number is the result to be skipped.
  • relative: Use an offset relative to last pattern match.
  • big: Process the data as big endian (default).
  • little: Process the data as little endian.
  • string: The data is a string in the packet.
  • hex: The converted string data is represented in hexadecimal notation.
  • dec: The converted string data is represented in decimal notation.
  • oct: The converted string data is represented in octal notation.
  • align: Round up the number of converted bytes to the next 32-bit boundary.

 

byte_test Syntax: –byte_test <bytes_to_convert>, <operator>, <value>, <offset> [multiplier][, relative] [, big] [, little] [, string] [, hex] [, dec] [, oct];

 

Description:

Use the byte_test keyword to compare a byte field against a specific value (with operator). This keyword is capable of testing binary values or converting representative byte strings to their binary equivalent and testing them. The available keyword options include:

  • <bytes_to_convert>: The number of bytes to compare.
  • <operator>: The operation to perform when comparing the value (<,>,=,!,&).
  • <value>: The value to compare the converted value against.
  • <offset>: The number of bytes into the payload to start processing.
  • [multiplier]: multiplier is optional. It must be a numerical value when present. The converted value multiplied by the number is the result to be skipped.
  • relative: Use an offset relative to last pattern match.
  • big: Process the data as big endian (default).
  • little: Process the data as little endian.
  • string: The data is a string in the packet.
  • hex: The converted string data is represented in hexadecimal notation.
  • dec: The converted string data is represented in decimal notation.
  • oct: The converted string data is represented in octal notation.

 

depth Syntax: –depth <depth_int>;

 

Description:

Use the depth keyword to search for the contents within the specified number of bytes after the starting point defined by the offset keyword. If no offset is specified, the offset is assumed to be equal to 0.

If the value of the depth keyword is smaller than the length of the value of the content keyword, this signature will never be matched.

The depth must be between 0 and 65535.

 

distance Syntax: –distance <dist_int>;

Description:

Use the distance keyword to search for the contents within the specified number of bytes relative to the end of the previously matched contents. If the within keyword is not specified, continue looking for a match until the end of the payload.

The distance must be between 0 and 65535.

content

Syntax: –content [!]”<content_str>”;

Description:

Deprecated, see pattern and context keywords. Use the content keyword to search for the content string in the packet payload. The content string must be enclosed in double quotes.

To have the FortiGate search for a packet that does not contain the specified context string, add an exclamation mark (!) before the content string.

Multiple content items can be specified in one rule. The value can contain mixed text and binary data. The binary data is generally enclosed within the pipe (|) character.

The double quote (“), pipe sign(|) and colon(:) characters must be escaped using a back slash if specified in a content string.

If the value of the content keyword is greater than the length of the value of the depth keyword, this signature will never be matched.

 

context Syntax: –context {uri | header | body | host};

 

Description:

Specify the protocol field to look for the pattern. If context is not specified for a pattern, the FortiGate unit searches for the pattern anywhere in the packet buffer. The available context variables are:

  • uri: Search for the pattern in the HTTP URI line.
  • header: Search for the pattern in HTTP header lines or SMTP/POP3/SMTP control messages.
  • body: Search for the pattern in HTTP body or SMTP/POP3/SMTP email body.
  • host: Search for the pattern in HTTP HOST line.

 

no_case

Syntax: –no_case;

Description:

Use the no-case keyword to force the FortiGate unit to perform a case-insensitive pattern match.

 

offset

Syntax: –offset <offset_int>;

Description:

Use the offset keyword to look for the contents after the specified number of bytes into the payload. The specified number of bytes is an absolute value in the payload. Follow the offset keyword with the depth keyword to stop looking for a match after a specified number of bytes. If no depth is specified, the FortiGate unit continues looking for a match until the end of the payload.

 

The offset must be between 0 and 65535.

pattern

Syntax: –pattern [!]”<pattern_str>”;

Description:

The FortiGate unit will search for the specified pattern. A pattern keyword normally is followed by a context keyword to define where to look for the pattern in the packet. If a context keyword is not present, the FortiGate unit looks for the pattern anywhere in the packet buffer. To have the FortiGate search for a packet that does not contain the specified URI, add an exclamation mark (!) before the URI.

 

Example: –pattern “/level/” –pattern “|E8 D9FF FFFF|/bin/sh” –pattern !”|20|RTSP/”

 

pcre

Syntax: –pcre [!]”/<regex>/[ismxAEGRUB]”;

 

Description:

Similarly to the pattern keyword, use the pcre keyword to specify a pattern using Perl-compatible regular expressions (PCRE). A pcre keyword can be followed by a context keyword to define where to look for the pattern in the packet. If no context keyword is present, the FortiGate unit looks for the pattern anywhere in the packet buffer.

For more information about PCRE syntax, go to http://www.pcre.org. The switches include:

  • i: Case insensitive.
  • s: Include newlines in the dot metacharacter.
  • m: By default, the string is treated as one big line of characters. ^ and $ match at the beginning and ending of the string. When m is set, ^ and $ match immediately following or immediately before any newline in the buffer, as well as the very start and very end of the buffer.
  • x: White space data characters in the pattern are ignored except when escaped or inside a character class.
  • A: The pattern must match only at the start of the buffer (same as ^ ).
  • E: Set $ to match only at the end of the subject string. Without E, $ also matches immediately before the final character if it is a newline (but not before any other newlines).
  • G: Invert the “greediness” of the quantifiers so that they are not greedy by default, but become greedy if followed by ?.
  • R: Match relative to the end of the last pattern match. (Similar to distance:0;).
  • U: Deprecated, see the context keyword. Match the decoded URI buffers.

uri

Syntax: –uri [!]”<uri_str>”;

 

Description:

Deprecated, see pattern and context keywords. Use the uri keyword to search for the URI in the packet payload. The URI must be enclosed in double quotes (“). To have the FortiGate unit search for a packet that does not contain the specified URI, add an exclamation mark (!) before the URI. Multiple content items can be specified in one rule. The value can contain mixed text and binary data. The binary data is generally enclosed within the pipe (|) character. The double quote (“), pipe sign (|) and colon (:) characters must be escaped using a back slash (\) if specified in a URI string.

 

within

Syntax: –within <within_int>;

Description:

Use this together with the distance keyword to search for the contents within the specified number of bytes of the payload.

The within value must be between 0 and 65535.

 

IP header keywords dst_addr Syntax: –dst_addr [!]<ipv4>;

 

Description:

Use the dst_addr keyword to search for the destination IP address. To have the FortiGate search for a packet that does not contain the specified address, add an exclamation mark (!) before the IP address. You can define up to 28 IP addresses or CIDR blocks. Enclose the comma separated list in square brackets.

Example: dst_addr [172.20.0.0/16, 10.1.0.0/16,192.168.0.0/16]

 

ip_dscp

Syntax: –ip_dscp

 

Description:

Use the ip_dscp keyword to check the IP DSCP field for the specified value.

 

ip_id

Syntax: –ip_id <field_int>;

Description:

Check the IP ID field for the specified value.

 

ip_option

Syntax: –ip_option {rr | eol | nop | ts | sec | lsrr | ssrr | satid | any};

 

Description:

Use the ip_option keyword to check various IP option settings. The available options include:

  • rr: Check if IP RR (record route) option is present. l  eol: Check if IP EOL (end of list) option is present. l  nop: Check if IP NOP (no op) option is present.
  • ts: Check if IP TS (time stamp) option is present.
  • sec: Check if IP SEC (IP security) option is present.
  • lsrr: Check if IP LSRR (loose source routing) option is present. l  ssrr: Check if IP SSRR (strict source routing) option is present. l  satid: Check if IP SATID (stream identifier) option is present.
  • any: Check if IP any option is present.

 

ip_tos

Syntax: –ip_tos <field_int>;

 

Description:

Check the IP TOS field for the specified value.

 

ip_ttl

Syntax: –ip_ttl [< | >] <ttl_int>;

 

Description:

Check the IP time-to-live value against the specified value. Optionally, you can check for an IP time-to-live greater-than (>) or less-than (<) the specified value with the appropriate symbol.

 

protocol

Syntax: –protocol {<protocol_int> | tcp | udp | icmp};

 

Description:

Check the IP protocol header.

 

Example: –protocol tcp;

 

src_addr

Syntax: –src_addr [!]<ipv4>;

Description:

Use the src_addr keyword to search for the source IP address. To have the FortiGate unit search for a packet that does not contain the specified address, add an exclamation mark (!) before the IP address. You can define up to 28 IP addresses or CIDR blocks. Enclose the comma separated list in square brackets.

 

Example: src_addr 192.168.13.0/24

TCP header keywords ack

Syntax: –ack <ack_int>;

 

Description:

Check for the specified TCP acknowledge number.

 

dst_port

Syntax: –dst_port [!]{<port_int> | :<port_int> | <port_int>: | <port_

int>:<port_int>};

 

Description:

Use the dst_port keyword to specify the destination port number. You can specify a single port or port range:

  • <port_int> is a single port.
  • :<port_int> includes the specified port and all lower numbered ports.
  • <port_int>: includes the specified port and all higher numbered ports.
  • <port_int>:<port_int> includes the two specified ports and all ports in between.

 

seq

Syntax: –seq [operator,]<number>[,relative];

 

Description:

Check for the specified TCP sequence number.

  • operator includes =,<,>,!.
  • relative indicates it’s relative to the initial sequence number of the TCP session.

 

src_port

Syntax: –src_port [!]{<port_int> | :<port_int> | <port_int>: | <port_

int>:<port_int>};

 

Description:

Use the src_port keyword to specify the source port number. You can specify a single port or port range:

  • <port_int> is a single port.
  • :<port_int> includes the specified port and all lower numbered ports.
  • <port_int>: includes the specified port and all higher numbered ports.
  • <port_int>:<port_int> includes the two specified ports and all ports in between.

 

tcp_flags

Syntax: –tcp_flags <SAFRUP120>[!|*|+] [,<SAFRUP120>];

 

Description:

Specify the TCP flags to match in a packet.

  • S: Match the SYN flag. l  A: Match the ACK flag. l  F: Match the FIN flag.
  • R: Match the RST flag.
  • U: Match the URG flag.
  • P: Match the PSH flag.
  • 1: Match Reserved bit 1.
  • 2: Match Reserved bit 2.
  • 0: Match No TCP flags set.
  • !: Match if the specified bits are not set.
  • *: Match if any of the specified bits are set.
  • +: Match on the specified bits, plus any others.

 

The first part if the value (<SAFRUP120>) defines the bits that must be present for a successful match.

 

Example:

–tcp_flags AP only matches the case where both A and P bits are set.

The second part ([,<SAFRUP120>]) is optional, and defines the additional bits that can be present for a match.

For example tcp_flags S,12 matches the following combinations of flags: S, S and 1, S and 2, S and 1 and 2. The modifiers !, * and + cannot be used in the second part.

window_size

Syntax: –window_size [!]<window_int>;

 

Description:

Check for the specified TCP window size. You can specify the window size as a hexadecimal or decimal integer. A hexadecimal value must be preceded by 0x. To have the FortiGate search for the absence of the specified window size, add an exclamation mark (!) before the window size.

 

UDP header keywords dst_port

Syntax: –dst_port [!]{<port_int> | :<port_int> | <port_int>: | <port_

int>:<port_int>};

 

Description:

Specify the destination port number. You can specify a single port or port range:

  • <port_int> is a single port.
  • :<port_int> includes the specified port and all lower numbered ports.
  • <port_int>: includes the specified port and all higher numbered ports.
  • <port_int>:<port_int> includes the two specified ports and all ports in between.

 

src_port

Syntax: –src_port [!]{<port_int> | :<port_int> | <port_int>: | <port_

int>:<port_int>};

 

Description:

 

Specify the destination port number. You can specify a single port or port range:

  • <port_int> is a single port.
  • :<port_int> includes the specified port and all lower numbered ports.
  • <port_int>: includes the specified port and all higher numbered ports.
  • <port_int>:<port_int> includes the two specified ports and all ports in between.

 

ICMP keywords icmp_code

Syntax: –icmp_code <code_int>;

 

Description:

Specify the ICMP code to match.

 

icmp_id

Syntax: –icmp_id <id_int>;

 

Description:

Check for the specified ICMP ID value.

 

icmp_seq

Syntax: –icmp_seq <seq_int>;

 

Description:

Check for the specified ICMP sequence value.

icmp_type

Syntax: –icmp_type <type_int>;

 

Description:

Specify the ICMP type to match.

 

Other keywords data_size

Syntax: –data_size {<size_int> | <<size_int> | ><size_int>;

 

Description:

Test the packet payload size. With data_size specified, packet reassembly is turned off automatically. So a signature with data_size and only_stream values set is wrong.

  • <size_int> is a particular packet size.
  • <<size_int> is a packet smaller than the specified size.
  • ><size_int> is a packet larger than the specified size. Examples:
  • –data_size 300;
  • –data_size <300;
  • –data_size >300;

data_at

Syntax: –data_at <offset_int>[, relative];

 

Description:

Verify that the payload has data at a specified offset, optionally looking for data relative to the end of the previous content match.

 

dump–all–html

Syntax: –dump-all-html

 

Description:

Dump all HTML files for benchmarking via iSniff. When there is no file type specified, all HTML files are dumped.

 

rate

Syntax: –rate <matches_int>,<time_int>;

 

Description:

Instead of generating log entries every time the signature is detected, use this keyword to generate a log entry only if the signature is detected a specified number of times within a specified time period.

  • <matches_int> is the number of times a signature must be detected.
  • <time_int> is the length of time in which the signature must be detected, in seconds.

For example, if a custom signature detects a pattern, a log entry will be created every time the signature is detected. If –rate 100,10; is added to the signature, a log entry will be created if the signature is detected 100 times in the previous 10 seconds. Use this command with –track to further limit log entries to when the specified number of detections occur within a certain time period involving the same source or destination address rather than all addresses.

 

rpc_num

Syntax: –rpc_num <app_int>[, <ver_int> | *][, <proc_int> | *>];

 

Description:

Check for RPC application, version, and procedure numbers in SUNRPC CALL requests. The * wild card can be used for version and procedure numbers.

 

same_ip

 

Syntax: –same_ip;

 

Description:

Check that the source and the destination have the same IP addresses.

 

track

Syntax: –track {SRC_IP |DST_IP |DHCP_CLIENT |DNS_DOMAIN}[,block_int];

 

Description:

When used with –rate, this keyword narrows the custom signature rate totals to individual addresses.

  • SRC_IP: tracks the packet’s source IP.
  • DST_IP: tracks the packet’s destination IP.
  • DHCP_CLIENT: tracks the DHCP client’s MAC address.
  • DNS_DOMAIN: counts the number of any specific domain name.
  • block_int has the FortiGate unit block connections for the specified number of seconds, from the client or to the server, depending on which is specified.

For example, if –rate 100,10 is added to the signature, a log entry will be created if the signature is detected 100 times in the previous 10 seconds. The FortiGate unit maintains a single total, regardless of source and destination address.

If the same custom signature also includes –track client; matches are totaled separately for each source address. A log entry is added when the signature is detected 100 times in 10 seconds within traffic from the same source address.

The –track keyword can also be used without –rate. If an integer is specified, the client or server will be blocked for the specified number of seconds every time the signature is detected.

Enable IPS packet logging

10 Replies

Enable IPS packet logging

Packet logging saves the network packets containing the traffic matching an IPS signature to the attack log. The FortiGate unit will save the logged packets to wherever the logs are configured to be stored, whether memory, internal hard drive, a FortiAnalyzer unit, or the FortiGuard Analysis and Management Service.

You can enable packet logging in the filters. Use caution in enabling packet logging in a filter. Filters configured with few restrictions can contain thousands of signatures, potentially resulting in a flood of saved packets. This would take up a great deal of space, require time to sort through, and consume considerable system resources to process. Packet logging is designed as a focused diagnostic tool and is best used with a narrow scope.

Although logging to multiple FortiAnalyzer units is supported, packet logs are not sent to the secondary and tertiary FortiAnalyzer units. Only the primary unit receives packet logs.

 

To enable packet logging for a filter

1. Create a filter in an IPS sensor.

2. After creating the filter, right-click the filter, and select Enable under Packet Logging.

3. Select the IPS sensor in the security policy that allows the network traffic the FortiGate unit will examine for the signature.

For information on viewing and saving logged packets, see “Configuring packet logging options”.

 

IPS logging changes

IPS operations severely affected by disk logging are moved out of the quick scanning path, including logging, SNMP trap generation, quarantine, etc.

Scanning processes are dedicated to nothing but scanning, which results in more evenly distributed CPU usage. Slow (IPS) operations are taken care of in a dedicated process, which usually stays idle.

 

IPS examples

 

Configuring basic IPS protection

Small offices, whether they are small companies, home offices, or satellite offices, often have very simple needs. This example details how to enable IPS protection on a FortiGate unit located in a satellite office. The satellite office contains only Windows clients.

 

Creating an IPS sensor

Most IPS settings are configured in an IPS sensor. IPS sensors are selected in firewall policies. This way, you can create multiple IPS sensors, and tailor them to the traffic controlled by the security policy in which they are selected. In this example, you will create one IPS sensor.

 

To create an IPS sensor— web-based manager

1. Go to Security Profiles > Intrusion Protection.

2. Select the Create New icon in the top of the Edit IPS Sensor window.

3. In the Name field, enter basic_ips.

4. In the Comments field, enter IPS protection for Windows clients.

5. Select OK.

6. Select the Create New drop-down to add a new component to the sensor and for the Sensor Type choose Filter Based.

7. In the Filter Options choose the following: a. For Severity: select all of the options b.  For Target: select Client only.

c. For OS: select Windows only.

8. For the Action leave as the default.

9. Select OK to save the filter.

10. Select OK to save the IPS sensor.

 

To create an IPS sensor — CLI

config ips sensor edit basic_ips

set comment “IPS protection for Windows clients” config entries

edit 1

set location client set os windows

end

end

 

Selecting the IPS sensor in a security policy

An IPS sensor directs the FortiGate unit to scan network traffic only when it is selected in a security policy. When an IPS sensor is selected in a security policy, its settings are applied to all the traffic the security policy handles.

 

To select the IPS sensor in a security policy — web-based manager

1. Go to Policy > Policy > Policy.

2. Select a policy.

3. Select the Edit icon.

4. Enable the IPS option.

5. Select the basic_ips profile from the list.

6. Select OK to save the security policy.

 

To select the IPS sensor in a security policy — CLI

config firewall policy edit 1

set utm-status enable

set ips-sensor basic_ips end

All traffic handled by the security policy you modified will be scanned for attacks against Windows clients. A small office may have only one security policy configured. If you have multiple policies, consider enabling IPS scanning for all of them.

 

Using IPS to protect your web server

Many companies have web servers and they must be protected from attack. Since web servers must be accessible, protection is not as simple as blocking access. IPS is one tool your FortiGate unit has to allow you to protect your network.

In this example, we will configure IPS to protect a web server. As shown below, a FortiGate unit protects a web server and an internal network. The internal network will have its own policies and configuration but we will concentrate on the web server in this example.

 

A simple network configuration

The FortiGate unit is configured with:

  • a virtual IP to give the web server a unique address accessible from the Internet.
  • a security policy to allow access to the web server from the Internet using the virtual IP.

To protect the web server using intrusion protection, you need to create an IPS sensor, populate it with filters, then enable IPS scanning in the security policy.

 

To create an IPS sensor

1. Go to Security Profiles > Intrusion Protection.

2. Select Create New.

3. Enter web_server as the name of the new IPS sensor.

4. Select OK.

The new IPS sensor is created but it has no filters, and therefore no signatures are included.

The web server operating system is Linux, so you need to create a filter for all Linux server signatures.

 

To create the Linux server filter

1. Go to Security Profiles > Intrusion Protection.

2. Select the web_server IPS sensor and select the Edit icon.

3. In the Pattern Based Signatures and Filters section, select Create New.

4. For Sensor Type, select Filter Based.

5. For Filter Options.

6. In the Filter Options choose the following: a. For Severity: select all of the options b.  For Target: select server only.

c. For OS: select Linux only.

7. Select OK.

The filter is saved and the IPS sensor page reappears. In the filter list, find the Linux Server filter and look at the value in the Count column. This shows how many signatures match the current filter settings. You can select the View Rules icon to see a listing of the included signatures.

 

To edit the security policy

1. Go to Policy & Objects > IPv4 Policy select security policy that allows access to the web server, and select the Edit icon.

2. Enable IPS option and choose the web_server IPS sensor from the list.

3. Select OK.

Since IPS is enabled and the web_server IPS sensor is specified in the security policy controlling the web server traffic, the IPS sensor examines the web server traffic for matches to the signatures it contains.

 

Create and test a packet logging IPS sensor

In this example, you create a new IPS sensor and include a filter that detects the EICAR test file and saves a packet log when it is found. This is an ideal first experience with packet logging because the EICAR test file can cause no harm, and it is freely available for testing purposes.

 

Create an IPS senor

1. Go to Security Profiles > Intrusion Protection.

2. Select Create New.

3. Name the new IPS sensor EICAR_test.

4. Select OK.

 

Create an entry

1. Select the Create New.

2. For Sensor Type choose Specify Signatures.

3. Rather than search through the signature list, use the name filter by selecting the search icon over the header of the Signature column.

4. Enter EICAR in the Search field.

5. Highlight the Virus.Test.File signature by clicking on it.

6. Select Block All as the Action.

7. Enable Packet Logging.

8. Select OK to save the IPS sensor.

You are returned to the IPS sensor list. The EICAR test sensor appears in the list.

 

Add the IPS sensor to the security policy allowing Internet access

1. Go to Policy & Objects > IPv4 Policy.

2. Select the security policy that allows you to access the Internet.

3. Select the Edit icon.

4. Turn ON Log Allowed Traffic.

a. Select All Sessions

5. Enable the IPS option.

6. Choose EICAR test from the available IPS sensors.

7. Select OK.

With the IPS sensor configured and selected in the security policy, the FortiGate unit blocks any attempt to download the EICAR test file.

 

Test the IPS sensor

1. Using your web browser, go to http://www.eicar.org/anti_virus_test_file.htm.

2. Scroll to the bottom of the page and select eicar.com from the row labeled as using the standard HTTP protocol.

3. The browser attempts to download the requested file and,

  • If the file is successfully downloaded, the custom signature configuration failed at some point. Check the custom signature, the IPS sensor, and the firewall profile.
  • If the download is blocked with a high security alert message explaining that you’re not permitted to download the file, the EICAR test file was blocked by the FortiGate unit antivirus scanner before the IPS sensor could examine it. Disable antivirus scanning and try to download the EICAR test file again.
  • If no file is downloaded and the browser eventually times out, the custom signature successfully detected the EICAR test file and blocked the download.

 

Viewing the packet log

1. Go to Log&Report > Security Log > AntiVirus.

2. Locate the log entry that recorded the blocking of the EICAR test file block. The Message field data will be tools: EICAR.AV.Test.File.Download.

3. Select the View Packet Log icon in the Packet Log column.

4. The packet log viewer is displayed.

 

Configuring a Fortinet Security Processing module

The Example Corporation has a web site that is the target of SYN floods. While they investigate the source of the attacks, it’s very important that the web site remain accessible. To enhance the ability of the company’s FortiGate-100D to deal with SYN floods, the administrator will install an ASM-CE4 Fortinet Security Processing module and have all external access to the web server come though it.

The security processing modules not only accelerate and offload network traffic from the FortiGate unit’s processor, but they also accelerate and offload security and content scanning. The ability of the security module to accelerate IPS scanning and DoS protection greatly enhances the defense capabilities of the FortiGate-100D.

 

Assumptions

As shown in other examples and network diagrams throughout this document, the Example Corporation has a pair of FortiGate-100D units in an HA cluster. To simplify this example, the cluster is replaced with a single FortiGate-100D.

An ASM-CE4 is installed in the FortiGate-100D. The network is configured as shown below.

Network configuration

The Example Corporation network needs minimal changes to incorporate the ASM-CE4. Interface amc-sw1/1 of the ASM-CE4 is connected to the Internet and interface amc-sw1/1 is connected to the web server.

Since the main office network is connected to port2 and the Internet is connected to port1, a switch is installed to allow both port1 and amc-sw1/1 to be connected to the Internet.

 

The FortiGate-100D network configuration

The switch used to connect port1 and amc-sw1/1 to the Internet must be able to handle any SYN flood, all of the legitimate traffic to the web site, and all of the traffic to and from the Example Corporation internal network. If the switch can not handle the bandwidth, or if the connection to the service provider can not provide the required bandwidth, traffic will be lost.

 

Security module configuration

The Fortinet security modules come configured to give equal priority to content inspection and firewall processing. The Example Corporation is using a ASM-CE4 module to defend its web server against SYN flood attacks so firewall processing is a secondary consideration.

Use these CLI commands to configure the security module in ASM slot 1 to devote more resources to content processing, including DoS and IPS, than to firewall processing.

config system amc-slot edit sw1

set optimization-mode fw-ips set ips-weight balanced

set ips-p2p disable

set ips-fail-open enable set fp-disable none

set ipsec-inb-optimization enable set syn-proxy-client-timer 3

set syn-proxy-server-timer 3 end

These settings do not disable firewall processing. Rather, when the security module nears its processing capacity, it will chose to service content inspection over firewall processing.

 

IPS Sensor

You can group signatures into IPS sensors for easy selection when applying to firewall policies. You can define signatures for specific types of traffic in separate IPS sensors, and then select those sensors in profiles designed to handle that type of traffic. For example, you can specify all of the web-server related signatures in an IPS sensor, and that sensor can then be applied to a firewall policy that controls all of the traffic to and from a web server protected by the unit.

The FortiGuard Service periodically updates the pre-defined signatures, with signatures added to counter new threats. Since the signatures included in filters are defined by specifying signature attributes, new signatures matching existing filter specifications will automatically be included in those filters. For example, if you have a filter that includes all signatures for the Windows operating system, your filter will automatically incorporate new Windows signatures as they are added.

Each IPS sensor consists of two parts: filters and overrides. Overrides are always checked before filters.

Each filter consists of a number of signatures attributes. All of the signatures with those attributes, and only those attributes, are checked against traffic when the filter is run. If multiple filters are defined in an IPS Sensor, they are checked against the traffic one at a time, from top to bottom. If a match is found, the unit takes the appropriate action and stops further checking.

A signature override can modify the behavior of a signature specified in a filter. A signature override can also add a signature not specified in the sensor’s filters. Custom signatures are included in an IPS sensor using overrides.

The signatures in the overrides are first compared to network traffic. If the IPS sensor does not find any matches, it then compares the signatures in each filter to network traffic, one filter at a time, from top to bottom. If no signature matches are found, the IPS sensor allows the network traffic.

The signatures included in the filter are only those matching every attribute specified. When created, a new filter has every attribute set to all which causes every signature to be included in the filter. If the severity is changed to high, and the target is changed to server, the filter includes only signatures checking for high priority attacks targeted at servers.