来自用户代理Mozilla / 5.0(Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.10)的非法流量Gecko / 2009042316 Firefox / 3.0.10(.NET CLR 3.5.30729)


31

这是一个瞬息万变的事件,尚无答案。

请不要将您的发现或假设作为答案;为您实际有答案时保留答案字段。

如果您要添加新内容,请直接在问题中进行编辑。


自从今年年初以来,我与用户代理的通信量很大:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729).

我的访问日志显示该用户代理的40%-60%。这很奇怪,因为用户代理使用的是Firefox 3.0.10浏览器(2012年有人在使用该浏览器吗?在普通网站上绝对不是40%-60%的访问者)。

此外,日志还显示该用户代理仅请求HTML文档,而没有引用的资产(如图像,css,js文件)。

我检查了那些请求的IP(使用该UA)。它来自世界各地。我认识到这些IP有时具有移动用户代理。

因此,我怀疑是一个移动应用程序正在执行很多“蜘蛛请求”。最好知道来自该用户代理的流量的根本原因。

谁能找出根本原因?

在过去的几周中,我们认识到来自该UA的流量下降了,其他流量增加了。看起来僵尸程序/爬网程序现在正在使用更通用的UA,因此更难以阻止。我看到其他人在回答这个问题时说了这一点,但是当serverfault决定重新安排这个问题时,它就被删除了。

旧答案作为参考


更新

我经营着自己的人流量很高的网站,最近一个月左右的时间在我的apache日志中看到了完全一样的东西(我还没有机会进一步检查)。很明显,所有请求中有40%是我所看到的百分比。

而且我还注意到,请求似乎总是说请求的浏览器不支持gzip压缩-导致所有网页请求都未经压缩发送,并且我们的带宽使用率飙升!

但是到目前为止,我仍无法确定到底发生了什么-到目前为止,我一直怀疑可能是某种代理服务器或用于发送伪造的useragent字符串的移动设备。

编辑添加:进行了更多研究,它可能是防病毒软件:http : //www.webmasterworld.com/search_engine_spiders/4428772.htm


来自jamur21的更新

是的,我们注意到多个站点之间的流量相似。

我们仍在寻找根本原因,但我们的一些发现包括:

  • 如果是蜘蛛,那就做得很差。似乎在每个域中锤击了一个或两个URL一段时间(可能是几个小时),直到它移到另一个URL。但是,内容总是相对“最新”的,这使Google新闻成为一个因素,正如Dee在其回答中张贴的链接(我们所有的网站都是新闻网站)中所假定的那样。

  • 尽管IP在地理位置上分散了,但对我们来说,大多数似乎都位于原始站点附近(我们的大多数站点都是本地新闻媒体,因此它们不会吸引大量的国家流量)。几乎没有任何请求来自美国以外。同样,这也使从Google新闻中获取URL的信誉得到了保证(我猜通过邮政编码对Google新闻进行本地化的人会看到我们的内容)。

  • 在大多数情况下,请求可以作为背景噪音(尽管特别嘈杂)被注销,但是一天几次,我们都会遇到麻烦,仅此UA就会在大约15-30分钟的时间内提供约100mbps的流量。

  • 不幸的是,尽管Google新闻似乎是发现这些URL的可能载体,但我们所看到的一切都是偶然的,我们仍然没有确切地知道如何锤击这些URL的方式或原因。


来自班诺湾的更新

我们有一个大型新闻网站-我们的故事每周都会被Google新闻收录几次。自11月下旬以来,我们一直在从该来源获得流量-并且流量每周都在增长-2月可能有3000万次展示。

Google新闻美国版首页的出现是这种流量的诱因-据称约有75%来自美国IP。但是,无论如何,它都在努力使自己模糊。那并不友好。

我们也没有找到吸烟枪-但是主要的安全供应商已经同意代表我们进行进一步调查。


Artem Russakovskii的更新

新闻网站(AndroidPolice.com)刚发生同样的事情。在这些随机请求中,大约有10分钟的时间使QPS超过了我们平均水平的5000%(5000qps,这是Linode的NodeBalancer的限制)。当请求吞噬了I / O和网络时,CPU开始空转-这是一个真正的DDOS。

我真的很想深入浅出,但此刻似乎完全令人困惑。


马克更新

