I’ve reached out to Webflow support, but its been more three days and I have not received a response, The issue is urgent, so I thought I would reach out here for some help.
Last week using a different analytic view, I discovered thousands of hits (18,468 and counting from 77 different AWS IP addresses), at times hits are occurring as frequently as 100 per minute. One of the IP addresses being used is 3.142.175.190 - which has been reported as an abusive/proxy/tunneled connection.
I reported the issue to AWS, with our logs from Visual Visitor - but they are requesting server logs, (10 log lines per each unique IP in xarf format) and they are unable/unwilling to help without them.
I cannot access our htacces file to block the IP addresses and do not have access to server logs.
In my last email to webflow support, I sent additional logs and asked about bandwidth overages on our hosting plan. Without any response from Webflow support, at this point I am at a loss - any suggestions or help on how I can stop this would be much appreciated.
I setup cloudflare as a reverse proxy for all of my clients, because it allows you to see incidents and block them at the WAF ( web application firewall ). That should help you cut out any illegitimate traffic.
If you’re struggling with spikes, I typically implement an edge caching framework for everything as well, which lets me optimize delivery, handle traffic spikes, fix-up HTML, watermark images, that kind of thing.
I appreciate your reply, we actually signed up for Cloudfare Pro yesterday, but cloudfare is proxying new connections, not our “old” IP addresses that the attacker is still using.
Am I missing something? Its my understanding that since our website is hosted by Webflow and was not initially set up with cloudfare, implementing a reverse proxy now would require the ability to access and edit our htacess file.
We still need server logs from when the attack began to submit to AWS and the FBI, which only webflow can provide.
Webflow touts site security and built in DDoS protection/ WAF on their hosting page, but doesn’t provide access to tools like server logs or htaccess that could help us mitigate the damage when their built in tools fail and we wait (and wait, and wait and wait) for a response from support during an active attack.
The fact that we have to use a paid version of cloudfare in attempt to effectively protect a webflow hosted site is ridiculous considering the price of hosting.
Those are good questions for your discussions with support.
My best guess is that they have some network security features baked into the delivery platform at the CDN level, but that there are no site-specific controls or visibility into attacks or WAF mitigation actions.
What’s the nature of the attack, are you actually seeing site outages?
Webflow’s platform is quite robust, I’ve never heard of a DoS attack taking down a Webflow-hosted site. Since it is CDN-delivered, there isn’t a solitary server to attack. I believe WF is still using Fastly as its primary CDN which has ~60 datacenters, and recently ( ~June 1 ) began using CF’s edge CDN for asset delivery, which is another ~300 datacenters.
If the problem you’re seeing is bandwidth related, i.e. you’re getting bogus traffic that’s causing problems for you, that’s trickier to deal with. The way WF’s platform is setup, assets are served on a WF-owned domain so even with an RP setup you need to do a bit of work to make those assets inaccessible to an attacker.
Depending on the impacts you’re seeing, that’s more WF’s ( i.e. Fastly’s ) problem than yours. I’d think you don’t need to care much about what traffic WF’s IP’s are getting, only what traffic is being directed towards your site specifically.
If the scenario is that you have an attacker who is abusing your assets, or an asset leech who is hosting your exposed Webflow CDN URLs directly on another site, there’s a technique my team uses we call “castle the king” as in the chess move. It eliminates domain and assets exposure, but we’ve needed to use it very rarely.
No, setting up an RP config on CF does not use an htaccess file, and it’s completely independent of Webflow’s setup. WF doesn’t need to do anything.
I’m curious to hear how support responds here. I’ve never heard of WF providing server logs, but it’s possible they have some Enterprise clients that require them ( government sites, financial providers, etc. ). In general, server logs are something of a rarity these days, since CDN architectures make it difficult to capture and aggregate that level of detail, and site traffic volumes make it impractical.
Even CF doesn’t have a built-in HTTP logging feature, you’d need to design your own.
I’m very curious about the impacts you’re seeing. My team mostly builds RPs to add features to WF ( content integration, semantic paths, expanded sitemaps, expanded user accounts capabilities… ), but this year we’ve been getting a lot of requests specific to dealing with bot traffic spikes and asset leeches who push a client over the hosting plan bandwidth limit.
I’ve never seen a WF site “disabled” by a bot attack.