AS0 can bypass WAF rules?

[sageth]

For my account, I block at the ASN level in a lot of cases, especially for Hosting companies. I’ve recently added “AS0 -Reserved AS-” as a block rule in Security → WAF → Tools → IP Access Rules.

However, while other ASNs are blocked, it seems that AS0 is allowed to continue (fortunately, being blocked because of the UA they used).

I’m not sure if this is intended… I could see it being that the “real” ASN just hasn’t been updated yet at Cloudflare, which makes it appear to be a false positive — but I don’t know how to test that.

The requests came in for ~10 minutes, all from the same IP. Here’s an example event.

Is this a false positive, or a bug in the firewall?

{
  "action": "managed_challenge",
  "clientASNDescription": "-Reserved AS-",
  "clientAsn": "0",
  "clientCountryName": "US",
  "clientIP": "85.209.133.7",
  "clientRequestHTTPHost": "_redacted_",
  "clientRequestHTTPMethodName": "GET",
  "clientRequestHTTPProtocol": "HTTP/1.1",
  "clientRequestPath": "/",
  "clientRequestQuery": "",
  "datetime": "2024-05-06T21:46:12Z",
  "rayName": "87fc2966ab82426d",
  "ref": "",
  "ruleId": "2c7e0156945c4705bc16eb95023b9498",
  "rulesetId": "bcb4fb48da2341f9a1bc7ef63ee6a363",
  "source": "firewallCustom",
  "userAgent": "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36",
  "matchIndex": 0,
  "metadata": [
    {
      "key": "ruleset_version",
      "value": "335"
    },
    {
      "key": "version",
      "value": "29"
    },
    {
      "key": "type",
      "value": "customer"
    },
    {
      "key": "js_detection",
      "value": "MISSING"
    }
  ],
  "sampleInterval": 1
}

[eportillo]

Hello,

Can you please provide the zone in question that you are seeing these AS 0 Ip addresses? Also are you seeing these routinely for all zones you have? Was this just a one time case? Can you please provide more info and ip address, so we can take a look please?

For the mean time you can configure a rate limiting rule to challenge or query any traffic that may see malicious to your zone see below.

Rate limiting rules · Cloudflare Web Application Firewall (WAF) docs

[sageth]

Hi eportillo - thanks for responding.

Zone ID is removed by author

There were 16 events from AS0 on May 5, all showing a client IP of 85.209.133.39.
May 2nd showed one event from the same IP (Ray ID: 87d580f70c3e4219)
May 4th showed 28 events from IP 85.209.133.7 (example Ray ID: 87ebaf552e6243b2)
The last time I saw events from AS0 was on May 6th (this post), with 22 events.

I believe, as part of my own troubleshooting, I either deleted and re-added AS0 or changed to Managed Challenge and back to Block. I don’t know if this was a glitch that was corrected by my troubleshooting or if the events just stopped, but I don’t see any events from AS0 on this zone since May 6.

All have a user agent which is known to be malicious and which I have rules for, and I saw no evidence on my server logs that they got through.

Regarding other zones: I didn’t think to check there because I don’t have active servers, but I do have events there as well.

• Zone removed by author shows events on May 7 from client IP 195.26.241.51 (example Ray ID: 880202dfaeac7b0a). I did not go back further than seeing if there were events.
• I do not see any events from AS0 on my third domain/zone.

[peterdowney01]

I am also seeing some A0 connections pop up in my logs that are bypassing all of my normal protections but are triggering rate limiting.

• Ray ID

8837d7e48a3a61ed

FilterExclude

• IP address

92.118.57.194

• ASN

AS0 -Reserved AS-

• Country

United States

• User agent

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

[DarkDeviL]

@sageth

"clientIP": "85.209.133.7",

This IP address seems to be announced to the Internet by AS399486, and in the RIPE database (which the IP address is allocated from), a route object was created on 2024-04-24, which is just around 3 weeks old right now.

@sageth

There were 16 events from AS0 on May 5, all showing a client IP of 85.209.133.39.

@sageth

May 4th showed 28 events from IP 85.209.133.7 (example Ray ID: 87ebaf552e6243b2)

