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's GUI, see Custom Application & IPS Signatures.
- 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:
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
--namekeyword 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
--patternkeyword 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
--servicekeyword 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.
--protocol tcp keywordto 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.
--no_casekeyword to make the pattern matching case insensitive.
F-SBID( --name "Block.example.com"; --pattern "example.com"; ‑‑service HTTP; --protocol tcp; --no_case; )
Unlike all of the other keywords in this example, the
--no_casekeyword has no value. Only the keyword is required.
- Limit pattern scans to only traffic sent from the client
--flowcommand 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; --protocol tcp; --no_case; ‑‑flow from_client; )
Web servers do not contact clients until clients first open a communication session. Therefore, using the
--flow from_clientcommand 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 hostkeyword/value pair.
F-SBID( --name "Block.example.com"; ‑‑pattern "example.com"; ‑‑service HTTP; --no_case; ‑‑flow from_client; ‑‑context host; )