IBM Cloud Docs
ファイアウォールの管理

ファイアウォールの管理

IBM Cloud® Virtual Router Appliance (VRA) は、デバイスを経由して経路指定される VLAN を保護するファイアウォールのルールを処理することができます。

VRA 内のファイアウォールは、次の 2 つのステップに分けることができます。

  1. 1 つ以上のルール・セットの定義。
  2. インターフェイスまたはゾーンポリシーに一連のルールを適用する。 1 つのゾーンは 1 つ以上のネットワーク・インターフェースで構成されます。 ゾーン・ポリシーは、あるゾーンから別のゾーンにトラバースするトラフィックに対して定義されます。

ファイアウォールのルールが意図したとおりに機能し、新しいルールがデバイスへの管理アクセスを制限しないようにするために、ルールを作成後にテストすることが重要です。

dp0bond1 インターフェースでルールを操作中に dp0bond0 を使用してデバイスに接続することをお勧めします。 Intelligent Platform Management Interface (IPMI) を使用してコンソールに接続することもオプションです。

ステートレスとステートフル

デフォルトでは、ファイアウォールはステートレスですが、必要な場合はステートフルとして構成することができます。 ステートレス・ファイアウォールは両方向のトラフィックのルールを必要としますが、ステートフル・ファイアウォールは接続を追跡し、受け入れられたフローの戻りトラフィックを自動的に許可します。 ステートフル・ファイアウォールを構成するには、どのルールをステートフルに操作するかを指示する必要があります。

tcp、udp、または icmp の各トラフィックの「ステートフル」トラッキングを有効にするには、以下のコマンドを実行します。

set security firewall global-state-policy icmp
set security firewall global-state-policy tcp
set security firewall global-state-policy udp

global-state-policy コマンドは、対応するプロトコルを明示的に設定するファイアウォール・ルールに一致したトラフィックの状態のみを追跡することに注意してください。 以下に例を示します。

set security firewall name GLOBAL_STATELESS rule 1 action accept

GLOBAL_STATELESS が protocol tcp を指定していないため、global-state-policy tcp コマンドはこのルールに適用されません。

set security firewall name GLOBAL_STATEFUL_TCP rule 1 action accept
set security firewall name GLOBAL_STATEFUL_TCP rule 1 protocol tcp

この場合、protocol tcp が明示的に定義されます。 global-state-policy tcp コマンドは、GLOBAL_STATEFUL_TCP のルール 1 に一致するトラフィックのステートフル・トラッキングを有効にします。

個々のファイアウォール・ルールを「ステートフル」にするには、以下のようにします。

set security firewall name TEST rule 1 allow
set security firewall name TEST rule 1 state enable

これにより、TEST コマンドが存在するかどうかに関係なく、ステートフルな追跡が可能な、global-state-policy のルール 1 に一致するすべてのトラフィックのステートフル・トラッキングが有効になります。

補助されるステートフル・トラッキング用の ALG

FTP などのいくつかのプロトコルは、通常のステートフル・ファイアウォール操作が追跡できる、より複雑なセッションを利用します。 これらのプロトコルをステートフルに管理できるようにする、事前構成されたモジュールがあります。

これらの ALG モジュールは、それぞれのプロトコルを正常に使用するために必要でない限り、使用不可にすることをお勧めします。

set system alg ftp 'disable'
set system alg icmp 'disable'
set system alg pptp 'disable'
set system alg rpc 'disable'
set system alg rsh 'disable'
set system alg sip 'disable'
set system alg tftp 'disable'

ファイアウォールのルール・セット

ファイアウォールのルールは、複数のインターフェースにルールを簡単に適用させるために、指定されたセットにグループ化されます。 各ルール・セットには、デフォルトのアクションが関連付けられています。 次の例を考えてみましょう。

