Documentation · Letting our agent through your CDN · Azure Front Door

Allowing our agent through Azure Front Door

On Azure Front Door, our agent is let through with one WAF custom rule: it matches our addresses on SocketAddr and a User-Agent header that begins with our token, with the action Allow. Custom rules run before the managed rule sets, so the Bot Manager rule set does not see the requests it allows.

What to match

User agent starts with OttomAgent/
Source address is one of those in https://ottom.io/agent/ips.json

Match both, never the user agent alone: anyone can send our user agent, but only we send it from those addresses. The current addresses are also listed on our agent page.

What you need

Permission to edit the WAF policy linked to your Front Door profile.
The current addresses from https://ottom.io/agent/ips.json.
Bot Manager needs Front Door Premium. On Standard, custom rules work the same way.

Setting it up

1. Add a custom rule to the WAF policy
Open the WAF policy in the Azure portal, go to Custom rules and add one. Name it AllowOttomAgent, make it a match rule and give it a priority number lower than your other custom rules, such as 10.
2. Match our addresses
First condition: match type IP address, match variable SocketAddr, operation IP match, and each address from the file. Use SocketAddr, not RemoteAddr: RemoteAddr is usually read from the X-Forwarded-For header, which a client can set itself.
3. And our user agent
Add a second condition, joined with and: match variable RequestHeader, header name User-Agent, operator Begins with, and the value below.
```
OttomAgent/
```
4. Set the action to Allow and save
Choose Allow and save the policy. A request it allows is not evaluated by any lower priority rule, including the managed rule sets.

Checking it works

Run a scan of your store from your Ottom dashboard. When the rule works, the report has no bot protection finding and the agent reaches your products. In the WAF logs for the profile, our requests show AllowOttomAgent as the rule that matched, with the action Allow.

When a scan is still blocked

Still blocked during a traffic spike
The HTTP DDoS rule set runs before custom rules, and an Allow does not bypass it. If a scan is refused while it is acting, run the scan again once traffic is normal.
The rule never matches
Check the first condition uses SocketAddr and that the policy is linked to the Front Door endpoint that serves your store.

Good to know

Custom rules are evaluated in priority order, lowest number first, and before the managed rule sets.

Azure Front Door documentation

Menus move. If a name here no longer matches your dashboard, these are the pages we checked this guide against:

Questions

Does Allow switch off the Default Rule Set for us?

Yes, for the requests it matches. Azure runs custom rules before the managed rule sets and stops at an Allow, which is why the rule matches the address and the user agent together rather than either alone.

The same rule for other providers, and why it is safe: the CDN guides.