Cisco Japan Blog > 脅威リサーチ

脅威リサーチ

Snort 3 サービスインスペクタを使用した ICS プロトコルのカバレッジ

TALOS Japan
2023年10月4日

広範囲に及ぶ IT ネットワークに接続される運用テクノロジー（OT）ネットワーク上のデバイスの数が増えるにつれ、ICS プロトコルに対する効果的な検査能力がこれまで以上に重要になっています。

しかし、ICS プロトコルのトラフィックを検査するときにいつも生じる課題がいくつかあります。

多くの場合、これらのデバイスを最新のネットワークに接続する際に使用されるプロトコルは、古いシリアルプロトコルがもとになっています。こうした経緯から、メッセージサイズを縮小するためにビットフィールドのような技法がプロトコルで使用されるようになり、元のプロトコルへの変更を防ぐために複数レベルでカプセル化が行われています。これらのプロトコルは、1 つのパケットに複数のリクエストを組み込んだり（パイプライン化）、1 つのリクエストを複数のパケットに分割したり（フラグメント化）することがよくあります。Snort はどちらの方法が採用されていても、その仕組みを利用してトラフィックを完全に検査できます。ただし、そのためには根底にあるプロトコルやさらに複雑なプレーンテキストのルールに対する深い理解が必要であり、誰もが簡単にできることではありません。

これらの問題は、高い検査能力を必要とするプロトコルに対して Snort 3 サービスインスペクタを使用することによって解決できます。サービスインスペクタは Snort 2 の前処理プログラムから発展したものであり、追加の組み込みルールへのアクセスを提供します。この組み込みルールとは、プロトコルレベルの異常を検出するルール、パイプライン化やフラグメント化されたメッセージを正規化するルール、検査対象のトラフィックが予測したプロトコルかどうかを補助的に検証するルールです。既存のサービスインスペクタで使用されるルールオプションによって、プレーンテキストのルール作成者は検査対象のカバレッジ拡大に重点を置くことができ、プロトコルの復号処理や正規化処理は Snort に任せることができます。

プロトコル

現在、Snort 3 には ICS プロトコルを対象とする 6 つのサービスインスペクタがあります。具体的には MMS、IEC104、ENIP/CIP、S7CommPlus、DNP3、Modbus です。

MMS

Cisco Talos は 2022 年春に、IEC 61850 で定義された Manufacturing Message Specification（MMS）プロトコル対応の Snort 3 専用サービスインスペクタを Firepower 7.2 と同時にリリースしました。それまではサービスインスペクタがなく、どの種類にせよ MMS のカバレッジ作成は複雑で、よく誤検出が発生していました。ルール作成者は、個々のルールすべてについて、MMS PDU のカプセル化が行われているさまざまなプロトコルレイヤを、対象のバイトデータが処理される前に解析する必要がありました。カプセル化レイヤを変更できる多数の方法を考えながら、それと同時にカプセル化された PDU を配信する必要もあったのです。ルール作成者が時間をかけてあらゆる組み合わせのカバレッジを書いたとしても、メッセージパイプライン技法は、最も考え抜かれたルールをも回避してしまうことがよくありました。このような困難とプロトコルへの対応強化の要望を受け、Talos は MMS 用のサービスインスペクタが最善の道であると判断しました。専用のサービスインスペクタを使用すれば、どのようなカプセル化レイヤやパイプライン技法が使用されていたとしても、ルール作成者はもはやほとんど気にする必要がありません。MMS PDU に関して記述するだけでよく、解析や正規化はインスペクタに任せておけます。

完全にカプセル化された MMS メッセージ内には識別可能な情報が大量にあるので、MMS メッセージは Snort 3 ウィザードのフレームワークの使用対象として最有力候補でした。Curse を使用して MMS トラフィックを精査することにより、いくつかの利点が得られます。まず、検査対象が特定のポートに限定されることがなくなり、非標準の実装であってもデフォルトで検査できます。ほかにも、複数のプロトコルが同じポートで使用される場合（MMS と S7CommPlus が同時に使用されるケースなど）のポート競合を回避できるという利点があります。さらに、トラフィックがより厳密に検査されるので誤検出のアラートも減少します。

