Installing to a Bash Default Shell

We will use a Linux Mint laptop (based on Ubuntu 18.04) for the Lunar installation. As standard, Ubuntu has moved its default shell away from the venerable Bash to Dash to speed up boot times and lighten the load because Bash is brimming with features and a little more cumbersome. This means that when /bin/sh is called, /bin/dash is actually run instead of /bin/bash. It appears this does not play nicely with Lunar, so a simple fix is needed, as described in the following series of commands. Note that this may not apply to your system, so be careful, or potentially much of Lunar's functionality may not work on your machine if there is no default shell alteration. Reverse these changes after trying them if you do not want Bash as your default shell.

First, you can check that /bin/sh is just a symlink to Dash with this command:

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 9 Aug  8 18:49 /bin/sh -> /bin/dash

As we can see, /bin/sh is just a symlink to /bin/dash.

We will temporarily delete the symlink from Dash to /bin/sh with this command:

$ rm /bin/sh

Next, we will re-create the symlink to point at Bash with this command:

$ ln -s /bin/bash /bin/sh

You could also globally change all references from /bin/sh to /bin/bash in the Lunar scripts if that seems less impactful.

Execution

We are all set to clone the Lunar GitHub repository and run Lunar next:

$ git clone https://github.com/lateralblast/lunar.git

Enter the lunar directory with the cd command, and in Listing 15.1 we can run the main shell script to generate the help output.

Here we can see lockdown options to make changes to systems; to preserve sanity, we will avoid those so that we do not make changes to the system. Instead, we will begin with a look at auditing operating systems, which is Linux in this case.

If we choose the lowercase -a switch for the script, it will not run all the exhaustive filesystem checks, whereas the -A switch would instead provide this functionality. Let's try that now with this command:

$ ./lunar.sh -a

The output of the command is extensive to say the least and completes with this summary:

Tests:     470
Passes:    191
Warnings:  279

Listing 15.2 shows a sample of the OS auditing output.

Here we see just the upper lines of the output generated. Other areas of the checks include PAM, squid, filesystem permission, NFS, apache2, SMB, tunable kernel parameters, syslog, system accounts, and password complexity policies, to name but a few. If you have worked with the CIS Benchmarks before, you will spot a number of familiar items that need to be hardened.

Let's look at the container runtime audits next. Running this type of audit is as simple as changing the command to use the following switch (Docker needs to be installed for this set of tests):

$ ./lunar.sh -d

Again, the output is impressive and completes without much of a wait. Some of the areas of coverage include the following:

• Checking for Linux kernel capabilities for running containers (including more privileged capabilities, such as CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_MODULE, and the like)
• Whether health checks configuration is present for containers
• Which logging level the Docker Engine is using
• Whether host-based networking is enabled
• Whether auditd is picking up the actions of the container runtime
• Whether the root filesystem is read-only

Again, CIS Benchmarks are put to good use here. If you search within the cloned repository directory locally by using the next command, you will see a number of references to CIS:

$ grep -R CIS *

This command produces lengthy output, including the following:

modules/audit_docker_security.sh:# Refer to Section(s) 5.4
Page(s) 132   CIS Docker Benchmark 1.13.0
modules/audit_docker_security.sh:# Refer to Section(s) 5.9
Page(s) 141   CIS Docker Benchmark 1.13.0
modules/audit_docker_security.sh:# Refer to Section(s) 5.12
Page(s) 146–7 CIS Docker Benchmark 1.13.0
modules/audit_docker_security.sh:# Refer to Section(s) 5.15
Page(s) 152–3  CIS Docker Benchmark 1.13.0
modules/audit_docker_security.sh:# Refer to Section(s) 5.16
Page(s) 154–5  CIS Docker Benchmark 1.13.0

