はじめての「ヤマハ vRX さくらのクラウド版」(4)入出力を観測

この連載では、ヤマハ 仮想ルーター vRXをさくらのクラウドで検証する環境を構築いたします。「ヤマハ vRX さくらのクラウド版」がどのように動作するのかや検証費用について説明していきます。皆さんも検証環境を作って、いろいろ試してみてください。
今回は、第2回で作成した「ヤマハ 仮想ルーター vRX」への入出力を観測します。入出力の観察にはパケットフィルター機能を利用(流用?)します。観測するパケットの種類に応じて、イーサネット、IPv4、IPv6のパケットフィルターで観測します。
パケットフィルターは「特定のパケットを破棄する」というイメージがありますが、「必要なパケットを通す」という機能もあります。また、精査したパケットのログを取るという機能があります。「すべてのパケットを通し、ログを取る」というパケットフィルターを作ってあげれば、入出力を観測できます。
目次
vRXを起動する
検証を開始する前に、コントロールパネルを開いて、vRXを起動します。
- 第2回の「コントロールパネルを開く」を参考にコントロールパネルを開きます。
- 第2回の「vRXの起動」を参考にvRXを起動します。
2回目以降のログイン
コンソールからログインします。手順は以下の通りです。
- ユーザー名とパスワードを入力します。初期ログイン時にユーザー名を変更している場合は新しいユーザー名でログインします。
- administratorコマンドで管理ユーザーに昇格します。
- show configコマンドを実行して設定内容を確認します。
なお、2回目以降のログインにおいては強制的なパスワード変更がありません。
ログイン後に実行するコマンドは次の通りです。(コマンド入力においては補完機能が働きます)
# administrator
# show config
コンソール操作の画面を以下に示します。こちらの画面では、ログインして管理ユーザーに昇格して設定内容を確認しています。
ヤマハの公開情報 |
---|
→ → administrator |
→ → show config |
イーサネットフィルターを使って通信ログを見る
イーサネットフレームのフィルター機能を利用して、入出力を観測します。
「すべてのパケットを通過させてログを記録する( pass-log * * )」という定義をして、LAN1の入力と出力に適用します。NOTICEタイプのSYSLOGをONにして、フィルターログを記録させます。
設定するコマンドは次の通りです。
... <<<イーサネットフィルターを設定する>>>
# ethernet filter 1 pass-log * *
# ethernet lan1 secure filter in 1
# ethernet lan1 secure filter out 1
# syslog notice on
... <<<ログをクリアする>>>
# clear log
... <<<パケットの入出力を観測する>>>
# show log
... <<<イーサネットフィルターを削除する>>>
# no ethernet filter 1
# no ethernet lan1 secure filter in
# no ethernet lan1 secure filter out
# no syslog notice
- キーワード(黒字)の部分には補完機能が働きます。
- インターフェース名(緑字)は、lan1/lan2などの物理インターフェースやトンネルインターフェースなどの名前を設定環境に合わせて指定します。今回はlan1を指定します。
- フィルター番号(赤字)は、静的フィルター番号(数字)を空白で区切って並べます。今回は"1"を一つ指定します。
コンソール操作の画面を以下に示します。
1. イーサネットパケットの記録を取るフィルターを設定します。
2. 記録されたログを確認します。
なお、ログに出力されているMacアドレスの一部を隠しています。それらのうち、vRX、GW、server A-Jについてはそれぞれ以下を表しています。
- vRX:vRXのMacアドレスの一部です。
- GW:このセグメントのゲートウェイ機器のMacアドレスの一部です。
- server A-J:同一セグメント内に存在するサーバーのMacアドレスの一部です。
3. イーサネットパケットの記録を取るフィルターを削除します。
ヤマハの公開情報 |
---|
→ → ethernet filter |
→ → ethernet lan1 secure filter in |
→ → ethernet lan1 secure filter out |
→ → syslog notice |
→ → clear log |
→ → show log |
イーサネットフィルターの観測まとめ
コンソール画面に表示された実行結果を観測してみると、当初の想定とは異なるものがいろいろと見えてきます。本来見えるものとしては以下を想定していました。
- 他のサーバーが発行したブロードキャストパケット:宛先MACアドレスが"FF:FF:FF:FF:FF:FF"など
- ゲートウェイ(GW)からvRXに対するユニキャストパケット:宛先MACアドレスがvRX自身
- vRXからGWに対するユニキャストパケット:発信元MACアドレスがvRX自身
- サーバー間通信は本来発生しないはず(見えないはず)
ところが、実際に見えたものをまとめると以下のようになります。
- GWのMAC Address Prefixは00:00:5eです。これはGWと通信後、show arpコマンドで表示されたIPアドレスとMACアドレスの対応表で確認できます。
- 同一セグメント内で稼働するサーバーからブロードキャストでARPが発信されています。宛先のMacアドレスが"ff:ff:ff:ff:ff:ffとなっているのがそれです。同一セグメントに複数台のサーバーが同居していることもわかります。
- Juniper Networksの装置(MAC AddressのPrefix = 40:de:ad)が、定期的に同一セグメント内へARPを発行しています。何をしているのかはわかりません。
IPv4パケットフィルターを使って通信ログを見る
IPv4パケットのフィルター機能を利用して入出力を観測します。
こちらも前項と同様に「すべてのパケットを通過させてログを記録する( pass-log * * * * * )」という定義をして、LAN1の入力と出力に適用します。NOTICEタイプのSYSLOGをONにして、フィルターログを記録させます。
設定するコマンドは次の通りです。
... <<<IPv4フィルターを設定する>>>
# ip filter 1 pass-log * * * * *
# ip lan1 secure filter in 1
# ip lan1 secure filter out 1
# syslog notice on
... <<<ログをクリアする>>>
# clear log
... <<<パケットの入出力を観測する>>>
# show log
... <<<IPv4フィルターを削除する>>>
# no ip filter 1
# no ip lan1 secure filter in
# no ip lan1 secure filter out
# no syslog notice
コンソール操作の例を以下に示します。
1. IPv4パケットの記録を取るフィルターを設定します。
2. 記録されたログを確認します。
3. IPv4パケットの記録を取るフィルターを削除します。
IPv4フィルターの観測まとめ
こちらもコンソール画面に出力されたログを観察した結果をまとめます。まず、本来見えるものとしては以下を想定していました。
- GWを経由したインターネットからvRXに対するIPv4通信:宛先アドレスがvRX自身
- vRXからGWを経由したインターネットへのIPv4通信(返信):発信元アドレスがvRX自身
- よく見かけるスキャンの例:23/TCP、8728/TCP、22/TCP、8080/TCP、80/TCP、ICMP等
これに対して実際に観測された事象としては、vRXの特定のポートを狙ったパケットが届いていて、それに対してvRXが何らかの返事をしているというものです。脆弱性を突こうとしているのかもしれません。
パケットが届いたポートとしては以下が挙げられます。
show log 結果から抜粋 | 攻撃対象アプリケーション |
---|---|
UDP : 56455 >1900 | UDP 1900(SSDP→UPnP) |
TCP : 43285 > 5005 | TCP 5005(RTCP) |
TCP : 7821 > 7001 | TCP 7001(Oracle WebLogicシリーズ(旧:BEA WebLogicシリーズ)) |
UDP : 38829 >161 | UDP 161 (SNMP) |
TCP : 8080 > 6267 | TCP 6267(不明) |
TCP : 54594 > 1433 | TCP 1433(MSSQLサーバー) |
TCP : 38581 > 8728 | TCP 8728(MikroTik製ルーターの管理API) |
TCP : 43131 > 6494 | TCP 6494 (不明) |
攻撃対象アプリケーションの正式名称を以下に記載しておきます。
- SSDP: Simple Service Discovery Protocol
- UPnP: Universal Plug and Play
- RTCP: Real-time Transport Protocol control protocol
- SNMP: Simple Network Management Protocol
- MSSQL: Microsoft SQL Server database management system
vRXがどのような返事をしているのかはログからはわかりませんが気になるところです。ポートスキャンなどの怪しい接続に対しては応答しないのが望ましいです。次回以降の記事でvRXの挙動を確認します。
ヤマハの公開情報 |
---|
→ → ip filter |
→ → ip lan1 secure filter in |
→ → ip lan1 secure filter out |
→ → syslog notice |
サービスやスキャンの情報 | ポート番号 |
---|---|
サービス概要およびネットワーク ポート要件 - Windows Server | Microsoft Learn | SNMP(UDP 161) SMB(TCP 445) RTCP(TCP 5005) SSDP(UDP 1900) Microsoft SQL Server(TCP 1433) など |
【セキュリティ ニュース】「Mirai」と異なるボット、国内ベンダーのルータに感染拡大か(1ページ目 / 全2ページ):Security NEXT | telnet(TCP 23) MikroTik製ルータの管理API(TCP 8728) Redis(TCP 6379) |
警察庁、システムを探る4種類の不審な通信に注意喚起 - ZDNET Japan | Redis(TCP 6379) Oracle Weblogic Server(TCP 7001) Drupal Cisco Smart Install Client(TCP 4786) |
IPv6パケットフィルターを使って通信ログを見る
今度はIPv6パケットのフィルター機能を利用して入出力を観測します。
こちらも「すべてのパケットを通過させてログを記録する( pass-log * * * * * )」という定義をして、LAN1の入力と出力に適用します。NOTICEタイプのSYSLOGをONにして、フィルターログを記録させます。
設定するコマンドは次の通りです。
... <<<IPv6フィルターを設定する>>>
# ipv6 filter 1 pass-log * * * * *
# ipv6 lan1 secure filter in 1
# ipv6 lan1 secure filter out 1
# syslog notice on
... <<<ログをクリアする>>>
# clear log
... <<<パケットの入出力を観測する>>>
# show log
... <<<IPv6フィルターを削除する>>>
# no ipv6 filter 1
# no ipv6 lan1 secure filter in
# no ipv6 lan1 secure filter out
# no syslog notice
コンソール操作の画面を以下に示します。
1. IPv6パケットの記録を取るフィルターを設定します。
2. 記録されたログを確認します。
3. IPv6パケットの記録を取るフィルターを削除します。
ヤマハの公開情報 |
---|
→ → ipv6 filter |
→ → ipv6 lan1 secure filter in |
→ → ipv6 lan1 secure filter out |
→ → syslog notice |
IPv6フィルターの観測まとめ
こちらもログを観察してわかったことを記載します。本来見えるものとしては以下を想定していました。
- GWを経由したインターネットからvRXに対するIPv4通信:宛先アドレスがvRX自身
- vRXからGWを経由したインターネットへのIPv4通信(返信):発信元アドレスがvRX自身
- しかし、vRX自身のIPv6アドレスを設定していないので、何も届かないはず
これに対して、実際に見えたものは以下の通りです。
- 想定通り、IPv6パケットを検出できませんでした。
- 検出したい場合はIPv6アドレスを設定してください。
[参考] 不必要な通信を破棄する設定
ここまでは、「通過したすべてのパケットのログを採る」ために「pass-log」を使用してきました。これに対してパケットを破棄するフィルタリングは、このキーワードを「reject」や「reject-log」に変更します。
すべてを破棄するフィルター定義は次の通りです。
... <<<破棄するフィルター定義に差し替える>>>
# ip filter 1 reject-log * * * * *
# Ipv6 filter 1 reject-log * * * * *
# ethernet filter 1 reject-log * * *
セキュリティー対策のパケットフィルタリングは、「破棄する定義(穴を塞ぐ)」と「通過させる定義(穴を開ける)」を組み合わせて構築します。それについてもいずれ検証します。
関連リンク
vRXで利用できるコマンド操作に関連する公式情報です。
vRXをシャットダウンする
検証が終わったら、コントロールパネルを開いて、vRXをシャットダウンします。
- 第2回の「コントロールパネルを開く」を参考にコントロールパネルの開きます。
- 第2回の「vRXのシャットダウン」を参考にvRXを停止します。
検証経費
第4回で検証したサーバとvRXに関する費用は次の通りです。
項目 | 経費 |
---|---|
vRXを動作させる仮想マシン | 起動からシャットダウンまでの稼働時間に応じた課金が発生 |
vRXのアーカイブ | 今回の動作確認だけなら費用は発生しません |
vRXのライセンス | 今回の動作確認だけなら費用は発生しません |
連載トップへのリンク
連載回数番号 | リンク |
---|---|
第1回 | はじめる前に |
第2回 | インストールとシャットダウン |
第3回 | 初期設定 |
※画面キャプチャーなどは、2025年1月時点のものです。