How to Install Apache Web Server on Ubuntu Server 22.04 LTS

[LHammonds]

Greetings and salutations,

I hope this thread will be helpful to those who follow in my foot steps as well as getting any advice based on what I have done / documented.

To discuss this thread, please participate here: Ubuntu Forums

High-level overview

The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows.

This tutorial will cover how to setup an Apache web server.

This is an overview image of a highly-available web server platform.
This article covers the web server install.


Tools utilized in this process

• Ubuntu Server 22.04 LTS, 64-bit
• Apache HTTP Server 2.4.52
• PHP 8.1.2
• Let's Encrypt 1.21.0
• Portable PuTTY 0.77
• VMware vSphere 6.0.0
• VirtualBox 6.1.34

Helpful links

The list below are sources of information that was helpful in the creation of this document.

• Apache Documentation
• Let's Encrypt Documentation
• Uncomplicated Firewall (UFW)
• SSL Configuration Generator

Assumptions

This documentation will need to make use of some very-specific information that will most-likely be different for each person / location. And as such, this information will be noted in this section. They will be highlighted in red throughout the document as a reminder that you should plug-in your own value rather than actually using these "place-holder" values.

Under no circumstance should you use the actual values listed below. They are place-holders for the real thing. This is just a checklist template you need to have answered before you start the install process.

Wherever you see RED in this document, you need to substitute it for you will use in your environment.

• Internet domain: mysite.mydomain.com -> 216.70.70.70 (Public IP) -> Firewall -> 192.168.107.91 (Internal IP)
• Ubuntu Admin ID: administrator
• Ubuntu Admin Password: myadminpass
• Email Server Name (remote): srv-mail
• Email Server Internal IP (remote): 192.168.107.25

Ubuntu Server - This tutorial assumes the server was configured according to this tutorial: How to install and configure Ubuntu Server

It is also assumed the reader knows how to use the VI editor. If not, you will need to beef up your skill set or use a different editor in place of it.

[LHammonds]

Install Apache

Code: Select all

sudo apt install apache2

Install PHP for Apache with MySQL/MariaDB support

Code: Select all

sudo apt install php8.1 libapache2-mod-php8.1 php8.1-mysql

TIP: You can search available PHP packages names by typing this:

Code: Select all

apt-cache search php8.1

Large File Upload Support

If your site will allow uploading of files larger than 8 MB, you can increase this limit in PHP. The below will modify the upload limit to allow files as large as 2,048 MB to be uploaded.

Code: Select all

sudo vi /etc/php/8.1/apache2/php.ini

Code: Select all

post_max_size = 2058M
upload_max_filesize = 2048M

Reload Apache for changes to the config to take affect:

Code: Select all

sudo systemctl reload apache2

Firewall Rules

Edit the firewall script that was created during the initial setup of the server (if you followed my instructions):

Code: Select all

sudo vi /var/scripts/prod/en-firewall.sh

Add (or enable) the following:

Code: Select all

echo "Adding Web Server rules"
ufw allow proto tcp to any port 80 comment 'HTTP Service' 1>/dev/null 2>&1
ufw allow proto tcp to any port 443 comment 'HTTPS Service' 1>/dev/null 2>&1

Run the updated rules:

Code: Select all

sudo /var/scripts/prod/en-firewall.sh

PHP Modules and Information

To verify Apache, PHP and modules are installed and enabled, lets create the famous phpinfo page.

Code: Select all

sudo touch /var/www/html/phpinfo.php
sudo chown www-data:www-data /var/www/html/phpinfo.php
sudo chmod 0644 /var/www/html/phpinfo.php
sudo echo "<?php phpinfo(); ?>" >> /var/www/html/phpinfo.php

Open a browser and load up the phpinfo page: http://192.168.107.91/phpinfo.php

You should be able to scroll down and see sections for each module we wanted enabled. If you don't see a dedicated section, then that module is not installed/enabled.

