トップ > テクノロジー > 利用終了したドメイン名の終活に向けて 〜観測環境を作った話〜

利用終了したドメイン名の終活に向けて 〜観測環境を作った話〜

テクノロジー セキュリティ アーキテクチャ アドベントカレンダー

この記事は、 NTT Communications Advent Calendar 2024 17日目の記事です。

みなさんこんにちは、イノベーションセンターの平木です。 Network Analytics for Security1 (以下、NA4Sec)プロジェクトのメンバーとして活動しています。 この記事では、利用終了ドメイン名観測の環境構築の知見を共有していきます。 明日の記事では観測されたログの分析結果を紹介したいと思います。

利用終了ドメイン名観測分析施策の背景と目的

昨今、廃止したドメイン名がドロップキャッチ2され被害にあうケースが多発しています。 NTTドコモグループでも、過去にドコモ口座で使用していたドメイン名が廃止後にオークションにかけられた事案がありました3。 ドロップキャッチされることで、フィッシングサイトなどで悪用されるリスクがあります。そこで、これらドロップキャッチの被害を最小限に抑えるために、NTTコミュニケーションズでは利用終了したドメイン名を永年保有する方針で運用を開始しました。

ただ一方で、組織が使用していないドメイン名を保有し続けることはインターネットの健全性に悪影響を及ぼす可能性があります。

そこで、利用終了ドメイン名の観測を通し、実際にどのような通信を受けているのか、そしていつ手放すことができるのか、また手放すために通信を減らすことはできないかなどを検討すべく、2024年に利用終了ドメイン名の観測分析の施策を立ち上げる運びとなりました。

工夫した点

DNSクエリのみならずWebアクセスログも取得する

ドメイン名の観測のため、当然DNSクエリログを収集しますが、同時にWebアクセスログも収集することにしました。

Webアクセスログも収集するようにした理由は、アクセス元やアクセス用途を特定し、より効果的な対策につなげるためです。 DNSクエリログは情報量が少なく、それ単体では誰がどこから何の用途でアクセスしてきたかを推し量ることは困難です。 そこでDNSクエリ結果の主たる用途の1つとして考えられるWebアクセスに着目し、WebサーバへのHTTP/HTTPSアクセスも収集できる形を要件としました。

さらに、より幅広くWebアクセスログを収集するため、サブドメイン名も対象としました。 サブドメイン名は、Passive DNS4から取得したサブドメイン名を登録することにしました。

パブリッククラウドとマネージドサービスを利用する

今回AWSを使いやすい状況が整っていたこと、またコストを抑えすぐに利用できる点も勘案し、AWSで観測環境を構築することにしました。 一方、分析・ログ保管については、社内リソース有効活用の観点で全社データ基盤を採用しています。

また、運用の手間を減らしつつもセキュリティを担保できるよう、マネージドサービスを使うことにしました。 Amazon EC2などでサーバを立てて構築した場合に比べ、マネージドサービスの方がAWS側のセキュリティ対応範囲が広くなるため、運用の手間が減るというメリットがあります。

構成

構成の全体像は下記の通りです。

送信元として、サービスが終了したが消し忘れられたリンク（残存するリンク）や、消し忘れの監視通信（残存監視通信）、 そしてインターネット全体で定常的に発生している探索通信などを想定しています。

それら通信をAWSのAmazon Route53、Amazon CloudFrontで受け、ログをJSON化しています。

JSON化されたログは、全社データ基盤に保存され、全社データ基盤のJupyter Notebookを使って分析できるようになります。

なお、送信元に対しては「何もページを返さない」（Access Denied）形を取ることで、 Amazon CloudFrontの利用料金を月数十円以下と低く抑えて運用しています。

