Tutoriel Linux

ProxmoxのVMまたはCTのファイアウォールルール

DébutantPublié par Julien Macé le 2 min de lecture

あなたのウェブVMはまだ応答していますが、広すぎるルールが不必要なサービスをオープンしたり、SSHを切断したりする瞬間に到達します。

Proxmoxのファイアウォールはすでにアクティブで、質問は明確になります：VM、ノード、またはゲストOSのレベルで書く必要がありますか？

VMまたはコンテナの場合、ゲストとその実際のフローから始めます。

net0のオプションを読み取り、INルールを構築し、OUTの運命を決定し、グループ化する価値のあるルールのみをファクタリングします。Proxmoxのコントロールとアプリケーションテストは、ホストのファイアウォールからは分離されています。

Proxmox VMに適用されるファイアウォールルールと、入出力フロー
VM/CT Proxmoxのルールは、ゲストの実際のフローに基づいて開始し、再利用可能な場合のみファクタリングする必要があります。

最初のルールを書く前にターゲットを設定する

VMID、仮想インターフェース、ゲストのアドレス、および実際に公開されているサービスを特定します。HTTPおよびHTTPSを提供するDebian VMは、バスティオンからアクセス可能な管理コンテナと同じエントリを持っていません。

  • 実際のVMIDとnet0インターフェースをメモします；
  • 受信ポートと許可されたソースをリストします；
  • ホストへのコンソールまたは管理者アクセスを保持します；
  • Datacenter/Nodeのファイアウォールがすでに処理されていることを確認します。

ゾーンは相互に置き換えることはできません。Datacenterは再利用可能なブロックに役立ち、Nodeはホストに関連し、VM/CTはゲストへのまたはゲストからのフローをフィルタリングします。

Debianのファイアウォールは別のレイヤーに残ります。 Proxmox VEの公式ドキュメントは、この分離やIN、OUT、およびFORWARDの方向について説明しています。

ノードのファイアウォールがまだ有効になっていない場合や、Web UIまたはSSHを失うのが心配な場合は、VMのルールの手前で停止し、アクセスを失うことなくProxmoxのファイアウォールを慎重に有効にするを参照してください。

ホストのロックはここでは範囲外です。

VMとそのインターフェースのオプションを読む

書く前に、Proxmoxノードから設定を再確認します。<VMID>を自分のVMの数値IDに置き換えます：

qm config <VMID> --current

次に、VMの設定の中でenable、policy_in、policy_out、log_level_in、log_level_out、およびipfilterを確認します。

各インターフェースも独自のファイアウォールインジケータを持っています。VMの全体のオプションが機能するには、net0のフラグが無効のままであってはいけません。

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

このブロックは制限的なエントリとまだ許可された出力を示しています。これをそのままコピーするファイルではありません：値をVMに合わせて調整し、生成された設定を確認します。

ipfilterは主にインターフェース上のアドレススプーフィングを制限するために使われ、HTTPまたはSSHの許可リストを作成するためのものではありません。

本当に必要な受信フローを許可する

最初にエントリから始めます。ウェブVMの場合、SSHは通常、バスティオンまたは管理ネットワークから来ます。

ポート80と443はリバースプロキシまたはアーキテクチャで定義された公的なソースから来ます。したがって、許可ルールにはプロトコル、ポート、ソース、インターフェースを知っている場合に記載する必要があります。

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

この例では、+adminsと+reverse_proxyは別々に定義されたIPSetです。

ドキュメンタリ住所192.0.2.0/24は、例やドキュメントでネットワークを例示することができますが、実際のネットワークを表すものではありません。チュートリアルで見つけたアドレスをそのままコピーせずに、確認済みのソースに置き換えます。

特定の許可をDROPまたはREJECTポリシーの前に置きます。早すぎるグローバルリフューズは有用なルールを隠してしまいます。

単純な忘れ物がSSHを切断することになります。設計を厳密にする前に設定を確認し、ホストコンソールを常に利用可能に保ちます。

政策OUTを決定してから厳しくする

許可された出力はDNS、NTP、更新、APTリポジトリ、監視、または外部APIを機能させることができますが、他のレイヤーがそれをフィルタリングする限り。

制限された出力は正確なインベントリを要求します：最初のDNSパケットがブロックされると、VMまたはそのブリッジがダウンしているように見えます。

VMからのフロー方向例DROPでのリスク
管理のSSHIN+adminsから22/tcpへソースがリストされていない場合、アクセスは拒否されます。
HTTP/HTTPSIN+reverse_proxyから80/443へウェブサービスが到達不可能になります。
DNS解決OUTUDP/TCP 53がリゾルバーにAPTと名前による呼び出しが失敗します。
システム時間OUTUDP 123がNTPソースへ別のメカニズムが取って代わらない場合、時計がずれます。
リポジトリとAPIOUTTCP 80/443へ予定の宛先へ更新と監視が停止する可能性があります。

インベントリ中はpolicy_out: ACCEPTを許可しておくことをお勧めし、その後文書化された出力を一つずつDROPに変更します。

この選択はサービスの可用性を保護しながら構築を行います。実際にホワイトリストポリシーが必要な場合、出力ポリシーの代わりにはなりません。

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depots

名前dns_interne、ntp_interne、およびdepotsは実際のアドレスまたはグループを指す必要があります。複数のポートとエイリアスの構文は、適用前にインストールされたProxmoxのバージョンを使用して再確認してください。

再利用可能なルールをセキュリティグループでファクタリングする

セキュリティグループは、複数のVMまたはコンテナが同じ機能を共有する場合に便利です。

