Share
Download the
Global Threat
Intelligence Report
第 15日目は私、IoT事業部の田中の記事になります。ここまでは主にSOC業務に従事するアナリストさんのブログがアドベントカレンダーを華やかに盛り上げておりますが、箸休め的に私の部署の取り組みの一部を紹介します。
「IoT」事業部なんて名前を聞くとなんだか焦点がぼやっとしてる印象を受けるかも知れませんが、半分当たりです。実際はIT以外の業界でのサービス化を目指して遊撃しているグループで、その中で私はProcess Automation(PA)やFactory Automation(FA)など、Industryal Contorol System(ICS)あるいはOperation Technology(OT)と呼ばれる領域に分類される新しいジャンルのアセスメントに従事しています。
最近ではOTネットワークを流れるトラフィックデータを収集し分析することで、ネットワーク上の端末、フローを可視化し、マイクロセグメンテーションなどの堅牢化に繋がるレポートを作成しています。その後、OTネットワークでのMSSをご希望のお客様にはホワイトリスト型検知のソリューションを提案することが多いのですが、ベースラインを作成する上で特に課題となるのがリストに登録すべきプロトコルの洗い出しです。
OTネットワークでも広く使われるようになったTCP/IP、UDP/IPを例に話をします。IPプロトコルはポート番号とサービスの対応表がIANAから公開されており、トラフィック情報の中でも宛先ポートは稼働しているアプリケーションやサービスを知るためのカギとなる情報です。IT分野においてはHTTPは80番(TCP),DNSは53番(TCP/UDP)と、有名なものはサーバーサイド固有の番号とサービスが紐づくことが多いです。（もちろんその限りではないものもありますが...）
マルウェアの例ではRemote Access Tool(RAT)は感染端末に空いてしまったバックドアと、その感染端末を複数コントロールする攻撃者のパネルにサーバー・クライアントの概念がありますね。このサーバーポートは変更できるものも多いですが、RATによって特徴があります。また、OTの分野では広く使われており、フォーマットやツールもインターネットに充実しているプロトコル「Modbus/tcp」では制御指令を出す端末はマスター、受け取る端末をスレーブと定義し、503番(TCP)ポートにて通信をしています。このように親子関係を把握することでプロトコルの方向を決めることができ、さらに方向毎に流れるデータをルール化してより強固なホワイトリストを作成することが可能になります。
ということで前置きが長くなりましたが、要は宛先ポートはネットワークの可視化から堅牢化まで大切なカギになっています。逆に送信元ポートは一定の範囲でランダムに割り当てられる設計が多いため、分析やホワイトリストに使うことは少ないです。しかしトラフィックデータを眺めているとどうもOTネットワーク独特のポート番号の使い方がありそうです。
OTプロトコルの使うポート番号のクセがすごい！
1. 宛先ポートと送信元ポートが同一
有名なプロトコルではビルディングでの空調管理などに用いられるBACnetがあります。BACnetは47808番(UDP)を宛先ポートだけでなく送信元ポートとしても用います。ちなみに47808という数字は16進数に変換すると0xBAC0となり、「BAC」netとして非常に覚えやすいですよね。
送受信ポートが同一なプロトコルはITでも皆無ではありませんが、UDPで通信することが多く3wayハンドシェイクもないため、宛先ポート番号でセッションを纏めるだけではどちらがサーバーであるかを判断できません。アプリケーション層を分析し「命令」と「応答」に分類することで初めて方向を決定することが出来ます。リクエストとリプライのタイミングで分類するアプローチも十分考えられます。
2. 送信元ポートが固定で宛先ポートが発散
当初分析していて、どうも方向を正しく分析ツールが認識しないなと思っていたら想像と逆！と裏切られたパターンです。制御機器の1つであるProgrammable Logic Controller(PLC)をエンジニアリングする際、実装されているモジュールごとにポート番号（および通信方式）が選択できるものがあります。この結果、同じフォーマットのプロトコルを複数の宛先ポート番号に送信することができるためこのような現象が発生します。下記の図を見ると明らかなのですが、先のHTTPのような一般的なプロトコルと真逆のやりとりのようになるため、統計を取る際には間違って方向を修正してしまわないよう注意が必要になります。
3. 宛先ポートと宛先IPアドレスが連動している
これが一番複雑で、想像以上に多く見かけます。OTネットワーク内での役割が同種の機器の送受信を並べて初めて気づくことが出来るレベルです。分析の前からプロトコルの設計仕様が分かっていれば良いのですが、エンドユーザー様からご提供いただけることは稀で、詳細設計資料は構築ベンダーで閉じていることがほとんどではないでしょうか。下記の左図はデイジーチェーン、右図はマルチドロップに近い印象を受けます。このネットワークはシリアル接続されている時代の仕様が色濃く残っていると個人的に推測しています。ポート番号もIPアドレスも合わせて「番地」として等しく扱っているのではないでしょうか。結果、2.と同じく複数のポートで同じプロトコルが使われることになります。
セキュリティ上のリスクなのか？
1. 2. 3. いずれの実装も送信元のSource Portにランダマイゼーションが適用されていないため、過去のDNSキャッシュポイズニングのように中間者攻撃が成功する確率が上がってしまうリスクがあります。対策は先のランダマイゼーションが有効なのですが、このような複雑な実装は個々の端末のアップデートではなくシステム全体の更新が必要になり、ほとんどのケースではこれら実装を受け入れて運用を強いられてしまうのではないでしょうか。ただ一方で、一般的でない番号のSource Portが固定されていることをルールとして逆手に取りアノマリとして検知することが可能なため、ホワイトリストとの相性が良いと前向きに捉えることも出来ます。我々はこの実装に対し強固かつ可用性を侵害しない適切なホワイトリストを提案できるよう日々取り組んでおります。
おわりに
OTネットワークのような限られた通信が行われているネットワークであってもホワイトリストの作成は簡単ではありません。OTネットワーク特有の実装はポート番号以外にも見受けられます。アドベントカレンダー以降でも続編をポストする予定ですので、このブログを見てくださった皆様から色々なご意見を頂けると非常に嬉しいです。