NTTドコモビジネスの技術ブログ

全641件

2026/11/05

OsecTに関する技術検証―ZeekとSuricataの比較からパーサー開発、性能評価まで(インターンシップ体験記)

はじめにこんにちは。2026年夏のNTTドコモビジネスの現場受け入れ型インターンシップに参加した、吉永( github.com/ta-061 )です。普段は、特殊環境で動作するアプリケーションの脆弱性検出に関する研究や、CTFなどのセキュリティ活動に取り組んでいます。 8月から9月にかけての2週間、NTTドコモビジネスのイノベーションセンターで、OTセキュリティサービスのOsecTに関する技術検証に取り組みました。ZeekとSuricataの取得情報を比較し、解析プラグインを開発したうえで、Raspberry Pi 5の実機で性能を評価しました。この記事では、今回取り組んだ業務の内容と、その中で難しかった点や学んだことについて紹介します。はじめに参加のきっかけ今回のテーマ：小型端末でのIDSセンサーを考える取り組んだこと 1. IPフローログとModbusログについて、ZeekとSuricataの取得情報を比較する 2. IPフローログとModbusログを同時に出力した際の実機性能をRaspberry Pi 5で比較する 3. CC-Link IE系の非IP通信について、Zeekで取得できる情報を整理する 4. CC-Link IE系の非IP通信に対応するSuricata向けプラグインを開発する 5. CC-Link IE系の非IP通信の実機性能をRaspberry Pi 5で比較する 6. 検証のまとめ自ら考え、相談しながら進める環境技術イベントや見学で知った職場の雰囲気 Tech LunchやTech Nightなどへの参加検証ルームの見学と社員の方との交流 2週間を通して変わった会社への印象おわりに参加のきっかけ私は、実際の社会インフラや産業システムを守るセキュリティ技術に関心があります。OT環境では、工場などの設備を止めないことや、制御システム特有の制約を踏まえて防御を考える必要があります。そうした環境を対象とするOsecTの開発や検証を通じて、検知や運用上の課題を実務に近い形で学びたいと考え、今回のインターンシップへの参加を決めました。今回のテーマ：小型端末でのIDSセンサーを考える OsecTは、工場などのOT環境を対象とするIDSです。IDSは侵入検知システムのことで、通信などを監視し、不審な活動や攻撃の兆候を検知します。OsecTは通信のコピーを受け取って解析し、脅威や脆弱性の検知に加え、接続された機器や通信状況の可視化によって、現場のセキュリティ対策を支えます。詳しくは OsecTのサービス紹介をご覧ください。今回は、OsecTの可視化や検知を支える通信解析に着目し、Raspberry Piのような小型端末上でセンサー機能を実現するための技術検証に取り組みました。小型端末で必要な処理ができれば、設置場所やコストの面で、導入の選択肢を広げられる可能性があります。そのためには、可視化や検知に必要な情報を取得できることと、センサー側で解析対象のパケットを取りこぼさずに処理できることが大切です。今回の実機性能評価では、パケットロスが0となる最も高い入力レートを求め、比較しました。具体的には、以下の順に進めました。 IPフローログとModbusログについて、ZeekとSuricataの取得情報を比較 IPフローログとModbusログを同時に出力した際の、Raspberry Pi 5でパケットロス0となる入力レートを比較 CC-Link IE系の非IP通信について、既存のZeek向けプラグインで取得できる情報を整理 CC-Link IE系の非IP通信に対応するSuricata向けプラグインを開発 CC-Link IE系の非IP通信について、Raspberry Pi 5でパケットロス0となる入力レートを比較取り組んだこと 1. IPフローログとModbusログについて、ZeekとSuricataの取得情報を比較するまず、OsecTが利用しているZeekと、同じくネットワーク解析に使われるOSSのSuricataについて、取得できる情報を比較しました。Zeekは通信を分析して詳細なログを生成するネットワーク監視ツールで、Suricataは侵入検知や防御、ネットワークセキュリティ監視の機能を持つツールです。最初の比較では、産業用通信プロトコルであるModbusの解析結果と、通信のまとまりを表すFlowの情報を確認しました。同じ通信を記録したPCAPファイルを入力し、それぞれがどのようなログを出力するかを調べました。比較の結果、確認したIPフローログとModbusログの多くの項目は、Suricataでもそのまま、あるいは変換や追加処理を行うことで取得できると分かりました。今回使用した通信データでは、Modbusのトランザクション数が両ツールで一致し、対象としたファンクションコードや例外応答も確認できました。ただし、IPフローの区切り方やModbusログの出力単位には違いがありました。同じ通信を入力しても、どこで一区切りとするかが異なれば、ログの件数や集計結果も変わります。そのため、項目名や件数だけで比較すると、取得できている情報を正しく判断できない場合がありました。そこで、各項目の意味や記録される単位まで確認し、設定や出力後の変換で対応できる部分と、追加の処理が必要な部分を整理しました。必要な情報の多くを取得できる見通しは得られましたが、そのまま同じログとして扱えるわけではなく、後続の処理に合わせた調整が必要だと分かりました。 2. IPフローログとModbusログを同時に出力した際の実機性能をRaspberry Pi 5で比較する取得情報の違いを整理した後は、IPフローログとModbusログを対象に、Raspberry Pi 5の実機上でZeekとSuricataを評価しました。入力レートを変えて測定し、その中でパケットロス0を確認できた最も高い入力レートを求めました。パケットロスの判定には、評価に用いたドロップカウンタを使用しました。結果は、1秒当たりのデータ量を表すMbpsと、1秒当たりのパケット数を表すkppsの両方で整理しました。この評価で難しかったのが、Suricataで並列数を増やしても、期待したようにパケットロス0となる入力レートが伸びなかったことです。原因を調べるため、各ツールが通信をどのように振り分けて処理しているかを確認しました。今回の構成では、IPアドレスやポート番号などを使って通信フローごとに処理先を決めていました。同じフローの要求と応答を同じ処理先に集めることで、両者を対応付け、通信の状態を保持しながら解析する仕組みです。初期の検証では、86パケット、7通信フローを含む小さなPCAPを繰り返し再生していました。図1に示すように、この方法では、再生する回数を増やしても同じフローの通信は同じ処理先に振り分けられるため、並列数を増やすだけでは処理が十分に分散されません。そこで、送信元ポート番号を変え、2,700パケット、100の独立したTCP通信フローを含むPCAPを用意し、複数の処理先へ通信が分散される条件で再評価しました。図1：通信フローのCPUコアへの割り当てを表した模式図 PCAPを見直した後は、100 TCP通信フローを4並列で解析し、IPフローログとModbusログを同時に出力する条件で比較を進めました。測定した範囲でパケットロス0を確認できた最も高い入力レートは、次のとおりです。ツール入力レート受信パケットレート Suricata 155 Mbps 約301.9 kpps Zeek 65 Mbps 約126.5 kpps ※入力レートは、送信側で指定したパケット再生レートです。今回の条件では、Suricataの方が高い入力レートまでパケットロス0を確認できました。この経験から、設定値を変えて結果を比べるだけでなく、ツールがどの単位で通信を振り分け、どのように状態を管理しながら解析しているかを理解することが結果の解釈や次の検証方法を考えるうえで重要だと学びました。 3. CC-Link IE系の非IP通信について、Zeekで取得できる情報を整理する IPフローログとModbusログの比較に続いて、対象をCC-Link IE系の非IP通信へ広げました。CC-Link IE系については、公開されているZeek向けプラグインがあります。まずはこの既存プラグインで取得できる情報を確認し、Suricata側で解析機能を実装するために整理しました。今回対象としたのはIPを使わない通信であり、IPアドレスやポート番号を前提にした見方では扱えません。そのため、対象のフレーム形式と、そこからどのような情報を取り出せるかを確認する必要がありました。既存プラグインでは、送受信元のMACアドレスやプロトコルの種別、通信から読み取れるノード情報などをログとして取得できます。これらの項目がどのように通信データから読み取られるかを調べ、Suricata向けプラグインで扱う内容を具体化しました。 4. CC-Link IE系の非IP通信に対応するSuricata向けプラグインを開発する次に、整理した情報と既存のZeek向け実装を参考に、CC-Link IE系の非IP通信を解析するSuricata向けプラグインをC言語で作成しました。パーサーとは、通信データを一定の規則に従って読み取り、意味のある情報に分解するプログラムです。既存実装を参考にできるとはいえ、ツールが変わると解析処理を呼び出す仕組みやログの出力方法も変わります。そのため、通信の読み取り方を理解したうえで、Suricataにどのように組み込むかを考えながら実装を進めました。また、通信データを読み取る処理では、想定より短い入力や、対応していない種類の入力をどう扱うかも重要になります。必要な長さがあるかを確認してから読み取るなど、解析結果だけでなく、入力に応じた処理の仕方にも気を配りました。作成後は、不具合の修正も進めました。自分でも解析処理を書くことで、比較の際に見ていたログがどのように生成されるのかを具体的に理解できました。 5. CC-Link IE系の非IP通信の実機性能をRaspberry Pi 5で比較するプラグインの開発後は、CC-Link IE系の非IP通信を対象に、Raspberry Pi 5でZeekとSuricataを評価しました。今回は既存のZeek向けプラグインと、作成したSuricata向けプラグインを使用し、測定した中でパケットロス0を確認できた最も高い入力レートを比較しました。入力には、2,704パケット、40種類のMACアドレスを含み、フレーム長にも変化のあるPCAPを用いました。この条件でパケットロス0を確認できた入力レートと、同じ測定での受信パケットレートは、次のとおりです。ツール入力レート受信パケットレート Suricata 5 Mbps 約20.5 kpps Zeek 10 Mbps 約41.1 kpps ※入力レートは、送信側で指定したパケット再生レートです。今回の条件では、Zeekの方が高い入力レートまでパケットロス0を確認でき、Modbus/TCP通信とは逆の傾向になりました。また、非IP通信では、IPアドレスやポート番号を使って処理先を決める分散方法を、そのまま適用できませんでした。Modbus通信で有効だった並列化の考え方を別の通信へ適用するには、処理の分け方から検討する必要があると分かりました。非IP通信に合わせた処理の分散は、今後さらに検討したい点です。これらの比較を通じて、Mbpsとkppsの値に加え、入力データの特性や並列処理の条件も含めて評価する大切さを学びました。 6. 検証のまとめ今回の検証では、IPフローログとModbusログの取得情報を比較し、Suricataでも必要な情報の多くを取得できる見通しが得られました。また、CC-Link IE系の非IP通信に対応するプラグインを実装し、実機での評価まで進めることができました。今回の測定条件では、パケットロス0を確認できた最も高い入力レートは、Modbus通信ではSuricata、CC-Link IE系の非IP通信ではZeekの方が高くなりました。通信の種類や解析の仕組みによって結果が変わるため、取得できる情報と実機での性能を合わせて判断する必要があります。ログの仕様を揃えるための調整や、非IP通信に適した処理の分散は、今後の検討課題として整理しました。自ら考え、相談しながら進める環境こうした調査や検証を進めるにあたり、自分で必要な情報を調べ、評価方法を考える余地を多くいただきました。担当社員の方には、技術的な質問に丁寧に答えていただきました。同時に、自分なりの調査や考察も尊重していただけたので、主体的に課題へ取り組むことができました。分からないことを調べ、実験し、その結果をもとに次の進め方を考えるという流れを、実際の業務に近い形で経験できたと感じています。勤務は対面とリモートを組み合わせた形式でした。対面では直接相談したり、職場の雰囲気を知ったりでき、リモートでは実装や実験に集中できました。技術的な経験に加え、自分がどのような環境で働きやすいと感じるかを知る機会にもなりました。技術イベントや見学で知った職場の雰囲気 Tech LunchやTech Nightなどへの参加担当業務以外にも、Tech LunchやTech Night、情報セキュリティに関する合同イベントに参加させていただきました。社員の方々によるLTでは、セキュリティに限らず、ネットワーク、仮想化、AI、ソフトウェア開発など、幅広い技術の話を聞くことができました。自分の担当テーマを深掘りする時間と、普段とは異なる分野に触れる時間の両方を持てたことが良かったです。特に印象的だったのは、社員の方が関心を持って調べたり検証したりした内容を、周囲に共有していることでした。技術への興味が日々の交流にもつながっていて、こうした環境で働く面白さを感じました。検証ルームの見学と社員の方との交流検証ルームでは、サーバーやOsecTセンサーなどの実機を見せていただきました。普段の作業で扱っているソフトウェアが、実際にはどのような機器の上で動いているのかを知り、自分の担当業務をより具体的にイメージできました。また、懇親会では、業務中とは異なる雰囲気で仕事やキャリアについて伺うことができました。技術的な課題に取り組むだけでなく、その仕事に関わる人や職場について知ることができたのも、現場受け入れ型インターンシップの魅力だと思います。 2週間を通して変わった会社への印象参加前は、ドコモグループに対して、通信を中心とした規模の大きな企業という印象を持っていました。セキュリティ分野への関心もありましたが、実際どのように技術を調べ、製品を開発しているのかまではイメージできていませんでした。今回、NTTドコモビジネスでOsecTの技術検証に取り組み、既存の機能や利用環境を踏まえて製品の改善を考える経験ができました。自分で調査方法を考え、実装や評価まで進める中で、想像していた以上に技術を深く追究でき、自分の専門性を活かせる仕事があるのだと感じました。社風についても、社員の方が自分の考察を尊重してくださったことや、技術イベントでネットワークやAI、セキュリティなどの知識を共有していたことが印象に残っています。個人の技術への関心を大切にしながら、周囲と学び合って仕事を進める雰囲気を感じました。また、対面で相談する時間とリモートで実装や実験に集中する時間を経験できたことで、日々の働き方も具体的に想像できるようになりました。2週間を通じて、会社の規模や事業内容への関心に加え、こうした社員の方々と技術を掘り下げながら働けることにも魅力を感じるようになりました。おわりに実際の製品に関係する課題について、自分で考えながら調査から実装、評価まで取り組みたい方や、NTTドコモビジネスでエンジニアとして働く様子を知りたい方には、魅力的なインターンシップだと思います。最後に、受け入れてくださったチームの皆さま、日々相談に乗ってくださった担当社員の皆さま、イベントや見学の機会を用意してくださった皆さまに感謝申し上げます。今回得た経験を、今後の研究やセキュリティ分野での活動に活かしていきたいと思います。2週間、本当にありがとうございました。

Raspberry Pi, セキュリティ, キャリア, インフラ, ネットワーク, OSS, 組み込み

NTTドコモビジネス の技術ブログ

コンテンツ

NTTドコモビジネスの技術ブログ