只需加上+1。我们在我们的网站上看到了相同的行为。此处没有大量新信息可添加,但这是我们的流量的大致形状:

  1. 流量高度分散。流量来自约6万个唯一IP。
  2. 绝大多数流量都点击了一个网址,通常是Google新闻中列出的最新网址(尽管Google新闻并不一定总是矢量)
  3. 所有这些流量都来自此线程中提到的同一Firefox / 3.0.10用户代理,尽管我们在此发现了一些奇怪的移动代理。
  4. 来自此代理的所有流量均不包含引荐来源数据。
  5. 每周爆发一次或两次,持续30-60分钟,然后消失。

从更新唐爱尔兰

最后的帖子是4月13日,但访问量当然还没有结束。最奇怪的部分可能是这样的事实,即任何值得他一掷千金的恶意软件作者都可以(肯定会)使用现代浏览器中的用户代理字符串,从而使阻止用户代理防御毫无价值。这个事实使它看起来好像是一个“无害的”新闻聚合器或其他应用程序。不过,到目前为止,我还无法得出任何真实的结论,希望任何有信息的人都可以在这里发表。

我们看到的是相同的模式,谷歌新闻报道了一个故事,然后请求该故事的访问量激增(但没有附件文件,例如图像)。出站响应流量会导致峰值,这些峰值可能会使网络饱和(或者确实如此,直到我们仅以503错误开始响应为止)。这些攻击(我们还能称其为什么?)平均持续约30分钟,但非常受欢迎的故事可能会在一个小时或更长时间内出现高流量(我所说的是firefox 3.0.10流量,当然正常流量也仍然很高)一阵子)。

在一个小时的时间内(对于负载平衡组中的单个服务器),我们看到了200,000个请求,其中97,000个是firefox 3.0.10请求,几乎占所有请求的50%。而且,当您考虑通常一个页面对主文件和附件文件生成10个或更多请求时,则97,000个织机要大得多。我注意到在97,000个地址中,有51,000个唯一IP地址。我所说的是一个小时(实际上是接近45分钟)。造成这种情况的原因非常普遍。


来自user119708的更新

我们在庞大的法国高科技新闻网站上也遇到过同样的问题。

每当新闻发布并在Google新闻上可见时,IP和用户代理“ Mozilla / 5.0(Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10 )Gecko / 2009042316 Firefox / 3.0.10(.NET CLR 3.5.30729)”。

所有IP地址似乎都位于法国或法国国家,并且没有推荐人。看来这是个机器人,但为什么一个远程地址在几分钟之内必须根据同一新闻返回50或100次?可能是受感染的计算机吗?当新闻在Google新闻上可见时,为什么会出现这种现象?Google对这种奇怪的流量负责吗?

如果本主题中的某人找到了解释,我认为这将帮助许多中型或大型网站控制其流量!

编辑:http : //2bits.com/botnet/botnet-hammering-web-site-causing-outages.html 如果确实是受感染的计算机,考虑到所涉及的地址数量,这将非常令人担忧。我们将为Apache实现此脚本以阻止所有流量:

# Referer is empty
RewriteCond %{HTTP_REFERER} ^$

# User agent is bogus old browser
RewriteCond %{HTTP_USER_AGENT} "Gecko/2009042316 Firefox/3.0.10"

# Forbid the request
RewriteRule ^(.*)$ - [F,L]

来自埃内斯托的更新

西班牙的一般新闻网站,几天以来注意到一些无关的新闻出现了高流量。

无论是谁,它都会加载完整的HTML,因为我们注意到它是由于“页面视图”计数而导致的,因此,一旦加载页面,我们就会通过数据库更新来增加计数。

我们仅注意到每天定位一个或两个URL。

几天之内,同一URL上的大量请求(7000-12000)一天中从不同IP分发。未来几天还会定位其他网址。

没有推荐人。

目标文章出现在Google新闻上,但我们不能保证它与之相关。

Google Analytics(分析)不将其视为合法流量。我们的文章点击率超过8000,而GA仅报告25个左右(我假设javascript尚未得到解释)。


旧专业版更新

为您添加一些数据点。

Bots vs. Browsers尚未将此UA视为机器人。

在我所记录的流量最高的网站上,截至2012年5月的使用情况显示,该UA的流量不到1%。UA请求的很大一部分看起来是合法的(例如,加载所有预期的资源)。这基本上与2012年2月相同。

该网站的首页很少更新,并且所有动态内容都被robots.txt阻止。


