Access Rule Not Working


#1

I’m new to this so I probably have something misconfigured, but my firewall access rule does not seem to be working. I added a single rule to block a single IP address from my website; however, that IP address is not getting blocked. I’m pretty sure the correct IP address was added. Anyone have an idea why it isn’t working?


#2

Have you made sure the action is “Block”? It is a single address, not a range, right? Could you post a screenshot of the row in question?


#3


#4

One thing I should mention is that the request received by my server does not contain any of the CF headers like CF-Connecting-IP. In fact, there is no indication that CF was in any way involved in the request. My understanding is that CF would inject that header. The IP address 184.96.243.235 that I am trying to block does appear as the 1st address in the HTTP_X_FORWARDED_FOR header.

Another thing, in case it makes any difference, my server is on MS Azure.


#5

Well…that’s interesting. There should at lease be a cf-ray header. What’s the domain? I’m going to check Name Servers and if that looks good, then I’ll see how the host resolves.


#6

Thats a very good point. Could it be they sent it directly to your server, bypassing Cloudflare? Have you disabled external access?


#7

As @sandro mentioned, this request could be going direct to origin, this is likely given that the domain was only very recently added to Cloudflare.


#8

The domain is www.rrfnsgen.com.

It does behave as if it’s going direct to the origin. However, the orange cloud is enabled. The headers received by the server are the same whether or not the orange cloud is enabled.

I’m not sure if external access is disabled. How can I tell?


#9

From the domain it is impossible to tell, as it now already resolves to Cloudflare and its actual IP address is hidden at this point.

Considering that you asked the question would lead me to believe that you probably havent shut it for external access, which would mean everybody knowing the IP address can still access it - and that is what might have happened here.

Depending on your configuration the best thing might be to block all access to your webserver (ports 80 and/or 443) except for Cloudflare.


#10

Looks like there is no way to restrict IP addresses on the server at this time.
However, almost nobody knows the IP address of my server. If my client app is hitting rrfnsgen.com, shouldn’t my server should only see traffic from CF?


#11

If you didn’t explicitly disable external access at your host/firewall/loadbalancer, it isn’t disabled. It is possible someone still has/had a cached DNS entry pointing to the origin or that someone hard coded the origin.


#12

This is a staging server. Nobody else but me has a client that can hit that API at the moment.


#13

In that case, how would the mentioned request show up in the first place? Apparently some does know how to access it and given the machine is not locked down, there is an equal chance someone connected directly.


#14

You mentioned the server is with Microsoft. What kind of access do you have? Maybe there is a way to lock it down. Which operating system does it run? Is it a proper server or one of those as-a-service thingies?


#15

Sorry, I’m not sure I follow. I am the only one that can connect directly because I created the API call and have never given that information out to anyone else. I wrote an app for the purpose of testing CF that I only run on my local machine that I can use to hit the origin directly or to hit the rrfnsgen.com domain. I do this by changing a hard-coded URL. Since I also control the server, I can see that my API was called and inspect the headers. Also, the CF portal only shows activity during the times I am testing.


#16

It’s a function app (like AWS lambda) running on Azure.
The IP white list for function apps has been temporarily disabled due to a bug. That’s why it’s not possible to lock it down at this time. It should be available in the future.


#17

Alright, so you dont control the machine itself. In that case it probably is not possible to block requests on a network level. There might be a chance to block them a bit higher up in the stack though.

Anyhow, you mentioned your server couldnt be accessed because it is a staging server and nobody had access. As you mentioned, somebody did access it however (or at least sent some sort of request) and if somebody manages to do so, it is not related to Cloudflare.

The fundamental point is, this machine is (network-wise) open to the public, hence there is a good chance the request in question came straight to the machine and not via Cloudflare (where it should have been blocked according to your configuration).


#18

Exactly! Everything points to CF being somehow bypassed. Either that or the access rule is not triggered for some reason. I’m wondering if it could be some kind of DNS configuration issue. My understanding of all this is somewhat limited, so it’s probably something I did wrong. Just don’t know what it is…

If I can get this to work in staging, I have 3 more servers I would like to configure.


#19

In the DNS configuration, the A record points to a Microsoft server in Des Moines, IA. The CNAME and TXT records are an alias of the origin.

The A and CNAME are orange.

Does this sound correct?


#20

It is difficult for to give a definite statement, but thats how it seems and what I would assume.

What would you have in mind? Right now the configuration looks alright, but of course a lot can depend on when you switched nameservers and if there was any period when the host entries were not :orange: respectively if there are possibly any other entries which could give away your original host.

That does sound about right, but the TXT record seems to give your host away