How Kademi’s Global IDP Policy Helps Protect Your Website

When you run a partner portal, customer website, or incentive program, you need people to access it reliably. You also need to manage requests that have no legitimate reason to reach your application, from automated vulnerability probes to excessive login activity.

The challenge is deciding what to allow, what to block, and when repeated activity should trigger a response. An individual request may reveal a recognizable attack pattern. 

Other concerns only become apparent when you look at activity over time.

Kademi’s Intrusion Detection and Prevention (IDP) framework supports those decisions through rules that check incoming requests and take action when a condition matches. Its global policy provides a shared baseline of the controls in Kademi.

For a technical decision-maker, understanding that baseline helps answer a practical question: which requirements are already covered, and which need additional configuration?

What is Kademi’s global IDP policy?

IDP is an application-level request-filtering engine built into Kademi. It evaluates requests early in their lifecycle, allowing a matching request to be blocked before it reaches the application functionality it is trying to access.

Each rule has two parts: a condition to check and an action to take.

The condition might concern an IP address, a requested path, information submitted with a request, or the volume of particular activity within a rolling time window. Depending on the rule, the response can include allowing the request, rejecting it, logging the event, or adding the source IP to a blocklist.

Kademi uses two policy levels. The global policy is administered by Kademi and applies across clients on the relevant cluster. Most clients use this shared default. A website-level policy allows additional rules to address the requirements of a particular site.

This article focuses on the global policy. The wider framework supports more capabilities than those included in the shared baseline. To explore what can be configured for an individual website, see our guide on Tailoring Website Security with Kademi’s Custom IDP Rules.

It also has a specific place in your security architecture. IDP makes decisions within the application; it does not replace a general-purpose network firewall or Web Application Firewall (WAF).

What protection does the global policy provide?

The policy combines checks for recognizable request patterns and activity that exceeds specified thresholds. These checks run in order, beginning with the sources explicitly allowed through.

Allowing trusted operational traffic

Your website may receive legitimate automated requests from uptime monitors and authorized security scanners. These services need to perform their work without being caught by rules intended to reject suspicious activity.

The global policy therefore starts with allow rules for configured trusted IP addresses and specified network ranges. These include Kademi’s security scanner, uptime-monitoring ranges, and the cluster’s own IPv6 range.

When a request matches one of these rules, it proceeds without being checked against later IDP rules. This is an exception within the request filter. The application’s normal authentication and permissions still apply.

Blocking requests from previously flagged IPs

Rejecting one suspicious request may not be enough if the same source immediately sends another.

Several global rules address this by adding the source IP to a blocklist when a request matches. Later requests from that address can then be rejected by the blocklist rule, even if they do not repeat the original pattern.

For example, an IP that triggers a vulnerability-probe rule can be added to the list. A subsequent request from that source does not have to contain the same probe to be blocked.

The list is populated automatically during operation and retained while the policy remains cached. Several blocking rules also exclude Kademi’s own cluster IP addresses from automatic blocklisting, providing a safeguard against internal traffic triggering those actions.

Checking for a known Log4Shell-related signature

Some requests can be identified through a recognizable pattern in the information they carry.

The global policy includes checks for a particular Log4Shell-related signature in two places: request headers and submitted form parameters. Headers carry information accompanying a request, while form parameters contain submitted values.

A match triggers blocking, IP blocklisting, and logging. Checking both locations covers the specified pattern whether it arrives in a header or a form submission.

The scope is targeted: these rules detect a particular signature in those parts of the request. They do not establish comprehensive coverage of every exploit variation.

Responding to excessive authentication-related activity

Other concerns emerge through repetition. A source generating a large volume of errors—or making an unusually high number of successful logins—may require a response even when a single request does not match an attack signature.

The global policy includes two separate rules:

• Error-response threshold: More than 1,000 responses with status 400 or 403 from one IP within 10 minutes triggers an IP blocklist action. These are Bad Request and Forbidden responses.

• Successful-login threshold: More than 40 successful login POST requests from one IP within one minute also triggers an IP blocklist action.

