For hardening you should use the best practice in form of the Center for Internet Security (CIS) benchmarks. Each benchmark contains a number of single atomar tests that are well described and discussed in the CIS expert community. Before a benchmark is finally published it runs through a defined quality assurance process which is kind of a guarantee, that no essential aspects are overseen. In practice CIS benchmarks are often seen as to challenging, to expensive in terms of the amount of work for the system engineers. But exactly this effort makes environments more sustainable against new attack methods, new vulnerabilities and zero days which you can’t avoid if your business is visible in public. To access the CIS Assessor you need a CIS membership which is around 3.630$/year for a consultant.

You start in a management network. The CIS Assessor is the test driver. It needs access in some way to the test objects – your network components, your servers, your containers, your clients. You can and probably should have multiple Assessors for different purposes in large environments.

figure 1: CIS Assessor placed in managment subnet (shared) of a typical web-app vpc

The Assessor is placed in the managment subnet, see figure 1. The management subnet is owned by the engineering department whereas the machine itself is owned by the security staff. The tests on linux images are done via ssh (port 22), the tests of windows is done via winrm over https (port 5986). The CIS Assessor is an independent java application and CIS provides the “dashboard” which is a separate Tomcat WebApp with a database. It is recommended to split the dashboard up in WebApp and database layer for security reasons. Here we have the WebServer (called cisdb as apache) -see figure 1 in 10.0.21.228- and the jump server -10.0.21.64- in the shared WebApp subnet and the Assessor with tomcat and MySQL database on a single node. The reasoning for this design is that we do not expose the WebServer (cisdb) to the public and we can secure both standard components by themselves, by subnet ACLs and security groups, so this is “ok” for short. The Assessor is based on a t2.medium instance, which means 2 vCPUs, 8GB RAM. This is sufficient for doing the tests, one after the other. Nevertheless 8 GB RAM is a lower limit, as sometimes you will get OutOfMemory Exceptions when the Assessor pushes the test result to the dashboard (Tomcat WebApp).

The installation starts with java. Generally you should not try to use newer versions than mentioned in the docs -it will simply not work- for now you should use MySQL 5.7, java 1.8, Tomcat 8.

First update the image to the current patch level with

$ sudo yum update

figure 3: patching succeded

next you install java:

$ sudo yum install java-1.8.0-openjdk.x86_64

which should give you:

figure 4: java installed

Next step is to download the Assessor from the CIS Workbench. As the Assessor image has no public IP address you download it on the jump server and use your favorite scp to put it into /home/ec2-user on the Assessor image.

figure 5: downloaded CIS modules

$ unzip Assessor-v4.2.0.zip

This creates all the infrastructure, missing is still the license which you download from your CIS Workbench profile. Via the jump server you put it in the license folder.

figure 6: License

Unzip the license there and then test it from the Assessor folder:

figure 7: first self test

Now you can use it interactively, just to try out the set of options

$ /home/ec2-user/Assessor-CLI/Assessor-CLI.sh -i

which shows the huge amount of benchmarks (currently 88) which are available for automatic testing. But good to know, not all benchmarks are available.

The usual way is now to create configuration files to specify the tests. There is a friendly sample configuration file:

figure 8: configuration files for own tests

which we can adopt to a first Level 1 test of the local linux2 image and start with:

figure 9: first own test

This takes a little time and should come to

figure 10: test finished correctly

As we see, the fresh Linux2 earned 57,89% of the possible points, there is room for improvement 🙂

Whenever there is a problem with tests we can use the log levels (Error) option -v up to (All) with -vvvvv. The log is as expected in the logs folder.

Part of the CIS offering is the dashboard. Installation requires the Tomcat and…

MySQL.

$ sudo amazon-linux-extras install epel -y

$ sudo wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm

$ sudo yum localinstall mysql57-community-release-el7-11.noarch.rpm

$ sudo yum install mysql-community-server

figure 11: start mysql

Now we secure the MySQL installation

$ sudo mysql_secure_installation

This requires setting a new password and answering the questions below:

figure 12: securing mysql as part of the installation

Then we create the tomcat database user for later usage:

$ mysql -h localhost -u root -p

mysql> create user 'tomcat'@'localhost' identified by 'ComplexPassword';
Query OK, 0 rows affected (0.00 sec)

mysql>; CREATE DATABASE ccpd CHARACTER SET utf8 COLLATE utf8_general_ci;

Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON 'CCPD.*' TO 'tomcat'@'localhost' identified by 'AnotherComplexPassword';

mysql>quit

Tomcat

The typical tomcat installation:

$ sudo groupadd tomcat
$ sudo useradd -M -s /bin/nologin -g tomcat -d /opt/tomcat tomcat

and install the latest tomcat 8 available..

$ wget https://mirror.ibcp.fr/pub/apache/tomcat/tomcat-8/v8.5.61/bin/apache- tomcat-8.5.61.tar.gz

$ sudo chmod -R g+r conf
$ sudo chmod g+x conf
$ sudo chown -R tomcat webapps/ work/ temp/ logs/
$ sudo systemctl daemon-reload

Create the service file

$ sudo vi /etc/systemd/system/tomcat.service

[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target
[Service]
Type=forking
Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always
[Install]
WantedBy=multi-user.target

and start the service:

figure 12: tomcat started

To secure the access to the manager web app we edit the

$ sudo vi /opt/tomcat/conf/tomcat-users.xml

figure 13: adjust the users

restrict access to the manager app further to the jump host

$ sudo vi /opt/tomcat/webapps/manager/META-INF/context.xml

figure 14: limit access to the manager webapp

$ sudo vi /opt/tomcat/webapps/host-manager/META-INF/context.xml

figure 15: limit access to the host manager

add some specific variables to the catalina startup file

$ sudo vi /opt/tomcat/bin/catalina.sh

figure 16: CCPD variables

and remove the sample webapps from tomcat standard installation

$ sudo rm -r /opt/tomcat/webapps/docs
$ sudo rm -r /opt/tomcat/webapps/examples

$ cd 

$ sudo mv CIS-CAT_Pro_Dashboard_v1.1.13-unix.zip /opt/tomcat/

finally we configure the tomcat connector in

/opt/tomcat/conf/server.xml

to accept uploads with a bigger size as default to allow the Assessor to push the results to the dashboard.

<Connector port="8080" protocol="HTTP/1.1"  connectionTimeout="20000" redirectPort="8443" maxPostSize="35728640"/>

The dashboard

$ cd /opt/tomcat

$ sudo unzip CIS-CAT_Pro_Dashboard_v1.1.13-unix.zip

$ cd CIS-CAT_Pro_Dashboard_v1.1.13-unix/

$ sudo chmod 744 CIS-CAT_Pro_Dashboard_Installer.sh

and answer the questions of the installer:

$ sudo ./CIS-CAT_Pro_Dashboard_Installer.sh

After the installer is completed you may test the deployment of the CCPD WebApp

figure 17: testing the CCPD deployment

As we have the apache webserver in the shared subnet bound to the name cisdb (not shown here) we can direct the browser to https://cisdb.uneedsecurity.com.dedivirt3228.your-server.de to see the new blank Dashboard. We restrict this dashboard to the security department.

CIS Dashboard ready for testing

This is the base for all subsequent test efforts. The Assessor is installed in the management subnet. It performs the tests via ssh for linux systems and winrm for Windows systems. It will publish its benchmark-results to the Dashboard.