## 1. Project Overview & Quickstart (dev-sec/developercertificate.org) # developercertificate.org Open-source repository dev-sec/developercertificate.org ### Repository Details - **Repository:** [dev-sec/developercertificate.org](https://github.com/dev-sec/developercertificate.org) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (dev-sec/docs) ## File: README.md # Hardening Framework Documentation We use [MkDocs](http://www.mkdocs.org/) to document all hardening projects ## Build # build the site mkdocs build # update master branch ghp-import -b gh-pages -p site ## Author * Author:: Christoph Hartmann * Author:: Hardening Framework Team * Author:: Deutsche Telekom AG Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --- ## File: docs/coding/contributing.md # Contributing The general steps are: - Create a ticket in Github Issues. - Fork the repository on GitHub. - Clone the repository on your local system. - Create a branch and make your changes. - Push the branch, create a pull request and [reference the issue in your pull request](https://github.com/blog/1506-closing-issues-via-pull-requests). Read on for detailed steps ## License This project is Apache 2 licensed. Every contribution must be under the Apache 2 License too. For new files we have added a section with [License Headers](/docs/license-headers). ### Sign your work In addition to the license we only accept contributions signed as your work. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below (from [developercertificate.org](developercertificate.org)): ``` Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 660 York Street, Suite 102, San Francisco, CA 94110 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ``` then you just add a line to every git commit message: HardeningFramework-DCO-1.1-Signed-off-by: Joe Smith (github: github_handle) using your real name (sorry, no pseudonyms or anonymous contributions.) One way to automate this, is customise your get ``commit.template`` by adding a ``prepare-commit-msg`` hook to your hardening project checkout: ``` curl -o .git/hooks/prepare-commit-msg https://raw.githubusercontent.com/hardening-io/docs/master/docs/contrib/prepare-commit-msg.hook && chmod +x .git/hooks/prepare-commit-msg ``` * Note: the above script expects to find your GitHub user name in ``git config --get github.user``, set it with `git config --global github.user ` ## Contributing to the Hardening Framework Projects Below, replace "REPO" with the project that should be changed. Replace "USER" with your GitHub username. 0. Create a issue for the bug, feature or improvement you are contributing. See [Mastering Issues](https://guides.github.com/features/issues/) for details 1. Fork the repository on GitHub. HardeningFramework/REPO -> USER/REPO You can replace REPO in your fork with a name for the repository that makes it unique, if required. 2. Clone the repository locally ``` git clone git@github.com:USER/REPO.git ``` 3. Ensure the origin is your repository. ``` git config remote.origin.url git@github.com:USER/REPO.git ``` 4. Add Hardening Framework REPOs as a remote named `upstream` and track it instead of your origin. ``` git remote add upstream git://github.com/hardening-io/REPO.git git config branch.master.remote upstream ``` 5. Make sure your master branch is updated. ``` git checkout master git pull --rebase ``` 6. Create a new branch for the ticket. ``` git checkout -b ISSUE-#### ``` 7. Make your changes and push the branch to your origin. ``` git push origin ISSUE-#### ``` 8. [Reference the ISSUE](https://github.com/blog/1506-closing-issues-via-pull-requests) in your [Github Pull Request](https://help.github.com/articles/using-pull-requests). We will review the issue and contribution as soon as possible. ### Some Tips In order to have your contribution accepted as quickly as possible, we have some requests for you. These make it easier to merge contributions without merge conflicts, and keep the scope on topic for a specific issue. - Please do not update the version in the metadata.rb (chef) or Modulefile/metadata.json (Puppet) files. We handle that as part of the release process. - Please do not update the CHANGELOG.md. We handle that as part of the release process. - Please do not mix style changes that are not related to the specific ticket. Create a new, separate ticket for style updates. For example, if a REPO has Foodcritic findings, create a separate ticket to handle those. See the section on linting. - Follow the current style of the code where appropriate. - Run the provided lint, spec and integration tests --- ## File: docs/coding/headers.md # File headers ## Ruby ```ruby # encoding: utf-8 # # Copyright 2015, Hardening Framework Team # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # ``` ## JavaScript ```javascript /* Copyright 2014 Hardening Framework Team * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ ``` ## Python ```python # Copyright 2014 Hardening Framework Team # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ``` ## HTML ```html ``` --- ## File: docs/coding/linting.md # Linting We run several linting tools in our continuous integration pipeline. If you create a pull request the CI will kick in and run [Rubocop](https://github.com/bbatsov/rubocop) for every project as well as [Foodcritic](http://www.foodcritic.io) for chef repos or [puppet-lint](http://puppet-lint.com) for puppet repos. The tasks are provided as Rake Tasks ready to run an give feedback. Here the example output of the [chef-os-hardening project](https://github.com/hardening-io/chef-os-hardening) (kitchen-tasks stripped): ```shell ± bundle exec rake -T rake acceptance # Alias for kitchen:all rake foodcritic # Run foodcritic lint checks rake integration # Run all tests except Kitchen (default task) rake kitchen:all # Run all test instances [ ... kitchen-tasks stripped ... ] rake lint # Run linters rake rubocop # Run Rubocop lint checks rake run_all_linters # Run all linters: rubocop and foodcritic rake spec # Run chefspec tests rake test # Run all tests ``` The CI is configured to run the common task `rake run_all_linters ` in all the projects. Example of a successful run: ```shell ± bundle exec rake run_all_linters Running RuboCop... Inspecting 20 files .................... 20 files inspected, no offences detected Running Foodcritic tests... done. ± echo $? 0 ``` The CI evaluates the return code of the task, which is `0` if no offences are found. The task will fail fast. Meaning we run [Rubocop](https://github.com/bbatsov/rubocop) first and the specific linter (if any) next. A failed run of rubocop looks like the following output: ``` ± bundle exec rake run_all_linters Running RuboCop... Inspecting 20 files ....C............... Offences: recipes/default.rb:22:1: C: Extra blank line detected. 20 files inspected, 1 offence detected RuboCop failed! ± echo $? 1 ``` The exit code is `1` indicating that one of the linters involved found an offence. Following an example in a chef cookbook were rubocop is successful but foodcritic found an offence: ```shell ± bundle exec rake run_all_linters Running RuboCop... Inspecting 20 files .................... 20 files inspected, no offences detected Running Foodcritic tests... done. FC019: Access node attributes in a consistent manner: /.../recipes/default.rb:29 rake aborted! FC019: Access node attributes in a consistent manner: /.../recipes/default.rb:29 /.../.rvm/gems/ruby-2.1.1/gems/foodcritic-3.0.3/lib/foodcritic/rake_task.rb:33:in `block in define' /.../.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `eval' /.../.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `
' Tasks: TOP => run_all_linters => foodcritic (See full trace by running task with --trace) ± echo $? 1 ``` ### Ruby - Rubocop [Rubocop](https://github.com/bbatsov/rubocop) catches a lot of basic syntax infractions and provides ruby best practice advise like using double quotes for strings that do not interpolate Ruby variables, or using simple if/else statements when a one-line ternary operator would be sufficient. This helps enforcing a common style guide and avoiding time consuming best practice discussions in pull requests. Have a look at [A community-driven Ruby coding style guide](https://github.com/bbatsov/ruby-style-guide) for further details. Every project has a rake task to run rubocop as well as a task where all linters for the project are run, including rubocop: ``` ± bundle exec rake -T|grep rubocop rake rubocop # Run Rubocop lint checks rake run_all_linters # Run all linters: rubocop and foodcritic ``` Rubocop honors the `.rubocop.yml` file of the project. Example successful run of rubocop: ```shell ± bundle exec rake rubocop Running RuboCop... Inspecting 6 files ...... 6 files inspected, no offences detected ± echo $? 0 ``` ### Chef - Foodcritic [Foodcritic](http://www.foodcritic.io) is a special linter for chef cookbooks. The rake task is configured to fail on `any` violation. We, as a project, decided to use the single quoted string node attribute notation to honor [FC019](http://www.foodcritic.io/#FC019). There are some edge cases were, upon discussion a violation is tolerated. This can be done with a special markup in the code itself. Following an example (taken from [chef-ssh-hardening server.rb](https://github.com/hardening-io/chef-ssh-hardening/blob/master/recipes/server.rb#L41)) ```ruby search('users', "#{field}:*").map do |v| # ~FC003 ignore footcritic violation Chef::Log.info "ssh_server: installing ssh-keys for root access of user #{v['id']}" v[field] end.flatten ``` Here we acknowledge [FC003](http://www.foodcritic.io/#FC003) as this cookbook will always need search in order to work and we use solo-search in testing. Every chef project has a rake task to run foodcritic as well as a task were all linters for the project are run, including rubocop: ``` ± bundle exec rake -T |grep foodcritic rake foodcritic # Run foodcritic lint checks rake run_all_linters # Run all linters: rubocop and foodcritic ``` Example successful run of foodcritic ``` ± bundle exec rake foodcritic Running Foodcritic tests... done. ± echo $? 0 ``` ### Puppet - Puppet-Lint [Puppet-Lint](http://puppet-lint.com) is a special linter for puppet modules. The rake task is configured to fail on `any` violation. ``` ± bundle exec rake -T |grep puppet-lint rake lint # Run puppet-lint / Check puppet manifests with puppet-lint rake run_all_linters # Run all linters: rubocop and puppet-lint ``` We disabled some checks from puppet-lint ``` ± grep Lint Rakefile PuppetLint.configuration.send('disable_autoloader_layout') PuppetLint.configuration.send('disable_80chars') PuppetLint.configuration.send('disable_inherits_across_namespaces') PuppetLint.configuration.fail_on_warnings = true PuppetLint.configuration.ignore_paths = ['vendor/**/*.pp'] ``` If everything is well the exit code is 0, and no further output is displayed: ``` ± bundle exec rake lint ± echo $? 0 ``` If there is an error or a warning you get some output and an exit code <> 0 ``` ± bundle exec rake lint manifests/init.pp - WARNING: double quoted string containing no variables on line 10 rake aborted! /.../.rvm/gems/ruby-2.1.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/puppet-lint.rb:25:in `block (2 levels) in initialize' /.../.rvm/gems/ruby-2.1.1/gems/puppet-lint-0.3.2/lib/puppet-lint/tasks/puppet-lint.rb:13:in `block in initialize' /.../.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `eval' /.../.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `
' Tasks: TOP => lint (See full trace by running task with --trace) ± echo $? 1 ``` --- ## File: docs/chef.md # Chef overview The following modules are part of the hardening framework: Base Operating System * [chef-os-hardening](https://github.com/hardening-io/chef-os-hardening) * [chef-ssh-hardening](https://github.com/hardening-io/chef-ssh-hardening) Database * [chef-mysql-hardening](https://github.com/hardening-io/chef-mysql-hardening) * [chef-postgres-hardening](https://github.com/hardening-io/chef-postgres-hardening) Web Server * [chef-nginx-hardening](https://github.com/hardening-io/chef-nginx-hardening) * [chef-apache-hardening](https://github.com/hardening-io/chef-apache-hardening) Example * [example-chef-hardening](https://github.com/hardening-io/example-chef-hardening) ## Publishing Cookbooks ### Stove-route The easy way: gem install stove stove login --username YOURNAME --key ~/.chef/YOURKEY.pem cd chef-os-hardening stove In case of errors: Use the method below to ensure that your `metadata.rb` is configure correctly. If you cannot generate a `metadata.json`, fix this error first. ### Chef-route We will use `chef-ssh-hardening` as an example project. 1. Install chef gem install chef 2. Since development happens locally, define your ssh key in your chef config ~/.chef/knife.rb client_key "#{ENV['HOME']}/.ssh/id_rsa" cookbook_license "apachev2" cookbook_copyright "" cookbook_email "" 3. Copy to temporary cookbooks location mkdir /tmp/cookbooks cp -r . /tmp/cookbooks/ssh-hardening 4. Generate `metadata.json` knife cookbook metadata ssh-hardening -o /tmp/cookbooks 5. Generate tarball knife cookbook site share ssh-hardening "ssh-hardening" -o /tmp/cookbooks --- ## File: docs/faq.md # Frequently asked questions ### Is it possible to use the toolkit without internet connection Yes, it is possible to use the hardening scripts on computers without internet connection. You need to ensure two specific things: * Configured package repository access (eg. RedHat Satellite) * Manual installation of chef or puppet To run the scripts via chef without internet and chef server, do the following. 1. Download the chef package for your operating system. ```bash wget https://opscode-omnibus-packages.s3.amazonaws.com/ubuntu/13.04/x86_64/chef_11.12.8-2_amd64.deb ``` Transfer the the package and the cookbooks on your servers and start the run: ```bash echo "---> Install Chef" dpkg -i chef_11.12.8-2_amd64.deb echo "---> Start chef run in local mode" # runs chef client in local mode chef-client -z -o yourcookbook ``` More information about about chef in local mode is available at [getchef.com](http://www.getchef.com/blog/2013/10/31/chef-client-z-from-zero-to-chef-in-8-5-seconds/) ### How do I configure LDAP authentication with ssh-hardening Configure the `ssh-cookbook` with `use-pam: true`. This enables the PAM authentication via ssh. In addition you need to configure [PAM properly to work with LDAP](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Directory_Servers.html#s2-ldap-pam). The configuration of PAM for LDAP is not covered by `os-hardening` or `ssh-hardening`. --- ## File: docs/index.md # Automatic server hardening Server hardening is a well-known topic with many guides out in the wild. Why this project? At Deutsche Telekom we need to manage thousands of servers for customers and ourselves. All servers need to be configured properly and maintained, which is difficult and time-consuming to get right. To answer these needs for security, compliance, and maintainability, we decided to launch this project as a common ground for requirements and their fulfillment. ## Vision / Goal Our goal is simple: Create a common layer for hardening operating systems and services easily and without interference. Even if you aren't knee-deep in configuration manuals for services or the latest security recommendations, you will be able to implement and use this framework with ease. ## Scope Since we use Chef and Puppet to automate our deployments, we decided to put them to work for system hardening. The hardening project is currently limited to Chef and Puppet, though extensions to other automation frameworks are welcome! **What is part of hardening?** * **Attack surface reduction**: Use service configurations to remove all those components, that are often activated for legacy compatibility or simplified setups. Some default configurations these days already cover good security practices. We take a step further and make sure to deactivate all application modules, which aren't usually required. This baseline changes over time. We keep track of these developments and integrate them with this project. * **Secure configuration**: It's easy enough to find a guide in a 2 minute search which will tell you to "Set this to 0 and everything will work". Without investigation, it's difficult to know what implications a few configuration lines may carry. Moreover, even a simple starting configuration can quickly make it into a production setup. To avoid these easy mistakes, we make the configuration explicit and default to a secure baseline. Many settings aren't changeable and some will yield errors and warnings with this framework. * **Core components**: Anything from the basic operating system to well known databases and web servers is part of this project. We want these common building blocks to be at their optimal configuration and avoid repeated mistakes. **What is NOT part of hardening?** * **Patch management**: We track changes and will update every piece of this project to work with current and older supported versions of operating systems and applications. However, we cannot safely automate all aspects of patch management. Nevertheless, you can easily integrate hardening into your patch management lifecycle. * **Minor components**: It's easy to set up a configuration for a service at some point of time and make it secure. It's much more difficult to maintain it over time and support it. We will focus on wide-spread services and components and support them with your and our feedback. * **Complex configurations**: This includes: Firewall configurations, web-application firewalls, AppArmor profiles or SELinux configurations, amongst others. These are incredibly important to have in your environment, however, their configuration is too dependent on specific setups to abstracted properly. We decided to focus on those components, that are able to take a generalized into their configuration. For everything else, feel free to get in touch with us. ## Lifecycle Let's take a quick look at the full lifecycle for servers and services and see where hardening fits in. ### Installation of OS We recommend to install operating systems from trusted sources. This could be an operating system vendor or a trusted third party. In virtualized environments like OpenStack, the secure generation of base images is part of our daily activity. We have automated the building of RedHat, CentOS and Oracle Linux based instances. * [packer-rhel](https://github.com/TelekomLabs/packer-rhel) ### Hardening We provide multiple cookbooks for chef and modules for puppet to cover this area. We use best-known guides like [Deutsche Telekom (German)](http://www.telekom.com/static/-/155996/7/technische-sicherheitsanforderungen-si), [BetterCrypto](https://bettercrypto.org/) and the [NSA hardening guide](http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf). For more details look into the respective `test-` repository. Checks are implemented following these guides. ### Continuous management This area includes tasks like patch management, attack monitoring, and fixing known vulnerabilities. None of these areas are covered in this hardening project. #### Patch management It is the heart of keeping your systems secure once everything is in place. So why not patch automatically on every run? We have considered this option for our hardening components but ultimately decided against it: Patches generally aren't a trivial thing to do. Even if you reduce it to security updates only, there may still be regressions which have to be weighted against benefits. Set up a patch management system of your choice. #### Attack monitoring Hardening includes a small section of compliance monitoring. Every time an attacker changes a core system configuration, you can gain insights into this through hardening. Since all of our components are tested independently, you can potentially use these tests to validate the compliance of your configuration. However, we recommend against putting too much weight on the results you get. The tests created here are written to verify hardening instructions. Attackers may still find ways to modify files in a way that gets around these checks (example: if we check `main.cfg` only, but attacker writes to `main.cfg.d/my.cfg`). Use HIDS, auditing, and monitoring systems to manage these risks. #### Vulnerability fixes A remainder of vulnerabilities may still remain after successful patch management. There are vulnerabilities that need mitigation before proper vendor fixes are released. We won't cover such vulnerabilities in this project. Many settings, however, are meant to reduce the attack surface and thus directly contribute to reducing the risks from unpatched vulnerabilities. --- ## File: docs/principles.md # Principles This section records decisions for all defaults and options we set. --- ## File: docs/puppet.md # Puppet overview The following modules are part of the hardening framework: Base Operating System * [puppet-os-hardening](https://github.com/hardening-io/puppet-os-hardening) * [puppet-ssh-hardening](https://github.com/hardening-io/puppet-ssh-hardening) Database * [puppet-mysql-hardening](https://github.com/hardening-io/puppet-mysql-hardening) * [puppet-postgres-hardening](https://github.com/hardening-io/puppet-postgres-hardening) Web Server * [puppet-nginx-hardening](https://github.com/hardening-io/puppet-nginx-hardening) * [puppet-apache-hardening](https://github.com/hardening-io/puppet-apache-hardening) Example * [example-puppet-hardening](https://github.com/hardening-io/example-puppet-hardening) ## Publishing Puppet Modules Simple enough: If you have your `Modulefile` and `metadata.json` ready, just run: cd puppet-xxx-hardening/ puppet module build . Results are in pkg. The two files may not get merged correctly, so please diff: colordiff metadata.json pkg/puppet-*-hardening/metadata.json