谷歌分析与 DDoS
我想知道的是,当发生 ddos 攻击时,Google Analytics 会显示什么样的行为?有什么理论吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
我想知道的是,当发生 ddos 攻击时,Google Analytics 会显示什么样的行为?有什么理论吗?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(6)
我的理论是,有效的 DDoS 平台/脚本不会包含像 JavaScript 引擎这样重量级的东西,因此 DDoS 活动根本不会出现在 Google Analytics 中。
DDoS 攻击的目的是通过大量请求淹没服务器。任何用于评估服务器发回的响应中的 JavaScript 的 CPU 周期都可以更好地用于向服务器发出更多请求。我完全希望正确执行的 DDoS 攻击不会浪费时间解析服务器的响应,甚至从底层套接字读取它,更不用说解释和执行可能嵌入在标记中的 JavaScript 或获取脚本和其他资源了来自目标服务器以外的域。
当然,这并不排除使用评估嵌入式 JavaScript 的 Web 框架和库实施极其幼稚的 DDoS 攻击的可能性。此类攻击不会(或者更确切地说,如果您正确实现了服务器代码,不应该)非常有效,但它可能会导致 Google Analytics(分析)流量激增。
My theory would be that an effective DDoS platform/script would not include anything as heavyweight as a JavaScript engine, and that therefore the DDoS activity would not show up in Google Analytics at all.
The point of a DDoS attack is to overwhelm the server with a flood of requests. Any CPU cycles that are spent evaluating JavaScript in the response that the server sends back are cycles that could better be used churning out more requests to the server. I would fully expect a properly executed DDoS attack to not waste time parsing the response from the server, or even reading it off of the underlying socket, let alone interpreting and executing and JavaScript that may be embedded in the markup or fetching scripts and other resources from domains other than the target server.
Of course, this does not preclude the possibility of an exceptionally naive DDoS attack implemented using web frameworks and libraries that do evaluate embedded JavaScript. Such an attack would not (or rather, should not if you've implemented your server code correctly) be very effective, but it would likely generate a spike in Google Analytics traffic.
这取决于 DDOS 的实施方式。如果它只是一个分发到多台机器的可执行文件,使用本机 TCP 套接字进行简单的 HTTP 查询,那么 Google Analytics 根本不会注意到任何事情:因为返回的 JavaScript 永远不会被执行。
然而,其他类型的 DDOS 攻击可能会利用分布在许多计算机上的实际浏览器。例如,如果您可以破解雅虎主页并在其中插入
,您就可以轻松地对“takemedown.com”进行 DDOS。在这种特定场景中,GA 肯定会检测展示次数,并且因为(取决于场景)可能存在 HTTP 引荐来源网址标记,所以您可以在 GA 中运行一个报告来提取可疑的展示次数。
但还有其他类似的场景,不会留下任何特定的足迹。例如,如果你可以破解 Lady Gaga 的 Twitter 帐户,你可以向她的 16MM 关注者发送一个链接,大量的粉丝会立即点击它:因为大多数点击它的人可能是在一个单独的页面中这样做的。应用程序中,不会有任何引用者标签,也没有识别请求的特定方法。
换句话说,这一切都取决于情况,但这可能不是一个非常有用的调查途径。在许多(大多数?)场景中,GA 甚至无法识别该印象;在许多其他情况下,没有任何合理的方法来区分好印象和坏印象。
It depends on the way that the DDOS is implemented. If it's simply an executable distributed to multiple machines, making simple HTTP queries using native TCP sockets, then Google Analytics wouldn't notice anything at all: because the JavaScript that gets returned would never be executed.
However, other sorts of DDOS attacks could leverage actual browsers distributed across many machines. For instance, if you could hack the Yahoo home page and insert an
<iframe src='takemedown.com'>
into it, you could easily DDOS "takemedown.com". In this particular scenario, GA would certainly detect the impressions, and because (depending on the scenario) there might be an HTTP referrer tag, you could possibly run a report in GA that could pull out the suspicious impressions.But there are other similar scenarios that wouldn't leave any particular footprints. For instance, if you could hack Lady Gaga's twitter account, you could send out a link to her 16MM followers, and a significant number would immediately click on it: and since most of those clicking on it would probably be doing so from within a separate app, there wouldn't be any referrer tag, and no particular way of identifying the requests.
In other words, it all depends, but it's probably not a terribly useful avenue to investigate. In many (most?) scenarios, GA wouldn't even recognize the impression; and in many others, wouldn't have any reasonable way of picking out the good impressions from the bad.
它将在谷歌分析中 100% 显示一些显着的峰值,仅仅是因为来自多个来源的大量请求具有巨大的跳出率!
It will show up 100% some significant peaks in google analytics , simply because there are huge number of requests from multiple sources having huge bounce rate !
当发生 HTTP DDoS 攻击时,攻击者要么使用几台(数千台)计算机来执行此攻击。有时,也通过服务器完成。当他们发出请求时,他们不会呈现 javascript 或任何内容 - 在大多数情况下,他们只是向网页发出 GET 请求。
所以不,它不会真正对 GoogleAnalytics 产生影响
When a HTTP DDoS attack occurs the attacker is either using several (thousands) of computers to do so. Sometimes, it's also done with servers. When they make the request, they don't render the javascript or anything - they simply in most cases just make a GET request to the webpage.
So no, it shouldn't really have an impact on GoogleAnalytics
好吧,我也在搜索此类信息,但我对答案有一些考虑:
您可能不会通过 Google 分析看到攻击本身,但您应该看到结果,我的意思是,DDoS 是“分布式拒绝”服务”,因此,如果服务被有效拒绝,那么您应该在 Google 分析的图表上看到一条平线。
Well, I'm also searching this kind of information, but I have some considerations about the answer:
You will probably not see the attack itself with Google analytics, but you should see the results, I mean, a DDoS is a "distributed deny of service", so, if the service is effectively denied, then you should see a flat line on the graph on Google analytics.
这取决于机器人的工作方式,但我的网站发生了以下情况:
僧侣
除了流量增加之外,您可能会发现跳出率飙升,平均页面停留时间显着下降 - 我确信这会对 SERPS 产生负面影响。
对我来说,它恰逢 Google 更新,所以首先我把它归结为这一点,但我开始获得大量流量到根页面、术语和隐私,其中许多都带有 /?m=0 前缀,这本身就很奇怪(我希望有人能够阐明)。
这次攻击导致了大量的超时,并且很难修复:
简而言之,我连接了 CloudFlare,然后创建安全-> WAF 规则挑战我接收大部分机器人流量的国家/地区。我还打开了基本的机器人攻击模式(付费订阅有更有效的超级机器人攻击模式)。
另一个有趣的地方是为什么我的网站会受到 DDOS 攻击。我希望我知道,但在攻击开始的同一时间,有人联系我询问购买该网站的情况。可能是让我卖掉/低价出售的策略。
It depends how the bot works, but here's what happened to my website:
Google Analytics real time report for the monk
As well as the increase in traffic you will likely see your bounce rate go sky high and average time on page significantly drop - which I'm sure can have a negative impact on SERPS.
For me it coincided with a Google update so first I put it down to that, but I started getting a lot of traffic to the root page, terms, and privacy, with many prefixed with /?m=0 which is in itself odd (and I'd love for someone to shed light).
The attack caused a great deal of timeouts and was painful to fix:
In short, I hooked up CloudFlare, then created Security -> WAF rules to challenge countries where I was receiving most of the bot traffic. I also switched on the basic bot attack mode (there's a more effective super bot attack mode with the paid subscriptions).
The other interesting point of note was why was my site subject to a DDOS attack. I wish I knew, but at a similar time to when the attack started I was approached by someone who enquired about buying the website. Possibly a tactic to get me to sell it/sell it cheap.