2 ms·

I have seen this come from CF in the past to my silly little hobby sites. I just drop the IP or sometimes subnet in a file that on startup effectively does:

I have seen this come from CF in the past to my silly little hobby sites. I just drop the IP or sometimes subnet in a file that on startup effectively does: ip -6 route add blackhole 2a06:98c0:3600::103 That method is faster processing and lower CPU than using a firewall and prevents a socket from being opened and wasting kernel memory and keeps it out of your firewall state table. For UDP I still use the raw table IPset in IPTables as a blackhole will not stop the traffic from getting to the application in that case, such as DNS servers. When reporting this to Cloudflare make sure you have NTP set up on your web server so that your access logs can line up with proxy/app logs on their side to make it easier for them to correlate. A couple lines of the traffic from tcpdump using -vv to get packet details may also be useful to them. tcpdump -p -NNnnvv -s0 -c2 host 2a06:98c0:3600::103

stanislavb 2y ago
Thanks!
stanislavb 2y ago
Unfortunately, that doesn't work as traffic is proxied through CloudFlare. i.e. all the traffic reaching my machine comes from CloudFlare IPs. The only way to know the real IP is at web-server level (e.g. Nginx). Usually, I can block similar traffic at CloudFlare level; however, that's somehow not the case with that IP.
- LinuxBender 2y ago
  This is not for you to get the real IP. What I described is for you to give to Cloudflare support so that they can look through any logs they may have and find the needle in the haystack of data. I am making an assumption that they log access to anything that might act like a forward proxy abusing their worker code, etc... Only Cloudflare employees could really say if the data is useful. If it is then they could get the real IP address and maybe even do some captures of their own to update their attack / bot detection assuming this is of interest to them. If they are unable to help then the best I could suggest would be to keep that abusive IP blocked at the risk of legit people also being blocked. Another potential option would be to just exclude logging from that IP or URL request patterns if they are not actually hurting your server. NGinx and Apache allow excluding or including status codes to log to get rid of noise. One can always disable this when debugging.

stanislavb 2y ago

Thanks!

stanislavb 2y ago

Unfortunately, that doesn't work as traffic is proxied through CloudFlare. i.e. all the traffic reaching my machine comes from CloudFlare IPs. The only way to know the real IP is at web-server level (e.g. Nginx). Usually, I can block similar traffic at CloudFlare level; however, that's somehow not the case with that IP.

LinuxBender 2y ago
This is not for you to get the real IP. What I described is for you to give to Cloudflare support so that they can look through any logs they may have and find the needle in the haystack of data. I am making an assumption that they log access to anything that might act like a forward proxy abusing their worker code, etc... Only Cloudflare employees could really say if the data is useful. If it is then they could get the real IP address and maybe even do some captures of their own to update their attack / bot detection assuming this is of interest to them. If they are unable to help then the best I could suggest would be to keep that abusive IP blocked at the risk of legit people also being blocked. Another potential option would be to just exclude logging from that IP or URL request patterns if they are not actually hurting your server. NGinx and Apache allow excluding or including status codes to log to get rid of noise. One can always disable this when debugging.