When done, do not forget to remove the info file:

Code: Select all

sudo rm /var/www/html/phpinfo.php

[LHammonds]

Disable the default sites

It is best to disable and not use the default sites.

Code: Select all

sudo a2dissite 000-default
sudo a2dissite default-ssl

Web Site Root Folder

Create the web site root folder and default test page:

Code: Select all

sudo mkdir -p /var/www/mysite.mydomain.com
sudo chown www-data:www-data /var/www/mysite.mydomain.com
sudo chmod 0755 /var/www/mysite.mydomain.com
sudo touch /var/www/mysite.mydomain.com/index.php
sudo chown www-data:www-data /var/www/mysite.mydomain.com/index.php
sudo chmod 0644 /var/www/mysite.mydomain.com/index.php
sudo echo "<?php phpinfo(); ?>" >> /var/www/mysite.mydomain.com/index.php

DNS Resolution

Typically, when you setup a web site, you will have a domain name and a public IP associated to it so people from anywhere on the Internet can access your server through the domain name. But if you do not have that yet and want to setup the server as if you did, you can edit the local host file of your PC to "resolve" the friendly domain name to the correct IP (at least until you get it working at the LAN/WAN DNS level). Just be sure to undo these changes once the DNS server starts handling the name resolution.

On a Linux PC, you edit the following file:

Code: Select all

sudo vi /etc/hosts

On a Windows PC, you edit the following file:

Code: Select all

notepad C:\Windows\System32\Drivers\etc\hosts

And add an entry like this:

Code: Select all

192.168.107.91   mysite.mydomain.com

You should be able to open a Command Prompt / Terminal and ping "mysite.mydomain.com" and your local host file should translate that to your IP address such as 192.168.107.91.

Code: Select all

# ping -c3 mysite.mydomain.com
PING mysite.mydomain.com (192.168.107.91) 56(84) bytes of data.
64 bytes from mysite.mydomain.com (192.168.107.91): icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from mysite.mydomain.com (192.168.107.91): icmp_seq=2 ttl=64 time=0.049 ms
64 bytes from mysite.mydomain.com (192.168.107.91): icmp_seq=3 ttl=64 time=0.053 ms

--- mysite.mydomain.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2049ms
rtt min/avg/max/mdev = 0.028/0.043/0.053/0.012 ms

Virtual Host Creation

Create the virtual host configuration file for your domain / web site:

Code: Select all

sudo touch /etc/apache2/sites-available/mysite.mydomain.com.conf
sudo chown root:root /etc/apache2/sites-available/mysite.mydomain.com.conf
sudo chmod 0644 /etc/apache2/sites-available/mysite.mydomain.com.conf

Edit the virtual host configuration file:

Code: Select all

sudo vi /etc/apache2/sites-available/mysite.mydomain.com.conf

Set these values:

Code: Select all

<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  ServerName mydomain.com
  ServerAlias mysite.mydomain.com
  DocumentRoot /var/www/mysite.mydomain.com
  ErrorLog ${APACHE_LOG_DIR}/mysite.mydomain.com-error.log
  CustomLog ${APACHE_LOG_DIR}/mysite.mydomain.com-access.log combined
</VirtualHost>

Validate Virtual Host Syntax

Validate the configuration file syntax and ensure it shows "Syntax OK"

Code: Select all

sudo apache2ctl configtest

Enable Virtual Host

To enable the site we just created, run this command (specific to your configuration filename):

Code: Select all

sudo a2ensite mysite.mydomain.com

Disable Virtual Host

If you need to disable a site, run this command (specific to your configuration filename):

Code: Select all

sudo a2dissite mysite.mydomain.com

Reload Apache Configuration

Whenever changes are made to the configuration files, modules or certificates, you will need to reload Apache for it to take affect.

Code: Select all

sudo systemctl reload apache2

[LHammonds]

Create Self-Signed SSL Certificate