这可能来自Genieo。他们已更新其应用程序以使用新的用户代理:Mozilla / 5.0 +(兼容; + Genieo / 1.0 + http://www.genieo.com/webfilter.html)。它的命中方式与原始用户代理相同,但现在他们似乎可以识别自己。如果您在他们的用户代理中查看URL,他们甚至承认他们可能已经或可能仍在为某些网站产生过多的流量。- dflaw


Mike Fagan的更新

数周以来,我们一直在努力应对所谓的DDOS攻击。我们才刚刚开始将Genieo视为这些攻击的用户代理。以前,我们看到过“ Mozilla / 5.0(Windows; U; Windows NT 5.1; zh-cn; rv:1.9.0.10)Gecko / 2009042316 Firefox / 3.0.10(.NET CLR 3.5.30729)”和来自“ Mozilla / 5.0(Windows NT 6.1; rv:11.0)Gecko / 20100101 Firefox / 11.0”。超过1万个不同的IP,每天最多有1百万个请求到仅3或4个页面,而同一IP则请求100次以上的页面,并且没有提取任何其他资产或广告。我的发现是这些IP实际上都没有转到我们网站上的任何其他页面。

我联系了Genieo,这是他们的回复:

“感谢您与我们联系。

Genieo的旧版本可能导致您描述的流量负载。对此造成的任何不便,我们深表歉意。我们昨天发布并更新了此版本,以解决此问题,应用程序中的数据负载将在接下来的24小时内消失。我们相信,通过向新用户介绍您的网站,我们可以为您的网站提供良好的服务。我们没有适当地评估,随着我们的安装量的增长,它可能会导致某些场所的过载。

Genieo是个人报纸或智能RSS阅读器。它是具有智能语义个性化过滤功能的客户端RSS阅读器。Genieo应用程序遵循用户喜欢的站点中的RSS数据,通过执行语义分析来“阅读”文章,并针对感兴趣的用户区域对其进行过滤。如果文章符合用户兴趣,则应用程序将在用户主页中显示文章的标题和摘录。单击标题将转到文章的站点-您的站点。Genieo代理是自主的(出于隐私原因);它运行在最终用户计算机上,这就是为什么您看到代理从许多不同的IP访问您的站点的原因。

Genieo的大多数数据来自用户的常规RSS提要,但是Genieo还从用户以前未注册的新新闻站点中添加了一些内容(出于偶然性和多样性)。Genieo算法查找“热门”文章,Twitter热门歌曲,观看最多的YouTube以及Google新闻精选,并检查它们是否符合用户的兴趣

我们不知道这会导致某些站点出现负载问题。一旦引起我们注意,我们将使用防止负载峰值的新版本更新当前用户。

最好的祝福,

-多坦

PS:过去(由于技术错误),我们确实使用过“ Mozilla / 5.0(Windows NT 6.1; rv:11.0)Gecko / 20100101 Firefox / 11.0”,但是当前所有Genieo用户都应使用Genieo用户代理(对于最近几周)”


您能否将出现在日志中的某些IP地址添加到问题中?
ricmarques 2012年

我不确定这是否是AVG防病毒软件-因为AVG已解决了该问题。此外,我仍然认为某些移动应用程序很可能导致该流量-一些新闻聚合器应用程序(例如skygrid.com之类的应用程序-但它不是skygrid的,因为它们使用了正确的UA)。
user114293 2012年

这里是一些示例IP:196.202.255.1 59.164.38.248 67.4.252.169 24.224.194.26 67.4.39.99 49.123.100.148
user114293 2012年

是的,我们注意到多个站点之间的流量相似。我们仍在寻找根本原因,但我们的一些发现包括:-如果是蜘蛛,那就做得很差。似乎在每个域中锤击了一个或两个URL一段时间(可能是几个小时),直到它移到另一个URL。但是,内容总是相对“最新”的,这使Google新闻成为一个因素,正如Dee在其回答中张贴的链接(我们所有的网站都是新闻网站)中所假定的那样。-尽管IP分布在地理位置上,但对我们来说,大多数IP似乎都位于原始站点附近(大多数
jamur2 2012年

我们有一个大型新闻网站-我们的故事每周都会被Google新闻收录几次。自11月下旬以来,我们一直在从该来源获得流量-并且流量逐周增长-2月可能有3000万次展示。Google新闻美国版首页的出现是这种流量的诱因-据称约有75%来自美国IP。但是,无论如何,它都在努力使自己模糊。那并不友好。我们也没有找到吸烟枪-但是主要的安全供应商已经同意代表我们进行进一步调查。
巴诺湾

Answers:


1

我认为dflaw用户找到了它。它是Genieo的软件。我们做了一些测试并与他们联系。所有结果均在此处发布。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.