「フィンガープリント」の話をしましょう | Source: Everett Collection/Shutterstock
AWS WAFのログを分析していて、ja3fingerprintや(最近では)ja4fingerprintというログフィールドに気づいたことはありませんか?「これは何だろう?」と思った方、ようこそ。見たことがなかったけれど興味が湧いてきた方も、ようこそ。
本記事では、これらのフィンガープリントとは何か、利用するクラウドサービスを問わずどう役立つのか、そしてAWS、Google Cloud、Azureでどう検出・分析・活用できるのかを見ていきます。AWS WAFログで使えるクエリの例もあわせて紹介します。
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パケット内の以下のフィールドから算出されます。
- TLSバージョン
- 受け入れる暗号スイート
- 拡張のリスト
- 楕円曲線
- 楕円曲線のポイントフォーマット
これらのフィールドを列挙して1つの文字列に並べ、その文字列をMD5でハッシュ化することで、より短い文字列を得ます。

こちらは私のマシンで取得した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フィンガープリントの各部分の算出方法をわかりやすく示した図 | Source: FoxIOのJA4リポジトリ(BSD-3-Clauseライセンス)
これらの情報はMD5ハッシュ化されません。シグネチャの一部は既にハッシュ化・切り詰めされており、シグネチャ全体はわずか36文字です。
ちょっとしたデモ
https://ja4db.comにアクセスすると、現在のJA4フィンガープリントを確認できます。ぜひ試してみてください。
なぜJA3/JA4フィンガープリントを使うのか?
ユースケース1:レート制限
従来、WAFやその他の保護レイヤーにおけるレート制限ルールは、IPアドレスやURIパス、その他クライアントリクエストの一部要素をもとに設定されてきました。
クライアント固有のフィンガープリントに基づいてリクエストレートを制限することには、次のメリットがあります。
- IPベースの制限などで生じがちな誤検知を回避できる
- IPアドレスを変えても、同じフィンガープリント/ツールを使う攻撃者を抑え込める
Google Cloud ArmorとAWS WAFはいずれもこの機能をサポートしています。

AWSではJA3またはJA4フィンガープリントをレート制限ルールの集約キーとして利用できます
ユースケース2:ブロックリスト
悪意のあるフィンガープリントが既にわかっているなら、ブロックリストに加えるだけで済みます。Google Cloud ArmorとAWS WAFのいずれもこの機能をサポートしています。
ユースケース3:脅威ハンティング
脅威ハンティングとは、自社環境内の脅威を能動的に検出する防御活動です。たとえば、新たに発見されたC2サーバーのIPアドレス情報を入手したら、それらのIPとの通信がないかネットワークログを確認するでしょう。
同じように、ネットワーク環境でJA3/4フィンガープリントを検出できれば、新たに見つかった悪意のあるクライアントのフィンガープリントをネットワークログ上で照合できます。これらのフィンガープリントは、ツールキットに加わるもう一つの武器なのです。
フィンガープリント vs IPアドレス
JA3とJA4のフィンガープリントはクライアントそのものの特徴を捉えるため、IPアドレスを追跡したりブロックしたりするより防御に有効なケースがあります。
- 独自の攻撃スクリプトを使う攻撃者は、利用しているライブラリやOSなどによって固有のフィンガープリントを持つ可能性が高い
- 侵害された複数の業務PC上のマルウェアからのトラフィックは、同一、もしくはごく少数のフィンガープリントに収束しやすい
- 既知の悪意あるツールのフィンガープリントを共有しておけば、ネットワーク上で実際に検出される前に自動的にブロックできる
JA3 vs JA4
基本的にはJA4フィンガープリントの利用が推奨されますが、目的が明確であればJA3も依然として有用です。主な違いは以下のとおりです。
- JA4フィンガープリントはJA3よりも多くの情報に基づいている
- JA3はSalesforce発のプロジェクトだが、現在は積極的に保守されていない
- サイバーセキュリティの常として、検出回避の研究や手法は進化し続けている。JA3は登場から時間が経ち、検出を回避する方法もより多く知られている
- ChromeやFirefoxなど一部のクライアントは、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関連機能を直接サポートしているわけではありません(今のところは)が、いくつかのセキュリティツールにはフィンガープリント機能が組み込まれています。
- Azure Firewall Intrusion Detection & Prevention System(IDPS)は、シグネチャルールでJA3フィンガープリンティングを利用していると明記しています。Azureにはこちらのブログ記事もあります。
- AzureのSIEMツールSentinelは、脅威オブジェクトデータ(STIX形式)にJA3とJA3S(サーバー側フィンガープリント)の情報を含めています。詳しくはこちらのドキュメントを参照してください。
AWSではどう活用できる?
AWSではJA3/JA4フィンガープリントに基づくロギングやルールが手厚くサポートされており、以下ではAWSの機能を中心に解説します。
リクエストのロギング
最初のステップは、JA3/JA4フィンガープリントをログに残せるようにすることです。次のAWSリソースは、ログ内でJA3/JA4フィンガープリントのフィールドをサポートしています。
- WAFログ(CloudFrontおよびApplication Load Balancerリソースに関連するログのみ)
- Network Firewallログ(一部のケースのみ。AWSがこちらにサンプルを公開しています)

