Botnetトラフィックをデータベース到達前に止める

多くのアプリケーションスタックは、基本的に「丁寧」に作られています。リクエストが届くと、ルーターがコントローラーへ渡し、コントローラーがデータベース接続を開き、クエリを実行し、レスポンスを返す。人間の利用者に対しては、これで問題ありません。しかしbotnetにとっては、これほど都合のよい構造はありません。

分散型のbotnetは、必ずしも脆弱性を突く必要がありません。必要なのは、アプリケーションが「はい」と言い続けることだけです。ログインフォームにも、検索エンドポイントにも、パスワードリセットメールにも、コネクションプールからの次の接続にも、ひたすら応じてしまう。トラフィックがORMに届くころには、すでにTLS、セッション参照、データベース往復のコストを支払っています。それが1分あたり何千ものノードから押し寄せるわけです。

最も安いリクエストは、処理しないリクエストです。エッジで行うIPレベルフィルタリングの考え方は、まさにそこにあります。

IPレイヤーで見るbotnetの実態

botnetのトラフィックは、1つのIPアドレスから来ることはほとんどありません。多数のアドレスから分散して届き、その内訳はおおむねいくつかのパターンに分けられます。

• 侵害された住宅向けホスト。 家庭用ルーター、IoTデバイス、感染したデスクトップ端末などです。1台あたりの量は少なくても、全体では膨大になります。
• 借り物のデータセンターリソース。 安価なVPSを大量に立ち上げるパターンです。通常の顧客が、AWS、OVH、Hetznerのレンジからあなたのチェックアウト画面を閲覧することは、まずありません。
• 商用proxyネットワーク。 住宅向けproxyやモバイルproxyのプールが、ギガバイト単位で再販売されています。IPベースのブロックを回避する手段として売られているものです。
• 公開VPNおよびTOR出口ノード。 プライバシーを重視する正当なユーザーにも使われますが、不正利用での出現率も高くなります。

もちろん、これらがすべて自動的に悪意あるものだという意味ではありません。データセンターIPは、自社で依頼した監視プローブかもしれません。VPN出口ノードは、ホテルのWi-Fiを使っている顧客かもしれません。だからこそ、判断は一律のブロックリストに任せるのではなく、自社側で下すべきです。必要なのは分類であり、その分類に対して自社のポリシーを適用することです。

データベースの後ではなく、前で止める

個々のシグナルの精度以上に重要なのが、処理の順番です。同じログインエンドポイントでも、次の2つでは負荷のかかり方がまったく違います。

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

パスワードハッシュは、意図的に遅く作られています。それが本来の役割だからです。しかし、保護されていないログイン画面にクレデンシャルスタッフィングが仕掛けられると、このセキュリティ機構そのものがDDoSの増幅要因になります。IPによる判断をその前段に移せば、攻撃ノードにはハッシュマップ参照程度のコストで403を返せます。一方で、データベースのコネクションプールは正規顧客のために空けておけます。

同じ考え方は、全文検索インデックスを叩く検索エンドポイント、トランザクションメールを送るサインアップフォーム、試行のたびに監査ログを書き込むエンドポイントにも当てはまります。

壁ではなく、現実的なポリシーを作る

怪しいものをすべて強制ブロックすると、サポート窓口に不満が殺到します。各IPアドレスにリスクスコアと種別が付与できるなら、段階的な対応にしたほうがうまく機能します。

• 黙って許可する。 リスクスコアの低い住宅向けISPや法人向けISPのアドレスです。実トラフィックの大半はここに入ります。
• 摩擦を加える。 VPNやTOR出口ノードについては、サインアップ、パスワードリセット、支払い先変更など、重要操作に限って追加確認を求めます。チャレンジを表示する、メール確認を必須にする、無料トライアルの自動付与を見送る、といった対応です。
• 強めにスロットリングする。 人間向けの画面にアクセスしてくるデータセンターやホスティングレンジです。正当な連携であれば、ログインフォームではなくAPIキー付きのAPIを使うべきです。
• エッジで拒否する。 認証系を激しく叩いている既知の悪用proxy基盤や、すでにIP単位の上限を超えているアクセスです。