DNSクエリログ、Webアクセスログ処理の詳細な流れは以下の通りです。

  1. Amazon Route 53がDNSクエリを受ける
  2. DNSクエリログがAmazon CloudWatch Logsに蓄積される（4.の処理の負荷分散のため、分散して蓄積）
  3. ログは1日1回、Amazon EventBridgeのCreateExportAPIにより、Amazon S3バケットにExportされる
  4. Exportされたタイミングで、AWS Lambda関数が立ち上げられ、JSON化される（AWS Lambdaの設定により、Amazon S3のファイル生成をトリガーに、AWS Lambdaを立ち上げている）
  5. 全社データ基盤がJSON化されたファイルを1日1回取得する

  1. Amazon CloudFrontがWebアクセスを受ける
  2. WebアクセスログがAmazon S3へ出力される（Amazon CloudFrontの設定により、ログをAmazon S3へ出力している）
  3. Amazon S3にログが生成されると、AWS Lambda関数が立ち上げられJSON化される（AWS Lambdaの設定により、Amazon S3のファイル生成をトリガーに、AWS Lambdaを立ち上げている）
  4. 全社データ基盤がJSON化されたファイルを1日1回取得する

大量アクセスを捌くコツ

今回の構成では、AWS Lambda関数の作りが最もキーになったと感じています。

当初は入力としてAWS Lambda関数1処理当たり数行〜数百行程度のデータを想定していましたが、観測するドメイン数が増えると、数万行のデータも現れ、タイムアウトやエラーが増えていきました。 これらタイムアウトやエラーに対応すべく試行錯誤を重ね、いくつかのAWSサービスを試したものの、最終的にはAWS Lambda関数（Pythonプログラム）の改良が、高速性やエラーの低減に最も効いたと感じています。

特にAWS Lambda関数を作るに当たっては「無駄な処理をなくすこと」が一番のポイントだったと考えています。

  • メモリに読み込むファイルは最小限にする（例えば全行は読み込まず、必要な数行のみ読み込む）
  • ファイルをフィルタするにあたって、テキストのままフィルタする（JSON化後にvalueでフィルタしてしまうと、入力データが増えるにつれ重くなるため）

コスト

全体のコストのうち、AWSの運用にかかるコストを紹介します。 2024年5月〜10月までのAWS利用料金を可視化したのが下図（左）、アクセス数を可視化したのが下図（右）となります。

下図（左）について、横軸が月、縦軸が月当たりのAWS利用料金となっていて、システムが安定しドメイン名が一定数（24）で推移した7〜10月の料金が安定していることが分かります。この時期の料金は概ね15000円前後となっています。

下図（右）について、横軸が月、縦軸がアクセス数となっていて、ドメイン名を増やしたタイミング（丸をつけた箇所）で、アクセス数が増えたことが分かります。

また、より詳細なコスト分析が以下の図です。

コストの主因はAWS Lambda、Amazon Route 53、Amazon S3であることが分かります。

AWS Lambdaについては、アルゴリズムが最適化されておらず金額が高くなっていました。 そこで、11月末にアルゴリズムを改善したところ、大幅な高速化に成功しています。 そのため、11月以降のAWS Lambdaによる支出は、大幅に低減される見込みです。

Amazon Route 53については、DNSレコード維持費が75%を占めています。 コストの内訳は、DNSZone75%、DNSQuery25%でした。 つまり、75%がDNSレコードの維持費用ということが分かります。

Amazon S3については、全社データ基盤の連携コストがほとんどを占めていると考えています。 コストの内訳は、API Request99.3%、Storage0.7%でした。 API Requestの中身は分かりませんが、全社データ基盤からのJSONファイルの取得によるものと考えています。

まとめ

利用終了ドメイン名の観測分析施策の、観測環境について振り返りました。 明日の記事では、この環境で収集したログの分析結果について紹介する予定です。お楽しみに。

  1. NA4Secプロジェクトについては、このブログの記事 サイバー脅威インテリジェンス（CTI）配信はじめました をご覧ください。↩
  2. ドロップキャッチについては、JPNICの ドロップキャッチとは にて分かりやすく説明されています。↩
  3. ドコモ口座の件については、ITmedia NEWSの 「ドコモ口座」のドメイン、ドコモが取り戻す　出品の経緯をGMO含め聞いた をご覧ください。↩
  4. Passive DNSについては、エヌ・エフ・ラボラトリーズ株式会社のエンジニアブログ サブドメイン名列挙の方法についてまとめてみた にて分かりやすく説明されています。↩
© NTT Communications Corporation 2014