はじめに こんにちは、イノベーションセンターの藤田、鈴ヶ嶺です。NTTコミュニケーションズ株式会社 (以下、NTT Com) は、世界最大級のネットワーク展示会である 「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」 におけるShowNetに対し、コントリビューターとしてローカル5G（以下、L5G）システムに携わりました。その取り組みに付随して、ShowNetと連携しAWS Outposts サーバーを用いたメトリクス監視基盤を構築しました。本記事ではその構成について解説します。 AWS Outpostsは、AWSのハイブリッドクラウド製品です。オンプレミス上に製品を設置してPublic AWSと同じような操作性でインフラストラクチャとサービスを作成できます。詳細については以下のリンクをご参照ください。 https://engineers.ntt.com/entry/2023/03/24/095642 メトリクス監視のアーキテクチャ 5G ネットワークでは通信品質の向上や保守運用のため、各セグメントごとに取得される大量のメトリクスデータを監視・可視化・分析する必要があります。 本アーキテクチャではエッジでのリアルタイム監視に加え、クラウドで大容量のデータを可視化・分析する基盤を構築しました。 エッジではAWS Outposts サーバー上にEC2インスタンスを構築し、EC2にて動作するPrometheusからLNI経由でオンプレミスのメトリクスデータを取得しています 1 。 これによりリアルタイムでパケットのドロップ率やセグメントごとのパケット流量なども可視化できるため、トラブルの早期発見やボトルネックの特定も期待されます。 EC2上のPrometheusで取得したデータはVPC経由でPublic AWS上のAmazon Managed Service for Prometheusに送信され、データを統合して蓄積しています。 エッジで一時的に蓄積することにより、通信量の削減や省電力化が見込まれます。 例えばリアルタイムなアラート処理はエッジ側で実施、モニタリングは全データを送るのではなくn秒間の統計値(平均、中央値)などをクラウドに送信することでデータ量を約1/nに削減できます。 クラウド上での可視化・分析についてはPublic AWSにてAmazon Managed Service for Prometheus、Amazon Managed Grafanaを利用し、スケーラビリティを担保しつつ運用コストを抑える構成にしました。 AWS Outposts サーバーを用いることのメリット AWS Outposts サーバーを用いて監視基盤を構築することは、1から基盤を構築することと比べて、以下のような点でメリットがあります。 Public Cloudサービスとの親和性 統一されたセキュリティの担保 Public Cloudサービスとの親和性 データの転送や集約するためのネットワーク設計や集約基盤との統合を1から作ろうとすると膨大なコストが必要となります。 AWS Outposts サーバー上に構築したEC2インスタンスはPublic AWSのVPCとシームレスに接続可能です。 また、VPCエンドポイントを利用することでインターネットに出ることなくPublic AWSのさまざまなサービスとの統合が簡易に可能となっています。 これらによりオンプレミスにありながらPublic Cloudのサービスとの親和性があることで、自動化やマネージドサービスの恩恵であるオペレーションコストの削減が見込まれます。 統一されたセキュリティの担保 オンプレミスにて監視基盤を構築する場合、多くの設定項目やセキュリティポリシーの統一化や統合は困難です。 AWS Outposts サーバーは、EC2インスタンスへのIAMロール設定やセキュリティグループの設定により、統一されたセキュリティポリシー設計ができます。 加えて、AWS Outposts サーバーはハードウェアまで含めてマネージドなサービスであるため、セキュリティアップデートなどもAWS Outposts サーバーのユーザー側で実施する必要はありません。 またこれらの設定はAWSコンソールやawsコマンド経由で統合的に管理が可能であるため、拠点が多くなった場合も自動化が可能となり、ヒューマンエラーの低減にも繋がります。 まとめ 本記事ではInterop Tokyo 2024のShowNetと連携したAWS Outposts サーバーを用いた5Gメトリクス監視の構成について紹介しました。 今後は更なる自動化を目指すと共にリアルタイム分析のフィードバックやエッジにAIの処理を組み込む検討をしつつ、サービスへの応用について検討していきます。 https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html ↩

何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした 組織が記憶喪失になる ことにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 ( @ryuzee ) さんにふらっと相談してみたら一瞬で突破口が見つかった＆話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念：ADR ADRの実践：その1 何を書くか ADRの実践：その2 どこに書くか ADRの実践：その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 ( @ppyv ) です。 開発・検証用PCの開発 に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよく働ける環境を提供するための仕事をしています。 事の発端 最近、同じチームで働いているmahitoからこんな質問がありました。 なんでこのアプリケーションは社内プラットフォームとしてモバイル対応していないんだっけ？ 他の組織から、してないならしてない理由があるんですよねって言われたので その理由はSlackの過去ログを遡って確認できたものの、こうした ちょっとした経緯を調べること に対して30分以上にわたる議論が巻き起こってしまいました。 正直言ってもったいない時間ですし、調べがつくうちはまだいいものの どこを調べたらいいか分からない とか、そもそも 間違った経緯が「発見」される 恐れもあります。 ではどうやってその経緯を記録しておくのがいいのか、との積年の疑問がここで再度噴出したため、ryuzeeさんに相談しに行くことにしました。 ryuzeeさんの油セール NTT Comの技術顧問でありアジャイルコーチでもあるryuzeeさんは、毎週火曜日をNTT Com向けの支援日として空けてくださっています。 特に社員からのアポイントメントがなければ、「油セール」と称してNTT ComのオンラインコミュニケーションツールであるNeWorkにおいでくださいます。 実際に聞いてみた その機会を使ってさっそく質問してみることにしました。 新たなる概念：ADR 小林）……とこういうエピソードがあって、自分は「組織が記憶喪失になる」と呼んでいるんですが、ほかではどうなんでしょうかね。 ryuzee) それはめっちゃあるあるですね。どこ行っても悩んでいると思います。 ただこの問題に対しては、ソフトウェア開発で使われている ADR: Architectural Decision Records っていう手法が役に立つと思います。 ジャブを打ったらいきなりストレート＝新しいキーワードが飛んできました。 ここでADRについて、GitHubのorganization "ADR" がメンテナンスしているサイト adr.github.io から語釈を引きます。 An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”). （拙訳）アーキテクチャ上の決定 (AD) とは、アーキテクチャ的に重要な機能要件または非機能要件に対処する、合理的なソフトウェア設計上の選択のことです。 アーキテクチャ的に重要な要件 (ASR) とは、ソフトウェアシステムのアーキテクチャと質に大きな影響を与える要件のことです。 アーキテクチャ決定記録 (ADR) は、単一のADとその理論的根拠を記録するためのものです。プロジェクトで作成・維持されるADRの集合は、意思決定のログを構成します。 これらはすべてアーキテクチャナレッジマネジメント (AKM) に含まれる話題ですが、ADRはany decision recordすなわちあらゆる決定の記録として、設計やそのほかの決定にも応用できます。 平たく言ってしまえば、 アーキテクチャ上重要な決定そのもの と、 どういう理由があってその決定をしたのかをまとめた記録 が ADR ということになります。 悩みに対するずばりの回答が10秒で返ってきて面食らいました。 ADRの実践：その1 何を書くか そしてADRの簡単な説明を受けて、思い出したのがこの話でした。 小林）これってコードコメントとかコミットログにはWhyを書けっていうのと同じですか？ ryuzee) あーまさにそうです。HOWはコード見れば分かるので、なんでそれを書いたの？というのを残しておく必要がありますね。 ソフトウェアエンジニアの方は、コードコメントの書き方について指導を受けたことはありませんか？ やってしまいがちなコードコメントとして 何が起きているかを書く というのがありますが、何が起きるかはコードを読めば理解できるので、一般にはコメントとして適当でないとされます。 代わりに、 なぜそのコードにしたのか であるとか、一見して意味・目的がわかりにくいロジックを解説するコメントを書くべきと言われます。 それとこの話は似た構造をしています。 ADRの実践：その2 どこに書くか 次に、ADRを書くにしてもどこに書いておくべきかの話になりました。 ryuzee) ソフトウェア開発に関係していれば、GitHubでいうところのpull request (PR) にWhyを書くのは合理的です。 あとはWebサービス系の会社が規程とかの管理をGitHubで行っている例がありますが、親和性が高いやり方だと思います。 その変更をするに至った背景、なぜ必要と思った、などなど書くべきとされることは会社によってさまざま考えられますが、そういったことをPRに書いておく。 そしてADRのテンプレートを作ってしまえばある程度定型にできるので、ADRテンプレートを満たしていないPRは突っ返すといった対応も容易です。 小林）確かにバージョン管理システムを使えば、変化したところを起点にどのコミットで編集されたかは即座に分かりますね。 ではソフトウェアや、プレーンテキストでなんとかできるものに関連しない分野だとどうしましょう？ ryuzee) 身も蓋もないですが、やっぱりどこかにまとめて書き残しておくしかないです。 ADRを書く先としては、簡単に書けることと簡単に検索できること、この2点を満たすことがとても重要です。 これらのいずれかが欠けるとうまく行きません。 書いてなければ探せないですし、探せなければ書いていないのと同じなので、結果として問題を蒸し返したり、過去の経験をリスペクトしない決定をしてしまったりする。 適切なところはプロジェクトによってさまざまだと思いますので、まずチームでやり方を合意してやってみるのがいいと思います。 アンチパターンとして、例えばこれをWordファイルでやってしまうと書き始めるまでのハードルが高いですし、書いたファイルが散逸しやすい問題があります。 そういった点は注意した方がいいですね。 それからADRが書きつけてあるファイルの保存先が複数箇所になると、これもうまくいきません。結局検索性がないのと同じになってしまいます。 2カ所以上を探すのは大変です。 その点やはりPRは合理的だと思います。自動的に一カ所に固まりますから。 記憶喪失にもバージョン管理システムの力を借りるのがいいのではないかと思います。 Slackの「地層」を探しに行って考古学者になったり、あっちもこっちもと掘り返したりしていると骨が折れます。 「ここを見ればわかる」状態にしておくのが大事だと感じました。 ADRの実践：その3 どう書くか ではどうやってADRを書き始めるか、その点も尋ねてみました。 小林）ではどうやってADRを書き始めたらいいでしょうか。 ryuzee) 例えば今日のこの相談をADRに起こすことを考えるとしましょう。 それなら、「なぜこの話をここに持ち込もうとしたか」をアウトプットするのが重要になります。 小林）確かに今日ここまで会話した内容はすべてHowの話で、Whyの話ではないですね。 なぜと言われると、「なんとなくryuzeeさんならなんか知ってそうだったから」となってしまいますが（笑 ryuzee) よく「Issueから始めろ、Howから始めるな」といいます。 実はHowに詳しい人っていっぱいいるんですよ。だけど、その人が直面しているIssueに詳しい人って、そんなにたくさんはいません。 なんならその人が一番詳しいかもしれない。 なんらかまず書いてみるのをおすすめします。 試してみて振り返って、それでいける or いけないを見るのは王道パターンですよね。 最後の話は目からうろこでした。問題解決なのだからHowを考えるのは当たり前だと思っていましたが、確かにIssueがあるからHowを考えているわけです。 今回で言えば、組織が記憶喪失になってしまうことがIssueなわけで、それに対する一つのHowがADRだといえます。 相談を受けて試しに書いてみたADR アドバイスを受けて、さっそくこの相談をADRにしてみることにしました。 例えば次のようになるでしょう。 タイトル： エンジニアリング組織を運営するための知恵が必要な際の問い合わせ先 背景： 次の通り 「何か決定した事実」は残るが「なぜそう決定したか」の記録が損なわれる事象が連続して発生し、これを仕組みで防止するための手段が何かあるのではと考えた こういった話はryuzeeさんが最も詳しいと思われた（開発組織を動かすプロセスに関するスライドや、発表を見聞きしていたため） 油セールがあるために、ふらっと会話しやすいと思われた もし人違いなら他の人に転送してくれるだろうと思われた 当初課題への対策としてADRを提示してもらえた 決定： まずryuzeeさんに相談し、なんらか回答いただくか、適切な転送先を指南してもらう 状態： 運用中。ryuzeeさんへの相談がしづらい状況（一例として、油セールの中止、技術顧問からの引退）になった際は更新を要する。 これは非常にシンプルな例ですが、もっと込み入った内容を記録しておくことももちろんできます。 こちらのリポジトリでADRのテンプレートがいくつか紹介されており、ほかにどんな項目を書いておくべきか参考になります。 例えば自らのプロジェクトに適用するADRテンプレートをこれらを参考に作ったとして、 その制作経緯・過程をADRとして記録しておくのもよさそうです。 まとめ 同僚のmahitoは、千葉市動物公園に長いこと肉食獣が存在しなかったことに実は理由がなかったことを引き合いに、今回の話を関連付けて次のように述べています。 定期的に見直す話 なぜこうなってるかが残されておらず、現状から誤った類推がされてきたが、調べると理由などなかったと。 組織にもこういう事が多くあり、どうすればという話を @ryuzee さんに先日したら、Architectural Decision Records という話を教えてもらった。 https://t.co/6qMtNRQOBC https://t.co/mUHQKD8pKf — Mahito / まひと (@Mahito) 2024年2月1日 人々の意識に浸透したものは放っておいても残りますが、なぜそうなったかが記録されていないと振り返りもできなければ旧弊を振り切って先へ進むことも難しくなります。 私見では、こうしたルールはできればプロジェクトの最初に、コミュニケーションルールの一環として決められるとよさそうに感じました。 みなさんのプロジェクトでも、この記事がなんらかの参考になれば幸いです。

こんにちは、クラウド&ネットワークサービス部の 福岡 です。 SDPF（Smart Data Platform） クラウドの IaaS である、 ベアメタルサーバー ・ ハイパーバイザーサービス 開発のソフトウェアエンジニアとして働いています。 本記事では、リリースプロセスの改善を目指して QA チームが実施している試験の一部を自動化したことで、チームの底力が爆上がりした事例について紹介します。 SDPF ベアメタルサーバーサービスのミッション 機能リリースまでの流れと課題 課題1: 価値提供までのリードタイムが長くなる 課題2: QA チームの稼働がひっ迫する QA 削減に向けた取り組み 〜自動テストによる代替〜 思いがけない困難 どうやってこの困難に立ち向かったのか 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 2. チームでサービス説明書の読み合わせ会を実施 取り組みの成果 1. QA の稼働削減 2. ソフトウェアの品質向上 3. セキュリティ向上 うれしい副次的効果 〜スキルの底上げ〜 1. サービス仕様の理解が向上 2. QA 試験項目の理解が向上 まとめ SDPF ベアメタルサーバーサービスのミッション ベアメタルサーバーサービス は、NTT コミュニケーションズが提供している Smart Data Platform におけるクラウド/サーバーメニューの1つです。 このサービスは OS インストール済みの物理サーバー（ベアメタルサーバー）をオンデマンドに提供するサービスです。 ユーザーは、物理サーバーのスペック、OS の種類などの情報をポータルの画面から指定することで、数十分後に諸々の設定が完了した物理サーバーにリモートでアクセスできるようになります。 このベアメタルサーバーサービスですが、開発の重要なミッションの1つとして 「最新の OS / ハードウェアの継続提供」 があります。 例えば、我々は物理サーバーにインストールできる OS として Red Hat Enterprise Linux (RHEL) を提供していますが、定期的に公開される RHEL の最新バージョンに可能な限り早く追従することを目指しています。 機能リリースまでの流れと課題 ベアメタルサーバーサービスの機能リリースは以下の流れで行なっています。 IaaS という、小さな不具合が大きな損害に繋がりかねないサービスを提供している以上、個々のプロセスは不可欠なものなのですが、 機能開発が完了してから商用環境にリリースしてユーザーに価値を提供できるようになるまで、およそ3ヶ月ほどかかってしまっているのが現状です。 その中でも大きな割合を占めるのが QA チームによる QA (品質保証) でした。 ベアメタルサーバーサービスでは、リリースまでにかかる QA の期間の長さが原因で、以下のような 2 つの課題が生じていました。 課題1: 価値提供までのリードタイムが長くなる 当たり前の話なのですが、機能開発が完了してからユーザーに価値を提供できるようになるまでのリードタイムが長くなります。 先ほど述べたように、我々のミッションは最新の OS を「可能な限り早く」提供することなので、この問題は致命的です。 課題2: QA チームの稼働がひっ迫する QA チームは我々以外のチームの QA を兼任しているため、慢性的に稼働が足りない状況になりがちです。 我々が依頼する QA の期間が長くなってしまうと QA チームの稼働がひっ迫し、本当に QA が必要なところで QA の稼働が取れず、SDPF 全体の開発が停滞することに繋がります。 QA 削減に向けた取り組み 〜自動テストによる代替〜 これらの課題を解決するため、QA チームに実施してもらっている試験項目を精査し、 自動テスト で代替することを考えました。 QA の試験項目には以下のようにさまざまな項目がありました。 サーバー作成が正常に行われること 作成されたサーバーの設定が想定通りであること GUI の表示が想定通りであること 課金が正しくできること etc... これらの項目のうち、CLI で実装可能である 「サーバー作成が正常に行われること」「作成されたサーバーの設定が想定通りであること」 の2つにスコープを絞れば、QA を自動テストで代替できるのではないかと考えました。 実装イメージは、 Serverspec 等を利用した下記のようなものであり、 提供している OS (VMware ESXi, RHEL, Windows 等、細かいバージョン違いを含めておよそ 20 パターンほど) 全てを対象とする想定でした。 # Chronyの起動と有効化をテスト describe service( ' chronyd ' ) do it { should be_running } it { should be_enabled } end # NTPの停止と無効化をテスト describe service( ' ntpd ' ) do it { should_not be_running } it { should_not be_enabled } end # clond-initのインストール状況とバージョンをテスト describe command( ' cloud-init --version ' ) do its( :stdout ) { should match( / cloud-init 22 \. 1-9 \. el9 / ) } end ... 思いがけない困難 しかし、この取り組みですが、計画したはいいものの一向に進む気配がありませんでした。 OS インストール後のサーバーの状態を試験するという特性上、自動化に工夫 1 が必要になること、および、OS の種類が 20 種類と多く実装稼働がかかることも理由の1つでしたが、それ以外にもっと大きな原因がありました。 それは 「網羅性が低く、かつ、メンテナンスされていない自動テストがすでにそこそこ存在していたこと」 です。 既存のコードの保守改修をしている方は共感していただけるかと思うのですが、このような自動テストを網羅性がある完全なものにするのは、大事な作業ではあるものの、創造性があまりなく面白味にかけます。 すでに存在していることが、逆にモチベーションを阻害します。 また、実装が完成したとしても 「コードレビューが滞りがちになってしまう」 という問題もありました。 これは、今回の自動テストの再実装においては、レビュアーは実装されたものが「網羅性のある完全なテスト」であることを逐一確認する必要があるため、レビュアーの負荷が高くなってしまうことが原因でした。 さらに、 「日々締切のある機能開発に追われている状況」 であったことも相まって、この自動テストの再実装はやらなくても直近で問題がないタスクとして後回しになってしまいました。 どうやってこの困難に立ち向かったのか なんとかしてこの取り組みを推し進めるために、主に2つの工夫を取り入れました。 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 1つめの工夫は、自動テストの再実装をそれ単体のタスクして扱うのではなく、新バージョン OS メニューの開発タスクとをセットで実施するようにしたことです。 例えば RHEL 9.2 メニューの新規開発をするときには、同時に RHEL に関する自動テストを過去バージョンを含めて全て実装し直すことにしました。 新バージョンの OS メニュー開発という締切があるタスクと、自動テストの再実装という締切のないタスクをセットにして実施することによって、インクリメンタルに無理なくこれまでの開発サイクルに組み込むような形で、自動テストの再実装を推し進めることができました。 2. チームでサービス説明書の読み合わせ会を実施 サービス説明書（サビ説）とは、我々が提供するサービスで満たすべき要件が記載されている文書です。 自動テストの実装およびレビューは、この文書をベースにして網羅的かつ正確に行う必要があります。 ただ、文言が全体的に固かったり、OS に関する事前知識が必要だったりと、少しとっつきにくいところがあります。 自動テストのレビューが滞る要因の1つに、レビュアーのサビ説を把握する手間があるのではないかと考え、 事前に自動テストの実装に必要なサービス説明書の読み合わせ会をチーム全体で開催することにしました。 この読み合わせ会の開催によって自動テストで実装すべき内容を強制的にインプットする機会を作ることで、実装後のレビューのコストを下げることができました。 取り組みの成果 自動テストの再実装により QA の短縮およびリリースプロセスの改善が達成できたことで、具体的に以下のような恩恵が得られることになりました。 1. QA の稼働削減 単純計算で、単一の OS あたり 20 時間/人ほどの稼働の削減になりました。 我々はおよそ 20 パターンの OS を提供しているため、 リリースごとに 400 時間/人ほど の稼働の削減ができたことになりました。 2. ソフトウェアの品質向上 先ほどおよそ 20 パターンほどの OS を提供していると述べましたが、QA チームの稼働には限りがあるため、実際のところは重要度の高い OS のみを対象にした QA しかできていませんでした。 それ以外の OS については QA を省略してリリースするということが半ば慣習化 しており、過去にそれが原因でトラブルを発生させてしまったこともありました。 しかし今回の取り組みによって、 全ての OS パターンについての網羅的な試験 を自動テストとして実行できるようになったため、ソフトウェアの品質向上に繋がりました。 3. セキュリティ向上 自動テストの実装により、QA チームの作業期間の短縮ができたので、 短いリードタイムでユーザーに最新の OS メニューの提供ができるようになりました。 これにより、脆弱性対応等の OS のマイナーバージョンのアップデート等の軽微な修正であっても、OS をその都度リリースする選択肢が生まれたため、結果的にセキュリティの向上に繋がりました。 うれしい副次的効果 〜スキルの底上げ〜 元々意図したものではなかったのですが、この取り組みを通して、経験の浅いメンバーを含めた開発メンバー全員のスキルの底上げが実現できました。 1. サービス仕様の理解が向上 ベアメタルサーバーサービスは巨大なサービス 2 であるため、経験が浅いメンバーは 「改修で触ったことがある部分はわかるけれど、それ以外の部分はさっぱり」「実装を断片的に読んだことはあるけど仕様はよく覚えていない」 となりがちでした。 今回の取り組みを通して、開発メンバー全員が一通りサビ説の内容が頭に入っている状態にまで持っていくことができました。 特に経験が長いメンバーに偏りがちな 「サービス仕様に関わる問い合わせ対応」 を全員で分担してできるようになったのは大きな成長でした。 2. QA 試験項目の理解が向上 今回の取り組み前は、試験項目のリストアップを QA チームにやってもらっているのをいいことに、 多くの開発メンバーは試験項目に対して興味が薄い状況でした。 恥ずかしながら 「細かいことはあまり把握していないものの、最終的に不具合があったら QA チームによって指摘されるから問題ない」 という意識で開発を進めていることが多々ありました。 しかし今回の取り組みを通して、QA の試験項目のうち「どこが自動化可能なのか」を真剣にチームで議論したことによって、具体的に何を QA で見てもらっているのかについての理解が向上しました。 その結果、「ここは開発のユニットテストでカバーしていて、ここの GUI との結合部分（or 課金部分）はQA チームに見てもらうことになる」というように、個々の機能について最終的にどこで動作確認をするのか、ということを常に意識した 堅実な開発 ができるようになりました。 まとめ 以下が本記事のまとめとなります。 ベアメタルサーバーサービスではリリースプロセスにおいて時間のかかる QA が課題であった OS インストール後のサーバーの状態を確認する自動テストの再実装をして、QA のプロセスを一部短縮 優先度が低くなりがちな自動テストの再実装を推し進めるために、以下の工夫を導入 締切有りのタスクと締切無しのタスクをセットで行う レビュー負荷の軽減を目的としたサービス説明書の読み合わせ会を実施 結果的にリリースプロセスの改善だけではなく、開発メンバー全員のスキルの底上げを実現 最後になりますが、SDPF クラウドは国内最大級のクラウドサービスです。 開発メンバーは、数千台以上の物理サーバーの操作の自動化をはじめとした、技術的難易度の高い課題に取り組みつつ、日々より良いサービスにしようと邁進しております。 直近ではベアメタルサーバー・ハイパーバイザーチームは「 B26.大規模国産クラウドを支える IaaS (ベアメタルサーバー/ハイパーバイザー) のソフトウェア開発 」というポストで現場受け入れ型インターンシップの募集をしています。 本記事に興味を持った学生の方は是非奮ってご応募ください。 例えば、実行環境ごとに異なるネットワークの設定やライセンス認証まわりの差分吸収や、ハードウェアごとに異なるストレージ周りの差分吸収などの工夫が必要になりました。 ↩ 具体的には、ソースコード行数が 50 万行以上、管理 VM 数が 1000 以上、管理物理サーバー数が数千台以上、といったところです。 ↩

