Re: [openstack-dev] [openstack-ansible] Security hardening

2015-09-15 Thread Jeff Keopp 
This is a very interesting proposal and one I believe is needed.  I¹m
currently looking at hardening the controller nodes from unwanted access
and discovered that every time the controller node is booted/rebooted, it
flushes the iptables and writes only those rules that neutron believes
should be there.  This behavior would render this proposal ineffective
once the node is rebooted.

So I believe neutron needs to be fixed to not flush the iptables on each
boot, but to write the iptables to /etc/sysconfig/iptables and then
restore them as a normal linux box should do.  It should be a good citizen
with other processes.

A sysadmin should be allowed to use whatever iptables handlers they wish
to implement security policies and not have an OpenStack process undo what
they have set.

I should mention this is on a system using a flat network topology and
bare metal nodes.  No VMs.

‹
Jeff Keopp | Sr. Software Engineer, ES Systems.
380 Jackson Street | St. Paul, MN 55101 | USA  | www.cray.com
<http://www.cray.com>




-Original Message-
From: Major Hayden <ma...@mhtx.net>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Monday, September 14, 2015 at 11:34
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [openstack-ansible] Security hardening

>On 09/14/2015 03:28 AM, Jesse Pretorius wrote:
>> I agree with Clint that this is a good approach.
>> 
>> If there is an automated way that we can verify the security of an
>>installation at a reasonable/standardised level then I think we should
>>add a gate check for it too.
>
>Here's a rough draft of a spec.  Feel free to throw some darts.
>
>  https://review.openstack.org/#/c/222619/
>
>--
>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 hardening

2015-09-15 Thread Clark, Robert Graham 
Very interesting discussion.

The Security project has a published security guide that I believe this
would be very appropriate content for, the current guide (for reference)
is here: http://docs.openstack.org/sec/

Contributions welcome, just like any other part of the OpenStack docs :)

-Rob

On 15/09/2015 16:05, "Jeff Keopp" <ke...@cray.com> wrote:

>This is a very interesting proposal and one I believe is needed.  I¹m
>currently looking at hardening the controller nodes from unwanted access
>and discovered that every time the controller node is booted/rebooted, it
>flushes the iptables and writes only those rules that neutron believes
>should be there.  This behavior would render this proposal ineffective
>once the node is rebooted.
>
>So I believe neutron needs to be fixed to not flush the iptables on each
>boot, but to write the iptables to /etc/sysconfig/iptables and then
>restore them as a normal linux box should do.  It should be a good citizen
>with other processes.
>
>A sysadmin should be allowed to use whatever iptables handlers they wish
>to implement security policies and not have an OpenStack process undo what
>they have set.
>
>I should mention this is on a system using a flat network topology and
>bare metal nodes.  No VMs.
>
>‹
>Jeff Keopp | Sr. Software Engineer, ES Systems.
>380 Jackson Street | St. Paul, MN 55101 | USA  | www.cray.com
><http://www.cray.com>
>
>
>
>
>-Original Message-
>From: Major Hayden <ma...@mhtx.net>
>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev@lists.openstack.org>
>Date: Monday, September 14, 2015 at 11:34
>To: "openstack-dev@lists.openstack.org"
><openstack-dev@lists.openstack.org>
>Subject: Re: [openstack-dev] [openstack-ansible] Security hardening
>
>>On 09/14/2015 03:28 AM, Jesse Pretorius wrote:
>>> I agree with Clint that this is a good approach.
>>> 
>>> If there is an automated way that we can verify the security of an
>>>installation at a reasonable/standardised level then I think we should
>>>add a gate check for it too.
>>
>>Here's a rough draft of a spec.  Feel free to throw some darts.
>>
>>  https://review.openstack.org/#/c/222619/
>>
>>--
>>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

__
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 hardening