このインスペクタによって、プレーンテキストの 2 つのルールオプションが導入され、MMS のカスタムルールの作成に必要な作業が簡略化されます。このインスペクタを ber_data と ber_skip のルールオプションと一緒に使用すれば、メッセージのカプセル化を気にすることなく MMS PDU の特定フィールドに対するカバレッジを作成できます。1 つ目のルールオプションは mms_func で、サポートされる MMS Confirmed-Request や MMS Confirmed-Response サービスが TCP ストリーム内に存在するかどうかを確認します。2 つ目は mms_data で、検出カーソルを MMS PDU の先頭に動かし、ルール作成者が常に同じ位置から検出を開始できるようにします。

このインスペクタで導入された機能がどのように使われるかを示すルールの例は次のとおりです。この例では、MMS Take Control Confirmed Service Request の acceptableDelay フィールドに異常値がないかを検索しています。

alert mms ( \

msg:”PROTOCOL-SCADA MMS take_control abnormal acceptableDelay value”; \

flow:to_server,established; \

# fast pattern

content:”|A0|”; \

# only enter in the takeControl confirmed service request

mms_func:take_control; \

# move cursor to the start of the mms data

mms_data; \

# enter the confirmed-RequestPDU

ber_data:0xA0; \

# skip `invokeID`

ber_skip:0x02; \

# enter the `takeControl` confirmed service request

ber_data:0xB3; \

# enter the `takeControl` data

ber_data:0xA0; \

# skip the semaphore name

ber_skip:0x80; \

# skip the named token parameter if it exists

ber_skip:0x81,optional; \

# skip the priority parameter if it exists

ber_skip:0x82,optional; \

# enter the `acceptableDelay` parameter

ber_data:0x83; \

# match on the abnormal value

content:”|FF FF|”, within 2; \

classtype:protocol-command-decode; \

sid:1000000; \

)

Talos のアナリストは、MMS のトラフィックを識別するためのルールセットを作成しています。これらのルールは単に特定のメッセージの存在を示すものであり、メッセージ自体に悪意のあるトラフィックがあるかどうかを示すものではありません。カバレッジについては、45423 ～ 45436 および 50538 ～ 50615 の SID を参照してください。

MMS サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

BER ルールオプションの詳細についてはこちらを参照してください。

IEC104

Cisco Talos は 2021 年春に、IEC 60870-5-104（IEC104）対応の Snort 3 専用サービスインスペクタを Firepower 7.0 と同時にリリースしました。サービスインスペクタがなくても IEC104 トラフィックのカバレッジを作成することは可能でしたが、複雑な作業でした。このプロトコルでは、ヘッダーに続くメッセージのタイプを特定するために、プロトコルヘッダーでビットフィールドが使用されています。Snort では、このビットフィールドを完全に解析できますが、すべてのルールでそうしなければならないのは厄介です。ルール作成者が時間をかけてメッセージを正しく解析しても、パイプライン化技法によってたびたび検出が回避されました。Talos は、より包括的なカバレッジを提供しルール作成者の支援を強化するには、IEC104 対応のサービスインスペクタを構築することが最善の措置であると判断しました。

IEC104 インスペクタには、それ自体にも 54 のルールが追加で組み込まれており、プロトコルの異常な使用や無効な使用にアラートを出します。これらのルールは、本質的には、あるストリームが悪意のあるトラフィックを含んでいるということを示すものではありません。トラフィックの一部が仕様を逸脱している可能性があることを指標で示すことが目的です。ブール関数 enable_builtin_rules の設定エントリによって、組み込みルールの実行や停止を行えます。

IEC104 のメッセージ内には一意に識別できる情報が少ないため、Snort 3 ウィザードでサポートするのではなく、ポートバインディングを選択しました。このインスペクタは、デフォルトでは TCP/2404 にバインドされています。

このインスペクタによって、プレーンテキストの 2 つのルールオプションが導入され、カスタムルールの作成に必要な作業が簡略化されます。1 つ目のルールオプションは iec104_apci_type で、これにより、3 種類のアプリケーションプロトコル制御情報（APCI）のうち、現在検査しているメッセージで指定されているものをルール作成者が簡単に特定できます。2 つ目は iec104_asdu_func で、検査しているメッセージが、指定されたアプリケーション サービス データユニット（ASDU）機能と整合がとれているかどうかを確認するものです。

