Other security profiles considerations

The following topics are included in this section:

• Security profiles and Virtual Domains (VDOMs) l Conserve mode
• Using wildcards and Perl regular expressions l CPU allocation and tuning commands to survive reboot

Global security profiles across Virtual domains (VDOMs)

Previously, if you enabled virtual domains (VDOMs) on your FortiGate unit, any Security Profiles configuration was limited to the VDOM in which you configured it.

Now Security Profiles can be configured globally across multiple VDOMs. In many VDOM environments, some or all profiles may be commonly-shared, for example an MSSP with “parental controls” configured will most likely have the same Web Filtering and Application Control profiles per VDOM.

Global profiles are configured under Global > Security Profiles in the GUI or under the following config global commands in the CLI:

l antivirus profile l application list l dlp sensor l ips sensor l webfilter profile

The name for any global profile must start with “g-” for identification. Global profiles are available as read-only for VDOM-level administrators and can only be edited or deleted from within the global settings.

Each security feature has at least one default global profile, available for all VDOMs.

Both Global security profile configuration and the various databases used by Security Profiles features are shared. The FortiGuard antivirus and IPS databases and updates to the databases are shared. The FortiGuard web filter and spam filter features access the FortiGuard distribution network and read the same information when checking email for spam and web site categories and classification.

Conserve mode

FortiGate units perform all Security Profiles processing in physical RAM. Since each model has a limited amount of memory, conserve mode is activated when the remaining free memory is nearly exhausted or the AV proxy has reached the maximum number of sessions it can service. While conserve mode is active, the AV proxy does not accept new sessions.

A warning will appear in the top bar of the FortiGate, regardless of which page in the FortiGate GUI you are on.

Conserve mode

The AV proxy

Most content inspection the FortiGate unit performs requires that the files, email messages, URLs, and web pages be buffered and examined as a whole. The AV proxy performs this function, and because it may be buffering many files at the same time, it uses a significant amount of memory. Conserve mode is designed to prevent all the component features of the FortiGate unit from trying to use more memory than it has. Because the AV proxy uses so much memory, conserve mode effectively disables it in most circumstances. As a result, the content inspection features that use the AV proxy are also disabled in conserve mode.

All of the Security Profiles features use the AV proxy with the exception of IPS, application control, DoS as well as flow-based antivirus, DLP, and web filter scanning. These features continue to operate normally when the FortiGate unit enters conserve mode.

Entering and exiting conserve mode

A FortiGate unit will enter conserve mode because it is nearly out of physical memory, or because the AV proxy has reached the maximum number of sessions it can service. The memory threshold that triggers conserve mode varies by model, but it is about 20% free memory. When memory use rises to the point where less than 20% of the physical memory is free, the FortiGate unit enters conserve mode.

The FortiGate unit will leave conserve mode only when the available physical memory exceeds about 30%. When exiting conserve mode, all new sessions configured to be scanned with features requiring the AV proxy will be scanned as normal, with the exception of a unit configured with the one-shot option.

Conserve mode effects

What happens when the FortiGate unit enters conserve mode depends on how you have av-failopen configured. There are four options:

off

The off setting forces the FortiGate unit to stop all traffic that is configured for content inspection by Security Profiles features that use the AV proxy. New sessions are not allowed but current sessions continue to be processed normally unless they request more memory. Sessions requesting more memory are terminated.

For example, if a security policy is configured to use antivirus scanning, the traffic it permits is blocked while in conserve mode. A policy with IPS scanning enabled continues as normal. A policy with both IPS and antivirus scanning is blocked because antivirus scanning requires the AV proxy.

Use the off setting when security is more important than a loss of access while the problem is rectified.

pass

The pass setting allows traffic to bypass the AV proxy and continue to its destination. Since the traffic is bypassing the proxy, no Security Profiles scanning that requires the AV proxy is performed. Security Profiles scanning that does not require the AV proxy continues normally.

Use the pass setting when access is more important than security while the problem is rectified.

Pass is the default setting.

Using wildcards and Perl regular expressions

one-shot

The one-shot setting is similar to pass in that traffic is allowed when conserve mode is active. The difference is that a system configured for one-shot will force new sessions to bypass the AV proxy even after it leaves conserve mode. The FortiGate unit resumes use of the AV proxy only when the av-failopen setting is changed or the unit is restarted.

idledrop

The idledrop setting will recover memory and session space by terminating all the sessions associated with the host that has the most sessions open. The FortiGate may force this session termination a number of times, until enough memory is available to allow it to leave conserve mode.