set security firewall name ALLOW_LEGACY default-action accept
set security firewall name ALLOW_LEGACY rule 1 action drop
set security firewall name ALLOW_LEGACY rule 1 source address network-group1
set security firewall name ALLOW_LEGACY rule 2 action drop
set security firewall name ALLOW_LEGACY rule 2 destination port 23
set security firewall name ALLOW_LEGACY rule 2 log
set security firewall name ALLOW_LEGACY rule 2 protocol tcp
set security firewall name ALLOW_LEGACY rule 2 source address network-group2

ルールセット ALLOW_LEGACY には、2つのルールが定義されている。 最初のルールは、network-group1 という名前のアドレス・グループから送信されるトラフィックをすべてドロップします。 もうひとつは、 network-group2 というアドレスグループからの、telnetポート(tcp/23)宛てのトラフィックをすべて破棄し、ログに記録する。 デフォルト・アクションは、それ以外なら何でも受け入れることを示す。 必要なトラフィックのみを許可してから、ルール・セットのデフォルト・アクションを使用して残りをブロックすることをお勧めします。

データ・センター・アクセスの許可

IBM Cloud は、データ・センター内で稼働するクライアント・サーバーにサービスとサポートを提供する多数のサブネット (プライベート・サービス・ネットワーク) をホストします。 例えば、DNS リゾルバー・サービスは 10.0.80.11 および 10.0.80.12 で実行され、デフォルトの NTP サーバーは 10.0.77.54 で実行されます。 この 3 つはすべて、 10.0.64.0/29 サービス・ネットワーク内にあります。 他のサブネットはプロビジョニングとサポート中に使用されます。 データ・センターで使用されるプライベート・サービス・ネットワークについては、 このトピック を参照してください。

ファイアウォールのルール・セットの初めに SERVICE-ALLOW のアクションを指定して、適切な accept ルールを設定することで、データ・センターへのアクセスを可能にすることができます。 ルール・セットが適用される必要がある場所は、実装されているルーティングとファイアウォール設計により異なります。

ファイアウォール・ルールを作業の重複が最小になるロケーションに設定することをお勧めします。 例えば、dp0bond0 でのバックエンド・サブネットのインバウンドを許可すると、各 VLAN 仮想インターフェースに対してバックエンド・サブネットのアウトバウンドを許可するよりも動作が少なくなります。

インターフェースごとのファイアウォール構成

VRA にファイアウォールを構成する 1 つの方法として、ファイアウォールのルール・セットを各インターフェースに適用する方法があります。 この場合、インターフェースは、内部 VLAN インターフェース (VIF) ( dp0bond0.1303 など)、外部インターフェース (dp0bond0 (プライベート) または dp0bond1 (パブリック)) のいずれか、またはトンネル・インターフェース ( tun0 または vti0 など) にすることができます。 各インターフェースには 3 個のファイアウォール割り当てがあります。

in- ファイアウォールはインターフェイスに入るパケットをフィルターする。 これらのパケットは、VRAを通過するか、VRAに向かうかのどちらかである。

out- ファイアウォールはインターフェイスから出るパケットをフィルターする。 これらのパケットは、VRAを通過するか、VRAに向かうかのどちらかである。

local- ファイアウォールは VRA 宛のパケットに対してチェックされる。 ループバック・インターフェース lo は、任意のインターフェース上のローカル・インバウンド・トラフィックをフィルタリングするために使用できます。 local に適用されたファイアウォール・フィルターおよびルール・セットは、いずれかのインターフェースに in として適用されたファイアウォール・ルール・セットの後に処理されます。

1 つのインターフェースには、各方向の複数のルール・セットを適用することができます。 これらは構成された順序で適用されます。 インターフェースごとのファイアウォールを複数使用して VRA デバイスから発信されるトラフィックにファイアウォールを適用することはできないことに注意してください。

例として、 dp0bond1 インタフェースの in オプションに ALLOW_LEGACY ルールセットを割り当てるには、コンフィグレーションコマンドを使用する：

set interfaces bonding dp0bond1 firewall in ALLOW_LEGACY

