Category Archives: FortiOS

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.

Configure IPS options

Leave a reply

Configure IPS options

The following IPS configuration options are available:

  • Malicious URL database for drive-by exploits detection
  • Customizable replacement message when IPS blocks traffic
  • Hardware Acceleration
  • Extended IPS Database
  • Configuring the IPS engine algorithm
  • Configuring the IPS engine-count
  • Configuring fail-open
  • Configuring the session count accuracy
  • Configuring IPS intelligence
  • Configuring the IPS buffer size
  • Configuring protocol decoders
  • Configuring security processing modules
  • IPS signature rate count threshold

 

Malicious URL database for drive-by exploits detection

This feature uses a local malicious URL database on the FortiGate to assist in drive-by exploits detection. The database contains all malicious URLs active in the last one month, and all drive-by exploit URLs active in the last three months. The number of URLs are controlled in the one million range.

 

CLI Syntax

config ips sensor edit <profile>

set block-malicious-url [enable | disable]

next end

 

Customizable replacement message when IPS blocks traffic

You can edit a replacement message that will appear specifically for IPS sensor blocked Internet access. Go to System > Replacement Messages, and find IPS Sensor Block Page under the Security heading.

 

Hardware Acceleration for flow-based security profiles (NTurbo and IPSA)

Some FortiGate models support a feature call NTurbo that can offload flow-based firewall sessions to NP4 or NP6 network processors. Some FortiGate models also support offloading enhanced pattern matching for flow- based security profiles to CP8 or CP9 content processors. You can use the following command to configure NTurbo and IPSA:

 

config ips global

set np-accel-mode {none | basic}

set cp-accel-mode {none | basic | advanced}

end

If the np-accel-mode option is available, your FortiGate supports NTurbo: none disables NTurbo and basic (the default) enables NTurbo. If the cp-accel-mode option is available your FortiGate supports IPSA: none disables IPSA, basic enables basic IPSA and advanced enables enhanced IPSA which can offload more types of pattern matching than basic IPSA. advanced is only available on FortiGate models with two or more CP8 processors or one or more CP9 processors.

See the Hardware Acceleration handbook chapter for more information about NTurbo and IPSA.

 

Extended IPS Database

Some models have access to an extended IPS Database. The extended database may affect the performance of the FortiGate unit so depending on the model of the FortiGate unit the extended database package may not be enabled by default. For example, the D-series Desktop model have this option disabled by default.

This feature can only be enbled through the CLI.

config ips global

set database extended end

 

Configuring the IPS engine algorithm

The IPS engine is able to search for signature matches in two ways. One method is faster but uses more memory, the other uses less memory but is slower. Use the algorithm CLI command to select one method:

config ips global

set algorithm {super | high | low | engine-pick}

end

 

Specify high to use the faster more memory intensive method or low for the slower memory efficient method. The setting super improves the performance for FortiGate units with more than 4GB of memory. The default setting is engine-pick, which allows the IPS engine to choose the best method on the fly.

 

Configuring the IPS engine-count

FortiGate units with multiple processors can run more than one IPS engine concurrently. The engine-count CLI command allows you to specify how many IPS engines are used at the same time:

config ips global

set engine-count <int>

end

 

The recommended and default setting is 0, which allows the FortiGate unit to determine the optimum number of IPS engines.

 

Configuring fail-open

IPS protection is likely more important to your network than uninterrupted flow of network traffic, so the fail-open behaviour of the IPS engine is disabled by default. If you would like to enable the fail-open option, use the following syntax. When enabled, if the IPS engine fails for any reason, it will fail open. This applies for inspection of all the protocols inspected by FortiOS IPS protocol decoders, including but not limited to HTTP, HTTPS, FTP, SMTP, POP3, IMAP, etc. This means that traffic continues to flow without IPS scanning. To enable:

config ips global

set fail-open {enable | disable}

end

 

The default setting is disable.

 