NTTコミュニケーションズ（以下、NTT Com）を含めたドコモグループでは、この夏に サマーインターンシップ2024 を開催します！ この記事では、その中でも NTT Com のリアルな業務を体験できる「 現場受け入れ型インターンシップ 」について紹介します。 現場受け入れ型インターンシップとは 募集ポスト これまでのインターンシップの様子 AI分野 セキュリティ分野 ネットワーク分野 ソフトウェア/クラウド分野 まとめ 現場受け入れ型インターンシップとは NTTドコモや NTT Com の社員と一緒に働きながら、実務を体験していただくインターンシップです。 エンジニアやセールス、ビジネスデザイン、リーガルなど幅広いワークフィールドを取り揃えて、業務体験を通じて仕事の理解を深め、成長機会を提供する内容となっています。 今季は 2024年8月26日（月）～9月6日（金）の土日祝日を除く10日間（2週間） で開催されます。開催場所は、出社＋リモートワークのハイブリッド形式です（出社割合はポストにより異なります）。 募集ポスト 各ワークフィールドの募集ポストについては、ワークフィールドごとのポスト情報をご覧ください。 地域エリア [PDF] ソリューションエンジニア [PDF] プロダクト・サービスエンジニア [PDF] AIエンジニア・データサイエンティスト [PDF] セキュリティエンジニア [PDF] ネットワーク・インフラエンジニア [PDF] 6G・IOWNエンジニア [PDF] セールス [PDF] ビジネスデザイン [PDF] リーガル [PDF] 記載されているポストのうち、受け入れ会社に NTTコミュニケーションズ と記載されたポストが NTT Com での業務です。 これまでのインターンシップの様子 NTT Com のエンジニア系ポストに参加した学生の方々が、これまで開催したインターンシップの体験記をこの NTT Communications Engineers' Blog に寄稿してくれています。 「インターンシップでどんなことに取り組むのだろう？」、「インターンシップを通して何が学べるのだろう？」といった疑問を解消する手助けになれば幸いです。 AI分野 インターンシップでマルチA100 GPUサーバをぶん回してみた - NTT Communications Engineers' Blog （2022年・冬） セキュリティ分野 セキュリティ技術開発のインターンシップに参加させていただきました!! - NTT Communications Engineers' Blog （2021年・夏） インターンシップ体験記 〜セキュリティ運用の健全化を目指すMetemcyberの開発〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 - NTT Communications Engineers' Blog （2023年・冬） インターンシップ生があるSaaSを用いた未知のC2脅威を実証してみた - NTT Communications Engineers' Blog （2023年・冬） 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） Pool Partyという攻撃手法を通じてWindowsの深淵を覗いた７日間（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） フィッシングキットから生成されたサイトの調査 (インターンシップ体験記) - NTT Communications Engineers' Blog （2024年・冬） ネットワーク分野 ネットワーク知識ゼロの大学院生が、NTTコミュニケーションズのインターンシップに参加してみた - NTT Communications Engineers' Blog （2021年・夏） インターンシップ体験記 〜BGP-LSの機能をFRRに実装してみた〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SRv6 L3VPN機能検証〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SR-MPLS IPv6 Underlay 相互接続検証〜 - NTT Communications Engineers' Blog （2023年・冬） インターンシップ体験記 〜SRv6 機能を Pola PCE に実装してみた〜 - NTT Communications Engineers' Blog （2023年・冬） SRv6/SR-MPLS相互接続を実現するための機能をFRRに実装してみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） ソフトウェア/クラウド分野 IoT Connect Gatewayを使ってみた 番外編 ～インターンシップでリリース前の機能を使って開発してみた～ - NTT Communications Engineers' Blog （2021年・夏） IoT Connect Gatewayを使ってみた 番外編 第2回 ～インターンシップでStorage転送機能を使って開発してみた～ - NTT Communications Engineers' Blog （2022年・冬） テレプレゼンスPJ インターン参加レポート - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SDNコントローラの性能改善〜 - NTT Communications Engineers' Blog （2023年・冬） インターン参加記 ～GPUクラスタ管理者への道～ - NTT Communications Engineers' Blog （2023年・冬） TypeScript未経験の学生がSkyWayの開発に取り組んでみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） データプレーンに起きたバグにパッチを当ててみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） パケット爆発を解析してみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） なお、NTT Com のデザイン系ポスト（KOEL）については KOEL公式note 、NTTドコモのエンジニア系ポストについては ドコモ開発者ブログ をご覧ください。 まとめ みなさんもこの夏、ドコモグループのインターンシップに参加して興味分野で熱い夏を過ごしてみませんか？ 気になる開催概要とポスト情報はこちらです（再掲）。 現場受け入れ型インターンシップ エントリーはこちらです。 ドコモグループ マイページ エントリーシートの提出締め切りは 2024年6月21日（金）23:59 です。 なお、今年度は 冬の現場受け入れ型インターンシップは予定されていません 。 興味のある方は、ぜひ夏のインターンシップをご検討ください。 みなさんのご応募をお待ちしています！

この記事では、Ruby の非同期処理ライブラリである Sidekiq を使って定期実行処理を行う Sidekiq-Cron の監視方法について、チームでの方式検討の様子を交えながらご紹介します。 目次 目次 はじめに Sidekiq-Cron について Sidekiq-Cron の cron job の status の監視 既存の status 監視の問題点 既存の監視の仕組みの問題点 負荷が低い監視の仕組みの検討 案1：全 cron job の status を定期的にダンプし、ダンプ結果を読み取って監視する 案2：Redis を直接参照して cron job の status を読み取る 案3：Sidekiq の GUI の html ページの内容をパースして status を取得 [採用] 案4：Sidekiq の GUI に新しいエンドポイントを実装して、そのエンドポイントから status を取得 案5：そもそも複数の cron job の status を監視するのをやめる さいごに 参考 はじめに こんにちは、クラウド & ネットワークサービス部で SDPF のベアメタルサーバー 1 ・ハイパーバイザー 2 の開発をしている山中です。 私のチームでは Ruby でサービスを開発しています。 API リクエスト受付など、さまざまな処理を gem を利用しながら実装しており、中でも定期実行処理は Sidekiq-Cron という gem を利用して実現しています。 先日チームで Sidekiq-Cron の監視の実装について議論している最中、チームメンバーから巧いと言われた実装がありました。 今回の記事では、実装内容を簡単に紹介しながら、普段チームでどういった観点で実装の方式を検討しているかご紹介したいと思います。 Sidekiq-Cron について Rails でもよく使用されている Sidekiq という非同期処理ライブラリを使って、定期実行を可能とする gem です。 定期実行処理は cron job という単位で定義でき、cron job ごとに status を enabled / disabled に設定することも可能となっています。 Sidekiq では、メインであるジョブを処理するプロセスの他に GUI のプロセスも起動でき、Sidekiq-Cron を導入すると以下のように GUI にもページが増え、cron job ごとの status や実行状況などを確認できるようになります。 Sidekiq-Cron の cron job の status の監視 私たちが運用しているサービスでは、各 cron job の status は全て enabled であることが期待値です。disabled があるとサービス影響につながる場合があります。 一方、cron job の status はメンテナンス作業の中で一時的に disabled に変更されることがあり、メンテナンス作業後は status を enabled に戻さなければいけません。 しかし、メンテナンスは人間が行う作業というのもあり、enabled に戻し忘れてしまうという問題が時折発生していました。 私達のチームではこの問題への対策として、enabled に戻し忘れたことに気付けるように一定間隔で status を取得し、enabled ではない場合にアラートを上げるような監視の仕組みも作っています。 既存の status 監視の問題点 この監視の仕組みですが、1つ問題が存在していました。それは1番重要な1つの cron job しか status を監視していなかったという問題です。 この問題により、監視対象ではない cron job の status が長期間 disabled になっていることに気付けなかったという問題が先日発生してしまいました。 振り返りの結果、全て（16個）の cron job の status を監視しようとチームで合意し、実装方式の検討が始まりました。 既存の監視の仕組みの問題点 既存の status 監視では、以下のような Ruby スクリプトを実行して status を取得しています。 （本筋から外れるので説明は割愛しますが、 Consul を使用してスクリプトを定期的に実行しています。） # cron job 名を引数に渡して実行することで status を取得 require ' sidekiq-cron ' < Sidekiq を Redis に接続する記述> job = Sidekiq :: Cron :: Job .find( ARGV [ 0 ]) if job.present? puts job.status else puts "#{ ARGV [ 0 ] } does not exist in cron jobs " exit 1 end 当初は 16個の cron job それぞれについてスクリプトを実行し、それぞれの cron job の status を取得すれば良いと考えていました。 ところが、スクリプト実行時の負荷を計測した結果、16個並列でスクリプトを実行すると CPU 使用率が 75% 以上に高騰してしまうことが判明してしまいました。 status 取得自体の負荷は軽いのですが、Ruby プロセスを起動してライブラリのロードをする部分の負荷が高く、既存の監視スクリプトを安直に16個並列で実行するのはやめようという流れになりました。 負荷が低い監視の仕組みの検討 結論から述べると、最終的にチームで合意したのは以下の案4です。 メンテナンス性や心理的な受け入れやすさ、動作の軽量さなどを考慮した結果、この案を採用することになりました。 ここでは各案の内容と、実際にチームで議論したときに上げられたメリット・デメリットを簡単に紹介します。 案1：全 cron job の status を定期的にダンプし、ダンプ結果を読み取って監視する 1回の Ruby スクリプトの実行で全ての cron job の status を取得してファイルにダンプし、各 cron job の監視ではダンプファイルを読み取って status を取得して監視をするという案です。 メリット 負荷が高い Ruby プロセスの起動やライブラリのロード部分を1回に集約することで負荷の軽減が可能 デメリット cron job の status をダンプする処理を別途実装する必要がある 厳密に現在の cron job の status を取得できるわけではない 仕組みとしてややこしい感が強い 案2：Redis を直接参照して cron job の status を読み取る Sidekiq は Redis にデータを書き込んでいるため、Redis に書き込まれている cron job の status を以下のように redis-cli コマンドで直接取得するというアイデアです。 redis-cli -a <password> -h <redis_address> hget <application_name>:cron_job:<cron_job_name> status メリット Ruby を使用しないため動作が軽い デメリット Sidekiq がラップしている部分（Sidekiq の利用者が本来意識しなくて良い Redis の中身の部分）を意識する必要がある 深いところを直接触りすぎている感がある 案3：Sidekiq の GUI の html ページの内容をパースして status を取得 最初に紹介したように Sidekiq には cron job の status を確認できる GUI が存在します。 以下のように curl で GUI の html ページを取得し、取得結果をパースして status を取得するというアイデアです。 curl -ks -u <user> :< pass> http :/ /<sidekiq_gui_address> / cron / <cron_job_name> | grep -o - E ' enabled|disabled ' メリット Ruby プロセスを新規に起動しないため動作が軽い GUI サーバとして既に起動している Ruby プロセスを利用することで、負荷が高い Ruby プロセスの起動やライブラリのロードを行わなくて済む デメリット html ページのパースは仕組みとして頑健ではない、強引に欲しい値を取得している感がある html ページがパースされることは Sidekiq の作者も想定していないはず Sidekiq のバージョンアップなどによって html ページの構造が変わったときに、値のパースができず監視の仕組みも動かなくなる恐れがある [採用] 案4：Sidekiq の GUI に新しいエンドポイントを実装して、そのエンドポイントから status を取得 cron job の status を取得する GUI のエンドポイントを Ruby のクラス拡張で新規に実装し、実装したエンドポイントから status を取得するというアイデアです。 Sidekiq に GUI があるということは「 各ページを表示するためのエンドポイントの実装があるはず 」というところに着目し、その実装を拡張すれば良いのではないかという流れでこのアイデアを思いつきました。 以下のように Sidkiq の GUI を起動するためのコードを実装し、新しいエンドポイントを実装します。 require ' sidekiq-cron ' < Sidekiq を Redis に接続する記述> use Rack :: Session :: Cookie , secret : SecureRandom .hex( 32 ), same_site : true , max_age : 86_400 module CustomWebExtension def self . registered (app) app.get ' /cron/:name/status ' do @job = Sidekiq :: Cron :: Job .find(route_params[ :name ]) if @job .present? @job .status else "#{ route_params[ :name ] } does not exist in cron jobs. " end end end end Sidekiq :: Web .register CustomWebExtension run Sidekiq :: Web .new メリット 案3と同じく Ruby プロセスを新規に起動しないため動作が軽い html ページという本来パースして値を取得するためのものではない所から欲しい値を取得しているわけではないため、案3よりも強引感がない クラス構造は html ページの構造よりも変化しづらいはずなので、案3 よりも頑健なはず デメリット Sidekiq のライブラリ構造が変わることで、将来的に動作しなくなる可能性がある 基本的にクラス拡張は避けた方が良い 案5：そもそも複数の cron job の status を監視するのをやめる うまく実装できる案が無いのであれば、現状を維持し、問題に遭遇するリスクを許容するという案です。 言わば戦略的撤退ような案ですが、他の議論でも時折このような案を採用することがあります。 さいごに いかがでしたでしょうか？ チームで実装方式について議論するときは、頭を柔らかくして複数の案を考え出し、あえて採用されないであろう案も提示し、その中から現状の最適解を選ぶことで、チーム全員の納得感を高めています。 口頭で話すだけだと各案のデメリットばかりに着目してしまい、議論がなかなか進みませんが、メリット・デメリットを書き下して共有しながら議論を進めることで冷静に各案を比較でき、円滑に議論を進められます。 また、今回採用した案のように、既存ライブラリのモジュールを拡張して新たな機能を簡単に追加できるのは、メタプログラミング 3 が得意な Ruby ならではだと思います。 既存ライブラリのモジュールに手を加えると、ライブラリのバージョンアップなどで将来的に動作しなくなる可能性ありますが、多用しなければ非常に強い効果を発揮すると思います。 みなさんもライブラリのコードの深い部分まで読みつつ、ここぞという場面で独自の拡張を入れてみるのはいかがでしょうか？ 最後になりますが、SDPF クラウドは国内最大級のクラウドサービスです。 開発メンバーは、数千台以上の物理サーバーの操作の自動化をはじめとした、技術的難易度の高い課題に取り組みつつ、日々より良いサービスにしようと邁進しています。 今回紹介した監視の実装など、実際にコードの深い部分まで理解したうえで、自分たちで手を動かして実装方式を検討しています。 直近ではベアメタルサーバー・ハイパーバイザーチームは「 B26.大規模国産クラウドを支える IaaS (ベアメタルサーバー/ハイパーバイザー) のソフトウェア開発 」というポストで現場受け入れ型インターンシップの募集をしています。 本記事に興味を持った学生の方は是非奮ってご応募ください。 参考 SDPF ベアメタルサーバー・ハイパーバイザー関連資料 クラウドサービスのウラオモテ SDPF ベアメタルサーバー/ハイパーバイザー開発における GitHub Actions を活用した CI 事例の紹介 専有型の物理サーバーをオンデマンドに利用可能とするサービス。 https://sdpf.ntt.com/services/baremetal-server/ ↩ ベアメタルサーバー上に vSphere ESXi や Hyper-V など代表的なハイパーバイザーを予めセットアップした状態で利用可能とするサービス。 https://sdpf.ntt.com/services/vsphere/ https://sdpf.ntt.com/services/hyper-v/ ↩ プログラミングコードを記述するコードを記述すること、既存の言語を拡張して動的にコードを変更するといった概念 ↩