Control Plane Policing (CPP)

Control Plane Policing (CPP) は、対象のインターフェースに割り当てられるファイアウォール・ポリシーの構成をユーザーに許可し、このポリシーを VRA に入るパケットに適用することで、IBM Cloud® Virtual Router Appliance を攻撃から保護します。

CPP は、キーワード local が各種の VRA インターフェース (データ・プレーン・インターフェースやループバックなど) に割り当てられたファイアウォール・ポリシーに使用された場合に実装されます。 VRA を通るパケットに適用されるファイアウォール・ルールとは異なり、コントロール・プレーンに入るかまたはコントロール・プレーンから出るトラフィックのファイアウォール・ルールのデフォルト・アクションは Allow です。 デフォルトの動作が望ましくない場合は、ユーザーは明示ドロップ・ルールを追加する必要があります

VRA は基本的な CPP ルール・セットをテンプレートとして提供します。 以下を実行することによって、それを構成にマージできます。

vyatta@vrouter# merge /opt/vyatta/etc/cpp.conf

このルール・セットがマージされた後、CPP という名前の新規ファイアウォール・ルール・セットが追加され、ループバック・インターフェースに適用されます。 ご使用の環境に合わせてこのルール・セットを修正することをお勧めします。

CPP ルールはステートフルであってはならず、進入トラフィックのみに適用されることに注意してください。

ゾーン・ベースのファイアウォール構成

ゾーン・ベースのファイアウォール構成では、1 つ以上のインターフェースがゾーンに割り当てられ (ただし、1 つのインターフェースを複数のゾーンに割り当てることはできません)、ファイアウォール・ルール・セットが 1 つのゾーンから別のゾーンに適用されます。 単一ゾーン・ポリシーの場合、トラフィックが最初のゾーンから 2 番目のゾーンに渡されるときにフィルタリングされ、フィルタリングはアウトバウンド/出口インターフェースでのみ行われます。 ゾーンは、明示的に許可されていないトラフィックが入ってくると、これらをすべてドロップします。

インターフェイスはゾーンに属するか、インターフェイスごとのファイアウォール設定を持つかのどちらかである。

3つの部門があり、各部門が独自のVLANを持つ次のようなオフィスシナリオを考えてみましょう：

  • 部門 A - VLAN 10 および 20 (インターフェース dp0bond1.10 および dp0bond1.20)
  • 部門B - VLAN 30および40 (インターフェース dp0bond1.30 および dp0bond1.40)
  • 部門 C - VLAN 50 (インターフェース dp0bond1.50)

ゾーンは各部門用に作成することができ、その部門用のインターフェースをゾーンに追加することができます。 次の例はこれを示している：

set security zone-policy zone DEPARTMENTA interface dp0bond1.10
set security zone-policy zone DEPARTMENTA interface dp0bond1.20
set security zone-policy zone DEPARTMENTB interface dp0bond1.30
set security zone-policy zone DEPARTMENTB interface dp0bond1.40
set security zone-policy zone DEPARTMENTC interface dp0bond1.50

commit コマンドは、各ゾーンをインターフェー スとして取り込み、デフォルトのドロップ・ルールは外部からゾーンに入ろうとするトラフィックをすべて破棄します。 例として、VLAN 10 と 20 は、同じゾーン内にあるので (DEPARTMENTA) トラフィックを渡すことができますが、VLAN 10 と VLAN 30 の場合は、VLAN 30 が別のゾーン (DEPARTMENTB) 内にあるので、トラフィックを渡すことができません。

各ゾーン内のインターフェースは自由にトラフィックを渡すことができ、ルールはゾーン間の相互作用に対して定義することができます。 ルール・セットは、あるゾーンから別のゾーンへの移動の観点から構成されます。

次のコマンドは、ルールを構成する方法の一例を示しています。

set security zone-policy zone DEPARTMENTC to DEPARTMENTB firewall ALLOW_PING

このコマンドは、 DEPARTMENTC から DEPARTMENTB への移行を、 ALLOW_PING というルールセットに関連付ける。 DEPARTMENTC ゾーンから DEPARTMENTB ゾーンに入るトラフィックは、このルールセットに対してチェックされる。

このゾーン DEPARTMENTC からゾーン DEPARTMENTB への移籍は、その逆について何も述べていないことを理解することが重要である。 ゾーン DEPARTMENTB からゾーン DEPARTMENTC へのトラフィックを許可するルールがない場合、トラフィック(ICMP応答)は DEPARTMENTC のホストには戻ってこない。

ALLOW_PING は、 ゾーンのインターフェース( と )に、 ファイアウォールとして適用される。 DEPARTMENTB``dp0bond1.30 dp0bond1.40 out これはゾーンポリシーによってインストールされるため、送信元ゾーンの インターフェース(dp0bond1.50)から発生するトラフィックのみがルールセットと照合される。

ゾーン・ベースのファイアウォールの例

以下の例では、VRA をモニターし、VRA を発信しているすべてのトラフィックをデバッグするファイアウォール環境について詳しく説明します。

ルール 1 に「log」を追加すると、パフォーマンスに重大な影響を与えるため、デバッグにのみ使用する必要があります。

この例のように、パブリック・インターフェースを開いたままにしないでください。

set security zone-policy zone Public-and-VTI interface dp0bond1
set security zone-policy zone Public-and-VTI interface vti2
set security zone-policy zone Public-Inside interface dp0bond1.807
set security zone-policy zone Private-Outside interface dp0bond0
set security zone-policy zone Private-Inside interface dp0bond0.829

#ruleset to allow all statefully and log every packet
set security firewall name AllowAllLogALL rule 1 action accept
set security firewall name AllowAllLogALL rule 1 log
set security firewall name AllowAllLogALL rule 1 state enable

#security policy pair between public/IPSec and private network servers
set security zone-policy zone Public-and-VTI to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between public/IPSec and public network servers
set security zone-policy zone Public-and-VTI to Public-Inside firewall AllowAllLogALL
set security zone-policy zone Public-Inside to Public-and-VTI firewall AllowAllLogALL

#security policy pair between service networks/private outside and private network customer servers
set security zone-policy zone Private-Outside to Private-Inside firewall AllowAllLogALL
set security zone-policy zone Private-Inside to Private-Outside firewall AllowAllLogALL

ファイアウォール・ルールのトラブルシューティング

インターフェース・ベースとゾーン・ベースの両方のファイアウォール構成のトラブルシューティングを行うことができます。

インターフェース・ベースのファイアウォール構成のトラブルシューティング

チェックおよびトラブルシューティングを開始するには、以下のコマンドを実行して、ポリシーがどのように構成されているかを理解します。

  1. 各インターフェースに適用されるファイアウォール・ルール・セットとその方向を収集するには、 show configuration commands | grep firewall | grep interface を実行します。
  2. ステップ 1 の出力を使用して、 show configuration commands | grep -iE '<name of firewall ruleset>'. を実行することで、確認しようとしているフロー内のインターフェースに適用されているすべてのルールを見つけることができます。
  3. ルールを調べて、適切なサブネット、ポート、およびプロトコルが許可されていることを確認します。
    • サービス・ネットワークからプライベート・サーバーへの接続をトラブルシューティングしていて、ルール・セットが in VIF (dp0bond0.XXX) に適用されている場合は、サービス・ネットワークを宛先として定義する必要があります。 これは、トラフィックが VIF に流れるとき、つまりクライアント・サーバーがトラフィックをアウトバウンドに送信するときに発生するからです。
    • サービス・ネットワークからプライベート・サーバーへの接続をトラブルシューティングしていて、ルール・セットが VIF の out (dp0bond0.XXX) に適用されている場合は、サービス・ネットワークをソースとして定義する必要があります。 これは、トラフィックが VIF から送信されると、クライアント・サーバーに送信されるためです。
    • プライベートサーバーへのサービスネットワーク接続のトラブルシューティングを行っている場合、ルールセットが in から dp0bond0 インターフェースに適用されている場合は、サービスネットワークをソースとして定義する必要があります。 これは、 dp0bond0 インターフェースに流入するトラフィックは、通常、Vyattaの後ろにあるサーバー宛てであるためです。
    • サービス・ネットワークからプライベート・サーバーへの接続をトラブルシューティングしていて、ルール・セットが dp0bond0 インターフェースの out 適用されている場合は、サービス・ネットワークを宛先として定義する必要があります。 これは、 dp0bond0 から流れるトラフィックが、Vyatta の背後にあるクライアント・サーバーからの方向にあるためです。

