Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Logan V.]

Ferm DSL is nice and featureful. There's a pretty sophisticated debops
ferm role at [1] allowing for pretty sophisticated rule definitions
[2]. Structurally I think the most important thing is having the
ability to define rules in layers based on host_vars, group_vars, etc.
and have them blended together by the firewall role using a weighting
system. You can get really fancy with the rules definitions as shown
by the rules.d template in debops-ferm [3].

My question now is what does ferm give us that iptables-save
templating does not? Writing ferm configuration can differ pretty
substantially from iptables-save syntax, and we add another language
dependency (perl) in the process. I think for ferm to make sense, we
should be able to argue pretty convincingly that there's some major
advantages over laying down a consolidated templated iptables-save
file. IMO we can have all of the same sophistication this way and
expose it in a very nice interface through ansible vars.

[1] https://github.com/debops/ansible-ferm
[2] https://docs.debops.org/en/latest/ansible/roles/ansible-ferm/docs/
[3] https://github.com/debops/ansible-ferm/tree/master/templates/etc/ferm

On Wed, Aug 2, 2017 at 3:47 PM, Major Hayden  wrote:
> On 08/02/2017 03:57 AM, Mark Goddard wrote:
>> The solution we built used a conf.d/ mechanism layered on top of iptables. 
>> An advantage of this approach is that operators or co-resident software 
>> stacks could add their own rules to the firewall. AFAIK, this is not 
>> generally possible when using iptables-save/restore as it relies on a single 
>> configuration file which must be 'owned' by something - in this case 
>> presumably OSA.
>>
>> I'm not suggesting that you reimplement the solution I've described, but it 
>> does outline one benefit of firewalld - OSA would not need to entirely own 
>> the firewall configuration.
>
> Thanks for the feedback!  I'm leaning away from firewalld now and looking at 
> something a little simpler with iptables.
>
> During a recent IRC meeting someone brought up ferm[0]. They have several 
> examples, but the workstation[1] one makes some sense. It would be fairly 
> easy to template the ferm DSL files.
>
> [0] http://ferm.foo-projects.org/
> [1] http://ferm.foo-projects.org/download/examples/webserver.ferm
>
> --
> Major Hayden
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Major Hayden]

On 08/02/2017 03:57 AM, Mark Goddard wrote:
> The solution we built used a conf.d/ mechanism layered on top of iptables. An 
> advantage of this approach is that operators or co-resident software stacks 
> could add their own rules to the firewall. AFAIK, this is not generally 
> possible when using iptables-save/restore as it relies on a single 
> configuration file which must be 'owned' by something - in this case 
> presumably OSA.
> 
> I'm not suggesting that you reimplement the solution I've described, but it 
> does outline one benefit of firewalld - OSA would not need to entirely own 
> the firewall configuration.

Thanks for the feedback!  I'm leaning away from firewalld now and looking at 
something a little simpler with iptables.

During a recent IRC meeting someone brought up ferm[0]. They have several 
examples, but the workstation[1] one makes some sense. It would be fairly easy 
to template the ferm DSL files.

[0] http://ferm.foo-projects.org/
[1] http://ferm.foo-projects.org/download/examples/webserver.ferm

--
Major Hayden

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Mark Goddard]

In my previous job we had to build a firewall solution for our OpenStack
control plane. Our research found that firewalld may have a habit of
'fighting' against the rules added by certain OpenStack services. This was
over a year ago, so things may have changed. We didn't pursue firewalld as
a solution, so perhaps these issues are non-existent or surmountable.

The solution we built used a conf.d/ mechanism layered on top of iptables.
An advantage of this approach is that operators or co-resident software
stacks could add their own rules to the firewall. AFAIK, this is not
generally possible when using iptables-save/restore as it relies on a
single configuration file which must be 'owned' by something - in this case
presumably OSA.

I'm not suggesting that you reimplement the solution I've described, but it
does outline one benefit of firewalld - OSA would not need to entirely own
the firewall configuration.

On 28 July 2017 at 07:49, Markos Chandras  wrote:

> On 07/26/2017 05:59 PM, Major Hayden wrote:
> >
> > firewalld disadvantages
> > ---
> > 1) Different distributions have different base rule sets
>
> Also different distributions offer different version of firewalld which
> means different behavior and possibly bugs between them. The Ansible
> module may not always 'mask' such things we either going to spend time
> improving the module or workaround all these in our playbooks. Improving
> the upstream module of course is a good thing but I just wanted to point
> out the maintenance cost of that.
>
> > 2) Medium/High complexity rules require --direct, which is like using
> iptables anyway
> > 3) It's another daemon to manage/monitor
> > 4) We wouldn't be able to use firewalld's "zones" very heavily
> > 5) Saving/restoring iptables rules is battle-tested already
>
> I am slightly in favor of iptables (or even nftables) mostly because
> they provide a stable known interface which can work for simple and
> complex rules. As your 2nd point above correctly states, if we start
> using the 'direct' rule feature of firewalld, then we will end up having
> a mixture of pure firewalld and iptables rules which may not be the
> cleaner option in terms of maintainability.
>
> --
> markos
>
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Markos Chandras]