NOTE: This section is only here for historical reference. For production SSL use, see the Let's Encrypt section for SSL certificates from a source web browsers trust.

This will create a self-signed certificate that will expire 1,095 days (3 years) from the date it was created. Web browsers will complain about it being untrusted. It will still work but end-users will have to allow this exception (unless it is on a LAN and you can add the site to all computers trusted sites via group policy)

Code: Select all

sudo a2enmod ssl
sudo a2enmod rewrite
sudo a2enmod headers
sudo mkdir -p /etc/apache2/ssl/certs
sudo mkdir -p /etc/apache2/ssl/private
sudo openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout /etc/apache2/ssl/private/mysite.mydomain.com.key -out /etc/apache2/ssl/certs/mysite.mydomain.com.crt
  Country Name: US
  State: MyState
  Locality Name: MyCity
  Organication Name: MyCompany
  Organizational Unit Name: MyDepartment
  Common Name: mysite.mydomain.com
  Email Address: webmaster@mydomain.com

Ensure correct file ownership/permissions:

Code: Select all

sudo chown root:root /etc/apache2/ssl/private/mysite.mydomain.com.key
sudo chown root:root /etc/apache2/ssl/certs/mysite.mydomain.com.crt
sudo chmod 600 /etc/apache2/ssl/private/mysite.mydomain.com.key
sudo chmod 600 /etc/apache2/ssl/certs/mysite.mydomain.com.crt

To verify the certificate:

Code: Select all

openssl x509 -in /etc/apache2/ssl/certs/mysite.mydomain.com.crt -text -noout

To verify the private key:

Code: Select all

openssl rsa -in /etc/apache2/ssl/private/mysite.mydomain.com.key -check

Create the virtual host SSL configuration file:

Code: Select all

sudo touch /etc/apache2/sites-available/mysite.mydomain.com-ssl.conf
sudo chown root:root /etc/apache2/sites-available/mysite.mydomain.com-ssl.conf
sudo chmod 0644 /etc/apache2/sites-available/mysite.mydomain.com-ssl.conf

Edit the configuration file:

Code: Select all

sudo vi /etc/apache2/sites-available/mysite.mydomain.com-ssl.conf

Set these values:

Code: Select all

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    ServerName mysite.mydomain.com
    ServerAlias mysite.mydomain.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/mysite.mydomain.com
    ErrorLog ${APACHE_LOG_DIR}/mysite.mydomain.com-error.log
    CustomLog ${APACHE_LOG_DIR}/mysite.mydomain.com-access.log combined
    SSLEngine on
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
      SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
      SSLOptions +StdEnvVars
    </Directory>
    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>
    BrowserMatch "MSIE [2-6]" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    SSLCertificateFile /etc/apache2/ssl/certs/mysite.mydomain.com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/private/mysite.mydomain.com.key
  </VirtualHost>
</IfModule>

Validate the configuration file syntax and ensure it shows "Syntax OK"

Code: Select all

apache2ctl configtest

Enable the site configuration:

Code: Select all

sudo a2ensite mysite.mydomain.com-ssl

Reload the Apache config so it is aware of the modified virtual host

Code: Select all

sudo systemctl reload apache2

Test the web page by visiting https://mysite.mydomain.com/index.php and make sure the page displays and shows the SSL certificate is active.

[LHammonds]

Let's Encrypt SSL Certificate

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge. The certificate is valid for 90 days, during which renewal can take place at any time.

This section will describe how to obtain a certificate and automate the renewal process.

Prerequisites

• A registered domain name such as mydomain.com
• Two Host A records on your authoritative DNS server for your domain such as:

  Code: Select all

  Type A, mydomain.com, 216.70.70.70
  Type A, mysite.mydomain.com, 216.70.70.70

• Web server (such as Apache)
• A Virtual Host configuration file

Install Certbot

To install from the Ubuntu repository:

Code: Select all

