You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
You can take action to intercept suspicious requests, such as by blocking requests or by flagging them for special handling within your API proxies. You can also take action to expressly allow requests from specific IP addresses.
How actions work
In the Apigee Sense console, you can take action to explicitly allow, block, or flag requests from specific clients. Apigee Edge applies these actions to requests before your API proxies process them. Typically, you'll take action either because requests conform to patterns of unwanted behavior or (in the case of the Allow action) because you want to exclude a client from existing prohibitive actions you've taken.
To discover which requests to take action on, you use the detection report (in the Apigee Sense console, click the Detection menu, then Report) to identify request behaviors that you want to block or flag. For example, the detection report might list show that a set of requests exhibit the Brute Guessor behavior. You can take action to block requests from those IP addresses.
You can take the following types of actions.
| Action | Description | Precedence order |
|---|---|---|
| Allow | Allow requests in the selected category to proceed. You might take the Allow action to explicitly permit requests from specific client IP addresses despite other actions that could impact the IP address. For example, you might want to permit an internal or partner client IP's requests despite their conforming to an "unwanted" behavior. | 1 |
| Block | Block requests in the selected category. When you choose to block requests completely, Apigee Edge responds to the client with a 403 status code. | 2 |
| Flag | Flag requests in the selected category so that you can take action on them within API proxy code. When you flag a client's requests, Apigee Edge adds to the request an X-SENSE-BOT-DETECTED header with a value of SENSE. Your API proxy can respond based on this header's presence, such as to send particular response to the client. |
3 |
Precedence order for Apigee Sense actions
Apigee Sense applies actions in precedence order, from Allow to Block to Flag. For example, if a given IP address has both an Allow and a Block action enabled for it, Apigee Sense will apply the Allow action and ignore the Block action.
Apigee Sense enforces a precedence order because you can apply multiple actions to an IP address without realizing it. That's because you're usually taking action on a behavior -- such as to block brute guessors -- that has many IP addresses associated with it. When you later take another action on a single IP -- such as by singling out a friendly IP address to allow -- both the behavior-applied action and single IP-applied actions are enabled for the IP. Yet only the action with the highest precedence is enforced for requests from a given IP address.
So although actions of all three types could be enabled for a IP address, the Allow action would take precedence over a Block or Flag action.
Identifying requests and clients to take action on
In the Apigee Sense console, you can filter and group suspicious clients by their origin and by the reason they are suspicious. Once you've isolated the group you want, you can take action on IPs in that group, such as to block them.
You can filter suspicious clients by the following partitions:
| Partition | Description |
|---|---|
| Single bot reason | The reason a request is suspicious. See more about reasons below. |
| Bot reason group | A set of reasons associated with a single set of one or more IP addresses. For example, analysis might have identified four IP addresses whose requests matched the criteria for three reasons. |
| Country | The country from which the request originated. |
| Autonomous system organization | The AS organization from which the request came. |
Reasons
When analyzing API requests, Apigee Sense measures the requests using criteria that determine if request behavior is suspicious. If requests from the IP meet criteria that suggest a reason for suspicious activity, Apigee Sense reports this in its console.
The following table describes reasons that requests are identified as suspicious. In the portal, you can see the list of criteria and filter clients making suspicious requests by these reasons.
You can also customize the criteria according to the needs of your API usage. For more, see Customizing detection rules.
| Reason | Behavior Captured |
|---|---|
| Brute Guessor | Larger proportion of response errors during previous 24 hours |
| Content Quota Exceeder | Additional requests after 403 error due to content quota exceeded |
| Content Robber | Few OAuth sessions with large volume of traffic in a 5-minute window |
| Content Scraper | Large number of URIs called in a 5-minute window |
| Distinct OS | Multiple operating system families used in a 5-minute window |
| Distinct User Agent Family | Multiple user agent families used in a 5-minute window |
| Flooder | High proportion of traffic from IP in a 5-minute window |
| Guessor | Large number of response errors in a 5-minute window |
| Login Guessor | High volume of traffic to few URIs in 5-minute window |
| OAuth Abuser | High number of OAuth sessions with small number of user agents during previous 24 hours |
| OAuth Collector | High number of OAuth sessions with small number of user agent families during previous 24 hours |
| OAuth Harvestor | High number of OAuth sessions with significant traffic in a 5-minute window |
| Robot Abuser | Larger number of 403 rejection errors in past 24 hours |
| Short Session | High number of short OAuth sessions |
| Static Content Scraper | High proportion of response payload size from IP in a 5-minute window |
| Storm | Few high spikes in traffic in a 5-minute window |
| Tornado | Consistent spikes in traffic in a 5-minute window |
| Tor List Rule | IP originates from a TOR project and the IP triggers at least one other bot rule |