vCenter Server Management の Firewall でアクセス制御を試す

概要

vCenter Server Appliance (VCSA) に標準搭載されている簡易ファイアウォール機能を使い、特定 IP からのアクセスを拒否する設定を実際に投入してみる。GUI での操作から、裏側で生成される iptables ルール、そして通信方向ごとの挙動を確認した。

1. VAMI ファイアウォールとは

vCenter は簡易的なアクセス制御機能を搭載しており、特定の IP アドレスやサブネットからのアクセスを許可・拒否できます。設定は vCenter Server Management Interface（VAMI、https://<appliance>:5480）の Firewall メニューから行います。[1]

これは環境内にファイアウォールを持たないフラットなネットワークでも、vCenterへのアクセスを制御できるという、セキュリティ観点では意外と有用な機能です。踏み台（ジャンプホスト）や管理セグメントからのみアクセスを許し、それ以外を遮断する、といった用途に使えます。[2]

ポート単位の制御はできない

この機能はあくまでネットワーク層（送信元 IP／サブネット）でのフィルタです。「443 だけ許可」「22 だけ拒否」といったポート単位の制御はできず、ルールはその NIC に届くすべてのトラフィックに一律で適用されます。SSH だけ絞りたい、GUI は全体公開したい、といった要件は VAMI 単体では実現できないため、外部 L4 ファイアウォールや NSX 側で行う必要があります。[3]

2. VAMI GUI での設定手順

VAMI の Firewall 画面では、ルールを上から順に評価します。今回は例として、送信元 192.168.80.253/32 からのアクセスを拒否（Reject）するルールを 1 件投入しました。

  1. ①ブラウザで https://<appliance-IP-or-FQDN>:5480 にアクセスし、root でログイン（vCenter SSO の SystemConfiguration.Administrators グループのメンバーである必要があります）。
  2. ②左メニューの Firewall を開き、ADD をクリック。
  3. ③ルールを指定する。
    Network Interface: nic0 ／ IP Address: 192.168.80.253 ／ Subnet Prefix Length: 32（単一 IP の場合）／ Action: Reject。
  4. ④SAVE をクリックして保存。必要に応じて REORDER でルールの評価順を調整。

Action には Accept（許可）／Ignore（黙って破棄＝DROP 相当）／Reject（拒否応答を返す）／Return（既定ルールに委ねる）の 4 種類があります。[1]


図 1: VAMI GUI の Firewall 画面。192.168.80.253/32 に対する Reject ルールを 1 件登録した状態

3. iptables への反映内容

VCSA は Linux ベースであり、VAMI で設定した内容は最終的に OS の iptables ルールとして書き込まれます。SSH で VCSA にログインし iptables -L を実行すると、以下のように該当 IP を拒否するルールが確認できます（抜粋・要点にコメントを付与）。

root@sb-e560f-vcsa [ ~ ]# iptables -L

Chain INPUT (policy DROP)              # 既定は DROP（明示的に許可された通信のみ通す）
target      prot opt source        destination
ACCEPT      all  --  anywhere      anywhere
DROP        all  --  anywhere      anywhere      ctstate INVALID
ACCEPT      all  --  anywhere      anywhere      ctstate RELATED,ESTABLISHED  # 戻り通信は許可
inbound     all  --  anywhere      anywhere      # ユーザー定義ルールへ分岐
port_filter all  --  anywhere      anywhere
...

Chain FORWARD (policy DROP)

Chain OUTPUT (policy ACCEPT)           # 送信（自ホスト発）は既定 ACCEPT
target        prot opt source     destination
ACCEPT        all  --  anywhere   anywhere      ctstate RELATED,ESTABLISHED
output_remote all  --  anywhere   anywhere
output_local_443 tcp -- anywhere   anywhere     tcp dpt:https  # 443 宛は UID 別に制限

Chain inbound (1 references)           # ← VAMI で作った拒否ルールはここ
target  prot opt source           destination
REJECT  all  --  192.168.80.253   anywhere      reject-with icmp-port-unreachable
RETURN  all  --  anywhere         anywhere

Chain log_reject (18 references)
LOG     all  --  anywhere  anywhere  LOG level debug prefix "iptables rejected by VSR "
REJECT  all  --  anywhere  anywhere  reject-with icmp-port-unreachable

Chain output_local_443 (1 references) # 443 宛 outbound を許可する UID の一覧
ACCEPT  all  --  anywhere  anywhere  owner UID match envoy
ACCEPT  all  --  anywhere  anywhere  owner UID match vpxd
ACCEPT  all  --  anywhere  anywhere  owner UID match content-library
ACCEPT  all  --  anywhere  anywhere  owner UID match vsphere-ui
...   (vmcam / lookupsvc / trustmanagement / sso-user / updatemgr / root ほか)
log_reject all -- anywhere anywhere  # 上記 UID 以外は log_reject へ

ポイントは次のとおりです。VAMI のルールは inbound チェインに REJECT ... reject-with icmp-port-unreachable として追加されます。INPUT チェインの既定ポリシーが DROP、OUTPUT は ACCEPT になっている点が、次章の挙動を理解する鍵になります。[4]

⚠ iptables を手動で編集・有効化しない

ルールはあくまで VAMI 経由で管理します。iptables サービスをコマンドラインから手動で有効化すると、vCenter のサービスは起動していても Web UI にアクセスできなくなる事象が報告されています。[5]

4. 通信の挙動

この iptables に設定された該当 IP（192.168.80.253）に対する通信の挙動は、方向によって異なります。既定ポリシー（INPUT=DROP／OUTPUT=ACCEPT）と、追加された REJECT ルールの組み合わせで、次のように整理できます。