私のJA3/JA4フィンガープリント値が表示されているAWS WAFログの例。ブロックしないでくださいね!
フィンガープリント値に基づくブロックとレート制限
本機能は前述のセクションでも触れましたが、参考ドキュメントを以下にまとめておきます。
ログの分析
以下は、私が過去にWAFトラフィックのJA3/JA4フィンガープリントを調査する際に使ったCloudWatch Logs Insightsのクエリ例です。
JA3フィンガープリントの上位件数
fields ja3Fingerprint
| stats count(*) as requestCount by ja3Fingerprint
| sort requestCount desc

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

情報を増やすほど、状況がぐっと見えやすくなります。
レートベースルールでブロックされたリクエストのフィンガープリント
このクエリはあらゆるレートベースルールを対象とします。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

同じIPでも異なるフィンガープリントを持つクライアントが存在することがあります
AWSはこちらのブログ記事とこちらのre:Post記事でも追加の例を紹介しています。JA3/4フィンガープリントを含めるためのカスタマイズは必要ですが、自分の状況に合った活用法を探る出発点として最適です。
さらに詳しく
JA3/JA4フィンガープリンティングについて、私が見つけた中でも特に有用な情報源とツールを以下にまとめます。
公式ソース
- JA3のGitHubリポジトリ
- JA4+のGitHubリポジトリ
- TLS Fingerprinting with JA3 and JA3S(Salesforceブログ)
- JA4+ Network Fingerprinting(FoxIOブログ)
ツール
- ja3.me — 私が見つけた中で最大規模の公開JA3フィンガープリントデータベース
- JA3.ZONE — オープンソースではない別のデータベース
- JA4+フィンガープリントDB
ブログ記事
- TLSフィンガープリンティングに関するIvan Ristić氏の最初のブログ記事
- TLSフィンガープリンティングに関するLee Brotherston氏の初期の研究(カンファレンスのプレゼンテーションへのリンクを含む)
- JA3・JA4フィンガープリントに関するCloudflareの解説(解析方法の詳細あり)
- Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal
プレゼンテーション
- Profiling And Detecting All Things SSL With JA3(YouTube/John Althouse・Jeff Atkinson)
- JA4+ Intro(YouTube/John Althouse)
- BSides DC 2019 — Using JA3. Asking for a friend?(YouTube/Justin Warner・Ed Miles)
JA3/JA4フィンガープリントは、すでに手元にある検出・分析手段に加えるべき非常に価値のある選択肢です。セキュリティアナリストでも、クラウドエンジニアでも、小規模チームでDDoS攻撃に立ち向かう「なんでも屋」でも、実環境でこれらに出くわしたときに必ず役に立つはずです。
クラウド環境のセキュリティについて、ご質問はありませんか?
クラウド環境の効率、コスト効果、セキュリティを最大化する方法について、ぜひDoiTにお問い合わせください。DoiTなら、コンサルティングやスキル向上支援、サポートのためにシニアレベルのクラウド専門家に独占的にアクセスできます。専門家の助言、第三者の視点、新技術導入の支援、本番環境のトラブル対応など、必要なときにいつでも頼っていただけます。
クラウドセキュリティやアーキテクチャの他のトピックも深掘りしたい方は、クラウドエンジニアリングのブログ記事もぜひご覧ください。