Назад | Перейти на главную страницу

Как защитить интерфейс BR0 моста?

У меня есть сервер Ubuntu, выступающий в качестве узла KVM, и несколько виртуальных машин, подключенных к сети, работающих под ним.

У виртуальных машин есть свои собственные правила iptables, и они подключены к сети через прямой мост на хосте br0.

Мой вопрос: как мне поступить с этим мостом в iptables на хосте. Считаю ли я его собственным устройством и защищаю ли я его, как любой интерфейс? Есть ли что-то, что я должен знать, что может заблокировать трафик для гостей, если я заблокирую его на хосте? А может написать свои правила в оригинальный интерфейс eno1?

Моя текущая установка выглядит так: (virbr0 не используется ни одной виртуальной машиной, vmnet0 - это работающая гостевая сеть)

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet xxx.HOSTIP.xxx  netmask 255.255.255.0  broadcast 62.210.172.255
        inet6 fe80::d6ae:52ff:fece:993a  prefixlen 64  scopeid 0x20<link>
        inet6 xxx:HOSTIPv6::xxx  prefixlen xx  scopeid 0x0<global>
        ether d4:ae:52:ce:99:3a  txqueuelen 1000  (Ethernet)
        RX packets 753413  bytes 59239171 (59.2 MB)
        RX errors 0  dropped 51  overruns 0  frame 0
        TX packets 115967  bytes 17911763 (17.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether d4:ae:52:ce:99:3a  txqueuelen 1000  (Ethernet)
        RX packets 993041  bytes 303457181 (303.4 MB)
        RX errors 0  dropped 599  overruns 0  frame 0
        TX packets 151299  bytes 22226710 (22.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 182799  bytes 19199389 (19.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 182799  bytes 19199389 (19.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:3c:92:cf  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:fe00:825e  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:00:82:5e  txqueuelen 1000  (Ethernet)
        RX packets 25390  bytes 2725539 (2.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 683484  bytes 266619773 (266.6 MB)
        TX errors 0  dropped 16075 overruns 0  carrier 0  collisions 0

В основном это вопрос того, насколько вы доверяете своим гостевым системам. До тех пор, пока вы не возитесь с таблицей FORWARD, помимо основ для любой маршрутизации, которую вы делаете, у вас должно быть все в порядке, делая практически все, что вы разумно сделали бы в обычном интерфейсе. В большинстве случаев, как правило, лучше просто заблокировать интерфейс, как любой другой, а затем добавлять исключения по мере необходимости (в идеале документировать каждое), но если вы полностью доверяете своим гостевым системам, не будет никакого вреда, если не заблокировать его. вниз.