The idledrop setting is primarily designed for situations in which malware may continue to open sessions until the AV proxy cannot accept more new sessions, triggering conserve mode. If your FortiGate unit is operating near capacity, this setting could cause the termination of valid sessions. Use this option with caution.

Configuring the av-failopen command

You can configure the av-failopen command using the CLI.

config system global set av-failopen {off | pass | one-shot | idledrop}

end

The default setting is pass.

Using wildcards and Perl regular expressions

Many Security Profiles feature list entries can include wildcards or Perl regular expressions.

For more information about using Perl regular expressions, see http://perldoc.perl.org/perlretut.html.

Regular expression vs. wildcard match pattern

A wildcard character is a special character that represents one or more other characters. The most commonly used wildcard characters are the asterisk (*), which typically represents zero or more characters in a string of characters, and the question mark (?), which typically represents any one character.

In Perl regular expressions, the ‘.’ character refers to any single character. It is similar to the ‘?’ character in wildcard match pattern. As a result: l example.com not only matches example.com but also examplea.com, exampleb.com, examplec.com, and so on.

To add a question mark (?) character to a regular expression from the FortiGate CLI, enter Ctrl+V followed by ?. To add a single backslash character (\) to a regular expression from the CLI you must add precede it with another backslash character. For example, example\\.com.

To match a special character such as ‘.’ and ‘*’ use the escape character ‘\’. For example:

• To match example.com, the regular expression should be: example\.com

Using wildcards and Perl regular expressions

In Perl regular expressions, ‘*’ means match 0 or more times of the character before it, not 0 or more times of any character. For example:

• exam*.com matches exammmm.com but does not match example.com

To match any character 0 or more times, use ‘.*’ where ‘.’ means any character and the ‘*’ means 0 or more times. For example, the wildcard match pattern exam*.com should be exam.*\.com.

Word boundary

In Perl regular expressions, the pattern does not have an implicit word boundary. For example, the regular expression “test” not only matches the word “test” but also any word that contains “test” such as “atest”, “mytest”, “testimony”, “atestb”. The notation “\b” specifies the word boundary. To match exactly the word “test”, the expression should be \btest\b.

Case sensitivity

Regular expression pattern matching is case sensitive in the web and Email Filter filters. To make a word or phrase case insensitive, use the regular expression /i. For example, /bad language/i will block all instances of “bad language”, regardless of case.

Perl regular expression formats

The following table lists and describes some example Perl regular expressions.

Perl regular expression formats

Expression	Matches
abc	“abc” (the exact character sequence, but anywhere in the string)
^abc	“abc” at the beginning of the string
abc$	“abc” at the end of the string
a|b	Either “a” or “b”
^abc|abc$	The string “abc” at the beginning or at the end of the string
ab{2,4}c	“a” followed by two, three or four “b”s followed by a “c”
ab{2,}c	“a” followed by at least two “b”s followed by a “c”
ab*c	“a” followed by any number (zero or more) of “b”s followed by a “c”
ab+c	“a” followed by one or more b’s followed by a c
ab?c	“a” followed by an optional “b” followed by a” c”; that is, either “abc” or ”ac”
a.c	“a” followed by any single character (not newline) followed by a” c “

Using wildcards and Perl regular expressions

Expression	Matches
a\.c	“a.c” exactly
[abc]	Any one of “a”, “b” and “c”
[Aa]bc	Either of “Abc” and “abc”
[abc]+	Any (nonempty) string of “a”s, “b”s and “c”s (such as “a”, “abba”, ”acbabcacaa”)
[^abc]+	Any (nonempty) string which does not contain any of “a”, “b”, and “c” (such as “defg”)
\d\d	Any two decimal digits, such as 42; same as \d{2}
/i	Makes the pattern case insensitive. For example, /bad language/i blocks any instance of bad language regardless of case.
\w+	A “word”: A nonempty sequence of alphanumeric characters and low lines (underscores), such as foo and 12bar8 and foo_1
100\s*mk	The strings “100” and “mk” optionally separated by any amount of white space (spaces, tabs, newlines)
abc\b	“abc” when followed by a word boundary (for example, in “abc!” but not in “abcd”)
perl\B	“perl” when not followed by a word boundary (for example, in “perlert” but not in “perl stuff”)
\x	Tells the regular expression parser to ignore white space that is neither preceded by a backslash character nor within a character class. Use this to break up a regular expression into (slightly) more readable parts.
/x	Used to add regular expressions within other text. If the first character in a pattern is forward slash ‘/’, the ‘/’ is treated as the delimiter. The pattern must contain a second ‘/’. The pattern between ‘/’ will be taken as a regular expressions, and anything after the second ‘/’ will be parsed as a list of regular expression options (‘i’, ‘x’, etc). An error occurs if the second ‘/’ is missing. In regular expressions, the leading and trailing space is treated as part of the regular expression.

