Cloudflare IPs not being detected and site under attack

Sim

Sim

Well-known member
I'm seeing a few cloudflare IP addresses sneak through instead of real ip addresses.

Specifically in the 2405:8100 range, examples:
  • 2405:8100:8000:5ca1::3:7fa2
  • 2405:8100:8000:5ca1::15d:cf80

I'm using the following nginx directives, which I thought would cover the above addresses?

Code: 
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header X-Forwarded-For;

My site is under attack right now from a disgruntled user - so I need to be able to block real IP addresses as a matter of urgency.

Any suggestions?

I'm on XF 1.5 if that makes a difference.
 
Hmm - I'm wondering if this is a difference between CF-Connecting-IP and X-Forwarded-For ... I'm reading that X-Forwarded-For can end up with multiple IP addresses if the header already exists when Cloudflare recieves the request - which might be confusing the real_ip_header directives?

I've changed to using CF-Connecting-IP to see if that helps.
 
Try to use the CF-Connecting-IP header instead of X-Forwarded-For. They recommend using that over X-Forwarded-For
 
  • Like
Reactions: Sim
CloudFlare offers "magic transit", and "cloudflare warp" which are an ISP and VPN service. There is also CloudFlare Workers.
Not all cloudflare IPs are from the site proxy service.

The canonical list IP list is;

I have this python script run daily to keep nginx in sync;
Python: 
#!/usr/bin/env python
import urllib2
import tempfile
import os
import subprocess

def generateIpBlock(url, txt):
  data = ''
  if txt:
    lines = txt.split('\n');
    for line in lines :
      if line:
        data += 'set_real_ip_from ' + line + ';\n'
    if data:
      return '# Allowed IPs - ' + url + '\n' + data + '\n'
  return ''

def generateMapBlock(url, txt):
  if txt:
    lines = txt.split('\n');
    data = ''
    for line in lines :
      if line:
        data += '  ' + line + ' 1;\n'
    if data:
      return '# IPs - ' + url + '\n' + data + '\n'
  return ''

if __name__ == "__main__":
  ipv4_url = 'https://www.cloudflare.com/ips-v4'
  ipv6_url = 'https://www.cloudflare.com/ips-v6'

  req = urllib2.Request(ipv4_url, headers={'Accept':'*/*', 'User-Agent': 'curl/7.29.0'})
  response = urllib2.urlopen(req)
  ipv4_data = response.read()
  req = urllib2.Request(ipv6_url, headers={'Accept':'*/*', 'User-Agent': 'curl/7.29.0'})
  response = urllib2.urlopen(req)
  ipv6_data = response.read()

  data = ''
  data += generateIpBlock(ipv4_url, ipv4_data)
  data += generateIpBlock(ipv6_url, ipv6_data)
  data += 'real_ip_header     CF-Connecting-IP;\n\n'

  data += 'geo $realip_remote_addr $isClouldFlare  {\n'
  data += ' default 0;\n'
  data += generateMapBlock(ipv4_url, ipv4_data)
  data += generateMapBlock(ipv6_url, ipv6_data)
  data += '}\n\n'

  confFile = '/etc/nginx/snippets/cloudflare.conf'
  try:
    with open(confFile, 'r') as f:
        oldData = f.read()
  except IOError:
    oldData = ''

  if oldData != data:
    fd, tmpName = tempfile.mkstemp(text=True,dir='/etc/nginx/snippets/')
    with os.fdopen(fd,'w') as f:
      f.write(data)
    print 'updating\n'
    os.chmod(tmpName, 0o644)
    os.rename(tmpName,confFile)
    command = ['/usr/sbin/service','nginx','reload']
    subprocess.call(command, shell=False)

This then spits out the following file;
Code: 
# Allowed IPs - https://www.cloudflare.com/ips-v4
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# Allowed IPs - https://www.cloudflare.com/ips-v6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header     CF-Connecting-IP;

geo $realip_remote_addr $isClouldFlare  {
 default 0;
# IPs - https://www.cloudflare.com/ips-v4
  173.245.48.0/20 1;
  103.21.244.0/22 1;
  103.22.200.0/22 1;
  103.31.4.0/22 1;
  141.101.64.0/18 1;
  108.162.192.0/18 1;
  190.93.240.0/20 1;
  188.114.96.0/20 1;
  197.234.240.0/22 1;
  198.41.128.0/17 1;
  162.158.0.0/15 1;
  104.16.0.0/13 1;
  104.24.0.0/14 1;
  172.64.0.0/13 1;
  131.0.72.0/22 1;

# IPs - https://www.cloudflare.com/ips-v6
  2400:cb00::/32 1;
  2606:4700::/32 1;
  2803:f800::/32 1;
  2405:b500::/32 1;
  2405:8100::/32 1;
  2a06:98c0::/29 1;
  2c0f:f248::/32 1;
}

I then pass the isClouldFlare variable to XenForo in the fastcgi config;
Code: 
fastcgi_param HTTP_CF $isClouldFlare;

In config.php I then have sanity checks to force XF not to try to recover the IP;
Code: 
))
{
    unset($_SERVER['HTTP_CF']);
    unset($_SERVER['HTTP_CF_RAY']);
    unset($_SERVER['HTTP_CF_VISITOR']);
    unset($_SERVER['HTTP_CF_IPCOUNTRY']);
}
unset($_SERVER['HTTP_CLIENT_IP']);
unset($_SERVER['HTTP_X_FORWARDED_FOR']);
unset($_SERVER['HTTP_CF_CONNECTING_IP']);