On 07/26/2017 05:59 PM, Major Hayden wrote:
> 
> firewalld disadvantages
> ---
> 1) Different distributions have different base rule sets

Also different distributions offer different version of firewalld which
means different behavior and possibly bugs between them. The Ansible
module may not always 'mask' such things we either going to spend time
improving the module or workaround all these in our playbooks. Improving
the upstream module of course is a good thing but I just wanted to point
out the maintenance cost of that.

> 2) Medium/High complexity rules require --direct, which is like using 
> iptables anyway
> 3) It's another daemon to manage/monitor
> 4) We wouldn't be able to use firewalld's "zones" very heavily
> 5) Saving/restoring iptables rules is battle-tested already

I am slightly in favor of iptables (or even nftables) mostly because
they provide a stable known interface which can work for simple and
complex rules. As your 2nd point above correctly states, if we start
using the 'direct' rule feature of firewalld, then we will end up having
a mixture of pure firewalld and iptables rules which may not be the
cleaner option in terms of maintainability.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Mark Mielke]

On Thu, Jul 27, 2017 at 2:31 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:
>
> For ppl who aren't iptables experts, firewalld module brings a lot of
> readability.
> If we are doing the tasks equivalent with iptables, the readability will
> be brought in by variables (I mean variables to list ports_to_open are
> fairly easy to understand).
>
> I am myself preferring to always use modules, and so, use the firewalld
> module (because it's already upstream, less tasks and therefore less error
> prone).
> However, that would mean that we improve the module itself to grant what
> we need: Real ubuntu and python3 support.
> Maybe it's a crusade that nobody wants to partake in, and using iptables
> would mean a path to least resistance, therefore easier to ship.
> On top of it, if it's more a hassle to use the module due to complex rules
> (do we even need that?), I'd understand the move to iptables management. Is
> there already a role to handle this?
>


I have been thinking about nftables for our use cases. iptables is (slowly)
on its way out. firewalld does provide some abstraction from this, in that
firewalld could provide an interface to translate from iptables to nftables
without application changes. But, I am concerned that firewalld is not
sophisticated enough to meet requirements, and I am hesitant to really
invest in it if it is too simple for requirements.

Just some food for thought I had to offer...
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Jean-Philippe Evrard]

Hello,

A few additions for/against firewalld, linked to ansible's firewalld
module: http://docs.ansible.com/ansible/latest/firewalld_module.html

+:
The module is built-in, so no need to ship it. It provides idempotency, and
is easy to use.

-:
The module is: "Not tested on any Debian based system.
Requires the python2 bindings of firewalld, which may not be installed by
default if the distribution switched to python 3".

My take:

For ppl who aren't iptables experts, firewalld module brings a lot of
readability.
If we are doing the tasks equivalent with iptables, the readability will be
brought in by variables (I mean variables to list ports_to_open are fairly
easy to understand).

I am myself preferring to always use modules, and so, use the firewalld
module (because it's already upstream, less tasks and therefore less error
prone).
However, that would mean that we improve the module itself to grant what we
need: Real ubuntu and python3 support.
Maybe it's a crusade that nobody wants to partake in, and using iptables
would mean a path to least resistance, therefore easier to ship.
On top of it, if it's more a hassle to use the module due to complex rules
(do we even need that?), I'd understand the move to iptables management. Is
there already a role to handle this?

Best regards,
JP

