セキュリティ対策したときに本当に有効なのかと自分で確認したことはありますか？ドアを施錠したらガチャガチャ確認するのに、セキュリティ対策した後ガチャガチャ確認しないのは不思議ではありませんか？
はじめに
ドアノブ、ガチャガチャしてますか？
ドアを施錠したとき、ドアノブをガチャガチャして確認しますよね。これをセキュリティ診断の目線で考えると、攻撃者目線で侵入できるか確認していることにあたります。
FWなどサイバーセキュリティ対策（施錠）をしたとき、侵入できるか確認（ガチャガチャ）していますか？確認していないとしたらなぜでしょう？確認せずに不安じゃないですか？
なぜガチャガチャしないのか？
「対策実施した人を信じている。」「サイバー攻撃されたことがない。」「目で見えないものはわからない。」「おかしな作業して問題おこしたら大変。」など、理由は様々ありそうですが、本稿では「確認したいが安全・簡単に確認する方法を知らないから」を答えとしてみます。
本稿の意図
サイバーディフェンス研究所の安井です。長年制御システムを開発してきた経験から制御システムセキュリティ向上に取り組んでいます。セキュリティ診断に関わっていると「開発・保守に関わる誰かが診断（攻撃者）目線で確認していたら気付いていただろうなぁ」という単純なミスに出会うことがあります。せっかくセキュリティ対策をしているのに、「対策の有効性をあまり確認していないのはもったいない。制御システム業界に、簡単にできる確認だけでも実施できる人が増えていただけたらいいのになぁ」と思います。
セキュリティ対策（施錠）をした人も、対策（施錠）を実施した事の確認はしていても、対策が有効なのかの確認（ガチャガチャ）はしていないのかもしれません。安全・簡単に確認できる方法があるならやってみたいと思った方へ、安全・簡単に確認（ガチャガチャ）する方法をテーマを決めてシリーズでお伝えします。本稿をきっかけに、セキュリティ診断など対策の有効性の確認に興味を持つ人が増えていただけたら幸いです。
対象読者
- 制御システムのセキュリティ対策の有効性の確認方法に関心がある方
- WindowsやLinuxの基礎的なコマンド実行と通信設定を実施したことがある方
- 予算が少ない一人情シスならぬ一人制御システムセキュリティ担当の方
第１回テーマ「インターネットへの疎通可否」
まず今回最初のテーマとして、制御システムセキュリティ業界における古典テーマである「インターネットとは切り離しているはずのシステムが、インターネットと繋がってしまっていないか？」の確認をテーマとしたいと思います。
何らかのミスにより、インターネットと通信できるようになってしまっていないか？ という確認です。初回なので初歩的でシンプルな内容としました。
制御システムがインターネットと疎通できるとどのようなリスクがあるかの代表事例としては、もし制御システム内にマルウェアが入り込んだとすると、疎通可能なルートを通じてインターネット上のC2サーバと接続されC2サーバから操作される事が挙げられます。
こんな事に見覚えありませんか？
良かれと思って作業していても人間ですからミスはするものです。ありえそうな２つの例を挙げてみます。こんな状態となっていたら不安をおぼえませんか？
-
ファイアウォールを設定する人が別部門であり、ファイアウォール設定変更作業時にミスをして穴を開けてしまったままとなっている。作業後、制御システム部門の人はインターネットと疎通できるかは確認していない。
-
制御システムの保守員が、遠隔保守したいために保守作業用にインターネットと接続するためのルータ等の機器を一時的に設置したまま撤去を忘れている。忘れた後、制御システム部門の人はインターネットと疎通できるかは確認していない。
確認手順 制御システムからインターネットへ疎通できるか
ここからが本題です。
最初に注意事項
制御システムの運用に問題を起こしそうなことは本題には記載していませんが、制御システムにおいては可用性が重視されるため、作業してよい項目を厳密に管理されている場合も多いと思います。以下に示す確認手順を制御システムで試す場合は、関係者に許可を得た上で実施してください。
IPネットワークの仕組みについて学んだことがある方へ（難しいと感じる箇所があれば読み飛ばしてください）
まず、３項目を挙げてみます。
# 1. 制御システムのネットワークからインターネット上のIPアドレスとICMP pingで疎通確認
疎通確認先のIPアドレスに対するゲートウェイが何に設定されているのかルーティングテーブルを確認してから、疎通確認先へping実行してください。
2. 外部との通信ルートが存在する可能性がある全てのゲートウェイ経由で確認
図１のように保守員が設置した管理外のゲートウェイがあるかもしれないので、疎通確認先のIPアドレスに該当するルーティングテーブルのゲートウェイを、候補となりそうなゲートウェイ分切り替えて、ping実行してください。
3. 疎通できる可能性あるIPアドレス・プロトコル・ポートでも確認
FWでICMPはブロックされていて、他のプロトコル・ポートは通過できるかもしれないため、DNS(UDP/53)、HTTP(TCP/80)、HTTPS(TCP/443)等でも疎通確認してみてください。
以上に記載している内容が理解出来て実践できる方は、実践してみてください。
上記では、難しいと感じる方へ、まずは、自宅のPCで手順と仕組みを理解
ここからは、噛み砕いて順を追って説明します。 いきなり制御システム上で試す前に、まずは、インターネットと接続している自宅のPCを使って確認手順と仕組みを理解しましょう。Windowsを例に説明します。
1. 自宅のネットワークのPCからインターネット上のIPアドレスとICMP pingで疎通確認
ゲートウェイの仕組み理解
外部のネットワークと通信をする際は、PCと同じネットワーク上にあるゲートウェイを介して通信が行われます。家庭であればホームルータなどがゲートウェイとなっています。PCが通信する時にどのゲートウェイを介して通信を行うかをPC内にルーティングテーブルとして記憶しているため、まずはrouteコマンドでルーティングテーブルの内容を確認してみましょう。
C:¥> route print -4
宛先IPアドレスを指定して通信を行うとき、PC上に記憶されたルーティングテーブルを参照し、宛先IPアドレスが該当する「ネットワーク宛先」を見つけ、その行に記載された「ゲートウェイ」を介して通信を行います。この例では、インターネット（ネットワーク宛先0.0.0.0ネットマスク0.0.0.0）との通信は、PCの「インターフェイス」192.168.10.145から、「ゲートウェイ」192.168.10.1を介して行う状態となっています。
デフォルトゲートウェイとゲートウェイ
例えば宛先8.8.8.8と通信する場合、ルーティングテーブルの「ネットワーク宛先」列に8.8.8.8に該当する行がある場合は、8.8.8.8宛の通信は、この行に記載の「インタフェース」から「ゲートウェイ」を介して通信が行われます。一方で、「ネットワーク宛先」列に8.8.8.8に該当する行がない場合は、先頭行「ネットワーク宛先」0.0.0.0の行の「ゲートウェイ」を介して通信が行われます。0.0.0.0の行に記載されたゲートウェイをデフォルトゲートウェイと呼びます。通常家庭では、8.8.8.8などインターネット上の個別の宛先IPアドレスがルーティングテーブル上の「ネットワーク宛先」に設定されていることはないため、インターネットとの通信はデフォルトゲートウェイのルールが適用されます。
ICMP ping で疎通確認する方法
ゲートウェイの仕組みを確認したので、インターネット上でping応答を返す適当な宛先IPと疎通確認してみます。ここでは、googleが提供するDNSサーバ(8.8.8.8)を指定し、pingコマンドを使って疎通確認してみます。
C:¥> ping 8.8.8.8
応答が返ってきていることがわかります。つまり、ゲートウェイ(192.168.10.1)を介してインターネット上の宛先(8.8.8.8)と疎通できたということです。ポイントは、同じネットワーク上にあるゲートウェイを経由して、インターネットと通信しているということです。
2. 外部との通信ルートが存在する可能性がある全てのゲートウェイ経由で確認
ゲートウェイを手動で設定する方法
外部との通信ルートが存在する可能性がある全てのゲートウェイといっても、家庭ではゲートウェイとなる候補の装置は1つなのが通常です。ただし、後ほど制御システムで、複数のゲートウェイを切り替えて疎通確認することを想定し、手動でゲートウェイを設定する方法を確認してみましょう。ゲートウェイの設定には管理者権限が必要なので、以降のコマンドは管理者として実行してください。 それでは、routeコマンドで、ルーティングテーブルに「ネットワーク宛先」8.8.8.8の「ゲートウェイ」として192.168.10.1を追加して、ルーティングテーブルを確認してみます。
C:¥>route add 8.8.8.8 192.168.10.1
C:¥>route print -4
ルーティングテーブルを見ると、「ネットワーク宛先」8.8.8.8の「ゲートウェイ」が192.168.10.1であるという行が追加されたことがわかります。 この状態で、8.8.8.8へpingをしてみましょう。
C:¥>ping 8.8.8.8
ping応答が帰ってきて疎通ができていることがわかります。「ゲートウェイ」192.168.10.1を介してインターネット上の8.8.8.8と疎通できたというわけです。
変更した設定は元に戻す
「さあ、自宅での確認はここまでです、制御システムの確認に進んでください。」と言いたいところですが、制御システムを触る前の心構えとして最も重要な手順が抜けています。制御システムでは可用性が重視されます。このため作業の後始末と後始末の確認が必須事項となります。
今回の作業では、ルーティングテーブルを追加しているので、後始末としてルーティングテーブルを削除し、削除できたか確認しましょう。
C:¥>route delete 8.8.8.8
C:¥>route print -4
たしかにルーティングテーブルから「ネットワーク宛先」8.8.8.8の行が消えていますね。 「さあ、自宅での確認はここまでです、制御システムの確認に進んでください。」
余談：本当にネットワーク宛先8.8.8.8の行が使われているのか確認したい方へ
先ほどping確認した時のルーティングテーブルを見て、「ネットワーク宛先」0.0.0.0の行と、「ネットワーク宛先」8.8.8.8の行が両方存在した時に、どちらの情報が今回の通信に使われたのか？と疑問を持った方がいると思います。ルーティングテーブルの仕組みではより詳細に「ネットワーク宛先」が指定されている行が優先されるので8.8.8.8の行が優先ですがルーティングテーブルを見ても本当かわかりません。本当か確かめたい方は以下の実験をしてみてください。
「ネットワーク宛先」8.8.8.8の「ゲートウェイ」を、ゲートウェイ機能を持たない機器のIPアドレスに変更してpingを確認してみましょう。ここでは、たまたま同じネットワークに接続していた他のPCのIPアドレス192.168.10.108を指定してみます(同じネットワークにつながっていればIoT機器や携帯電話などでもよいです）。
C:¥>route add 8.8.8.8 192.168.10.108
C:¥>route print -4
ルーティングテーブルを見ると、「ネットワーク宛先」8.8.8.8のゲートウェイが192.168.10.108という行が追加されたことがわかります。この状態で、8.8.8.8へpingをしてみましょう。
要求がタイムアウトしており疎通できていないことがわかります。192.168.10.108の機器はゲートウェイ機能をもたないためインターネットへ通信が失敗したのです。これで確かに8.8.8.8の行が優先して使われていたことがわかりました。
なお、確認が終わった後は、追加したルーティング情報を消してください。後始末は忘れずに！ということを習慣づけてください。
制御システムのネットワークで確認
自宅で手順を確認できたら、制御システムのネットワークで確認してみてください。 行うことは基本的に自宅と変わりませんが、制御システムで確認する上で気をつける事項も追加して、全体の流れを記載します。
勝手にやらない。実施してよいか関係者へ確認
くれぐれも関係者に無断で勝手に行わないでください。作業ミスを起こさないように手順作成・確認し慎重に行う事はもちろんですが、セキュリティ対策への取り組みが積極的な組織ではSoC(セキュリティオペレーションセンター）などで通信パケットを監視していて、通常発生しない通信を検知して驚いてしまうかもしれません。
どのネットワークから実施するか決定
保守作業を行うときに使用してよい端末は決まっていると思うため、その端末を利用して実施してください。 なお、Windowsでの手順を記載しましたが、Linuxの端末から実施したい場合は、コマンドや設定画面は異なっても手順の流れは同じですので、Windowsの手順を参考に詳細手順はご自身で調べてください。
ゲートウェイとなりそうな装置のIPアドレスを確認
図１のように保守員が設置した管理外のゲートウェイがあるかもしれないので、候補となりそうなIPアドレス（例えばネットマスクが255.255.255.0のセグメントであればX.X.X.1〜254）の254台に対してpingを行なってください。ここでは、制御システムのネットワークが192.168.10.0/24であった場合のコマンドを記載します。
pingを行った後、arpコマンドでarpテーブルを確認してIPアドレスを抽出してください。
arpテーブルに表示したIPアドレスが、192.168.10.0/24のネットワークに接続している機器でありゲートウェイ候補となる可能性があるIPアドレスです。 なお、ping応答結果だけで確認せずarpテーブルで確認するのはpingに応答しない設定がされている機器もあるためです。
外部との通信ルートが存在する可能性がある全てのゲートウェイ経由で確認
外部との通信ルートが存在する可能性があるゲートウェイを順番に「ネットワーク宛先」8.8.8.8のゲートウェイとしてルーティングテーブルに設定しなおして、pingで疎通確認してください。このときarpテーブルに表示した全てのIPアドレスを手動で試すことは手間もかかるのでスクリプト化して自動でためすことを推奨します。自動化は手間なので簡易的に手動で試すというのであれば、最低限あやしい装置のIPアドレスをゲートウェイに設定して試すことをお勧めします。どれがあやしいかわからない場合は、ルータ、FWなどの通信機器や複数ネットワークに接続してルーティング設定したサーバなど、複数ネットワークに接続する機器は候補にいれることをお勧めします。特に、何者か不明のIPアドレスはあやしいので候補に入れると良いです。
インターネットと疎通できないはずであった制御システムにおいて、インターネットと疎通できた場合は、それでセキュリティ上問題ないのか関係者と相談してください。
変更した設定は元に戻す
確認作業のために、ゲートウェイの設定を変更するなど何か変更した場合は、必ず作業後に元に戻して、戻し忘れがないことを確認してください。
もう少し深掘り 3. 疎通できる可能性あるプロトコル・ポートで確認。
ここまでのpingでの確認は、ICMPというプロトコルで確認したものです。ブラウザでよく利用されるプロトコル・ポートはHTTPS(TCPプロトコルの443番ポート)なのでブラウザでインターネット上のサイト(例: https://www.google.com)が見れるか確認してみてください。制御システムの装置から、ブラウザで任意のサイトを表示できたら、何かの際にうっかりマルウェアをダウンロードしてしまう心配など、この環境あぶなくないかな？ と感じるのではないでしょうか？ google.comのようにURL指定でアクセスする場合は名前解決が行えない環境では、URLに該当するIPアドレスがわからないため宛先のIPアドレスにアクセスできず表示できません。
DNSによる名前解決は、端末に問い合わせ先のDNSサーバが設定してあり、端末からDNSサーバにURLに対応するIPアドレスを問い合わせることで行われます。端末にDNSサーバが設定されていない場合は名前解決が行えないためURL指定でブラウザにて表示できませんが、コマンドにてDNSサーバを明示的に指定すれば疎通確認は行える場合もあります。では、明示的にDNSサーバをgoogleが提供する8.8.8.8に指定して、google.comの名前解決を行ってみましょう。
C:¥>nslookup google.com 8.8.8.8
172.217.26.238というIPアドレスが表示したということは名前解決が行えたということなので、8.8.8.8とDNS(UDP/53)で疎通ができているということになります。 次に、ブラウザでURL部をIPアドレスに置き換えて https://172.217.26.238 を指定して表示してみてください。
上記のとおり、警告表示画面が表示すれば、172.217.26.238とhttps(tcp/443)で疎通は行えているということを意味しています。
なお、ここまでは、DNSとHTTPSの疎通確認を行っていますが、HTTPS単体で疎通確認したい場合は、CLOUDFLAREが提供している https://1.1.1.1 にアクセスしてみてください。
このように表示した場合は、1.1.1.1とHTTPS(TCP/443)で疎通できているということを意味しています。
まとめ
はじめに「セキュリティ対策をしていても有効性を確認していないとしたら、それは不思議なことなのではないか？」という問題提起を行い、１つ目のテーマとして、「制御システムからインターネットへ疎通できるか確認する方法」を紹介しました。
こんな風にドアノブをガチャガチャして、自ら考えてみようとすることがセキュリティ意識向上の第一歩な気がします。本稿を読んで、セキュリティ対策の有効性の確認について改めて考えていただければ幸いです。
もし、意図しないインターネット接続がみつかったら… その先、どんな攻撃が考えられるでしょう？もっとガチャガチャしたくなったあなた、続編を乞うご期待ください。
PR
本格的に確認されたいという方は、ペネトレーションテストをご検討ください。サイバーディフェンス研究所では制御システムぺネトレーションテストに限らず、さまざまなセキュリティ診断を行っています。
おまけ
本記事に込めた想いや、想定される多数のツッコミに対する FAQ など、筆を進めたところ本文超える量になりそうなので制御システムのドアノブ、ガチャガチャしてますか？[OTセキュリティ:システム開発とぺネトレーションテストをしてきて思うこと]として別記事としました。よろしければ、こちらもみてください。