はじめに こんにちは、インターン生の 鈴木健吾 です。 私は現在修士 2 年生で、学部 4 年生から研究室や WIDE プロジェクト でネットワークの構築・運用に関わったり、Interop や JANOG などのイベントに足を運んだりしています。 このたび、2024 年 2 月に NTT コミュニケーションズで 2 週間の現場受け入れ型インターンシップに参加させていただいたので、その体験談を執筆させていただきます。 目次 はじめに 目次 参加したインターンシップについて 配属されたチームについて インターンシップの課題 インターンシップで取り組んだこと 障害の再現 障害の解析 ネットワーク側の解析 ファイアウォール 側の解析 ファイアウォールの動作がおかしいことの証明 障害の解決確認 まとめ 反省 感想 メンターからのコメント 次回インターンシップのお知らせ 参加したインターンシップについて 配属されたチームについて 私は 「エンタープライズ向け大規模クラウドサービスを支えるネットワーク開発」 というポストで、NTT コミュニケーションズのサービスの 1 つである Smart Data PlatForm (SDPF) クラウドの NFV チームでインターンに参加させていただきました。 SDPF クラウド とは、エンタープライズ向けのクラウドサービスで、「オンプレミスのネットワークをそのまま持ち込める IaaS」を目標にしています。 下の図は SDPF クラウド のアーキテクチャを表しており、 ネットワーク仮想化技術である EVPN-VXLAN によって ハードウェア VTEP 配下のベアメタルサーバ やソフトウェア VTEP (VXLAN Tunnel End Point) 配下の VM などが L2 で連結されることでカスタマーの要望に合わせた柔軟なネットワークの提供を可能にしています。 私の配属された NFV チームは SDPF クラウドのファイアウォールやロードバランサーのサービス開発などを担当しているチームです。 インターンシップの課題 私が今回取り組んだテーマは、このインターンの 3 ヶ月ほど前に実際に発生した 障害対応の追体験 でした。 その障害の内容とは 「パケット爆発」 で、NFV チームがファイアウォールの更改作業をしていた際にマネジメントネットワークで DDoS 検知が作動したことで発覚しました。 この障害について、簡素化された当時の再現環境が用意され、 「マネジメントネットワークで、ファイアウォール VM にパケットを流しながらその VM を消すと、パケットが爆発する」 という情報からその原因解析に取り組みました。 インターンシップで取り組んだこと 私は 2 週間のインターン期間で、大きく次の 3 ステップで課題を進めました。 障害の再現 障害の解析 障害の解決確認 障害の再現 再現環境では下の図のようなネットワークが用意されていました。 図中で FW はユーザに提供されているファイアウォールを表します。FW のマネジメントインターフェースが繋がっているマネジメントネットワーク（mgmt_nw）とバックヤードネットワーク（backyard_nw）の間にはゲートウェイ（GW）があります。 作業の中心となる VM からは GW 越しに FW に ping などを送ることができます。 この状態からマネジメントネットワークに新たな FW-4(IP アドレス 192.168.1.104)を作成し、VM から ping を打ちながら削除すると、ping 出力画面に突然 「Time to Live Exceeded」 の出力が大量に流れるようになり、パケット爆発を再現できました。 障害の解析 ネットワーク側の解析 最初に、このパケット爆発がどのように収束するのかを調べました。 パケットの爆発を確認してから ping を止めたり、再度送信したりすると、次のことがわかりました。 ping を打つのを止めてしばらくすると、再度送信してもパケットは爆発しない ping を打ち続けているとパケット爆発は終了しない ping を打つのを止めてすぐに再度送信すると、パケットは爆発する 次に、 ファイアウォールに流れるパケットを tcpdump でキャプチャすることで、マネジメントネットワークにどのようなパケットが流れているのかを観察しました。 下の図は VM から（削除済みの）FW-4 に ping のパケットを 1 つだけ送信したときの FW-1 でのパケットキャプチャの結果を示しており、全部で約 18 万個のパケットが流れてきたことがわかりました。 このパケットキャプチャの結果を「送信元 MAC アドレス」や「宛先 MAC アドレス」、「TTL」 に注目して解析すると、FV-1~FW-3 は FW-4 の インターフェースの MAC アドレス宛のパケットを受信して、その TTL を 1 減らし、FW-4 宛に転送していることがわかりました。 これにより、パケット爆発のメカニズムが次のように説明できます。 VM から FW-4 に ping を打っている状態で FW-4 が削除されると、マネジメントネットワークの L2 スイッチ機能によって 全ての FW にパケットがフラッディングされる 各 FW に届いたパケットは 各々 FW-4 宛に転送される 転送されたパケットが 1 と同様に他の全ての FW にフラッディングされ、さらに転送される このプロセスがパケットの TTL が 0 になるまで繰り返される ここまでの解析でファイアウォールが自分のインターフェース宛でないパケットを転送してしまうことがパケット爆発の原因であることがわかりました。 ファイアウォール 側の解析 本来、ネットワーク機器は受信パケットを低いレイヤーから処理し、自分のインターフェース宛でないパケットは L2 の段階で破棄（フィルタリング）するはずです。 それでは何故 FW-1~FW-3 は FW-4 のインターフェース宛のパケットをフィルタリングしないのでしょう。 私は最初に、ユーザの設定したファイアウォールの設定に関連するものがないかを調べました。 しかし、MAC アドレスによるフィルタリングを無効にするような設定（例えばプロミスキャスモードを on にするなど）は見つかりませんでした。 困っていると、次のヒントが与えられました。 この障害は開発環境でのテストでは発生しなかった 開発環境と再現環境の設定の違いは ARP の Passive Learning が有効になっていること ARP の Passive Learning とは、受信した GARP(Gratuitous ARP)を ARP テーブルの学習に利用するというもので、GARP はネットワークに接続されたホストが最初に IP アドレスの衝突を回避するために ARP 要求を送信する仕組みです。 しかし、この設定の有無で MAC アドレスのフィルタリングに影響を与えるとは考えられません。 ここで解析が行き詰まり、ネタバラシが入りました。 実は、この障害の原因はユーザの設定起因やクラウドのバグではなく 「ファイアウォールの OS の不具合」 でした。すなわち、「ファイアウォールの動作がそもそもおかしいこと」だったのです。 サービス環境では、受信パケットに対するフィルタリングが機能していないことに加えて、ARP の Passive Learning が有効になっていたファイアウォールではそのパケットを転送する条件も揃っていたため、このパケット爆発という現象に繋がったのです。 ファイアウォールの動作がおかしいことの証明 ここまでの検証から、今回の障害の原因はファイアウォールのアプライアンス OS の不具合にある、ということがわかりました。 したがって、この障害を解決するためにはベンダーにファイアウォールのアプライアンス OS の不具合を示して、修正してもらう必要があります。 しかし、これまでの検証ではベンダーに対してイメージの実装に不具合があると断言することは難しいです。 なぜなら、この検証は複数のホストが存在する複雑な環境で行われており、ファイアウォールにも ARP の Passive Learning などさまざまな設定がされており、それらが今回の障害に関係するかもしれないからです。 もっとシンプルで端的な検証により、不具合を証明する必要があります。 そこで、下の図のような環境を用意しました。 まず、ファイアウォールは 1 つにし、初期設定のままにします。 ARP テーブルは ARP Passive Learning を用いなくても、コマンドを使って自由に操作できるため、GW と FW-1 の ARP テーブルに 192.168.1.104 というネットワーク上に存在しない架空の IP アドレスと、それに対する架空の MAC アドレスのレコードを挿入しました。 この条件で、架空の IP アドレス & MAC アドレス宛のパケットを FW-1 が転送することを確認できれば、予期せぬ動作の原因がイメージ実装の不具合にあると主張できます。 実際に、これまでと同様に VM から 192.168.1.104 へ ping を打つと、全く同じ現象を再現できました。 障害の解決確認 ここまでの検証と問い合わせは、実際に NFV チームがインターン開始前にやっていたことでした。 すでに新しいイメージが出されており、この新しいイメージで先ほどと同様の検証することで不具合が修正されていることを確かめられるはずです。しかしながら、検証の結果、新しいイメージでもパケットの転送が確認されてしまいました。結局完全解決を見る前にインターンは終わってしまいました。 まとめ 反省 今回は 2 週間のインターンシップに参加させていただきましたが、祝日が挟まったり、大雪の影響を受けたりした結果、実際には 6 日にも満たない短期間で課題に取り組むことになりました。 限られた時間の中でしたが、これまで Linux やネットワーク機器に触ってきたことによる慣れや事前知識、トラブルシューティングの経験のおかげでファイアウォールの解析まで約 1 日半とスムーズに進めることができたと思っています。 しかし、これまでネットワークのトラブルは自身の設定ミスだったり仕様の把握が甘かったりが原因であったため、そもそもの OS がおかしいという発想になかなかなれなかったのが悔やまれます。 ファイアウォールの動作がそもそもおかしいことの証明までノーヒントで辿り着くことができれば完璧でした。 感想 本インターンシップに参加する前は NTT コミュニケーションズの SDPF クラウド というサービスを知らなかったのですが、パブリッククラウドサービスを提供しているという国内有数のとても魅力的なチームでした。 私は本インターンシップで初めてビジネスのネットワークの運用・構築を間近で見ることができ、とても貴重な学びを得られたと感じています。 障害当時のチームの対応履歴も拝見させていただき、ビジネスのネットワークではこれまで私の経験してきたただ直すだけのトラブルシューティングとは異なり、カスタマーを第一に考えた対応が求められることがわかりました。 技術的には、これまで度々耳にしていた EVPN-VXLAN をちゃんと勉強できたことや初めて ARP にフォーカスしたトラブルシューティングができたことがとても学びになりました。 私がこれまであまり経験してこなかった冗長化や自動化の重要さも教えていただき、これから勉強していこうと思いました。 課題以外でも、NFV チームの一員として実際のミーティングに参加させていただいたり、チームに関わるさまざまなお話を聞かせていただいたりと NFV チームのリアルを体験でき、とても有意義なインターンシップでした。 また、他のインターン生や社員さんとの交流の場もたくさん用意していただき、とても楽しいインターンシップでした。 最後に、メンターの石井さんをはじめ NFV チームの皆さん、並びに関わっていただいた社員さんやインターン生に皆さん、このインターンシップに参加させていただいたことに感謝を申し上げます。 メンターからのコメント SDPF クラウドで NFV 開発を担当している石井です。鈴木さん、2 週間お疲れ様でした。 天候の影響もあり予定より日程が少なかったですが、交流イベントにも全参加しつつ、業務も効率よく進めていただきました。 さまざまな要因が考えられる事象の解析にチャレンジいただきましたが、持ち前の知識・経験を生かし、発生している事象から原因の切り分けまで我々の想定を超えて素早く進めることができていました。 幅広い技術力と積極性があり、これからもご活躍されることと思います。心より応援しております。 次回インターンシップのお知らせ ドコモグループでは サマーインターンシップ2024 を開催します。 鈴木さんが参加された 現場受け入れ型インターンシップ も下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 本記事に関連するポストは「 B21.エンタープライズ向け大規模クラウドサービスを支える仮想ネットワークソフトウェア開発 」（PDFファイル、22ページに記載）です。 興味を持たれた方はぜひご応募ください。

はじめに こんにちは、ドコモグループのウインターインターンシップ2023に参加した猪飼です。 普段は、大学院でマルウェアの動的解析に関する研究をしています。 「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明するセキュリティアナリスト」のポストに参加させていただきました。 この記事では、私がインターンシップで取り組んだ内容について紹介します。 NA4Secプロジェクトについて まずは、私がお世話になったNA4Secプロジェクトについて紹介します。 正式には「Network Analytics for Security」というNTTコミュニケーションズ イノベーションセンターのプロジェクトであり、通称NA4Sec（なよせ）と呼ばれています。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」という理念に基づき、攻撃インフラの解明、撲滅の実現を目指して活動しているプロジェクトです。 参加のきっかけ 現場で業務を体験できるインターンシップを調査していた際、過去にドコモグループのインターンシップを体験した方々のブログを発見しました。ブログの内容が非常に興味深く、「このインターンシップはとても面白そうだな」という印象を受けました。 そこから調べていく間に、セキュリティに関する業務を現場で体験できる点に魅力を感じ、「実際に働く雰囲気を体験したい！」と考え応募しました。また、自分が興味を持っている攻撃インフラに関連するポストが存在したことも、応募の決め手でした。 インターンシップ概要 2/5から2/16までの約2週間、プロジェクトメンバーとして業務を体験させていただきました。 業務はオンラインで実施し、 NeWork というオンラインコミュニケーションツールを活用しました。気軽に相談できる環境・雰囲気であったため、非常に働きやすかったです。 インターンシップにて、「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明すること」をテーマに、私は以下のことに取り組みました。 脅威調査 ペネトレーションテストツールであるCobalt Strikeについて調査し、理解する。 脅威分析1 Cobalt Strikeが悪用された攻撃事例を調査し、ダイヤモンドモデルに基づいて分析する。 脅威探索 デバイス検索エンジンであるCensysを使用し、インターネット上に存在するCobalt StrikeのC2サーバを調査する。 脅威検証 攻撃者が、インフラの秘匿に使用するクローキング技術について調査し、サーバに実装する。 脅威分析2 フィッシングについて調査し、フィッシングキットを解析する。 URLスキャンサービスであるurlscan.ioを使用し、フィッシングサイトを調査する。 今回は、「脅威分析2」について紹介したいと思います。 「脅威分析2」以外の内容に関しては、過去にインターンシップに参加された方の記事が公開されているのでそちらをご覧ください 1 　 2 。 脅威分析：フィッシングキットの解析 私は今回、フィッシングキットの解析に取り組み、以下のワークを行いました。 フィッシングについての調査 フィッシングキットについての調査 フィッシングキットの解析 フィッシングサイトの調査 フィッシング詐欺について フィッシング詐欺とは、通販サイトや会員ページのログイン画面を模倣し、利用者にIDやパスワード、カード情報などを入力させ、情報を搾取する犯罪の一種です。 近年では、フィッシング詐欺の件数は年々増加傾向にあります。フィッシング対策協議会によると、2024年1月に報告された件数は、85,827件でした 3 。 フィッシング詐欺の分業化 フィッシング詐欺の件数が増加している背景として、分業化が考えられます。それぞれの工程を担当する業者が分かれることで、フィッシング詐欺の実行が容易になっています。 以下に、各工程と内容の例を挙げます。 工程 内容 計画 対象の調査・決定 調達 必要ツールや情報の取得 構築 フィッシングサイトの構築 誘導 フィッシングメール、SMSなどの送信 詐取 情報を騙し取る 収益化 盗んだ情報を金銭に変換 強化拡大 攻撃の強化・拡大 フィッシングキットについて フィッシングキットとは、フィッシングサイトを容易に構築可能なテンプレートのことです。高度なスキルを必要とせずにフィッシングサイトの構築が可能となります。このようなフィッシングキットは、秘匿性の高いチャットサービスであるTelegramやダークウェブなどのコミュニティ、配布サイトなどで配布されていると考えられます。 フィッシングキットに含まれるソースコードを解析することで、実装されている調査・解析妨害のテクニックや、通信先といった攻撃者についての知見を得ることができます。また、フィッシングサイトを構築しているファイルのハッシュ値に着目することで、同じフィッシングキットから作成された他のサイトについても調査可能です。 フィッシングキットに含まれるファイルの解析 実際に、フィッシングキットに含まれるファイルの解析に取り組みました。今回対象としたフィッシングキットには3つのファイルが含まれており、各ファイルのソースコードから処理内容を解析しました。 その中で、一部のファイルには、解析を困難にする目的で「難読化」と呼ばれる処置が施されていました。難読化の解除にも取り組みましたが時間が足りず、プロジェクトの方から解除後のソースコードを提供していただき解析を続行しました。自力で難読化を解除できず悔しかったです... 解析から、各ファイルの処理内容、及びフィッシングサイトの挙動は以下の通りだとわかりました。 ファイル 内容 ファイル1 フィッシングサイトを生成し、入力された情報を攻撃者サーバ内のファイル2に送信するphpファイル ファイル2 受け取った入力情報を攻撃者のTelegramやメールに送信するphpファイル ファイル3 メール送信に関する処理が記述されたjsファイル ファイル1が生成したフィッシングサイトに、被害者が情報を入力して送信ボタンをクリックすると、攻撃者サーバに入力した情報が送信されます。この情報をファイル2が受信し、さらに攻撃者のTelegramとメールに送信します。この際、メール送信処理を担当するファイル3も使用されます。 フィッシングサイトの調査 次に、 urlscan.io というサービスを用い、同じフィッシングキットから作成されているフィッシングサイトを調査しました。 urlscan.ioでは、調査対象ページに代理でアクセスし、スクリーンショットや、ブラウザが受信したファイルの一覧、その他の詳細情報を閲覧可能です。また、過去に他のユーザによってスキャンされた結果についても検索できます。 今回、調査した手順は以下です。 urlscan.ioにフィッシングサイトのURLを入力し、過去のスキャン結果を検索します フィッシングサイトを構築するHTMLファイルのハッシュ値を取得します 取得したハッシュ値をurlscan.ioに入力し、同一ハッシュ値を持つサイトのスキャン結果を検索します 同じフィッシングキットから作成されたと考えられるサイトのURLが、900件以上表示されました(2024年2月15日時点) 上記の調査結果より、同一のフィッシングキットから延べ900件以上のサイトが作成された可能性があることが分かりました。 このことから、フィッシング詐欺が増加している一因として、フィッシングキットの流通により、フィッシングサイトの複製が容易になったことが考えられます。 学んだこと 本インターンシップに参加して、さまざまなことを学びました。技術的なことはもちろん、チームで業務を進める雰囲気も体験できました。 以下に学びをピックアップして紹介します。 能動的に情報を収集し、攻撃インフラを発見する体験ができた Cobalt StrikeのC2サーバや、フィッシングサイトのURL調査を能動的に実施した C2サーバのIPアドレスや、フィッシングサイトのURLを発見する経験を積めた セキュリティインシデント事例の調査を体験できた ネット上に公開されている、インシデントに関する記事・情報の調査を実施した Cobalt Strikeを用いた攻撃の流れや脆弱性の悪用、C2サーバに関する情報などの知見を吸収できた 現在でも使用されている攻撃手法や技術について触れられた 攻撃者の視点でクローキングを実装することで、アクセス制御に関する理解が進んだ 年々件数が増加しているフィッシング詐欺について、その背景にあるフィッシングキットの解析を体験できた チームで仕事をする雰囲気を体験できた 情報共有が盛んであり、発言し易い環境を作る重要性を学んだ 疑問点があれば積極的に質問することで、自分が担当している作業の目的が明確になった おわりに 約2週間という期間でしたが、あっという間に過ぎ去ってしまいました。楽しい時間は、過ぎるのが早いです。 今回所属させていただいたNA4Secプロジェクトは、質問や情報共有が非常にしやすい雰囲気であり、素朴な疑問・質問にも丁寧に答えていただきました。また、技術的な学びだけでなく、チームで働く際に必要な事を自分なりに考えるきっかけにもなりました。 受け入れてくださったNA4Secプロジェクトの皆さま、ありがとうございました。 特にインターンシップを担当してくださった神田さん、坪井さん、鮫嶋さんには、非常にお世話になりました。 ありがとうございました。 メンターからのコメント 坪井です。猪飼さん、まずは2週間のインターンシップお疲れ様でした。 今回2週間という短い期間かつ3連休も重なったため、実際に手を動かして作業してもらう期間が短い中、スケジュール通りに予定していた範囲の業務を完遂していただけました。今回のインターンシップではNA4Secの全員と対面で会う機会がなかったものの、NeWorkに参加しているチームメンバに対して積極的に質問をして課題解決をされており、技術スキルだけではなく、社会人としてチームで働くということを経験していただくことができたかと思います。 猪飼さんの持ち前の高いコミュニケーション能力と課題解決能力でこれからもご活躍されることを心より信じています。 次回インターンシップのお知らせ ドコモグループでは2024夏インターンシップを開催します。 猪飼さんが参加された現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 詳細については今後順次公開される予定です 4 。 興味を持たれた方はぜひご応募ください。 (5/23追記) サマーインターンシップ2024 の情報が公開され、 現場受け入れ型インターンシップ の受け入れポスト情報も公開されました。 本記事に関連するポストは「 D2.脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト 」（PDFファイル、4ページに記載）です。 参考文献 フィッシング対策協議会 : フィッシング対策ガイドライン 2023年度版 「脅威調査」「脅威分析1」「脅威探索」については、「 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 」で紹介されています ↩ 「脅威検証」については、「 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） 」で紹介されています ↩ 月次報告書 | 2024/01 フィッシング報告状況 ↩ 予め マイページ に登録していただければ、インターンシップ募集開始時にメールでお知らせが届きます ↩