2015-09-14 Thread Matthew Thode 
On 09/14/2015 03:28 AM, Jesse Pretorius wrote:
> On 10 September 2015 at 19:21, Clint Byrum  > wrote:
> 
> Excerpts from Major Hayden's message of 2015-09-10 09:33:27 -0700:
> > Hash: SHA256
> >
> > On 09/10/2015 11:22 AM, Matthew Thode wrote:
> > > Sane defaults can't be used?  The two bugs you listed look fine to me 
> as
> > > default things to do.
> >
> > Thanks, Matthew.  I tend to agree.
> >
> > I'm wondering if it would be best to make a "punch list" of CIS 
> benchmarks and try to tag them with one of the following:
> >
> >   * Do this in OSAD
> >   * Tell deployers how to do this (in docs)
> 
> Just a thought from somebody outside of this. If OSAD can provide the
> automation, turned off by default as a convenience, and run a bank of
> tests with all of these turned on to make sure they do actually work
> with
> the stock configuration, you'll get more traction this way. Docs should
> be the focus of this effort, but the effort should be on explaining how
> it fits into the system so operators who are customizing know when they
> will have to choose a less secure path. One should be able to have code
> do the "turn it on" "turn it off" mechanics.
> 
> 
> I agree with Clint that this is a good approach.
> 
> If there is an automated way that we can verify the security of an
> installation at a reasonable/standardised level then I think we should
> add a gate check for it too.
> 
> 
> __
> 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
> 
There are a few different ways to verify system security.  They are
generally outside tools though.

http://www.open-scap.org/page/Main_Page for instance.

-- 
-- Matthew Thode (prometheanfire)

__
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 hardening

2015-09-14 Thread Major Hayden 
On 09/14/2015 03:28 AM, Jesse Pretorius wrote:
> I agree with Clint that this is a good approach.
> 
> If there is an automated way that we can verify the security of an 
> installation at a reasonable/standardised level then I think we should add a 
> gate check for it too.

Here's a rough draft of a spec.  Feel free to throw some darts.

  https://review.openstack.org/#/c/222619/

--
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 hardening

2015-09-14 Thread Jesse Pretorius 
On 10 September 2015 at 19:21, Clint Byrum  wrote:

> Excerpts from Major Hayden's message of 2015-09-10 09:33:27 -0700:
> > Hash: SHA256
> >
> > On 09/10/2015 11:22 AM, Matthew Thode wrote:
> > > Sane defaults can't be used?  The two bugs you listed look fine to me
> as
> > > default things to do.
> >
> > Thanks, Matthew.  I tend to agree.
> >
> > I'm wondering if it would be best to make a "punch list" of CIS
> benchmarks and try to tag them with one of the following:
> >
> >   * Do this in OSAD
> >   * Tell deployers how to do this (in docs)
>
> Just a thought from somebody outside of this. If OSAD can provide the
> automation, turned off by default as a convenience, and run a bank of
> tests with all of these turned on to make sure they do actually work with
> the stock configuration, you'll get more traction this way. Docs should
> be the focus of this effort, but the effort should be on explaining how
> it fits into the system so operators who are customizing know when they
> will have to choose a less secure path. One should be able to have code
> do the "turn it on" "turn it off" mechanics.
>

I agree with Clint that this is a good approach.

If there is an automated way that we can verify the security of an
installation at a reasonable/standardised level then I think we should add
a gate check for it too.
__
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 hardening

2015-09-10 Thread Major Hayden 
Hey there,

I've been looking for some ways to harden the systems that are deployed by 
os-ansible-deployment (soon to be openstack-ansible?) and I've been using the 
Center for Internet Security (CIS)[1] benchmarks as a potential pathway for 
that.  There are benchmarks available for various operating systems and 
applications there.

Many of the items shown there fall into a few different categories:

  1) things OSAD should configure
  2) things deployers should configure
  3) things nobody should configure (they break the deployment, for example)

#3 is often quite obvious, but #1 and #2 are a bit more nebulous.  For example, 
I opened a ticket[2] about getting auditd installed by default with 
openstack-ansible.  My gut says that many deployers could use auditd since it 
collects denials from AppArmor and that can help with troubleshooting broken 
policies.

Also, I opened another ticket[3] for compressing all logs by default.  This 
affects availability (part of the information security CIA triad[4]) in a 
fairly critical way in the long term.

My question is this: How should I go about determining which security changes 
should go upstream and which should go into documentation as things deployers 
should do locally?


[1] https://benchmarks.cisecurity.org/
[2] https://bugs.launchpad.net/openstack-ansible/+bug/1491915
[3] https://bugs.launchpad.net/openstack-ansible/+bug/1493981
[4] https://en.wikipedia.org/wiki/Information_security#Key_concepts

