web-dev-qa-db-ja.com

nftablesブリッジはローカルパケットに一致します

Arch Linuxを使用していて、bridge-utilsを使用してブリッジをセットアップしました。今、私はそれをファイアウォールで保護したいと思います。このマシンがブリッジの背後にあるマシンと自由に通信できるようにしながら、そのブリッジを通過するいくつかのパケットをドロップしたいと思います。私は通常、iifname loを照合することでこのようなケースを処理しますが、残念ながら、パケットとは一致しません。

再び、うまくいけばもっと明確に

  • masterとslaveの2台のマシンがあります。
  • masterには2枚のイーサネットカードがあります。 1つはネットワークの残りの部分に接続され、もう1つはslaveに接続されています
  • masterがanythingをslaveに送信できるようにしたい
  • ネットワークの残りの部分からslaveのmasterへのトラフィックをフィルタリングしたい

Nftablesを使ってやりたいです。あなたはなにか考えはありますか？

firewallbridgenftables
1
Vojtech Kane

loインターフェースはイーサネットインターフェースではありません。リンク層アドレスがなく、ブリッジの一部になることはできません。だから方法はありませんiifname loは一致します。

ブリッジレイアウトは引き続きIPレイアウトと同様に編成されますが、レイヤー2で機能します（ルーティングではなく）スイッチされたイーサネットフレームがフォワードチェーンに入ります。ホスト用のイーサネットフレームは入力チェーンに入り、ホストからのイーサネットフレームは出力チェーンに入ります。

ネットワークが次のようになっているとしましょう。

LAN <--------> eth0 master eth1 <--------> slave
                   (bridge0)

eth0およびeth1に奴隷化されたbridge0。

したがって、ホスト上に1つの一意のブリッジがある場合、この「空の」nftルールセットはslaveを分離するのに十分であり、LANおよびmasterでslaveの無制限のトラフィックを許可します。フォワードチェーンでポリシーを削除します。

#!/usr/sbin/nft -f

flush ruleset

table bridge filter {
    chain input {
        type filter hook input priority -200; policy accept;
    }

    chain forward {
        type filter hook forward priority -200; policy drop;
    }

    chain output {
        type filter hook input priority 200; policy accept;
    }
}

ARPが双方向で機能することを期待するのは確かに正常です（そうでない場合、slaveはIPレベルで多くのことを行うことができません）：

nft add rule bridge filter forward ether type arp accept

ここで、LANがslaveへのpingを許可されているが、その逆は許可されていない場合：

nft add rule bridge filter forward oif eth1 ip protocol icmp icmp type echo-request accept
nft add rule bridge filter forward iif eth1 ip protocol icmp icmp type echo-reply accept

今日の時点ではまだconntrackの統合がないため、ブリッジレベルでのnftablesの使用は、iptablesと比較してまだいくらか制限されています（ただし、よりクリーンです）。ですから、私が知る限り、ステートフルファイアウォールは利用できません。

したがって、通常は簡単なタスクの中には、厄介に見えるものもあります。たとえば、次のようになります。（おそらくリモートの）IPからsshを許可する203.0.113.3。スレーブからLANへの最初の同期が許可されていないことを除いて、双方向のトラフィックを許可します。

nft add rule bridge filter forward oif eth1 ip saddr 203.0.113.3 ip protocol tcp tcp dport 22 accept
nft add rule bridge filter forward iif eth1 ip daddr 203.0.113.3 ip protocol tcp tcp sport 22 tcp flags != syn accept

masterに複数のブリッジがある場合は、ルールやデフォルトポリシーを調整する必要がある場合があります。

0
A.B