ゾーン・ベースのファイアウォール構成のトラブルシューティング

チェックおよびトラブルシューティングを開始するには、以下のコマンドを実行して、ポリシーがどのように構成されているかを理解します。

  1. どのインターフェースがどのゾーンにあるかを表示するには、 show configuration commands | grep zone | grep interface を実行します。
  2. ステップ 1 の出力を使用して、 show configuration commands | grep <name of zone> | grep <name of other zone> を実行することにより、各ゾーン・ポリシーに適用されているファイアウォール・ルール・セットを見つけることができます。
  3. ステップ 2 の出力を使用すると、 show configuration commands | grep -iE '<name of firewall ruleset>|<name of other firewall ruleset>' を実行して、チェックしようとしているフロー内のインターフェースに適用されているすべてのルールを見つけることができます。
  4. ルールを調べて、適切なサブネット、ポート、およびプロトコルが許可されていることを確認します。
    • サービス・ネットワークからプライベート・サーバーへの接続をトラブルシューティングしており、ポリシーが VIF (dp0bond0.XXX) から dp0bond0 へのものである場合は、サービス・ネットワークを宛先として定義する必要があります。
    • dp0bond0 から VIF (dp0bond0.XXX) へのポリシーの場合は、サービス・ネットワークをソースとして定義する必要があります。

以下の例では、ファイアウォールがサービス・ネットワークを許可するかどうかを判別するために必要な情報をプルするために使用できるコマンドについて詳しく説明します。

vyatta@gateway02:~$ show configuration commands | grep zone | grep interface
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1750'
set security zone-policy zone SL-Private-Servers interface 'dp0bond0.1623'
set security zone-policy zone SL-Service interface 'dp0bond0'

vyatta@gateway02:~$ show configuration commands | grep SL-Private-Servers | grep SL-Service
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

vyatta@gateway02:~$ show configuration commands | grep -iE 'To-Private-Service-Network|To-Private-Servers'
set security firewall name To-Private-Servers rule 1 action 'accept'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 action 'accept'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'
set security zone-policy zone SL-Private-Servers to SL-Service firewall 'To-Private-Service-Network'
set security zone-policy zone SL-Service to SL-Private-Servers firewall 'To-Private-Servers'