This ensures nginx is the canonical source of the forwarding IP headers, and if the request is not flagged as XF, ensure none of the CF headers are in the request.
 
Last edited:
Jake B. said:
Try to use the CF-Connecting-IP header instead of X-Forwarded-For. They recommend using that over X-Forwarded-For
Click to expand...

This isn't helping - I'm still seeing connections from 2405:8100:8000:5ca1: ... addresses :(
 
Xon said:
CloudFlare offers "magic transit", and "cloudflare warp" which are an ISP and VPN service. There is also CloudFlare Workers.
Click to expand...

Yes - I think this is what might be happening here.

When I query the other IP addresses from Cloudflare using MaxMind's insights web service, it clearly labels them as a "content delivery network"

However, when I query the IP addresses in the 2405:8100:8000:5ca1::/64 range - it labels them as a proxy service.

So it could well be Warp or similar.
 
  • Like
Reactions: Xon
I am sorry, not following. If your website is under attack, why not allow only cloudflare IP's to connect your VPS?

What I have done, is white list cloudflare IP's and block other IP's. After that, I used ASN's to block all the IP's of hosting across the world. That took care of 90% DDoS attacks on our site.

Yes once, i was getting 20 million hits and cloudflare handled it well.
 
hellreturn said:
I am sorry, not following. If your website is under attack, why not allow only cloudflare IP's to connect your VPS?

What I have done, is white list cloudflare IP's and block other IP's. After that, I used ASN's to block all the IP's of hosting across the world. That took care of 90% DDoS attacks on our site.

Yes once, i was getting 20 million hits and cloudflare handled it well.
Click to expand...

That is how things are set up - but there are some Cloudflare IPs that are not part of their standard service and are used for other purposes (eg VPN).

I was getting confused by the Cloudflare IPs showing up in my logs - which they normally don't ... but it turns out that there was nothing wrong with my config - they are simply re-using certain IP ranges for their other non-core services.
 
In case it helps, this is what we have in our config.php that seems to pass through real ip's:

Code: 
if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];}
 
Mr. Jinx said:
Reading this topic, I'm so confused about configuring Xenforo with Cloudflare :confused:

I thought it was enough to add the ip's from https://www.cloudflare.com/ips-v4 and https://www.cloudflare.com/ips-v6 in Nginx (set_real_ip_from) and put those also in the allow list of my firewall.
Click to expand...

That should be all you need - your users real IP addresses should be showing in the Current visitors list, right? If so, then you are all good.

Just be aware that there are certain IP ranges (eg: 2405:8100:8000:5ca1::/64) which are not standard Cloudflare IPs (despite appearing in the ips-v6 list you linked to) - because (I suspect) they are being used by Cloudflare's VPN service.

So if you see users from IPs in that specific range appearing on your site - don't worry, it's not a misconfiguration on your side.
 
Sim said:
because (I suspect) they are being used by Cloudflare's VPN service.
Click to expand...
AFAIK, Cloudflare Warp VPN uses 8.xxx.xxx IPs :) At least that's what's used when I am using Cloudflare Warp+ For Teams. But Warp connecting to Cloudflare proxied sites will actually see the real visitor IP as it isn't a anonymous VPN, it's just to secure the connection. See https://developers.cloudflare.com/w...why-is-my-public-ip-address-sometimes-visible

Why is my public IP address sometimes visible?​

Cloudflare WARP Client in WARP mode was meant to ensure all your traffic is kept private between you and the originOpen external link (the site you are connecting to), but not from the origin itself. In a number of cases, if the origin site you are communicating with can't determine who you are and where you're from, they can't serve locale relevant content to you.

Sites inside Cloudflare network are able to see this information. If a site is showing you your IP address, chances are they are in our network. Most sites outside our network (orange clouded sites) however are unable to see this information and instead see the nearest egress colo to their server. We are working to see if in the future we can't find a way to more easily share this information with a limited number of gray clouded sites where it is relevant to both parties.
Click to expand...
 
eva2000 said:
AFAIK, Cloudflare Warp VPN uses 8.xxx.xxx IPs :) At least that's what's used when I am using Cloudflare Warp+ For Teams
Click to expand...

Do you know what service might be using the 2405:8100:8000:5ca1::/64 range?

Are you somehow limited to IPv4 when you used Warp?
 
Sim said:
Do you know what service might be using the 2405:8100:8000:5ca1::/64 range?

Are you somehow limited to IPv4 when you used Warp?
Click to expand...

I'm on ISP which seems to only show up with IPv4 and all I have seen behind Cloudflare Warp+ For Teams (different from normal Warp non+) is IPv4 addresses logged on servers outside of Cloudflare network and also IPv4 address (real ISP IP) for servers inside/behind Cloudflare network (orange cloud proxied sites).

As to 2405:8100 no idea, not seeing that IP being logged on origin side of any of my servers using Cloudflare. You can try logging additional details of requests behind Cloudflare to dig deeper into the request via CF analytics i.e. CF rayid

For example for additional logging with Nginx https://community.centminmod.com/threads/cloudflare-custom-nginx-logging.14790/ or in Nginx JSON logging format https://community.centminmod.com/threads/how-to-configure-nginx-for-json-based-access-logging.19641/
 
  • Like
Reactions: Sim
You must log in or register to reply here.
Top Bottom