All those IP addresses are within 85.209.133.0/24 (85.209.133.0 - 85.209.133.255), which the route object from above (and the announcement to the Internet) covers.

@peterdowney01

92.118.57.194

This IP address seems to be announced to the Internet by AS40021, and in the RIPE database (which the IP address is allocated from), a route object was created on 2024-05-04 (and updated on 2024-05-06), which is just around 10 - 12 days old right now.

That route object covers 92.118.56.0/23 (92.118.56.0 - 92.118.57.255).

@sageth

Is this a false positive, or a bug in the firewall?

I think you should count this as a delay from things happening (e.g. from the time that the IP spaces are actually announced to the Internet), and until the data is up-to-date matching the reality.

According to Fields reference · Cloudflare Ruleset Engine docs the AS number is present in the field ip.src.asnum (which was previously called ip.geoip.asnum).

Based especially on the previous field name for the AS number (ip.geoip.asnum), that makes me believe that the AS number also originate from the MaxMind data set, just like it has previously been mentioned, that MaxMind is the source for e.g. country, city and other geographical location data.

In that case, the data for the AS numbers will depend on MaxMind to have the AS number updated for the IP address space in their data sets, as well as that Cloudflare have received an update of the MaxMind data that actually covers the “new reality”.

It is likely only a matter of time, before the AS numbers will adjust properly.

[sageth]

This information is good to know, though the question was not that AS0 showed up – it was around AS0 seemed to bypass at least a portion of the Cloudflare WAF, getting caught by firewall rules down the line.

As late as 2 days ago, I had a few events come in which Cloudflare is identifying the ASN as AS0 and also is letting them through to be caught by other rules.

I understand what you’re saying: Cloudflare is looking at the real IP space and it’s not really AS0 (obviously, since it’s reserved) – but then Cloudflare is doing one thing and displaying another.

If it’s known to be part of an IP space, then it should display that since Cloudflare is detecting it; If it is “unknown” and being calculated as AS0, then blocking AS0 should block it as intended. Even if it’s “working as designed” behind the scenes, the Cloudflare display to the customers is confusing.

Edit: I also checked and AS399486 is already in my rules and it didn’t block the ASN (likely since it’s detected as AS0), so it still seems to be a bug to me.

[DarkDeviL]

@sageth

I understand what you’re saying:

I still think something are misunderstood:

@sageth

If it’s known to be part of an IP space, then it should display that since Cloudflare is detecting it; If it is “unknown” and being calculated as AS0

It actually is unknown to Cloudflare, at the time being.

It is only just recently that Contabo and Virtuo started broadcasting these IP ranges to the global Internet.

@sageth

so it still seems to be a bug to me.

I understand why you may see it as a bug.

→

However, - if I may take another example:

Telephone directories, …

The telephone directory for the year 2024 is being printed from October 2023 and onwards, and expected to be completely by December 2023, so that it can be delivered to (the majority of) households across the country during December.

However, the middle of December 2023, you’re getting a new phone number, and/or moving to another house/apartment.

Since the middle of December 2023 is later than when the 2024 telephone directories were printed, your new phone number / address will NOT end up in the 2024 telephone directory.

It will however be possible for your data to end up in the 2025 telephone directory, that will be released next year.

@sageth

but then Cloudflare is doing one thing and displaying another.

Just like the 2024 telephone directory won’t know anything about you, in the above example, Cloudflare is currently unaware of which AS number that the mentioned IP addresses (more correct: corresponding IP spaces / IP ranges) belong to.

It will like the 2024 ↔ 2025 example just be a matter of time before e.g. AS0 will be replaced with AS399486, if that is (still) the reality, at the next update of the data set that is providing the IP space ↔ AS numbers information.

I highly doubt that it will take a year like the telephone directory example, but I would expect it to be able to take at least a month or two, for such data to propagate out.

@sageth

I also checked and AS399486 is already in my rules and it didn’t block the ASN (likely since it’s detected as AS0)

I would not say “likely” here, but go as far as to call it the actual reason.

It does sound to me like you’re trying to block these two AS numbers ( AS40021, AS399486), or, at least AS399486, which I fully understand given the “category” of these AS numbers.