#Pull the actual subnets that I'm allowing via the defined ServiceNetwork addresses:
vyatta@gateway02:~$ show configuration commands | grep ServiceNetwork
set resources group address-group ServiceNetwork address '10.0.86.0/24'
set resources group address-group ServiceNetwork address '10.2.128.0/20'
set resources group address-group ServiceNetwork address '10.1.176.0/20'
set resources group address-group ServiceNetwork address '10.1.64.0/19'
set resources group address-group ServiceNetwork address '10.1.96.0/19'
set resources group address-group ServiceNetwork address '10.1.192.0/20'
set resources group address-group ServiceNetwork address '10.1.160.0/20'
set resources group address-group ServiceNetwork address '10.2.32.0/20'
set resources group address-group ServiceNetwork address '10.2.64.0/20'
set resources group address-group ServiceNetwork address '10.2.112.0/20'
set resources group address-group ServiceNetwork address '10.2.160.0/20'
set resources group address-group ServiceNetwork address '10.1.208.0/20'
set resources group address-group ServiceNetwork address '10.2.80.0/20'
set resources group address-group ServiceNetwork address '10.2.144.0/20'
set resources group address-group ServiceNetwork address '10.2.48.0/20'
set resources group address-group ServiceNetwork address '10.2.176.0/20'
set resources group address-group ServiceNetwork address '10.3.64.0/20'
set resources group address-group ServiceNetwork address '10.0.64.0/19'
set resources group address-group ServiceNetwork address '10.0.80.11'
set resources group address-group ServiceNetwork address '10.0.80.12'
set resources group address-group ServiceNetwork address '10.200.80.0/20'
set resources group address-group ServiceNetwork address '10.3.160.0/20'
set resources group address-group ServiceNetwork address '10.201.0.0/20'
set resources group address-group ServiceNetwork address '10.3.80.0/20'
set security firewall name To-Private-Servers rule 1 source address 'ServiceNetwork'
set security firewall name To-Private-Service-Network rule 1 destination address 'ServiceNetwork'

セッションとパケットのロギング

VRA は、セッションとパケットごとの 2 つのタイプのロギングをサポートします。

セッション・ログ記録

コマンド security firewall session-log を使用して、ファイアウォール・セッション・ロギングを構成します。

UDP、ICMP、およびすべての非 TCP フローの場合、セッションはフローの存続期間中に 4 つの状態に遷移します。 各遷移ごとに、メッセージをログに記録するように VRA を構成することができます。 TCP は 状態遷移の数が多く、それぞれをログに記録するように構成することができます。 以下の例では、ファイアウォール用の session-log の構成について詳しく説明します。

set security firewall session-log icmp established
set security firewall session-log tcp established
set security firewall session-log udp established

パケットごとのロギング

パケット・ロギングごとに、ファイアウォールまたは NAT ルールにキーワード log が含まれていることを確認します。 これにより、ルールに一致するすべてのネットワーク・パケットがログに記録されます。

パケットごとのロギングは、パケット転送パスで実行され、大量の出力が生成されます。 パケットごとのロギングは VRA のスループットを大幅に低下させ、パフォーマンスの問題を引き起こし、ロ グファイル用に使用されるディスク容量を劇的に増大させる可能性がある。 パケットごとのロギングは、デバッグ目的でのみ使用することをお勧めします。 すべての運用目的では、代わりにステートフルセッションロギングを使うべきである。

ファイアウォール・ログを使用したトラブルシューティング

デバッグの目的で、デフォルトのログとパケットごとのロギングをセットアップすることができます。 パケットごとのロギングを個々のルールに追加して、パケットがドロップまたは受け入れられたときにログに表示することができます (ルールに設定されているアクションによって異なります)。 デフォルトのログは、発生時に「暗黙的」ドロップを記録します。 以下のゾーン・ポリシー・ベースのファイアウォール構成の場合、デフォルト・ログ設定は、トラフィックがルール 1 に一致しないたびにログに記録します。 これは、構成されている唯一のルールです。

set security firewall name To-Private-Servers rule 1 action drop
set security firewall name To-Private-Servers rule 1 source address ServiceNetwork
set security firewall name To-Private-Servers rule 1 log
set security firewall name To-Private-Servers default-log

ログを表示するには、2 つのコマンドがあります。以下の出力は、特定のトラフィックのログ・ブロックを示しています。

journalctl -u vyatta-dataplane | grep <IP Address>
show log firewall name To-Private-Servers | grep <IP Address>

vyatta@gateway02# journalctl -f -u vyatta-dataplane | grep 10.3.84.106
Feb 18 05:47:09 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
Feb 18 05:47:10 gateway02 vyatta-dataplane.service dataplane[4313]: fw rule To-Private-Servers:10000 block icmp(1) src=//10.3.84.106 dst=dp0bond0.1750//10.126.19.174 len=84 ttl=55 type=8 code=0
^C
[edit]