Lab 8

Lab 8-1

This lab will only work on an EC2 instance using Amazon Linux 2 (not the 2023 version). The LAMP stack instance created in Lab 5 is used for this purpose.

Prerequisites

First, ensure that Apache is running. Start it if necessary:

sudo systemctl is-enabled httpd
# if needed:
sudo systemctl start --now httpd

Then, perform an update to ensure the system is up to date:

sudo yum update -y

SSL setup

Install mod_ssl, the Apache TLS module:

sudo yum install -y mod_ssl

The following configuration files are created during installation:

• /etc/httpd/conf.d/ssl.conf
  • This is the mod_ssl configuration
• /etc/pki/tls/certs/make-dummy-cert
  • This is a script that generates a self-signed certificate and private key

Self-signed certificate

Generate a self-signed certificate and associated private key:

cd /etc/pki/tls/certs
sudo ./make-dummy-cert localhost.crt

The resultant localhost.crt file contains both the self-signed certificate and associated private key. The name of the file is the default expected by the SSLCertificateFile directive in /etc/httpd/conf.d/ssl.conf.

mod_ssl configuration

As the file generated by make-dummy-cert contains both certificate and private key, the following line must be commented out in /etc/https/conf.d/ssl.conf:

/etc/httpd/conf.d/ssl.conf

SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

Finally, restart Apache to apply the changed configuration:

sudo systemctl restart httpd

At this point, Apache should be accessible via the https:// protocol. If it does not load, ensure that the security group applied to the EC2 instance allows port 443 inbound.

SSL hardening

Testing SSL configuration

The Qualys SSL Lab site can be used to test an existing SSL configuration and report any errors or potential weaknesses.

Within the mod_ssl configuration file, make the following changes to harden and future-proof the default configuration.

Disallow deprecated versions

Comment or remove the existing SSLProtocol directive, and replace it with the following:

/etc/httpd/conf.d/ssl.conf

#SSLProtocol all -SSLv3
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

This will explicitly disable SSL versions 2 and 3, and TLS versions 1.0 and 1.1. This means that TLS 1.2 will be the only supported protocol for encrypted communication.

Modify allowed cipher suites

To determine the appropriate allowed suites and their order, use Mozilla’s SSL Configuration Generator.

To determine which Apache and OpenSSL versions to use in the configuration generator, run the following command:

yum list installed | grep 'httpd\|openssl'

In the SSL Configuration Generator, use the following options:

• Server Software: Apache
• Mozilla Configuration:
  • Modern - will most aggressively enforce security, but still works on most browsers
  • Intermediate - suitable with most software that is too old to be compatible with the modern configuration
• Server Version: Apache version determined above
• OpenSSL Version: OpenSSL version determined above

Modern configuration

As of this writing, the latest available version of OpenSSL on Amazon Linux 2 does not support the Modern configuration option on SSL Configuration Generator. The Intermediate option may be used instead.

Near the bottom of the SSL Configuration Generator output is an SSLCipherSuite directive. Modify the existing SSLCipherSuite directive in /etc/httpd/conf.d/ssl.conf, overwriting it with the one generated above:

/etc/httpd/conf.d/ssl.conf

# SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Honor cipher order

Also in the mod_ssl configuration, uncomment the SSLHonorCipherOrder directive to enable it:

SSLHonorCipherOrder on

Finally, restart Apache once again to apply these changes.

Lab 8-2

In this lab, the self-signed certificate will be replaced with one from Let’s Encrypt.

Subdomain setup

For the purposes of this lab, a free subdomain from Duck DNS is used to allow for a valid certificate to be created. From the Duck DNS page (after signing in), create a new subdomain using the public IP address of the EC2 instance running Apache.

Certbot setup

Prerequisites

EPEL repositories

First, download and install the Extra Packages for Enterprise Linux (EPEL) 7 repository, to allow for installation of some Certbot dependencies:

wget -r --no-parent -A 'epel-release-*.rpm' https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
sudo yum-config-manager --enable epel*

Now, sudo yum repolist all should include the epel-* repos with the status enabled.

Apache VHOST

Add a VHOST to the Apache configuration at /etc/httpd/conf/httpd.conf, using the subdomain created with (in this example) Duck DNS above. In this example it is added immediately after the existing Listen 80 directive:

/etc/httpd/conf/httpd.conf

Listen 80
 
<VirtualHost *:80>
    DocumentRoot "/var/www/html"
    ServerName "rs-sys-360.duckdns.org"
ServerAlias "rs-sys-360.duckdns.org"
</VirtualHost>

After saving this config file addition, restart Apache to apply the changes. The server should now be accessible at https://yoursubdomain.duckdns.org.

Installation and setup

Install Certbot and dependencies:

sudo yum install -y certbot python2-certbot-apache

Run Certbot with sudo certbot, and enter the following in the configuration wizard:

• Enter email address: Enter a valid email address
• Terms of Service: Y
• EFF newsletter: Optional
• Select domains: Press Enter to select all domains and SANs

At this point, Certbot should generate a certificate and apply any necessary configuration changes to Apache. The output includes the locations of the new certificate and private key files, as well as the expiration date(s) for these certificate(s).

In the future, sudo certbot renew will renew all certificates, updating their expiry dates.

At this point, the server should be accessible at the previously configured domain, using HTTPS, without any certificate warnings.