Imperva Bot Protection and Carrier IPs

Imperva, now part of Thales, runs one of the older cloud web application firewalls, and its Advanced Bot Protection grew out of the Distil Networks acquisition. Automation builders meet it on banks, insurers, airlines, government portals and retailers, often recognizing it by an Incapsula incident ID on a block page or by cookies starting with visid_incap and incap_ses. This page breaks down the layers Imperva applies, the single layer a dedicated NeonProxies carrier line touches, and the practices that keep research and monitoring jobs within bounds.

WAF rules and bot rules are separate questions

Imperva asks two questions of each request. The WAF asks whether the request is an attack: injection strings, malformed headers, known exploit paths. The bot layer asks whether the client is automated and whether that automation is welcome. Confusing the two wastes debugging time. A scraper that sends a query parameter containing quotes or angle brackets can trip a WAF rule and receive a block that has nothing to do with bot scoring, while a perfectly formed request can still be classified as a bad bot.

On the bot side, Imperva classifies clients into good bots such as search crawlers, bad bots, and humans, using a client-side challenge script, browser and device fingerprinting, cookie behavior, request rate and reputation data drawn from traffic across its network. Site owners pick actions per category and per path: allow, require a JavaScript or CAPTCHA challenge, or block.

One signal a mobile line improves

Imperva's reputation data does penalize some addresses up front. Cloud hosting ranges, anonymizers and addresses that recently attacked other Imperva customers enter with a mark against them. A NeonProxies line exits from a mobile carrier range where carrier-grade NAT places many real subscribers behind each address, and the line is dedicated, so it does not inherit someone else's attack history.

That is the whole of its contribution. The challenge script still inspects your browser. Cookies still need to persist the way a normal visitor's do. The rate and path of your requests are still compared with human visits. A mobile address paired with a client that discards visid_incap on every request will look like a bot that happens to be on a phone network.

Practical rules for Imperva-protected targets

Imperva customers in finance and government often forbid automated access to account areas outright, and many offer official APIs or data services for the purpose instead. Checking what the terms allow is part of the build, not an afterthought. For public pages such as rate tables, branch information or published notices, a slow scheduled job that behaves like a patient reader is usually fine.

• Encode query parameters properly so WAF rules have nothing to object to.
• Keep cookies across requests and across runs for each worker profile.
• Use a real browser where the site relies on its challenge script.
• Keep financial and government portals to the actions you are authorized to perform.
• Log incident IDs and stop, rather than rotating the IP and retrying.

Testing your own Imperva policy

If your organization runs Imperva, a carrier line in a customer metro is a useful probe. Walk your key journeys from a real US mobile address and compare the classification and actions in the Imperva console with a run from a cloud server. If mobile visitors are being challenged on routes where they should not be, you have found a rule that punishes your own customers before any of them complained about it.

Repeat the test on more than one carrier. AT&T, T-Mobile and Verizon ranges carry different histories in reputation feeds, and a policy that treats one carrier kindly can still be harsh on another. Because moving a NeonProxies line between our US metros is free and self-service, a small team can sample New York, Houston and Los Angeles visitors in a single afternoon and hand the security team concrete incident IDs rather than anecdotes from support tickets.

Reading an Imperva block page

The block page usually shows an incident ID and your client IP. Save both, along with the full request that triggered it. If a normal browser on the same line loads the page and your worker does not, compare their headers, cookies and TLS client side by side; the difference is almost always there. If both are blocked, the rule may target the path or the region, and the right next step is to ask the site owner rather than to vary the request until something gets through.

Setting up a Imperva proxy on NeonProxies

1. Choose a line on a carrier and metro typical of your target's visitors.
2. Configure it in a browser profile that retains cookies between runs.
3. Validate and encode every parameter your job sends.
4. Load one page manually through the line to confirm normal access.
5. Run on a slow schedule and record incident IDs for any block.
6. Pause the worker and review whenever a block appears.

Imperva proxy questions