testing-ics-ot-protocols

Name: testing-ics-ot-protocols
Author: trilwu

github.com/trilwuセキュリティ17748 回インストール12 週間前に更新

リポジトリ

testing-ics-ot-protocols について

産業制御ネットワークの許可済み評価に使う ICS/OT セキュリティテストスキルです。物理プロセスに影響する可能性を踏まえ、パッシブ調査、プロトコル別の確認、運用担当者の承認を重視します。

主な機能

01安全を優先する OT テスト指針
02パッシブなトラフィックと資産の調査
03主要 ICS プロトコルの列挙
04読み取り専用操作と書き込み操作の区別
05Purdue モデルに基づくセグメンテーションレビュー

活用シーン

01許可済み SCADA 評価の計画
02公開された ICS デバイスとプロトコルの棚卸し
03IT/OT セグメンテーションとリモートアクセスの確認
04プロトコルの認証と暗号化の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/trilwu/secskills --skill testing-ics-ot-protocols

インストール後、Claude Code で/testing-ics-ot-protocolsを入力して読み込まれたか確認します。

詳細

ICS/OT プロトコルのテスト

ICS/OT プロトコルは、接続されたネットワークでのセキュリティではなく、隔離されたネットワークでの信頼性を重視して設計されました。ほとんどのプロトコルには、認証も暗号化も整合性チェックもありません。危険なのは、悪用が難しいことではありません。悪用によって物理的な影響が生じる可能性があることです。そのため、ここで行うすべての作業には安全上の制約が適用されます。

使用する場面

許可を得たエンゲージメントで、SCADA ネットワークや ICS 環境を評価する場合
対象範囲内の Modbus、DNP3、OPC UA、BACnet、EtherNet/IP、S7comm、MQTT デバイスをテストする場合
OT の安全要件に沿って、ICS 専用のペネトレーションテストを実施する場合
OT ネットワークのセグメンテーションと Purdue モデルへの準拠状況を確認する場合
制御システムネットワークへのリモートアクセス経路を評価する場合
ICS 資産を棚卸しし、認証されていないプロトコルの露出を特定する場合

使用しない場面

標準的な IT ネットワークのスキャン — enumerating-network-services を使用してください
通常の Web アプリとしてテストする HMI Web インターフェイス — testing-web-applications を使用してください
ICS 専用の検知ルールの作成 — engineering-detections を使用してください

安全最優先の原則

OT のペネトレーションテストは、ポートが異なるだけの IT ペネトレーションテストではありません。対象が物理プロセスを制御しているため、作業規則は根本的に異なります。

OT でアクティブスキャンが危険な理由：

PLC と RTU は、最小限の組み込みファームウェアで動作しています。不正なパケットや予期しない接続によって、デバイスがクラッシュしたり、プロセスが停止したり、危険な状態に陥ったりすることがあります。
PLC の再起動には現場での作業が必要になることがあり、制御対象のプロセスは中断に耐えられない場合があります。
TCP 接続をコマンドセッションとして扱うデバイスもあり、接続すること自体が操作に当たります。
Nmap のデフォルトのサービスプローブによって、本番環境の PLC がクラッシュした事例があります。

必須の制約：

アクティブテスト中は、必ず OT エンジニアまたはプラントオペレーターに立ち会ってもらうか、すぐに連絡できる状態にしてください。
ICS/OT 資産を明示的に対象とする書面での許可を得てください。一般的なネットワークのペネトレーションテストの対象範囲に、OT が含まれるとは限りません。
可能な限り、メンテナンス時間帯にテストしてください。明示的かつ個別の許可なしに、安全計装システム（SIS）をテストしてはいけません。
まずは受動的な観測から始めてください。受動フェーズでデバイスの種類を確認し、OT エンジニアの承認を得てから、アクティブな列挙に進んでください。
読み取り専用の操作（レジスターの読み取り、デバイス情報の照会）と、書き込み操作（コイルの設定、レジスターへの書き込み、コマンドの発行）を区別してください。書き込み操作にはデバイスごとの承認が必要です。
書き込み操作ごとにロールバック計画を用意してください。変更を加える前に、想定される状態を把握してください。
各デバイスとのやり取りをすべて記録してください。タイムスタンプと送信した正確なコマンドも含めてください。

プロトコルの概要