Proxmoxはこれをクラスターのレベルで定義し、各ゲストの設定でそのセクション[RULES]内から呼び出します。グループは、そのルールの中に挿入するまで、どのVMにも適用されません。

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

グループ内には実際に共通するルールを保持します。VM固有の例外は/etc/pve/firewall/<VMID>.fwに残ります。この分離により、管理ポートを修正するためにすべてのゲストを変更する必要がなくなります。

ソースにIPSetとエイリアスを付ける

IPSetはアドレスやネットワークをグループ化し、エイリアスはアドレスやネットワークに読みやすい名前を付けます。

ルールはソースまたは宛先にそれらを使用できます。このようにして、+adminsやdns_interneを毎回IPの列を解釈することなく再確認できます。

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

アドレス192.0.2.10、192.0.2.20、および192.0.2.21はドキュメントのプレースホルダーです。IPSetは+プレフィックスで参照され、たとえば-source +adminsのように使用されます。

このプレフィックスがない場合、Proxmoxは名前をアドレスまたはエイリアスとして読み取り、ルールは意図と一致しません。

ipfilter-net0をアプリケーションの許可リストと混同しないでください。

このIPSetはインターフェースに添付されており、ソースアドレスのスプーフィングを防ぐのに役立ちます。アプリケーションのポート443を開くことができる者を決定するわけではありません。

ポリシーを厳密にする前にルールの順序を確認する

グループルールまたはローカルルールは、期待される位置で読まれる場合にのみ効果があります。拒否の前に正確なマッチを配置し、各変更後に設定を再確認します。

読まれる順序例下に置かれたリスク
1. 明確なソースおよびポート+adminsから22/tcpのSSHバスティオンがポリシーによってブロックされる。
2. 再利用可能なグループGROUP webserverこのVM上でWebポートが閉じたままとなる。
3. 文書化された出力DNS、NTP、リポジトリサービスは開始するが、依存関係を失う。
4. デフォルトポリシーDROPまたはREJECT忘れられたすべてのフローがここに落ちる。

公式ドキュメントはIN/OUT構文、オプション--source、--dest、--dport、および--ifaceの挿入、およびセキュリティグループの挿入について説明しています。

お使いのバージョンに応じた形式を使用し、そのグループがアクティブであると仮定するのではなく、コンパイルされた設定を確認してください。

テスト中にターゲットログを有効にする

Proxmoxのロギングはデフォルトではフィルタリングされたトラフィックに対して無効です。オプションlog_level_inとlog_level_outは、VM/CTの標準ログを有効にし、ファイアウォール→ログで確認できます。

ログに追加されたレベルは、パケットを特定するために役立ちます：自動的にログに記録されるパケットの数を増やすわけではありません。

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

関心のあるフローのテスト中のみレベルを有効にし、ボリュームがうるさくなった場合はnologに戻します。

恒久的な全体のロギングは、実際の拒否を読みづらくし、運用上の雑音を増加させます。

注意：空のログは、サービスが正常に機能していることを証明するものではありません。ルール、アプリケーションの応答、および実際のソースからのネットワーク経路を確認する必要があります。

コンパイル、テスト、ロールバックを計画する

最初にノードでのファイアウォールの状態を読み取ります：

pve-firewall status
pve-firewall compile

pve-firewall statusはルールを再読み取り、コンパイルします：構文警告は、ネットワークテストの前に修正すべき問題です。

pve-firewall compileは生成された設定を見ることを可能にします。

pve-firewallの公式ドキュメントでは、pve-firewall simulateについても説明しており、ソース、宛先、ポート、およびプロトコルをシミュレートするのに役立ちますが、カーネルのルーティングやアプリケーションの動作を証明するものではありません。

最終確認は許可されたソースから始め、その後、リスクなしに使用できるソースを拒否する必要があります：

  • 予想された管理IPからのSSHにssh -vを使用；
  • リバースプロキシからのHTTPまたはHTTPSにcurl -I https://<IP_VM>を使用；
  • VMからのDNS、NTP、およびAPTの場合、policy_outが制限されている場合；
  • テストウィンドウ中にProxmoxのログを確認し、その後nologに戻します。

これらのコマンドをすでに実施したテストとして提示しないでください：これらはあなたの検証プロトコルを形成します。

予想される結果は、応答する許可された接続、失敗する禁止されたフロー、および確認されたルールとの一致したトレースです。

もしルールがVMを切断する場合、そのルールを削除するか、そのVM/CTのファイアウォールを一時的に無効にします。

DNS、NTP、または更新が破損する場合は、policy_out: ACCEPTに戻します。

正常なロールバックとしてpve-firewall stopを使用しないでください：このコマンドはホストのProxmoxルールを取り除き、サーバーを無防備にする可能性があります。

境界を明確に保つ

IPアドレスのないVM、欠落したブリッジ、または正しく転送されていないVLANは、ファイアウォールルールによって修正されることはありません。

ルールが正しいように見えてもゲストにIPがない場合は、Proxmox VMのネットワーク診断に進み、ブリッジからゲストに移動してください： VMのネットワークを復元する。

ホスト側の問題については、 サーバーへのアクセスを失わずにProxmoxブリッジを作成するが適切なレイヤーを扱っています。

バックエンドnftablesproxmox-firewallは、PVE 9.2.11のドキュメントでテックプレビューとしてマークされています。

上記の例は、標準バックエンドpve-firewallに焦点を当てています。環境がIPv6を使用している場合は、IPv4のテストから単独で結論を下すのではなく、NDPとIPv6アドレスも確認してください。