You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rene Moser <ma...@renemoser.net> on 2017/11/13 17:47:03 UTC

POLL: ACL default egress policy rule in VPC

Hi Devs

The last days I fought with the ACL egress rule behaviour and I would
like to make a poll in which direction the fix should go.

Short Version:

We need to define a better default behaviour for acl default egress
rule. I see 3 different options:

1. always add a default deny all egress rule.

This would be super easy to do (should probably also the intermediate
fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)


2. add a deny all egress rule in case if have at least one egress allow
rule.

A bit intransparent to the user, but doable. This seems to be the
behaviour how it was designed and should have been implemented.


3. use the default setting in the network offering "egressdefaultpolicy"
to specify the default behavior.

There is already a setting which specifies this behaviour but is not
used in VPC. Why not use it?

As a consequence when using this setting, the user should get more infos
about the policy of the network offering while choosing it for the tier.


Poll:

1. []
2. []
3. []
4. [] Other? What?


Long Version:

First, let's have a look of the issue:

In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
would result in a "accept egress all":

-A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
NEW -j ACL_OUTBOUND_eth2
-A ACL_OUTBOUND_eth2 -j ACCEPT

When an egress (here deny 25 egress) rule (no mather if deny or allow)
gets added the result is a "deny all" appended:

-A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
NEW -j ACL_OUTBOUND_eth2
-A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
-A ACL_OUTBOUND_eth2 -j DROP

This does not make any sense and is a bug IMHO.


In 4.9 the behaviour is different:

(note there is a bug in the ordering of egress rules which is fixed by
https://github.com/apache/cloudstack/pull/2313)

The default policy is kept accept egress all.

-A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
NEW -j ACL_OUTBOUND_eth2
-A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
-A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
-A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT


To me it looks like the wanted behavior was "egress all as default. If
we have allow rules, append deny all". This would make sense but is
quite instransparent.

But let's poll



Re: POLL: ACL default egress policy rule in VPC

Posted by Wei ZHOU <us...@gmail.com>.
I agree with (3).

To achieve backward compatibility, we need to add an egress rule to allow
ALL on existing ACLs which do not contain any egress rule.

For now almost every one uses integrated network offerings for VPC networks:
DefaultIsolatedNetworkOfferingForVpcNetworks
DefaultIsolatedNetworkOfferingForVpcNetworksNoLB
DefaultIsolatedNetworkOfferingForVpcNetworksWithInternalLB

The default egress policy are "Deny" in all network offerings above.

-Wei


2017-11-13 18:47 GMT+01:00 Rene Moser <ma...@renemoser.net>:

> Hi Devs
>
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
>
> Short Version:
>
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
>
> 1. always add a default deny all egress rule.
>
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
>
>
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
>
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
>
>
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
>
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
>
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
>
>
> Poll:
>
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
>
>
> Long Version:
>
> First, let's have a look of the issue:
>
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
>
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
>
> This does not make any sense and is a bug IMHO.
>
>
> In 4.9 the behaviour is different:
>
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
>
> The default policy is kept accept egress all.
>
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
>
>
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
>
> But let's poll
>
>
>

Re: POLL: ACL default egress policy rule in VPC

Posted by Rene Moser <ma...@renemoser.net>.
Looks like the winner is 3 for devel.

Thanks for the participation.

Regards
René

On 11/13/2017 06:47 PM, Rene Moser wrote:
> Hi Devs
> 
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
> 
> Short Version:
> 
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
> 
> 1. always add a default deny all egress rule.
> 
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
> 
> 
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
> 
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
> 
> 
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
> 
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
> 
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
> 
> 
> Poll:
> 
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
> 
> 
> Long Version:
> 
> First, let's have a look of the issue:
> 
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
> 
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
> 
> This does not make any sense and is a bug IMHO.
> 
> 
> In 4.9 the behaviour is different:
> 
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
> 
> The default policy is kept accept egress all.
> 
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> 
> 
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
> 
> But let's poll
> 
> 

RE: POLL: ACL default egress policy rule in VPC

Posted by Rohit Yadav <ro...@shapeblue.com>.
Option 3, makes sense to me.

-Rohit
________________________________
From: Paul Angus <pa...@shapeblue.com>
Sent: Tuesday, November 14, 2017 4:08:51 PM
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: RE: POLL: ACL default egress policy rule in VPC

3 sounds like a winner.

[I think that (2) is how non-vpc networks work, I guess the thinking was, that if you are adding allow rules, then you want to deny everything else.  But if you didn't care (ie didn't add egress rules) then allow all outbound was ok]