sudo apt install certbot python3-certbot-apache

LetsEncrypt Permission Fix

NOTE: This is due to the umask setting in ~/.bashrc

While testing version 0.31.0 thru 0.40.0, I found that I kept getting a "client lacks sufficient authorization" error message. The problem is that during the authorization phase, it re-directs the Virtual Host configuration to /var/lib/letsencrypt/http_challenges but the parent folder of /var/lib/letsencrypt has too restrictive of permissions set. The owner is set to root:root and permissions of 700 which means the web service (www-data) cannot view anything under that directory. The solution is to fix the permission on that folder so "other" users (www-data) can see the contents. NOTE: This folder only exists once you try to obtain your 1st SSL certification in the next section below.

Code: Select all

sudo mkdir -p /var/lib/letsencrypt/http_challenges
sudo chmod 755 /var/lib/letsencrypt
sudo chmod 755 /var/lib/letsencrypt/http_challenges

Obtain the SSL Certificate

Be sure to use the FQDN for all domain names that will be used to access this site.

Code: Select all

sudo certbot --apache -d mydomain.com -d mysite.mydomain.com

We use -d to specify each name we would like the certificate to be valid for.

Upon the first time creating the certificate, you will be prompted for various information.

Once the information gathering is complete, Certbot will ask how to configure the HTTPS settings such as not forcing a redirect of HTTP to HTTPS or letting it add a redirect to force all HTTP traffic to HTTPS.

You can answer however you like but I like to do my own redirection (especially if this is already handled on a load balancer).

The new files will be placed here by default:

Code: Select all

/etc/letsencrypt/live/mydomain.com/fullchain.pem
/etc/letsencrypt/live/mydomain.com/privkey.pem

Look at the modified Virtual Host configuration file:

Code: Select all

sudo vi /etc/apache2/sites-available/mysite.mydomain.com.conf

The modified file now looks something like this:

Code: Select all

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    ServerName mysite.mydomain.com
    ServerAlias mysite.mydomain.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/mysite.mydomain.com
    ErrorLog ${APACHE_LOG_DIR}/mysite.mydomain.com-error.log
    CustomLog ${APACHE_LOG_DIR}/mysite.mydomain.com-access.log combined
    SSLEngine on
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
      SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
      SSLOptions +StdEnvVars
    </Directory>
    <IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>
    BrowserMatch "MSIE [2-6]" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/mysite.mydomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mysite.mydomain.com/privkey.pem
  </VirtualHost>
</IfModule>

Schedule For SSL Certificate Auto-Renew

Let's Encrypt certificates are only valid for 90 days. This encourages admins to automate their certificate renewal process.

You can force a simulated update to ensure the process will work using the dry-run option below. If you see "success" messages, then you should be OK when it comes time for the renew to run for real:

Code: Select all

sudo certbot renew --dry-run

Starting with Ubuntu 18.04 LTS, we now have a systemd timer. When enabled, it will check for renewals twice per day.

Code: Select all

sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

Check the status with this command (which also shows when it last ran and when the next run will be):

Code: Select all

systemctl status certbot.timer

Example Output:

Code: Select all

● certbot.timer - Run certbot twice daily
   Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: en
   Active: active (waiting) since Tue 2020-05-19 09:14:23 CDT; 6h ago
  Trigger: Tue 2020-05-19 20:05:09 CDT; 4h 20min left

May 19 01:00:00 srv-apache systemd[1]: Started Run certbot twice daily.

You can check the journal logs for certbot-related events:

Code: Select all

journalctl | grep certbot

Example Output:

Code: Select all

May 19 09:14:23 srv-apache systemd[1]: Started Run certbot twice daily.
May 19 09:16:47 srv-apache sudo[5618]:     root : TTY=pts/1 ; PWD=/etc/apache2/sites-available ; USER=root ; COMMAND=/usr/bin/certbot --apache -d mysite.mydomain.com
May 19 09:18:12 srv-apache sudo[5690]:     root : TTY=pts/1 ; PWD=/etc/apache2/sites-available ; USER=root ; COMMAND=/usr/bin/certbot --apache -d mysite.mydomain.com
May 19 12:00:01 srv-apache CRON[6946]: (root) CMD (test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew)