はじめに こんにちは、ドコモグループのウインターインターンシップ2023に参加した猪飼です。 普段は、大学院でマルウェアの動的解析に関する研究をしています。 「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明するセキュリティアナリスト」のポストに参加させていただきました。 この記事では、私がインターンシップで取り組んだ内容について紹介します。 NA4Secプロジェクトについて まずは、私がお世話になったNA4Secプロジェクトについて紹介します。 正式には「Network Analytics for Security」というNTTコミュニケーションズ イノベーションセンターのプロジェクトであり、通称NA4Sec（なよせ）と呼ばれています。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」という理念に基づき、攻撃インフラの解明、撲滅の実現を目指して活動しているプロジェクトです。 参加のきっかけ 現場で業務を体験できるインターンシップを調査していた際、過去にドコモグループのインターンシップを体験した方々のブログを発見しました。ブログの内容が非常に興味深く、「このインターンシップはとても面白そうだな」という印象を受けました。 そこから調べていく間に、セキュリティに関する業務を現場で体験できる点に魅力を感じ、「実際に働く雰囲気を体験したい！」と考え応募しました。また、自分が興味を持っている攻撃インフラに関連するポストが存在したことも、応募の決め手でした。 インターンシップ概要 2/5から2/16までの約2週間、プロジェクトメンバーとして業務を体験させていただきました。 業務はオンラインで実施し、 NeWork というオンラインコミュニケーションツールを活用しました。気軽に相談できる環境・雰囲気であったため、非常に働きやすかったです。 インターンシップにて、「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明すること」をテーマに、私は以下のことに取り組みました。 脅威調査 ペネトレーションテストツールであるCobalt Strikeについて調査し、理解する。 脅威分析1 Cobalt Strikeが悪用された攻撃事例を調査し、ダイヤモンドモデルに基づいて分析する。 脅威探索 デバイス検索エンジンであるCensysを使用し、インターネット上に存在するCobalt StrikeのC2サーバを調査する。 脅威検証 攻撃者が、インフラの秘匿に使用するクローキング技術について調査し、サーバに実装する。 脅威分析2 フィッシングについて調査し、フィッシングキットを解析する。 URLスキャンサービスであるurlscan.ioを使用し、フィッシングサイトを調査する。 今回は、「脅威分析2」について紹介したいと思います。 「脅威分析2」以外の内容に関しては、過去にインターンシップに参加された方の記事が公開されているのでそちらをご覧ください 1 　 2 。 脅威分析：フィッシングキットの解析 私は今回、フィッシングキットの解析に取り組み、以下のワークを行いました。 フィッシングについての調査 フィッシングキットについての調査 フィッシングキットの解析 フィッシングサイトの調査 フィッシング詐欺について フィッシング詐欺とは、通販サイトや会員ページのログイン画面を模倣し、利用者にIDやパスワード、カード情報などを入力させ、情報を搾取する犯罪の一種です。 近年では、フィッシング詐欺の件数は年々増加傾向にあります。フィッシング対策協議会によると、2024年1月に報告された件数は、85,827件でした 3 。 フィッシング詐欺の分業化 フィッシング詐欺の件数が増加している背景として、分業化が考えられます。それぞれの工程を担当する業者が分かれることで、フィッシング詐欺の実行が容易になっています。 以下に、各工程と内容の例を挙げます。 工程 内容 計画 対象の調査・決定 調達 必要ツールや情報の取得 構築 フィッシングサイトの構築 誘導 フィッシングメール、SMSなどの送信 詐取 情報を騙し取る 収益化 盗んだ情報を金銭に変換 強化拡大 攻撃の強化・拡大 フィッシングキットについて フィッシングキットとは、フィッシングサイトを容易に構築可能なテンプレートのことです。高度なスキルを必要とせずにフィッシングサイトの構築が可能となります。このようなフィッシングキットは、秘匿性の高いチャットサービスであるTelegramやダークウェブなどのコミュニティ、配布サイトなどで配布されていると考えられます。 フィッシングキットに含まれるソースコードを解析することで、実装されている調査・解析妨害のテクニックや、通信先といった攻撃者についての知見を得ることができます。また、フィッシングサイトを構築しているファイルのハッシュ値に着目することで、同じフィッシングキットから作成された他のサイトについても調査可能です。 フィッシングキットに含まれるファイルの解析 実際に、フィッシングキットに含まれるファイルの解析に取り組みました。今回対象としたフィッシングキットには3つのファイルが含まれており、各ファイルのソースコードから処理内容を解析しました。 その中で、一部のファイルには、解析を困難にする目的で「難読化」と呼ばれる処置が施されていました。難読化の解除にも取り組みましたが時間が足りず、プロジェクトの方から解除後のソースコードを提供していただき解析を続行しました。自力で難読化を解除できず悔しかったです... 解析から、各ファイルの処理内容、及びフィッシングサイトの挙動は以下の通りだとわかりました。 ファイル 内容 ファイル1 フィッシングサイトを生成し、入力された情報を攻撃者サーバ内のファイル2に送信するphpファイル ファイル2 受け取った入力情報を攻撃者のTelegramやメールに送信するphpファイル ファイル3 メール送信に関する処理が記述されたjsファイル ファイル1が生成したフィッシングサイトに、被害者が情報を入力して送信ボタンをクリックすると、攻撃者サーバに入力した情報が送信されます。この情報をファイル2が受信し、さらに攻撃者のTelegramとメールに送信します。この際、メール送信処理を担当するファイル3も使用されます。 フィッシングサイトの調査 次に、 urlscan.io というサービスを用い、同じフィッシングキットから作成されているフィッシングサイトを調査しました。 urlscan.ioでは、調査対象ページに代理でアクセスし、スクリーンショットや、ブラウザが受信したファイルの一覧、その他の詳細情報を閲覧可能です。また、過去に他のユーザによってスキャンされた結果についても検索できます。 今回、調査した手順は以下です。 urlscan.ioにフィッシングサイトのURLを入力し、過去のスキャン結果を検索します フィッシングサイトを構築するHTMLファイルのハッシュ値を取得します 取得したハッシュ値をurlscan.ioに入力し、同一ハッシュ値を持つサイトのスキャン結果を検索します 同じフィッシングキットから作成されたと考えられるサイトのURLが、900件以上表示されました(2024年2月15日時点) 上記の調査結果より、同一のフィッシングキットから延べ900件以上のサイトが作成された可能性があることが分かりました。 このことから、フィッシング詐欺が増加している一因として、フィッシングキットの流通により、フィッシングサイトの複製が容易になったことが考えられます。 学んだこと 本インターンシップに参加して、さまざまなことを学びました。技術的なことはもちろん、チームで業務を進める雰囲気も体験できました。 以下に学びをピックアップして紹介します。 能動的に情報を収集し、攻撃インフラを発見する体験ができた Cobalt StrikeのC2サーバや、フィッシングサイトのURL調査を能動的に実施した C2サーバのIPアドレスや、フィッシングサイトのURLを発見する経験を積めた セキュリティインシデント事例の調査を体験できた ネット上に公開されている、インシデントに関する記事・情報の調査を実施した Cobalt Strikeを用いた攻撃の流れや脆弱性の悪用、C2サーバに関する情報などの知見を吸収できた 現在でも使用されている攻撃手法や技術について触れられた 攻撃者の視点でクローキングを実装することで、アクセス制御に関する理解が進んだ 年々件数が増加しているフィッシング詐欺について、その背景にあるフィッシングキットの解析を体験できた チームで仕事をする雰囲気を体験できた 情報共有が盛んであり、発言し易い環境を作る重要性を学んだ 疑問点があれば積極的に質問することで、自分が担当している作業の目的が明確になった おわりに 約2週間という期間でしたが、あっという間に過ぎ去ってしまいました。楽しい時間は、過ぎるのが早いです。 今回所属させていただいたNA4Secプロジェクトは、質問や情報共有が非常にしやすい雰囲気であり、素朴な疑問・質問にも丁寧に答えていただきました。また、技術的な学びだけでなく、チームで働く際に必要な事を自分なりに考えるきっかけにもなりました。 受け入れてくださったNA4Secプロジェクトの皆さま、ありがとうございました。 特にインターンシップを担当してくださった神田さん、坪井さん、鮫嶋さんには、非常にお世話になりました。 ありがとうございました。 メンターからのコメント 坪井です。猪飼さん、まずは2週間のインターンシップお疲れ様でした。 今回2週間という短い期間かつ3連休も重なったため、実際に手を動かして作業してもらう期間が短い中、スケジュール通りに予定していた範囲の業務を完遂していただけました。今回のインターンシップではNA4Secの全員と対面で会う機会がなかったものの、NeWorkに参加しているチームメンバに対して積極的に質問をして課題解決をされており、技術スキルだけではなく、社会人としてチームで働くということを経験していただくことができたかと思います。 猪飼さんの持ち前の高いコミュニケーション能力と課題解決能力でこれからもご活躍されることを心より信じています。 次回インターンシップのお知らせ ドコモグループでは2024夏インターンシップを開催します。 猪飼さんが参加された現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 詳細については今後順次公開される予定です 4 。 興味を持たれた方はぜひご応募ください。 (5/23追記) サマーインターンシップ2024 の情報が公開され、 現場受け入れ型インターンシップ の受け入れポスト情報も公開されました。 本記事に関連するポストは「 D2.脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト 」（PDFファイル、4ページに記載）です。 参考文献 フィッシング対策協議会 : フィッシング対策ガイドライン 2023年度版 「脅威調査」「脅威分析1」「脅威探索」については、「 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 」で紹介されています ↩ 「脅威検証」については、「 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） 」で紹介されています ↩ 月次報告書 | 2024/01 フィッシング報告状況 ↩ 予め マイページ に登録していただければ、インターンシップ募集開始時にメールでお知らせが届きます ↩

こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか？詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキングについて ドメインパーキングとは、活用していないドメインを所有している場合にそのドメインを Web 上で保持・管理ができるサービスです。パーキングサービス利用者は DNS の設定を変更し、対象ドメインの NS レコードにパーキングサービスの権威サーバを指定することで、そのドメインの名前解決先をパーキングサービスに変更し訪問者をパーキングサービスに向けることができます。またそのドメイン宛にアクセスするとパーキングサービスが用意したページや広告が表示されるため、利用者はドメインを Web 上に保持させるだけでなく表示された広告へのアクセス数に応じた報酬を受け取ることができます。一方でこのようなパーキングサービスを攻撃者が悪用した事例も確認されています。 一般的に攻撃者が配布するマルウェアに感染するとマルウェアは C&C サーバと通信をすることで感染端末から窃取した情報の送信や新たな悪性のファイルの追加ダウンロードなどを実行することがあります。このような活動に対抗するためアナリストによるマルウェアの解析が日々実施されていて、C&C サーバの IP アドレスが判明した場合にはその IP アドレスは危険性があるものとして周知され、さまざまなブラックリストに追加されます。 しかし攻撃者は C&C サーバの宛先ドメインを攻撃活動を実施していない通常時にはパーキングサービスに登録しておき、攻撃実施時のみ名前解決先を実際の C&C サーバの IP アドレスに変更することがあります。このようにすることでマルウェアを解析されたとしても、通常時であれば C&C サーバの IP アドレスとして検出されるのはドメインパーキングの IP アドレスとなり、本物の C&C サーバの IP アドレスが発見されることを困難にできます。このように攻撃者がパーキングサービスを隠れ蓑にする事例が確認されています。 アラートの概要 本記事の冒頭に記述した通り、以前マルウェアに関するアラートを検知したことがありました。この節ではそのアラートの概要について説明しますが、このアラートから確認できた情報は下記の数点のみでした。 接続先の IP アドレス 接続先が何らかのマルウェアの IoC であること 悪性通信が検知された端末の識別番号 上記の検知された IP アドレスを外部インテリジェンスで調査した結果、この IP アドレスがマルウェア Ursnif の IoC に含まれていることを確認できました。そのため、この時点では組織内の端末が Ursnif と関連する接続先と通信したことが疑われる状況となりました。 Ursnif について Ursnif は 2006 年ごろ確認されたバンキング型トロイで、フィッシングメール等を契機に感染し銀行情報を窃取していました。年々機能が拡張されておりバックドアやランサムウェアとしての機能を持つ亜種も確認されています。確認されている亜種として Gozi、ISFB、LDR4 など多くが存在します。（Gozi、ISFB については Ursnif の別名として使用される場合もあります。） これまで複数の国がターゲットにされており日本に対してもフィッシングメールによる Ursnif のばらまきを実行されたことが確認されています。 接続先についての調査 上述の通り Ursnif に関連する悪性の接続先へのアクセスが疑われる状況だったため、接続先についての調査を実施しました。 アラートから接続先の IP アドレスは把握できたため、まずは外部サービス（ AlienVault OTX ）が提供する Passive DNS を確認したところ、多数のドメインがこの IP アドレスを名前解決先にしていることが分かりました。また所属している AS はパーキングサービスの提供者である Sedo でした。 その後、今回のアラートが上がった端末の利用者にヒアリングを実施したところ、アラート発生時刻において過去に参加したプロジェクトで使用していたドメインにブラウザからアクセスをしていたことが確認でき、これがアラートの契機であることが分かりました。確認のため安全な環境からそのドメインの Web サイトを表示させたところ、やはり Sedo のドメインパーキングのページであり、検知された通信先は Sedo が提供するパーキングサービスであることを確認できました。 以下の画像はパーキングサービスに所属するドメインへアクセスした際の一例です。（本記事のアラートの契機となったドメインではありません。） 検知されたアラートの危険性について 過去のプロジェクトで使用したドメインへのアクセスにより Sedo のパーキングサービスが表示されましたが、これはこのドメインの有効期限が切れて廃止された後に第三者がこのドメインを取得し Sedo に登録したことが原因と考えられます。また、今回アラートが上がった接続先は Ursnif の IoC として周知されていましたが実態はパーキングサイトであり、調査した限りにおいては Ursnif の感染チェーンにおいてパーキングサービスが使用された事例は確認できませんでした。 そのことから、今回のアラートが上がった接続先の IP アドレスは本物の Ursnif の C&C サーバではなく、上述した方法で Ursnif の隠れ蓑にされたことでブラックリストに追加されたと考えられます。つまりアラートは誤検知の可能性が高く危険性は低いと思われます。 さいごに 今回は悪性の接続先（Ursnif）として検知された IP アドレスを調査し、それがパーキングサービスであることを確認しました。一方で Ursnif の感染においてパーキングサービスが利用された前例はなく、今回のアラートが誤検知の可能性が高いと判断できました。 本記事の要点は以下の 2 点と考えています。 以下の要因が重なると悪性でないドメインでもマルウェアの IoC に登録される場合がある あるドメインがパーキングサービスに登録される 攻撃者が C&C サーバの IP アドレスを隠蔽するために C&C サーバのドメインをパーキングサービスに登録する C&C サーバのドメインがパーキングサービスに登録されている時にアナリストがマルウェアを解析し、パーキングサービスの IP アドレスをブラックリストに追加する 悪性の IP アドレスへの接続が検知されたとしてもそれがパーキングサービスであった場合には、誤検知の場合もある ただしパーキングサービスであれば必ずしも危険性がないということはもちろんなく、マルウェアファミリーによってはパーキングサービスから配布が実行された事例もあるため、アラートが上がったマルウェアにそのような事例がある場合には EDR でパーキングサービスにアクセスした後のリダイレクト先を確認するなどの注意をする必要があります。また、マルウェア以外にもパーキングサービスへのアクセスを契機にフィッシングサイトやサポート詐欺サイトが表示された事例も確認されているため、この点についても警戒する必要があります。

こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか？詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキングについて ドメインパーキングとは、活用していないドメインを所有している場合にそのドメインを Web 上で保持・管理ができるサービスです。パーキングサービス利用者は DNS の設定を変更し、対象ドメインの NS レコードにパーキングサービスの権威サーバを指定することで、そのドメインの名前解決先をパーキングサービスに変更し訪問者をパーキングサービスに向けることができます。またそのドメイン宛にアクセスするとパーキングサービスが用意したページや広告が表示されるため、利用者はドメインを Web 上に保持させるだけでなく表示された広告へのアクセス数に応じた報酬を受け取ることができます。一方でこのようなパーキングサービスを攻撃者が悪用した事例も確認されています。 一般的に攻撃者が配布するマルウェアに感染するとマルウェアは C&C サーバと通信をすることで感染端末から窃取した情報の送信や新たな悪性のファイルの追加ダウンロードなどを実行することがあります。このような活動に対抗するためアナリストによるマルウェアの解析が日々実施されていて、C&C サーバの IP アドレスが判明した場合にはその IP アドレスは危険性があるものとして周知され、さまざまなブラックリストに追加されます。 しかし攻撃者は C&C サーバの宛先ドメインを攻撃活動を実施していない通常時にはパーキングサービスに登録しておき、攻撃実施時のみ名前解決先を実際の C&C サーバの IP アドレスに変更することがあります。このようにすることでマルウェアを解析されたとしても、通常時であれば C&C サーバの IP アドレスとして検出されるのはドメインパーキングの IP アドレスとなり、本物の C&C サーバの IP アドレスが発見されることを困難にできます。このように攻撃者がパーキングサービスを隠れ蓑にする事例が確認されています。 アラートの概要 本記事の冒頭に記述した通り、以前マルウェアに関するアラートを検知したことがありました。この節ではそのアラートの概要について説明しますが、このアラートから確認できた情報は下記の数点のみでした。 接続先の IP アドレス 接続先が何らかのマルウェアの IoC であること 悪性通信が検知された端末の識別番号 上記の検知された IP アドレスを外部インテリジェンスで調査した結果、この IP アドレスがマルウェア Ursnif の IoC に含まれていることを確認できました。そのため、この時点では組織内の端末が Ursnif と関連する接続先と通信したことが疑われる状況となりました。 Ursnif について Ursnif は 2006 年ごろ確認されたバンキング型トロイで、フィッシングメール等を契機に感染し銀行情報を窃取していました。年々機能が拡張されておりバックドアやランサムウェアとしての機能を持つ亜種も確認されています。確認されている亜種として Gozi、ISFB、LDR4 など多くが存在します。（Gozi、ISFB については Ursnif の別名として使用される場合もあります。） これまで複数の国がターゲットにされており日本に対してもフィッシングメールによる Ursnif のばらまきを実行されたことが確認されています。 接続先についての調査 上述の通り Ursnif に関連する悪性の接続先へのアクセスが疑われる状況だったため、接続先についての調査を実施しました。 アラートから接続先の IP アドレスは把握できたため、まずは外部サービス（ AlienVault OTX ）が提供する Passive DNS を確認したところ、多数のドメインがこの IP アドレスを名前解決先にしていることが分かりました。また所属している AS はパーキングサービスの提供者である Sedo でした。 その後、今回のアラートが上がった端末の利用者にヒアリングを実施したところ、アラート発生時刻において過去に参加したプロジェクトで使用していたドメインにブラウザからアクセスをしていたことが確認でき、これがアラートの契機であることが分かりました。確認のため安全な環境からそのドメインの Web サイトを表示させたところ、やはり Sedo のドメインパーキングのページであり、検知された通信先は Sedo が提供するパーキングサービスであることを確認できました。 以下の画像はパーキングサービスに所属するドメインへアクセスした際の一例です。（本記事のアラートの契機となったドメインではありません。） 検知されたアラートの危険性について 過去のプロジェクトで使用したドメインへのアクセスにより Sedo のパーキングサービスが表示されましたが、これはこのドメインの有効期限が切れて廃止された後に第三者がこのドメインを取得し Sedo に登録したことが原因と考えられます。また、今回アラートが上がった接続先は Ursnif の IoC として周知されていましたが実態はパーキングサイトであり、調査した限りにおいては Ursnif の感染チェーンにおいてパーキングサービスが使用された事例は確認できませんでした。 そのことから、今回のアラートが上がった接続先の IP アドレスは本物の Ursnif の C&C サーバではなく、上述した方法で Ursnif の隠れ蓑にされたことでブラックリストに追加されたと考えられます。つまりアラートは誤検知の可能性が高く危険性は低いと思われます。 さいごに 今回は悪性の接続先（Ursnif）として検知された IP アドレスを調査し、それがパーキングサービスであることを確認しました。一方で Ursnif の感染においてパーキングサービスが利用された前例はなく、今回のアラートが誤検知の可能性が高いと判断できました。 本記事の要点は以下の 2 点と考えています。 以下の要因が重なると悪性でないドメインでもマルウェアの IoC に登録される場合がある あるドメインがパーキングサービスに登録される 攻撃者が C&C サーバの IP アドレスを隠蔽するために C&C サーバのドメインをパーキングサービスに登録する C&C サーバのドメインがパーキングサービスに登録されている時にアナリストがマルウェアを解析し、パーキングサービスの IP アドレスをブラックリストに追加する 悪性の IP アドレスへの接続が検知されたとしてもそれがパーキングサービスであった場合には、誤検知の場合もある ただしパーキングサービスであれば必ずしも危険性がないということはもちろんなく、マルウェアファミリーによってはパーキングサービスから配布が実行された事例もあるため、アラートが上がったマルウェアにそのような事例がある場合には EDR でパーキングサービスにアクセスした後のリダイレクト先を確認するなどの注意をする必要があります。また、マルウェア以外にもパーキングサービスへのアクセスを契機にフィッシングサイトやサポート詐欺サイトが表示された事例も確認されているため、この点についても警戒する必要があります。

この記事では、SDPFクラウド/サーバで提供しているファイアウォールサービスについて、数週間かかっていたコントローラのテストを一新し、開発効率/品質向上に繋がった事例を紹介します。 目次 目次 はじめに ファイアウォール サービスとは テストにおける課題 問題1: テスト時間が長い 問題2: テストツールのEOL テスト環境の一新 問題の調査と整理 外部サービスのmock化 apiごとのテスト実装 CIの導入 テスト環境を一新して さいごに はじめに みなさん、こんにちは。 現在、SDPFクラウド/サーバで提供しているファイアウォール/ロードバランサーのサービス開発業務に携わっています、片貝です。 この記事では、数週間かかっていたファイアウォールサービスのテストを一新し、開発効率/品質向上に繋がった事例を紹介させていただきます。 ファイアウォール サービスとは ファイアウォールサービスでは、IaaS環境の上で利用できる仮想ファイアウォールアプライアンスを提供しています。 お客さまからの申し込み(API call/GUI操作)に合わせて、我々で管理/開発するファイアウォールコントローラが基盤となる仮想サーバー作成、NW接続、ファイアウォールの設定投入といった、サービスの提供に必要な操作を実施し、デプロイまでの自動化を実現しています。 テストにおける課題 ファイアウォールサービスでは、リソースの作成や削除といった基本機能はすでに実装されており、現在はお客さまからのフィードバックに基づいた機能追加や改善が行われています。 このような機能追加の開発やリリースにおいて、コントローラへのソフトウェアテスト時にたびたび問題が生じていました。 問題1: テスト時間が長い 1つの問題は、テストにかかる時間が長いことです。 ファイアウォールサービスの開発では、サービスの正常動作を担保するためのテストに2,3週間もの時間がこれまでかかっていました。 その結果以下のような問題が発生していました。 開発効率低下 たった数行の変更でさえも1時間以上の手動確認が必要になるなど、開発時間の多くをテスト実行が占める非効率的な状態でした。また、それによってスケジュールへの影響が出てしまうこともありました。 品質低下 変更ごとに全てのテストを実施すると、時間がかかりすぎて現実的ではないため、必要なテストに絞って実施するしかない状態となっていました。その結果テスト漏れもしばしばありました。 開発者のモチベーション低下 待ち時間が長く確認作業も煩雑であること、待機後のコンテキストスイッチによるコスト増など、開発者にとってストレスが生じていました。 問題2: テストツールのEOL もう1つの問題は、使用しているテストツールのEoLです。 ファイアウォールサービスの開発では社内で独自開発されたテストツールが使用されていましたが、そのツールがEoLを迎えることでサポートが受けられなくなるという問題が生じました。 さらに、既存のテスト実装者がすでにチームを離れており、テストがオーパーツ化していたことや、新規参入者が独自のテストツールの習熟に時間がかかるという問題も発生していました。 テスト環境の一新 上記の問題を解決するため、これまでのテストについての観点や環境を刷新することを決めました。 改善についての過程や方法を含めてその流れを追っていきます。 問題の調査と整理 まずはじめに行ったのが既存テストの調査です。 開発のどのフェーズに時間が掛かっているか、時間がかかる要因としてどんなものがあるか、アンケートを用いて調査し、チーム内で議論を重ねました。 その結果、現在の開発においては機能の追加や改善よりも、その動作確認におけるテストに多く比重が掛かっていることがチーム全体の総意であることがわかりました。 また、遅くなる要因として多く挙げられたのが既存テストの仕組みです。 現行のテストは、ファイアウォールとの結合を含めて全テストが実環境で実行されていたため、 外部サービス(仮想サーバーやネットワークを管理するIaaSコントローラー)との依存関係がある状態でした。 そのことが原因で以下のような問題が発生していました。 ① 外部サービスの計画メンテナンスや一時的なエラーなど、本来テストしたいファイアウォールウォールコントローラ以外が原因でテストが失敗、中断、やり直しになる。 ②そもそも外部サービスのAPI call(仮想サーバの起動やファイアウォールの設定反映待ち)が長い。 その結果、外部結合に伴う処理がテストの開発時間を引き延ばし、問題1で挙げたさまざまな課題を誘発していました。 外部サービスのmock化 上記の調査を通して、外部サービスに依存したテストが問題だとわかったため、解消する取り組みとして外部サービスのmock化を行いました。 具体的には仮想サーバ、ネットワーク操作、ファイアウォールの設定投入などAPI callをhookし、それら動作を模擬する実装に切り替えました。 ファイアウォールの特定通信の可否を確認するテストなどは、実体がなければ詳細なテストは難しいため、外部サービスとの依存が必要となります。 しかし、既存テストのほとんどは構築ロジック(仮想サーバの作成/削除や、ユーザネットワークと繋ぎこむ部分)のテストであり、 外部サービスの挙動を十分に理解し模擬できれば依存は必要ないものとなっていました。 そのためテストの品質を大きく損なうことなく、mock化を通してテストにおける課題を緩和できるだろうと判断しています。 apiごとのテスト実装 mock化を完了させた後はAPIごとのテスト実装です。 mock化した外部サービスを通してテストが実行できるよう、APIごとに新規でテストを実装しました。 ここでは、既存のテストツールのEOLや習熟コストを考え、ファイアウォールコントローラ開発のメイン言語であるPythonのテストツールpytestへの移行も同時に行っています。 全APIで約1300個のテストを新規で単体テストとして作り直しました。 その結果これまで数週間かかっていたテストが1時間以内で終了するようになりました。 Before After テスト所要時間 2,3週間 1h以内 外部結合 あり なし テストツール 社内独自ツール(EoL済み) pytest CIの導入 新規テスト実装を通した時間短縮の結果、頻繁にテスト内容を確認できるようになり、テストも安定してきたため、CIも導入できるようになりました。 開発者はPRの作成や更新のみを行い、それをトリガーとしてテスト環境の作成や実行、Slack通知までを自動化しました。 チーム内で、この通知をマージのゲートとして利用することで、開発者やレビュワーはテストの確認に負担をかけることなく開発を進めることができるようにもなりました。 テスト環境を一新して テスト時間の短縮によって開発効率はもちろん開発者の体験までもが大幅に向上したと感じています。 さらにCIの導入で、バグの早期検出から修正までが容易になり、リリース時の不安やリスクの軽減、サービスの品質向上へ繋がりました。 全ての項目を合わせると4人で半年という期間がかかっていますが、このテスト環境の一新を土台としてスムーズな開発プロセスが確立され、その時間を費やした価値は十分にあると感じています。 ユーザに直接提供する機能の開発ではないですが、こういった開発環境改善はチーム全体の文化の改善や効率性の向上をもたらすものと感じており、今後も取り組みを継続し、より良いサービスの提供に努めていきたいと思っています。 さいごに 今回、SDPFクラウド/サーバのファイアウォールサービスについて、テストを一新し開発効率/品質向上に繋がった事例について紹介させていただきました。 この記事のようにファイアウォールサービスの開発チームでは、新機能の開発/改善に加え、開発のサイクル向上といった取り組みも行い、ユーザへの利益提供のために日々努力しています。 2024年4月現在、一緒に開発を進めてくれるメンバーを募集していますので、 興味を持ってくださった方、以下のリンクから是非詳細をご覧ください。 https://hrmos.co/pages/nttcom0033/jobs/1928706488764108838 皆さまのご応募お待ちしています！

