Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

AWS WAFで活用するJA3/JA4フィンガープリント

このページはEnglishDeutschEspañolFrançaisItalianoPortuguêsでもご覧いただけます。

By Tyler WengerdApr 10, 20259 min read
Tyler Wengerd

About Tyler Wengerd

Cloud Architect with 10+ years of cloud expertise, both on AWS and GCP. Focused on security, networking, and IaC.

When I'm not at work, you might find me riding my bicycle or playing the ukulele (not simultaneously).

My personal page

「フィンガープリント」の話をしましょう | Source: Everett Collection/Shutterstock

AWS WAFのログを分析していて、ja3fingerprintや(最近では)ja4fingerprintというログフィールドに気づいたことはありませんか?「これは何だろう?」と思った方、ようこそ。見たことがなかったけれど興味が湧いてきた方も、ようこそ。

本記事では、これらのフィンガープリントとは何か、利用するクラウドサービスを問わずどう役立つのか、そしてAWS、Google Cloud、Azureでどう検出・分析・活用できるのかを見ていきます。AWS WAFログで使えるクエリの例もあわせて紹介します。

PerfectScale™ for Kubernetes

Ready to optimize?

Get your free Kubernetes savings analysis

JA3/JA4フィンガープリントとは?

JA3とJA4(発音は「ジャー・スリー」「ジャー・フォー」)フィンガープリントは、AWS WAFなどのサービスが算出するクライアント識別子です。トラフィックの種類を見極めたり、潜在的・進行中の攻撃を緩和したりする際に大いに役立ちます。

簡単な歴史

意外かもしれませんが、JA3とJA4の前にJA1やJA2があったわけではありません。「JA3」という名前は、このツールを開発した3人の「J.A.」開発者の頭文字に由来します。

  • John Althouse
  • Josh Atkins
  • Jeff Atkinson

(出典:John AlthouseとJeff Atkinson本人による優れたプレゼンテーション Profiling And Detecting All Things SSL With JA3)

彼らの取り組みは、Ivan Ristić氏やLee Brotherston氏によるTLS暗号スイート分析の研究を土台にしています。

JA3はSalesforceで考案され、その直接の後継であるJA4はFoxIO(John Althouseと、4人目(!)のJ.A.であるJosh Alexanderが共同創業した会社)によって生み出されました。

どちらのフィンガープリントもオープンソースですが、FoxIOはJA4+と呼ばれるより大規模なフィンガープリント群もライセンス提供しており、こちらは別のライセンス条項が適用されます。AWSは現時点でJA4+の機能をサポートしていませんが、他の多くのネットワーク・セキュリティツールはサポートしています。

簡単な(かなり簡略化した)解説

一文でまとめると、JA3とJA4のフィンガープリントは、サービスに送られるTLSハンドシェイク冒頭のClient Helloパケットに含まれる情報をもとに、IPアドレスやポート、地理的位置などの一般的な変数に依存せずクライアント(サービスにアクセスするあらゆるもの)を識別する仕組みです。

TLS 1.2ハンドシェイクの簡略化フロー | Source: Wikimedia Commons

JA3/JA4フィンガープリントの算出方法

JA3フィンガープリントは(公式オープンソースリポジトリに説明されているとおり)、Client Helloパケット内の以下のフィールドから算出されます。

これらのフィールドを列挙して1つの文字列に並べ、その文字列をMD5でハッシュ化することで、より短い文字列を得ます。

WiresharkのパケットキャプチャによるClient Helloパケットの詳細テキスト

こちらは私のマシンで取得したTLS 1.3ハンドシェイクのWiresharkキャプチャです。JA3フィンガープリントもしっかり表示されていますね。

JA4クライアントフィンガープリントは、JA4リポジトリに詳しく記載されているとおり、Client Helloの以下の情報を使用します。

  • プロトコル(TCPまたはQUIC)
  • TLSバージョン
  • SNIを使用しているか(使用=ドメインの「d」、未使用=IPの「i」)
  • 暗号スイート(数と内容)
  • 拡張(数と内容)
  • ALPN拡張の値(Application-Layer Protocol Negotiation。HTTP/2、HTTP/3、POP3、DNS-over-TLS、SPDY/3、その他多数の短縮コードが該当)

JA4クライアントフィンガープリントの各部分の算出方法を示した図のスライド

JA4フィンガープリントの各部分の算出方法をわかりやすく示した図 | Source: FoxIOのJA4リポジトリ(BSD-3-Clauseライセンス)

これらの情報はMD5ハッシュ化されません。シグネチャの一部は既にハッシュ化・切り詰めされており、シグネチャ全体はわずか36文字です。

