29 Janvier 2014 16:53:59
Objet: RE: [pve-devel] RFC : iptables implementation
> I'll have a look at pve-firewall this week.
But feel free to assemble something totally new if that is easier for you.
___
pve-devel mailing list
pve-devel@pve.p
> I'll have a look at pve-firewall this week.
But feel free to assemble something totally new if that is easier for you.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
dre DERUMIER"
Cc: "pve-devel"
Envoyé: Mercredi 29 Janvier 2014 08:29:29
Objet: RE: [pve-devel] RFC : iptables implementation
> Also,I would like to add dynamic tap rules on vm start/stop,to reduce rules
> when
> vm are offline migrated to another host.
> what do
> Also,I would like to add dynamic tap rules on vm start/stop,to reduce rules
> when
> vm are offline migrated to another host.
> what do you think about it ?
Yes, we can update firewall rules whenever we start/stop a VM.
> Currently we don't have a qemu pve-bridge stop script.
we don't really
nterface destroy and delete iptables rules dynamically ?
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Mercredi 29 Janvier 2014 07:18:51
Objet: RE: [pve-devel] RFC : iptables implementation
> The main idea is to re
> The main idea is to reduce a maximum rules lookup for performance.
>
> 1) the forward rules are splitted by bridge, and we only check rules for tap
> devices on this bridge. This reduce a lot lookups if you have a lot of bridge
> (bridgevlan for example)
> 2) the inter-bridge routing is dropped
Sorry, to be late, I was very busy at work.
So, the new implementation, mostly same that cloudstack.
The main idea is to reduce a maximum rules lookup for performance.
1) the forward rules are splitted by bridge, and we only check rules for tap
devices on this bridge. This reduce a lot lookups
okup)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Vendredi 24 Janvier 2014 09:07:22
Objet: RE: [pve-devel] RFC : iptables implementation
> ah ok, I understand. But isn't it blocked by the INPUT
> ah ok, I understand. But isn't it blocked by the INPUT rule on host ?
> (10.1.0.2-
> >10.1.0.1) I'll do test today.
>
>
> If we really want to block host->tap, without known ip in guest, we could also
> only allow known authorized ips in output
We just need to be aware of that.
I guess normal
ptables -j DROP
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Vendredi 24 Janvier 2014 08:57:06
Objet: RE: [pve-devel] RFC : iptables implementation
> >>If you have several bridges with assigned IP
> >>If you have several bridges with assigned IPs, traffic can be routed
> >>from one VM to another VM on different bridge. This will bypass all your
> firewall rules!
>
> Can you provide an network schema with guest and bridge ip address for this
> example ?
vmbr0(10.1.0.1/24) => VM1(10.1.0.2)
riginal -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: "pve-devel"
Envoyé: Vendredi 24 Janvier 2014 07:59:40
Objet: Re: [pve-devel] RFC : iptables implementation
>>That is the other direction? I talk about OUTPUT from HOST into VM
I wanted to say,t
test that today
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Vendredi 24 Janvier 2014 07:05:03
Objet: RE: [pve-devel] RFC : iptables implementation
> >>The problem is that all routed traffic from HOS
> >>The problem is that all routed traffic from HOST to VM is allowed. So
> >>a good test would be trying to block something.
>
> yes, but return packet (tap-->input) is blocked, so you can't established a
> connection
> iptables -A INPUT -m physdev --physdev-in tap115i0 -j DROP
>
> or
>
> ipt
ROTO=ICMP TYPE=0
CODE=0 ID=7239 SEQ=21
another way should be to block guest ip in OUTPUT, but we need to known the ip
address of the guest.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Jeudi 2
> >>But they test everything twice that way?
>
> Yes, I don't known why.
> maybe they want to be sure that tap to tap filtering is done only on known tap
> interfaces with firewall enable ?
Yes, I think so.
But one could avoid double checks by using '-j cleaup-chain' instead of
using RETURN in
"pve-devel"
Envoyé: Jeudi 23 Janvier 2014 11:01:42
Objet: RE: [pve-devel] RFC : iptables implementation
> By the way, I understand now why they are doing this:
>
> -A proxmoxfw-FORWARD -m physdev --physdev-out tap110i0 --physdev-is-
> bridged -j tapchains
> -A prox
> By the way, I understand now why they are doing this:
>
> -A proxmoxfw-FORWARD -m physdev --physdev-out tap110i0 --physdev-is-
> bridged -j tapchains
> -A proxmoxfw-FORWARD -m physdev --physdev-in tap110i0 --physdev-is-
> bridged -j tapchains
> -A proxmoxfw-FORWARD -m physdev --physdev-out tap11
> >>Maybe no big problem unless the user assigns IP addresses to multiple
> bridges.
>
> I'll do test today. Because I known openstack can use dhcpd from host
The problem is that all routed traffic from HOST to VM is allowed. So a good
test
would be trying to block something.
__
original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: "pve-devel"
Envoyé: Jeudi 23 Janvier 2014 08:39:50
Objet: Re: [pve-devel] RFC : iptables implementation
>>But the other direction does not work (HOST to VM).
>>Maybe no big probl
he tap interfaces.
I'll try to make a sample of rules for
internet->host
host->internet
host->tap
tap->host
tap->tap
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Jeudi 23 Janvier 2014 07:1
> They also add an -input rules for outgoing packet from tap. (I think this for
> from
> tap to host)
>
>
> -A INPUT -j proxmoxfw-chain-INPUT
> -A FORWARD -m physdev --physdev-out tap100i0 --physdev-is-bridged -j
> proxmoxfw-chain
> -A FORWARD -m physdev --physdev-in tap100i0 --physdev-is-bridge
100i0-out
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 19:45:41
Objet: RE: [pve-devel] RFC : iptables implementation
> I am also concerned about this:
>
> --quote-shorewall-d
> I am also concerned about this:
>
> --quote-shorewall-docs--
> As described above, Shorewall bridge support requires the physdev match
> feature of Netfilter/iptables. Physdev match allows rules to be triggered
> based
> on the bridge port that a packet arrived on and/or the bridge port that a
-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Dietmar Maurer
> Sent: Mittwoch, 22. Jänner 2014 19:14
> To: Alexandre DERUMIER
> Cc: pve-devel
> Subject: Re: [pve-devel] RFC : iptables implementation
>
> Well, we also need to have rul
> With the coming add-on for firewall how would that affect iptables rules on
> the
> host?
We will add a way to specify rules for the host.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Well, we also need to have rules for traffic unrelated to VMs.,
i.e from and to the host.
> > don't known if it's better than
>
> >>Above would only handle traffic originated from a VM and skip traffic from
> outside (eth0)?
>
> maybe. I think we shouldn't filter from ethX, because outside can b
On Wed, 22 Jan 2014 18:27:07 +0100 (CET)
Alexandre DERUMIER wrote:
>
> maybe. I think we shouldn't filter from ethX, because outside can be also
> other hosts with others vm.
> (Or maybe users want to add some custom rules on ethX to protect the host
> itself, like this it doesn't conflict wit
on ethX to protect the host
itself, like this it doesn't conflict with openstack rules)
also,maybe they are doing like this to add later some custom rules before the
ACCEPT.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-de
> FORWARD -> proxmoxfw-chain ->jump in tap chain1
><-return or drop
>->jump in tap chain2
><-return or drop
>
>->ACCEPT
>
>
> don't known if it's better than
Above would only handle t
quot;Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 13:18:05
Objet: RE: [pve-devel] RFC : iptables implementation
yes, that looks better now.
> -Original Message-
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent
yes, that looks better now.
> -Original Message-
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent: Mittwoch, 22. Jänner 2014 10:27
> To: Dietmar Maurer
> Cc: pve-devel
> Subject: Re: [pve-devel] RFC : iptables implementation
>
> Hi, again,
>
- Mail original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 10:27:06
Objet: Re: [pve-devel] RFC : iptables implementation
Hi, again,
It's seem to works if I use RETURN instead ACCEPT in outgoing rule
tables -A tap115i0-out -j ACCEPT
#in rules for tap115i0 (drop all)
iptables -A tap115i0-in -m state --state INVALID -j DROP
iptables -A tap115i0-in -m state --state RELATED,ESTABLISHED -j RETURN
iptables -A tap115i0-in -j LOG --log-prefix "tap11i5in-dropped: " --log-level 4
iptables
opped: " --log-level 4
iptables -A tap115i0-in -j DROP
- Mail original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 09:19:05
Objet: Re: [pve-devel] RFC : iptables implementation
>>If y
Cc: "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 08:19:02
Objet: RE: [pve-devel] RFC : iptables implementation
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Dietmar Maurer
> Sent:
> -Original Message-
> From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel-
> boun...@pve.proxmox.com] On Behalf Of Dietmar Maurer
> Sent: Mittwoch, 22. Jänner 2014 08:13
> To: Alexandre DERUMIER
> Cc: pve-devel
> Subject: Re: [pve-devel] RFC : iptables impleme
ge port/ tap only.
And I don't have any problem to communicate with others ports (mac address
rules), or with external network(rules by ip).
I'll do tests with 2 firewalled ports.
----- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve
> >>I am not sure if that model correctly handle traffic form one VM to another
> (traffic from VM1 to VM2)?
> >>Because you would need to apply out rules for VM1, the in rules for VM2.
> >>Does that work - if so how?
>
> Well, is like to have 2vms behind 2 firewalls.
OK, so I just believe you th
going to internal network and drop
for internet (external network) by default.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER" , "pve-devel"
Envoyé: Mercredi 22 Janvier 2014 07:19:28
Objet: RE: [pve-devel] RFC : iptables implementation
> what do you think about it ?
>
>
>
> iptables -F
> iptables -X
>
> iptables -N tap110i0-out
> iptables -N tap110i0-in
> #out
> iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in tap110i0 -j
> tap110i0-out
> #in
> iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-out
> >>How would you present that to the user (how would you design a GUI for
> that)?
> I see 2 parts:
>
> 1 firewall tab on the vm
> in this tab, we can associate security groups for incoming rules and outgoing
> rules by network interface
>
> [INCOMING RULES]
> net0 security1
> net0 security
1 bridge for each tap
interface plugged to ovs.
Like this it's possible to manage iptable rules on theses bridge.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER" , "pve-devel"
Envoyé: Mardi 21 Janvier 2014 06:55:43
Objet: RE:
> - you can defined rules (chain names up to 28characters), and reuse them for
> differents vms
> -you can apply rules on vms or group
> - if you need to change a chain/security group, you can simply flush the chain
> (iptables -F chain) before reapply rules,
> without need to regenerate/"compile
Hi,
here an implementation of firewall with iptables, like openstack and cloudstack
is doing.
The main idea is to use as much of possible chains feature of iptables.
First, we create 2 chains by tap interface, for incoming and outgoing packets.
(In my example, tap110i0-out and tap110i0-in).
Se
45 matches
Mail list logo
