web-dev-qa-db-ja.com

DoS攻撃の可能性があるサイトをスパムするユーザーエージェントのないFacebookクローラー

Facebook（ipv6の末尾が：face：b00c :: 1）に登録されたクローラーは、私たちのサイトを非難しており、わずか20分で数万件のヒットがありました。ヘッダーにユーザーエージェントがないことに気付き、自分自身を保護するためにcloudflareにルールを実装しました。

クローラーにパッチを適用し、認識されたクローラーであるユーザーエージェント「Externalhit/1.1」を追加したようです。今、彼らはルールを回避している、私は15分で11,000ヒットを見ています。多くの場合、同じページに複数回！これはデータベースに障害を与えています。顧客がサイトを合法的に使用することを防ぎます。

これを試して改善するために、FacebookのすべてのIPに広範なブロックを実装しましたが、そのためすでにビジネスを失っている可能性があります。

私の質問は次のとおりです。何がそれを引き起こしているのでしょうか？ Facebookから回答を得るためのチャネルはありますか、それとも合法的なルートがありますか？

ツイートへのリンク： https://Twitter.com/TicketSource/status/969148062290599937 FB開発者グループとFacebook担当者を試し、サポートに転送されました。チケットを提出しましたが、返信はありません。

ログサンプル：

2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5394 2a03:2880:30:7fcf:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5362 2a03:2880:30:afd1:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5378 2a03:2880:30:7fcf:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5425 2a03:2880:30:2fea:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5394 2a03:2880:30:2fea:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5659 2a03:2880:30:2fd8:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5659 2a03:2880:11:dff3:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /whitedreamspremiere - 443 - facebookexternalhit/1.1 - 200 0 0 5048 2a03:2880:2020:bffb:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4633 2a03:2880:3020:1ffd:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4727 2a03:2880:3011:afc5:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4977 2a03:2880:3020:1ffd:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /event/FDMEJD - 443 - facebookexternalhit/1.1 - 200 0 0 4868 2a03:2880:2111:1ff9:face:b00c:0:8000

Edit2：支払いプロセスからURLが見つかったため、これらのIPはクロールしています。そのため、彼らはリンクをたどり、セッションのみのURLになりました。

Edit3：Facebookは バグを確認して修正を探している のようです。

web-crawlersfacebookcdncloudflareddos
7
L Martin

https://developers.facebook.com/bugs/1894024420610804

Facebookからの回答によると、Facebookで共有されるページは、コンテンツが共有される場合、Facebookクローラーがその共有数の10〜20倍のトラフィックを増やすことを期待する必要があります。

これは、Facebookがアクセスするたびにコンテンツをスクレイピングしているように聞こえますが、キャッシュはほとんどまたはまったくありません。

私たちの場合、Facebookはおそらく広告全般に適していますが、共有されているデータベース集約型のページを実行すると、これは大きな負担になります。サービス拒否攻撃を防ぐために、トラフィックをレート制限する必要があります。 Facebookのアクティブボットに対するリソース集約的な回答。

1
L Martin

情報筋によると、Facebookはクローラーを使用せず、スクレーパーを使用しているため、Facebook/Externalhitはrobots.txtのクロール遅延を尊重していません。

Facebookでページの1つが共有されるたびに、メタタイトル、説明、画像のためにサイトがスクレイプされます。

私の推測では、Facebookが15分でサイトを11,000回スクレイピングしている場合、最も可能性の高いシナリオは、誰かがFacebookスクレーパーをサイトのDDOSに悪用する方法を見つけたということです。

おそらく彼らはあなたの共有リンクを何度もクリックするボットを実行しており、Facebookはそのたびにあなたのページをスクレイピングしています。

私の頭上で、私が最初にやろうとすることは、Facebookがスクレイピングしているページをキャッシュすることです。これはhtaccessで実行できます。これにより、キャッシュの有効期限が切れるまで、すべての共有でページをロードしないようFacebookに指示できます。

あなたの問題のため、私はhtmlの有効期限を通常よりも長く設定します

.htaccess内：

<IfModule mod_expires.c> 
  ExpiresActive On
  ExpiresDefault "access plus 60 seconds"
  ExpiresByType text/html "access plus 900 seconds"

</IfModule>

Htmlを900秒で期限切れに設定すると、Facebookが個々のページを15分に1回以上クロールするのを防ぐことができます。

編集：クイック検索を実行し、数年前に書かれたページを見つけました。このページでは、あなたが今直面している問題について議論しています。この人は、Facebookスクレイパーが共有機能を使用してWebサイトをあふれさせる可能性があることを発見しました。彼はそれをFacebookに報告したが、彼らはそれについて何もしないことを選んだ。おそらくこの記事はあなたに何が起こっているかをより明確に伝え、おそらくあなたが状況にどのように対処したいかに関して正しい方向に導くことができるでしょう：

http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/

7
Michael d