Creating Your Own Website

Published 17 Nov 2024. Nil revisions.

Acquire a Domain Name

Acquire a domain name if you haven't already. This is done through a registrar. A registrar is a company that registers domain names with ICANN on your behalf. Examples of registrars include: Spaceship (newer company owned by NameCheap and started by its founder), NameCheap, Porkbun and Cloudfare.

Setup a Web Server

A web server is a computer that serves web-pages to clients (i.e. it 'hosts' your website). One can use their own (usually spare) computer to do this, or rent a computer. If using your own computer, you'll also need a static Internet Protocol (IP) address. Static IP addresses are issued by your Internet Service Provider (ISP). This usually costs more money on personal internet plans (approximately 5 AUD extra per month), or is commonly free with business plans. In addition to this increased cost, one also needs to ensure that their private network is protected, as using a static IP address on your own local network means that people from around the world will be connecting to that network. Thus, the simpler solution is to rent a computer (server) from web server provider. A very basic shared Virtual Private Server (VPS) will cost around 5 AUD per month. Examples of web server providers include: Vultr and DigitalOcean.

Once a computer has been setup and a static IP address allocated, one can then setup the DNS records.

Setup DNS Records

A Domain Name System (DNS) is a system that links domain names to the IP addresses of the web servers for given domains. DNSs are managed by DNS service providers. Often your registrar where you purchased your domain will provide such a service. Other specialised DNS providers include: DNS Made Easy, DynDNS and EasyDNS. Using your registrar to setup your DNS records is the simplest.

Create both IPV4 (Type A) and IPV6 (Type AAAA) DNS records. For example:

Hostname	Type	Value (IP Address)	Time To Live (TTL)
mydomain.com	A	40.21.10.163	30min
www.mydomain.com	A	40.21.10.163	30min
mydomain.com	AAAA	23a4:e206:caae:...	30min
www.mydomain.com	AAAA	23a4:e206:caae:...	30min

If you are setting up an e-mail server as well, you will also have to setup a reverse DNS record. However, this is not necessary for just a website.

Harden the Security of the Web Server

Force Using a Non-Root User

Why not use root?

Logging in as root is generally considered bad practice. The reason being is that applications and commands should be run at a non-administrative level in order to prevent accidental or unwanted changes to the underlying system. For example, a crash of software to wipe a directory or a vulnerability to allow an attacker to gain root access. Instead, it is good practice to run applications and commands at a user level, and elevate privileges on a per-need basis.

Creating a Non-Root User with Superuser Privileges

The following commands assume that you are logged in as root to your server, and have not yet created a non-root user.

Add a new user:

adduser <username>

Enter the password for the new user. You can leave the full name, room number and phone numbers blank by just pressing Enter in each of the fields; otherwise, if you want to add these details, then add them here.

Add the user to the superuser group to give them superuser (administrator) privileges:

usermod -aG sudo <username>

To check that the new user has been added, switch to it:

su - <username>

Check if superuser privileges have been added by running a command that requires them, for example reconfiguring time-zone data:

sudo dpkg-reconfigure tzdata

If the reconfiguration Terminal User Interface (TUI) opens successfully, a non-root user with superuser privileges has been added successfully.

Disable Root Log-Ins

Once a user with superuser privileges has been added, one can disable root log-ins.

Edit the SSH daemon configuration file on your server:

sudo vim /etc/ssh/sshd_config

Replace the line containing PermitRootLogin yes with PermitRootLogin no.

Save the file, then restart the daemon:

sudo systemctl restart sshd

Change the SSH Port Number

The default port for the Secure Shell (SSH) protocol is port 22. One can change this to a random port number greater than 1,024 and less than 65,536 to make automated SSH attacks less likely. Once changed, attackers attempting to gain access to your server via SSH will have to first scan all ports to see if the SSH daemon is listening on another port, then initiate the attack (e.g. brute-force). This is time consuming, so attackers are more likely to move onto other servers.

Decide on a port number greater than 1024 and less than 65,536, then log-in to the server.

