[pve-devel] [PATCH] add ips feature v3

[Alexandre DERUMIER]

>>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" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at 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:aderumier at odiso.com] 
> Sent: Mittwoch, 19. März 2014 06:33 
> To: Dietmar Maurer 
> Cc: pve-devel at 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?