重要なのは、step 4を最小のバケットにすることです。これをデフォルトにしてはいけません。目的は、不正利用のコストを引き上げることであって、プロダクトを利用不能にすることではありません。

スタックのどこでチェックするべきか

配置場所は大きく3つあります。効果が高い順に並べると、次のようになります。

• CDNまたはリバースproxy。 最も早い地点です。リクエストはアプリケーションサーバーに到達しません。明らかに悪質なレンジを一律に扱うルールに向いています。
• アプリケーション内のミドルウェア。 ルーティングより前、データベース呼び出しより前に動きます。/loginでは厳しく、/pricingでは緩くする、といったエンドポイント別の細かなポリシーはここに置くのが適しています。
• ビジネスロジックの内部。 アカウント文脈が必要な判断に使います。たとえば、これまで特定のモバイルキャリアからしか使われていなかったアカウントに、突然データセンターIPからログインがあった場合にフラグを立てる、といったケースです。

多くのチームがまず導入すべきなのは、真ん中のミドルウェアです。ルーターの手前に数行加えるだけで、その背後にある処理全体を守れます。

積極的にキャッシュし、障害時は通す

IPレピュテーションチェック自体を障害要因にしないために、運用上のルールが2つあります。

アドレス単位でキャッシュする。 botnetは同じノードを繰り返し使います。短いインメモリTTL、つまり日単位ではなく分単位のキャッシュを持たせるだけで、何千ものリクエストを1回のlookupに圧縮できます。再訪する攻撃元に対しては、追加レイテンシもマイクロ秒単位に抑えられます。Guardaがサーバー側でlookupをキャッシュしているのも、まさにこのためです。キャッシュ期間は設定できます。

障害時はfail openにし、ログは大きく残す。 レピュテーションサービスに到達できない場合は、リクエストを通し、その事実を記録します。第三者サービスの不調でチェックアウトが止まるような不正対策は、不正そのものより高くつくことがあります。fail closedは、出金のような本当に高リスクな操作に限るべきです。

導入後に見るべき指標

まずはlog-onlyモードでフィルターを有効化し、1週間分のトラフィックを観察します。そのうえで、ブロックを有効にした1週間と比較します。

• データベースに到達する前に拒否されたリクエストの割合。
• 不正アクセスが集中する時間帯におけるデータベースのコネクションプール逼迫度。
• 1時間あたりのログイン失敗回数。
• 「ログインできない」といった内容のサポートチケット数。これはfalse positiveのカナリアです。
• サインアップから認証済みアカウントに至る比率。使い捨てのデータセンター由来サインアップが止まると、通常は大きく改善します。

最後の2つが悪い方向に動くようなら、全体を止めるのではなく、該当するティアを緩めるべきです。

正直な限界

IPレピュテーションはあくまで1つのレイヤーであり、万能の防壁ではありません。住宅向けproxyプールは、実在する消費者向けアドレスをローテーションするため、顧客のアクセスと見分けがつかないことがあります。キャリアグレードNATでは、1つのモバイルIPの背後に何千人もの利用者がいる場合があります。予算のある攻撃者は、予算のない攻撃者よりも常にクリーンなインフラを見つけてきます。

それでもIPフィルタリングが確実に効く領域はあります。安価で大量に飛んでくる攻撃、つまりレンタルサーバーや使い古されたproxyリストから走るスクリプト型の洪水を取り除くことです。そうすることで、より遅く、より賢い防御策、たとえばデバイスフィンガープリンティング、行動分析、MFA、アカウント単位のレート制限は、はるかに小さく、より精査に値する母集団だけを相手にすればよくなります。

現実的な勝ち筋はそこにあります。突破不能な境界を作ることではなく、攻撃を受けている最中でもデータベースがクエリに応答し続けられる状態を保つことです。

Guardaのトップページにある無料チェックを使えば、任意のIPアドレスについてproxy、VPN、TOR、ホスティング、リスクスコアの各シグナルで分類できます。同じ呼び出しをルート手前のミドルウェアに組み込めば、実運用にもそのまま活用できます。