ウェブのパブリックサービス根本的な攻撃者からの防御策は基本的にはない
こんにちは、無能です。
直近でかなり攻撃が増えていますが何となくで書き殴りしてみます。
HTTPクライアントからの根本的な攻撃防御は存在しない
そもそもですが、それぞれの防御した場合を考えます
IPアドレス
IPv6アドレスであれば良いですが、CGNAT環境下であると共用IPv4アドレスの割り当てとなり攻撃対象者以外の被害者も巻き込むこととなります。
また、IPローテーション自体は容易なので昨今攻撃用途で使われやすい世界的に保有IPが多いUSの格安VPSや、中国系のクラウド環境から数千単位でIPアドレスを用意してDDoSが行われるのもメジャーになってきておりAS Number単位で遮断したとしても結局は中国展開しているサービス等があれば中国系クラウドのIPアドレス遮断も根本的ではないことや中国ユーザがちょっと可哀想です。
基本的に中国のクラウド環境自体が他国から悪用されることが非常に多い為、一概に遮断していい対象とは私は思いません。
そもそもの私の考えとしてワールドワイドウェブの属しているサービス時点で、サービスを楽しむ人が一人でもいるならば一概に遮断したくありません。
私だって、BiliBiliの動画は時々見たりするし、米国のサービスだって見ます。
User-Agent
基本的には論外というか、ほぼリクエストヘッダー評価自体をアクセス制限として評価するのはほぼ無意味と思っている為あまり書くことはありません。
詐称はいくらでも出来る為、端的に評価する UA だけの基準で遮断は出来ません。
行うとすれば、今私がこのサイトでやっているような googlebot としての UA を自称してその逆引きホストが *.googlebot.com または *.google.com じゃなければ完全遮断、とかも出来るでしょうが自前実装か、CDN側で似たような実装がされていたりするのか？それは確認する必要があります。また、Googleは公式ではそういっているけれども、実は逆引きホストでそれら以外のホストからで正規botをGoogleが飛ばしているのも少なからずいるので完全にこの評価だけで出来るという訳でもありません。
ちなみにこんなカスみたいなサイトでもGooglebotを自称してきている輩はこれだけいます
fail2ban report - fake-googlebot
国遮断
何か攻撃があった場合の暫定措置としてはなり得る、でしょうが恒久的な対応としては意味を成さないというかこれは理由はIPアドレス単位と同じなので割愛します。
ただし、国内サービスだけとして展開している場合は別に有益ではあるかと思います。
TLS Fingerprint
TLS指紋も容易に偽装自体は可能です。
なぜか、というかブラウザでビルドされている暗号ライブラリと同様のものを組み込み等をHTTPクライアント側にしてしまえばブラウザの指紋を偽装できてしまいます。
効果は完全に無いと言えば、微妙ですが例えば同じ暗号ライブラリ等を使っていて正常なbotがリクエストを投げているとした場合誤遮断になります。
多数のHTTPクライアントと重複するリスクが高い為、端的に評価出来ません。
そのため、判断基準の一つとして利用出来るため一つだけの条件として利用するより他のルールとして複合的に考えるのであれば、有益性はあるにはあるとは思います。
Cloudlfare Challenge / PoW Challenge
Cloudflare Challenge自体はヘッドレスブラウザも使わずに簡単にバイパス出来ます。
Anubisはどうかわかりませんが、UX的にあまりよくなくクライアント側の演算を求める必要がありページ遷移時に結構ストレスがかかります。
ある意味で言えば、JS Challengeと複合的な保護にはなり得るといえばなります。実際に、昨今のリークフォーラムも独自実装の PoW Challenge を実装しているものも増えてきている為、どこで PoW Challenge を利用するか、そもそもDoS対策で行うならばこの PoW Challenge というアプリレイヤーに近い部分で保護するかと言われると微妙なので利用シーンをかなり限定して実装すれば、出来る限りUXを損なわない形で比較的守りの形のフロント実装が出来るかもしれません。
Pay Wall
ペイウォールしたいサービスは限られるので割愛。
HTTPキャッシュ
そもそもこの記事にいれるか？と思った項目でちょっと迷ったが入れました。
CDNでのキャッシュでOriginまでの到達性で言えば、GET 等では有益ではあるでしょうが基本的にもうどこも導入しているのでは？という感想です。
保護としてはあまり考えず普通に観点としては、ユーザ体験の向上をさせるためと逆にエラー系を返したときのフラッド対策としては有益なのでアプリに影響しないパフォーマンス向上という観点で利用をしたほうがいいように思います。
レート制限
サービスによって結構 key 自体が異なるのでちゃんと実装ルールは確認したほうがよさそうです。あくまで Nginx の場合であれば、全体のトラフィックだったり、URIごとだったり、IP単位だとか複合的にも可能だったりするので DoS 対策の観点で言えば有益かと思います。
じゃあどうする？
いくつかのレイヤーで分けて、そして複合的な条件として対応するしかないと思います。
現段階で考えているのはAS Number単位での信頼性高いクラウドプロバイダー三社と、各社SNS等のクローラの許可リストを入れてそれ以外はちょっと厳し目にする、とか。
基本的な攻撃者パターンとして確実におかしいリクエストパターン各種
.envetc スキャン等してきたIPgooglebot自称で間違いなくおかしいやつPOST/PUTetc でありえないリクエストぶち込んでくる/login配下とか、セッション生成出来るパス先でめちゃくちゃなリクエスト投げてくる
等、一発遮断でもいいのでは？という。ぶっちゃけ格安VPS系は悪用されているパターンがかなり多いので一括遮断したい気持ちもありますが、私も格安VPSにVPNサーバ建ててその出口IPからサイト閲覧すること結構あるのでやりすぎかなあと思いつつサービスによってはいいのかもしれません。
また、昨今のオーディオデバイス検知でのFingerprintなどが非難されていましたが実際には有益だとは思うので検出出来なかった場合に遮断は結構ありかとは思います。いずれかは偽装経路出来るのでしょうが・・・
GPU FingerprintやAudio Finderprint等、これから複合的にユーザデバイスとしての検出として採用されていく未来があるのかもしれません。