>>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
> >>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
14 matches
Mail list logo
