3 ms·
This was addressed in CloudFlare's blog post: > One suggestion has been that we treat GET requests for static content differently than we do more risky request
by pfg 11y ago
This was addressed in CloudFlare's blog post:
> One suggestion has been that we treat GET requests for static content differently than we do more risky requests like POSTs. We actually already do treat more dangerous requests differently than less risky requests. The problem is Tor exit nodes often have very bad reputations due to all the malicious requests they send, and you can do a lot of harm just with GETs. Content scraping, ad click fraud, and vulnerability scanning are all threats our customers ask us to protect them from and all only take GET requests.
- kristofferR 11y agoHm, I didn't notice that part and I hadn't thought about ad click fraud and vulnerability scanning. Preventing content scraping for publicly accessible content is kind of dumb and impossible in my view anyway though. For the few that care about making scraping more cumbersome the option should be there to enable the captchas, but I don't think it should be a default. Ad click fraud is a harder problem to figure out, but should be a issue for the ad-networks to deal with and not the sites with the ads. I'm torn about preventing vulnerability scanning. While I do it on my server using mod_security, it's also a form of "security by obscurity", which I'm not that much a fan of. Anyway, disabling captchas completely should be a very visible option. The protections on "dangerous GET requests" are probably only needed for a small minority of CloudFlare sites, so what should be the default setting becomes a question of what's most valued the most - safety for the many (making Tor usage easy and not cumbersome) or security for the few (who rely on the default settings protecting them from "niche" security issues). I think making Tor usage easy by default would be best for the security of the web at large, but I can see why CloudFlare has different priorities.
- kuschku 11y agoThat argument only holds true if the person operating the site has no idea at all about the HTTP standards. * GET requests have to be idempotent. * Security by Obscurity is not Security. * Content Scraping is nothing you have to protect against, or should protect against – DRM just does not work.
- pfg 11y agoRight, but this is about abuse and solutions for that. Obviously, blocking Tor is not going to prevent a determined attacker from scraping your site or trying some SQLi vectors. It might, however, prevent a large number of bots from scraping your site for emails, scanning for vulnerabilities, or doing click fraud. It's not a perfect solution, but those rarely exist. CloudFlare sees a lot of malicious traffic, so they probably have a better view of what works and what doesn't compared to everyone else.
- kuschku 11y agoI see a lot of fraud on my site as well, and I can say that there are some ISPs in Eastern Europe and Asia that are just as likely as Tor as being the origin for a malicious attack. I don’t block them either. Instead, I use fail2ban with a 30min ban for the IP for all my servers, and have the rest of the system hardened. Also, I add an additional delay that’s just below the timeout that browsers have for each request from an IP of that block for the next 30min. Reduced my logs of "123.456.789.012 tried to authenticate as "root" with invalid password" from several gigabytes a day to a few kilobytes. ________________________ Sure, I don’t host a large site, or get much traffic, but saying "Tor is the only issue" or even "Tor is the largest issue" isn’t true. And there are solutions for these cases. Solutions which allow legitimate users to continue using the services.