Looking for help addressing an issue with suspicious activity on the site, and need some advice on how to stop/block this user/bot with information I have.
Over the last month our site has been pinged on various pages by an unknown source 135 times from various IP addresses, which all link to the org Tencent Building, Kejizhongyi Avenue.
It is coming from the same device and browser each time.
Chrome 126.0.6478.114 on Windows Server 2008 R2 / 7 64-bit
Generally most visits would not be cause for alarm, however the fact that they’re using Windows 2008 and the IP address comes from China, along with the type of behavior the user/bot is portraying.
It appears that the user/bot is performing a meticulously controlled attack to avoid setting off any bells or whistles with Cloudfare by strategically pinging site pages at different times, strategically spaced apart.
Though, we have recently made numerous URL path changes, and thus the user/bot has nearly pinged all dead pages, leading to 404. However, until recently, the user/bot has made it to a working page.
It seems that maybe the user/bot is seeking a 200 response, possibly to find a means of exploitation. That is just my initial assessment and opinion developed on the very little knowledge I have on these sorts of attacks.
Any other information or tips are greatly appreciated.
I have tried instituting a couple of things that would block or redirect any user with Chrome 126.0.6478.114 on Windows Server 2008 R2 / 7 64-bit, but it has proved unsuccessful, likely due to it being a bot rather than a user.
The Windows 2008 part is just text, and they can make that whatever they want. They probably just copy and paste the same text.
Pretty much every single live site will have this happen. Most either don’t notice or don’t care.
Doesn’t sound like the bot is creating accounts. We talked about that somewhere on here about using a honeypot to stop the bots from doing that.
But you mentioned Cloudflare. Did you add your site to Cloudflare yourself and set it up? That’s your first line of defense. Couldn’t tell from your comment if you actually did that or not…I see you mentioned Cloudflare though.
You also said you did a few things to try and stop this. It would depend on what you did and whether you set your site up with Cloudflare to give the best response to you
Hey, thanks for the reply. Very interesting. Only deepens my curiosity about what’s going on. Who would be renting a server, and what their intent would be? I haven’t seen this behavior in the almost four years I’ve been using bubble.
Our account creating happens only on the backend after the execution of a DocuSign agreement with email verification.
We don’t have Cloudfare setup at this time, but from what I could tell there is some protection via Cloudfare because Bubble use them for CDN. I might of misunderstood, but I thought I read in another post that Cloudfare DDoS protection would trigger autonomously if there was an apparent attack on a Bubble app.
The only thing I have done is put up a blocker and a redirect, but that hasn’t worked thus far. Still getting pings every other hour or two.
It may be time to move everything to Cloudfare, I’ve been procrastinating.
In the app world, we call this rattling door handles to see if any are unlocked.
Surprised you’ve never seen it, it’s pretty common.
You can just go to Cloudflare and add your domain name. Cloudflare will scan your site and then give you a couple of nameservers to add. You can then make some settings to give you better protection. The free plan does quite a bit. However, if you are ever seriously attacked, you could upgrade. But for your case, you could probably just use the free plan
Yea, that’s definitely what it seems like to me, “rattling door handles”, that’s a good expression. Thanks again for the reply. I think Cloudfare is the solution. Pain in the butt.
I just fended off a bot attack managing to create accounts. We implemented several extra “generic” security measures on Cloudflare and in the app. But at the end of the day it was actually our analysis of log data that lead us to implement specific blockers in app.
We actually stopped sending SMS codes since that cost money and the bots manage to trigger that a lot. But, to my surprise, the bots entered country codes well out of our area of operation. So we could trap that and stop them early in the process.
So that suggests the bot had access to an email account associated with the address it used to sign up. That’s a bit disconcerting, though not surprising in an age of AI-enhanced security exploits.
I actively discourage email/password sign-ups by listing it at the bottom of the list of sign-up methods, and I might eventually remove it entirely. (IMO, Apple has been leading the industry with its passkey implementation.)
It occurred to me that you (@philledille) might have meant the bot was able to create users but that the email verification step actually prevented it from fully onboarding and logging in as a privileged user. If that’s the case, it’s less unsettling. Can you clarify when you get a chance?
Went ahead and made the move to Cloudfare tonight. Tried implementing some simple rules like (ip.geoip.country in {“CN”}) Block, gave it a test from China IP addresses, and still got page loads. Tried various other rules and IP addresses from different countries and continents, and still got page loads. Did some sanity checks and verified Cloudfare is all plugged in correctly. Googled the issue and apparently Bubble doesn’t support your own Cloudfare account WAF. I am a noob when it comes to that stuff. So idk what the work around is, or what I am doing wrong.
)