>>this create a new chain PVEFW-Accept
>>
>>-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
>>All those checks are unnecessary, because we have already check it in tap-IN
>>chain?
Well, we need to pass packets to ips, when the connection is established, not
only the first packet.
(http inspection for example)
if we keep -A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j
ACCEPT,
we bypass the ips when connection is already established.
>>And the PVEFW-Accept can grow really large because all interfaces from all
>>VMs are added to a single chain (not per bridge)?
I'm not sure you can add a lot of taps, as ips use a lot of cpu. (but it depend
of your network traffic)
But I think I can improve this, filtering by bridge before tap
PVEFW-ACCEPT
-->vmbr0
--->tap
--->tap
-->vmbr1
--->tap
--->tap
>-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j
>NFQUEUE --queue-num 0 --queue-bypass
>-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j
>NFQUEUE --queue-num 0 --queue-bypass
>-A PVEFW-Accept -j ACCEPT
>>Then I saw that you also jump to PVEFW-Accept for OUT traffic:
>>
r>>uleset_create_chain($ruleset, "$bridge-IN");
>>ruleset_addrule($ruleset, "$bridge-FW", "-m physdev --physdev-is-out -j
>>$bridge-IN");
>>- ruleset_addrule($ruleset, "$bridge-FW", "-m mark --mark 1 -j ACCEPT"); #
>>AFAIK this is for direction OUT
>>+ ruleset_addrule($ruleset, "$bridge-FW", "-m mark --mark 1 -j
>>PVEFW-Accept");
>>why?
I'm thinked to add option to choose direction of ips filtering (in|out|both).
I don't known if user need to filter outgoing traffic ? (reverse shell exploit
? I'm not sure about this)
What do you think about it ?
----- Mail original -----
De: "Dietmar Maurer" <diet...@proxmox.com>
À: "Alexandre DERUMIER" <aderum...@odiso.com>
Cc: pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 07:32:48
Objet: RE: [pve-devel] [PATCH] add ips feature v3
> -----Original Message-----
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent: Mittwoch, 19. März 2014 06:33
> To: Dietmar Maurer
> Cc: pve-devel@pve.proxmox.com
> Subject: Re: [pve-devel] [PATCH] add ips feature v3
>
> I'll send a new patch today, I found some other missing accept
OK
I am still a bit unhappy with that PVEFW-Accept chain.
>this create a new chain PVEFW-Accept
>
>-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
All those checks are unnecessary, because we have already check it in tap-IN
chain? And the PVEFW-Accept
can grow really large because all interfaces from all VMs are added to a single
chain (not per bridge)?
>-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j
>NFQUEUE --queue-num 0 --queue-bypass
>-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j
>NFQUEUE --queue-num 0 --queue-bypass
>-A PVEFW-Accept -j ACCEPT
Then I saw that you also jump to PVEFW-Accept for OUT traffic:
ruleset_create_chain($ruleset, "$bridge-IN");
ruleset_addrule($ruleset, "$bridge-FW", "-m physdev --physdev-is-out -j
$bridge-IN");
- ruleset_addrule($ruleset, "$bridge-FW", "-m mark --mark 1 -j ACCEPT"); #
AFAIK this is for direction OUT
+ ruleset_addrule($ruleset, "$bridge-FW", "-m mark --mark 1 -j PVEFW-Accept");
why?
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
