> so, in the case of any tap-in chain don't have matched. (so it don't go in
> group-in too, and mark is not overwrited)
Ah, I see.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
.proxmox.com
Envoyé: Vendredi 21 Mars 2014 08:09:43
Objet: RE: [pve-devel] [PATCH] add ips feature v6
> group-in rules now use also mark
This will overwrite the mark set by the -OUT chain, so this breaks the basic
flow?
___
pve-devel mailing li
riginal -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Vendredi 21 Mars 2014 07:13:52
Objet: RE: [pve-devel] [PATCH] add ips feature v6
> this create a new chain PVEFW-Accept (not used anymore, but could be use
> for optimisation
> group-in rules now use also mark
This will overwrite the mark set by the -OUT chain, so this breaks the basic
flow?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> this create a new chain PVEFW-Accept (not used anymore, but could be use
> for optimisation for ESTABLISHED connection)
Please can you remove it. It is not used, so it does not really belong to this
commit.
It is very hard to find such dead code later.
___
This add ips (like suricata) support through nfqueues.
The main idea is to replace -j ACCEPT with -J NFQUEUE , to pass packets to ips
it's using --queue-bypass (only available in 3.10 kernel), so it's suricata
daemon is down,
packets are not dropped.
tap-out chain,
-
we goto PVEFW-S
"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Mars 2014 14:11:10
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> I'll try to setup a benchmark.
> Do you known how to monitor netfilter cpu usage ? (maybe simply %sys
> I'll try to setup a benchmark.
> Do you known how to monitor netfilter cpu usage ? (maybe simply %sys
> counter ?)
no idea, sorry.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
? (maybe simply %sys counter ?)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Mars 2014 10:04:43
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> I was to avoid going into each tap-out device t
> I was to avoid going into each tap-out device then -g PVEFW-SET-ACCEPT-
> MARK.
> go directly to vmbr-OUT
Sorry, I do not understand why that is required. Maybe this is only an
optimization?
If so, please can we optimize later (after doing benchmarks)?
_
re DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Mars 2014 08:09:40
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> maybe could we add
>
> -A vmbrX-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
>
> at the beginning of vmbrX-OUT ?
>
> maybe could we add
>
> -A vmbrX-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
>
> at the beginning of vmbrX-OUT ?
Sorry, I don't get that. What problem does that solve? I thought you want to
enable ips per VM?
___
pve-devel mailing list
p
> But isn't it slower (more taps(in|out) to check), than simply use
>
> -m conntrack --ctstate RELATED,ESTABLISHED -j PVE-Accept at the begin of
> FORWARD ?
Maybe, but still faster than -j PVEFW-Accept?
And we only need to do that when ips is enabled.
___
uot;
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Mars 2014 07:43:48
Objet: Re: [pve-devel] [PATCH] add ips feature v5
>>Maybe we can/should replace that with -g PVEFW-SET-ACCEPT-MARK?
yes, it should work.
But isn't it slower (more taps(in|out) to check), than simply use
-m conntrack -
, maybe the difference is not so big with
modern processors)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Mars 2014 06:55:27
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> Not for conntrack
&
> Not for conntrack
>
> -N tapXXXi0-OUT
> -A tapXXXi0-OUT -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs -A
> tapXXXi0-OUT -p udp -m udp --sport 68 --dport 67 -j PVEFW-SET-ACCEPT-
> MARK -A tapXXXi0-OUT -p tcp -j PVEFW-tcpflags -A tapXXXi0-OUT -m
> conntrack --ctstate INVALID -j DROP
> -A tapX
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-Accept -o vmbr14 -m physdev --physdev-is-out -j vmbr14-IPS
-A vmbr14-IPS -m physdev --physdev-out tap110i0 --physdev-is-bridged -j NFQUEUE
--queue-num 0 --queue-bypass
-A PVEFW-Accept -o vmbr1 -m
RUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 19:34:31
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> in this case:
>
> tap1-out : ACCEPT (ips off) -> tap2-in : ACCEPT (ips on)
>
>
> We don't want always NFQUEUE in tap1-out, bec
> in this case:
>
> tap1-out : ACCEPT (ips off) -> tap2-in : ACCEPT (ips on)
>
>
> We don't want always NFQUEUE in tap1-out, because ips is off, but we want
> NFQUEUE if the destination have ips on.
I do not understand this. In tap-out we simply set the mark (we do not jump to
ACCEPT th
ee if tap-in have ips
enabled, and add a specific mark ?
Help is welcome ;)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 17:07:00
Objet: RE: [pve-devel] [PATCH] add ips feature v5
> for
> for tap-out rules,
> PVEFW-Accept is always use when connection is already established
> -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
Why do we still need ' PVEFW-Accept' instead of -j NFQUEUE?
> in tap-in chain,
> I replace -j ACCEPT by -j NFQUEUE when ips is enabled
> and
> -m
-ACCEPT-MARK,
>>and REJECT is replaced by PVEFW-reject
Ok,got it. Thanks !
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 12:57:29
Objet: RE: [pve-devel] [PATCH] add ips fea
> > 'Razor' => [
> > - { action => 'ACCEPT', proto => 'tcp', dport => '2703' },
> > + { action => 'PVEFW-Accept', proto => 'tcp', dport => '2703' },
> > ],
>
> No, this is the wrong way to do it!
>
> This rules are emitted with ruleset_generate_rule, and you can pass $actions
> ther
> # 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");
> -
> +ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --ctstate
> RELATED,ESTABLIS
> 'Razor' => [
> - { action => 'ACCEPT', proto => 'tcp', dport => '2703' },
> + { action => 'PVEFW-Accept', proto => 'tcp', dport => '2703' },
> ],
No, this is the wrong way to do it!
This rules are emitted with ruleset_generate_rule, and you can pass $actions
there to overwrit
>>ok, removed.
don't have remove yet in my v4 patch,but maybe can you already review it
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 09:12:48
Objet: RE: [pve-devel] [PAT
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-Accept -o vmbr14 -m physdev --physdev-is-out -j vmbr14-IPS
-A vmbr14-IPS -m physdev --physdev-out tap110i0 --physdev-is-bridged -j NFQUEUE
--queue-num 0 --queu
> >>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
ok, removed.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http
ure if we have IPS!
I really need it ;)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mercredi 19 Mars 2014 08:23:04
Objet: RE: [pve-devel] [PATCH] add ips feature v3
> > I'm thinked to add op
DERUMIER"
Cc: pve-devel@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 c
> > 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 sho
> >>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,ESTAB
tion 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"
À: "Alexandre DERUMIER"
Cc:
> -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 toda
I'll send a new patch today, I found some other missing accept
- Mail original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mardi 18 Mars 2014 10:33:06
Objet: Re: [pve-devel] [PATCH] add ips feature v3
> I
Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mardi 18 Mars 2014 09:22:04
Objet: RE: [pve-devel] [PATCH] add ips feature v3
> Do you think the overhead is big ?
> I can work on an optimisation to only replace ACCEPT when ips is enabled
>
Ok, lets go the si
> Do you think the overhead is big ?
> I can work on an optimisation to only replace ACCEPT when ips is enabled
>
Ok, lets go the simple way. We can optimize later.
> >>Besides, I cannot see that this patch replaces all ACCEPT actions, for
> example:
> >>
> >>---
> >>sub ruleset_gene
leset, $chain, "-m addrtype --dst-type MULTICAST -j
PVEFW-Accept");
ruleset_addrule($ruleset, $chain, "-p udp -m conntrack --ctstate NEW
--dport 5404:5405 -j PVEFW-Accept");
ruleset_addrule($ruleset, $chain, "-p udp -m udp --dport 9000 -j
PVEFW-Accept"); #corosyn
> this create a new chain PVEFW-Accept
You use this chain unconditionally, so we slow down things when the IPS is not
active.
(because of an additional jump to PVEFW-Accept).
Besides, I cannot see that this patch replaces all ACCEPT actions, for example:
---
sub ruleset_generate_vm
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j NFQUEUE
--queue-num
> >>We can? Or we 'have to' replace that in order to make ips work?
>
> Currently, it's working, when connection is already established.
>
> Only the first ACCEPT is not yet managed.
Ah, OK.
> >>I would like to have a complete patch before I commit this.
>
> Sure ! I'll improve the patch this
ch this afternoon.
(I need also to check for vnet0)
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Lundi 17 Mars 2014 13:43:29
Objet: RE: [pve-devel] [PATCH] add ips feature v2
> >>We use '
> >>We use '-j ACCEPT' at many places. Each of those calls will bypass the ips?
> >>So shouldn't we replace all occurrences of '-J ACCEPT'?
>
> I only replace when connection is established for now, but I think we can
> replace the -J ACCEPT in tap-in chains without problem.
We can? Or we 'have t
t problem.
and in vmbrX-FW chain too.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Lundi 17 Mars 2014 13:02:54
Objet: RE: [pve-devel] [PATCH] add ips feature v2
We use '-j ACCEPT' at many places
We use '-j ACCEPT' at many places. Each of those calls will bypass the ips?
So shouldn't we replace all occurrences of '-J ACCEPT'?
> This add ips (like suricata) support through nfqueues.
>
> this create a new chain PVEFW-Accept
>
> -A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j
ct: Re: [pve-devel] [PATCH] add ips feature v2
>
> > # fixme: this is an optimization? if so, we should also drop
> > INVALID packages?
> > -ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --
> ctstate
> > RELATED,ESTABLISHED -j ACCEP
> # 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");
> -
> +ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack
> + --ctstate RELATED,ESTABL
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j NFQUEUE
--queue-num
> -Original Message-
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent: Montag, 17. März 2014 08:14
> To: Dietmar Maurer
> Cc: pve-devel@pve.proxmox.com
> Subject: Re: [pve-devel] [PATCH] add ips feature
>
> Well, we jump to NFQUEUE in tap chains.
&g
AIN -j ACCEPT
)
should be faster too
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre Derumier" , pve-devel@pve.proxmox.com
Envoyé: Lundi 17 Mars 2014 07:10:20
Objet: RE: [pve-devel] [PATCH] add ips feature
> # fixme: this is an optimization? if so, we
> # 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");
> -
> +if(!$ips_enable){
> + ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
This replace -J ACCEPT with -J NFQUEUE on established connection when it's
enabled.
it's using --queue-bypass (only available in 3.10 kernel), so it's suricata
daemon is down,
packets are not dropped.
vm
52 matches
Mail list logo
