Requests from Slack blocked by Bot Fight Mode

Website, Application, Performance Security
1

Requests from user agent “Slackbot 1.0 (+https://api.slack.com/robots)” used to pass perfectly fine through Bot Fight Mode, seen last working on May 24, 2023. Sometime between then and May 28th, Bot Fight Mode started returning Managed Challenges to POSTs from the Slackbot agent. This is a problem for those of us who host Slack applications behind Cloudflare that rely on user interactivity from Slack users (button presses and whatnot, that get sent to the Slack app as Slackbot agent POSTs).

I cannot contact CF support without a business plan, so posting here to see what can be done.

{
  "action": "managed_challenge",
  "clientASNDescription": "AMAZON-AES",
  "clientAsn": "14618",
  "clientCountryName": "US",
  "clientIP": "3.237.182.157",
  "clientRequestHTTPHost": "redacted",
  "clientRequestHTTPMethodName": "POST",
  "clientRequestHTTPProtocol": "HTTP/1.1",
  "clientRequestPath": "/api/slack/interactivityshortcuts/",
  "clientRequestQuery": "",
  "datetime": "2023-06-01T16:28:03Z",
  "rayName": "7d08d3d7c9478009",
  "ruleId": "bot_fight_mode",
  "rulesetId": "",
  "source": "botFight",
  "userAgent": "Slackbot 1.0 (+https://api.slack.com/robots)",
  "matchIndex": 0,
  "metadata": [],
  "sampleInterval": 1
}
4

What a coincidence this post was made today because we just got told by support this morning the following:

We have an update from our engineering team, they have confirmed this as a known issue as the IPs Slack’s bots use rotate sometimes. When a new IP comes into play, it takes some time for it to make enough requests for our ML validator to pick it up as a verified bot based on the activity. Currently, we don’t have any ETA on priority of better solution. It would be easier if Slackbot provides more reliable method for verification public list or rDNS:
https://developers.cloudflare.com/bots/reference/verified-bots-policy#ip-validation
Is it possible for you to request Slackbot to implement better verification method so its easy for us to identify the requests from them as verified bots when they rotate the IPs.

We’re having a problem with links not unfurling in our company slack if they contain our company domain name because the bot ML is marking them as a score of 1 which we have an explicit deny on.

image
image2272×1160 130 KB

Slack support responded with the following to the above request

Our servers are reassigned IPs dynamically within our hosting environment, provided by AWS so the range of possible IPs is very, very large. If you’d like, you can get the full list of possible IP addresses here - http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html. Slack’s servers currently reside in the us-east-1 region.

Instead, we ask that you allow all requests from Slack, and validate that inbound callbacks to your servers are truly coming from Slack by using the process outlined on this page:

https://api.slack.com/docs/verifying-requests-from-slack

We kind of have a workaround but it requires us making a possibly insecure change to our WAF rules which we’d rather not do. We’d like to just have the traffic classified correctly.

1 Like
5

Dang, unfortunate that Slack can’t provide an IP list / rDNS, but I appreciate the relayed support responses

6

I have this problem too. Is there already a solution to this problem other than adding an AWS IP range?

7

I’m also having the same issue. It looks like the only solution is to create a WAF IP Access Rule for all of AWS east region which is insecure. It’s unfortunate that custom WAF rules won’t work…

8

Here is a good writeup explaining the issue in more detail

1 Like
9

I tested today and everything is working as it did before.

1 Like
10

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.