Migrating to New Server

If you are moving all your sites to a new server (such as upgrading to new OS), you will need to take certificates with you. Here is the process for moving from an Ubuntu 18.04 to Ubuntu 20.04 server.

On the old server, create an archive of the certificates, renewal account and renewal config:

Code: Select all

sudo tar -chvzf /tmp/le-files.tar.gz /etc/letsencrypt/archive /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory /etc/letsencrypt/renewal

Transfer the archive from the old server to the new server:

Code: Select all

scp /tmp/le-files.tar.gz administrator@srv-ubuntu:/tmp/.

On the new server, extract the archives:

Code: Select all

sudo tar -xvf /tmp/le-files.tar.gz -C /

Now we have to re-create the symlinks in the "live" folder which is what the Apache config files point to.

As time goes by, the certificates are renewed and they create new files. Make sure you are pointing each website's certificate to the latest cert.

Example: This particular website has renewed the certificate 5 times so the latest set of files to use has the number "5" in them which is what we link to from the "live" folder.

Code: Select all

ls -l /etc/letsencrypt/archive/games.mydomain.com
-rw------- 1 root root 1952 Jul 23  2019 cert1.pem
-rw-r--r-- 1 root root 1952 Sep 21  2019 cert2.pem
-rw-r--r-- 1 root root 1952 Nov 21 01:20 cert3.pem
-rw-r--r-- 1 root root 1952 Jan 20 07:43 cert4.pem
-rw-r--r-- 1 root root 1952 Mar 20 09:36 cert5.pem
-rw------- 1 root root 1647 Jul 23  2019 chain1.pem
-rw-r--r-- 1 root root 1647 Sep 21  2019 chain2.pem
-rw-r--r-- 1 root root 1647 Nov 21 01:20 chain3.pem
-rw-r--r-- 1 root root 1647 Jan 20 07:43 chain4.pem
-rw-r--r-- 1 root root 1647 Mar 20 09:36 chain5.pem
-rw------- 1 root root 3599 Jul 23  2019 fullchain1.pem
-rw-r--r-- 1 root root 3599 Sep 21  2019 fullchain2.pem
-rw-r--r-- 1 root root 3599 Nov 21 01:20 fullchain3.pem
-rw-r--r-- 1 root root 3599 Jan 20 07:43 fullchain4.pem
-rw-r--r-- 1 root root 3599 Mar 20 09:36 fullchain5.pem
-rw------- 1 root root 1708 Jul 23  2019 privkey1.pem
-rw------- 1 root root 1704 Sep 21  2019 privkey2.pem
-rw------- 1 root root 1704 Nov 21 01:20 privkey3.pem
-rw------- 1 root root 1708 Jan 20 07:43 privkey4.pem
-rw------- 1 root root 1704 Mar 20 09:36 privkey5.pem

Since I have a lot of websites, I created a script to help me automate this process in a consistent manner (once or more in test and again when performing the migration to production). You need to modify it to fit your needs or manually create the links yourself.

Modify the script below by passing the website folder and the certificate number to use.

/var/scripts/prod/le-symlink-create.sh (GitHub Download)

Code: Select all

#!/bin/bash
#############################################################
## Name          : le-symlink-create.sh
## Version       : 1.2
## Date          : 2022-08-10
## Author        : LHammonds
## Purpose       : Recreate Let's Encrypt symlinks to
##                 certificates after a server migration.
## Compatibility : Verified on Ubuntu Server 18.04 thru 22.04 LTS
## Run Frequency : Once after migration to new machine.
## Parameters    : None
## Exit Codes    : None
###################### CHANGE LOG ###########################
## DATE       VER WHO WHAT WAS CHANGED
## ---------- --- --- ---------------------------------------
## 2020-05-19 1.0 LTH Created script.
## 2020-10-05 1.1 LTH "If (not) exist" logic added.
## 2022-08-10 1.2 LTH Better automation. Only need to set BaseDir.
#############################################################