Examples of regular expressions

Block any word in a phrase

/block|any|word/

Block purposely misspelled words

Spammers often insert other characters between the letters of a word to fool spam blocking software.

/^.*v.*i.*a.*g.*r.*o.*$/i

/cr[eéèêë][\+\-\*=<>\.\,;!\?%&§@\^°\$£€\{\}()\[\]\|\\_01]dit/i

Control how sessions are distributed to Fortinet processes

Block common spam phrases

The following phrases are some examples of common phrases found in spam messages.

/try it for free/i

/student loans/i

/you’re already approved/i

/special[\+\-\*=<>\.\,;!\?%&~#§@\^°\$£€\{\}()\[\]\|\\_1]offer/i

Control how sessions are distributed to Fortinet processes

Previously, the explicit web proxy balanced the client to a specific WAD daemon based only on the source IP.

There are cases where customers use another explicit proxy in front of the FortiGate. With such a design, the FortiGate can see the traffic originating from only one IP address (or a small set of IP addresses) and utilize only one (or a small number) of WAD processes.

This new feature modifies the wad-worker balancing algorithm to also use the source port in addition to source IP when distributing the client to a specific WAD daemon. With this in place, even the connections from one IP address will be balanced over all the WAD processes. This also avoids the degraded performance results for the cases where customers are testing the FortiGate as the explicit webproxy to replace Bluecoats, but don’t want to remove Bluecoats from the network for the PoC.

Syntax

config system global set wad-source-affinity {enable | disable}

end

This feature is enabled by default. Disabling this option results in some features to be unsupported. IP-based user authentication, disclaimer messages, security profile override, authentication cookies, MAPI scanning, and some video caches such as Youtube are not supported.

CPU allocation and tuning commands to survive reboot

CPU affinity, whereby a process will execute on a specific CPU, can be changed so it survives a reboot.

CLI syntax:

config system global set av-affinity set ips-affinity set miglog-affinity

end av-affinity: Affinity setting for AV scanning (64-bit hexadecimal value in the format of xxxxxxxx_xxxxxxxx).

ips-affinity: Affinity setting for IPS (64-bit hexadecimal value in the format of xxxxxxxx_xxxxxxxx; allowed CPUs must be less than total number of IPS engine daemons). This option is only available if the FortiGate includes NP6 processors and support NTurbo. miglog-affinity: Affinity setting for logging (64-bit hexadecimal value in the format of xxxxxxxx_xxxxxxxx).

Excluding industrial IP signatures

Excluding industrial IP signatures

To reduce performance impacts caused by industrial IP signatures, the admin can choose to exclude the industrial signatures when they are loaded by IPS; the industrial signatures then become inactive as a result. The following CLI command has been restored for this purpose.

Syntax

config ips global set exclude-signatures {none | industrial} end

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

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’s GUI, see Custom Application & IPS Signatures.

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; )

Custom signature keywords

l information l session l content l IP header l TCP header l UDP header l ICMP l other

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.

app_cat

Syntax: –app_cat <category_int>;

Description:

Specify the category of the application signature. Signatures with this keyword are considered as application rules. These signatures will appear under Application Control instead of IPS configuration. To display a complete list of application signature categories, enter the following CLI commands:

config application list edit default config entries edit 1 set category ?

weight

Syntax: –weight <weight_int>;

Description:

Specify the weight to be assigned to the signature. This keyword allows a signature with the higher weight to have priority over a signature with a lower weight. This is useful to prioritize between custom and stock signatures and also between different custom signatures.

The weight must be between 0 an 255. Most of the signatures in the Application Control signature database have weights of 10; botnet signatures are set to 250. A range of 20 to 50 is recommended for custom signatures.

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 GUI or the CLI.

To create a custom signature

1. Go to Security Profiles > Intrusion Prevention.
2. Select [View IPS Signatures]
3. Select Create 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 Custom signature keywords.
6. Select OK.

Custom signature syntax

All custom signatures follow a particular syntax. Each begins with a header and is followed by one or more keywords. 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 Prevention, 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 definition 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.