Determine if a firewall is active. Debian and Ubuntu will likely have Uncomplicated Firewall (UFW) set up by default. If you are using another Linux distribution, find the equivalent commands to the ones below.

Check the status of the firewall:

sudo ufw status

Ensure the UFW is active and SSH is allowed (it should be by default).

Allow the new port:

sudo ufw allow 5341

Edit the SSH daemon configuration file on your server:

sudo vim /etc/ssh/sshd_config

Replace the line containing #Port 22 with Port 5341.

Save the file, then restart the daemon:

sudo systemctl restart sshd

The new port is now allowed and required to be used via SSH. When using an SSH client program to access the server in future, you'll have to specify the new port number to be used (otherwise the default port 22 is used), for example:

ssh -p 5431 <user>@yourdomain.com

Similarly, when using a Secure Copy Protocol (SCP) client program to copy files to the server, you'll have to specify the port number to be used (otherwise the default port 22 is used), for example:

scp -P 5431 <src_file> <username>@yourdomain.com:<trgt_file>

Note: while the ssh command uses a lower-case -p flag, the scp command uses an upper-case -P to specify the port number.

Reject Connection Requests Without Passwords

Although it is bad practice, administrators can create a user account without a password. This means that remote connection requests from that account will have no password to check against; therefore, the connection will be accepted without authentication. By default, SSH accepts connection requests without passwords, disable it by editing the SSH daemon configuration file:

sudo vim /etc/ssh/sshd_config

Then uncomment the line containing #PermitEmptyPasswords no by removing the octothrope (#) (i.e. the line should be PermitEmptyPasswords no).

Save the file, then restart the daemon:

sudo systemctl restart sshd

Disable X11 Forwarding

X11 forwarding allows remote users to run graphical applications from the server over an SSH session. It is recommended to disable features like this that will in general not be used. Edit the SSH daemon configuration file on your server:

sudo vim /etc/ssh/sshd_config

Then uncomment the line containing #X11Forwarding no by removing the # (i.e. the line should be X11Forwarding no).

Save the file, then restart the daemon:

sudo systemctl restart sshd

Set an Idle Timeout Value

If an SSH session has had no activity for some time, it is likely that the session is unattended and could pose a security risk. Set an idle limit that will cause the SSH connection to timeout and drop connection if the session has no activity during that time period.

Edit the SSH daemon configuration file on your server:

sudo vim /etc/ssh/sshd_config

Replace the line containing #ClientAliveInterval 0 with ClientAliveInterval 600. The integer corresponds to a number of seconds (e.g. 600 is 600 seconds i.e. 10 minutes).

Save the file, then restart the daemon:

sudo systemctl restart sshd

Force Public-Key (GPG) Authentication Only

Public-key cryptography provides a more secure means of logging into a server via SSH compared to passwords. Passwords are susceptible to guessing (via brute-force or other targeted means) or cracking. While public-key authentication is not perfect, it is not subject to such attacks.

Public-key cryptography relies on a pair of keys: the public key and the private key. The public key is shared with the others (in this case the server you want to connect to), while the private key, as the name suggests, is kept private and secure on your own computer.

When you make a connection request to the sever, the server uses its public key to create an encrypted message that is sent back to your computer. As it was encrypted with your public key, only you with your paired private key can decrypt it. Your computer does this and extracts information from the message, importantly, the session ID. Your computer then re-encrypts this and sends it back to the server. If the server can decrypt it with its copy of your public key, and the information provided matches what was initially sent, then the server knows that connection request is someone it should trust.

The SSH client program provides the ability to generate public-private key pairs that can be used for authentication. However, most people use Gnu Privacy Guard (GPG) so utilising those existing key-pairs produces fewer keys to manage.

Generate GPG Private-Public Key Pair

Create a Gnu Privacy Guard (GPG) private-public key pair. You can follow my guide on GPG key generation if needed.

Add Authentication Sub-Key to GPG Key for SSH Use

If you haven't already added an authentication sub-key to your existing GPG key-pair, edit the key:

gpg --expert --edit-key <email-assoc-with-key>

Add a key by typing addkey and then pressing Enter.