BaseDir="/etc/letsencrypt"
ArchiveDir="${BaseDir}/archive"
LiveDir="${BaseDir}/live"

function f_remove () {
  if [ -e ${1} ]; then
    rm ${1}
  fi
} ## f_remove() ##

function f_fixkey () {
  ## Param 1 = Web Folder
  ## Param 2 = Filename
  ## Param 3 = Keyname
  f_remove ${LiveDir}/${1}/${3}
  ln -s ${ArchiveDir}/${1}/${2} ${LiveDir}/${1}/${3}
} ## f_fixkey() ##

function f_getlatest () {
  ## Param 1 = Directory ##
  ## Param 2 = File pattern ##
  ## Output = Newest file matching pattern ##
  unset -v latest
  for file in ${1}/${2}; do
    [[ $file -nt $latest ]] && latest=$file
  done
  ## Remove parent path from filename and return value ##
  printf "${latest#${1}/}"
} ## f_getlatest() ##

## Loop through every folder in BaseDir ##
find ${ArchiveDir} -maxdepth 1 -mindepth 1 -type d | while read CurrentDir; do
  ## Remove the parent path from the current directory ##
  WebDir=${CurrentDir#${ArchiveDir}/}
  if [ ! -d ${LiveDir}/${WebDir} ]; then
    mkdir -p ${LiveDir}/${WebDir}
  fi
  printf "Fixing certs for ${WebDir}\n"
  f_fixkey "${WebDir}" "$(f_getlatest "${ArchiveDir}/${WebDir}" "cert*.pem")" "cert.pem"
  f_fixkey "${WebDir}" "$(f_getlatest "${ArchiveDir}/${WebDir}" "chain*.pem")" "chain.pem"
  f_fixkey "${WebDir}" "$(f_getlatest "${ArchiveDir}/${WebDir}" "fullchain*.pem")" "fullchain.pem"
  f_fixkey "${WebDir}" "$(f_getlatest "${ArchiveDir}/${WebDir}" "privkey*.pem")" "privkey.pem"
done

Once the certs are on the new server, make sure everything works by doing a dry run (no changes will be made):

Code: Select all

sudo certbot renew --force-renewal --apache --dry-run

If there were no failures, go ahead and force a renewal to make double-certain everything will work right when it needs to do so the next time it tries to automate the process:

Code: Select all

sudo certbot renew --force-renewal --apache

Now you can take a look at all the certificates and info (which should all have the same expiry date around 89 days from now):

Code: Select all

sudo certbot certificates

Code: Select all

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: mysite.mydomain.com
    Domains: mysite.mydomain.com
    Expiry Date: 2020-08-22 15:32:53+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/mysite.mydomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mysite.mydomain.com/privkey.pem
  Certificate Name: forum.mydomain.com
    Domains: forum.mydomain.com.com
    Expiry Date: 2020-08-22 15:33:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/forum.mydomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/forum.mydomain.com/privkey.pem
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Certificate Deletion / Removal

If you ever need to delete a certificate and all its related files to ensure the automatic renewal does not try renew a dead site, run this command:

Code: Select all

sudo certbot delete

It will then present you with a list of certificates. Type the number next to the certificate you want to delete.

Example:

Code: Select all

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which certificate(s) would you like to delete?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: nextcloud.mydomain.com
2: video.mydomain.com
3: forum.mydomain.com
4: wiki.mydomain.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): c
User ended interaction.

[LHammonds]

Force SSL Usage