Something in your wordings above makes it sound like you may have tried it already, … but just to be sure:

• Do you have AS0 in your filters?

• Does it block the traffic earlier (e.g. in your AS399486 rules), if you also add AS0 to the list of blocked AS numbers?

• What does your current (AS number) filter look like?

[sageth]

Yes, AS0 is in my filters (Security → Access → Tools → IP Access Rules for “all accounts”) and that’s not where it’s getting stopped.

For my AS rules – it’s moderately large with 134 ASN rules that apply to all accounts. AS0 is one of those rules, and that’s what I’m saying appears to be bypassed.

Regarding your phone book example: I understand that. Using the same analogy, based on my testing I believe either:

• Cloudflare is using the not-yet-published 2025 directory behind the scenes, but is only able to display the “official” 2024 copy to me (which makes it confusing), OR
• Since the 2025 directory isn’t yet published and the phone number 000-000-0000 isn’t technically a valid number, I’ve blocked it. However, if I get a call from 000-000-0000, it’s bypassing the operator/hub and directly calling my phone… meaning my phone is still ringing from a number that I’ve blocked.

I am tending to lean toward the latter – that it’s directly dialing my phone without going through the hub because I do filter both Alice’s non-existing 2024 phone number (000-000-0000) and the 2025 phone number that is known, but not published yet. Even though I’ve blocked both possibilities, my phone is still ringing.

Same thing here: I’ve blocked AS0 and also AS399486, which represents both possibilities, and it still seems to be getting to the filters that I don’t think it should be. This diagram from Cloudflare confirms that IP Access Rules come before WAF, meaning something is wrong because it shouldn’t be making it to WAF – it should be stopped at IP Access Rules.

Hope that helps clarify.

[DarkDeviL]

@sageth

AS0 is in my filters (Security → Access → Tools → IP Access Rules for “all accounts”) and that’s not where it’s getting stopped.

I have looked in to that area, and also noticed that you can actually add AS0 as allowed, or blocked, to either a specific zone, or the whole account.

I was initially thinking about the WAF custom rules, - have you tried if they are able to block AS0?

→ https://dash.cloudflare.com/?to=/:account/:zone/security/waf/custom-rules

→ https://dash.cloudflare.com/?to=/:account/:zone/security/waf/custom-rules/new

For example:

Actually, an interesting fact, when looking over here:

IP Access rules · Cloudflare Web Application Firewall (WAF) docs

The advice, according to the warning, is to use WAF custom rules to provide IP-based or geography-based blocking (including AS numbers).

@sageth

Since the 2025 directory isn’t yet published and the phone number 000-000-0000 isn’t technically a valid number, I’ve blocked it.

The understood analogy would be sightly incorrect here, as we do actually have valid phone number - 800-555‑0175 (in your case: the IP address).

The source network, the operator of that phone number, has all the details (source “telephone exchange” / switch board) and knows where exactly the phone number would go.

However, the operator of the destination network doesn’t know whether 800-555‑0175 (in your case: the IP address) should be sent to a “telephone exchange” / switch board in US East, or US West, or which specific state/city it goes to, which is what the AS number defines with this analogy.

→ Adjustments of this “telephone exchange” / switch board data in this analogy, will be far from instant, and may unfortunately (in the eyes of some) take a (long) while to propagate.

But that said, I doubt we’re getting further with this analogy.

@sageth

meaning something is wrong because it shouldn’t be making it to WAF – it should be stopped at IP Access Rules.

In my database, the street number of your address, or your phone number (if you avoid dashes and other special characters), … et al, can, if it is unknown:

1. Be a NULL value in the data (e.g. not have been set to anything)

2. Be set to actual the number 0.

#1 and #2 would be two different ways of storing the data, and they have the potential of messing up things, if the two different states aren’t treated well enough when parsing it.

With all that said, -

Even though we can see from some sources on the Internet that some IP ranges are routed to specific AS numbers, it doesn’t mean that the third party vendor (e.g. MaxMind) that I also believe is the source of this AS data for Cloudflare, is up-to-date on the information, … yet.

AS0 should at most be temporary, until the data sets have the updated data available AND that Cloudflare have “fetched” the new updates.