Allowing IOCCheckBot

If IOC Site Check reported that it could not reach your site, a security layer in front of your server most likely blocked the request before it arrived. This page explains how to let IOCCheckBot through.

You do not have to. The check is optional, and blocking it has no effect on anything else. This page exists because “we could not reach your site” is not a useful answer on its own.

What you are allowing

All crawl traffic comes from that single address. Its reverse DNS resolves to checkbot.ioclabsco.com, and that hostname resolves forward to the same address, so you can verify any request claiming to be us without trusting the user-agent string.

IOCCheckBot also signs its requests using Web Bot Auth (RFC 9421 HTTP Message Signatures, Ed25519). The Signature-Agent value is https://ioclabsco.com and our public keys are at https://ioclabsco.com/.well-known/http-message-signatures-directory.

What it does while it is there: fetches at most 10 pages, one request per second, follows robots.txt including crawl-delay, submits no forms, logs into nothing, and stops on 403 rather than retrying. Full behaviour is documented at /bot.

Start with robots.txt

Before changing anything in a firewall, check robots.txt. If it disallows IOCCheckBot or blocks all crawlers, we stop there and never reach your security layer at all — and no allowlist rule will change that.

User-agent: IOCCheckBot
Allow: /

Cloudflare

Cloudflare’s managed bot rules and Bot Fight Mode challenge unrecognised crawlers, which is the most common reason a check fails on sites in this region.

Create a WAF custom rule that skips bot protection when the source IP matches 169.58.231.36. Match on the IP rather than the user-agent — user-agent strings can be forged by anyone, the IP cannot.

Imperva

Imperva (formerly Incapsula) ships a predefined Good Bots list, and IOCCheckBot is not on it. There is no way for us to apply to be added; the list is curated by Imperva. It has to be done from your side.

In your site’s bot access control settings, add IOCCheckBot to the good bots list, or create an allowlist rule for 169.58.231.36. The exact menu names differ between Cloud WAF versions — if you cannot find them, Imperva support can add a client application rule for you.

Akamai

In Bot Manager, add IOCCheckBot as a custom-defined bot, matching on the IOCCheckBot token in the user-agent combined with the source IP, and set the action for that category to allow.

Fastly

If you run a custom VCL or a Next-Gen WAF rule that blocks non-browser user-agents, add an exception for the IP above.

Sucuri and ModSecurity

Both allow IP-based allowlisting. Add 169.58.231.36 to the trusted or whitelisted address list.

Your own server

If nothing sits in front of your site, the block is local:

• iptables or ufw rules that deny data-centre ranges
• fail2ban, which may have banned the address after repeated requests
• .htaccess or nginx rules denying non-browser user-agents
• rate limiting that treats one request per second as abuse

Check your access log for IOCCheckBot first. If the requests appear with a 403 or 429, the block is yours. If they do not appear at all, it is upstream.

Shared hosting

On shared hosting you may not be able to edit firewall rules at all. Your hosting provider can add the address for you, or can tell you whether their platform-level protection is what refused the request.

Checking whether it worked

Run the check again at /check. If it still fails, the block is at a layer above the one you changed — a CDN in front of a WAF in front of a server means three places to look.

If we are the problem

If IOCCheckBot is causing load, hitting pages it should not, or ignoring your robots.txt, write to abuse@ioclabsco.com with the timestamp and the affected URLs. We answer requests to slow down or stop crawling, and you do not need an account with us to send one.