This section will describe how to modify the site configuration to ensure anyone that hits an http (port 80) URL will be automatically re-directed to the https (port 443) location...thus ensuring all traffic on the site is encrypted using SSL.

Enable the rewrite mod:

Code: Select all

sudo a2enmod rewrite

Restart Apache service for change to take affect:

Code: Select all

sudo systemctl restart apache2

Edit the non-secure Virtual Host configuration file:

Code: Select all

sudo vi /etc/apache2/sites-available/mysite.mydomain.com.conf

Add the following entries:

Code: Select all

  RewriteEngine On
  RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

Make sure the syntax is correct for the config file:

Code: Select all

sudo apache2ctl configtest

Reload the Apache configuration for changes to take affect:

Code: Select all

sudo systemctl reload apache2

Visit the non-ssl URL (http) and it should automatically swap it to the SSL URL (https).

http://mysite.mydomain.com

[LHammonds]

Directory Security

It is a good idea to have your site permission settings in a script that can be scheduled to run on a normal basis. Each site/application will need to have specific permissions set so use the following script as an example of things you can do to customize a script for your site.

Create the file and set appropriate ownership / permissions.

Code: Select all

sudo touch /var/scripts/prod/secure-mysite.mydomain.com.sh
sudo chown root:root /var/scripts/prod/secure-mysite.mydomain.com.sh
sudo chmod 0755 /var/scripts/prod/secure-mysite.mydomain.com.sh

Edit the script:

Code: Select all

sudo vi /var/scripts/prod/secure-mysite.mydomain.com.sh

Add the following to the file and make changes that match your site:

/var/scripts/prod/secure-mysite.mydomain.com.sh (GitHub Download)

Code: Select all

#!/bin/bash
#############################################
## Name          : secure-mysite.mydomain.com.sh
## Version       : 1.1
## Date          : 2019-09-03
## Author        : LHammonds
## Compatibility : Ubuntu Server 18.04 - 20.04 LTS
## Requirements  : Run as root user
## Purpose       : Ensures ownership and permissions are set correctly.
## Run Frequency : Manual as needed or via crontab schedule.
################ CHANGE LOG #################
## DATE       WHO WHAT WAS CHANGED
## ---------- --- ----------------------------
## 2019-07-23 LTH Created script.
## 2019-09-03 LTH Added full path to executables.
#############################################
wwwdir='/var/www/mysite.mydomain.com'
webuser='www-data'
webgrp='www-data'
rootuser='root'

echo "Setting Ownership..."
/bin/chown -R ${webuser}:${webgrp} ${wwwdir}/
/bin/echo "Setting Folder Permissions..."
/usr/bin/find ${wwwdir}/ -type d -print0 | /usr/bin/xargs -0 /bin/chmod 0750
/bin/echo "Setting File Permissions..."
/usr/bin/find ${wwwdir}/ -type f -print0 | /usr/bin/xargs -0 /bin/chmod 0640
if [ -f ${wwwdir}/.htaccess ]; then
  /bin/chmod 0644 ${wwwdir}/.htaccess
fi
/bin/echo "Permission change complete."

Run the script and make sure there are no syntax errors:

Code: Select all

sudo /var/scripts/prod/secure-mysite.mydomain.com.sh

Verify that file and folder permissions were set correctly:

Code: Select all

ls -l /var/www/mysite.mydomain.com

Crontab Schedule

The script can now be schedule to run automatically. The steps below will have the script run daily as the root user.

Make a backup of the root crontab schedule (this file should exist if you followed my instructions)

Code: Select all

cp /var/scripts/data/crontab.root /var/scripts/data/2019-07-23-crontab.root

Edit the root crontab schedule file:

Code: Select all

sudo vi /var/scripts/data/crontab.root

Add the following line which will schedule the script to run at 3am every day:

Code: Select all

0 3 * * * /var/scripts/prod/secure-mysite.mydomain.com.sh > /dev/null 2>&1

