5 ms·
Maybe this is common knowledge, but this is a quick and dirty way to reduce bots, spam and abuse. if geo:get('location', 'accuracy_radius') >= 100 then
by panarky 4y ago
Maybe this is common knowledge, but this is a quick and dirty way to reduce bots, spam and abuse.
if geo:get('location', 'accuracy_radius') >= 100 then
SetStatus(403)
Write('you can only post comments from your home internet connection')
return
end
Bad actors often use cheap cloud instances, and the IP addresses of their data centers typically have an accuracy radius of 1000 km.
- m00dy 4y agoI wouldn't prefer that rule.
- detaro 4y agoHave a normal connection at one of Germanys biggest ISPs, am a bot according to that rule.
- 8organicbits 4y agoThe same is true for some large US based ISPs. Lot's of home users would be considered bots using this rule.
- andrewmcwatters 4y agoThanks for sharing this, but how are accuracy radii defined by MaxMind?
- gazby 4y agoThis strikes me as a terrible idea, relying on an idiosyncrasy of an arbitrary database to deny access to users. For anyone doing something like this with a service that's useful to people, consider MaxMind's minFraud service. It's PAYG and you can choose three different levels of information at three different price points. It's targeted at fraud minimization, but you can hand it as little as an IP address and it'll give you what you need to know.
- panarky 4y agoDepends on the use case. MaxMind's minFraud is $0.015 per request and requires a call to an external endpoint. Justified for finance and shopping apps, not great for a high volume free service. And you don't have to deny based on this one signal alone, you could fall back to recaptcha or minFraud to reduce the false positive rate.
- capableweb 4y ago> MaxMind's minFraud is $0.015 per request and requires a call to an external endpoint. Justified for finance and shopping apps, not great for a high volume free service. What fraud are you trying to prevent that gets abused in a free service? Most of the abuse I see for free services I host is DDoS, brute-forcing paths/authentication and port scanning, but all of those are trivial to deal with rate-limiting.
- zdragnar 4y agoAny and all public form submissions will get spammed. My wife ran a small business for awhile that catered to local customers only (i.e. not an online business, products didn't ship through the mail. She added a contact us type form which submitted to google forms as a quick alternate to phone calls for prospective clients. It was used almost exclusively by people trying to sell her things from overseas. She wasn't even running ads or anything online, so how they ever found the website in the first place, I have no idea.
- capableweb 4y agoThat's also relatively easy to protect. First defense is rate-limited, second is captchas, third is having a dynamic "secret" key fetching from some backend via JS that gets injected into the form and works as a "password" to successfully trigger the email to get sent (but displaying success messages even if it's not).
- d110af5ccf 4y ago
- _wolfie_ 4y agoWell, I guess I was a bot all along with 200 on my home IP.
- smt88 4y agoThis is a really bad idea. Bot detection is an incredibly complex problem, and simple rules like this are more likely to catch humans than (motivated) bad actors.
- bigiain 4y ago“(Motivated) bad actors” are a different problem to drive by bot spammers. While I agree with all the people saying “this’ll block real people at significant rates”, for some things (like personal blog replies or small forums) that can be a perfectly sensible trade off for some sites. Sure, if you are Netflix, or a government department website that people need to use, it’s a terrible idea. For somebody who’s sick of deleting spam replies on their personal blog posts? Simple rules with known and acceptable unintended consequences might be a really good idea.
- ezekiel68 4y agoThat's precisely the kind of comment we'd expect to read from a (motivated) bad actor. </sarcasm>
- cmeacham98 4y agoYou'd be better off banning known "cloud" IP ranges than this (and I think even that protection is questionable).
- heavyset_go 4y agoIt's questionable, and it blocks a lot of legitimate traffic.
- bigiain 4y ago“A lot”? What sort of ”legitimate traffic” comes off AWS/Azure/DigitalOcean et al? And how does the volume of that (and relevance of that traffic) compare to home add and mobile CGNAT ipaddresses? Unless I’m selling something, dropping all cloud instance IP ranges doesn’t em like it’d block a lot of “legitimate traffic” to me, at least not enough to care about. If my choices were “spend time implementing a more sophisticated locking technique to reduce blogspam” or “write more blogposts”, I’d be triggerhappy blocking everybody using AWS o browse from and writing more content. I use FSecure as a VPN, and I see it “do weird shit” at about the same rate as I see when I’m using a Hertzner box as a wire guard endpoint. (Most common thing there is I can’t order via menulog when I’ve got a vpn endpoint out of I am getting it delivered to, and I’ve just got used to switching off my phone’s vpn while ordering..)
- lstodd 4y agoYeah, now consider living in a country which blocks stuff left and right (including vpn services) so that DO/Hetzner endpoint is the only endpoint outside you have.
- deleted 4y ago[deleted]
- achillean 4y agoFor a more specific check, you could query internetdb.shodan.io and see if the client IP has port 22 open, has the "vpn" tag or is any other services that you wouldn't expect to see from a visitor. We have a bunch of enterprise users that created rules to filter traffic out from IPs that are compromised or otherwise look malicious.
- heavyset_go 4y agoI'd imagine this might hurt those behind CGNAT or anyone that chooses to use VPN services.
- Kiro 4y agoFor anyone confused by this comment: it's a copypasted example from the article itself regarding support in redbean for Maxmind.