Configuring the session count accuracy

The IPS engine can keep track of the number of open session in two ways. An accurate count uses more resources than a less accurate heuristic count.

config ips global

set session-limit-mode {accurate | heuristic}

end

 

The default is heuristic.

 

Configuring IPS intelligence

If intelligent-mode is enabled (the default), in most cases the IPS engine will scan the first 200 kilobytes of a session (this value is hard coded).

In some cases, however, the IPS engine will still scan all traffic in a session. If intelligent-mode is disabled, the IPS engine scans all traffic.

config ips global

set intelligent-mode [enable|disable]

end

 

Configuring the IPS buffer size

Set the size of the IPS buffer.

config ips global

set socket-size <int>

end

 

The acceptable range is from 1 to 64 megabytes. The default size varies by model. In short, socket-size determines how much data the kernel passes to the IPS engine each time the engine samples packets.

 

Configuring protocol decoders

The FortiGate Intrusion Protection system uses protocol decoders to identify the abnormal traffic patterns that do not meet the protocol requirements and standards. For example, the HTTP decoder monitors traffic to identify any HTTP packets that do not meet the HTTP protocol standards.

To change the ports a decoder examines, you must use the CLI. In this example, the ports examined by the DNS decoder are changed from the default 53 to 100, 200, and 300.

config ips decoder dns_decoder set port_list “100,200,300”

end

 

You cannot assign specific ports to decoders that are set to auto by default. These decoders can detect their traffic on any port. Specifying individual ports is not necessary.

 

Configuring security processing modules

FortiGate Security Processing Modules, such as the CE4, XE2, and FE8, can increase overall system performance by accelerating some security and networking processing on the interfaces they provide. They also allow the FortiGate unit to offload the processing to the security module, thereby freeing up its own processor for other tasks. The security module performs its own IPS and firewall processing, but you can configure it to favor IPS in hostile high-traffic environments.

If you have a security processing module, use the following CLI commands to configure it to devote more resources to IPS than firewall. This example shows the CLI commands required to configure a security module in slot 1 for increased IPS performance.

 

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

In addition to offloading IPS processing, security processing modules provide a hardware accelerated SYN proxy to defend against SYN flood denial of service attacks. When using a security module, configure your DoS anomaly check for tcp_syn_flood with the Proxy action. The Proxy action activates the hardware accelerated SYN proxy.

 

IPS signature rate count threshold

The IPS signature threshold can allow configuring a signature so that it will not be triggered until a rate count threshold is met. This provides a more controlled recording of attack activity. For example, if multiple login attempts produce a failed result over a short period of time then an alert would be sent and perhaps traffic blocked. This would be a more rational response than sending an alert every time a login failed.

 

The syntax for this configuration is as follows:

config ips sensor edit default

config entries

edit <Filter ID number>

set rule <*id>

set rate-count <integer between 1 – 65535>

set rate-duration <integer between 1 – 65535>

 

The value of the rate-duration is an integer for the time in seconds.

set rate-mode <continuous | periodical>

 

The rate-mode refers to how the count threshold is met.

If the setting is “continuous”, and the action is set to block, as soon as the rate-count is reached the action is engaged. For example, if the count is 10, as soon as the signature is triggered 10 times the traffic would be blocked.

If the setting is “periodical”, the FortiGate allows up to the value of the rate-count incidents where the signature is triggered during the rate-duration. For example, if the rate count is 100 and the duration is 60, the signature would need to be triggered 100 times in 60 seconds for the action to be engaged.

set rate-track <dest-ip | dhcp-client-mac | dns-domain | none | src-ip>

 

This setting allows the tracking of one of the protocol fields within the packet.

IPS processing in an HA cluster

Leave a reply

IPS processing in an HA cluster

IPS processing in an HA cluster is no different than with a single FortiGate unit, from the point of view of the network user. The difference appears when a secondary unit takes over from the primary, and what happens depends on the HA mode.

 