On Wed, Jul 26, 2017 at 3:59 PM, Major Hayden  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey there,
>
> I'm working through some drafts of a spec[0] (rendered[1]) that aims to
> deploy software firewalls within an OpenStack-Ansible deployment. The goal
> is to increase security by restricting lateral movement.
>
> One of the questions that was raised was the method for managing firewall
> rules. The spec lays out a plan for firewalld since it is available in the
> supported operating systems (Ubuntu 16.04, CentOS 7, OpenSUSE 42.x) and it
> allows us to control IPv4/IPv6 rules in the same place.
>
> However, Logan makes a good point about using a jinja template to write
> firewall rules to a file and load that via normal iptables service
> mechanisms. I definitely see merit to that approach, too.
>
> I'd really like feedback from developers/operators of OpenStack-Ansible to
> determine the best method to proceed. Here's what I've come up with so far:
>
> firewalld advantages
> - 
> 1) Available in all distributions we support
> 2) Provides simple commands to interface with firewall rules
> 3) Manages IPv4/IPv6 iptables rules at the same time
>
> firewalld disadvantages
> - ---
> 1) Different distributions have different base rule sets
> 2) Medium/High complexity rules require --direct, which is like using
> iptables anyway
> 3) It's another daemon to manage/monitor
> 4) We wouldn't be able to use firewalld's "zones" very heavily
> 5) Saving/restoring iptables rules is battle-tested already
>
>
> [0] https://review.openstack.org/#/c/479415/
> [1] http://docs-draft.openstack.org/15/479415/5/check/gate-
> openstack-ansible-specs-docs-ubuntu-xenial/6a50e01//doc/
> build/html/specs/pike/software-firewall.html
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAll4rkwACgkQc3BR4MEB
> H7G3ThAAkYfAGPThoaLK+a+xSZjQrrDYo3T2Q8h/nCVdSbXU1npfv0wnIUcpezH7
> a2bq4tSOX53tupUtvtMXK1VzSh5zQbohewfndmAOpwH8yNJ6UdnBjTfNXbs1WU05
> ke6X/RIvkNEKO4q5RvO3hbgKFKtLFdDVWRa7m6ORM2UaN2QXRrr85Cs0GrS0wWJq
> XDLVf5277VPXiobntUkdSdVAHfPX0QULMUBxSbnhAjGhLWfZnGiyInntHAu0rGqj
> xhkZNT3wuEMmorbIfUkY1NhjWJyy5LyjCar+hpJKRz/pNlFiOiF36Ps4PLNBW06P
> IwL3IbTkOwI6KPffFBqmMYb2AHsbqpnwxjBjoUQv1YvW55IZn3EliUY0t05JBFZ0
> N4EDNplyX9UhEQdFQrKHkOjCzADuuI/nnngfsZiCziiU068mRYIp4S3phj6QiOZP
> bHdjQDUx3X7rk1s6i7SdLPxPYNPxEs6wipXzofjB4STwDYqFKmpSNOTecLVN64PE
> H1bmt/lOfSpl05jjwhk8Jaxd0RgMAM2a7pA7nsTpFqRG4v7VaucewGaCRypCvAUD
> JiuQ+RYCNifEBb8nX6lx8TnJLCzaFK4xZuEdpBqGCwKaXRYUqdS+W2bRPqRY6EmF
> 5jYN1d2U0rxyYmQ1cH921VQPhA8K142FoUgq+oqiaH/8cqeWr9o=
> =lwtm
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible][security] To firewalld, or not to firewalld

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

I'm working through some drafts of a spec[0] (rendered[1]) that aims to deploy 
software firewalls within an OpenStack-Ansible deployment. The goal is to 
increase security by restricting lateral movement.

One of the questions that was raised was the method for managing firewall 
rules. The spec lays out a plan for firewalld since it is available in the 
supported operating systems (Ubuntu 16.04, CentOS 7, OpenSUSE 42.x) and it 
allows us to control IPv4/IPv6 rules in the same place.

However, Logan makes a good point about using a jinja template to write 
firewall rules to a file and load that via normal iptables service mechanisms. 
I definitely see merit to that approach, too.

I'd really like feedback from developers/operators of OpenStack-Ansible to 
determine the best method to proceed. Here's what I've come up with so far:

firewalld advantages
- 
1) Available in all distributions we support
2) Provides simple commands to interface with firewall rules
3) Manages IPv4/IPv6 iptables rules at the same time

firewalld disadvantages
- ---
1) Different distributions have different base rule sets
2) Medium/High complexity rules require --direct, which is like using iptables 
anyway
3) It's another daemon to manage/monitor
4) We wouldn't be able to use firewalld's "zones" very heavily
5) Saving/restoring iptables rules is battle-tested already


[0] https://review.openstack.org/#/c/479415/
[1] 
http://docs-draft.openstack.org/15/479415/5/check/gate-openstack-ansible-specs-docs-ubuntu-xenial/6a50e01//doc/build/html/specs/pike/software-firewall.html

- --
Major Hayden
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAll4rkwACgkQc3BR4MEB
H7G3ThAAkYfAGPThoaLK+a+xSZjQrrDYo3T2Q8h/nCVdSbXU1npfv0wnIUcpezH7
a2bq4tSOX53tupUtvtMXK1VzSh5zQbohewfndmAOpwH8yNJ6UdnBjTfNXbs1WU05
ke6X/RIvkNEKO4q5RvO3hbgKFKtLFdDVWRa7m6ORM2UaN2QXRrr85Cs0GrS0wWJq
XDLVf5277VPXiobntUkdSdVAHfPX0QULMUBxSbnhAjGhLWfZnGiyInntHAu0rGqj
xhkZNT3wuEMmorbIfUkY1NhjWJyy5LyjCar+hpJKRz/pNlFiOiF36Ps4PLNBW06P
IwL3IbTkOwI6KPffFBqmMYb2AHsbqpnwxjBjoUQv1YvW55IZn3EliUY0t05JBFZ0
N4EDNplyX9UhEQdFQrKHkOjCzADuuI/nnngfsZiCziiU068mRYIp4S3phj6QiOZP
bHdjQDUx3X7rk1s6i7SdLPxPYNPxEs6wipXzofjB4STwDYqFKmpSNOTecLVN64PE
H1bmt/lOfSpl05jjwhk8Jaxd0RgMAM2a7pA7nsTpFqRG4v7VaucewGaCRypCvAUD
JiuQ+RYCNifEBb8nX6lx8TnJLCzaFK4xZuEdpBqGCwKaXRYUqdS+W2bRPqRY6EmF
5jYN1d2U0rxyYmQ1cH921VQPhA8K142FoUgq+oqiaH/8cqeWr9o=
=lwtm
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev