I work in a DoD environment where the blanket directive is that everything
must be secured according to security technical implementation guides
(STIG). There are general guides that apply to various technologies:
database, web server, OS, application servers, etc. Any time that there is
a component that falls into one of the categories that has a guide it must
be configured as closely as possible to the guide. Some deviations may be
acceptable if a mitigation can be identified.
Katello+Foreman+Pulp has a lot of configuration that would apply: MongoDB,
PostgreSQL, Apache, Tomcat, and possibly the Ruby code itself. Has anyone
else had to put any thought into this issue? I'm primarily concerned that
the only way to achieve this is to make a single change and then test the
system for any operational change. This would take an excessively long
time.
Have wondered the same for using the CIS Benchmarks. Came to the same
conclusion; make one change, reinstall, test, repeat.
Haven't got round to doing this yet as it is indeed time consuming. My one
test of applying all changes and then trying to install turned out exactly
as I expected - with a failed install. Am now working on building a new
Satellite 6.1 system under CIS Benchmarks, so will hopefully get further.
D
···
On Monday, 30 November 2015 18:55:35 UTC, Lesley Kimmel wrote:
>
> All;
>
> I work in a DoD environment where the blanket directive is that everything
> must be secured according to security technical implementation guides
> (STIG). There are general guides that apply to various technologies:
> database, web server, OS, application servers, etc. Any time that there is
> a component that falls into one of the categories that has a guide it must
> be configured as closely as possible to the guide. Some deviations may be
> acceptable if a mitigation can be identified.
>
> Katello+Foreman+Pulp has a lot of configuration that would apply: MongoDB,
> PostgreSQL, Apache, Tomcat, and possibly the Ruby code itself. Has anyone
> else had to put any thought into this issue? I'm primarily concerned that
> the only way to achieve this is to make a single change and then test the
> system for any operational change. This would take an excessively long
> time.
>
Has anyone on this thread had any progress with securing Satellite/Katello?
I've just begun using the DoD-provided security requirements guide to
secure MongoDB. The downside is that the direction is very generic and only
states what type of security should be provided by the database but no
product-specific way to do it. Therefore, I am slogging through and having
to learn MongoDB as I go. I would love to have gotten my hands on the STIG
published by the MongoDB folks but they will not provide it unless I am a
customer paying for their "enterprise" product. Has anyone gotten their
hands on this STIG document? Can it [legally] be shared?
Thanks,
-LJK
···
On Monday, November 30, 2015 at 12:55:35 PM UTC-6, Lesley Kimmel wrote:
>
> All;
>
> I work in a DoD environment where the blanket directive is that everything
> must be secured according to security technical implementation guides
> (STIG). There are general guides that apply to various technologies:
> database, web server, OS, application servers, etc. Any time that there is
> a component that falls into one of the categories that has a guide it must
> be configured as closely as possible to the guide. Some deviations may be
> acceptable if a mitigation can be identified.
>
> Katello+Foreman+Pulp has a lot of configuration that would apply: MongoDB,
> PostgreSQL, Apache, Tomcat, and possibly the Ruby code itself. Has anyone
> else had to put any thought into this issue? I'm primarily concerned that
> the only way to achieve this is to make a single change and then test the
> system for any operational change. This would take an excessively long
> time.
>
For clarity - the reason I reinstall after each test is that I've had
varying results when trying to apply security lock-downs to an installed
system. I've found it cleaner to do fresh installs on each test.
I'm probably not offering anything you don't already know…As of today,
there are currently no MongoDB specific STIGs published by DISA as far as I
can see, the link previously posted does download the July2015 SRG for a
generic database. That would leave you with going off the higher level
Database SRG.
The SRG is problematic in a generic sense like you mention because the
purpose of the SRG is to classify what the technology "should" be capable
of, where the STIG relates to what SRG controls are both "applicable" and
"configurable" only. If Mongo Enterprise is offering a STIG, it's likely
to be an unofficial draft that has not yet been submitted to DISA. By
comparison, DISA currently publishes STIGs for Oracle 11g, 11.2g, 12c, and
Exadata and Micosoft SQL Server 2012; while MySQL and Microsoft SQL 2014
are noted as in draft stage under development, MongoDB isn't mentioned at
all. This information should be available publicly
here: http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx.
From the legal perspective, there are some STIGs published on the IASE
site, which require DoD PKI to obtain, this implies they are at least
marked FOUO.
Regarding your challenges with the variety of components involved within a
DoD environment… I'm in a similar boat as you are, though I'm just using
puppet and foreman. To date I've not had to address applying the STIG to
Foreman's components, but I'm sure as my project develops that will become
a requirement in some way. It might be nice if the RH folks on this
project (since Satellite Server 6 is an RH product) can get together with
Shawn Wells (RH's Govt. guy of openscap security guide project fame) and
talk about those issues in some meaningful way to us DoD folks who are
interested in using Satellite or Katello/Foreman.
···
On Monday, February 1, 2016 at 9:57:38 AM UTC-5, Lesley Kimmel wrote:
>
> Has anyone on this thread had any progress with securing
> Satellite/Katello? I've just begun using the DoD-provided security
> requirements guide to secure MongoDB. The downside is that the direction is
> very generic and only states what type of security should be provided by
> the database but no product-specific way to do it. Therefore, I am slogging
> through and having to learn MongoDB as I go. I would love to have gotten my
> hands on the STIG published by the MongoDB folks but they will not provide
> it unless I am a customer paying for their "enterprise" product. Has anyone
> gotten their hands on this STIG document? Can it [legally] be shared?
>
> Thanks,
> -LJK
>
> On Monday, November 30, 2015 at 12:55:35 PM UTC-6, Lesley Kimmel wrote:
>>
>> All;
>>
>> I work in a DoD environment where the blanket directive is that
>> everything must be secured according to security technical implementation
>> guides (STIG). There are general guides that apply to various technologies:
>> database, web server, OS, application servers, etc. Any time that there is
>> a component that falls into one of the categories that has a guide it must
>> be configured as closely as possible to the guide. Some deviations may be
>> acceptable if a mitigation can be identified.
>>
>> Katello+Foreman+Pulp has a lot of configuration that would apply:
>> MongoDB, PostgreSQL, Apache, Tomcat, and possibly the Ruby code itself. Has
>> anyone else had to put any thought into this issue? I'm primarily concerned
>> that the only way to achieve this is to make a single change and then test
>> the system for any operational change. This would take an excessively long
>> time.
>>
>
Just a thought; isn't MongoDB being replaced by PostgreSQL in Pulp?
Implement the relevant upgrade when it drops a D you'll no longer have to lock down MongoDB. A bit like we're not planning to lock down ElasticSearch as it will hopefully have vanished in the next Satellite release.
I sort of get that. However, what if the updates you are making are to a
database. The Katello (or Satellite) installation reinstalls the entire
database, correct? This would be overwriting your changes every time.
···
On Tue, Dec 1, 2015 at 10:40 AM, Duncan Innes wrote:
For clarity - the reason I reinstall after each test is that I’ve had
varying results when trying to apply security lock-downs to an installed
system. I’ve found it cleaner to do fresh installs on each test.
Is it? I just got done reading the pulp wiki on why the developers chose
mongo. They seemed pretty committed. Although it would make securing
foreman/katello easier if it just used a single DB.
···
On Feb 1, 2016 5:03 PM, "Duncan Innes" wrote:
Just a thought; isn’t MongoDB being replaced by PostgreSQL in Pulp?
Implement the relevant upgrade when it drops a D you’ll no longer have to
lock down MongoDB. A bit like we’re not planning to lock down ElasticSearch
as it will hopefully have vanished in the next Satellite release.
I did think about that after the first edit. We only harden the OS at the
moment. Databases and the like are another challenge ahead of us.
I have test build scripts, however, that create a fresh CentOS7 OS
platform, then run katello-installer followed by some hammer CLI commands
that build me a new Katello instance in around an hour. All the build
packages are (or can be) local to my machine, along with the repos that I
sync into Katello once running. The new build is in a KVM virtual machine
running on my laptop, with all repos served from the host OS. A big SSD
and plenty of RAM makes this less tedious, but no less repetitive.
I would just stick in the new database/app hardening scripts somewhere in
the middle or start of the hammer CLI database populate stuff.
Yeah - I searched for reasons why I thought that as soon as I posted it.
Not sure where the idea comes from now.
Possible red-herring in my brain - sorry. Will search some more.
···
On Tuesday, 2 February 2016 18:53:38 UTC, Lesley Kimmel wrote:
>
> Is it? I just got done reading the pulp wiki on why the developers chose
> mongo. They seemed pretty committed. Although it would make securing
> foreman/katello easier if it just used a single DB.
> On Feb 1, 2016 5:03 PM, "Duncan Innes" <dun...@innes.net > > wrote:
>
>> Just a thought; isn't MongoDB being replaced by PostgreSQL in Pulp?
>>
>> Implement the relevant upgrade when it drops a D you'll no longer have to
>> lock down MongoDB. A bit like we're not planning to lock down ElasticSearch
>> as it will hopefully have vanished in the next Satellite release.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Foreman users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/foreman-users/_9sOAlD0Mkg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> foreman-user...@googlegroups.com .
>> To post to this group, send email to forema...@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/foreman-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
The OS doesn't really concern me at all. That's definitely the easy part.
Changing these databases that I don't know or understand the structure of
concerns me.
···
On Tue, Dec 1, 2015 at 2:28 PM, Duncan Innes wrote:
I did think about that after the first edit. We only harden the OS at the
moment. Databases and the like are another challenge ahead of us.
I have test build scripts, however, that create a fresh CentOS7 OS
platform, then run katello-installer followed by some hammer CLI commands
that build me a new Katello instance in around an hour. All the build
packages are (or can be) local to my machine, along with the repos that I
sync into Katello once running. The new build is in a KVM virtual machine
running on my laptop, with all repos served from the host OS. A big SSD
and plenty of RAM makes this less tedious, but no less repetitive.
I would just stick in the new database/app hardening scripts somewhere in
the middle or start of the hammer CLI database populate stuff.
> From: "Lesley Kimmel" <lesley.j.kimmel@gmail.com>
> To: foreman-users@googlegroups.com
> Sent: Tuesday, December 1, 2015 3:35:26 PM
> Subject: Re: [foreman-users] Re: [Katello] Security Guidance
>
> The OS doesn't really concern me at all. That's definitely the easy part.
> Changing these databases that I don't know or understand the structure of
> concerns me.
Can you share the security guidelines? Or perhaps particular items
you're interested in changing?
Do keep in mind Katello is using puppet for the installer and upgrades, so
manual changes could get overwritten. If the guidelines seem reasonable and
interesting to a wider audience we can change the defaults or make them at
least configurable.
For databases, we use PostgreSQL and Mongo, neither of which have CIS benchmarks
AFAIK, but if you take a look at something like the MySQL benchmark and how the
puppetlabs-mysql module configures things out of the box, you'd find the scored
items (for the most part) pass already. I'd expect you might find our configurations for
Mongo and PostgresSQL aren't too far away from where you need to be too.
Stephen
···
----- Original Message -----
On Tue, Dec 1, 2015 at 2:28 PM, Duncan Innes duncan@innes.net wrote:
I did think about that after the first edit. We only harden the OS at the
moment. Databases and the like are another challenge ahead of us.
I have test build scripts, however, that create a fresh CentOS7 OS
platform, then run katello-installer followed by some hammer CLI commands
that build me a new Katello instance in around an hour. All the build
packages are (or can be) local to my machine, along with the repos that I
sync into Katello once running. The new build is in a KVM virtual machine
running on my laptop, with all repos served from the host OS. A big SSD
and plenty of RAM makes this less tedious, but no less repetitive.
I would just stick in the new database/app hardening scripts somewhere in
the middle or start of the hammer CLI database populate stuff.
Generally speaking there exist Security Requirements Guides (SRG) that
generically describe types of changes that should be applied (if possible)
to various technologies (e.g. database, web server, OS, etc.). Some of the
more popular vendors/projects have had Secure Technical Implementation
Guides (STIG) created. These guides use the SRG and then provide specific
settings for the target product to address the various generic rules. For
example, as you can see above, Apache has an applicable STIG, but
PostgreSQL and MongoDB do not, so they will be governed by the database
SRG. I found that the MongoDB project will provide a STIG upon request ( https://docs.mongodb.org/manual/administration/security-checklist/) as
well.
I'm personally rather familiar with configuring systems to meet STIG
requirements but it becomes much more difficult if one doesn't fully
understand the interactions between all of the components being secured. In
this regard Katello is somewhat of a black box. Granted it is open-source
and any of it could be tracked down if one had the time.
Please do let me know your thoughts and maybe I can help in some way under
your guidance (based on your wording in your message I assume you are
involved in the project in some way).
Thanks!
-[Mr.] Lesley Kimmel, RHCE
···
On Tue, Dec 1, 2015 at 9:21 PM, Stephen Benjamin wrote:
The OS doesn’t really concern me at all. That’s definitely the easy part.
Changing these databases that I don’t know or understand the structure of
concerns me.
Can you share the security guidelines? Or perhaps particular items
you’re interested in changing?
Do keep in mind Katello is using puppet for the installer and upgrades, so
manual changes could get overwritten. If the guidelines seem reasonable and
interesting to a wider audience we can change the defaults or make them at
least configurable.
For databases, we use PostgreSQL and Mongo, neither of which have CIS
benchmarks
AFAIK, but if you take a look at something like the MySQL benchmark and
how the
puppetlabs-mysql module configures things out of the box, you’d find the
scored
items (for the most part) pass already. I’d expect you might find our
configurations for
Mongo and PostgresSQL aren’t too far away from where you need to be too.
Stephen
On Tue, Dec 1, 2015 at 2:28 PM, Duncan Innes duncan@innes.net wrote:
I did think about that after the first edit. We only harden the OS at
the
moment. Databases and the like are another challenge ahead of us.
I have test build scripts, however, that create a fresh CentOS7 OS
platform, then run katello-installer followed by some hammer CLI
commands
that build me a new Katello instance in around an hour. All the build
packages are (or can be) local to my machine, along with the repos
that I
sync into Katello once running. The new build is in a KVM virtual
machine
running on my laptop, with all repos served from the host OS. A big
SSD
and plenty of RAM makes this less tedious, but no less repetitive.
I would just stick in the new database/app hardening scripts somewhere
in
the middle or start of the hammer CLI database populate stuff.
–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
On a somewhat related note, does Katello support a split-install, much
like a Puppet Master can be split into master, console & DB tiers? I
couldn't see anything obvious in the 'katello-installer --help'
output, but I'm brand new to Katello so might be missing something
obvious.
Thanks,
Matt.
···
On 2 December 2015 at 03:21, Stephen Benjamin wrote:
> ----- Original Message -----
>> From: "Lesley Kimmel"
>> To: foreman-users@googlegroups.com
>> Sent: Tuesday, December 1, 2015 3:35:26 PM
>> Subject: Re: [foreman-users] Re: [Katello] Security Guidance
>>
>> The OS doesn't really concern me at all. That's definitely the easy part.
>> Changing these databases that I don't know or understand the structure of
>> concerns me.
>
> Can you share the security guidelines? Or perhaps particular items
> you're interested in changing?
>
> Do keep in mind Katello is using puppet for the installer and upgrades, so
> manual changes could get overwritten. If the guidelines seem reasonable and
> interesting to a wider audience we can change the defaults or make them at
> least configurable.
>
> For databases, we use PostgreSQL and Mongo, neither of which have CIS benchmarks
> AFAIK, but if you take a look at something like the MySQL benchmark and how the
> puppetlabs-mysql module configures things out of the box, you'd find the scored
> items (for the most part) pass already. I'd expect you might find our configurations for
> Mongo and PostgresSQL aren't too far away from where you need to be too.
>
>
> - Stephen
>
>
>> On Tue, Dec 1, 2015 at 2:28 PM, Duncan Innes wrote:
>>
>> > I did think about that after the first edit. We only harden the OS at the
>> > moment. Databases and the like are another challenge ahead of us.
>> >
>> > I have test build scripts, however, that create a fresh CentOS7 OS
>> > platform, then run katello-installer followed by some hammer CLI commands
>> > that build me a new Katello instance in around an hour. All the build
>> > packages are (or can be) local to my machine, along with the repos that I
>> > sync into Katello once running. The new build is in a KVM virtual machine
>> > running on my laptop, with all repos served from the host OS. A big SSD
>> > and plenty of RAM makes this less tedious, but no less repetitive.
>> >
>> > I would just stick in the new database/app hardening scripts somewhere in
>> > the middle or start of the hammer CLI database populate stuff.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "Foreman users" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/foreman-users/_9sOAlD0Mkg/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > foreman-users+unsubscribe@googlegroups.com.
>> > To post to this group, send email to foreman-users@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/foreman-users.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Foreman users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to foreman-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/foreman-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Foreman users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com.
> To post to this group, send email to foreman-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/foreman-users.
> For more options, visit https://groups.google.com/d/optout.
Generally speaking there exist Security Requirements Guides (SRG) that
generically describe types of changes that should be applied (if possible)
to various technologies (e.g. database, web server, OS, etc.). Some of the
more popular vendors/projects have had Secure Technical Implementation
Guides (STIG) created. These guides use the SRG and then provide specific
settings for the target product to address the various generic rules. For
example, as you can see above, Apache has an applicable STIG, but
PostgreSQL and MongoDB do not, so they will be governed by the database
SRG. I found that the MongoDB project will provide a STIG upon request ( https://docs.mongodb.org/manual/administration/security-checklist/) as
well.
I’m personally rather familiar with configuring systems to meet STIG
requirements but it becomes much more difficult if one doesn’t fully
understand the interactions between all of the components being secured. In
this regard Katello is somewhat of a black box. Granted it is open-source
and any of it could be tracked down if one had the time.
Please do let me know your thoughts and maybe I can help in some way under
your guidance (based on your wording in your message I assume you are
involved in the project in some way).
Thanks!
-[Mr.] Lesley Kimmel, RHCE
On Tue, Dec 1, 2015 at 9:21 PM, Stephen Benjamin stephen@redhat.com > wrote:
The OS doesn’t really concern me at all. That’s definitely the easy
part.
Changing these databases that I don’t know or understand the structure
of
concerns me.
Can you share the security guidelines? Or perhaps particular items
you’re interested in changing?
Do keep in mind Katello is using puppet for the installer and upgrades, so
manual changes could get overwritten. If the guidelines seem reasonable
and
interesting to a wider audience we can change the defaults or make them at
least configurable.
For databases, we use PostgreSQL and Mongo, neither of which have CIS
benchmarks
AFAIK, but if you take a look at something like the MySQL benchmark and
how the
puppetlabs-mysql module configures things out of the box, you’d find the
scored
items (for the most part) pass already. I’d expect you might find our
configurations for
Mongo and PostgresSQL aren’t too far away from where you need to be too.
Stephen
On Tue, Dec 1, 2015 at 2:28 PM, Duncan Innes duncan@innes.net wrote:
I did think about that after the first edit. We only harden the OS
at the
moment. Databases and the like are another challenge ahead of us.
I have test build scripts, however, that create a fresh CentOS7 OS
platform, then run katello-installer followed by some hammer CLI
commands
that build me a new Katello instance in around an hour. All the build
packages are (or can be) local to my machine, along with the repos
that I
sync into Katello once running. The new build is in a KVM virtual
machine
running on my laptop, with all repos served from the host OS. A big
SSD
and plenty of RAM makes this less tedious, but no less repetitive.
I would just stick in the new database/app hardening scripts
somewhere in
the middle or start of the hammer CLI database populate stuff.
–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
Has this issue been addressed any further from what you can tell? I’m looking through the forums for any clues for Apache 2.4 STIG guidance. So far I’ve been reaching dead ends.