Active–passive

In an active-passive HA cluster, the primary unit processes all traffic just as it would in a stand-alone configuration. Should the primary unit fail, a secondary unit will assume the role of the primary unit and begin to process network traffic. By default, the state of active communication sessions are not shared with secondary units and will not survive the fail-over condition. Once the sessions are reestablished however, traffic processing will continue as normal.

If your network requires that active sessions are taken over by the new primary unit, select Enable Session Pick-up in your HA configuration. Because session information must be sent to all subordinate units on a regular basis, session pick-up is a resource-intensive feature and is not enabled by default.

 

Active–active

The fail-over process in an active-active cluster is similar to an active-passive cluster. When the primary unit fails, a secondary unit takes over and traffic processing continues. The load-balancing schedule used to distribute sessions to the cluster members is used by the new primary unit to redistribute sessions among the remaining subordinate units. If session pick-up is not enabled, the sessions active on the failed primary are lost, and the sessions redistributed among the secondary units may also be lost. If session pick-up is enabled, all sessions are handled according to their last-known state.

Enable IPS scanning

Leave a reply

Enable IPS scanning

Enabling IPS scanning involves two separate parts of the FortiGate unit:

  • The security policy allows certain network traffic based on the sender, receiver, interface, traffic type, and time of day. Firewall policies can also be used to deny traffic, but those policies do not apply to IPS scanning.
  • The IPS sensor contains filters, signature entries, or both. These specify which signatures are included in the IPS sensor.

When IPS is enabled, an IPS sensor is selected in a security policy, and all network traffic matching the policy will be checked for the signatures in the IPS sensor.

 

General configuration steps

For best results in configuring IPS scanning, follow the procedures in the order given. Also, note that if you perform any additional actions between procedures, your configuration may have different results.

1. Create an IPS sensor.

2. Add signatures and /or filters.

These can be:

  • Pattern based
  • Rate based
  • Customized

3. Select a security policy or create a new one.

4. In the security policy, turn on IPS, and choose the IPS sensor from the list.

All the network traffic controlled by this security policy will be processed according to the settings in the policy. These settings include the IPS sensor you specify in the policy.

 

Creating an IPS sensor

You need to create an IPS sensor before specific signatures or filters can be choosen. The signatures can be added to a new sensor before it is saved, but it is a good practice to keep in mind that the sensor and its included filters are separte things, and therefore their creation will be treated separately.

 

To create a new IPS sensor

1. Go to Security Profiles > Intrusion Protection.

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

3. Enter the name of the new IPS sensor.

4. Optionally, you may also enter a comment. The comment will appear in the IPS sensor list and serves to remind you of the details of the sensor.

5. Select OK.

A newly created sensor is empty and contains no filters or signatures. You need to add one or more filters or signatures before the sensor will be of any use.

 

Adding an IPS filter to a sensor

While individual signatures can be added to a sensor, a filter allows you to add multiple signatures to a sensor by specifying the characteristics of the signatures to be added.

 

To create a new Pattern Based Signature and Filter

1. Go to Security Profiles > Intrusion Protection.

2. Select the IPS sensor to which you want to add the filter using the drop-down list in the top row of the Edit IPS Sensor window or by going to the list window.

3. Under IPS Filters, select Add Filter.

4. Configure the filter that you require. Signatures matching all of the characteristics you specify in the filter will be included in the filter. Once finished, select Use Filters.

Severity refers to the level of threat posed by the attack. The options include Critical, High, Medium, Low, and Info.

Target refers to the type of device targeted by the attack. The options include Clients and Server.

OS refers to the Operating System affected by the attack. The options include BSD, Linux, MacOS, Other,

Solaris, and Windows.

5. Once you have selected the filters you wish to add, right-click the filters and choose an action for when a signature is triggered:

 

Action                      Description
Pass                          Select Pass to allow traffic to continue to its destination.

 