Select the option that matches the encryption algorithm used for the original key (e.g. ECC), and that allows you to set your own capabilities.

Toggle the capabilities such that the only allowed action is authentication (i.e. signing and encryption are disabled).

Set the sub-key validity for the desired period.

Create the key by typing y and then pressing Enter.

Quit the GPG utility by typing quit and then pressing Enter.

Confirm that the new authentication sub-key has been created and is associated with your master key:

gpg --list-keys <email-assoc-with-key>

The output should be something like the following:

pub   ed25519 2024-11-17 [SC]
      Q8FAP38902NFDB28339NSSFC2ACCD118AU8A82BF
uid           [ultimate] username <email@address.com>
sub   cv25519 2024-11-17 [E]
sub   ed25519 2024-11-17 [A]

Where one should now have the authentication sub-key listed, marked by the [A].

As an aside, cv25519 (short for Curve25519) is the counterpart to ed25519:

cv25519 is used for X25519 key agreement (a type of Elliptic curve Diffie-Hellman (ECDH) key agreement) used for key exchange.
ed25519 is the Edwards-curve Digital Signature Algorithm (EdDSA) key signature scheme which uses SHA-512 and an elliptic curve related to Curve25519 to create fast and secure digital signatures.

Enable SSH Support in GPG

Configure the SSH daemon on your computer to accept incoming gpg agent requests. Edit the GPG agent configuration file:

sudo vim ~/.gnupg/gpg-agent.conf

Add the following line to the GPG agent configuration file:

enable-ssh-support

Save and close the GPG agent file.

Edit your bash run commands (.bashrc) file:

sudo vim ~/.bashrc

Add the following lines at the end of the file:

export GPG_TTY=$(tty)
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi

Setting the GPG_TTY environment variable tells the GPG utility which tty (teletypewriter, i.e. terminal) is associated with the standard input so that pin-entry (curses- or GUI-based) can work. Without pin-entry you cannot enter a password to decrypt your secret key for subsequent use.

Unsetting the SSH_AGENT_PID setting the SSH_AUTH_SOCK tells ssh that gpg-agent will be used instead of the ssh-agent.

Display the keygrips of the GPG keys:

gpgp --list-keys --with-keygrip

Copy the keygrip of the authentication sub-key.

Create an sshcontrol file under the .gnupg directory:

sudo vim ~/.gnupg/sshcontrol

Paste the keygrip into this file and save it. Only keys in this file will be used in the SSH protocol.

Reload your bash run commands file on the current terminal session:

source ~/.bashrc

Test if the SSH daemon is linked to the GPG agent and is now working properly by listing its public SSH key:

ssh-add -l

Exporting and Testing Your GPG Key

Generate and save the SSH-compatible GPG key:

gpg --ssh-export-key <email-assoc-with-key> > ~/authorized_keys

Set the permission of the exported key to be only user-readable and writeable:

chmod 600 ~/authorized_keys

Connect via SSH to your server and log-in. Ensure that the .ssh directory exists in the home directory. If it doesn't, create it:

mkdir ~/.ssh

Press Ctrl+D to log-out of the server and close the SSH connection.

Send the authorized_keys file to the server using the Secure Copy Protocol (SCP) client program:

scp ~/authorized_keys <username>@yourdomain.com:~/.ssh/authorized_keys

Connect via SSH to your server and log-in. Restart the SSH daemon to apply the new key:

sudo systemctl restart sshd

Press Ctrl+D to log-out of the server and close the SSH connection. Re-connect via SSH to your server, a prompt asking for your GPG password should appear. You can now authenticate using your GPG key.

Disable All Other Authentication Methods

Edit the SSH daemon configuration file on your server:

sudo vim /etc/ssh/sshd_config

Disable password authentication by replacing the commented line containing #PasswordAuthentication yes with PasswordAuthentication no.

Disable any keyboard-based interactive authentication by replacing the line containing KbdInteractiveAuthentication yes with KbdInteractiveAuthentication no.

Ensure that the line:

