リストにはそれよりもはるかに多くの項目があります。何か案はありますか？
クライアントのログでこれを見かけたので、単なる偶然以上のものだと思います。
編集：いや、偶然かもしれません。「ymwears .cn」で検索すると、リファラスパムに関する他の苦情も複数見つかります。例えば、これら（1年以上前の投稿）です：Relevanssi shows weird search queries on my page | WordPress.org および Block specific referrer or agent to enter url | WordPress.org
先月、クライアントからこれらの件について苦情が寄せられました。いくつかのIPアドレスをブロックし、特定のURLを検索するIPアドレスをfail2banでブロックする設定も検討しましたが、結局何も実行しませんでした。地理的な地域によるブロックも調べましたが、それを実現するには月額20ドルのデータベースが必要らしいことが分かりました。
リファラースパムは、Google アナリティクスのような大手さえも100%完全に解決できていない、かなり大きな問題です。現時点で思いつくのは、これらのエントリを手動で削除することだけです。
これらのサイトは、少なくとも部分的には、複数の独立した Discourse サイトで同じであるようです（私たちのスクリーンショットがほぼ同じリストを示しているという事実から）。動的なブラックリストを導入するというアイデアはいかがでしょうか？ @codinghorror さんは何か提案はありますか？
私たちは長年にわたり大規模でこの問題を検出し、対処・緩和してきました。過去数年間で最も信頼性の高い方法は、ユーザーエージェント（UA）文字列（場合によっては GeoIP 情報と組み合わせて）に基づいてブロックすることです。
過去数年で数億回に及ぶ中国のボットのアクセスをブロックしてきましたが、IP アドレスのブロックは、UA 文字列に基づくクライアントのブロックに比べて、長期的にはあまり効果的ではないと気づきました。
以下は、当社のサイトの 1 つで実際に使用しているコードの抜粋です。
$user_agents = explode('|',$string_of_bad_user_agents,-1);
$hide_content_useragent = $_SERVER['HTTP_USER_AGENT'];
$IS_A_BAD_BOT = FALSE;
foreach($user_agents as $hcag) {
trim($hcag);
if (preg_match("/$hcag/i", "$hide_content_useragent")) {
$IS_A_BAD_BOT = TRUE;
break;
}
}
ほとんどの（すべてではありませんが）不正なボットは、比較的簡単に特定・ブロックできる UA 文字列を使用しています（現在の時代においてです。将来の変化については確信が持てませんが）。そのため、IP アドレスに基づいて不正なボットをブロックしようとする方法は、数年前にやめました。IP によるブロックを放棄した理由は、中国、ロシア、北朝鮮など多くの国が、自国のサーバーではなく他国のサーバーからボットファームを運営しているためです。IP アドレスは、実際の発信元や意図を示す良い指標ではありません。さらに、大規模な IP アドレス範囲をブロックすると、正当なユーザーのアクセスを遮断する可能性があります。
例えば、中国は、発信元を隠蔽し、データ取得を高速化するために（地理的に米国に近い）ブラジルや他の国から巨大なボットサーバーファームを運営しています。
WHOIS データが中国、北朝鮮、ロシア（例）の物理住所と一致することもあれば、現地の住所を使用する場合もあります。過去数年で、中国の不正なボットがブラジルの企業に登録されているケースを多く目撃しました。その際、ユーザーエージェント文字列が中国発の不正ボットと一致することを確認できました。また、これらの UA 文字列で Google 検索を行うと、他の人々も同様の UA 文字列を中国由来として特定していることがわかります。
まとめると、多くの人は不正なボット活動をブロックするために即座に IP アドレスのブロックを選びますが、高度なボットファームは他国からボットを運用することに非常に長けています。ほとんどの国で VPS を簡単に設定でき、もちろんボットが標的国に近いほど、より多くのデータをスクレイピングできます。VPS は数分で立ち上げ・終了でき、ボットソフトウェアも世界中のほぼあらゆる VPS データセンターに迅速に展開可能です。
過去数年間、UA 文字列に基づくブロック（場合によっては GeoIP 情報と組み合わせることもあれば、そうでないこともありますが）が、より信頼性の高い方法であることが証明されています。もちろん、スパマー、ボットマスター、そのエージェントも、IP アドレスを偽装してきたように、UA 文字列を偽装し始めています。
これが役立つことを願っています。
では、ボットハンティングを楽しんでください！
はい、IP ブロックが効果的ではないという点に完全に同意します。
ユーザーエージェントのブロックは、スパマーがそれを頻繁に変更しない限り、かなりうまく機能する傾向があります。
そのため、私は実際にリファラースパムされている URL そのものをブラックリスト化するという考えに至りました。
これは「このユーザーエージェントは悪いリファラを返すので信頼できない」という根拠のない仮定に基づいて何かをブロックするのではなく、「複数の Discourse サイトでこのウェブサイトがリファラースパムされているので、データベースに登録しない」という、実際にブロックしたい対象をブロックしているため、「より良い気がする」のです。少なくとも、これを回避するのはより困難です。
良い考えですね。
不正なボットや悪意のあるボットを完全に阻止する「万能な解決策」は存在しません。各サイトが、自分たちに最も適した対策を評価する必要があります。
同様の話題ですが…
主にブラックリストやスパム・不正ボットのデータベースに依存しているサイトも問題を抱えることがあります。例えば、競合サイトである www.our-arch-rival.com が気に入らない、あるいは単に怒りや不快感を与えられたとして、誰かがそのサイトをブラックリストやデータベースに登録してしまうケースです。すると、他のサイトもこの「悪影響」により、正当なサイトまでフィルタリングしてしまいます。
もちろん、ブラックリストの支持者たちは「ブラックリストサイトへ報告し、削除を依頼すればよい」と主張しますが、多くの忙しい長年運営されているサイトにとって、それは時間のかかる作業です。
一般的に、問題を分析し、シナリオに基づいた緩和策を策定することが重要です。なぜなら、すべての「敵」は異なるからです。これは孫子の『孫子』や『孫子の兵法』にある「敵を知り己を知れば百戦危うからず」という古い教訓と同じです。現実世界では状況がそれぞれ少しずつ異なり、残念ながら、システム管理者が悪意のあるまたは望ましくないサイバー活動に対する最適な緩和策を策定するには、分析能力が求められます。
これはまた、Discourse をリバースプロキシの背後で実行する良い理由でもあります。リバースプロキシは、悪意のあるトラフィックが Discourse アプリに到達する前に、それを分析、分類、制御するのに最適な場所だからです。
2020 年において、不正なボットやその他の悪意のある活動を制御・緩和しようとすることは、フルタイムの仕事になり得ます。管理者が優れた検出・緩和策を考え出すとすぐに、スパマーやスクレイパーはそれに対応し、回避策を見つけるものです。私は、これらのサイバー空間の問題は時間の経過とともに悪化する一方であり、改善することはないため、サーバーを過剰に設計し、十分な余力を確保するよう人々に助言する傾向にあります。
Ready Player One!
これこそが、IP ブロックリストを避けるべき「もう一つの理由」です。スパマーは「対策を講じている」ということを把握してしまうからです。
Cloudflare を通じてスパマーの大半をブロックできると思うのですが、ブラウザの User Agent に関するルールに何を入力すべきか確信が持てません。
@neounix "UA strings"とは具体的に何を指しているのでしょうか？また、それらを Cloudflare のファイアウォールルールでどのように活用できるのでしょうか？
でも、これはリファラースパムではないですよね？単にその URL で検索しているだけで、実際には何も実行していないはずです。あのレポートのことを完全に誤解しているのでしょうか？あのレポートは管理者以外には見られないはずです。
@pfaffman さん、おっしゃる通りだと思います。このレポートはフォーラム内での検索のみを対象としているようです。CTR も含まれており、これがリファラーレポートであれば意味が通りません。
いいえ、技術的にはこれはリファラースパムではありませんが、この特定の種類の悪用を表す適切な用語があるかどうかはわかりません。これはリファラースパムに非常に近いですが、検索クエリレポートに対してのみ行われるものではないでしょうか？
リファラースパムは決して実際に何も行わず、レポートに表示されることを目的としています。
こちらをご覧ください……
HTTP において、User-Agent ストリングは、コンテンツネゴシエーションに頻繁に使用されます。これは、オリジンサーバーがレスポンスに適したコンテンツや動作パラメータを選択する仕組みです。例えば、User-Agent ストリングは、特定のクライアントソフトウェアのバージョンの既知の機能に基づいて、ウェブサーバーがバリアントを選択するために使用されることがあります。「特定のユーザーエージェントの制限を避けるためにレスポンスをカスタマイズする」というコンテンツの調整の概念は、RFC 1945の HTTP 標準に組み込まれています。
User-Agent ストリングは、Robots 排除標準（robots.txtファイル）を使用して、ウェブクローラーがウェブサイトの特定の部分へのアクセスを除外する際の基準の一つです。
他の多くの HTTP リクエストヘッダーと同様に、「User-Agent」ストリングに含まれる情報は、ストリングがユーザーによって大きく異なる可能性があるため、クライアントがサーバーに送信する情報に貢献します。[5]
参考文献：
@Yassine_Yousfi。インターネット上には、HTTP のユーザーエージェント（UA）ストリングや、ボットやその他の悪意のあるサイバー活動を検出する際のセンサーとしてそれらを使用する方法などに関する無数のリファレンスが存在します。
ボットハンティングを楽しんでください！
注記：
- ボットユーザーエージェントの
Discourse 表示（一部の UA ストリングは切り捨てられています）は、こちらでご覧いただけます：
https://discourse.your-great-domain.com/admin/reports/web_crawlers
-
どの検出アルゴリズムも、すべてのボットを 100% の精度で検出することはできません。
-
UA ストリングは、ウェブサーバーのログファイルや他の方法からも取得できます。
関連情報：