プロトコル	デフォルトポート	設計上の認証	暗号化	備考
Modbus TCP	502	なし	なし	最も一般的な ICS プロトコル。ネットワーク上のあらゆるホストが読み書きできます
DNP3	20000	オプション（SA）	なし	SCADA のポーリングに使用されます。セキュア認証が導入されていることはまれです
EtherNet/IP (CIP)	44818	なし	なし	Rockwell/Allen-Bradley のエコシステム
OPC UA	4840	あり（複数のモード）	オプション（TLS）	新しいプロトコルです。セキュリティは設定に全面的に依存します
BACnet/IP	47808 (UDP)	なし	なし	ビルオートメーション — HVAC、照明、アクセス制御
S7comm	102	なし	なし	Siemens S7 PLC。一定の保護機能を備えた S7comm-plus に置き換えられています
MQTT	1883 / 8883 (TLS)	オプション	オプション（TLS）	IoT/ICS のメッセージングに使用されます。ブローカーは公開状態のまま放置されていることがよくあります

パッシブ偵察

まずはここから始めます。パッシブな観察であればデバイスに影響を与えるリスクがなく、何かに触れる前に必要な資産インベントリを作成できます。

ICS ディセクタを使った Wireshark：

# Capture on the OT network interface (mirror/span port or tap)
tcpdump -i eth0 -w ics_capture.pcap -n

# Wireshark filters for ICS protocols
# Modbus
modbus

# DNP3
dnp3

# EtherNet/IP
enip

# OPC UA
opcua

# BACnet
bacnet

# S7comm
s7comm

# MQTT
mqtt

パッシブキャプチャから抽出する情報：

デバイスの IP アドレスと MAC アドレス（OUI 検索でベンダーを特定できます。Siemens、Rockwell、Schneider、ABB など）
プロトコルの分布 — 使用中のプロトコルと、それらが使われているセグメント
ポーリングパターン — マスター／スレーブの関係、ポーリング間隔、読み取られているレジスタ
プロトコルのバナーや応答フィールドで確認できるファームウェアバージョン
想定外のトラフィック — OT セグメント上の IT プロトコル、想定外のパターンで通信するデバイス
MQTT CONNECT パケット、OPC UA セッション、または HTTP ベースの HMI に含まれる暗号化されていない認証情報

パッシブな観察に基づく資産インベントリ：

IP、MAC、ベンダー（OUI に基づく）、観測されたプロトコル、役割（マスター／スレーブ／HMI／ヒストリアン）、確認できる場合はファームウェアバージョンを記載した表を作成します。これがアクティブな列挙範囲の基礎になります。

アクティブな列挙（許可を得た場合）

次の条件を満たした場合にのみ進めてください：（1）パッシブ偵察が完了していること、（2）OT エンジニアが資産リストを確認し、アクティブテストを承認していること、（3）対象範囲に ICS のアクティブな列挙が明示的に含まれていること。

ICS での安全な nmap の使用：

# NEVER use aggressive timing or default scripts against OT devices
# Use slow timing and specific ICS scripts only

# Modbus device discovery
nmap -Pn -sT -p 502 --script modbus-discover TARGET

# Siemens S7 device info (read-only query)
nmap -Pn -sT -p 102 --script s7-info TARGET

# BACnet device enumeration
nmap -Pn -sU -p 47808 --script bacnet-info TARGET

# EtherNet/IP enumeration
nmap -Pn -sT -p 44818 --script enip-info TARGET

# OPC UA discovery
nmap -Pn -sT -p 4840 --script opcua-endpoints TARGET

# IMPORTANT: Use -Pn (skip host discovery), -sT (full connect, not SYN scan),
# and NEVER use -A, -sV with high intensity, or broad script categories
# against OT devices.

専用の ICS スキャンツール：

# plcscan — lightweight PLC scanner
plcscan -t TARGET

# Redpoint Nmap scripts (Digital Bond)
# These are ICS-specific and safer than generic nmap scripts
nmap --script redpoint/ -p 502,44818,47808,102,20000 TARGET

プロトコル固有のテスト

Modbus TCP（ポート 502）

Modbus には認証機能がありません。ポート 502 に到達できるホストであれば、センサーの読み取り、コイルへの書き込み、PLC の制御が可能です。これは仕様どおりです。Modbus は、隔離環境のシリアルリンク向けに 1979 年に作られました。

コイルとレジスタの読み取り（読み取り専用、低リスク）：

# Using modbus-cli
modbus read TARGET 0 10          # Read 10 holding registers starting at address 0
modbus read -s coil TARGET 0 10  # Read 10 coils starting at address 0

# Using mbtget
mbtget -a 1 -r1 -n 10 TARGET    # Read 10 holding registers, unit ID 1
mbtget -a 1 -r2 -n 10 TARGET    # Read 10 input registers

