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
- Go to Security Profiles > Intrusion Protection > IPS Signatues.
- Select Create New to add a new custom signature.
- Enter a Name for the custom signature.
- Enter the Signature. For information about completing this field, see “Custom signature syntax and keywords”.
- 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 > IPS Signatues, select Create New and enter the data directly into the Signature field, following the guidance in the next topics.
T able 1 shows the valid characters and basic structure. For details about each keyword and its associated values, see “Custom signature keywor ds” on page 76.
Page 74
Table 1: Valid syntax for custom signatur e fields
| Field | Valid Characters | Usage |
| HEADER | F-SBID | The header for an attack definition signature. Each custom signature must begin with this header. |
| 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. See “Custom signature keywords” on page 76
for tables of supported keywords. |
| 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
Table 2: Information keywords
| Keyword and value | Description |
| –attack_id
<id_int>; |
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 <name_str>; | 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”; |
Table 3: Session keywords
| Keyword and value | Description |
| –flow
{from_client[,reversed] | from_server[,reversed] | bi_direction }; |
Specify the traffic direction and state to be inspected. They can be used for all IP traffic.
Example: –sr c_port 41523; –flow bi_direction; The signature checks traffic to and fr om 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 {HTTP |
T ELNET | FTP | DNS | S MTP | POP3 | IMAP | S NMP | RADIUS | LDAP | MSSQL | RPC | SIP | H 323 | NBSS | DCERPC | SSH | SSL}; |
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. |
Table 4: UDP header keywords
| Keyword and Value | Description |
| –dst_port
[!]{<port_int> | :<port_int> | <port_int>: | <port_int>:<port_int>}; |
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
[!]{<port_int> | |
Specify the source port number.
You can specify a single port or port range: |
| :<port_int> | <port_int>: |
<port_int>:<port_int>}; |
• <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. |
Table 5: ICMP keywords
| Keyword and Value | Usage |
| –icmp_code <code_int>; | Specify the ICMP code to match. |
| –icmp_id <id_int>; | Check for the specified ICMP ID value. |
| –icmp_seq <seq_int>; | Check for the specified ICMP sequence value. |
| –icmp_type <type_int>; | Specify the ICMP type to match. |
Table 6: Other keywor ds
| Keyword and Value | Description |
| –data_size {<size_int> |
<<size_int> | ><size_int> | <port_int><><port_int>}; |
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. • <size_int><><size_int> is a packet within the range between the specified sizes. |
| –data_at <offset_int>[, relative]; | Verify that the payload has data at a specified offset, optionally looking for data relative to the end of the previous content match. |
| –rate
<matches_int>,<time_int>; |
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 <app_int>[,
<ver_int> | *][, <proc_int> | *>]; |
Check for RPC application, version, and procedure numbers in SUNRPC CALL requests. The * wildcard can be used for version and procedure numbers. |
Table 6: Other keywords (continued)
| Keyword and Value | Description |
| –same_ip; | Check that the source and the destination have the same IP addresses. |
| –track {client | server}[,block_int]; | When used with –rate, this keyword narrows the custom signature rate totals to individual addresses.
• client has the FortiGate unit maintain a separate count of signature matches for each source address. • server has the FortiGate unit maintain a separate count of signature matches for each destination address. • 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 totalled 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. |
Hi,
Do you know if you can see a predefined IPS signature? what values it has…etc.
Never tried. Will have to do some digging on that. I have never even thought to look at what they have outside of signature names themselves.
Hi, Mike!
What you think about the description a signature example?
“The keywords distance and distance_abs indicate the minimum distance from the end of the last reference point to the beginning of the current pattern. The distance is counted from the next character after the last reference point. Both these keywords support negative range value. In this case, distance does not require the designated amount of data before the reference point while distance_abs does. For example, the following signature makes sure no ? character is before the /BBBB pattern in the URI:
–pattern “/BBBB”; –context uri; –within 200,context; –pattern!”?”; –context uri; –distance 200; –within 200;
This signature works even if the /BBBB pattern in the URI is not preceded by 200 bytes of data.”
It seems to me that there is an error in the description and signature. I also checked the signature and as a result it doesn’t work correctly.