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

[Alexandre DERUMIER]

>>So why do we need that rule at all? It is already marked with: 
>>
>># fixme: this is an optimization? if so, we should also drop INVALID packages? 
>>ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT"); 
>>
>>So maybe it is better to remove it? 
It's just an optimisation to avoid to go to all tap chains when  the connection is already established.
But of course we can remove 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 08:14:46 
Objet: RE: [pve-devel] [PATCH] add ips feature v3 

> >>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. 

So why do we need that rule at all? It is already marked with: 

# fixme: this is an optimization? if so, we should also drop INVALID packages? 
ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT"); 

So maybe it is better to remove it? 

> >>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 ? 

My feeling is that the whole thing gets to complex. We should make the basic 
firewall working, instead of spending so much time on ips. There are too many 
open questions for me.