This output is exceptionally useful because it translates into remediating issues much more easily. Visit the CIS website and download the benchmarks directly (https://cisecurity.org/benchmark/docker) to gain more insight into any discovered issues and find remediation tips there too. In Listing 15.3, we can see some sample output from running the excellent Lunar against our container runtime.

The tool is comprehensive and does not fail to deliver from a runtime perspective either, with a significant number of checks summarized on the author's device as follows:

Tests:     1722
Passes:    1106
Warnings:  616

Cloud Auditing Against Benchmarks

To test against AWS, we need sufficient permissions attached to a role or user via a policy. Lunar offers some advice but does not provide a policy verbatim about exactly which permissions you will need to permit. You will need the AWS CLI tool installed locally. If you are not sure how to get this, the documentation can be found at https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html. You may have had it installed to set up your credentials (with the aws configure command) previously.

Also, you need to fine-tune some rules, but Figure 15.1 shows a reasonable start.

In Figure 15.1 we can see some read-only permissions. If you have not supplied the correct permissions, then certain checks will result in a permission-denied error of sorts.

There are two AWS modes to run Lunar in: recommendations mode and auditing mode. We will start with this “recommended” tests scan as follows:

$ ./lunar.sh -x

The output begins as follows:

Running:   In audit mode (no changes will be made to system)
Auditing:  AWS—Recommended Tests
# SYSTEM INFORMATION:
Virtual:   LENOVO
Processor: x86_64
Machine:   x86_64
Vendor:    LinuxMint
Name:      Linux
Version:   19
Update:    19
Checking:  EC2 Recommendations

We are then offered a number of useful suggestions such as tagging our security groups with recognizable names and pruning older EC2 snapshots. The checks include coverage of RDS, CloudWatch, RedShift, ElastiCache, Inspector, VPCs, security groups, DynamoDB, ELBs, and EC2. In Listing 15.4 we can see a sample of the output.

Next, let's run “audit” mode over an AWS account and see the difference in output. We can do this using the following command:

$ ./lunar.sh -w

This time, the output is much more familiar and relates to CIS Benchmarks. Note that, at the time of writing, there seems to be a bug within the lunar.sh script with reference to the -w switch in the latest release. Once that bug is resolved, the sample output should again be as shown in Listing 15.5. There appears to be an issue with functions being disordered within the script.

Because of the vast number of checks run in audit mode this time, the tool takes longer. If you want to select specific functions in AWS to check, use the -W switch to retrieve a list of available functions that you can choose from first. Once you've done so, you can then run Lunar using the -s switch to run in selective mode. Refer to Figure 15.1 to see the switches required for the other areas of coverage that the broad-reaching Lunar provides.

Generating Reports

We are all set to run the tool and generate reports. That was an easy process, even if the build took a little while. To get started, enter the default profile name and use the following command, which creates a PDF named scan_report.pdf :

$ npm run scan -- --profile default

Make sure that you execute that file within the cloud-reports/ directory and wait patiently for the AWS API to respond to an abundance of requests. Do not be too alarmed if, during the process, you see some errors related to createPDF ; they appear to be innocuous, but if your scan fails, use the instructions that follow to output to HTML instead. Should you be unsure if the process is working, check the Last Used section in the Security Credentials tab to see which service the tool last accessed. It will show an AWS service name and an accessed time and date associated with it (under the Last Used column), as shown in Figure 15.5.

Cloud Reports recommends running on an EC2 instance directly and, to speed things up, making sure that you have at least 2GB of RAM available. If, however, you do not want to scan everything and scan remotely, for example, then you can name specific AWS services with a command this way:

$ npm run scan -- -m s3,acm

You can also limit your regions, as follows:

$ npm run scan -- -m s3,acm -r us-east-1,eu-west-2

If you add -f html to your command, you will output to HTML format instead of to PDF. The same is true if you choose csv for a CSV file format. Adding -o will change the generated report name to something more familiar. If you have opted for HTML to avoid createPDF errors, just hit Ctrl+C when you are presented with some error output and look for the scan_report.html file. The command that generated the HTML report in Figure 15.5 was as follows:

$ npm run scan -- --profile default -m s3 -r eu-west-1 -d -u -f html

Note the -d and -u flags. The first is for debugging output to assist with troubleshooting, and the second is to reuse some of the data from previous scans in order to speed up the processing and then reduce the time it takes to produce a report. If you are frustrated with processing time because you are on a slow machine, start with as few services as possible.

The output from the tool is clean and easy to fathom. We can see in Figure 15.6 that we have only scanned AWS S3, and 21 buckets have been discovered. There are explanations in text about what Failed, Warning, Passed, and Info results mean, and there are a couple of things to note from this report.

First, out of the 21 buckets, one has been identified as having public access permissions, which is usually not a good thing at all for data loss prevention (DLP). In this case, however, it is a bucket plugged into the AWS CloudFront CDN service with public assets such as website images, so it is safe. The other warnings are that the buckets do not have cost optimization enabled with “Bucket Life cycle rules are not configured,” and we are dutifully told to “Configure life cycle rules” as a result.

EC2 Auditing

The report for EC2 on this particular AWS account is not quite as complimentary. The command used was as follows:

$ npm run scan -- --profile default -m s3 -r eu-west-1 -d -u -f html

For example, two keypairs were unused and in two different security groups: “SSH Port is open to entire world.” What did pass with flying colors, however, were the MySQL, RDS, Oracle, and Postgres ports, which were all closed within the security groups.

The welcome detail from Cloud Reports is that the auditing is still very comprehensive, even though in that region there were not any running EC2 instances. In Figure 15.7 we can see just how thorough it is.

You can apparently also run Cloud Reports against Microsoft Azure, too. When it is processing the associated API data, it first sorts them into collectors, which look something like the JSON shown in Listing 15.7.

The next part of the process involves what are called analyzers. As you may have guessed, these rules, of sorts, check against known best practices on the cloud platform of choice and are then run past the data found by the collectors. Listing 15.8 shows the analyzer output for reference.

Finally, the reporters generate the file type from the analysis as you would expect.

The excellent Cloud Reports is well worth a look. The attention to detail is invaluable to assist in periodically auditing the security posture of your AWS accounts.