ちょっとしたデモ

https://ja4db.comにアクセスすると、現在のJA4フィンガープリントを確認できます。ぜひ試してみてください。

なぜJA3/JA4フィンガープリントを使うのか?

ユースケース1:レート制限

従来、WAFやその他の保護レイヤーにおけるレート制限ルールは、IPアドレスやURIパス、その他クライアントリクエストの一部要素をもとに設定されてきました。

クライアント固有のフィンガープリントに基づいてリクエストレートを制限することには、次のメリットがあります。

  • IPベースの制限などで生じがちな誤検知を回避できる
  • IPアドレスを変えても、同じフィンガープリント/ツールを使う攻撃者を抑え込める

Google Cloud ArmorAWS WAFはいずれもこの機能をサポートしています。

AWS WAFのルール設定画面の一部スクリーンショット。集約キーのドロップダウンに「JA4 fingerprint」が表示されている

AWSではJA3またはJA4フィンガープリントをレート制限ルールの集約キーとして利用できます

ユースケース2:ブロックリスト

悪意のあるフィンガープリントが既にわかっているなら、ブロックリストに加えるだけで済みます。Google Cloud ArmorAWS WAFのいずれもこの機能をサポートしています。

ユースケース3:脅威ハンティング

脅威ハンティングとは、自社環境内の脅威を能動的に検出する防御活動です。たとえば、新たに発見されたC2サーバーのIPアドレス情報を入手したら、それらのIPとの通信がないかネットワークログを確認するでしょう。

同じように、ネットワーク環境でJA3/4フィンガープリントを検出できれば、新たに見つかった悪意のあるクライアントのフィンガープリントをネットワークログ上で照合できます。これらのフィンガープリントは、ツールキットに加わるもう一つの武器なのです。

フィンガープリント vs IPアドレス

JA3とJA4のフィンガープリントはクライアントそのものの特徴を捉えるため、IPアドレスを追跡したりブロックしたりするより防御に有効なケースがあります。

  • 独自の攻撃スクリプトを使う攻撃者は、利用しているライブラリやOSなどによって固有のフィンガープリントを持つ可能性が高い
  • 侵害された複数の業務PC上のマルウェアからのトラフィックは、同一、もしくはごく少数のフィンガープリントに収束しやすい
  • 既知の悪意あるツールのフィンガープリントを共有しておけば、ネットワーク上で実際に検出される前に自動的にブロックできる

JA3 vs JA4

基本的にはJA4フィンガープリントの利用が推奨されますが、目的が明確であればJA3も依然として有用です。主な違いは以下のとおりです。

  • JA4フィンガープリントはJA3よりも多くの情報に基づいている
  • JA3はSalesforce発のプロジェクトだが、現在は積極的に保守されていない
  • サイバーセキュリティの常として、検出回避の研究や手法は進化し続けている。JA3は登場から時間が経ち、検出を回避する方法もより多く知られている
  • ChromeFirefoxなど一部のクライアントは、Client Helloパケットの一部をシャッフルするオプションをサポートし始めた。これによりJA3フィンガープリントは変動するが、JA4はソートを用いて一貫性を保つ
  • どちらのフィンガープリントもコミュニティ管理のデータベースが存在する。私が確認した範囲で最大規模の公開JA3データベースは12万8,000件強のエントリがあった。本稿執筆時点では、JA4+データベースにはおよそ10万5,000件のエントリがあった
  • JA3には長い実績があるが、JA4のサポートは活発に広がりつつある。実際、本稿の執筆中にもAWSがNetwork FirewallサービスでのJA4フィルタリング対応を発表した

そのほかの考慮事項

誤検知 フィンガープリント値をキーにした強めのレート制限ルールを適用すると、特に類似するクライアントが多い場合に誤検知が大量発生する可能性があります。AWSのこちらのブログ記事で紹介されているヘッダー順序など、追加のクライアント情報を組み合わせることで、正規ユーザーへの不要なブロックを最小限に抑えられます。

データベースは成長途上 公開されているJA3・JA4データベースはコミュニティ運営のため、最先端の脅威検出を求めるなら、これだけに頼るのは心もとないかもしれません。クラウドプロバイダーやマネージドセキュリティサービスは独自に悪意あるフィンガープリントの非公開データベースを保有している可能性が高いので、AWSのBot Controlルールグループのようなマネージドルールの併用も検討する価値があります。