Kind regards,

Paul Angus

paul.angus@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.yadav@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Simon Weller [mailto:sweller@ena.com.INVALID]
Sent: 13 November 2017 20:14
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: Re: POLL: ACL default egress policy rule in VPC

3 definitely seems to make the most sense.

________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, November 13, 2017 12:02 PM
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: Re: POLL: ACL default egress policy rule in VPC

3

On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland <da...@gmail.com>
wrote:

> 3 of course ;)
>
> On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:
>
> > Hi Devs
> >
> > The last days I fought with the ACL egress rule behaviour and I
> > would like to make a poll in which direction the fix should go.
> >
> > Short Version:
> >
> > We need to define a better default behaviour for acl default egress
> > rule. I see 3 different options:
> >
> > 1. always add a default deny all egress rule.
> >
> > This would be super easy to do (should probably also the
> > intermediate fix for 4.9, see
> > https://github.com/apache/cloudstack/pull/2323)
> >
> >
> > 2. add a deny all egress rule in case if have at least one egress
> > allow rule.
> >
> > A bit intransparent to the user, but doable. This seems to be the
> > behaviour how it was designed and should have been implemented.
> >
> >
> > 3. use the default setting in the network offering "egressdefaultpolicy"
> > to specify the default behavior.
> >
> > There is already a setting which specifies this behaviour but is not
> > used in VPC. Why not use it?
> >
> > As a consequence when using this setting, the user should get more
> > infos about the policy of the network offering while choosing it for the tier.
> >
> >
> > Poll:
> >
> > 1. []
> > 2. []
> > 3. []
> > 4. [] Other? What?
> >
> >
> > Long Version:
> >
> > First, let's have a look of the issue:
> >
> > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND)
> > rule would result in a "accept egress all":
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -j ACCEPT
> >
> > When an egress (here deny 25 egress) rule (no mather if deny or
> > allow) gets added the result is a "deny all" appended:
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -p tcp -m tcp
> > --dport 25 -j DROP -A ACL_OUTBOUND_eth2 -j DROP
> >
> > This does not make any sense and is a bug IMHO.
> >
> >
> > In 4.9 the behaviour is different:
> >
> > (note there is a bug in the ordering of egress rules which is fixed
> > by
> > https://github.com/apache/cloudstack/pull/2313)
> >
> > The default policy is kept accept egress all.
> >
> > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -d
> > 224.0.0.18/32 -j ACCEPT -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j
> > ACCEPT -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> >
> >
> > To me it looks like the wanted behavior was "egress all as default.
> > If we have allow rules, append deny all". This would make sense but
> > is quite instransparent.
> >
> > But let's poll
> >
> >
> >
>
>
> --
> Daan
>



--
Rafael Weingärtner


RE: POLL: ACL default egress policy rule in VPC

Posted by Paul Angus <pa...@shapeblue.com>.
3 sounds like a winner.

[I think that (2) is how non-vpc networks work, I guess the thinking was, that if you are adding allow rules, then you want to deny everything else.  But if you didn't care (ie didn't add egress rules) then allow all outbound was ok]



Kind regards,

Paul Angus

paul.angus@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Simon Weller [mailto:sweller@ena.com.INVALID] 
Sent: 13 November 2017 20:14
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: Re: POLL: ACL default egress policy rule in VPC

3 definitely seems to make the most sense.

________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, November 13, 2017 12:02 PM
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: Re: POLL: ACL default egress policy rule in VPC

3

On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland <da...@gmail.com>
wrote:

> 3 of course ;)
>
> On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:
>
> > Hi Devs
> >
> > The last days I fought with the ACL egress rule behaviour and I 
> > would like to make a poll in which direction the fix should go.
> >
> > Short Version:
> >
> > We need to define a better default behaviour for acl default egress 
> > rule. I see 3 different options:
> >
> > 1. always add a default deny all egress rule.
> >
> > This would be super easy to do (should probably also the 
> > intermediate fix for 4.9, see 
> > https://github.com/apache/cloudstack/pull/2323)
> >
> >
> > 2. add a deny all egress rule in case if have at least one egress 
> > allow rule.
> >
> > A bit intransparent to the user, but doable. This seems to be the 
> > behaviour how it was designed and should have been implemented.
> >
> >
> > 3. use the default setting in the network offering "egressdefaultpolicy"
> > to specify the default behavior.
> >
> > There is already a setting which specifies this behaviour but is not 
> > used in VPC. Why not use it?
> >
> > As a consequence when using this setting, the user should get more 
> > infos about the policy of the network offering while choosing it for the tier.
> >
> >
> > Poll:
> >
> > 1. []
> > 2. []
> > 3. []
> > 4. [] Other? What?
> >
> >
> > Long Version:
> >
> > First, let's have a look of the issue:
> >
> > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) 
> > rule would result in a "accept egress all":
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state 
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -j ACCEPT
> >
> > When an egress (here deny 25 egress) rule (no mather if deny or 
> > allow) gets added the result is a "deny all" appended:
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state 
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -p tcp -m tcp 
> > --dport 25 -j DROP -A ACL_OUTBOUND_eth2 -j DROP
> >
> > This does not make any sense and is a bug IMHO.
> >
> >
> > In 4.9 the behaviour is different:
> >
> > (note there is a bug in the ordering of egress rules which is fixed 
> > by
> > https://github.com/apache/cloudstack/pull/2313)
> >
> > The default policy is kept accept egress all.
> >
> > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state 
> > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -d 
> > 224.0.0.18/32 -j ACCEPT -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j 
> > ACCEPT -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> >
> >
> > To me it looks like the wanted behavior was "egress all as default. 
> > If we have allow rules, append deny all". This would make sense but 
> > is quite instransparent.
> >
> > But let's poll
> >
> >
> >
>
>
> --
> Daan
>



--
Rafael Weingärtner


Re: POLL: ACL default egress policy rule in VPC

Posted by Simon Weller <sw...@ena.com.INVALID>.
3 definitely seems to make the most sense.

________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, November 13, 2017 12:02 PM
To: dev@cloudstack.apache.org
Cc: user@cloudstack.apache.org
Subject: Re: POLL: ACL default egress policy rule in VPC

3

On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland <da...@gmail.com>
wrote:

> 3 of course ;)
>
> On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:
>
> > Hi Devs
> >
> > The last days I fought with the ACL egress rule behaviour and I would
> > like to make a poll in which direction the fix should go.
> >
> > Short Version:
> >
> > We need to define a better default behaviour for acl default egress
> > rule. I see 3 different options:
> >
> > 1. always add a default deny all egress rule.
> >
> > This would be super easy to do (should probably also the intermediate
> > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
> >
> >
> > 2. add a deny all egress rule in case if have at least one egress allow
> > rule.
> >
> > A bit intransparent to the user, but doable. This seems to be the
> > behaviour how it was designed and should have been implemented.
> >
> >
> > 3. use the default setting in the network offering "egressdefaultpolicy"
> > to specify the default behavior.
> >
> > There is already a setting which specifies this behaviour but is not
> > used in VPC. Why not use it?
> >
> > As a consequence when using this setting, the user should get more infos
> > about the policy of the network offering while choosing it for the tier.
> >
> >
> > Poll:
> >
> > 1. []
> > 2. []
> > 3. []
> > 4. [] Other? What?
> >
> >
> > Long Version:
> >
> > First, let's have a look of the issue:
> >
> > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> > would result in a "accept egress all":
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -j ACCEPT
> >
> > When an egress (here deny 25 egress) rule (no mather if deny or allow)
> > gets added the result is a "deny all" appended:
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> > -A ACL_OUTBOUND_eth2 -j DROP
> >
> > This does not make any sense and is a bug IMHO.
> >
> >
> > In 4.9 the behaviour is different:
> >
> > (note there is a bug in the ordering of egress rules which is fixed by
> > https://github.com/apache/cloudstack/pull/2313)
> >
> > The default policy is kept accept egress all.
> >
> > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> >
> >
> > To me it looks like the wanted behavior was "egress all as default. If
> > we have allow rules, append deny all". This would make sense but is
> > quite instransparent.
> >
> > But let's poll
> >
> >
> >
>
>
> --
> Daan
>



--
Rafael Weingärtner

Re: POLL: ACL default egress policy rule in VPC

Posted by Rafael Weingärtner <ra...@gmail.com>.
3

On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland <da...@gmail.com>
wrote:

> 3 of course ;)
>
> On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:
>
> > Hi Devs
> >
> > The last days I fought with the ACL egress rule behaviour and I would
> > like to make a poll in which direction the fix should go.
> >
> > Short Version:
> >
> > We need to define a better default behaviour for acl default egress
> > rule. I see 3 different options:
> >
> > 1. always add a default deny all egress rule.
> >
> > This would be super easy to do (should probably also the intermediate
> > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
> >
> >
> > 2. add a deny all egress rule in case if have at least one egress allow
> > rule.
> >
> > A bit intransparent to the user, but doable. This seems to be the
> > behaviour how it was designed and should have been implemented.
> >
> >
> > 3. use the default setting in the network offering "egressdefaultpolicy"
> > to specify the default behavior.
> >
> > There is already a setting which specifies this behaviour but is not
> > used in VPC. Why not use it?
> >
> > As a consequence when using this setting, the user should get more infos
> > about the policy of the network offering while choosing it for the tier.
> >
> >
> > Poll:
> >
> > 1. []
> > 2. []
> > 3. []
> > 4. [] Other? What?
> >
> >
> > Long Version:
> >
> > First, let's have a look of the issue:
> >
> > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> > would result in a "accept egress all":
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -j ACCEPT
> >
> > When an egress (here deny 25 egress) rule (no mather if deny or allow)
> > gets added the result is a "deny all" appended:
> >
> > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> > -A ACL_OUTBOUND_eth2 -j DROP
> >
> > This does not make any sense and is a bug IMHO.
> >
> >
> > In 4.9 the behaviour is different:
> >
> > (note there is a bug in the ordering of egress rules which is fixed by
> > https://github.com/apache/cloudstack/pull/2313)
> >
> > The default policy is kept accept egress all.
> >
> > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> > NEW -j ACL_OUTBOUND_eth2
> > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> >
> >
> > To me it looks like the wanted behavior was "egress all as default. If
> > we have allow rules, append deny all". This would make sense but is
> > quite instransparent.
> >
> > But let's poll
> >
> >
> >
>
>
> --
> Daan
>



-- 
Rafael Weingärtner

Re: POLL: ACL default egress policy rule in VPC

Posted by Daan Hoogland <da...@gmail.com>.
3 of course ;)

On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser <ma...@renemoser.net> wrote:

> Hi Devs
>
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
>
> Short Version:
>
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
>
> 1. always add a default deny all egress rule.
>
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
>
>
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
>
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
>
>
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
>
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
>
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
>
>
> Poll:
>
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
>
>
> Long Version:
>
> First, let's have a look of the issue:
>
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
>
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
>
> This does not make any sense and is a bug IMHO.
>
>
> In 4.9 the behaviour is different:
>
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
>
> The default policy is kept accept egress all.
>
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
>
>
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
>
> But let's poll
>
>
>


-- 
Daan

Re: POLL: ACL default egress policy rule in VPC

Posted by Rene Moser <ma...@renemoser.net>.
Note the typo in the user mailing list email address, don't use reply
all... sry

Re: POLL: ACL default egress policy rule in VPC

Posted by Nux! <nu...@li.nux.ro>.
Ok, good enough for me.

I vote for option 3 as well then.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Rene Moser" <ma...@renemoser.net>
> To: "dev" <de...@cloudstack.apache.org>
> Sent: Friday, 17 November, 2017 09:22:24
> Subject: Re: POLL: ACL default egress policy rule in VPC

> Hi
> 
> On 11/16/2017 11:14 AM, Nux! wrote:
>> 4. I think Jayapal's reply deserves more attention.
>> 
>> See below.
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> ----- Original Message -----
>>> From: "Jayapal Uradi" <ja...@accelerite.com>
>>> To: "dev" <de...@cloudstack.apache.org>
>>> Sent: Tuesday, 14 November, 2017 05:12:52
>>> Subject: Re: POLL: ACL default egress policy rule in VPC
>> 
>>> Hi Rene,
>>>
>>> Please look at my inline comments.
>>> Let me add some context for the VPC egress/ingress rules behavior.
>>>
>>> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.
>>>
>>> 1. Default egress is ALLOW and ingress is DROP.
>>>   a.  When a rule is added to egress then that particular rule traffic is allowed
>>>   and rest is blocked in egress.
> 
> This works as designed in 4.5.
> 
> However, from a user perspective, if we have an "allow all" to egress, a
> user would add a drop for a single port, but then anything else is also
> blocked. The current implementation does not determine, if the rule
> added is allow or blocked.
> 
>>>   b.  When a rule is added to ingress then that particular rule traffic is allowed
>>>   and rest is blocked in egress.
>>>
>>> After 4.5 ACL lists and ACL items feature is introduced there we have ‘default
>>> allow’ and ‘default deny’ ACLs. User can also
>>> create a custom acl. In ACL feature we can add mix of allow and deny rules and
>>> the ordering of rules is maintained.
> 
> "default allow" and "default deny" already exists in 4.5 as well.
> 
>>> 1.  when ‘default allow’ is selected while creating the vpc tier
>>>    By default traffic is ALLOWED and rules can be added to ALLOW/DENY the traffic
>>>   After adding the rules there will be ACCEPT at the end
>>> 2.  when ‘default deny’ is selected while creating the vpc tier
>>>    By default traffic is DENY and rules can be added to DENY/ALLOW the traffic.
>>>      After adding the rules there will be DROP at the end
> 
> Makes sense,
> 
>>> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
>>> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add
>>> rules for allow/deny rules.
> 
> This works as designed. H
> 
> owever, the issue I see here is that the behaviour for exising rules
> changed. This can potentially lead to a security hole. In 4.5 we had an
> implicit "block all egress when one rule", after 4.5 we have no such rule.
> 
> One can arg for or against this "behaviour". The choice should be up to
> a cloudstack admin, and it would be best if this can be configured. That
> is why using the egressdefaultpolicy makes sense.
> 
>>>
>>> If you see behavior other than above then there will be bug.
>>>
>>> Currently in VPC egress behavior is controlled from the ACLs. If include
>>> ‘egressdefaultpolicy’ then there will be confusion.
> 
> I don't see why there should be any confusion at all. If you would like
> to keep the behaviour currently in 4.9, you just set
> egressdefaultpolicy=true. voila.
> 
>>> What I feel is that current VPC ACLs are flexible enough  to configure the
>>> required behavior.
> 
> It is flexible but the default has changed. a cloudstack admin should
> have the choice.
> 
> René

Re: POLL: ACL default egress policy rule in VPC

Posted by Rene Moser <ma...@renemoser.net>.
Hi

On 11/16/2017 11:14 AM, Nux! wrote:
> 4. I think Jayapal's reply deserves more attention.
> 
> See below.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> ----- Original Message -----
>> From: "Jayapal Uradi" <ja...@accelerite.com>
>> To: "dev" <de...@cloudstack.apache.org>
>> Sent: Tuesday, 14 November, 2017 05:12:52
>> Subject: Re: POLL: ACL default egress policy rule in VPC
> 
>> Hi Rene,
>>
>> Please look at my inline comments.
>> Let me add some context for the VPC egress/ingress rules behavior.
>>
>> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.
>>
>> 1. Default egress is ALLOW and ingress is DROP.
>>   a.  When a rule is added to egress then that particular rule traffic is allowed
>>   and rest is blocked in egress.

This works as designed in 4.5.

However, from a user perspective, if we have an "allow all" to egress, a
user would add a drop for a single port, but then anything else is also
blocked. The current implementation does not determine, if the rule
added is allow or blocked.

>>   b.  When a rule is added to ingress then that particular rule traffic is allowed
>>   and rest is blocked in egress.
>>
>> After 4.5 ACL lists and ACL items feature is introduced there we have ‘default
>> allow’ and ‘default deny’ ACLs. User can also
>> create a custom acl. In ACL feature we can add mix of allow and deny rules and
>> the ordering of rules is maintained.

"default allow" and "default deny" already exists in 4.5 as well.

>> 1.  when ‘default allow’ is selected while creating the vpc tier
>>    By default traffic is ALLOWED and rules can be added to ALLOW/DENY the traffic
>>   After adding the rules there will be ACCEPT at the end
>> 2.  when ‘default deny’ is selected while creating the vpc tier
>>    By default traffic is DENY and rules can be added to DENY/ALLOW the traffic.
>>      After adding the rules there will be DROP at the end

Makes sense,

>> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
>> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add
>> rules for allow/deny rules.

This works as designed. H

owever, the issue I see here is that the behaviour for exising rules
changed. This can potentially lead to a security hole. In 4.5 we had an
implicit "block all egress when one rule", after 4.5 we have no such rule.

One can arg for or against this "behaviour". The choice should be up to
a cloudstack admin, and it would be best if this can be configured. That
is why using the egressdefaultpolicy makes sense.

>>
>> If you see behavior other than above then there will be bug.
>>
>> Currently in VPC egress behavior is controlled from the ACLs. If include
>> ‘egressdefaultpolicy’ then there will be confusion.

I don't see why there should be any confusion at all. If you would like
to keep the behaviour currently in 4.9, you just set
egressdefaultpolicy=true. voila.

>> What I feel is that current VPC ACLs are flexible enough  to configure the
>> required behavior.

It is flexible but the default has changed. a cloudstack admin should
have the choice.

René

Re: POLL: ACL default egress policy rule in VPC

Posted by Nux! <nu...@li.nux.ro>.
4. I think Jayapal's reply deserves more attention.

See below.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Jayapal Uradi" <ja...@accelerite.com>
> To: "dev" <de...@cloudstack.apache.org>
> Sent: Tuesday, 14 November, 2017 05:12:52
> Subject: Re: POLL: ACL default egress policy rule in VPC

> Hi Rene,
> 
> Please look at my inline comments.
> Let me add some context for the VPC egress/ingress rules behavior.
> 
> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.
> 
> 1. Default egress is ALLOW and ingress is DROP.
>   a.  When a rule is added to egress then that particular rule traffic is allowed
>   and rest is blocked in egress.
>   b.  When a rule is added to ingress then that particular rule traffic is allowed
>   and rest is blocked in egress.
> 
> After 4.5 ACL lists and ACL items feature is introduced there we have ‘default
> allow’ and ‘default deny’ ACLs. User can also
> create a custom acl. In ACL feature we can add mix of allow and deny rules and
> the ordering of rules is maintained.
> 
> 1.  when ‘default allow’ is selected while creating the vpc tier
>    By default traffic is ALLOWED and rules can be added to ALLOW/DENY the traffic
>   After adding the rules there will be ACCEPT at the end
> 2.  when ‘default deny’ is selected while creating the vpc tier
>    By default traffic is DENY and rules can be added to DENY/ALLOW the traffic.
>      After adding the rules there will be DROP at the end
> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add
> rules for allow/deny rules.
> 
> If you see behavior other than above then there will be bug.
> 
> Currently in VPC egress behavior is controlled from the ACLs. If include
> ‘egressdefaultpolicy’ then there will be confusion.
> 
> What I feel is that current VPC ACLs are flexible enough  to configure the
> required behavior.
> 
> Thanks,
> Jayapal
> 
> 
> 
> 
> 
>> On Nov 13, 2017, at 11:17 PM, Rene Moser <ma...@renemoser.net> wrote:
>> 
>> Hi Devs
>> 
>> The last days I fought with the ACL egress rule behaviour and I would
>> like to make a poll in which direction the fix should go.
>> 
>> Short Version:
>> 
>> We need to define a better default behaviour for acl default egress
>> rule. I see 3 different options:
>> 
>> 1. always add a default deny all egress rule.
>> 
>> This would be super easy to do (should probably also the intermediate
>> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
>> 
>> 
>> 2. add a deny all egress rule in case if have at least one egress allow
>> rule.
>> 
>> A bit intransparent to the user, but doable. This seems to be the
>> behaviour how it was designed and should have been implemented.
>> 
> Currently we can configure the ACLs to get this behavior.
>> 
>> 3. use the default setting in the network offering "egressdefaultpolicy"
>> to specify the default behavior.
>> 
>> There is already a setting which specifies this behaviour but is not
>> used in VPC. Why not use it?
>> 
>> As a consequence when using this setting, the user should get more infos
>> about the policy of the network offering while choosing it for the tier.
>> 
>> 
>> Poll:
>> 
>> 1. []
>> 2. []
>> 3. []
>> 4. [] Other? What?
>> 
>> 
>> Long Version:
>> 
>> First, let's have a look of the issue:
>> 
>> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
>> would result in a "accept egress all":
>> 
>> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -j ACCEPT
>> 
>> When an egress (here deny 25 egress) rule (no mather if deny or allow)
>> gets added the result is a "deny all" appended:
>> 
>> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
>> -A ACL_OUTBOUND_eth2 -j DROP
> This is seen because default egress is drop and user added rule to deny port 25
> traffic.
> User has choice of adding allow/deny rules with priority number.
>> 
>> This does not make any sense and is a bug IMHO.
>> 
>> 
>> In 4.9 the behaviour is different:
>> 
>> (note there is a bug in the ordering of egress rules which is fixed by
>> https://github.com/apache/cloudstack/pull/2313)
>> 
>> The default policy is kept accept egress all.
>> 
>> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
>> NEW -j ACL_OUTBOUND_eth2
>> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
>> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
>> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
> 
> In 4.9 it is a bug. After accept rules there supposed to DROP all at the end.
>> 
>> 
>> To me it looks like the wanted behavior was "egress all as default. If
>> we have allow rules, append deny all". This would make sense but is
>> quite instransparent.
>> 
>> But let's poll
>> 
>> 
> 
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is the
> property of Accelerite, a Persistent Systems business. It is intended only for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient, you are not authorized to read, retain, copy, print,
> distribute or use this message. If you have received this communication in
> error, please notify the sender and delete all copies of this message.
> Accelerite, a Persistent Systems business does not accept any liability for
> virus infected mails.

Re: POLL: ACL default egress policy rule in VPC

Posted by Jayapal Uradi <ja...@accelerite.com>.
Hi Rene,

Please look at my inline comments.
Let me add some context for the VPC egress/ingress rules behavior.

Pre 4.5 (subject to correction) the behavior of VPC acl is as follows.

1. Default egress is ALLOW and ingress is DROP.
   a.  When a rule is added to egress then that particular rule traffic is allowed and rest is blocked in egress.
   b.  When a rule is added to ingress then that particular rule traffic is allowed and rest is blocked in egress.

After 4.5 ACL lists and ACL items feature is introduced there we have ‘default allow’ and ‘default deny’ ACLs. User can also
create a custom acl. In ACL feature we can add mix of allow and deny rules and the ordering of rules is maintained.

1.  when ‘default allow’ is selected while creating the vpc tier
    By default traffic is ALLOWED and rules can be added to ALLOW/DENY the traffic
   After adding the rules there will be ACCEPT at the end
2.  when ‘default deny’ is selected while creating the vpc tier
    By default traffic is DENY and rules can be added to DENY/ALLOW the traffic.
      After adding the rules there will be DROP at the end
3. If no ACL selected for the ACL then Pre 4.5 behavior will be there.
4. With custom acl default ingress is DROP and egress is ALLOW. User can add rules for allow/deny rules.

If you see behavior other than above then there will be bug.

Currently in VPC egress behavior is controlled from the ACLs. If include  ‘egressdefaultpolicy’ then there will be confusion.

What I feel is that current VPC ACLs are flexible enough  to configure the required behavior.

Thanks,
Jayapal





> On Nov 13, 2017, at 11:17 PM, Rene Moser <ma...@renemoser.net> wrote:
> 
> Hi Devs
> 
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
> 
> Short Version:
> 
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
> 
> 1. always add a default deny all egress rule.
> 
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
> 
> 
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
> 
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
> 
Currently we can configure the ACLs to get this behavior.
> 
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
> 
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
> 
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
> 
> 
> Poll:
> 
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
> 
> 
> Long Version:
> 
> First, let's have a look of the issue:
> 
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
> 
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
> 
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
This is seen because default egress is drop and user added rule to deny port 25 traffic.
User has choice of adding allow/deny rules with priority number.
> 
> This does not make any sense and is a bug IMHO.
> 
> 
> In 4.9 the behaviour is different:
> 
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
> 
> The default policy is kept accept egress all.
> 
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT

In 4.9 it is a bug. After accept rules there supposed to DROP all at the end.
> 
> 
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
> 
> But let's poll
> 
> 

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.