Note: to see what the default for a signature is, go to the IPS Signatures page and enable the column Action, then find the row with the signature name in it.
Block                         Select Block to drop traffic matching any the signatures included in the filter.
Reset                         Select Reset to reset the session whenever the signature is triggered. In the CLI this action is referred to as Reject.
Default                      Select Default to pass all traffic matching the signatures included in the filter, regard- less of their default setting.
Quarantine               The quarantine based on the attacker’s IP Address – Traffic from the Attacker’s IP address is refused until the expiration time from the trigger is reached. You may set the Quarantine Duration to any number of Days, Hours, or Minutes.
Packet Logging       Select to enable packet logging for the filter.

 

When you enable packet logging on a filter, the unit saves a copy of the packets that match any signatures included in the filter. The packets can be analyzed later.

 

For more information about packet filtering, see “Configuring packet logging options”.


6. Select Apply.

The filter is created and added to the filter list.

 

Adding Rate Based Signatures

These are a subset of the signatures that are found in the database that are normally set to monitor. This group of signatures is for vulnerabilities that are normally only considered a serious threat when the targeted connections come in multiples, a little like DoS attacks.

Adding a rate based signature is straight forward. Select the enable button in the Rate Based Signature table that corresponds with the desired signature.

 

Customized signatures

Customized signatures must be created before they can be added to the sensor. To get more details on customized signatures check the IPS Signatures chapter.

 

Updating predefined IPS signatures

The FortiGuard Service periodically updates the pre-defined signatures and adds new signatures to counter emerging threats as they appear.

To ensure that your system is providing the most protection available, these updates can be scheduled as often as on an hourly basis. To configure this feature, go to System > FortiGuard. Under AntiVirus & IPS Scanning, enable Schedule Updates. From here you can set the updates to occur on a consistent weekly, daily, or even hourly basis.

Because 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.

 

Viewing and searching predefined IPS signatures

Go to Security Profiles > Intrusion Protection. Select [View IPS Signatures] to view the list of existing IPS signatures. You may find signatures by paging manually through the list, apply filters, or by using the search field.

 

Searching manually

Signatures are displayed in a paged list, with 50 signatures per page. The bottom of the screen shows the current page and the total number of pages. You can enter a page number and press enter, to skip directly to that page. Previous Page and Next Page buttons move you through the list, one page at a time. The First Page and Last Page button take you to the beginning or end of the list.

 

Searching CVE-IDs

A CVE–ID column displaying CVE-IDs can be optionally added to the IPS Signatures list, however the column is only available if the IPS package contains CVE-IDs for signatures. CVE-IDs can be numerically filtered by selecting the CVE-ID column’s arrows.

 

Applying filters

You can enter criteria for one of more columns, and only the signatures matching all the conditions you specify will be listed.

 

To apply filters

1. Go to Security Profiles > Intrusion Protection. Select [View IPS Signatures] .

2. Select column by which to filter.

3. Select the funnel/filter icon and enter the value or values to filter by.

4. Use additional columns as needed to refine search.

The available options vary by column. For example, Enable allows you to choose between two options, while OS has multiple options, and you may select multiple items together. Filtering by name allows you to enter a text string and all signature names containing the string will be displayed.

IPS concepts

Leave a reply

IPS concepts

The FortiGate Intrusion Protection System (IPS) protects your network from outside attacks. Your FortiGate unit has two techniques to deal with these attacks: anomaly- and signature-based defense.

 

Anomaly–based defense

Anomaly-based defense is used when network traffic itself is used as a weapon. A host can be flooded with far more traffic than it can handle, making the host inaccessible. The most common example is the denial of service (DoS) attack, in which an attacker directs a large number of computers to attempt normal access of the target system. If enough access attempts are made, the target is overwhelmed and unable to service genuine users. The attacker does not gain access to the target system, but it is not accessible to anyone else.

The FortiGate DoS feature will block traffic above a certain threshold from the attacker and allow connections from other legitimate users. The DoS policy configuration can be found in the Firewall Handbook.

 

