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 signatur e” on page 74.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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”; –p attern “example.com”;
–service HTTP; –no_case; –f low 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.
- 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”; –p attern “example.com”;
–service HTTP; –no_case; –f low from_client;
— context host; )
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 signatur e” on page 74.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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”;
–s ervice SMTP; –no_case; )
Unlike all of the other keywords in this example, the –no_case keyword has no value. Only the keyword is required.
- 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”;
–s ervice SMTP; –no_case; –context header; )
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.