Why check successful logins? Valid credentials do not, by themselves, make a high volume of automated login activity appropriate. The second rule addresses that activity separately from error responses.

The first counter also needs to be understood accurately. It measures responses with the specified status codes, rather than simply counting incorrect passwords.

Both controls operate at the source-IP level. Locking an individual account after repeated failed login attempts is a separate requirement that can be addressed through custom rules.

Rejecting common vulnerability probes

Automated scanners often look for weaknesses by requesting paths associated with particular applications or technologies.

Kademi’s global policy checks for several of these patterns, including PHP files, WordPress login paths, and PHP information pages. Kademi is not a PHP or WordPress application, so the policy treats matching requests as probes and can add their source IPs to the blocklist.

Specific host-and-path combinations can be exempted from the PHP-probe rule where an exception has been configured.

Other checks cover listed exploit-related paths and script-tag patterns in the request path. These provide targeted filtering for those patterns, including certain attempted cross-site scripting inputs; they are not a general claim that every form of malicious input will be detected.

There is also a specific endpoint restriction. Requests for /omni-search are blocked outside permitted Kademi admin hosts, limiting where that endpoint can be accessed.

What happens when a rule matches?

The response depends on the rule. Some allow traffic through. Others reject a request, and several also affect how later requests from the same source are handled.

Consider a request that matches a vulnerability-probe rule. The rule can:

1. Add the source IP to the blocklist.

2. Return a 403 Forbidden response.

3. Stop the request.

4. Record the event in the IDP request log.

That combines an immediate response with a way to reject subsequent traffic from the source.

Not every blocking rule takes all four actions. The /omni-search restriction blocks and logs matching requests without adding the source IP to the blocklist. The existing-IP rule rejects requests from addresses already listed.

This matters when your team reviews an incident or investigates a rejected request. A 403 response does not, on its own, tell you that the source has been blocklisted. The rule that matched determines the action taken and whether the event was logged.

Adaptive rate limiting when enabled

The controls above respond to particular request patterns or activity thresholds. The global policy also includes an optional control that responds to server performance: adaptive rate limiting.

These rules operate only when enabled in the environment.

The limiter uses request-volume and average-response-time measurements to adjust the permitted request rate. When responses are fast, the allowed rate can be higher. As responses slow, the permitted rate decreases.

This allows the traffic ceiling to change with measured performance rather than remaining fixed regardless of how the server is responding.

Requests exceeding the permitted rate receive 429 Too Many Requests. For assets and API requests covered by the limiter, processing stops with the rate-limit response and no-cache headers. Covered HTML page requests receive a friendly explanatory page.

A rate-limit response is different from an IP blocklist action. These adaptive rules restrict requests that exceed the permitted rate; they do not themselves add the source IP to the blocklist.

If this control is important to your operational requirements, confirm whether it is enabled. Its inclusion in the policy template does not mean it is active in every deployment.

Where the shared policy ends

The global policy provides a defined baseline, but your website may need controls beyond it.

Country-based blocking, impossible-travel checks, and cloud-provider or datacentre IP blocking are not included as standard in the supplied global policy. The source identifies these separately as candidates for further standardization.

The wider IDP framework also provides components for requirements such as account lockouts, authenticated group checks, and administrator notifications. Their availability should not be confused with being enabled in your shared policy.

Website-level rules provide a way to address additional requirements. You might need to restrict access to a particular path, respond differently to repeated account failures, or notify an administrator when a sensitive request occurs. Those choices should reflect how your website is used, including legitimate automated services and users connecting through shared networks or VPNs.

The companion article on custom IDP rules explores these possibilities in more detail.

Reviewing your requirements with Kademi

Understanding the global policy gives your team a clear starting point. You can see how approved traffic is handled, which request patterns are checked, what activity triggers IP blocking, and where optional rate limiting fits.

The next step is to compare that coverage with your website’s needs.

Ask the Kademi team to confirm the policy active in your environment, whether adaptive rate limiting is enabled, and which requirements would benefit from website-level rules. That turns a broad security discussion into specific decisions about the controls your program needs.