Replace the current root crontab schedule with the updated file:

Code: Select all

crontab -u root /var/scripts/data/crontab.root

You can verify the update by listing the current schedule:

Code: Select all

crontab -u root -l

[LHammonds]

This section covers settings that can be modified to make it a bit more secure.

ServerSignature

Turn off ServerSignature to prevent Apache from identifying itself and version number.

/etc/apache2/conf-available/security.conf

Code: Select all

ServerSignature Off

ServerTokens

Set ServerTokens to the least amount of information given.

This directive configures what you return as the Server HTTP response Header such as the the OS-Type and compiled in modules.

/etc/apache2/conf-available/security.conf

Code: Select all

ServerTokens Prod

Fail2Ban - Standard Filters

If you followed my instructions for setting up the Ubuntu Server, you should already have sshd being protected by Fail2Ban. Now we are going to add some pre-defined Apache filters.

Edit the jail configuration file:

Code: Select all

sudo vi /etc/fail2ban/jail.local

Add the following sections to the bottom:

Code: Select all

[apache-auth]
# detect password authentication failures
enabled  = true
port     = http,https
filter   = apache-auth
action   = iptables-multiport[name=auth, port="http,https"]
logpath  = %(apache_error_log)s
bantime  = 3600
maxretry = 3

[apache-noscript]
# detect potential search for exploits
enabled  = true
port     = http,https
filter   = apache-noscript
action   = iptables-multiport[name=noscript, port="http,https"]
logpath  = %(apache_error_log)s
bantime  = 3600
maxretry = 6

[apache-overflows]
# detect Apache overflow attempts
enabled  = true
port     = http,https
filter   = apache-overflows
action   = iptables-multiport[name=overflows, port="http,https"]
logpath  = %(apache_error_log)s
bantime  = 3600
maxretry = 2

[apache-badbots]
# detect spammer robots crawling email addresses
enabled  = true
port     = http,https
filter   = apache-badbots
action   = iptables-multiport[name=badbots, port="http,https"]
logpath  = %(apache_access_log)s
bantime  = 48h
maxretry = 1

[php-url-fopen]
# detect PHP remote injection attacks
enabled  = true
port     = http,https
filter   = php-url-fopen
action   = iptables-multiport[name=phpfopen, port="http,https"]
logpath  = %(apache_access_log)s
maxretry = 1

Restart the Fail2Ban service:

Code: Select all

sudo systemctl restart fail2ban

Check the status:

Code: Select all

sudo fail2ban-client status

Fail2Ban - WordPress Login

WordPress does not write login results to the web logs. However, we can make an assumption that anyone trying to access the login page multiple times in a short period of time does not know their credentials or they are trying to brute-force crack accounts. So let's create a filter that looks for anyone accessing the login page multiple time in a short timeframe.

Create a new filter:

Code: Select all

sudo touch /etc/fail2ban/filter.d/wordpress-login.conf
sudo chown root:root /etc/fail2ban/filter.d/wordpress-login.conf
sudo chmod 644 /etc/fail2ban/filter.d/wordpress-login.conf

Edit the filter file:

Code: Select all

sudo vi /etc/fail2ban/filter.d/wordpress-login.conf

Add this to the file:

Code: Select all

[Definition]
failregex = <HOST> - - .*(POST|GET) .*/wp-login.php HTTP.*

Edit the jail configuration file:

Code: Select all

sudo vi /etc/fail2ban/jail.local

Add the following sections to the bottom:

Code: Select all

[wordpress-login]
# detect multiple attempts to login
enabled  = true
port     = http,https
action   = iptables-multiport[name=wordpress, port="http,https"]
filter   = wordpress-login
logpath  = %(apache_access_log)s
bantime  = 3600
findtime = 60
maxretry = 6

Restart the Fail2Ban service:

Code: Select all

sudo systemctl restart fail2ban

Check the status:

Code: Select all

sudo fail2ban-client status