Access control lists in DoS Policies

This feature allows you to define a list of IPs/subnets/ranges in a DoS policy, and block those IPs from sending any traffic, by way of an ACL (access control list). The ACL looks similar to a firewall policy, but only checks source IP, destination IP, destination port, and protocol.

 

Syntax

config firewall acl edit 1

set interface “port1”

set srcaddr “google-drive” set dstaddr “all”

set service “ALL” next

end

 

Signature-based defense

Signature-based defense is used against known attacks or vulnerability exploits. These often involve an attacker attempting to gain access to your network. The attacker must communicate with the host in an attempt to gain access and this communication will include particular commands or sequences of commands and variables. The IPS signatures include these command sequences, allowing the FortiGate unit to detect and stop the attack.

 

Signatures

IPS signatures are the basis of signature-based intrusion protection. Every attack can be reduced to a particular string of commands or a sequence of commands and variables. Signatures include this information so your FortiGate unit knows what to look for in network traffic.

Signatures also include characteristics about the attack they describe. These characteristics include the network protocol in which the attack will appear, the vulnerable operating system, and the vulnerable application.

To view the complete list of signatures, go to Security Profiles > Intrusion Protection, and select View IPS Signatures. This will include the predefined signatures and any custom signatures that you may have created.

 

Protocol decoders

Before examining network traffic for attacks, the IPS engine uses protocol decoders to identify each protocol appearing in the traffic. Attacks are protocol-specific, so your FortiGate unit conserves resources by looking for attacks only in the protocols used to transmit them. For example, the FortiGate unit will only examine HTTP traffic for the presence of a signature describing an HTTP attack.

 

IPS engine

Once the protocol decoders separate the network traffic by protocol, the IPS engine examines the network traffic for the attack signatures.

 

IPS sensors

The IPS engine does not examine network traffic for all signatures. You must first create an IPS sensor and specify which signatures are included. Add signatures to sensors individually using signature entries, or in groups using IPS filters.

To view the IPS sensors, go to Security Profiles > Intrusion Protection.

There is a disabled group of industrial signatures. This category is disabled by default, however it can be applied through use of the CLI command below. Note that none will mean no signatures are excluded, and that industrial will exclude all industrial signatures.

 

CLI Syntax

config ips global

set exclude-signatures [none | industrial]

end

 

IPS filters

IPS sensors contain one or more IPS filters. A filter is a collection of signature attributes that you specify. The signatures that have all of the attributes specified in a filter are included in the IPS filter.

For example, if your FortiGate unit protects a Linux server running the Apache web server software, you could create a new filter to protect it. By setting OS to Linux, and Application to Apache, the filter will include only the signatures that apply to both Linux and Apache. If you wanted to scan for all the Linux signatures and all the Apache signatures, you would create two filters, one for each.

To view the filters in an IPS sensor, go to Security Profiles > Intrusion Protection, select the IPS sensor containing the filters you want to view, and select Edit.

 

Custom/predefined signature entries

Signature entries allow you to add an individual custom or predefined IPS signature. If you need only one signature, adding a signature entry to an IPS sensor is the easiest way. Signature entries are also the only way to include custom signatures in an IPS sensor.

Another use for signature entries are to change the settings of individual signatures that are already included in a filter within the same IPS sensor. Add a signature entry with the required settings above the filter, and the signature entry will take priority.

 

Policies

To use an IPS sensor, you must select it in a security policy or an interface policy. An IPS sensor that it not selected in a policy will have no effect on network traffic.

IPS is most often configured as part of a security policy. Unless stated otherwise, discussion of IPS sensor use will be in regards to firewall policies in this document.

 

Session timers for IPS sessions

A session-ttl (time to live) timer for IPS sessions is available to reduce synchronization problems between the FortiOS Kernel and IPS, and to reduce IPS memory usage. The timeout values can be customized.