--
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 hardening

2015-09-10 Thread Matthew Thode 
On 09/10/2015 09:54 AM, Major Hayden wrote:
> Hey there,
> 
> I've been looking for some ways to harden the systems that are deployed by 
> os-ansible-deployment (soon to be openstack-ansible?) and I've been using the 
> Center for Internet Security (CIS)[1] benchmarks as a potential pathway for 
> that.  There are benchmarks available for various operating systems and 
> applications there.
> 
> Many of the items shown there fall into a few different categories:
> 
>   1) things OSAD should configure
>   2) things deployers should configure
>   3) things nobody should configure (they break the deployment, for example)
> 
> #3 is often quite obvious, but #1 and #2 are a bit more nebulous.  For 
> example, I opened a ticket[2] about getting auditd installed by default with 
> openstack-ansible.  My gut says that many deployers could use auditd since it 
> collects denials from AppArmor and that can help with troubleshooting broken 
> policies.
> 
> Also, I opened another ticket[3] for compressing all logs by default.  This 
> affects availability (part of the information security CIA triad[4]) in a 
> fairly critical way in the long term.
> 
> My question is this: How should I go about determining which security changes 
> should go upstream and which should go into documentation as things deployers 
> should do locally?
> 
> 
> [1] https://benchmarks.cisecurity.org/
> [2] https://bugs.launchpad.net/openstack-ansible/+bug/1491915
> [3] https://bugs.launchpad.net/openstack-ansible/+bug/1493981
> [4] https://en.wikipedia.org/wiki/Information_security#Key_concepts
> 
> --
> 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
> 

Sane defaults can't be used?  The two bugs you listed look fine to me as
default things to do.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [openstack-ansible] Security hardening

2015-09-10 Thread Matthew Thode 
On 09/10/2015 11:33 AM, Major Hayden wrote:
> On 09/10/2015 11:22 AM, Matthew Thode wrote:
>> Sane defaults can't be used?  The two bugs you listed look fine to me as
>> default things to do.
> 
> Thanks, Matthew.  I tend to agree.
> 
> I'm wondering if it would be best to make a "punch list" of CIS benchmarks 
> and try to tag them with one of the following:
> 
>   * Do this in OSAD
>   * Tell deployers how to do this (in docs)
>   * Tell deployers not to do this (in docs)
> 
> That could be lumped in with a spec/blueprint of some sort.  Would that be 
> beneficial?
> 
> 
> __
> 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
> 

I think that'd work, it'd also allow discussion on if something should
be in each section as well.

-- 
Matthew Thode

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [openstack-ansible] Security hardening

2015-09-10 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 11:22 AM, Matthew Thode wrote:
> Sane defaults can't be used?  The two bugs you listed look fine to me as
> default things to do.

Thanks, Matthew.  I tend to agree.

I'm wondering if it would be best to make a "punch list" of CIS benchmarks and 
try to tag them with one of the following:

  * Do this in OSAD
  * Tell deployers how to do this (in docs)
  * Tell deployers not to do this (in docs)

That could be lumped in with a spec/blueprint of some sort.  Would that be 
beneficial?

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8bDUAAoJEHNwUeDBAR+xEc0P/3S4qQ/U/TET0ag3hwzN0JBv
G3bbcUHhalnGYq12+nX49rF3f0aa3HOOFcWi/hgFFoS4RXQg9vrxnX6AHE5dWP0u
UgqBM8y24CaYXqPoXnfQC/sNbs7gngduKbpTLFqIUXIS+Rye1uOQSnnHuX4iN0US
u1cTQA6Dv04wORvRIAKlKN1kpGoS/WfKUzVQ7bmorCJjm+azBw0amj50Z7KW9w4X
Ci0VBraKSqojUbhvWgD0so7gcfLwrq9eT5pz67xo26df8cpic/LX1UJ9TBBmS97W
YeDxFcubvPviWxHTwxJEnOjHAN4UF2J4sEn8ExwC5UhfG6vOLt97Je6Bt8inTBh4
tTXgfpLrh50B3xk6l1jFEjglaVaSIMLMhirUUALIaJgMcUsWt5F5utcnvp+4+A41
+MKYn/EhGQIHDe/JPa5Yd37TZTwkTW2jthDWb2lkn72sBfC43L/hnIYcKPq7sLVZ
VOP2hSkoMHVT+My8zUBY/m/gcdVJgR9dHDnTPhAts54P4mZg7iOBlRjk+i4YLmSL
0HA4lDiBbpX1wbDIueeDlSDAnQl0PENRrM8fUiJpI0pJC4AOflqQr2r5Bsb6Cz0V
2q/uPgmv0FRup5efjSF2tGTMGAVarijWlqsPSzkGHBt8KVeR0qlgq1Da8qojesdN
gcW2nS0sHcS6Z90t62dJ
=rN2a
-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

