Each Security Configuration contains a policy that defines how your application handles incoming requests, and contains protections that enforce those controls.

When you create a Security Configuration in App & API Protector Hybrid, a default policy is created automatically. You can modify this policy to adjust how protections are applied to your application traffic.

Protections are individual controls within a policy. They apply specific rules and response actions, such as web application firewall behavior or custom protection rules. When you open your Security Configuration, you can access these protections from the menu on the left side of your screen. Read on to learn how to configure, apply, and adjust them:

Protect against web application attacks

Web Application Firewall protections perform rule-based evaluation of requests to either deny a request or trigger an alert. These rules focus on request behavior and traits. They defend against multiple known attack vectors and flag suspicious behavior, like protocol violations, HTTP policy violations, cross-site scripting attacks, injection attacks, and more.

Akamai's Web Application Firewall protection engine delivers advances that help you protect your websites with less effort and greater accuracy. Features include:

Flexibility for different management styles. Depending upon your product and experience, you can switch easily between two modes of web application firewall management:
- Automatic (recommended) updates itself so you always have the latest protections to face emerging threats. This is the easiest way to keep robust protections in place with the least administrative effort.
  👍
  Akamai conducts thorough advance and continuous testing of new rules. Rely on our monitoring and automation instead of scattershot manual efforts.
- Manual requires you to manually install new rule versions to stay up-to-date.

When you apply web application firewall protections as part of your security policy, the policy uses rules to examine specific requests and determine what, if any, action to take. Because our network handles about one third of the world's web traffic, it has unique insight into traffic patterns and request behavior. Our Security Research team leverages insights and data to improve rules and create new ones based on the latest threats.

Rules fall into attack groups which focus on individual attack vectors, like SQL injection, cross-site scripting, trojans, and more. You can specify defensive action by an attack group, and take advantage of our web application firewall engine's dynamic risk assessment.

How risk scoring works

When you scroll through the rules on your Web Application Firewall list, you see that their action is preset to Risk scoring. That's a misleadingly simple label for all the hard work the protection engine does. When evaluating a request, each rule runs and contributes a score up to its group. The whole group's tabulated score determines whether or not to apply the response action.

👍
In addition to the risk score by group, threat intelligence rules also evaluate a request. These rules detect suspicious request traits that fall outside regular web application firewall rules. These detections also contribute to scoring and taken together with web application firewall rule scores can help trigger a response action.

The risk-scoring system works well because it gathers lots of data. Armed with intelligence from multiple points along an entire attack vector, the group-level evaluation can make a broadly informed assessment of whether or not a request poses a threat.

How you can handle risk score intelligence, depends on how you're managing your Web Application Firewall:

Rule violations within an attack group combine to calculate an automatically-generated risk score for the group, which the engine uses to decide when to apply the assigned action. You also can set action by individual rules if you want. Say there's a rule you always want to enforce with a Deny action. When you do so, any request that violates that rule will be blocked, and evaluation of the request by additional rules halts.

👍
The proverb "Two heads are better than one." applies to Web Application Firewall rules as well. In some cases you may wish to have individual rules trigger actions, but when all the rules for an attack vector work together, their intelligence and effectiveness is enhanced. For this reason, try to apply action by group, leaving individual rules in risk-scoring. Or better yet, consider using automatic mode to not only set protections by group, but have them update themselves as needed.

Custom Rules

Use Custom Rules to handle scenarios not covered by standard rules or to quickly patch new website vulnerabilities.

The Custom Rule builder lets you alert on or deny requests based on parameters like:

hostname
request method
path
extension
filename
protocol version
request header
request header order
cookie
query string
request body parameter
request body parameter name

Custom Rules are a handy way to cover unusual situations. For example, say that your website creation software provider notifies you of a newly discovered vulnerability they plan to patch in an upcoming release. In the meantime, you could create a Custom Rule that protects your site from the problem.

👍
Custom Rules are version-level resources. It means that each Security Configuration version has its own set of Custom Rules.

You can't customize a rule that exists in the Web Application Firewall rule set. You can only create a new Custom Rule, and customize it to be similar and do what you wish.

Protect against denial-of-service attacks (DoS)

Distributed Denial of Service (DDoS) attacks attempt to bring down web content by overwhelming a website's origin server with bogus requests, often from multiple locations and networks. This attack traffic can result in slow page loads and even complete blockage of legitimate site traffic. App & API Protector Hybrid lets you configure your security policy to mitigate application-layer DoS attacks using rate limiting controls.

Rate limiting

Identify clients that send requests at an excessive rate.

To discover a security or application vulnerability, attackers often must send lots of HTTP requests. Rate Limiting Policies let you protect against excessive request rates like this and also against Denial of Service attacks by monitoring and controlling the rate of requests.

You create a Rate Limiting Policy and set rate controls in your Security Configuration. In the Rate Limiting Policy, you specify what to check, and in the rate controls you set the response action you want to take.

In your Rate Limiting Policy, you set the following two rate thresholds:

Burst threshold. The number of hits per second occurring within a one to five-second window.

👍
You can configure this timespan according to preference — however, for existing Rate Limiting Policies, proceed with caution and be careful not to reduce the measure window from 5 seconds without analyzing your traffic in Alert mode first.

Average threshold. The number of hits per second occurring within a two-minute window.

You can also set criteria for requests. For example, you could apply rate settings only to submission requests on your site's login page. The match criteria you set in your Rate Limiting Policy define the scope for initial request rate checks, which happen right away. It specifies which requests to tally and compare to your threshold settings. Violators are put in the penalty box for 10 minutes (if the action in your Rate Limiting Policy is set to Deny), where rate controls check for them.

You set rate controls within your Rate Limiting Policy. Controls let you specify the action to take on rate-violating clients.

👍
For rate controls, IPv4 addresses are identified using a /32 prefix, while IPv6 addresses use a default /64 prefix.

When a request comes in from a client currently in the penalty box, and it meets the match criteria for a Rate Limiting Policy, then the Deny action you specify in your rate control applies. The Deny action continues to apply to requests from that client for the next 10 minutes. After 10 minutes, the action deactivates until another request exceeds the threshold and reactivates it.

You can associate up to 10 Rate Limiting Policies with a Security Configuration. Consider using only 9 active Rate Limiting Policies to keep a free slot available in case of emergency.

Rate Limiting Policies are version-level resources, which means that if you roll back to an earlier Security Configuration version, these policies roll back too.

Control requests by IP or geographic location

Say you've been getting bothersome requests from a few specific IP addresses. Or maybe you want to block all traffic from The Onion Router (TOR), which hackers use to hide their identity. IP/Geo controls let you block or allow traffic coming from a specific IP, subnet, geographic area, or more.

The smartest way to specify IP clients or locations is using a Client List, rather than manually entering addresses, locations, or other identifiers in your security policy. You can make changes to the list without having to version, save, and activate a new Security Configuration. Also, you can share the same list across several security policies and Security Configurations. When you need to change an entry (be it an IP address, location, or ASN), you do so in only one place, and the update automatically flows to any policy that uses the list.

Open or edit the Security Configuration.
On the left side of the screen, select IP/Geo Firewall.
If this protection is off, turn it On.
Select the Mode:
1. Block specific IPs/subnets, geos, and ASNs. Protections block traffic from the IPs, subnets, geographies or Client Lists you specify.
2. Block all traffic, except from clients identified in Block exceptions. Protections block all incoming traffic by default. Only IPs, subnets, or Client Lists added to Block exceptions are allowed.
To block IPs and subnets, go to the IP Controls section and select the IP Client Lists you want to block.
To block geographic regions like countries and other areas, go to the Geo Controls section and select the Geo Client Lists you want to block.
To block Autonomous System Numbers (ASNs), go to the ASN controls section and select the ASN client lists you want to block.
To allow specific client lists despite existing blocks, go to the Block exceptions section and select the client list to allow.
👍
Block exceptions override IP/Geo/ASN blocking only. They do not bypass other security protections.
If an IP address or subnet appears in both a blocked Client List and the Block exceptions list, the request bypasses IP/Geo blocking and is allowed through. However, these requests are still evaluated by all other security protections you have enabled, such as DoS protection, Web Application Firewall, and other security rules.
If you need to manage requests from a geographic area in transition or in turmoil, click Geo controls for uncertain conditions. You can set these controls per security policy and choose an action, like Deny or Alert, for requests from a dedicated region.
When you’re done making all selections, click Save.

Client Lists

👍
See documentation here to learn about Client Lists — an improved and flexible way of grouping IPs, geo locations, ASNs, and more.

The best way to block or allow access by IP address or geographic location is to gather addresses in a Client List. Client Lists are collections of web request characteristics, based on which you can block or allow client access.

Client Lists are account-level resources, which means you can share them across multiple Security Configurations within an account, as well as across different security products. You create and edit lists on the Client Lists page. Then within a security policy, you block or allow a list. The beauty is that you can edit addresses within a Client List at any time, without having to edit and reactivate your Security Configuration.

Akamai creates and offers packaged Client Lists for you to use. These lists feature a wave icon beside their name and are usually collections of IP addresses around a common theme, like cloud service networks you may use. These lists are read-only, which means you can't edit them, but you can duplicate and edit your own copy.

You can also create your own custom Client Lists. For example, say you want to allow all your internal IP addresses and those belonging to your vendors. You'd collect them in a Client List and activate it. Then in a security policy, you'd use IP/Geo controls to allow all requests from that list.

In App & API Protector Hybrid, you can use Client Lists to control requests by IP, ASN, or geographic location in IP/Geo controls.

📘
While other list types (such as TLS fingerprints) can be created in the Client Lists app, IP, Geo, and ASN are currently the only criteria supported and enforced by App & API Protector Hybrid.

Create a Client List

To create, activate, and manage your Client Lists for App & API Protector Hybrid, visit Akamai Control Center and log in. Next, go to ☰ > WEB & DATA CENTER SECURITY > App & API Protector Hybrid. Go either to the App & API Protector Hybrid Security Configurations page or Connection Configurations. Click the dropdown next to the product name and select Client Lists.

Follow instructions available in the Client Lists user guide.