# Python with pymodbus
python3 -c "
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('TARGET')
client.connect()
result = client.read_holding_registers(0, 10, unit=1)
print(result.registers)
client.close()
"

主な Modbus ファンクションコード：

FC 01 - Read Coils (digital outputs)
FC 02 - Read Discrete Inputs (digital inputs)
FC 03 - Read Holding Registers (analog outputs / config)
FC 04 - Read Input Registers (analog inputs)
FC 05 - Write Single Coil              ← WRITE — requires explicit approval
FC 06 - Write Single Register           ← WRITE — requires explicit approval
FC 15 - Write Multiple Coils            ← WRITE — requires explicit approval
FC 16 - Write Multiple Registers        ← WRITE — requires explicit approval
FC 43 - Read Device Identification

報告すべき指摘事項： プロセス制御ネットワークの外部からポート 502 に到達できる場合、制御システムにはアクセス制御がありません。これはほぼ常に重大度が「クリティカル」です。ネットワーク経路と、読み取り可能だったレジスタを記録してください。

OPC UA（ポート 4840）

OPC UA は、セキュリティを念頭に設計された唯一の ICS プロトコルです。実際に安全かどうかは、設定によって異なります。

検出とエンドポイントの列挙：

# List OPC UA endpoints and their security modes
# Using opcua-client-gui or UaExpert

# Python with opcua library
python3 -c "
from opcua import Client
client = Client('opc.tcp://TARGET:4840')
endpoints = client.connect_and_get_server_endpoints()
for ep in endpoints:
    print(f'Endpoint: {ep.EndpointUrl}')
    print(f'  Security Mode: {ep.SecurityMode}')
    print(f'  Security Policy: {ep.SecurityPolicyUri}')
    print(f'  User Token: {[t.TokenType for t in ep.UserIdentityTokens]}')
"

確認すべき認証方式：

匿名 — 認証情報は不要です。このエンドポイントが存在し、到達可能であれば報告してください。
ユーザー名／パスワード — デフォルト値（admin/admin、user/password、opcua/opcua）を試してください。
証明書 — 最も強力な方式です。証明書が単に受け入れられているのではなく、検証されていることを確認してください。

一般的な OPC UA の指摘事項：

認証が必要なエンドポイントと並行して匿名認証が有効になっている
セキュリティモードが None（署名も暗号化もなし）に設定されている
検証せずに自己署名証明書を受け入れている
ユーザー名／パスワード方式のエンドポイントでデフォルトの認証情報が使われている

DNP3（ポート 20000）

# DNP3 enumeration — identify master/outstation roles
nmap -Pn -sT -p 20000 --script dnp3-info TARGET

# Check for DNP3 Secure Authentication (rarely deployed)
# Most DNP3 implementations have no authentication at all

BACnet（UDP ポート 47808）

# BACnet device discovery
nmap -Pn -sU -p 47808 --script bacnet-info TARGET

# BACnet enumeration with BAC0
python3 -c "
import BAC0
bacnet = BAC0.lite(ip='YOUR_IP/24')
devices = bacnet.whois()
print(devices)
"

S7comm（ポート 102）

# Siemens S7 PLC information
nmap -Pn -sT -p 102 --script s7-info TARGET

# Identifies: module name, serial number, plant identification,
# firmware version, hardware version, CPU state

よくある所見

以下は、ICS 評価の大半で見られます。

1. フラットなネットワーク（IT-OT 融合） 最も影響の大きい所見です。企業 IT と制御システムがセグメント化されていないと、侵害されたワークステーションから PLC に直接アクセスできます。IT ネットワークセグメントから ICS ポートに到達できるか試して確認します。

2. HMI およびエンジニアリングワークステーションのデフォルト認証情報 HMI のウェブインターフェース、オペレーターステーションの VNC サーバー、エンジニアリングソフトウェアでは、工場出荷時のデフォルト認証情報が使われていることがよくあります。テスト前に、ベンダーのドキュメントでデフォルト認証情報を確認します。

3. プロセスネットワーク以外に公開された認証なしのプロトコル Modbus、S7comm、BACnet には認証機能がありません。プロセス制御ネットワークの外部からこれらのポートに到達できる場合、侵害されたホストから物理プロセスを制御できます。

4. 機密データを運ぶ暗号化されていないプロトコル 認証情報、プロセス値、設定データが平文で送信されています。読み取り可能なデータが示されたパケットキャプチャで実証します。

