
キーポイント:
*訪問者のPTRを確認するスクリプトの実装。
*マップブランチを使用したIfIsEvilスタイルのnginxの構成。
*マップ変数の場所名。
* try_files / nonexist $ map_varによるブランチコントロール。
負荷の高い人気のあるサイトの多くは、ライブの訪問者に加えて、有益な効果はないが、偽のトラフィックを作成し、既にロードされたシステムに負荷をかけるさまざまなパーサー、ボット、およびその他の自動スキャナーによって訪問されるという事実に苦しんでいます。 この場合、私は検索ボットを意味するわけではありません。検索ボットはプロジェクトをロードすることが多いのですが、標準化されておらず、単にプロジェクトに必要です。
クライアントの1人は、1日の特定の時間に雪崩のような負荷増加の問題を定期的に経験しました。 定期的に、1日に1回、さらに頻繁に訪問が流入し、サーバー上のLAが大幅に増加しました。 スプリアストラフィックに対する保護を構築することが決定されました。
スプリアストラフィックには、特定のパターンの動作とプロパティがあることがわかりました。
*リクエストソース別-Amazon、Torサブネット。
*エントリポイント別-商品セクションへのほとんどのリクエスト。
* UserAgentによると、ボットの主要部分はUA検索エンジンGoogle、Yandex、Bingによって送信されましたが、客観的には送信されませんでした。
*リファラーによる-基本的にリファラーは空でした。
チェック、制限、およびロックの実装:
*ホワイトリストに既知のIPを手動で追加
*以前に侵害されたIP-ブラックリスト
*ホワイトリスト以外のすべてのlimit_req_zoneを制限する
* PTRレコードが検索エンジンの実際のPTRレコードに準拠しているかどうかをUA検索エンジンからの訪問者に確認し、認証済みユーザーのホワイトリストに入れて、常に許可します。
* LAのしきい値「攻撃」の増加:
** UAをブラックリストに登録せず、PTR検証に合格してブロックしません。
**アクセスログでリファラーの再現性を確認し、指定されたエントリ数を超えるリファラーで訪問者をブロックします
**残りをcaptchaで確認し、成功した場合は解決します。
最初の3つのポイントは一般的なソリューションであるため、PTRで訪問者をチェックし、try_files / nonexist $ map_varコンストラクトと複雑なマップを使用してnginxを構成することに集中します。
検索エンジンの実際のPTRレコードとPTRレコードのコンプライアンスについて、UA検索エンジンからの訪問者を非同期にチェックするスクリプトを実装しました。
cronで1分間に1回実行されます。 UAからのIPビジターの一意のリストに基づいて、検索エンジンはPTRをチェックし、第2レベルのドメイン名をチェックします。 ドメインが一致する場合、ホワイトリストにIPを追加し、そうでない場合はブラックリストに追加します。 リストをチェックするとき、スクリプトは、検証プロセスを高速化するために、以前に検証されたIPのPTRをチェックしません。 これにより、高速でアクセスログがいっぱいになった場合でも、アクセスログからIPリストを1分ごとに確認できます。 ブラックリストへのエントリは、大規模なNATネットワークでの共通IPの永続的なブロックを除外するために、ブロックリストから一定の削除時間で入力されます。
したがって、nginx configに含まれるptr_blacklist.mapおよびptr_whitelist.mapファイルを作成して維持します。
それは毎分始まります。
UAおよびPTRコンプライアンス検証スクリプトリスト: リファラーの頻度と、次の形式のファイルreferer-block.confの形成を確認するスクリプト:
~domain.ru 0; ~… 1; ~… 1;
それは毎分始まります。
nginx設定ファイルは、シンボリックリンクとして、通常および高LAモードで動作する2つのファイルのいずれかを指します。
モードはCronから毎分実行されるスクリプトによって切り替えられます
構成の一部は、メイン構成ファイルに含まれる別のファイルに移動されます。
vhosts.d / map.domain.ru.incの両方のモードの一般的な構成パラメーターを含むファイル: map_hash_bucket_size 128; geoip_country /usr/share/GeoIP/GeoIP.dat; limit_req_zone $newlimit_addres1 zone=newone:10m rate=50r/m; map $whitelist-$remote_addr:$remote_port $newlimit_addres1 { ~"^0" $binary_remote_addr; ~"^1-(?<match_rap>.*)" $match_rap; } geo $whitelist { default 0; 91.205.47.150 1; 194.87.91.154 1; 83.69.225.78 1; 77.88.18.82 1; 91.143.46.202 1; 213.180.192.0/19 1; 87.250.224.0/19 1; 77.88.0.0/18 1; 93.158.128.0/18 1; 95.108.128.0/17 1; 178.154.128.0/17 1; 199.36.240.0/22 1; 84.201.128.0/18 1; 141.8.128.0/18 1; 188.134.88.105 1; 89.163.3.25 1; 46.39.246.91 1; 84.21.76.123 1; 136.243.83.53 1; 77.50.238.152 1; 83.167.117.49 1; 109.188.82.40 1; 79.141.227.19 1; 176.192.62.78 1; 86.62.91.133 1; 144.76.88.101 1; }
構成ファイルのリスト
通常の操作の主な構成はvhosts.d / fpm.domain.ru.noddosです。 include vhosts.d/map.domain.ru.inc; map "$searchbot:$valid_addr:$bad_referer:$bad_query" $root_location_p1 { default @allow_limit; "~^1:" @allow; "~^2:1" @allow_limit; "~^0" @loc_403; "~^2:0" @loc_403; "2:2:1:0" @loc_403; "2:2:1:1" @loc_403; "2:2:0:1" @loc_403; } map "$searchbot:$valid_addr:$bad_post_referer:$bad_query" $root_only_location_p1 { default @allow_limit; "~^1:" @allow; "~^2:1" @allow_limit; "~^0" @loc_403; "~^2:0" @loc_403; "2:2:1:0" @loc_403; "2:2:1:1" @loc_403; "2:2:0:1" @loc_403; }
高いLA vhosts.d / fpm.domain.ru.ddosモードの構成: include vhosts.d/map.domain.ru.inc; map "$searchbot:$valid_addr:$bad_referer:$bad_query" $root_location { default @main; "~^1:" @allow; "~^2:1" @allow; "~^0" @loc_403; "~^2:0" @loc_403; "2:2:1:0" @loc_403; "2:2:1:1" @loc_403; "2:2:0:1" @loc_403; } map "$searchbot:$valid_addr:$bad_post_referer:$bad_query" $root_only_location { default @main; "~^1:" @allow; "~^2:1" @allow; "~^0" @loc_403; "~^2:0" @loc_403; "2:2:1:0" @loc_403; "2:2:1:1" @loc_403; "2:2:0:1" @loc_403; } map "$allowed_country:$allowed_cookie" $main_location { "1:0" @allow_limit; "1:1" @allow_limit; "0:1" @allow_limit; default @restrict; }
まとめ
このソリューションにより、クライアントが偽のトラフィックからプロジェクトを保護し、サーバーの安定性を向上させるのを支援しました。
投稿者:Marat Rakhimov、トップシステム管理者