Re: [openstack-dev] [openstack-ansible] Security hardening

2015-09-10 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 01:21 PM, Clint Byrum wrote:
> Just a thought from somebody outside of this. If OSAD can provide the
> automation, turned off by default as a convenience, and run a bank of
> tests with all of these turned on to make sure they do actually work with
> the stock configuration, you'll get more traction this way. Docs should
> be the focus of this effort, but the effort should be on explaining how
> it fits into the system so operators who are customizing know when they
> will have to choose a less secure path. One should be able to have code
> do the "turn it on" "turn it off" mechanics.

I'm completely in agreement on this one. ;)

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8fQcAAoJEHNwUeDBAR+x1BIP/jkq0Gd2SuPcWbMU53xADj1W
ml8VtfkJwT/gs1v8Kfd/6OWzUG6DKG+Qk3HR/uAjOUxyYAWYjLcV7aRc3EhDfHqs
8OxoXqy85hPZCiMDFy6apQOsr//5WDYnFig1RPMtHjsEPto+ewJTTMhD8cD2SNC/
/TtCWYEP7pC2pxu8kJCGtJnptGEeg0SL78/MXLjMaKhXV++yrIIyFiqFlKIb2XW9
i4wgm9TAPd6Rs27AY9ew3GFS6UVCm/9nmcw2fqSN639ukTYoLent+NGXNvNEEQ2M
6Gn1hStPS08MYj97dvYrA5aFpVz7q6Jp1GM5DAk3wPAYnrFriU4WNOTdQtzAdlQz
crs4OevM+r/3y1AMcLNmCBMIdOCMwAftjr01sGbU7fHHr2jeUM2p9q/OZkWp56CZ
0YI5Gse9KugNuKNAN8rITM4QgslJOESQu4PxNOhoKCrP+hjQ6bh6K1vVGADNplTM
qG0zD5Jhdbmv42Eud/lQrkth5+aAvZKz+gOsRauTWjbwcRLaX8qT5yBPRJEq3OO9
GhdgN3IRszlUu+TTNXv96ENROOA6DERnx2HmJtBm8EpV1vOIo5tGgsE5IUuPjqnr
BEWkosgMz+ooaLQd6hnnHm88a6WVMcbbZ4pPOywXsgDwEBzCn+rVQ+3sIVrebEdI
pxYuv/fx8oR8G3YAMsLn
=Y66T
-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

Re: [openstack-dev] [openstack-ansible] Security hardening

2015-09-10 Thread Clint Byrum 
Excerpts from Major Hayden's message of 2015-09-10 09:33:27 -0700:
> Hash: SHA256
> 
> On 09/10/2015 11:22 AM, Matthew Thode wrote:
> > Sane defaults can't be used?  The two bugs you listed look fine to me as
> > default things to do.
> 
> Thanks, Matthew.  I tend to agree.
> 
> I'm wondering if it would be best to make a "punch list" of CIS benchmarks 
> and try to tag them with one of the following:
> 
>   * Do this in OSAD
>   * Tell deployers how to do this (in docs)

Just a thought from somebody outside of this. If OSAD can provide the
automation, turned off by default as a convenience, and run a bank of
tests with all of these turned on to make sure they do actually work with
the stock configuration, you'll get more traction this way. Docs should
be the focus of this effort, but the effort should be on explaining how
it fits into the system so operators who are customizing know when they
will have to choose a less secure path. One should be able to have code
do the "turn it on" "turn it off" mechanics.

>   * Tell deployers not to do this (in docs)
> 
> That could be lumped in with a spec/blueprint of some sort.  Would that be 
> beneficial?
> 
> 

__
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