本記事では Databricks のDatabricks Container Serviceを用いてNVIDIA社の推論ライブラリであるTensorRT-LLMを実行可能なNotebook環境を構築する方法を紹介します。 目次 目次 はじめに Databricks Container Service NVIDIA TensorRT-LLM 解決したいこと TensorRT-LLM Container Imageの作成 Databricks Containers ベースイメージの変更 Pytorch バージョンの変更 TensorRT-LLMのインストール 動作確認 Databricks環境設定 TensorRT-LLMのインポート Llama2 HF-7b-instruct モデルの変換 TensorRT-LLMの呼び出し まとめ 参考文献 はじめに こんにちは、NTTコミュニケーションズの露崎です。 本記事では Databricks のDatabricks Container Serviceを用いてDatabricksのデフォルトRuntimeでサポートされていないNVIDIA社の推論ライブラリ、TensorRT-LLMを実行可能なNotebook環境を構築する方法を紹介します。 Databricks Container Service Databricksはデータウェアハウスとデータレイクの両方の強みを兼ね備えたデータとAIのためのオープンな統合プラットフォーム「データ・インテリジェンス・プラットフォーム」を提供しています。DatabricksではDatabricks Runtimeと呼ばれるプリセットされたSparkの環境が提供されており、通常、ユーザは希望するRuntimeを選択するだけでNotebookの計算環境を構築できます。デフォルトのDatabricks RuntimeにはPythonやRといった実行用の言語環境、及び、機械学習や分析に必要な基本的なライブラリがプリインストールされています。 一方で、プリインストールに含まれていない任意のライブラリについてはNotebookの起動後にaptやpipコマンドを用いて別途インストール必要があります。依存するライブラリが多い場合やインストール中にコンパイルを含むパッケージがある場合、このインストール作業に時間がかかる場合があります。 Databricks Container Service はこうしたライブラリの追加に伴うリソース消費を避け、予め必要な設定を構成した環境を持ち込むための仕組みです。ユーザは事前にビルドしたContainer Imageを任意のレジストリサービス経由でDatabricksの実行環境として利用できます。 NVIDIA TensorRT-LLM TensorRT-LLM はNVIDIA社の提供する大規模言語モデル(以下LLM)向けのライブラリです。 事前に学習されたLLMを最先端のLLM向け最適化を含んだ形でTensorRTエンジンに変換し、GPUを用いた高速な推論を実現します。TensorRT-LLMはTensorRTエンジンを簡単に生成する為のPython APIをユーザーに提供するだけでなく、TensorRTエンジンを実行するPythonおよびC++のランタイム作成の為のコンポーネントやTriton Inference Serverと統合する為のバックエンドも含まれており、GPUベースのLLM推論のデプロイを容易にします。 TensorRT-LLMを利用するためにはSDKとして利用するTensorRT、及び、TensorRT-LLMのパッケージをインストールする必要があります。 解決したいこと TensorRT-LLMは強力なライブラリですがDatabricks Runtimeのデフォルトではサポートされていません。また、2024年4月現在Databricks RuntimeがサポートするCUDAのバージョンは11系であり、12系を利用する最新のTensorRT-LLMを利用できません。 本記事では、DatabricksのNotebook上でTensorRT-LLMを使った推論高速化を実現するためにDatabricks Container Serviceを用いてTensorRT-LLM v0.8.0の実行環境を持ち込む方法を紹介します。 TensorRT-LLM Container Imageの作成 Databricks社は、Databricks Container Serviceで実行可能なコンテナのサンプルをGitHubで 公開 していますので、これをベースにTensorRT-LLMをインストールしたContainer Imageを作成します。 TensorRT-LLMのリポジトリ にもDocker Containerを構築するためのDockerfileが 公開 されていますがベースイメージである nvcr.io/nvidia/pytorch のサイズが大きく、最終的なイメージサイズがDatabricksのContainerをベースにするよりも大きくなってしまうことから今回はDatabricksのContainerイメージをベースにする方法を紹介します。 Databricks Containers 実際の構築の前にベースとなるDatabricks社が公開しているコンテナのサンプルの構成を紹介します。Root directoryにある ubuntu diretoryで公開されているイメージがDatabricks Container Serviceでサポートされており、機能ごとにDockerfileが分かれています。 通常のRuntimeとしては ubuntu/standard が利用可能であり、Scala、Java、Pythonなど、Databricksで通常利用可能な機能がパッケージ化されています。 GPU向けRuntimeのDockerfileは ubuntu/gpu にあり、対応するcudaのバージョン毎にdirectoryが分かれています。各cuda directoryはさらに対応する機能毎に base 、 venv 、 pytorch 、 tensorflow に分かれています。Notebookに必要な最低限の機能は venv で構成されており、これを継承した pytorch 、 tensorflow についてはユーザが予めインストールしておきたいフレームワークに応じて選択できます。 この後解説するTensorRT-LLM向けのイメージについては こちら に動くものがありますが、実際の変更点については以降で解説していきます。 ベースイメージの変更 現在公開されているDatabricksのイメージ はCUDA 11.8のためTensorRT-LLM用に ベースイメージ を変更します。また、TensorRT-LLMでは cudnn-runtime でなく devel を使いますのでベースイメージを nvidia/cuda:12.1.0-devel-ubuntu22.04 とします。 Pytorch バージョンの変更 ベースイメージの変更でCUDAのバージョンを上げたので Pytorch についてもバージョンを上げます。今回、紹介するTensorRT-LLMのバージョン (v0.8.0) では Pytorchのバージョンを2.2.0a以下の 制約 があるため、利用できる範囲の最新バージョンである2.1.2を利用します。またベースイメージで設定したCUDA 12.1向けのPytorchを利用するため、Dockerfile内で torch==2.1.2 torchvision==1.6.2 --index-url https://download.pytorch.org/whl/cu121 のように --index-url にPytorchのリポジトリを設定します。 1 TensorRT-LLMのインストール ここまで設定するとCUDA 12.1、PyTorch 2.1.2に対応したDatabricks Container(便宜的に databricksruntime/gpu-pytorch:cuda12.1 とします)がビルドできます。次にこのContainer Imageに以下のDockerfileでTensorRT-LLMのパッケージを追加します。 FROM databricksruntime/gpu-pytorch:cuda12.1 RUN apt-get update && \ apt-get -y install openmpi-bin libopenmpi-dev && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* # install the tenserrt llm version RUN /databricks/python3/bin/pip install \ tensorrt_llm==0.8.0 --extra-index-url https://pypi.nvidia.com \ && /databricks/python3/bin/pip cache purge これでDatabricks上で実行できるContainerのDockerfileができました。ビルドするとおおよそ以下のサイズのイメージが作成されます。 REPOSITORY TAG IMAGE ID CREATED SIZE databricksruntime/gpu-trt-llm cuda12.1 348ca75258f6 3 hours ago 18.6GB 後はこれを持ち込みたい環境からアクセスできるレジストリ (Docker Hub, Google Container Registry, Azure Container Registry, Amazon Elastic Container Registryなど)にpushしましょう。 動作確認 Databricks環境設定 Databricks Container Serviceのドキュメント に従い、クラスタを起動します。今回は以下の設定で動作確認しています。 Databricks Runtimeバージョン: 15.0 (Apache Spark 3.5.0, Scala 2.12) ノードタイプ: Standard_NC24ads_A100_v4 (Azure) 高度なオプション Spark構成 spark.master local[*, 4] spark.databricks.cluster.profile singleNode spark.databricks.unityCatalog.volumes.enabled true Docker イメージURL: PrivateのAzure Container Registry 認証：ユーザ名とパスワード ユーザ名、パスワード：(省略) TensorRT-LLMのインポート 以下のセルを実行しTensorRT-LLM 0.8.0が正しく組み込めていることが確認できました。 Llama2 HF-7b-instruct モデルの変換 公式のdocs を参考に huggingface で提供されているMeta社の Llama2 を変換します。checkpointのconvert及び、エンジン化の変換手順は 公式のdocs に記載があるのでここでは省略します。 手順によって生成された config.json と rank0.engine (GPUの枚数や環境次第でengineファイルの名前は変更されます)を次のTensorRT-LLMの呼び出しで利用します。 TensorRT-LLMの呼び出し 以下は、TensorRT-LLMで生成したエンジンを呼び出して推論するためのサンプルです。 環境変数である BASE_DIR には変換したエンジンが保存されているディレクトリを設定します。Databricksの環境の場合、通常の ワークスペースファイルには200MBの制限(Azureの場合) がありますのでLLMを扱う場合にはUnity Catalog上のボリュームを利用するのが良いでしょう。 from pathlib import Path import os import torch from transformers import LlamaTokenizer import tensorrt_llm from tensorrt_llm.runtime import ModelRunner EOS_TOKEN = 2 PAD_TOKEN = 2 def generate (input_text): tensorrt_llm.logger.set_level( "info" ) tokenizer_dir = "meta-llama/Llama-2-7b-chat-hf" engine_dir = Path(os.environ[ 'BASE_DIR' ]) runtime_rank = tensorrt_llm.mpi_rank() torch.cuda.set_device( 0 ) tokenizer = LlamaTokenizer.from_pretrained(tokenizer_dir, legacy= False ) runner = ModelRunner.from_dir(engine_dir=engine_dir, rank=runtime_rank) input_tokens = [tokenizer.encode(input_text, add_special_tokens= False )] input_ids = torch.nested.to_padded_tensor( torch.nested.nested_tensor(input_tokens, dtype=torch.int32), EOS_TOKEN).cuda() output_gen_ids = runner.generate( input_ids, pad_id=PAD_TOKEN, end_id=EOS_TOKEN, max_new_tokens= 100 , streaming= False ) torch.cuda.synchronize() output_text = tokenizer.decode(output_gen_ids[ 0 ][ 0 ]) return output_text text = generate( "hello, could you tell a story for the galaxy?" ) print (text) このコードを実行すると以下のような出力が得られます。この出力から「銀河の物語について語ってほしい」という英語のプロンプトに対して、LLMの回答結果を得られていることがわかります。これによりTensorRT-LLMで変換されたエンジンを用いて推論できていることが確認できました。 まとめ 本記事ではDatabricks Container Serviceの機能を利用してNVIDIA社の推論ライブラリであるTensorRT-LLMをDatabricks Notebookで利用する方法を紹介しました。こうした仕組みを使うことでモデルの開発や検証を効率よく行うことができると思います。 参考文献 https://www.databricks.com/ https://github.com/NVIDIA/TensorRT-LLM https://github.com/databricks/containers https://catalog.ngc.nvidia.com/containers https://pytorch.org/get-started/previous-versions/ ↩

はじめに こんにちは、イノベーションセンターの鍔木（GitHub: takuma0121 ）です。 OT/ICSセキュリティリスク可視化サービス、 OsecT の開発・運用を担当しています。 2024年3月4日から7日までの間、米国マイアミで開催されたS4x24に聴講参加しました。 このカンファレンスは日本では知名度が高いとは言えませんので、S4の全容とOT/ICSセキュリティのトレンドについてお伝えできればと思います。 目次 はじめに 目次 S4とは プレゼンテーション Vulnerability Management Pavilion Welcome Party / Cabana Sessions Swag Bag 最新のOT/ICSセキュリティトレンド Keynote CFP経由での発表 スポンサーセッション ネットワーキング 会場の雰囲気 エピソード 所感 イベント全体 最新動向/発表 さいごに S4とは S4 （SCADA Security Scientific Symposium）は、 2008年から開催 されるOT/ICSセキュリティに特化したカンファレンスです。 発表だけでなく、パートナー企業探しやネットワーキングも重視されたイベントです。 S4x24には公式発表によれば、約1000人の参加者がいました。 日本からはNTTコミュニケーションズを含めて数社参加していました。 プレゼンテーション 4日間にわたり、Keynote・CFP経由での発表・スポンサーセッションが行われます。 Keynoteの時間帯だけは1つのセッションだけで、それ以外の時間帯は3パラでのセッション形式でした。 Vulnerability Management Pavilion 一部のスポンサーは、会期中デモ展示を行います。 各企業はパートナーやエンドユーザーを探すことを明確な目的としており、デモ展示を見たい旨を伝えると、デモを見る目的を聞かれることがありました。 また、NTTグループをパートナー候補と見なす企業もあり、すぐに商談に進む兆しもありました。 Welcome Party / Cabana Sessions ネットワーキングを目的としたセッションも準備されています。 特にCabana Sessionsでは、スポンサーブースも併設されており、カンファレンス最大のネットワーキングパーティとなっています。 今年の会場の様子がすでに YouTube にアップロードされています。 Swag Bag 2022年から”Swag Bag”と呼ばれる参加記念品が配布されるようになりました 。ちなみに、この帽子にはCabana Sessionsの際に無料で刺繍を入れてくれるサービスもありました。 最新のOT/ICSセキュリティトレンド 発表は主に、Keynote・CFP経由での発表・スポンサーセッション（S4 Prime Sponsors）の3種類に分類されます。 S4x24のAgendaは こちら から参照できます。 それぞれについて抜粋して紹介します。 Keynote 最初のセッション「Believe」では主催者であるDale PetersonがOT/ICSセキュリティの未来について発表していました。 OT/ICSセキュリティと言えば「脅威検知」が挙げられます。 しかし、そもそも検知より前のタイミングで対処したほうが低コストで済むという話が出ていました。 また、調査機関のデータからOT/ICSセキュリティの重要性の高まりなどの話が出ていました。 また別のKeynote「Fireside Chat With Robert M. Lee」では、Robert M. Lee（Dragos CEO）とDaleとの対談が行われ、マルウェア：PIPEDREAMを題材にエネルギー産業への攻撃が増えていることや、脅威検知の必要性やコストについての議論がありました。 CFP経由での発表 AI・自動化、従来はOT/ICSセキュリティでは利用されなかったフレームワークの適用、実用的な運用方法の提案、事例紹介が多かった印象を受けました。 「AI In Production, Today!」では、AIによってできること（リスクアセスメント・ネットワーク図分析・脆弱性アセスメント・IR (Incident Response)準備）、それらを実現するための具体的な手順とOSSがわかりやすく説明されていました。 今回の発表の中では、最も実用的な内容で、すぐにでも試すことができると思います。 「Applying FAIR To OT」では、FAIR (Factor Analysis of Information Risk)をOTに適用し、リスクを定量評価する取り組みが紹介されました。 脅威→攻撃手法→資産→影響の順に事象を洗い出して定量化（= 影響による損失額等）して、モンテカルロシミュレーションによって損失額等の平均や中央値を算出していました。 セキュリティ対策に投資すべき金額がわかるようになる点がよいと感じました。 「The Attack Against Danish Critical Infrastructure」では、デンマークのエネルギー業界を攻撃された事例の紹介がされており、2023/04/25~05/12の間で、準備から攻撃されるまでの状況を事細かに発表していました。 スポンサーセッション 「Dragos: Hacktivist Threat Briefing」では、イランのハクティビストグループ（反イスラエルグループ）が UNITRONICS製デバイス を攻撃（米国およびヨーロッパ）したことを踏まえて、どのように攻撃の影響を軽減するのかについて紹介していました。 攻撃事例を踏まえて、その対策と対策を実現するための体制・サービスを提供している、というスポンサーセッションらしい発表だと感じました。 ネットワーキング 会場の雰囲気 Welcome PartyやCabana Sessionsでは、主催者であるDale Petersonを始め、参加者が積極的にネットワーキングを行っていました。 話したい相手を事前に決めてアプローチしても気軽に応じてくれ、会話が自然に始まるフレンドリーな雰囲気がありました。 エピソード 私はDaleとスポンサー企業の選定方法や、S4を再び日本で開催できないか等についてコミュニケーションを取りました。 日本からの参加者だけでなく、発表者やその他の参加者ともOTセキュリティの重要性について議論、開発・運用しているOsecTに対するフィードバックをもらうことができました。 また多くの参加者と連絡先の交換ができ、今後もOTセキュリティについての議論や情報交換ができるようになり、ネットワーキングの観点でも有意義でした（一人での参加でしたが、連日参加者と昼食・夕食をともにできました）。 所感 今回初めてS4x24に参加してみて、イベント全体と最新動向、発表について感じたことをまとめます。 イベント全体 4日間の開催で発表は実質2日弱くらいで、発表だけでなくネットワーキングも同様に重要な存在だと感じました。 1人で全ての発表を聴講するのは量的に難しく、また参加費を考えると現地でしかできないネットワーキング等も目的に加えると良いと思われます。 最新動向/発表 発表内容はAIによるセキュリティスキャン・自動運用、新しいフレームワークの適用、EoL対応するための実用的な運用方法、定量的なリスク評価、事例紹介など多様な観点から総合的にバランスを取った形となっていました。 さいごに 今回はS4x24の概要、OT/ICSセキュリティのトレンド、ネットワーキング、そしてこれらを踏まえた所感についてまとめました。 次回の S4x25 （2025年2月10日から13日）は、マイアミビーチではなくタンパで開催予定です。 より大きな会場で開催されるとのことで、今後もOT/ICSセキュリティから目が離せません。 日本ではまだOT/ICSセキュリティの注目度が高まっていませんが、NTTコミュニケーションズでは今後OT/ICSセキュリティを盛り上げて、日本でOT/ICSセキュリティを牽引していきます。 OT/ICSセキュリティ可視化サービス OsecTもよろしくお願いします。

マネージド&セキュリティサービス部サービスプラットフォーム部門の田中です。 2023年度の下期にダブルワークという社内施策で、イノベーションセンター生成AIチームに参加しました。 その取り組みとして、本ブログの記事データを管理している GitHub リポジトリに LLM (大規模言語モデル) の1つである GPT-4 を用いた校正CIを導入してみました。 適切なプロンプトを得るための試行錯誤や、この記事自体を校正させてみた結果をお伝えします。 目次 目次 背景 LLM校正CIの詳細 プロンプトの試行錯誤 この記事の校正結果 おわりに 背景 本ブログ記事のデータ管理やレビューには GitHub を利用しています。 投稿者は記事を執筆した後 PR (Pull Request) を出し、レビュアーが PRコメントで記事の修正を提案し、推敲していきます (なお、GitHubを活用した記事公開プロセスについては、別記事「 開発者ブログをリニューアルしたついでにレビューと記事公開プロセスをいい感じにしたお話 」で紹介していますので、ご興味がありましたらご覧ください) 。 レビュー観点の1つに、日本語の文章表現に誤りがないかといった校正的な観点があります。 この観点では、以前より textlint を用いた文章校正CIが GitHub Actions に実装されており、文末の句点有無などを機械的にチェックしています。 ただ、誤字脱字など textlint だけでは検出できない誤りも一定数あり、今回は LLM を用いることでより抜けのない校正ができるのではと考え、CIに組み込んでみることにしました。 LLM校正CIの詳細 校正CIに使う LLM は、記事全文を1度に入力できる Azure OpenAI の GPT-4 32k を利用することにしました。 システムプロンプトは以下を与え、マークダウン形式の記事全文を入力として与えます。 あなたは日本語文章を校正するアシスタントです。 与えられたマークダウン形式の文章で、誤字や文法誤りのある行を抜き出し、修正した行を出力してください。 その際、確実に修正すべき誤りのみを出力してください。 出力は、5個以下とし、より優先的に修正すべきものを出力してください。 また、以下のようなJSON形式で出力してください。 [ {"error_line": "...", "revised_line": "..."} ] PRを契機に、編集のあった記事に対して校正CIが動き、以下のようにPRコメントの形で校正提案を表示するようにしました。 PRコメントの表示には、 reviewdog を利用しています。 プロンプトの試行錯誤 上述のプロンプトは、複数のプロンプトを試行錯誤した結果得られたものです。 過去記事数件を入力とした結果を比較して、どれにするかを決めていきました。 レビュアーを担当される方の意見に、「指摘数が多くなると確認が大変になるかもしれない」というものがあったため、Recall よりも Precision *1 を重視する方針をとりました。 ここでは、試したものをいくつかご紹介します。 はじめは以下のようなプロンプトを与えてみました。 あなたは日本語文章を校正するアシスタントです。 与えられたマークダウン形式の文章で、誤字や文法誤りのある行を抜き出し、修正した行を出力してください。 その際、確実に修正すべき誤りのみを出力してください。 また、以下のようなJSON形式で出力してください。 [ {"error_line": "...", "revised_line": "..."} ] すると、以下のような非常に多くの出力が返ってきました。 抜けた「を」を追加している1つめなどの良い修正提案もありますが、特に必要性を感じない修正提案や修正できていない出力 ( error_line と revised_line が同じもの) などが含まれており、ノイジーな印象です。 (文字が小さく申し訳ありません、読みづらい場合は拡大してご覧ください。なお、見やすさのために改行を追加したり差分文字に色をつけています) そのため以下の1文を加えて、出力数を制限してみました (これが前章記載の最終的にCIに組み込んだプロンプトです) 。 出力は、5個以下とし、より優先的に修正すべきものを出力してください。 結果は次のようになりました。 指定した通りに出力数は5個までに減りました。 しかし、別に修正しなくてもよさそうな提案が依然残っています。 では、やってほしい文法誤りの修正例や誤字の修正例を与えればうまくいくのではと思い、別記事をもとにデータを用意して One-shot Prompting *2 を試してみました。 結果は以下となりました。 Zero-shot とは異なる有効な修正提案が見られる一方で、修正できていない出力が増えてしまっており、トータルではあまり改善がみられないといった印象です。 他記事でも出力を確認したのですが、同様の印象でした。 また、One-shot の分だけ入力が大きくなり LLM の出力にかかる時間が大幅に増えたため、Zero-shot でよさそうです。 また、もしかすると修正の分類も同時にさせることで精度が高まるかもしれないと考え、以下のプロンプトも試してみました。 あなたは日本語文章を校正するアシスタントです。 与えられたマークダウン形式の文章で、以下の誤りのある行を抜き出し、修正した行と誤りの分類を出力してください。 * 誤字 * 漢字変換誤り * 文法誤り * 表記誤り その際、確実に修正すべき誤りのみを出力してください。 出力は、5個以下とし、より優先的に修正すべきものを出力してください。 また、以下のようなJSON形式で出力してください。 [ {"error_line": "...", "revised_line": "...", "error_type": "..."} ] 結果は以下となりました。 どうやら誤りの分類もうまくできていないようです。 また、同様 One-shot も試してみましたが、特にあまり変化は見られませんでした。 他にもプロンプトを英文にするなど試してみましたが、大きな変化は見られませんでした。 そのため、比較的シンプルなプロンプト (前章のプロンプト) を CI で使うことにしました。 この記事の校正結果 校正CIを導入後にこの記事を書いているので、もちろんこの記事にもCIは実行されます。 ここでは、その結果をお見せしたいと思います。 うまくいくといいなと思いながら、今回はわざとすこし誤字を放置して PR を出すと以下のコメントが1つ付きました! 有効な修正提案です! 一方で、実は他に以下の誤字が記事に含まれていたのですが、これらは検出されませんでした。 しかし、別に修正しなくてもよさそうな提案が以前残っています。 また、もしかしると修正の分類も同時にさせることで精度が高まるかもしれないと考え、以下のプロンプトも試してみました。 修正提案は Recall よりも Precision 重視の方針をとっているものの、正直なところ、これらも検出してほしかったなあと思います。 おわりに 本記事ではLLMを用いた校正CIについてお伝えしました。 プロンプトの試行錯誤や、この記事での校正結果をご紹介しました。 校正という１つのタスクに対してさまざまなプロンプトを試してみることは、個人的に初めてのことだったため良い経験になりました。 また、GPT-4 クラスのモデルでも、一見簡単そうに思える日本語長文の文章校正でもまだ完璧でないということを知りました。 今回は環境面の点から、Azure OpenAI の GPT-4 32k を利用しましたが、現在続々と誕生している日本語メインで学習した LLM を用いるとどのような結果が得られるのかが気になります。 機会があれば、これらも今後試していけたらと思います。 校正CIは導入してまだ間もないため、一定期間 CI を試してみて、実際に利用した方の意見を収集し、改善や利用継続を判断する予定です。 *1 : Recall は修正すべきもののうち修正提案できている割合 (どれだけもれなく修正提案できているか) 。Precision は修正提案のうち正しいものの割合 (どれだけ修正提案が正しいか) 。両者はトレードオフの関係にある。 *2 : タスクを指示するプロンプトとともに、お手本となる例を1つ入力に与えること。これに対して、タスク指示のみを与える場合は Zero-shot Prompting という。

はじめに はじめまして、今回ドコモグループの現場受け入れ型インターンシップに参加させていただいた上野です。大学院ではコンテナセキュリティなどについて研究しています。 この記事では、インターンシップ体験記として以下の内容を紹介します。 私のインターンシップの参加経緯や取り組み NTTコミュニケーションズの業務やインターンシップについて知りたい就活生向け Process InjectionとPool Partyの概要 Pool Partyについて日本語で概要を知りたいセキュリティエンジニア向け 目次 はじめに 目次 RedTeam プロジェクト（RedTeam PJ） インターンシップ参加の経緯 インターンシップ概要 T1055 - Process Injection Pool Party Thread Pool Pool Party Variants Variant 1: Worker Factory Start Routine Overwrite おわりに 参考文献 RedTeam プロジェクト（RedTeam PJ） 私が配属されたポストは、NTTコミュニケーションズ イノベーションセンターのRedTeam PJです。RedTeam PJ は攻撃者の目線からセキュリティについて研究開発をしているチームで、ドコモグループやNTTグループに対するRedTeamの案件支援や攻撃手法の研究開発を行なっています。 RedTeam PJの活動については以下の記事や資料でも紹介しています。 MITRE ATT&CK Contribution - T1562.009 Safe Mode Boot インターンシップ生があるSaaSを用いた未知のC2脅威を実証してみた The Dark Playground of CICD: Attack Delivery by GitHub Actions インターンシップ参加の経緯 私はサイバーセキュリティに興味があり、これまでにセキュリティ関連のインターンシップへの参加や、セキュリティに関わる研究を行なってきました。その過程で、攻撃者目線でセキュリティを考えるオフェンシブセキュリティに魅力を感じ、将来はRedTeam関連の職業に就きたいと考えるようになりました。そのような中で、RedTeamの業務体験ができるこのインターンシップを発見し、応募することにしました。 私が今回応募したポストであれば、オフェンシブセキュリティの研究に近い業務も行えそうだなと思ったこともきっかけの１つです。脆弱性診断をするセキュリティ業務のインターンシップなどは多く存在しますが、新しい攻撃手法の開発や攻撃の根本的な原理の調査などを行うものは少ないと感じています。 インターンシップ概要 今回のインターンシップでは、BlackHat Europe2023で発表された Pool Party 1 という攻撃手法の検証業務 を担当しました。最終的にはこの攻撃手法を、NTTコミュニケーションズのRedTeamが内製している独自ツールに組み込むことが検証の目的です。残念ながら今回のインターンシップではツールの組み込みまではできず、PoolPartyの調査結果をRedTeam PJメンバーに共有するところまで体験しました。 インターンシップとしては2024年2月5日〜16日のスケジュールでしたが、オリエンテーションや土日祝日、最終日の成果報告会を除くと、実質的には 7日間 の日程でした。この7日間は以下の3つのテーマをそれぞれ2〜3日ずつ使いながら順番に業務を進めました。 基礎となる攻撃技術の習熟 C2 2 やProcess Injcetion、検証環境や各種ツール（攻撃、開発、解析）に関する座学 CreateRemoteThread InjectionによりC2感染させるPoC検体の開発と動的解析 Process Injection手法の調査・検証 APC 3 を悪用する2つの攻撃テクニックの理解と比較、およびPoC検体の開発と動的解析 APC Queue Code Injection 4 Early Bird Injection 5 Pool Partyの調査・検証 発表者のブログ 6 を読み解きPool Partyの原理を理解 （少しだけ）GitHub 7 で公開されているPool PartyのPoCコードの動作検証とコードリーディング 本記事では、インターンシップで私が調査をしたProcess InjectionとPool Partyの概要について紹介します。 T1055 - Process Injection Process Injection 8 とは、任意のコードを別プロセスのアドレス空間で実行する方法です。攻撃者は、セキュリティ製品の検知回避や権限昇格を目的として、悪意のあるプロセスから正規のプロセスに対してProcess Injectionを行うことがあります。 基本的にProcess Injectionは次の4つのステップから成り立ちます。 Step 1 : プロセスハンドルの取得 Step 2 : メモリの割り当て Step 3 : メモリへの書き込み Step 4 : スレッドの実行 Process Injection（参考文献1から引用） EDRのようなプロセスの振る舞いを監視するセキュリティ製品は、同一プロセス上で実行される「メモリ割り当て/メモリへの書き込み/スレッド実行」の相関を監視しProcess Injectionを検知します。そのため、上記のステップを単純に実行するだけでは、攻撃が検知されます。これに対してセキュリティ研究者や攻撃者は、検知されずに攻撃可能なさまざまなProcess Injectionのテクニックを開発しています。今回のインターンシップで検証をしたPool PartyやAPC Queue Code Injection, Early Bird Injectionもそれぞれそのテクニックの1つです。 Pool Party Pool Partyは2023年12月に発表されたProcess Injectionの手法で、WindowsのThread Poolという仕組みを悪用する手法です。Pool Partyは「メモリの割り当て」と「メモリへの書き込み」のみでProcess Injectionを実現します。「スレッドの実行」を攻撃者が行わずに、Windowsの一般的な並列処理の仕組みによってスレッド実行を引き起こすことで検知回避をしています。 Thread Pool Thread Pool 9 とは、プロセスを非同期処理や並列処理を効率的に実行するためのWindowsの機構です。Worker Threadというタスクの実行単位の集まり、およびそれらを管理して並列に処理する仕組みをThread Poolと呼びます。発表者によると、デフォルトでWindowsプロセスはThread Poolを持つため、PoolPartyはすべてのプロセスに対して適用可能であるとのことです。 Thread Pool（参考文献1から引用） また、Thread PoolにはWorker Factoryと呼ばれるWorker Threadを管理するオブジェクトが存在します。Worker Factoryは、Thread PoolのWorker Threadを監視し、監視結果に基づいてWorker Threadを作成・削除します。 Worker Factory（参考文献1から引用） Pool Party Variants Pool PartyにはVariantと呼ばれる8つの手法が存在し、これらのVariantsを総称してPool Partyという名前が付けられています。 Work Factory Start Routine Overwrite TP_WORK Insertion TP_WAIT Insertion TP_IO Insertion TP_ALPC Insertion TP_JOB Insertion TP_DIRECT Insertion TP_TIMER Insertion Variant 1はThread PoolにおけるWorker Factory、Variant 2~8はThread Poolにおける3つのキュー（Task Queue, Timer Queue, I/O CompletionQueue）およびキューに挿入されるワークアイテムを使用する攻撃です。本記事ではVariant 1に限定して紹介をします。 Variant 1: Worker Factory Start Routine Overwrite Variant 1はWorker Factoryを悪用する手法です。StartRoutineと呼ばれるWorker Threadのエントリーポイントをシェルコードに書き換えることによって、Worker Threadが作成されるタイミングなどで任意のコードを実行させることができます。 以下に攻撃の流れを記載します。 ターゲットプロセスのプロセスハンドルを取得する NtQueryInformationProcess を使用して、ターゲットプロセス内のオブジェクトハンドルを取得する ターゲットプロセス内のオブジェクトハンドルからWorker Factoryのハンドルを探索する DupilicateHandle を使用して、Worker Factoryのハンドルを複製する NtQueryInformationWorkerFactory を使用して、Worker Factoryの情報を取得する Worker Factoryの情報からStartRoutineのアドレスを取得する WriteProcessMemory を使用して、StartRoutineをシェルコードで上書きする NtSetInformationWorkerFactory を使用して、任意のタイミングで攻撃をトリガーさせることも可能です。WorkerFactoryThreadMinimum（最小限実行されるべきThreadの数）を「現在動いているThreadの数+1」に変更すると新たなWorker Threadが作成され、StartRoutineの実行、つまりシェルコードが実行されます。 Worker Factory Start Routine Overwrite（参考文献1から引用） おわりに 私は普段ほとんどUbuntuしか使わず、Windowsの操作もままならない状態からのスタートでした。トレーナーの久保さんに丁寧に検証ツールの使い方などを教えてもらいながら、一歩一歩Process Injection について理解していき、最終的にはチーム内でPool Partyについて発表するというところまで達成できました。知識ゼロの状態からのスタートだったので、インテンシブで大変ではあったのですが、その分成長も感じられた2週間でした。 このようなインターンシップの機会を作っていただいたRedTeam PJの皆さま、ありがとうございました。特にトレーナーの久保さんには NeWork やSlack等で親身になってサポートしていただき、とてもお世話になりました。 参考文献 https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/ BlackHat Europe 2023 - The Pool Party You Will Never Forget: New Process Injection Techniques Using Windows Thread Pools ↩ C2: Command and Controlの略、C&Cと略すことも多い。 ↩ 非同期プロシージャ呼び出し（APC） ↩ APC Queue Code Injection ↩ Early Bird APC Queue Code Injection ↩ SafeBreach - The Pool Party You Will Never Forget: New Process Injection Techniques Using Windows Thread Pools ↩ GitHub - SafeBreach-Labs/PoolParty ↩ MITRE ATT&CK - Process Injection ↩ スレッドプール ↩

