3 ms·
Ask HN: Have you had issues with Cloudflare's IP 2a06:98c0:3600:103?
Hi guys,
I'm sure many of you use CloudFlare. One of my websites have been over-crawled and the traffic is coming from IP 2a06:98c0:3600::103 which belongs to CloudFlare. The user agent resembles a Google Bot, but that could easily be spoofed, and I guess Google isn't using CF.
My issue is that the traffic continues even if I try blocking that IP address at CF level. Note - I've blocked it at Nginx level; yet's that's hundreds of requests per second of rejects (if not more).
If anybody has resolved this issue in the past, sharing your experience is greatly appreciated. Thanks!
- MatthiasPortzel 2y agoHave you submitted an abuse report to Cloudflare?
- stanislavb 2y agoI haven't. I will.
- t312227 2y agohello, imho. this sounds like a ddos... maybe the ip address(es) of the requests are spoofed!? this could be given you mentioned, that the request didn't stop after you blocked them at nginx/ipt/... level for this ip/ip-range!? idk ... set up nginx's rate-limiting? * https://www.nginx.com/blog/rate-limiting-nginx/ https://www.nginx.com/blog/rate-limiting-nginx/ which OS do you use? if its linux and you are able to access the OS itself, (additionally) setup a rate-limit at ip-level for the machine? * https://www.baeldung.com/linux/iptables-packet-rate-limit https://www.baeldung.com/linux/iptables-packet-rate-limit or even ask your upstream-provider to help/configure its ddos-protection properly!? just my 0.02€
- LinuxBender 2y agoIf it's TCP HTTPS and making established connections then it is not spoofed. Spoofed TCP connections will be SYN packets but a TCP handshake and TLS handshake will not complete. More likely someone abusing a proxy capability of Cloudflare which is why reporting it to them along with logs is very important. They process massive amounts of traffic so logs with accurate timestamps NTP correctly running on the web server are important to find the needle in the haystack.
- LinuxBender 2y agoI 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 agoThanks!
- stanislavb 2y agoUnfortunately, 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 agoThis 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.