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.