このインスペクタで導入された機能がどのように使われるかを示すルールの例は次のとおりです。この例では、iec104_asdu_func ルールオプションを用いて、アドレスフィールドに特定のアドレス値が含まれる C_IC_NA_1 リクエストを検索しています。

alert iec104 ( \

msg:”PROTOCOL-SCADA IEC104 C_IC_NA_1 abnormal address”; \

flow:to_server,established; \

# verify the ASDU Type ID matches the target interrogation command

iec104_asdu_func:C_IC_NA_1; \

# check to see if the Address field matches the target value

content:”|BE EF|”, offset 10, depth 2; \

classtype:protocol-command-decode; \

sid:1000000; \

)

あるいは、Numbered Supervisory Function リクエストがセンサーを通過するたびに単純にアラートを出すことが目標であれば、iec104_apci_type ルールオプションを下に示したように使用することができます。

alert iec104 ( \

msg:”PROTOCOL-SCADA IEC104 Numbered Supervisory Function request”; \

flow:to_server,established; \

# fast pattern on the magic

content:”|68|”, depth 1; \

# verify the Numbered Supervisory Function (S) APCI type is in use

iec104_apci_type:S; \

classtype:protocol-command-decode; \

sid:1000000; \

)

Talos のアナリストは、IEC104 のトラフィックを識別するためのルールセットをリリースしています。これらのルールは単に特定のメッセージの存在を示すものであり、メッセージ自体に悪意のあるトラフィックがあるかどうかを示すものではありません。カバレッジについては、41047 ～ 41052、41078、41079、52150 ～ 52203 の SID を参照してください。

IEC104 サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

CIP と EtherNet/IP

2019 年に、シスコの Jian Wu が Common Industrial Protocol（CIP）と EtherNet/IP（ENIP）プロトコル対応の Snort 3 専用サービスインスペクタをリリースしました。どちらのプロトコルであっても、多数のオプション、機能、サブプロトコルが利用可能になったことを考えると、カバレッジの作成は決して容易なことではありません。CIP サービスインスペクタは、ルールオプションを通じて、より一般的に必要とされるフィールドのいくつかを明らかにすることでルール作成者を支援します。ルール作成者は、プロトコル全体を手作業で解析する代わりにサービスインスペクタを使用することで、メッセージバッファの正規化という利点も得られ、パイプライン技法に起因する検出漏れの可能性を減らすことができます。

CIP インスペクタには、それ自体にも 4 つのルールが追加で組み込まれており、プロトコルの異常な使用や無効な使用にアラートを出します。これらのルールは、本質的には、あるストリームが悪意のあるトラフィックを含んでいるということを示すものではありません。トラフィックの一部が仕様を逸脱している可能性があることを指標で示すことが目的です。ブール関数 enable_builtin_rules の設定エントリによって、組み込みルールの実行や停止を行えます。

現時点では、CIP サービスインスペクタに対応したウィザードはありません。デフォルトでは TCP/44818 と UDP/22222 にバインドされています。これは必要に応じ、Snort の設定で変更できます。

このインスペクタによって、プレーンテキストの 11 のルールオプションが導入され、カスタムルールの作成に必要な作業が簡略化されます。ルールオプションのうちの 4 つ（cip_req、cip_rsp、enip_req、enip_rsp）は、トランザクションの方向を素早く検証するために使用されます。別の 6 つのオプション（cip_attribute、cip_class、cip_conn_path_class、cip_instance、cip_service、cip_status）を使用すれば、ルール作成者はこのプロトコルのカプセル化されたヘッダー内の特定フィールドに関してアラートを出すことができます。最後の 1 つのルールオプションは enip_command で、このオプションを使用すれば、ルール作成者は整数値で指定された特定の EtherNet/IP コマンドに関してアラートを出すことができます。

利用できる CIP サービスインスペクタのルールオプションを組み合わせて使用したルールの例を以下に示します。この例では、ENIP Send RR Data リクエスト内に含まれる PCCC リクエストを検索しています。

alert cip (

msg:”PROTOCOL-SCADA EtherNet/IP PCCC request”; \

flow:to_server, established; \

# fast pattern on the ENIP command code

content:”|6F 00|”, depth 2; \

# check for a Send RR Data ENIP command

enip_command:0x6F; \

# check for the PCCC CIP service code

cip_service:0x4B; \

classtype:protocol-command-decode; \

sid:1000000; \

)

