Bot signatures identify web robots by looking for specific patterns in the headers of incoming HTTP requests. DoS Layer 7 bot detection includes many signatures that identify bots, and you can also write your own for customized bot defense.
Bot signatures carefully identify bots and have a low rate of producing false positive results. The signatures identify the type of bot for classification and investigative purposes, and can distinguish between benign and malicious bots.
Benign bots can be useful for providing Internet services such as search engine bots, index crawlers, site monitors, and those used to establish availability and response time. Some environments may not want to block benign bot traffic. But attackers use malicious bots for more harmful purposes such as harvesting email addresses, producing spam, and developing exploitation tools. You may want to block malicious bots because they can orchestrate DoS attacks, waste internet resources, and search for vulnerabilities to exploit in your application.
Being able to classify bots allows you to treat them differently. You can report, block, or do nothing when a signature matches a malicious or benign bot. Further, malicious and benign bots fall into more specific bot signature categories that can be handled as needed. You can create new categories if needed for custom bot signatures.
|During Attacks||Checks all traffic during a DoS attack, and prevents detected attacks from escalating.|
|Always||Checks all traffic at all times, and prevents DoS attacks from starting.|
|Allow all requests||
Allows requests arriving to a non-HTML URL referred by a different domain and without a valid cookie if they pass a simple challenge. The system sends a challenge that tests basic browser capabilities, such as HTTP redirects and cookies.
|Allow configured domains; validate in bulk||Allows requests to other related internal or external domains that
are configured in this section, and validates the related domains in
advance. The requests to related site domains must include a valid
cookie from one of the site domains; the external domains are allowed if
they pass a simple challenge. Choose this option if your web site does
not use many domains, and then include them all in the lists
Also, if your website uses CORs, select this option and then specify the WebSocket domain in the Related Site Domains list.
|Allow configured domains; validate upon request||Allows requests to other related internal or external domains that are configured in this section. The requests to related site domains must include a valid cookie from the main domain; the external domains are allowed if they pass a simple challenge. Choose this option if your web site uses many domains, and include the main domain in the list below.|
If proactive bot detection is always running, ASM™ filters out bots before they manage to build up an attack on the system and cause damage. If using proactive bot defense only during attacks, once ASM detects a DoS attack, the system uses proactive bot defense for the duration of the attack.
Proactive bot defense is used together with the active mitigation methods specified in TPS- and stress-based detection. Any request that is not blocked by the active mitigation method still has to pass the proactive bot defense mechanism to be able to reach the server (unless it is on the URL whitelist). Proactive bot defense blocks requests to CORS (Cross-Origin Resource Sharing) URLs not on the URL whitelist.
Because this defense mechanism uses reverse lookup, you need to configure a DNS Server () and a DNS Resolver ( ) for it to work.
|None||Ignore requests in this category.|
|Report||Log requests in this category.|
|Block||Block and report requests in this category.|
These settings override the Proactive Bot Defense settings. For example, requests from bots in any category, if set to Block, are always blocked.