[pve-devel] [PATCH pve-firewall 1/3] global -m conntrack --ctstate INVALID : PVEFW-reject instead DROP

[Alexandre DERUMIER]

>>Rejecting in forward chains is dangerous, we should never do that by
>>default unless we already know for sure the packet was meant to go down
>>this path, otherwise we end up rejecting connections for other guests if
>>the bridge hasn't learned or forgot the neighbor entry for the packet's
>>mac address.

Is it more dangerous than DROP ? 
the difference is to send an RST. (this could be bad for spoofed attack)

In my case, it seem that flushing conntrack after pve-firewall stop,
fix the problem when pve-firewall start again.


Maybe could we make it optionnal ? 
I'm seeing that we have a new option "nf_conntrack_allow_invalid" to make ACCEPT.

maybe could we rename is "nf_conntrack_invalid_action" : DROP(default)/REJECT/ACCEPT ?



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 18 Février 2019 10:56:42
Objet: Re: [pve-devel] [PATCH pve-firewall 1/3] global -m conntrack --ctstate INVALID : PVEFW-reject instead DROP

On Fri, Feb 15, 2019 at 10:48:01AM +0100, Alexandre Derumier wrote: 
> --- 
> src/PVE/Firewall.pm | 2 +- 
> 1 file changed, 1 insertion(+), 1 deletion(-) 
> 
> diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm 
> index 2125d3b..61d5599 100644 
> --- a/src/PVE/Firewall.pm 
> +++ b/src/PVE/Firewall.pm 
> @@ -2137,7 +2137,7 @@ sub ruleset_chain_add_conn_filters { 
> my ($ruleset, $chain, $allow_invalid, $accept) = @_; 
> 
> if (!$allow_invalid) { 
> - ruleset_addrule($ruleset, $chain, "-m conntrack --ctstate INVALID", "-j DROP"); 
> + ruleset_addrule($ruleset, $chain, "-m conntrack --ctstate INVALID", "-j PVEFW-reject"); 

Rejecting in forward chains is dangerous, we should never do that by 
default unless we already know for sure the packet was meant to go down 
this path, otherwise we end up rejecting connections for other guests if 
the bridge hasn't learned or forgot the neighbor entry for the packet's 
mac address.