CIP サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

S7CommPlus

2019 年に、シスコの Pradeep Damodharan が、S7CommPlus プロトコル対応の Snort 3 専用サービスインスペクタをリリースしました。S7CommPlus PDU のデータセクションは暗号化されているので、プレーンテキストのヘッダーに着目して内容の検査が行われます。このインスペクタは、トラフィックの正規化とルール作成者の作業の複雑さを軽減することに重点を置いたもので、いくつかのルールオプションを使用して一般的な機能を明らかにします。

名前は似ていますが、このサービスインスペクタでサポートされるプロトコルを S7Comm と混同しないようにしてください。

S7CommPlus インスペクタには、それ自体に 3 つのルールが組み込まれており、プロトコルの異常な使用や無効な使用にアラートを出します。これらのルールは、本質的には、あるストリームが悪意のあるトラフィックを含んでいるということを示すものではありません。トラフィックの一部が仕様を逸脱している可能性があることを指標で示すことが目的です。ブール関数 enable_builtin_rules の設定エントリによって、組み込みルールの実行や停止を行えます。

S7CommPlus ヘッダー内の識別可能な情報量からすると、プロトコルを特定するために Snort 3 ウィザードのフレームワークを使用することは理にかなっていました。Curse を使用して S7CommPlus トラフィックを精査することにより、いくつかの利点が得られます。具体的には、検査対象が特定のポートに限定されることがなくなり、非標準の実装であってもデフォルトで検査できます。ほかにも、複数のプロトコルが同じポートで使用される場合（S7CommPlus と MMS が同時に使用されるケースなど）のポート競合を回避できるという利点があります。さらに、トラフィックがより厳密に検査されるので誤検出のアラートも減少します。

このインスペクタによって、プレーンテキストの 3 つのルールオプションが導入され、カスタムルールの作成に必要な作業が簡略化されます。最初のルールオプションは s7comm_content で、検出カーソルを PDU データの先頭に動かし、ルール作成者が常に同じ位置から検出を開始できるようにします。2 つ目のルールオプションは s7comm_func で、トラフィックが特定機能のコード（explore、createobject、deleteobject など）を含んでいるかどうかを確認します。最後のルールオプションは s7comm_opcode で、リクエストタイプのオペコードが特定の値（request、response、notification など）と一致するかどうかを確認します。

このインスペクタの 1 つのルールオプションを使用した例を以下に示します。この例のルールでは、対象の機能を構成するバイト情報がメッセージに含まれているかどうかをまず確認し、その後このインスペクタを使用して S7CommPlus CreateObject 機能が使用されているかを検証しています。

alert s7commplus (

msg:”PROTOCOL-SCADA S7CommPlus CreateObject request”; \

flow:to_server, established; \

# fast pattern on CreateObject

content:”|04 CA|”; \

# check for the CreateObject function code

s7commplus_func:createobject; \

classtype:protocol-command-decode; \

sid:1000000; \

)

S7CommPlus サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

DNP3

2015 年に、シスコの Ryan Jordan、Rashmi Pitre、Maya Dagon が分散ネットワークプロトコル 3（DNP3）対応の Snort3 専用サービスインスペクタをリリースしました。このインスペクタを実行すると、PDU を正規化し、TCP と UDP 上の DNP3 トラフィックの異常を検出できます。

DNP3 インスペクタには、それ自体に 6 つのルールが組み込まれており、プロトコルの異常な使用や無効な使用にアラートを出します。これらのルールは、本質的には、あるストリームが悪意のあるトラフィックを含んでいるということを示すものではありません。トラフィックの一部が仕様を逸脱している可能性があることを指標で示すことが目的です。ブール関数 enable_builtin_rules の設定エントリによって、組み込みルールの実行や停止を行えます。

現時点では、DNP3 サービスインスペクタに対応したウィザードはなく、デフォルトのポートバインディングもありません。DNP3 のルールオプションが使用されている、dnp3 サービスのキーワードが指定されている、カスタムのポートバインディングがインスペクタの設定に追加されている、このいずれかに該当する場合に DNP3 サービスインスペクタを使用できます。Snort3 ウィザードとバインダの設定に関する詳細についてはこちらを参照してください。