攻撃者の巧妙さはさまざま DoiTではこれまで多くのお客様の攻撃分析を支援してきました。複数のIPにまたがって単一のフィンガープリントが見られ、基本的なDoSツールが使われていると示唆されたシンプルなケースもあれば、JA3/4フィンガープリントが一貫せず特定が難しいケースもありました。攻撃者の能力やリソース、忍耐力は実にさまざまです。

ところでAzureはどうなのか? Azureも忘れてはいけません。AzureのツールはAWSやGoogle Cloudのように独自のJA3/JA4関連機能を直接サポートしているわけではありません(今のところは)が、いくつかのセキュリティツールにはフィンガープリント機能が組み込まれています。

Your cloud bill shouldn't be a mystery

Optimization, automation, expertise. In one platform.

AWSではどう活用できる?

AWSではJA3/JA4フィンガープリントに基づくロギングやルールが手厚くサポートされており、以下ではAWSの機能を中心に解説します。

リクエストのロギング

最初のステップは、JA3/JA4フィンガープリントをログに残せるようにすることです。次のAWSリソースは、ログ内でJA3/JA4フィンガープリントのフィールドをサポートしています。

私のJA3/JA4フィンガープリント値が表示されているAWS WAFログの例。ブロックしないでくださいね!

フィンガープリント値に基づくブロックとレート制限

本機能は前述のセクションでも触れましたが、参考ドキュメントを以下にまとめておきます。

ログの分析

以下は、私が過去にWAFトラフィックのJA3/JA4フィンガープリントを調査する際に使ったCloudWatch Logs Insightsのクエリ例です。

JA3フィンガープリントの上位件数

fields ja3Fingerprint
| stats count(*) as requestCount by ja3Fingerprint
| sort requestCount desc

Logs Insightsのスクリーンショット。クエリと、ログ内に出現するフィンガープリントとその出現回数の一覧が表示されている

1,097件——これは多すぎでしょうか?

JA4フィンガープリントの上位件数(URLパスとUser Agent別)

parse @message /\{\"name\":\"[Uu]ser\-[Aa]gent\",\"value\"\:\"(?<useragent>[^"\}]*)/
| stats count(*) as requestCount by ja4Fingerprint, httpRequest.uri, useragent
| sort requestCount desc

Logs Insightsのスクリーンショット。クエリと、ログ内のフィンガープリントの出現回数、User Agentやパス情報の一覧が表示されている

情報を増やすほど、状況がぐっと見えやすくなります。

レートベースルールでブロックされたリクエストのフィンガープリント

このクエリはあらゆるレートベースルールを対象とします。IPベースのレート制限ルールを既に運用していて、共通するフィンガープリントがないかを確認したい場合に便利です。

fields @timestamp, httpRequest.clientIp as ClientIP, terminatingRuleId as rule, httpRequest.country as Country, ja4Fingerprint
| filter action = "BLOCK"
| filter terminatingRuleType = "RATE_BASED"
| stats count(*) as count by ja4Fingerprint, ClientIP, rule, Country | sort by count desc

Logs Insightsのスクリーンショット。レートベースルールでブロックされたトラフィックのクエリと、件数順に並んだフィンガープリント、伏せたIPアドレスの一覧が表示されている

同じIPでも異なるフィンガープリントを持つクライアントが存在することがあります

AWSはこちらのブログ記事こちらのre:Post記事でも追加の例を紹介しています。JA3/4フィンガープリントを含めるためのカスタマイズは必要ですが、自分の状況に合った活用法を探る出発点として最適です。

さらに詳しく

JA3/JA4フィンガープリンティングについて、私が見つけた中でも特に有用な情報源とツールを以下にまとめます。

公式ソース

ツール

ブログ記事

プレゼンテーション

JA3/JA4フィンガープリントは、すでに手元にある検出・分析手段に加えるべき非常に価値のある選択肢です。セキュリティアナリストでも、クラウドエンジニアでも、小規模チームでDDoS攻撃に立ち向かう「なんでも屋」でも、実環境でこれらに出くわしたときに必ず役に立つはずです。

クラウド環境のセキュリティについて、ご質問はありませんか?

クラウド環境の効率、コスト効果、セキュリティを最大化する方法について、ぜひDoiTにお問い合わせください。DoiTなら、コンサルティングやスキル向上支援、サポートのためにシニアレベルのクラウド専門家に独占的にアクセスできます。専門家の助言、第三者の視点、新技術導入の支援、本番環境のトラブル対応など、必要なときにいつでも頼っていただけます。

クラウドセキュリティやアーキテクチャの他のトピックも深掘りしたい方は、クラウドエンジニアリングのブログ記事もぜひご覧ください。