5. 制御が不十分なリモートアクセスゲートウェイ OT ネットワークへのリモートアクセスを提供する VPN コンセントレーター、踏み台ホスト、携帯電話モデムなどです。多要素認証、セッションのログ記録、アクセス制限を確認します。

6. 既知の脆弱性がある古いファームウェア ICS デバイスは、パッチ適用に停止時間が必要なため、最新リリースより何年も遅れたファームウェアを実行していることがよくあります。バージョンを記録し、既知の CVE と照合します。ただし、明示的な承認なしに悪用を試みてはいけません。

7. ヒストリアンおよびデータダイオードの設定ミス IT と OT を橋渡しするヒストリアンは DMZ に配置する必要があります。データダイオードでは一方向の通信を強制する必要があります。トラフィック分析で確認します。

ネットワークセグメンテーションのレビュー

Purdue エンタープライズ参照アーキテクチャに照らして評価します。

Level 5  Enterprise network (corporate IT)
Level 4  Site business planning (ERP, email)
         ─── IT/OT DMZ ───
Level 3  Site operations (historians, OPC servers)
Level 2  Area supervisory control (HMI, engineering workstations)
Level 1  Basic control (PLCs, RTUs, controllers)
Level 0  Process (sensors, actuators, field devices)

確認事項：

レベル 3 とレベル 4 の間に DMZ がありますか？IT と OT の間でトラフィックが直接流れないようにする必要があります。
必要な箇所にデータダイオードまたは一方向ゲートウェイが設置されていますか？
レベル 5／4 のホストからレベル 1／0 のデバイスに到達できますか？（到達できないようにする必要があります。）
OT へのリモートアクセスに踏み台ホストまたはバスティオンホストが必要ですか？
OT 内の東西方向のトラフィックはセグメント化されていますか（レベル 2 とレベル 1 の分離、プロセスゾーンの分離など）？
ファイアウォールルールはデフォルト拒否に明示的な許可を設定していますか、それともデフォルト許可ですか？

防御レビューのチェックリスト

攻撃ではなく、ICS のセキュリティ態勢をレビューする場合：

拒否すべき合理化

「通常のネットワークと同じようにスキャンすればよいのです。」 そうはいきません。SYN スキャンによって PLC がクラッシュし、物理プロセスが停止するおそれがあります。OT のスキャンには、デバイス固有の知識、ゆっくりとしたタイミング設定、そして介入できるエンジニアが必要です。
「エアギャップがあるので、テストする必要はありません。」 エアギャップが現実に触れても維持されることはほとんどありません。USB ドライブ、保守用ノート PC、セルラーモデム、ベンダーの VPN によって、エアギャップを迂回する経路が生まれます。
「OT チームが、何にも触れられないと言っています。」 それなら、パッシブ評価のみを対象範囲にしてください。トラフィックのキャプチャとアーキテクチャのレビューだけでも、価値の高い発見が得られます。作業を見送らないでください。
「Modbus が公開されているのを見つけました。それで十分です。」 ネットワーク経路、読み取れたレジスタ、そのレジスタが制御する対象を記録してください。「ポート 502 がオープン」はスキャン結果であり、発見事項ではありません。
「読み取り専用のテストに OT エンジニアの立ち会いは不要です。」 デバイスによっては、読み取り操作にも副作用があります。どのデバイスに注意が必要かは、エンジニアが把握しています。エンジニアに常に状況を共有してください。
「影響を証明するために、コイルに書き込みましょう。」 本番環境の PLC に書き込むと、物理的な損害を引き起こすおそれがあります。実際に書き込まずに書き込み能力を実証するか、保守時間内にプロセスを安全に停止してテストしてください。
「ベンダーは、このプロトコルは安全だと言っています。」 独自プロトコルのセキュリティに関するベンダーの主張は、証拠にはなりません。テストしてください。「独自」とされるプロトコルの多くは、簡単にリバースエンジニアリングできるか、隠蔽によるセキュリティしか提供していません。

参考資料

enumerating-network-services — 標準的な IT ネットワークサービスの列挙
engineering-detections — ICS 固有の脅威に対する検知ルールの作成
reporting-security-findings — 影響を最大化する ICS の発見事項の構成
IEC 62443（産業用オートメーションのセキュリティ）；NIST SP 800-82（ICS セキュリティガイド）
MITRE ATT&CK for ICS：https://attack.mitre.org/techniques/ics/

Markdown 対応

ログインしてコメント

基本情報

作者: trilwu
リポジトリ: trilwu/secskills
カテゴリ: セキュリティ
インストール数: 48
GitHub スター: 177

問題を報告