こんにちは、インターン生の 横尾 です。 2024年2月に2週間実施されたNTTコミュニケーションズの現場受け入れ型インターンシップに参加させていただきました。普段は、大学院でユーザサイトにおけるIPv6マルチホーミングなどの研究に取り組んでいます。 今回のインターンシップでは、「次世代キャリアネットワークの開発エンジニア」というテーマで、OSSのソフトウェアルータであるFRRouting（以降、FRR）に、SRv6とMPLS/SR-MPLSの相互接続を実現するための機能を実装しました。この記事では、このテーマで取り組んだ内容について具体的に紹介します。 目次 目次 インターンシップに参加した経緯 インターンシップで取り組んだこと L3VPN Inter-AS Option-B w/MPLS の動作確認 SRv6とMPLS/SR-MPLSの相互接続を実現するために必要な機能の確認 実装 動作検証 感想 トレーナーからのコメント インターンシップに参加した経緯 私は以前からSegment Routing(SR)という技術に興味を持っていましたが、Linuxでデータプレーンを少し触った程度で、次のステップにハードルを感じていました。 私が今回インターンシップで参加させていただいたチームでは、Segment Routingに関する取り組みを外部カンファレンス等で発表しており、しばしば目にする機会があったため、より詳細な業務内容を知りたいと思いました。 そして、過去にこのインターンシップへ参加された方々の 参加Blog を拝見し、「ネットワーク × ソフトウェア開発」という内容に興味を惹かれ応募を決めました。 このインターンシップを通して、Segment Routingやネットワークに関するソフトウェア開発の知見を得たいと思いました。 インターンシップで取り組んだこと 今回のインターンシップでは、SRv6とMPLS/SR-MPLSの相互接続について説明されている SRv6 and MPLS interworking（draft-agrawal-spring-srv6-mpls-interworking-14） を参考に、FRRへのSRv6とMPLS/SR-MPLSの相互接続機能の実装に取り組みました。 現在、NTT コミュニケーションズでは、ドコモグループの持つSR-MPLSネットワークにおいて、新たな付加価値の提供や運用の効率化を目指し、サービスファンクションチェイニングの利用やモバイルネットワークでの活用が期待されているSRv6ネットワークとの相互接続検証が実施されています。 今後の相互接続検証にあたって、独自の機能拡張が可能かつSRv6/SR-MPLSの相互接続機能を提供するルータが必要になってきます。 そこで今回のインターンシップでは、OSSソフトウェアルータであるFRRにSRv6とSR-MPLSの相互接続機能を実装することを目標としています。 インターンシップの目標達成に向けて、まずは複数のSR-MPLSネットワークを接続するMulti-AS Segment Routingの仕組みと挙動の理解を進めました。 その後、SR-MPLSネットワークとSRv6ネットワークの相互接続に置き換えて、現行実装での挙動と本来期待する挙動の差分を整理し、拡張が可能なソフトウェアルータであるFRRに目的の機能を実装しました。 以下では、私が今回のインターンシップにおいて実施した業務内容を具体的に紹介します。 L3VPN Inter-AS Option-B w/MPLS の動作確認 まずはじめに、現在NTTコミュニケーションズのTestbedにて運用されているMulti-AS SR-MPLSネットワーク（L3VPN Inter-AS Option-B w/MPLS）について理解を深めます。 そもそも、なぜSingle-ASではなくMulti-ASなのかや、なぜInter-ASの接続方式がOption-Bなのかといった技術選定の背景については以下の外部向け発表資料や連載記事をご参照ください。 マルチASかつマルチベンダにおけるSR-MPLS TEの実現 マルチAS/マルチドメインなSegment Routingの実現 [Multi-AS Segment Routing 検証連載 #0] Multi-AS Segment Routing で VPN を構築する記事を連載します 以下のような開発環境でFRRを設定しながら、経路情報の広告とパケットの流れについて確認します。 この環境は、2つのルータで構成されるAS同士を接続したコア網で、顧客1（Customer-1）を収容しています。各ルータにはFRRをインストールし、AS内はIS-IS、AS間はBGPを用いて経路情報を交換します。VPNのパラメータは以下の通りです。 SR Domain 1 AS 番号: 65001 VRF 100: RD/RT: 65001:100 AS間でのVPNv4経路の広告用RT: 64999:100 SR Domain 2 AS 番号: 65002 VRF 100: RD/RT: 65002:100 AS間でのVPNv4経路の広告用RT: 64999:100 はじめに、PE-MPLS-1が受け取った経路情報を確認します。192.168.2.0/24の経路が受信できています。ここでは省略しますが、PE-MPLS-2では192.168.1.0/24の経路の受信を確認できます。 PE-MPLS-1# show bgp ipv4 vpn neighbors 10.255.1.2 received-routes detail BGP table version is 1, local router ID is 10.255.1.1, vrf id 0 Default local pref 100, local AS 65001 Route Distinguisher: 65002:100 BGP routing table entry for 192.168.2.0/24, version 1 not allocated Paths: (1 available, best #1) Not advertised to any peer 65002 10.255.1.2 (metric 20) from 10.255.1.2 (10.255.1.2) Origin incomplete, localpref 100, valid, internal, best (First path received) Extended Community: RT:64999:100 Remote label: 81 Last update: Sun Mar 24 17:20:14 2024 Total number of prefixes 1 host1からhost2に対してpingによる疎通確認を行います。疎通確認によって、L3VPNが構築できていることが確認できます。 root@host1:/# ping 192.168.2.254 -c 3 PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data. 64 bytes from 192.168.2.254: icmp_seq=1 ttl=60 time=0.428 ms 64 bytes from 192.168.2.254: icmp_seq=2 ttl=60 time=0.071 ms 64 bytes from 192.168.2.254: icmp_seq=3 ttl=60 time=0.073 ms --- 192.168.2.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2052ms rtt min/avg/max/mdev = 0.071/0.190/0.428/0.167 ms このとき、ASBR間のパケットをキャプチャしてみると、MPLS ラベルを用いてパケットが転送されていることが確認できます。 root@ASBR-MPLS-1:~# sudo tcpdump -nni net1 sudo: unable to resolve host ASBR-MPLS-1: Temporary failure in name resolution tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on net1, link-type EN10MB (Ethernet), capture size 262144 bytes 17:24:21.208266 MPLS (label 81, exp 0, [S], ttl 62) IP 192.168.1.254 > 192.168.2.254: ICMP echo request, id 6, seq 1, length 64 17:24:21.208555 MPLS (label 80, exp 0, [S], ttl 62) IP 192.168.2.254 > 192.168.1.254: ICMP echo reply, id 6, seq 1, length 64 17:24:22.236020 MPLS (label 81, exp 0, [S], ttl 62) IP 192.168.1.254 > 192.168.2.254: ICMP echo request, id 6, seq 2, length 64 17:24:22.236079 MPLS (label 80, exp 0, [S], ttl 62) IP 192.168.2.254 > 192.168.1.254: ICMP echo reply, id 6, seq 2, length 64 17:24:23.260009 MPLS (label 81, exp 0, [S], ttl 62) IP 192.168.1.254 > 192.168.2.254: ICMP echo request, id 6, seq 3, length 64 17:24:23.260064 MPLS (label 80, exp 0, [S], ttl 62) IP 192.168.2.254 > 192.168.1.254: ICMP echo reply, id 6, seq 3, length 64 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel 以上を踏まえて、経路情報の広告とパケットの流れについて以下の図にまとめます。 SRv6とMPLS/SR-MPLSの相互接続を実現するために必要な機能の確認 続いて、先ほどの開発環境のうちAS65002をSRv6網に変更し、現状を確認します。 先ほどと同様に、PE-MPLSが受け取った経路情報を確認します。192.168.2.0/24の経路は受け取れているようですが、SRv6で転送する経路だと判断し、SRv6拡張ヘッダでカプセル化するようにカーネルへ設定されてしまっています。PE-MPLSはSR-MPLS網のルータであるため、MPLSヘッダでのカプセル化が期待されます。 PE-MPLS# show bgp ipv4 vpn neighbors 10.255.1.2 received-routes detail BGP table version is 1, local router ID is 10.255.1.1, vrf id 0 Default local pref 100, local AS 65001 Route Distinguisher: 65002:100 BGP routing table entry for 192.168.2.0/24, version 1 not allocated Paths: (1 available, best #1) Not advertised to any peer 65002 10.255.1.2 (metric 20) from 10.255.1.2 (10.255.1.2) Origin incomplete, localpref 100, valid, internal, best (First path received) Extended Community: RT:64999:100 Remote label: 16 Remote SID: fd00:0:0:44:: Last update: Sun Mar 24 19:55:00 2024 Total number of prefixes 1 PE-MPLS# root@PE-MPLS:~# ip route show vrf USER-1 192.168.1.0/24 dev net1 proto kernel scope link src 192.168.1.1 192.168.2.0/24 nhid 12 encap seg6 mode encap segs 1 [ fd00:0:0:44:1:: ] via 10.1.2.2 dev net0 proto bgp metric 20 なぜこのようなことが起きているのかを確かめるため、ASBR-MPLSからPE-MPLSへ送信されるMP-BGPのUPDATEメッセージのパケットをキャプチャしてみると、「Path Attribute - BGP Prefix-SID」が含まれていることがわかります。このAttributeが含まれているため、PE-MPLSはこの経路情報をSRv6で転送する経路だと判断してしまったと考えられます。 続いて、PE-SRv6が受け取った経路情報を確認します。192.168.1.0/24の経路は受け取れているようですが、MPLSで転送する経路だと判断し、MPLSヘッダでカプセル化するようにカーネルへ設定されてしまっています。PE-SRv6はSRv6網のルータであるため、SRv6拡張ヘッダでのカプセル化が期待されます。 PE-SRv6# show bgp ipv4 vpn neighbors fd00::3 received-routes detail BGP table version is 1, local router ID is 10.255.1.4, vrf id 0 Default local pref 100, local AS 65002 Route Distinguisher: 65001:100 BGP routing table entry for 192.168.1.0/24, version 1 not allocated Paths: (1 available, best #1) Not advertised to any peer 65001 0.0.0.0 (metric 20) from fd00::3 (10.255.1.3) Origin incomplete, localpref 100, valid, internal, best (First path received) Extended Community: RT:64999:100 Remote label: 80 Last update: Sun Mar 24 19:25:54 2024 Total number of prefixes 1 PE-SRv6# root@PE-SRv6:~# ip route show vrf USER-1 192.168.1.0/24 nhid 17 encap mpls 80 via inet6 fe80::4819:ccff:fe22:992d dev net0 proto bgp metric 20 192.168.2.0/24 dev net1 proto kernel scope link src 192.168.2.1 以上のことから、この環境では大きく2つの問題点が挙げられます。 問題1: SR-MPLS網にも関わらず、SRv6拡張ヘッダでencapしようとしている(192.168.2.0/24 の経路) 問題2: SRv6網にも関わらず、MPLSヘッダでencapしようとしている(192.168.1.0/24 の経路) 次に、ASBR間のeBGPピアを一度 no activate し、上記の2つの問題が生じない環境下で、データプレーンへ直接経路情報を挿入して最終的な理想の形を確認します。データプレーンへの経路情報の挿入には、iproute2を用いて行います。先ほどと同じように経路情報の広告とパケットの流れについて、iproute2で挿入する経路情報と一緒に以下の図にまとめます。 iproute2を用いてデータプレーンへ経路情報を直接挿入した後、host1からhost2に対してpingによる疎通確認を行います。疎通確認によって、SRv6とMPLS/SR-MPLSの相互接続をした上でL3VPNが構築できていることが確認できました。これで、最終的にデータプレーンにどのような設定が挿入されれば良いのか、イメージを掴むことができました。 root@host1:/# ping 192.168.2.254 -c 3 PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data. 64 bytes from 192.168.2.254: icmp_seq=1 ttl=61 time=0.201 ms 64 bytes from 192.168.2.254: icmp_seq=2 ttl=61 time=0.126 ms 64 bytes from 192.168.2.254: icmp_seq=3 ttl=61 time=0.138 ms --- 192.168.2.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2049ms rtt min/avg/max/mdev = 0.126/0.155/0.201/0.032 ms 実装 続いて、先ほどiproute2で直接データプレーンに設定した内容をコントロールプレーン（BGP）で配布するための実装をします。問題1と問題2を解決するために必要なBGPの処理を考えます。 前提条件として、MPLS網のルータは、SRv6の機能が実装されていないと仮定します。そのため、追加実装はSRv6網のルータ(ASBR-SRv6)を対象とします。 また、各構造体の処理条件は現状の実装に従って紹介します。これらの条件については、拡張性を考慮してもっと検討する必要があるかもしれません。 問題1: ASBR-SRv6で、PE-SRv6から受け取ったVPNv4経路情報をSRv6からMPLSに変換してASBR-MPLSへ配布する このとき、UPDATEメッセージに含まれるBGP Prefix-SID Attributeを削除する 問題2: ASBR-SRv6で、ASBR-MPLSから受け取ったVPNv4経路情報をMPLSからSRv6に変換してPE-SRv6へ配布する このとき、新たにUPDATEメッセージにBGP Prefix-SID Attributeを追加する はじめに、追加機能を設定するためのコマンドを作成します。BGPのピアに対して neighbor <A.B.C.D|X:X::X:X|WORD> seg6-mpls-label-switching が設定されていれば、そのピアに対してSRv6とMPLS/SR-MPLSの相互接続を実施すると判断します。それに伴い、BGPのピアに関するあらゆる情報を持つ struct peer に新たなフラグ PEER_FLAG_SEG6_MPLS_LABEL_SWITCHING を追加します。 次に、ラベルのマッピングを行います。Inter-AS Option-B方式において、隣接ASからラベル付きのL3VPN経路情報を受信し、ローカルラベルで再広告する際に、受信ラベルとローカルラベルのマッピング情報を扱うための構造体があります（ struct bgp_mplsvpn_nh_label_bind_cache ）。 l3vpn-multi-domain-switching が設定されている場合に new_label がセットされ、ラベルのSWAPがカーネルへ設定されます。 /* used to bind a local label to the (label, nexthop) values * from an incoming BGP mplsvpn update */ struct bgp_mplsvpn_nh_label_bind_cache { /* RB-tree entry. */ struct bgp_mplsvpn_nh_label_bind_cache_item entry; /* The nexthop and the vpn label are the key of the list. * Only received BGP MPLSVPN updates may use that structure. * orig_label is the original label received from the BGP Update. */ struct prefix nexthop; mpls_label_t orig_label; /* resolved interface for the paths */ struct nexthop *nh; /* number of mplsvpn path */ unsigned int path_count; /* back pointer to bgp instance */ struct bgp *bgp_vpn; /* MPLS label allocated value. * When the next-hop is changed because of 'next-hop-self' or * because it is an eBGP peer, the redistributed orig_label value * is unmodified, unless the 'l3vpn-multi-domain-switching' * is enabled: a new_label value is allocated: * - The new_label value is sent in the advertised BGP update, * instead of the label value. * - An MPLS entry is set to swap <new_label> with <orig_label>. */ mpls_label_t new_label; /* list of path_vrfs using it */ LIST_HEAD(mplsvpn_nh_label_bind_path_lists, bgp_path_info) paths; time_t last_update; bool allocation_in_progress; }; 既存の実装では、 受信したMPLSのVPNラベル と 配布するMPLSのVPNラベル のマッピングしかできません。そこで、以下を定義します。 受信したSRv6のVPN SID を 配布するMPLSのVPNラベル にマッピングする関数 受信したMPLSのVPNラベル を 配布するSRv6のVPN SID にマッピングする関数 実際にマッピングを行う関数は void bgp_mplsvpn_nh_label_bind_register_local_label() として定義されています。これを参考に、 MPLSのVPNラベル と SRv6のVPN SID のマッピングを行う関数を定義します。 extern void bgp_mplsvpn_sid_bind_register_local_label ( struct bgp *bgp, struct bgp_dest *dest, struct bgp_path_info *pi, afi_t afi); extern void bgp_mplspvn_nh_label_bind_register_sid ( struct bgp *bgp, struct bgp_dest *dest, struct bgp_path_info *pi, afi_t afi); そして、VPNv4経路情報を受け取りラベル情報をインポートする際に、場合分けを行って適切にマッピングします。今回は、受け取ったUPDATEメッセージにBGP Prefix-SID Attributeが含まれていれば、 受信したSRv6のVPN SID を 配布するMPLSのVPNラベル にマッピング、含まれていないかつ PEER_FLAG_SEG6_MPLS_LABEL_SWITCHING が設定されたピアからの経路情報であれば 受信したMPLSのVPNラベル を 配布するSRv6のVPN SID にマッピングするという単純な条件で処理を行います。 static void bgp_mplsvpn_handle_label_allocation ( struct bgp *bgp, struct bgp_dest *dest, struct bgp_path_info *new_select, struct bgp_path_info *old_select, afi_t afi) { ... } else if (new_select->attr->srv6_l3vpn) { // srv6 -> mpls bgp_mplsvpn_sid_bind_register_local_label ( bgp, dest, new_select, afi); } else if (!new_select->attr->srv6_l3vpn && CHECK_FLAG (new_select->peer->af_flags[afi][SAFI_MPLS_VPN], PEER_FLAG_SEG6_MPLS_LABEL_SWITCHING)) { // mpls -> srv6 bgp_mplspvn_nh_label_bind_register_sid ( bgp, dest, new_select, afi); } else ... } 次に、BGP Prefix-SID Attributeの削除・追加部分を実装します。UPDATEメッセージに付与するAttributeの構築は bgp_size_t bgp_packet_attribute() で行います。この関数では、 struct stream *s へ必要なAttributeのデータを挿入します。以下は、Origin Attributeを構築している箇所です。 /* Origin attribute. */ stream_putc (s, BGP_ATTR_FLAG_TRANS); stream_putc (s, BGP_ATTR_ORIGIN); stream_putc (s, 1 ); stream_putc (s, attr->origin); struct attr *attr には、利用可能なAttributeの構造体がたくさん定義されています。たとえば、BGP Prefix-SID Attributeの情報は、 attr->srv6_l3vpn にあります。このポインタがNULLであれば付与しません。今回は、以下のようにピアがeBGPかつ、 PEER_FLAG_SEG6_MPLS_LABEL_SWITCHING フラグがオンであれば attr->srv6_l3vpn をNULLにすることで削除を実現しています。 /* SRv6 Service Information Attribute. */ if ((afi == AFI_IP || afi == AFI_IP6) && safi == SAFI_MPLS_VPN) { /* draft-spring-srv6-mpls-interworking-service-iw (yokoo) */ if (peer->sort == BGP_PEER_EBGP && CHECK_FLAG (peer->af_flags[afi][safi], PEER_FLAG_SEG6_MPLS_LABEL_SWITCHING) && afi == AFI_IP) { /* not supported ipv6 vpn */ attr->srv6_l3vpn = NULL ; } 一方付与の場合は、ピアがiBGPかつ、SAFI（Subsequent Address Family Indicator）がMPLS VPNであれば、 attr->srv6_l3vpn を構築するようにしています。 attr->srv6_l3vpn の構築は、既存コードを参考に行います。 bgp_size_t bgp_packet_attribute ( struct bgp *bgp, struct peer *peer, struct stream *s, struct attr *attr, struct bpacket_attr_vec_arr *vecarr, struct prefix *p, afi_t afi, safi_t safi, struct peer *from, struct prefix_rd *prd, mpls_label_t *label, uint32_t num_labels, bool addpath_capable, uint32_t addpath_tx_id, struct bgp_path_info *bpi) { ... if (peer->sort == BGP_PEER_IBGP && afi == AFI_IP && safi == SAFI_MPLS_VPN) { /* not supported ipv6 vpn */ zlog_info ( "Create BGP Prefix-SID attribute for SRv6 MPLS interworking" ); /* attr->srv6_l3vpn を構築する */ ... } ... } 動作検証 最後に動作検証を行います。host1からhost2へpingを送信し、その様子を各リンクでパケットキャプチャします。MPLS網ではMPLSヘッダで、SRv6網ではSRv6拡張ヘッダでカプセル化されて転送されているのがわかります。また、Inter-ASはMPLSラベルを用いて転送されていることも確認できます。 root@Customer-1:/# ping 192.168.2.254 -c 3 PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data. 64 bytes from 192.168.2.254: icmp_seq=1 ttl=61 time=0.747 ms 64 bytes from 192.168.2.254: icmp_seq=2 ttl=61 time=0.194 ms 64 bytes from 192.168.2.254: icmp_seq=3 ttl=61 time=0.215 ms 感想 2週間という短い期間で、事前知識の学習から実装まで完走でき、非常に良い経験になりました。FRRoutingに機能を追加するのは初めての試みであり、膨大なソースコードや多様な構造体を理解することは難しかったですが、大きなやりがいを感じることができて非常に楽しかったです。 トレーナーの竹中さんには、全工程を通して手厚くサポートいただき、ネットワーク技術やソフトウェア開発に関するさまざまなことを学ぶことができました。特に実装工程では、多くの相談に乗っていただき、最後の最後までデバッグにお付き合いいただきました。また、ミーティングに参加させていただいたり、データセンターを見学させていただいたりと、貴重な経験を積むことができました。本当にありがとうございました。 私は、前半はリモート、後半は出社という少し特殊な形で参加させていただきましたが、リモートと対面の両方を経験できたのは非常に良かったです。 対面だけでなく、リモートでもコミュニケーションが取りやすい環境を提供していただき、作業をスムーズに進められました。また、懇親会はハイブリットで開催していただき、他のインターン生やチームの社員の方々との交流の場を提供していただき、職場の雰囲気を肌で感じることができました。 本インターンを通して多くの学びや経験を得ることができました。改めまして、本当にありがとうございました。 トレーナーからのコメント トレーナーを担当したイノベーションセンターの竹中です。横尾さん、2週間のインターンシップお疲れ様でした。 今回のインターンではSRv6ネットワークとSR-MPLSネットワークの相互接続という新規機能を、ソフトウェアルータへ実装いただきました。 祝日を含んだ２週間という短い作業期間でこの難易度の高い目標を見事達成したことは本当に嬉しい成果です。 ソフトウェアルータの機能拡張は、プログラミングスキルだけでなく、ルータが対話に用いるルーティングプロトコルに関する深い知識も必要になってきます。そのため前半数日をSegment Routingを用いたネットワークにおけるルーティングプロトコルの挙動学習、残りの作業日をコードリーディング・機能実装の時間としていました。 インターン開始当初は作業可能な期間から想定し、プロトコルの挙動学習は軽い動作確認、コードリーディングは問題点を洗い出したもの・実装する箇所をピンポイントで共有して実装だけに注力してもらう予定でした。 しかし、持ち前の高い技術学習力による想定を大きく超えた進捗だったため、不足している機能の洗い出しから実装方針の検討まで実施してもらう方針へ変更しました。インターンシップ目標を達成した横尾さんの実装力はもちろんのこと、その過程でのプロトコルの挙動学習速度もとても印象に残っています。 実装いただいたSRv6ネットワークとSR-MPLSネットワークの相互接続機能は、今後我々が実施していくSRv6/SR-MPLS相互接続環境における検証の核になる機能です。今後の我々の検証において大いに活用させていただきます。 このインターンシップを通して得られた経験が今後の横尾さんの活動にも役立つことを願っています。 改めて、インターンシップへのご参加とご活躍、ありがとうございました！

みなさんこんにちは、イノベーションセンターの益本 (@masaomi346) です。 Network Analytics for Security (以下、NA4Sec) プロジェクトのメンバーとして、脅威インテリジェンス(潜在的な脅威について収集されたデータを収集・分析したもの)の分析をしています。 最近、広告から偽のセキュリティ警告画面に飛ばされる事例が目立っています。 本記事では、偽のセキュリティ警告画面が表示される仕組みについて、実際に使われているツールを使って紹介していきます。 ぜひ最後まで読んでみてください。 NA4Secについて 「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指した活動をしているプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズ（以下、NFLabs.）からもメンバーが参画し、日夜攻撃インフラを追跡しています。 NA4Secの最近の活動については、以下の記事をご覧ください。 セキュリティカンファレンス「JSAC2024」に参加してきた話（登壇編） 日本を狙ったフィッシングサイトの情報配信はじめました サポート詐欺について サポート詐欺とは、偽のセキュリティ警告画面を表示させて、偽のサポート窓口に電話をかけさせ、サポート料金と称して金銭を騙し取る手口のことをいいます。 近年サポート詐欺による被害が増加しており、政府広報や国民生活センターなど、各所で注意喚起が出ています。 PCやスマホに警告画面が出ても慌てないで！ 🚨サポート詐欺が急増中🚨 パソコンやスマホを使用中、「ウイルスに感染した」という警告画面がでたりしても、実際には感染していないことがほとんど。 表示された偽のサポート窓口に電話をすると、金銭を請求されます💥 https://t.co/axdRjHJFXs https://t.co/JpePWnrzn2 pic.twitter.com/PLlosBy4OF — 政府広報オンライン (@gov_online) 2024年4月7日 【発表情報】 パソコンに突然の #警告画面 ！ 表示されたマイクロソフト社の電話番号は偽物なので絶対に電話しないで！ パソコンを #遠隔操作 されネットバンキングで100万円送金されてしまった被害も。 https://t.co/esArIOGxPO 困った時は、一人で悩まず、まず相談！消費者ホットライン「188」に電話 pic.twitter.com/Ne6mbou3Cr — 国民生活センター (@kokusen_ncac) 2024年3月27日 また、IPAの偽セキュリティ警告対策特集ページにて、偽セキュリティ警告についての情報がまとめられていたり、偽セキュリティ警告画面を体験できるサイトが公開されています。 興味がある方はぜひ読んでみてください。 偽セキュリティ警告（サポート詐欺）対策特集ページ どこから出現するのか インターネット上の広告を中心として、いろんなところから出現します。 検索結果の広告をクリックする Webサイト上の広告をクリックする ブラウザ通知スパムによる偽のセキュリティ通知をクリックする etc. 検索結果の広告をクリックする URLが本物と同じように表示されているが、これは、広告のトラッキングテンプレートを悪用することで、上の画像のように表示されます。 トラッキングテンプレートの悪用については、以下の記事が参考になりますので、興味がある方はぜひ読んでみてください。 PSA: Ongoing Webex malvertising campaign drops BatLoader Webサイト上の広告をクリックする 広告をクリックした後、いくつかのドメインを経由して、偽のセキュリティ警告画面が表示されます。 ブラウザ通知スパムによる偽のセキュリティ通知をクリックする ブラウザ通知の許可を求められ、許可を押すと、偽のセキュリティ警告画面に誘導するための通知が表示されます。 なぜ広告が使われているのか これについては、とても複雑であり、詳細を書くと長くなるので、ざっくり紹介します。 インターネットの世界には、広告で収益を稼いでいる攻撃者がいます。 その中には、アクセスした人の属性によって、どの不正なコンテンツにトラフィックを流すかをルーティングするためのシステムを構築・運用している攻撃者もいます。 流れてきたトラフィックを自分で構築したWebサイトに流して広告収入を得たり、他の攻撃者が構築したWebサイトに流して手数料を得たりしています。 広告で収益を稼いでいる攻撃者は、偽のセキュリティ警告画面にトラフィックを流すことで、広告収入や手数料を手に入れるができます。 サポート詐欺を行っている攻撃者は、トラフィックを流してもらうことで、多くの人を誘導できるという仕組みになっています。 偽のセキュリティ警告画面の仕組み 偽のセキュリティ警告画面がどのように動作しているのか。 実際に使われている偽のセキュリティ警告画面を構築するためのツール(フィッシングキット)を使って、主な部分を紹介していきます。 ※あくまで一例であり、すべての偽のセキュリティ警告画面がこうなっているわけではありません。 今回紹介するツールは、zipファイルとなっており、展開すると、以下のようになっています。 ブラウザの環境に合わせて表示内容を変化させる このツールを実際に動かしてみると、使っている環境によって、偽のセキュリティ警告画面が変化します。 Windows macOS 最初に読み込まれるファイルを見てみると、ブラウザの種類やバージョンを取得して、どのアドレスに飛ばすかを指定しています。 電話番号の表示 警告画面の電話番号がどのように表示されているかというと、電話番号をsessionStorageへ格納している箇所があり、そこから呼び出しています。 攻撃者の電話番号を入力すれば、偽のサポート窓口の電話番号として表示されます。 Windows版での送信元の情報表示 Windows版の偽のセキュリティ警告画面を表示したときに、IPアドレスや場所などの情報が表示されていたが、この部分については、外部サービス(画像ではipwho.is)を使って取得しています。 多言語対応 ブラウザの言語によって、警告画面の言語が変わるようになっています。 まとめ 偽のセキュリティ警告画面は、インターネット上の広告を中心として、いろんなところから出現しています ブラウザの種類や言語など、アクセスした人の情報に合わせて、表示する警告画面や言語を変えています 外部サービスを使って、アクセスした人の情報を取得しています 偽のサポート窓口用の電話番号があれば、簡単に使えるようになっています さいごに 本記事では、偽のセキュリティ警告画面が表示される仕組みについて、使われているツールを使って紹介しました。 怪しい広告から、偽のセキュリティ警告画面に飛ばされる事例が増加しています。 本記事が、偽のセキュリティ警告画面がどのように表示されているかを知るための参考になればと思います。 今回の偽のセキュリティ警告以外にも、フィッシング詐欺で使われているツールなどの分析も行なっています。 興味がある方はぜひご連絡ください。 おまけ NA4Secでは、一緒に働く仲間を募集しています。 また、兄弟プロジェクトにMetemcyberというチームがあり、こちらも、一緒に働く仲間を募集しています。 「脅威インテリジェンス」をキーワードに活躍の場を探している方、プロジェクトの理念に共感していただける方のご応募をお待ちしています。 Threat Intelligence Analyst / 脅威インテリジェンスアナリスト （NA4Sec） Threat Intelligence Engineer / 脅威インテリジェンスエンジニア （Metemcyber）

みなさんこんにちは、イノベーションセンターの益本 (@masaomi346) です。 Network Analytics for Security (以下、NA4Sec) プロジェクトのメンバーとして、脅威インテリジェンス(潜在的な脅威について収集されたデータを収集・分析したもの)の分析をしています。 最近、広告から偽のセキュリティ警告画面に飛ばされる事例が目立っています。 本記事では、偽のセキュリティ警告画面が表示される仕組みについて、実際に使われているツールを使って紹介していきます。 ぜひ最後まで読んでみてください。 NA4Secについて 「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指した活動をしているプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズ（以下、NFLabs.）からもメンバーが参画し、日夜攻撃インフラを追跡しています。 NA4Secの最近の活動については、以下の記事をご覧ください。 セキュリティカンファレンス「JSAC2024」に参加してきた話（登壇編） 日本を狙ったフィッシングサイトの情報配信はじめました サポート詐欺について サポート詐欺とは、偽のセキュリティ警告画面を表示させて、偽のサポート窓口に電話をかけさせ、サポート料金と称して金銭を騙し取る手口のことをいいます。 近年サポート詐欺による被害が増加しており、政府広報や国民生活センターなど、各所で注意喚起が出ています。 PCやスマホに警告画面が出ても慌てないで！ 🚨サポート詐欺が急増中🚨 パソコンやスマホを使用中、「ウイルスに感染した」という警告画面がでたりしても、実際には感染していないことがほとんど。 表示された偽のサポート窓口に電話をすると、金銭を請求されます💥 https://t.co/axdRjHJFXs https://t.co/JpePWnrzn2 pic.twitter.com/PLlosBy4OF — 政府広報オンライン (@gov_online) 2024年4月7日 【発表情報】 パソコンに突然の #警告画面 ！ 表示されたマイクロソフト社の電話番号は偽物なので絶対に電話しないで！ パソコンを #遠隔操作 されネットバンキングで100万円送金されてしまった被害も。 https://t.co/esArIOGxPO 困った時は、一人で悩まず、まず相談！消費者ホットライン「188」に電話 pic.twitter.com/Ne6mbou3Cr — 国民生活センター (@kokusen_ncac) 2024年3月27日 また、IPAの偽セキュリティ警告対策特集ページにて、偽セキュリティ警告についての情報がまとめられていたり、偽セキュリティ警告画面を体験できるサイトが公開されています。 興味がある方はぜひ読んでみてください。 偽セキュリティ警告（サポート詐欺）対策特集ページ どこから出現するのか インターネット上の広告を中心として、いろんなところから出現します。 検索結果の広告をクリックする Webサイト上の広告をクリックする ブラウザ通知スパムによる偽のセキュリティ通知をクリックする etc. 検索結果の広告をクリックする URLが本物と同じように表示されているが、これは、広告のトラッキングテンプレートを悪用することで、上の画像のように表示されます。 トラッキングテンプレートの悪用については、以下の記事が参考になりますので、興味がある方はぜひ読んでみてください。 PSA: Ongoing Webex malvertising campaign drops BatLoader Webサイト上の広告をクリックする 広告をクリックした後、いくつかのドメインを経由して、偽のセキュリティ警告画面が表示されます。 ブラウザ通知スパムによる偽のセキュリティ通知をクリックする ブラウザ通知の許可を求められ、許可を押すと、偽のセキュリティ警告画面に誘導するための通知が表示されます。 なぜ広告が使われているのか これについては、とても複雑であり、詳細を書くと長くなるので、ざっくり紹介します。 インターネットの世界には、広告で収益を稼いでいる攻撃者がいます。 その中には、アクセスした人の属性によって、どの不正なコンテンツにトラフィックを流すかをルーティングするためのシステムを構築・運用している攻撃者もいます。 流れてきたトラフィックを自分で構築したWebサイトに流して広告収入を得たり、他の攻撃者が構築したWebサイトに流して手数料を得たりしています。 広告で収益を稼いでいる攻撃者は、偽のセキュリティ警告画面にトラフィックを流すことで、広告収入や手数料を手に入れるができます。 サポート詐欺を行っている攻撃者は、トラフィックを流してもらうことで、多くの人を誘導できるという仕組みになっています。 偽のセキュリティ警告画面の仕組み 偽のセキュリティ警告画面がどのように動作しているのか。 実際に使われている偽のセキュリティ警告画面を構築するためのツール(フィッシングキット)を使って、主な部分を紹介していきます。 ※あくまで一例であり、すべての偽のセキュリティ警告画面がこうなっているわけではありません。 今回紹介するツールは、zipファイルとなっており、展開すると、以下のようになっています。 ブラウザの環境に合わせて表示内容を変化させる このツールを実際に動かしてみると、使っている環境によって、偽のセキュリティ警告画面が変化します。 Windows macOS 最初に読み込まれるファイルを見てみると、ブラウザの種類やバージョンを取得して、どのアドレスに飛ばすかを指定しています。 電話番号の表示 警告画面の電話番号がどのように表示されているかというと、電話番号をsessionStorageへ格納している箇所があり、そこから呼び出しています。 攻撃者の電話番号を入力すれば、偽のサポート窓口の電話番号として表示されます。 Windows版での送信元の情報表示 Windows版の偽のセキュリティ警告画面を表示したときに、IPアドレスや場所などの情報が表示されていたが、この部分については、外部サービス(画像ではipwho.is)を使って取得しています。 多言語対応 ブラウザの言語によって、警告画面の言語が変わるようになっています。 まとめ 偽のセキュリティ警告画面は、インターネット上の広告を中心として、いろんなところから出現しています ブラウザの種類や言語など、アクセスした人の情報に合わせて、表示する警告画面や言語を変えています 外部サービスを使って、アクセスした人の情報を取得しています 偽のサポート窓口用の電話番号があれば、簡単に使えるようになっています さいごに 本記事では、偽のセキュリティ警告画面が表示される仕組みについて、使われているツールを使って紹介しました。 怪しい広告から、偽のセキュリティ警告画面に飛ばされる事例が増加しています。 本記事が、偽のセキュリティ警告画面がどのように表示されているかを知るための参考になればと思います。 今回の偽のセキュリティ警告以外にも、フィッシング詐欺で使われているツールなどの分析も行なっています。 興味がある方はぜひご連絡ください。 おまけ NA4Secでは、一緒に働く仲間を募集しています。 また、兄弟プロジェクトにMetemcyberというチームがあり、こちらも、一緒に働く仲間を募集しています。 「脅威インテリジェンス」をキーワードに活躍の場を探している方、プロジェクトの理念に共感していただける方のご応募をお待ちしています。 Threat Intelligence Analyst / 脅威インテリジェンスアナリスト （NA4Sec） Threat Intelligence Engineer / 脅威インテリジェンスエンジニア （Metemcyber）

こんにちは、イノベーションセンターの坂本です。 ソフトウェアエンジニアとしてノーコードAI開発ツール Node-AI の開発に取り組んでいます。 先日 2024年3月19日~22日 にかけてフランス パリで開催された KubeCon+CloudNativeCon Europe 2024 を聴講してきました。 本記事はあえて各セッションなどの技術的なお話ではなく、現地の雰囲気に焦点を当てた内容としています。行けなかった人や今後行ってみたい人に向けて、技術部分はRecapや 公式セッション動画 で、現地ならではの部分は本記事で今回のKubeConを補完できることを目指して執筆します。 目次 目次 そもそもKubeConとは？ スケジュール Day1: CNCF Co-Located Events Day2~4: KubeCon Keynote Breakout Solutions Showcase CNCFプロジェクトブース お昼ご飯 / ケータリング 記念品 / ショップ 日本交流会@現地 まとめ そもそもKubeConとは？ 非営利団体 Cloud Native Computing Foundation (CNCF) が主催するイベントで、毎年北米とヨーロッパで1回ずつ開催されます。Kubernetesおよびクラウドネイティブコンピューティング技術についての事例共有やCNCFがホストするプロジェクト(CNCFプロジェクト)のメンテナなどからアップデート紹介など中心に行われます。他にも企業展示や各CNCFプロジェクトのブース、交流会などさまざまな催しがあります。 会場はパリ中心部からバスを利用して片道約45分 今夏にオリンピックを控えているせいかKubeCon会場でさえ手荷物検査がある スケジュール Day1: CNCF Co-Located Events 初日は各CNCFプロジェクトに特化したCo-Located Eventsがあります。 2~4日目のKubeConとは別費用が必要ですが、個人的にはKubeConよりもこちらに参加しに行くと言ってもいいくらい興味深いセッションが多いのでオススメです。 昨年は国内外問わず技術系イベントではOpenTelemetry関連のObservability系セッションがかなり多かったと記憶していますが、やはりそういった注目領域は扱いが違います。 私が主に聴講していたEdge Dayはスクリーン1枚に椅子のみといった部屋で開催されましたが、Observability Dayは倍近くの部屋の広さでスクリーン2枚にテーブル完備と厚遇されていました。 Observability Dayのもよう Day2~4: KubeCon KubeCon自体の中にもさまざまなイベントがありますが、いくつか抜粋して紹介します。 Keynote KubeConでは毎朝Keynoteがいくつかあり、その後個別のセッションが各部屋で行われるといった流れになります。 やはりエンジニア的には Graduated Project Updates が一番盛り上がり、会場の反応でインパクトの大きさを推察できます。 ここまで言っておいてなんですが今回自分はこれを現地で聞けませんでした。 ただ内容を見るに Istio Ambient Modeがbetaリリース間近 という部分が一番盛り上がったのではないでしょうか。 Keynote会場のもよう Breakout 開催期間中は絶え間なく複数の部屋でBreakout(セッション)が行われます。 人気のあるセッションは部屋の定員に達してで入れないこともしばしばありました。 逆に言えば人の入りで注目度を測るといった現地参加ならではの目利きもできます。 例えばKubernetes 1.27以降で使えるInPlacePodVerticalScalingを紹介した こちらのセッション は長蛇の列がついていました。 セッションではMLワークロードやゲームサーバ周りで有用と言及されていましたが、たしかに技術領域としてどちらも使用しているNode-AIに相性のよい技術だと感じたので今後導入していきたいです。 DB Operator比較 ( https://sched.co/1YeO5 )のセッションの入室は空き待ち 会場はとても広いので移動もひと苦労 Solutions Showcase 会場にはSolutions Showcase(企業展示)コーナーもあります。 展示ブースのもよう 欧州で人気のスポーツ F1の強豪チームのスポンサーをやっているせいかOracle社ブースにはレーシングゲームがあったり、GitHub社ブースにはテーブル・フットボールの台があったりと地域色あふれるブースがいくつかありました。 ちなみにDocker社ブースにも同様のレーシングゲームがありましたが、そちらは新サービスのdocker build cloudではF1マシンのように速くイメージをビルドできることを表現した結果だそうな。 レーシングゲームは順番待ちするくらいの盛況っぷり KubeConは一般的なイベントとは一味違い、各社ブースでの配布物がリッチです。 K3sを提供するSUSE社ブースではぬいぐるみやマフラーを配布していました。 Red Hat社のブースでは恒例の書籍配布 兼 サイン会が行われ長蛇の列となっていました。今回は米アマゾン販売価格$47相当の書籍が配布されていたそうです。 今回はぬいぐるみだけゲット その気になれば多くのグッズ集められるのでカバンには余裕を持って来ましょう CNCFプロジェクトブース 学会でのポスター発表のような感じで各CNCFプロジェクトのコーナーもあり、メンテナと直接ディスカッションできます。今回のKubeConでは成熟度レベルに応じてブースを設けられる期間が決まっていたそうです。 お昼ご飯 / ケータリング 会期中は毎日お昼ご飯としてお弁当を提供してくれます。 Day1のCo-Located Eventsではフランス料理のような弁当のレベルを超えたものが出ましたが、Day2以降はKubeCon NA同様フランスパン型のサンドイッチとサラダ、デザートのセットでした。(正直おいしくはない) 会場にはケータリングもあります。今回はパン数種類に各種飲み物がありました。昨年のKubeCon NAではヨーグルトや果物があってかなり豪華だったので少し残念なポイントです。やはりパリは物価が高いのでしょうか。 左: 今回 右: 昨年のKubeCon NA 記念品 / ショップ KubeConでは参加者に記念品としてTシャツが配られます。 写真の黒い方は昨年のKubeCon NAのもので、青い方が今回のものです。 さすがはパリ、何もかもが洒落ています。 名曲 "La Vie en rose (ばら色の人生)" になぞらえて "クラウドネイティブな人生" ショップにはパーカーやTシャツ、リュックなど定番グッズも充実しています。 ショップのもよう 日本交流会@現地 KubeCon期間中には日本交流会が開催されました。 他社の方々と開発事情や技術活用のあれこれについて情報交換でき、とても貴重な時間を過ごすことができました。 企画してくださった方々やスポンサーとして支援してくださった企業の方々にはこの場を借りてお礼申し上げます。 まとめ 本記事では現地ルポと題し、実際に会場に足を運ばないとわからないような部分を中心に紹介しました。 今回はNode-AIのブラッシュアップや関連新サービス開発のための情報収集を目的に予めセッションの目星をつけて行きました。 その他にもふらりと立ち寄ったセッションでヒントを得ることもでき、今回も現地参加ならではの利点を十分に得られたと感じています。本記事が少しでも皆さまのお役に立てば幸いです。

この記事では、社内部署横断で開催したデータ分析開発合宿について紹介します。 自社サービスが持つ課題に対して、社員がデータ分析と課題解決のための施策提案に取り組み、サービス側へのフィードバックと改善へつなげることができました。 目次 目次 はじめに 各サービスでの分析内容と施策提案 NeWork 課題と提供データの簡単な説明 バブル滞在時間と画面共有時間の傾向分析 通話あたりの画面共有率の傾向分析 Node-AI 課題と提供データの簡単な説明 1日でやめてしまったユーザーの傾向分析 SDPF 課題と提供データの簡単な説明 日時当たりの送信元IPアドレスのユニーク数を使った分析 報告を受けての各サービスでの施策状況 終わりに はじめに 皆さんこんにちは、ソリューションサービス部の小関と是松です。 今回はこちらの記事の続編です。 データ分析開発合宿を開催しました～自社サービスのデータ利活用を促進しよう～ 前回の記事では、エンジニアを中心とした社員でチームを作り、データ分析で自社サービスの課題解決に取り組んだ、データ分析開発合宿を紹介しました。 今回の記事では、NTT ComのサービスであるNeWork、Node-AI、Smart Data Platform (SDPF) に向けて実施された分析と施策提案について紹介します。 各サービスでの分析内容と施策提案 NeWork NeWork は、リモートワーク、オフィス、複数の拠点が同じ空間でつながるオンラインワークスペースです。 バーチャルオフィス空間上でチームメンバーとのコミュニケーションがいつでも可能で、誰が誰とやり取りしているのかを把握できます。 1対1の通話はもちろん、「バブル」 という会議室に似たスペースを自由にカスタマイズして、多人数コミュニケーションをとることが可能です。 課題と提供データの簡単な説明 NeWorkが提示した課題は、チャーンレート（解約率）の分析です。 例えば、以下の画像にあるような有料プランから無料プランへ変更したユーザーの傾向や、利用状況の時間変化などから、チャーンシグナル（解約の前触れ）はあるかという分析内容です。 提供データは、Googleアナリティクス4から収集されたイベントデータで、複雑なデータ構造となっています。そのため、まずはデータ構造の把握や欠損値等の前処理から実施する必要がありました。 バブル滞在時間と画面共有時間の傾向分析 NeWorkを担当したチームの分析の一部を紹介します。 こちらのチームでは、バブル滞在時間・通話時間・画面共有時間を分析し、以下の傾向があることを発見しました。 継続しているワークスペースは、バブル滞在時間が長い 継続しているワークスペースは、バブル滞在時間に対して通話時間が短い 継続しているワークスペースは、画面共有が多い この分析結果を受けて、ユーザーの解約防止として以下の施策が提案されました。 もくもく会としての活用を訴求 アプリ版への導線を引く チュートリアル機能の追加 通話あたりの画面共有率の傾向分析 またこちらのチームでは、通話時間の中で画面共有をしていた時間の割合（画面共有率）を分析し、以下の傾向があることを発見しました。 サービスを利用し始めてから10週を過ぎると、有料プランユーザーと解約ユーザーで画面共有率に差がある 有料プランユーザーは10分以内の短時間の通話の中でも画面共有を利用している傾向がある この分析結果を受けて、以下の施策が提案されました。 画面共有率のウォッチ 導入・トライアル初期における画面共有活用のユースケースの事例紹介 Node-AI Node-AI はドラッグアンドドロップでカードを配置しながら繋げていき、ノーコードでAIを開発できるサービスです。 学習に使うデータを設定するデータカードや、データを加工する前処理カード、予測モデルを作成する学習カードなど、さまざまなカードがあります。 課題と提供データの簡単な説明 Node-AIが提示した課題は、長く使うユーザーとすぐにやめるユーザーの傾向や、ユーザーがどこでエラーを踏むかの情報をもとに、優先して改善すべきカードや機能を知りたいという内容です。 Node-AIでは各ユーザーの実行ログを取得しており、どのユーザーがいつ何のカードを実行し成功/失敗したかのデータが合宿参加者へ提供されました。 1日でやめてしまったユーザーの傾向分析 Node-AIを担当したチームの分析の一部を紹介します。 こちらのチームでは、1日で利用をやめたユーザーが最後に実行したカードとカードの実行遷移を分析し、以下の傾向があることを発見しました。 学習に使うデータを設定するデータカードを最後に実行したユーザーが多い（左側の円グラフ） 「dataresource SUCCESS」は、データカード上で目的変数と説明変数を設定し、その設定に成功したログを表している 「dataresource SUCCESS」を繰り返す傾向がある（右側のグラフ） この分析結果を受けて、1日で利用をやめたユーザー像の仮説と離脱防止施策として以下が提案されました。 仮説 ：目的変数や説明変数の設定成功に気付かず繰り返し実行した後、次に何をするのかが分からず離脱したユーザーが一定数いると考えられる 施策 ：データカード上で設定成功のメッセージを強調し、気付かず離脱してしまうユーザーを減らす SDPF SDPF はデータ利活用に必要なさまざまな機能を集約したプラットフォームサービスです。 今回分析の対象となった SDPF クラウド/サーバー はSDPFの機能の一部であり、IaaSメニューとしてネットワーク、データセンター、マネージドサービスを連携したサービスです。WebポータルだけでなくAPIによる操作も対応しています。 課題と提供データの簡単な説明 SDPFが提示した課題は、SDPFへアクセスするIPアドレスのリクエスト情報から、オブザーバビリティを高め、システムやユーザーの状態変化を把握したいという内容です。 SDPFではサービスへアクセスするIPアドレスのリクエスト情報を取得しており、どのIPアドレスがいつどのURIをリクエストしたかのログデータが合宿参加者へ提供されました。 日時当たりの送信元IPアドレスのユニーク数を使った分析 SDPFを担当したチームの分析の一部を紹介します。 こちらのチームでは、1時間ごとの送信元IPアドレスのユニーク数について分析し、以下の傾向があることを発見しました。 受領データの期間内に、ユニーク数が多い時間帯が3つあった(画像1枚目の時系列グラフ) 上記3つの時間帯にアクセスした送信元IPアドレスの中で、直近アクセスが無かったIPアドレスに絞ると、特定のURIに対して複数回リクエストを要求するIPアドレスがあった 分析結果からは、上記の傾向がシステムへどのような影響を及ぼしたかまでは判明しませんでしたが、特徴的な傾向を発見できました。その上で、アクセスの傾向の把握とシステム改善への利活用について以下が提案されました。 分析から分かった送信元IPアドレスの増加原因とシステムへの影響調査 時間ごとの送信元IPアドレスのユニーク数を用いた普段と異なるリクエスト傾向の検知システム開発 報告を受けての各サービスでの施策状況 NeWorkでは、分析結果を元に解約率低減や定着率向上のためチュートリアルを実装し、効果測定のABテストに取り組んでいます。今後計測結果を分析する予定です。また、解約傾向の見直しにも取り組んでいます。 Node-AIでは、分析結果を元にチュートリアルを変更しました。また、合宿の参加者からレビュアーを募り、変更内容について意見をもらう開発レビューも実施しました。 さらに、チーム内で協議し、提供された分析結果を参考にしてデータ可視化用のダッシュボードを作成し、日々のサービスの状況を確認しています。 SDPFでは合宿で指摘されたIPアドレスからのアクセス増加による影響が調査されました。このアクセスによるシステムへの影響はなかったものの、分析結果からアクセス集中を検知することで、システム負荷計測やユーザーのアプリケーション活用方法の変化を検知し、フィードバックができないか協議がなされました。 上記のように合宿で得られた分析結果が、各サービスの改善に用いられました。 終わりに 今回のデータ分析開発合宿により、サービスがもつデータの分析と課題解決のための施策を提案し、サービスの改善に貢献できました。 今年も開催し社内のデータ利活用をさらに推進していきたいです。