通信方向結果理由
192.168.80.253 → このホスト の新規通信拒否inbound チェインの送信元 IP 一致ルール（REJECT）にマッチ
このホスト → 192.168.80.253 の新規通信概ね許可OUTPUT の既定ポリシーが ACCEPT のため
このホスト → 192.168.80.253 の一部通信拒否あり特定 UID / 443 宛通信の制限（output_local_443 で許可 UID 以外は log_reject 行き）
このホスト発通信の戻り通信許可ctstate RELATED,ESTABLISHED にマッチするため

つまり、拒否ルールは「その IP から VCSA へ向かう新規のインバウンド通信」を止めるものです。VCSA 自身がその IP へ発信するアウトバウンドは、既定で許可されたままである点に注意が必要です（443 宛など一部は UID ベースで別途制限されます）。

5. 拒否時の応答（ICMP port-unreachable）

Action が Reject の場合、拒否された通信に対して VCSA は ICMP port-unreachable（type 3 / code 3）を返します。これは iptables の reject-with icmp-port-unreachable の挙動によるものです。[6]

Reject と Ignore（DROP）の違い

Reject は「拒否した」という ICMP 応答を返すため、送信元にはポートが閉じていることが即座に伝わります。一方 Ignore（DROP 相当）はパケットを黙って破棄し、何も返しません。応答有無でスキャン耐性やタイムアウト挙動が変わるため、要件に応じて使い分けます。

6. 使う前に押さえる注意点

手軽な機能ですが、設定ミスがそのまま「vCenter への締め出し」に直結します。実運用に投入する前に、以下の確認が重要です。

ルールは上から順に評価される

vCenter はルールを上から順に処理し、最初にマッチしたものを適用します。「特定 IP／サブネットだけ許可し、それ以外を拒否」する場合は、Allow ルールを先に、Reject ルールを後に配置する必要があります。順序が逆だと許可したい相手まで拒否されます。[7]

⚠ 締め出しを防ぐ
  • Reject ルールを入れる前に、管理端末・踏み台の IP を許可する Allow ルールを先に作成する。
  • 「全拒否」を意図して 0.0.0.0/0 Reject を入れる場合、ESXi ホストの管理 IP・vSAN VMkernel・DNS/NTP・バックアップ/監視・vCenter HA 等をすべて許可リストに含める。含め忘れると連携が壊れます。[8]
  • サブネットプレフィックス長の指定ミス（例: /24 のつもりで /0）で全遮断してしまう事故が多いので、保存前に必ず確認する。

作業前にスナップショットを取得する

設定変更前にオフラインスナップショットの取得が推奨されます。Enhanced Linked Mode (ELM) 構成の場合は、ELM 内のすべての vCenter を停止したうえでスナップショットを取得します。[9]

複数 NIC 環境ではインターフェースごとに設定

VCSA が管理用（nic0）・vSAN・vSphere HA 用など複数の NIC を持つ場合、rhttpproxy や vpxd が待ち受ける各インターフェースに対して許可／拒否ルールを適用する必要があります。[8]

7. ロックアウト時の復旧

誤って自分の IP を拒否し VAMI にアクセスできなくなった場合でも、VM コンソール経由で復旧できます。手順の概略は次のとおりです。[10]

  1. vSphere Client などから VCSA VM のコンソールを開く（VAMI がダメでもコンソールは使える）。
  2. Alt + F1 でコンソールログインし、root でログイン。必要なら Troubleshooting Mode から Bash Shell を有効化。
  3. appliance shell で全ファイアウォールルールを削除:
    appliancesh → com.vmware.appliance.version1.networking.firewall.addr.inbound.delete --all true
  4. 削除を確認（...inbound.list で出力が空になればOK）。VAMI へ再アクセスできるようになる。
補足: iptables を直接クリアする場合

ホームラボ等でより低レベルに戻したい場合は、コンソールから iptables -F / iptables -X と各チェインの既定ポリシーを ACCEPT に戻す方法もあります。ただし本番環境では前述の appliance shell 経由の削除が安全です。

8. まとめ

VAMI の Firewall 機能は、GUI から数クリックで vCenter への到達 IP を絞れる手軽なアクセス制御です。実体は VCSA 内の iptables（inbound チェインの REJECT ルール）であり、拒否時には ICMP port-unreachable を返します。挙動は方向依存で、止まるのは「相手→VCSA の新規インバウンド」であり、VCSA からのアウトバウンドは既定で許可されたままです。

一方で、ポート単位の制御ができない・ルール順序が結果を左右する・設定ミスで自分を締め出しやすい、という制約もあります。運用では「スナップショット取得 → Allow を先に → Reject を後に → 保存前に IP とプレフィックスを再確認」を徹底し、ポート単位の要件は外部ファイアウォールや NSX 側で補完するのが安全です。

参考リンク
  1. Edit the Firewall Settings — Broadcom TechDocs (vSphere 8.0)
  2. vCenter Security Bug Workaround with vCenter Firewall Configuration
  3. Restricting SSH Access to vCenter Server While Maintaining Global GUI Access (KB 437359)
  4. Troubleshooting packet drops on the vCenter Server firewall (KB 418941)
  5. ICMP timestamp Type 13/14 observed on vCenter Server (KB 308835)
  6. iptables REJECT default = icmp port-unreachable (type 3/3)
  7. vCenter firewall configuration considerations (KB 393717)
  8. How to Block All Traffic on vCenter except for Specific IPs/Subnets (KB 377036)
  9. Configure the VAMI firewall to restrict vCenter access to specified IPs/subnets (KB 412016)
  10. Remove VAMI firewall rule when client IP is blocked by it (KB 388934)

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む