Include /etc/ssh/sshd_config.d/*.conf

is after any manual changes to your configuration. The SSH daemon will be configured with whatever setting is encountered first. Thus, if this line is placed before your changes, whatever settings are provided in these .conf files will be used, which may be in contradiction to the manual changes you made.

Save the file, then restart the daemon:

sudo systemctl restart sshd

Configuring the Nginx Server

Install Nginx

Ensure packages are up-to-date:

sudo apt update

Intall Nginx:

sudo apt install nginx

Update Firewall Settings

Nginx registers itself as a service with UFW upon installation. Thus, application profiles will be available to easily allow or deny firewall access to Nginx. Display the list of application profiles available:

sudo ufw app list

The output should include:

Available applications:
    ...
    Nginx Full
    Nginx HTTP
    Nginx HTTPS
    ...

Allow the Nginx traffic through your firewall:

sudo ufw allow 'Nginx HTTP'

In general, it is recommended that one only allow the traffic that has been configured for. That is why only HTTP is allowed for now until SSL/TLS has been setup to support HTTPS traffic. This will be done later.

Verify that Nginx HTTP traffic has been allowed:

sudo ufw status

The output should contain at least the following entries:

Status: active

To                         Action      From
--                         ------      ----
Nginx HTTP                 ALLOW       Anywhere                  
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Confirm the Nginx Server is Running

After installation, Nginx should have already been started. Confirm that it is running:

systemctl status nginx

Confirm that Nginx is working correctly by requesting a page. This is done by going to your browser and navigating to either the Internet Protocol (IP) of your server:

http://<your-domain-IP>

Or, if your Domain Name Server (DNS) records have been set up, the domain name:

http://<yourdomain.com>

You should now see the default Nginx landing page. You can use basic Nginx server management commands to manage the Nginx application if needed.

Set Up Server Blocks

Sever blocks are used to encapsulate configuration details and host more than one domain from a single server.

One server block is set up by default to serve files out of the /var/www/html directory. Instead of modifying /var/www/html, this default directory will be left in place as something to be served if a client request does not match any other sites.

Create the following directory. Replace <yourdomain-withoutTLD> with your domain name, but without any Top-Level Domains (e.g. .com, .org etc.) in the name:

sudo mkdir -p /var/www/<yourdomain-withoutTLD>/html

The -p flag ensures that any necessary parent directories are automatically created.

Assign ownership of the directory created using the $USER environment variable:

sudo chown -R $USER:$USER /var/www/<yourdomain-withoutTLD>/html

Ensure that the file permission are correct, allowing the owner to read, write and execute files, while groups and others can only read and execute:

sudo chmod -R 755 /var/www/<yourdomain-withoutTLD>

Create a test HTML file:

sudo vim /var/www/<yourdomain-withoutTLD>/html/index.html

As an example, add the following content to it:

<html>
    <head>
        <title>Welcome!</title>
    </head>
    <body>
        <h1><yourdomain.com> server block is working!</h1>
    </body>
</html>

Save the test HTML file.

In order for Nginx to serve the content in /var/www/<yourdomain-withoutTLD>/html, one must create a server block with the correct directives. Create the server block:

sudo vim /etc/nginx/sites-available/<yourdomain-withoutTLD>

Paste the following configuration block into the server block:

server {
        listen 80;
        listen [::]:80;

        root /var/www/<yourdomain-withoutTLD>/html;
        index index.html index.htm index.nginx-debian.html;

        server_name <yourdomain.com> www.<yourdomain.com>;

        location / {
                try_files $uri $uri/ =404;
        }
}

Enable the server block by creating a symbolic link to it in the sites-enabled directory:

sudo ln -s /etc/nginx/sites-available/<yourdomain-withoutTLD> /etc/nginx/sites-enabled/

The sites-enabled is what Nginx reads during start-up. Creating a symbolic link in this manner allows one to easily enable and disable certain server blocks without deleting the actual server block.

With this server block enabled, now two server blocks are configured to respond to requests based on the listen and server_name directives:

/etc/nginx/sites-available/<yourdomain-withoutTLD> will respond to requests for <yourdomain.com> and <www.yourdomain.com>.
/etc/nginx/sites-available/default will respond to any requests on port 80 that do not match the others.

To learn more about how Nginx processes server blocks, see the article on understanding Nginx server and location block selection algorithms by Justin Ellingwood.

To avoid possible hash bucket memory problems that can arise from adding additional sever names in future, specify the bash bucket size in the Nginx configuration file. Edit the file:

sudo vim /etc/nginx/nginx.conf

Then uncomment the line #server_names_hash_bucket_size 64; by removing the octothrope (#) (i.e. the line should be server_names_hash_bucket_size 64;).

Save and close the file. Check there are no syntax errors:

sudo nginx -t

Restart Nginx to enable the changes:

sudo systemctl restart nginx

Nginx should now be serving the test HTML file to any requests made using your domain name. Test this by navigating to:

http://<yourdomain.com>

It is useful to familiarise yourself with the important directories and files of Nginx.

Setting Up HTTPS

Install Certbot

Ensure packages are up-to-date:

sudo apt update

Install certbot:

sudo apt install certbot

Check the Configuration of Nginx

Ensure that the enabled server block in /etc/nginx/sites-available/<yourdomain-withoutTLD> has the sever_name set appropriately:

...
server_name <yourdomain.com> www.<yourdomain.com>
...

Update Firewall Settings

Previously, the firewall was set up to allow only Nginx HTTP. Running the command:

sudo ufw status

You should see at least the following:

Status: active

To                         Action      From
--                         ------      ----
Nginx HTTP                 ALLOW       Anywhere                  
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Allow both HTTPS and HTTP traffic:

sudo ufw allow 'Nginx Full'

Delete the redundant Nginx profile for HTTP only traffic:

sudo ufw delete allow 'Nginx HTTP'

Recheck the status of the firewall:

sudo ufw status

The output should include at least the following:

Status: active

To                         Action      From
--                         ------      ----
Nginx Full                 ALLOW       Anywhere
Nginx Full (v6)            ALLOW       Anywhere (v6)

Get SSL Certificates and Reconfigure Nginx for HTTPS

Use certbot to generate the SSL certificates:

sudo certbot --nginx -d <yourdomain.com> -d <www.yourdomain.com>

By running certbot with the Nginx configuration, it will handle the necessary reconfiguration of Nginx for the two domain names given.

If this is the first time running certbot, you will be prompted to enter an email and agree to the terms of service. If you don't want to enter your email, use the --register-unsafely-without-email flag in the above certbot command.

If given the option to force redirection of HTTP traffic to HTTPS, enable this feature.

Once complete, certbot will tell you the process is complete and where your SSL certificates are stored.

Confirm HTTPS has been configured correctly by navigating to:

htts://<yourdomain.com>

Verify Auto-Renewal of Certificates

Let's Encrypt certificates are only valid for 90 days to encourage users to automate certificate renewal. The certbot package takes care of this by setting up a systemd timer that runs twice daily to automatically renew any certificate that is within 30 days of expiration. Check the status of the timer:

sudo systemctl status certbot.timer

Test the renewal process works:

sudo certbot renew --dry-run

If automated renewals fail, Let's Encrypt will send a reminder if you configured certbot with your email. If not, the responsibility will be on you to check.

Remove .HTML Extension from URLs

A request URI is the absolute path URL string, possibly followed by a URL query string, of the full URL given in the HTTP request. For example, the absolute path URL string and URL query string are indicted by the ^ and *, respectively, in the example below:

https://yourdomain.com/path/to/file?param=3#fragment
                       ^^^^^^^^^^^^ *******

To force all URLs to not use the .html extension, one can rewrite the request URI and then tell the client's browser, via a 301 status code, that the updated request URI (without the .html extension) should be used in future.

Edit your Nginx server block file:

sudo vim /etc/nginx/sites-available/<yourdomain-withoutTLD>

Replace the location block:

location / {
    try_files $uri $uri/ =404;
}

With the following:

location / {
    if ($request_uri ~ ^/(.*)\.html(\?|$)) {
        return 301 /$1;
    }
    try_files $uri $uri.html $uri/ =404;
}

Save and close the file. Reload Nginx:

sudo nginx -s reload