Re: filter network traffic of KVM guests.
On Sun, 20 May 2018 00:15:12 +0300 Reco wrote: > Not your only option (had my share of openvswitch, ditched the thing > recently). I fact, I count four possible ways of doing it (and that's > without the external hardware): Thank you Reco! Your replies were very helpful. I really appreciate them. Chris -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht.
Re: filter network traffic of KVM guests.
Hi. On Sat, May 19, 2018 at 06:35:59AM +0200, Chris wrote: > On Thu, 17 May 2018 23:11:51 +0300 > Reco wrote: > > > Either ebtables (for a conventional brigde) or macvtap in private mode > > will do it. Openvswitch will work too, but it's nowhere near in > > simplicity compared to macvtap. > > Thank you for your quick reply, Reco. > > Unfortunately, I described improperly what I want to achieve. > > I don't want to block all host - guest connections, but allow some with > iptables, e.g. SSH login from host to guest, but not the other way > round. > > Do I have to use Open vSwitch then? Not your only option (had my share of openvswitch, ditched the thing recently). I fact, I count four possible ways of doing it (and that's without the external hardware): 1) Conventional Linux bridge, but with br_netfilter kernel module on top of it. You keep your iptables rules (FORWARD chain), they work, but the things may break once they'll release buster. Or not. 2) Conventional Linux bridge, with ebtables on top. Should work for the foreseeable future. Or not. Ask Red Hat. 3) macvtap in bridge mode, with host netfilter rules on top. Very straightforward setup, all host blocking rules go into INPUT (*not* FORWARD) chain. Also should work for the foreseeable future. 4) Openvswitch. Writing openvswitch filtering rules is more-or-less straightforward. Debugging them is a PITA. But, you get NetFlow and LACP for free (*the* reasons I got into openvswitch). Personally I said that enough is enough, and switched to macvtap/macvlan setup. Reco
Re: filter network traffic of KVM guests.
On Thu, 17 May 2018 23:11:51 +0300 Reco wrote: > Either ebtables (for a conventional brigde) or macvtap in private mode > will do it. Openvswitch will work too, but it's nowhere near in > simplicity compared to macvtap. Thank you for your quick reply, Reco. Unfortunately, I described improperly what I want to achieve. I don't want to block all host - guest connections, but allow some with iptables, e.g. SSH login from host to guest, but not the other way round. Do I have to use Open vSwitch then? - Chris -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht.
Re: filter network traffic of KVM guests.
Hi. On Fri, May 18, 2018 at 10:47:11AM +1200, Richard Hector wrote: > On 18/05/18 08:11, Reco wrote: > >> I read it's deprecated to use iptables on a linux bridge. [1] > > Yup, you should not. > Interesting, I wasn't aware of that. dmesg(1) says to this: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. That's on stock Debian kernel version 4.9. I tell you, reading logs leads to interesting discoveries sometimes ;). > Does that just apply to running iptables on the host? No. You need to have Linux bridge configured, and you need to apply at least one netfilter rule to one of the bridge's slave interfaces. That's then things start breaking. > Or should I also not run it in the vm (eg on a rented VPS, where I > assume the net device is backed by a bridge)? You're safe ☺. Nobody's taking away your ability to configure netfilter *inside* the VPS, that was working, and that will work. You VPS provider, on the other hand, may have a huge headache. > Presumably if it causes a security hole, I shouldn't be _able_ to run it > in the VM? No, it's not like this. For netfilter/iptables rules to apply every packet that traverses brigde should register in several netfilter hooks (parts of kernel code). Either upstream is trying to unify exisiting netfilter_ip4, netfilter_ipv6, netfilter_arp and whatever that thing called that's utilized by ebtables. Currently these are four copy-pasted parts of code. Or they are aiming at performance gains - it's more or less common knowledge that you don't use Linux kernel's IP stack starting with 40Gpbs, you bypass it as it's faster. Reco
Re: filter network traffic of KVM guests.
On 18/05/18 08:11, Reco wrote: >> I read it's deprecated to use iptables on a linux bridge. [1] > Yup, you should not. Interesting, I wasn't aware of that. Does that just apply to running iptables on the host? Or should I also not run it in the vm (eg on a rented VPS, where I assume the net device is backed by a bridge)? Presumably if it causes a security hole, I shouldn't be _able_ to run it in the VM? Richard signature.asc Description: OpenPGP digital signature
Re: filter network traffic of KVM guests.
Hi. On Thu, May 17, 2018 at 08:11:06PM +0200, Chris wrote: > All, > > I'd like to filter network traffic of KVM guests. > > case A: > - no MAC / IP Spoofing > - isolate guest, connections to the gateway only > - no connection to the KVM host > - no NAT > - maybe contradictory: same subnet as KVM host Either ebtables (for a conventional brigde) or macvtap in private mode will do it. Openvswitch will work too, but it's nowhere near in simplicity compared to macvtap. > case B: > - no MAC / IP Spoofing > - isolate guest, connections to the gateway only > - no connection to the KVM host > - no NAT > - some guests should share a "private VLAN" Ditto, but combine private macvtap with external reflector switch. > What's the easiest way to separate KVM guests' traffic on the host? > > I read it's deprecated to use iptables on a linux bridge. [1] Yup, you should not. Besides, iptables is for IP-based protocols anyway. There are ebtables if you really need to deal with the bridges. > I don't like the libvirt (NAT) iptables rules. The default libvirt > network connections aren't secure the way they are pre-configured. > A good summary is in [2] (German only). It's designed with desktop vitualization in mind, so it's no wonder it's unsuitable for anything even remotely looking like a server :). > Is Open vSwitch a viable solution? Can OVS ACLs (or firewall) be used > instead of iptables? You got it wrong. If you're implementing openvswtich, you *have* to utilize its flows instead of iptables. Openvswitch bypasses netfilter by design. Reco
filter network traffic of KVM guests.
All, I'd like to filter network traffic of KVM guests. case A: - no MAC / IP Spoofing - isolate guest, connections to the gateway only - no connection to the KVM host - no NAT - maybe contradictory: same subnet as KVM host case B: - no MAC / IP Spoofing - isolate guest, connections to the gateway only - no connection to the KVM host - no NAT - some guests should share a "private VLAN" What's the easiest way to separate KVM guests' traffic on the host? I read it's deprecated to use iptables on a linux bridge. [1] I don't like the libvirt (NAT) iptables rules. The default libvirt network connections aren't secure the way they are pre-configured. A good summary is in [2] (German only). Is Open vSwitch a viable solution? Can OVS ACLs (or firewall) be used instead of iptables? I'm a bit surprised, that I couldn't find more about it on this list. Chris [1] http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01592.html [2] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Sicherheitsanalyse_KVM/Sicherheitsanalyse_KVM.pdf?__blob=publicationFile&v=3 -- Papst Franziskus ruft zum Kampf gegen Fake News auf. Wir finden, der Mann, der sich als Stellvertreter Christi ausgibt, von dem er behauptet, dessen Mutter sei zeitlebens Jungfrau gewesen, er hätte über Wasser gehen und selbiges in Wein verwandeln können, hat vollkommen recht.