このインスペクタによって、プレーンテキストの 4 つのルールオプションが導入され、カスタムルールの作成に必要な作業が簡略化されます。まず、dnp3_data が検出カーソルを PDU データの先頭に動かし、ルール作成者が常に同じ位置から検出を開始できるようにします。次に dnp3_func が、特定機能のコードを持つ PDU がストリームに存在するかどうかを確認します。続いて、dnp3_ind を使用し、ルール作成者が DNP3 のインジケータフラグへ簡単にアクセスできるようにします。最後に、dnp3_obj のルールオプションによってプロトコルのオブジェクトのヘッダーが明らかになります。

DNP3 サービスインスペクタを使用したルールの一例を以下に示します。この例では、Disable Spontaneous Message 機能が使用されている箇所を検索しています。

alert dnp3 (

msg:”PROTOCOL-SCADA DNP3 Disable Spontaneous Message request”; \

flow:to_server, established; \

# fast pattern on magic

content:”|05 64|”, depth 2; \

# check for the desired function code

dnp3_func:disable_unsolicited; \

classtype:protocol-command-decode; \

sid:1000000; \

)

DNP3 サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

Modbus

2015 年に、シスコの Russ Combs と Ryan Jordan が Modbus TCP プロトコル対応の Snort3 専用サービスインスペクタをリリースしました。

Modbus インスペクタには、それ自体に 3 つのルールが組み込まれており、プロトコルの異常な使用や無効な使用にアラートを出します。これらのルールは、本質的には、あるストリームが悪意のあるトラフィックを含んでいるということを示すものではありません。トラフィックの一部が仕様を逸脱している可能性があることを指標で示すことが目的です。ブール関数 enable_builtin_rules の設定エントリによって、組み込みルールの実行や停止を行えます。

現在は、Modbus サービスインスペクタに対応したウィザードはありません。このサービスインスペクタは、デフォルトでは TCP/502 にバインドされています。これは必要に応じ、Snort の設定で変更できます。

このインスペクタによって、プレーンテキストの 3 つのルールオプションが導入され、カスタムルールの作成に必要な作業が簡略化されます。まず、modbus_data が検出カーソルを PDU データ先頭に動かし、ルール作成者が常に同じ位置から検出を開始できるようにします。次に modbus_func により、センサーを通過するトラフィックで特定の Modbus 機能のコードが使用されているかどうかをルール作成者が簡単に確認できるようになります。最後に modbus_unit によって MBAP ヘッダーの Unit ID フィールドが明らかになり、プレーンテキストのルール内で簡単にアクセスできるようになります。

Modbus サービスインスペクタを使用したルールの一例を以下に示します。この例では、Diagnostics リクエストが存在するかどうかを検索しています。

alert modbus (

msg:”PROTOCOL-SCADA Modbus Diagnostics request”; \

flow:to_server, established; \

# fast pattern on null protocol identifier

content:”|00 00|”, offset 2, depth 2; \

# check for the desired function code

modbus_func:diagnostics; \

classtype:protocol-command-decode; \

sid:1000000; \

)

Modbus サービスインスペクタの使用方法や機能の詳細についてはこちらを参照してください。

技術情報

Snort 3 が提供するサービスインスペクタによってプレーンテキストのルールがシンプルになると同時に、異常トラフィックが正規化され、誤検出が減少します。既存の ICS サービスインスペクタとルールオプションに関する詳細については、以下の技術情報を参照してください。

• Manufacturing Message Specification（MMS）サービスインスペクタの使用方法
• IEC 60870-5-104（IEC104）サービスインスペクタの使用方法
• Common Industrial Protocol（CIP）と EtherNet/IP （ENIP）サービスインスペクタの使用方法
• S7CommPlus サービスインスペクタの使用方法
• 分散ネットワークプロトコル 3（DNP3）サービスインスペクタの使用方法
• Modbus サービスインスペクタの使用方法
• BER ルールオプションの情報
• Snort の設定に関する詳細情報
• Snort 3 サービスインスペクタのソースコード
• Snort 3 のウィザードとバインダの設定

本稿は 2023 年 09 月 26 日に Talos Group のブログに投稿された「ICS protocol coverage using Snort 3 service inspectors」の抄訳です。

• SNORT