Wazuh is a monitoring solution with focus on security, combining features for XDR (Extended Detection and Response) and SIEM (Security Information and Event Management) into one platform. And the best part is, it’s free and open source.

Some of the capabilities of Wazuh are Log Data Analysis, Intrusion Detection, File Integrity Monitoring, Vulnerability Detection and Compliance Reporting.

By using a security monitoring solution like Wazuh it is possible to gain more insights into the security posture of the machines available so we can act faster in case threats and vulnerabilities arise to mitigate possible attacks.

In this article we are going to setup Wazuh and also install our first Wazuh agent on the machine of our choice to start collecting data.

Installation

The following steps will show how to setup Wazuh with Docker. It is possible to deploy Wazuh as a single-node or multi-node stack. The following steps show the deployment of the single-node stack.
As recommended per Documentation we will start by adding the following line to our /etc/sysctl.conf file:

vm.max_map_count=262144

Retrieving the source codes

First we will clone the Wazuh repository to our system via a git clone command:

git clone https://github.com/wazuh/wazuh-docker.git -b v4.10.1

Generating self signed certificates

Next we will move into the wazuh-docker/single-node folder. We are provided with the generate-indexer-certs.yml file through which we will generate some certificates for our wazuh containers. We will execute it with:

docker-compose -f generate-indexer-certs.yml run --rm generator

This will generate the certificates for the Wazuh indexer, Wazuh manager and Wazuh dashbaord.

If you don’t want to run the application behind a reverse proxy this would be it for the first part and a single docker-compose up would start the application and map it to host port 443.

Running Wazuh behind a Reverse Proxy

First adjust the docker-compose.yml file and map the Wazuh dashboard container port 5601 to host port 5601 or any other available port of your liking.

Next navigate to wazuh-docker/single-node/config/wazuh-dashboard and configure the opensearch_dashboard.yml file by commenting the server.ssl.key and server.ssl.certificate entries and changing the server.ssl.enable value to false.

server.ssl.enabled: false
#server.ssl.key: "/usr/share/wazuh-dashboard/certs/wazuh-dashboard-key.pem"
#server.ssl.certificate: "/usr/share/wazuh-dashboard/certs/wazuh-dashboard.pem"

With these changes the Wazuh setup should run behind the proxy after starting it with a docker-compose up.

Changing the default credentials

We probably don’t want to run Wazuh with the default credentials to make our application an easy target for attackers. Therefore we will now change them.

If your application is already running, stop it first with a simple docker-compose down command.

Inside config/wazuh_indexer/internal_users.yml we will find sections for the admin user and the kibanaserver user. The passwords stored in this file are hashed via bcrypt. After having decided for the new passwords we want to provide run the following command:

docker run --rm -ti wazuh/wazuh-indexer:4.10.1 bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh

This will start a prompt asking for the password and generate the corresponding bcrypt hashes. We will take these newly generated hashes and replace them with the old values inside the internal_users.yml file.

Afterwards we will need to also replace the values inside the docker-compose.yml file. For admin we replace the value wherever we find the INDEXER_PASSWORD entry (wazuh.manager and wazu.dashboard container). For kibanaserver we do the same for the DASHBOARD_PASSWORD entry (wazuh.dashboard container).

Now we start the Wazuh stack again via docker-compose up and access the bash shell of the single-node-wazuh.indexer-1. Easiest is to first determine the container ID via docker ps and then entering it with:

docker exec -t <Container ID of single-node-wazuh.indexer-1> bash

Inside the container we execute the following commands:

export INSTALLATION_DIR=/usr/share/wazuh-indexer
CACERT=$INSTALLATION_DIR/certs/root-ca.pem
KEY=$INSTALLATION_DIR/certs/admin-key.pem
CERT=$INSTALLATION_DIR/certs/admin.pem
export JAVA_HOME=/usr/share/wazuh-indexer/jdk

We wait a moment (2-5 minutes) as suggested by the Wazuh documentation and run finally

bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh -cd /usr/share/wazuh-indexer/opensearch-security/ -nhnv -cacert  $CACERT -cert $CERT -key $KEY -p 9200 -icl

We wait again a short moment and then the changes should be applied and the Wazuh dashboard accessible.

In case we want to also change the credentials for the API we would do this by changing the Password inside config/wazuh_dashboard/wazuh.yml and in the docker-compose.yml and re-run the whole stack via docker-compose down and up.

Deploying an Wazuh agent

To start collecting data from the machine of our choice, we need to deploy an Wazuh agent on it first. For this we log into our Wazuh dashboard and navigate to the agents section. Here we find the option to Deploy a new agent. We select the button and on the new page we select the OS and the file format in which the installation instructions should be delivered. For server address we provide the address through which the agent can reach the machine on which the Wazuh server is running. We provide a name for the agent and select a group to put it into. Next we are provided with installation instructions, e.g. a command to run.

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.1-1_amd64.deb \ 
&& sudo WAZUH_MANAGER='<IP>' WAZUH_AGENT_GROUP='default' WAZUH_AGENT_NAME='<Name>' \
dpkg -i ./wazuh-agent_4.10.1-1_amd64.deb

When the agent has been installed we enable and start wazuh agent service (command are also provided). And when we navigate back to the agents sections of the dashboard an entry should be listed for the deployed agent showing it in an active state.

Next steps

Now that we have set up Wazuh and deployed our first agent it is up to you to bring out everything Wazuh has to offer and configure it to your needs. This could include configuring the log sources that you want to observer, checking for vulnerabilities or suspicious files, configuring alerts and receiving notifications in case of events that require fast intervention.

For more information refer to the official Documentation.

In today’s competitive software development world, speed is crucial to develop new features, as well as improving existing features to stay ahead of the competition. Multiple developers of varying skill levels and work experience contribute to the software. Through the addition of new code lines the code base will grow larger over time. Through the differences level of experience and coding styles between the contributors the code base will also become more complex and in some areas even less efficient or insecure, making it more difficult to maintain.

SonarQube is a powerful static code analysis tool that helps development teams maintain high-quality, maintainable and secure code. It scans the the code base for potential issues like bugs, vulnerabilities and code smells to ensure problems are identified early. It can also be integrated into the CI/CD pipeline, ensuring that every code commit is automatically analyzed for issues. This integration provides developers with immediate feedback on code quality and security vulnerabilities. By using SonarQube, teams can siginificantly reduce the time spent on manual code reviews and prevent defects from reaching production, thereby improving overall efficiency and the software’s reliability.

Installation

SonarSource, the company behind SonarQube, provides a Docker Compose file that simplifies the process of running SonarQube. The code can be found at the following GitHub page. I’ve made slight adjustment to at the networks configuration settings and also moved credentials into environment variables stored in a .env file.

services:
  sonarqube:
    image: sonarqube:community
    restart: unless-stopped
    hostname: sonarqube
    container_name: sonarqube
    read_only: true
    depends_on:
      db:
        condition: service_healthy
    environment:
      SONAR_JDBC_URL: ${SONAR_JDBC_URL}
      SONAR_JDBC_USERNAME: ${SONAR_JDBC_USERNAME}
      SONAR_JDBC_PASSWORD: ${SONAR_JDBC_PASSWORD}
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
      - sonarqube_temp:/opt/sonarqube/temp
    ports:
      - "9000:9000"
    networks:
      - sast
  db:
    image: postgres:15
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d ${POSTGRES_DB} -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
    hostname: postgresql
    container_name: postgresql
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data
    networks:
      - sast

volumes:
  sonarqube_data:
  sonarqube_temp:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql:
  postgresql_data:

networks:
  sast:
    driver: bridge

SONAR_JDBC_URL: jdbc:postgresql://db:5432/${POSTGRES_DB}
SONAR_JDBC_USERNAME: <sonarqube_username>
SONAR_JDBC_PASSWORD: <sonarqube_password>
POSTGRES_USER: <postgres_username>
POSTGRES_PASSWORD: <postgres_password>
POSTGRES_DB: <postgres_database_name>

And finally run it with a simple

docker compose up #or docker-compose up

GitHub Integration

Now that Sonarqube is up and running, we can log in using our credentials and begin configuring it for integration with GitHub. The process is similar to integrating SonarQube with other DevOps platforms. Detailed instructions can be found in the documentation under the DevOps platform intergration section*.*

One thing I don’t like is that new projects are set to Public by default. To change this to Private, navigate to Administration → Projects → Management. On the page, just to the left of the blue Create Project button we will find the option to modify the default visibility setting for new projects, which can be switched from Public to Private.

Set up server base URL

First we need to configure a base URL for the application. To do this, we connect our application to a custom domain and secure it with a TLS certificate. For the sake of this example, I will use the domain example.com.

To set the base URL, navigate to Administration → General → Server base URL and enter the URL
(e.g., https://example.com).

Setting up a GitHub App

Now that we have configured the server base URL, we will create a GitHub Application to allow SonarQube access to the repositories. The steps presented are for a personal GitHub account, but they should also apply to GitHub organizations. For more information please refer to the documentation.

For this we log into out personal GitHub account and navigate to GitHub Profile → Settings → Developer Settings → New GitHub App. In the new Register new GitHub App page we will provide the following information:

• GitHub App name → Provide a name for this application

• Homepage URL → The base URL of SonarQube (https://example.com)

• Callback URL → The base URL of SonarQube again

• Webhook URL → Disable as per recommendation of the SonarQube documentation

• Permissions

  • Repository permissions

    • Checks → Read & Write

    • Administration → Read-only

    • Metadata (GitHub.com) | Repository metadata (GitHub Enterprise) → Read-only

    • Pull Requests → Read & Write

    • Private repositories: Content → Read only

    • Code scanning alerts → Read & Write

  • Organizations permissions

    • Administration → Read-only

    • GitHub Copilot Business → Read-only

    • Members → Read-only

    • Projects → Read-only

  • Account permissions

    • Email addresses → Read-only

• Select the “Only on this account” option under “Where can this GitHub App be installed?”

Once we are done creating the GitHub App, we will be taken to an overview page for newly created applications. Here we click the Generate a new client secret button, which generates a client secret that should be saved securely. It will be needed later to configure SonarQube. Also make notes of the App ID and Client ID of this application. Further down the page there is a Generate a private key button. We need to click it to generate and download the private key. Now that we have all the necessary credentials, we can continue the setup in SonarQube.

SonarQube DevOps Platform Integration

Now that we have created the GitHub application and saved all the necessary information, we can proceed in SonarQube. Navigate to Administration → Configuration → General Settings → DevOps Platform Integrations. Select GitHub and then click the Create Configuration button. This will open a popup window where we need to provide a name for the configuration. Next, we enter the GitHub API URL. Since we are using a personal GitHub account, we can use the default URL: https://api.github.com. In the following fields enter the App ID, Client ID and Client secret that we saved earlier. To provide the Private Key, simply retrieve it from the downloaded file.

cat <filename>.private-key.pem

-----BEGIN RSA PRIVATE KEY-----
AFGDSAFasdfasfasdfGAsd....
.........
SAFGSAgfaGADSFASDFSFSF
-----END RSA PRIVATE KEY-----

Copy the contents of the private key file and paste it directly into the provided field in the configuration. Once all required information has been entered, we submit the configuration and wait for the result. If everything is correct, we should see a confirmation message stating Configuration valid.

Next we navigate to the Projects page where we will se the Import from GitHub option. We select it and then choose our GitHub username from the dropdown list under Choose an organization. This will display all our repositories, from which we can select the ones we wish to import.

First Repository Scan

Let’s start our first repository scan. We navigate to Projects page → Import from GitHub → and select our username from dropdown. Then we choose a repository from the list of available repositories and click the Import button on the right.

On the next page, we select Use the global settings for now and create the project by clicking the Create Project button. Afterwards we will be directed to a new page where we can choose our analysis method. We select GitHub Actions.

On the following page, SonarQube will provide the necessary secrets, along with information for the sonar-project.properties and YAML files that need to be added to our repository. We follow the instructions, commit the required files to our project and shortly after, the pipeline should start running. Once the scan is complete, we will be able to view the results in our newly created project in SonarQube.

To ensure the health, performance and availability of our systems we need a way to monitor and observe our machines in use. Prometheus and Grafana are two of the most widely used solutions to achieve this goal.

Prometheus is an open-source monitoring solution which can collect data from multiple endpoints, query data with its PromQL (Prometheus Query Language), evaluate the data and trigger alerts based on given rules.

Grafana is an open-source monitoring solution as well, but it doesn’t collect the data from the endpoints directly. It uses data sources like Prometheus that already scraped the necessary data and it allows us to create visually appealing dashboards in which we can see the collected data through which we can make informed decisions about the state of our machines. Possible data to display are for example different metric values or logs and Grafana provides also the ability to create alerts based on given rules.

In the following I will guide you through the steps on how to quickly start with a basic Prometheus and Grafana setup. And we will also collect our first data from the host machine on which Prometheus and Grafana are running with the help of the Node exporter and present the data inside a dashboard.

Prerequisites

To follow this process for setting up Prometheus and Grafana, it is recommended to have some basic experience with Linux and Docker.

I will perform these steps on an Ubuntu server, an I am assuming you have already set up your own Linux-based environment with Docker installed.

Folder Structure

The following shows the folder structure of the directories and files in use to quickly start a basic Prometheus and Grafana environment.

/opt/monitoring
|---.env
|---docker-compose.yaml
|---prometheus
|   |---prometheus.yaml
|
|---grafana
    |
    |---provisioning
        |    
        |---dashboards
        |   |---dashboards.yaml
        |   |---node-exporter-full-dashboard.json
        |   
        |---datasources
            |---datasource.yaml

In the presented folder structure, the monitoring stack is organized within the /opt/monitoring directory, where everything needed for the Prometheus and Grafana setup is stored. This structure is designed to automate much of the configuration, ensuring that you can easily replicate the setup on different machines without having to manually adjust these settings through the web interfaces.

Inside the monitoring directory there are two files .env, which holds the credentials for logging into Grafana and the docker-compose.yaml file, which is used to define and start the services via Docker Compose.

Within the monitoring directory there are two subdirectories: prometheus and grafana. The prometheus folder contains the prometheus.yaml file, which is the primary configuration file for Prometheus. It defines how and from where Prometheus scrapes metrics data. The grafana folder contains a dashboard .json file, as well as the the necessary configuration files dashboard.yaml, which specifies the dashboards that should be automatically loaded when Grafana starts and the datasource.yaml file through which Prometheus is already provided as a data source.

Docker Compose

Let’s start with the longest file first.

The docker-compose.yaml file defines three services: Prometheus, Grafana and the Node exporter.
They are configured so they can communicate through the same network named monitoring. Also two volumes are defined, one for Prometheus and one for Grafana, ensuring persistent data storage for each service.

Prometheus Service

We use the latest Prometheus Docker image and configure the service the automatically restart, unless stopped manually. In the volumes section, we mount the prometheus-data Docker volume to ensure persistent storage of Prometheus data, and we also provide our custom prometheus.yaml configuration file. In the command section, we specify the location of the Prometheus configuration file and set the storage path to /prometheus where Prometheus will store the collected time series data. The service exposes the port 9090 to the host machine and is connected to the monitoring network.

Grafana Service

We use the latest Grafana Docker image and configure the container to restart automatically, unless manually stopped. In the volumes section, we mount the grafana-data Docker volume to persist Grafana’s data and also mount the dashboard and datasources folders into the container containing the pre-downloaded dashboards and .yaml configuration files. In the environment section we set the admin username and password using environment variables stored in the .env file. Additionally we disable the option for sign-up, ensuring only the admin can create new users. The service exposes port 3000 to the host machine and is connected to the monitoring network.

Node exporter Service

We use the latest Node exporter Docker image and configure the container to restart automatically unless manually stopped. In the volumes section we grant the container read-only access to the hosts’s /sys, /proc, and / mount points, enabling it to collect system metrics. Through the command section we configure the Node exporter to gather metrics from these specific mount points. This service exposes the port 9100 to the host machine and is connected to the monitoring network.

services:
  prometheus:
    image: prom/prometheus:latest
    restart: unless-stopped
    volumes:
      - ./prometheus/prometheus.yaml:/etc/prometheus/prometheus.yaml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yaml'
      -  "--storage.tsdb.path=/prometheus"
    ports:
      - 9090:9090
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    restart: unless-stopped
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/provisioning/dashboards:/etc/grafana/provisioning/dashboards
      - ./grafana/provisioning/datasources:/etc/grafana/provisioning/datasources
    environment:
      - GF_SECURITY_ADMIN_USER=${GF_ADMIN_USER}
      - GF_SECURITY_ADMIN_PASSWORD=${GF_ADMIN_PW}
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - 3000:3000
    networks:
      - monitoring

  node-exporter:
    image: prom/node-exporter:latest
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.rootfs=/rootfs"
      - "--path.sysfs=/host/sys"
    ports:
      - 9100:9100
    networks:
      - monitoring



networks:
  monitoring:
    driver: bridge

volumes:
  prometheus-data:
  grafana-data:

.env

The .env file is very small consisting of two variables.

GF_ADMIN_USER=<username>
GF_ADMIN_PW=<password>

prometheus.yaml

The prometheus.yaml file is structured into two main sections: global and scrape_configs.

In the global section, we define configurations that apply globally across all jobs. In this case, we set both the scrape_interval and evaluation_interval to 15 seconds. This means Prometheus will check every 15 seconds for new data to scrape and will evaluate the collected data at the same interval.

The scrape_configs section defines the various target from which Prometheus will collect data. Each target is associated with a unique job name for easier identification. In this example the first job is named prometheus with the target localhost:9090, which points to the Prometheus service itself. The second job is named node-exporter-local, with the target node-exporter:9100, referring to the Node exporter service. Since Prometheus and Node exporter are both part of the same monitoring network, Prometheus can directly access the Node exporter’s endpoint.

For more detailed configuration options to fine-tune the prometheus.yaml, please refer to the Prometheus Documentation.

global:
  scrape_interval:  15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ['localhost:9090']
  - job_name: "node-exporter-local"
    static_configs:
      - targets: ['node-exporter:9100']

datasource.yaml

To avoid manually adding the Prometheus service as a data source in Grafana after startup, we can create a file called datasource.yaml and provide it to Grafana. This configuration automatically connects Grafana to Prometheus when it starts.

For more information on how to further adjust the datasource.yaml, please refer to the Grafana documentation.

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus:9090
    basicAuth: false
    isDefault: true
    editable: true

dashboards.yaml

The dashbaord.yaml file is used to define how dashboards are provisioned in Grafana. Through this file we specify the location and settings for the dashboards that will be automatically loaded when Grafana starts.

For more information on how to adjust this configuration file to your needs please refer to the Grafana documentation at the Dashboards section.

apiVersion: 1

providers:
  - name: 'MyDashboards'
    orgId: 1
    folder: ''
    type: file
    disableDeletion: false
    updateIntervalSeconds: 10
    alloUiUpdates: true
    editable: true
    options:
      path: /etc/grafana/provisioning/dashboards

Retrieving existing Dashboard(s)

On the following site you can download a pre-configured dashboard that is tailored to visualize the metrics collected by the Node exported. We save the .json file for this dashboard into the dashboards folder. Due to our Docker Compose configuration, Grafana will automatically detect and load the dashboard at runtime.

Start the services

Now that all the necessary files are prepared, you can start the services with a simple command:

docker compose up

Depending on your version of Docker Compose you might need to use a hyphen in the command:

docker-compose up

Wait a moment for the services to start, and then navigate to the Grafana web interface at localhost:3000.

Log in using the credentials defined in the .env file. Once logged in you should see the Prometheus data source listed under Connections → Data Sources, and the Node exporter dashboard should be available under Dashboards.

What’s next?

Your next steps could involve identifying additional areas from which you want to collect data. For example, you could integrate cAdvisor into your existing Docker Compose setup to gain insight into the performance and resource usage of your running containers. Additionally, you may want to explore the creation of alerts for specific events, ensuring that you’re notified when critical conditions arise, allowing you to act quickly and effectively.

I wanted to setup a home server where I could run applications and access them when I am not at home. But I also wanted to avoid opening ports directly to my home network to access the services running on the home server. Another issue is that the global IP address received by my ISP changes every few days and I also didn’t want to work with something like DynDNS.

Therefore as a workaround I purchased a cheap Cloud VPS which has its own static IPv4 address through which I built a tunnel via a VPN connection to my home server for accessing the services.

Initial Setup

At first I went through the initial setup for both the home server and the VPS.

1. Installing the Server Software (Ubuntu Server)

2. Creating a dedicated user and granting it sudo access

3. Providing root and user with strong passwords

4. Upgrading all available packages

5. Removing SSH permission for root user

6. Allowing only SSH access via SSH key

7. Changing default SSH port to reduce Bot noises

8. Installing and activating unattended-upgrades

9. Installing and enabling fail2ban

10. Installing and running the web application

I won’t be going into details for these steps in this article since the focus is on the VPN connection between home server and the VPS.

VPN Connection Setup

After setting up the application on our home server, we need to setup the VPN connection between our home server and the VPS. For this I have been using Wireguard since it was far more easy to setup than any other VPN software.

The following steps are similar for both the home server and the VPS.

Wireguard Installation

The installation process is as easy as executing following commands in Ubuntu.

sudo apt update
sudo apt install wireguard

Private Key and Public Key Generation

Next we need to generate our private and public keys that we will provide to our Wireguard interface configuration files.

Private Key

umask 077
wg genkey > privatekey

Public Key

wg pubkey < privatekey > publickey

Wireguard Configuration File

After the installation of Wireguard a directory with the name wireguard will be available inside /etc.

Here we will create a .conf file and name it whatever we want. For simplicity I will name it the same as found in many other tutorials wg0.conf.

sudo touch /etc/wireguard/wg0.conf

VPS

On the VPS we will add the following lines to the configuration file.

# VPS
[Interface]
PrivateKey = <VPS Private Key>
Address = 10.0.0.1/24
ListenPort = 51820

# Home Server
[Peer]
PublicKey = <Home Server Public Key>
AllowedIPs = 10.0.0.2/32

Home Server

One the home server we will add the following lines to the configuration file.

# Home Server
[Interface]
PrivateKey = <Home Server Private Key>
Address = 10.0.0.2/24
ListenPort = 51820

# VPS
[Peer]
PublicKey = <VPS Public Key>
Endpoint = <Static IPv4 Address of VPS>
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25

You can add whatever private IP addresses you want to the Endpoints for the VPN connection. But they must be in the same subnet so they will be able to reach each other. In this case I decided to go with a 10.0.0.X/24 Subnet. The VPN subnet should also not overlap with the subnets of either endpoint.

It is also possible to assign a different Port, which becomes useful if you want to use multiple interfaces to establish different connections in order to separate different endpoints. In that case you would create an additional .conf file (e.g. wg1.conf) and start this interface similarly to the following steps shown for the wg0.conf example. Additionally this port must also be opened in the firewall, as shown later.

Enabling and Starting the Wireguard Interface

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

If you named your .conf file something else you would use the that name instead of wg0.

Allow Port 51820 on Firewall

In case UFW (Uncomplicated Firewall) is not installed and enabled yet, do it with the following commands.

sudo apt install ufw
sudo ufw enable

For the communication to work we will also need to open port 51820 on the home server. This is as easy as executing the following UFW command. This has to be done on both machines.

sudo ufw allow 51820/udp

We might also go a step further and permit connection to only IP address 10.0.0.1 for the application.

sudo ufw allow from 10.0.0.1 to any port <APPLICATION_PORT>
sudo ufw deny <APPLICATION_PORT>

Check VPN Connectivity

Now test the connectivity by trying to ping the other device.

ping 10.0.0.1 # From Home Server
ping 10.0.0.2 # From VPS

If the ping worked, we might also try to access the application with a curl command.

curl http://10.0.0.2:<APPLICATION_PORT>

Setting up a Reverse Proxy Connection to the Home Server Application

Now that we know that we are able to reach the application through our VPN connection, we need to configure the access from our VPS to the application.

This is fairly easy with Caddy as a Reverse Proxy. If you own a domain create an A record to the IP address of your VPS for the domain or subdomain of your choosing.

Next we will install Caddy on our VPS.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Firewall Adjustments

Before we continue with configuring Caddy we need to open the ports 80 and 443 both on our VPS as well as the firewall rules in our administration panel for our VPS provided by the cloud provider.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Caddy(file) Configuration

Now that Caddy is installed we need to configure the Caddyfile which is located under /etc/caddy.

https://<Your-Domain>{
    reverse_proxy 10.0.0.2:<APPLICATION_PORT>{
        header_up X-Real-IP {remote_host} 
        header_up X-Forwarded-For {remote_host} 
        header_up X-Forwarded-Proto {scheme} 
        header_up X-Forwarded-Port {server_port} 
    }
    header {
        -Server
    }
    log {
        output file /var/log/caddy/access.log
        format json
    }
}

This basic setup should work fine for the start and can be easily adjusted depending on the needs and how the application is installed and served on the home server (native or container).

It might be necessary to format the file correctly for it to work with. Run this following command when your are in the /etc/caddy directory where the Caddyfile resides.

sudo caddy fmt --overwrite

Enabling and Starting Caddy

sudo systemctl enable caddy
sudo systemctl start caddy

Caddy should automatically generate a TLS certificate for you. But in case not stop the service first.

sudo systemctl stop caddy

And run the command.

sudo caddy reverse-proxy --from <your-domain> --to 10.0.0.2:<APPLICATION_PORT>

Then restart caddy service again.

Check VPS Connectivity

At last we will check if everything works by opening our browser and typing in our domain and hopefully we will have established a secure HTTPS connection to our home server.

But it should be noted that one drawback of such an setup can be reduced speed. So choose wisely what applications you want to run and what data you want to access and send through this way of connection.

Resources

For fine tuning and more information I can recommend to visit the Wireguard and Caddy documentation.

Devices need to be able to understand each other when communicating over networks. The same way humans need to understand the language spoken by their communication partner. Otherwise the received information couldn't be processed to react properly.

For network communication the devices and applications use network protocols. These are rules that dictate how communication should take place. What information needs to be transmitted and how the information has to be evaluated.
Now vendors that create hardware devices and applications need to follow the rules of these protocols when designing them. This allows vendor-independent communication, since all devices no matter who produced them follow the same rules and speak the same language now.
Without them each vendor would have to come up with their own idea for network communication, therefore only the devices of this same vendor could communicate.

We might compare it with rules for sports. Even if two teams of different countries face each other in a match, they still know how to behave thanks to the rules that act as guidelines. But if each country had their own rules for a specific sport, then both teams would have learned the sport with different rules which would only cause chaos on the game field and simply wouldn't work.

Why do wee need network layers?

There are two network models available that are most referred when it comes to describing networks and their functions. These are the OSI and TCP/IP model. Both follow the same approach of dividing the network into layers.

In the previous section we did learn about protocols and rules. There are multiple network protocols available that operate on a different layer of these models. Thus each layer is responsible for handling different tasks and there are multiple protocols being used simultaneously when starting a network communication.
For example TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are protocols that both work at the Transport layer and their task is to establish a connection between two devices before data is sent.

With this layered approach not only are we able to take a closer look at the communication processes in more detail and understand them better, but in case of networking issues we are able to better pinpoint where those issues might come from and solve them.

While both models follow the same layering methodology, they differ in terms of layer number. The TCP/IP model describes the network with four layers, but the OSI model goes a step further an breaks the TCP/IP layers 1 and 4 into five additional layers, resulting in seven layers. As we can see from the cover image the layers 5, 6 and 7 of OSI can be mapped to the layer 4 of TCP/IP and the layers 1 and 2 of OSI can be mapped to the layer 1 of TCP/IP.

The TCP/IP model is more practical oriented and derives its name from the TCP and IP protocols, which serve as the foundational elements of the internet, since they were introduced before UDP. On the other hand, the OSI model provides a more theoretical perspective on networks, making it better suited for understanding network layer functions.

Short overview of layer functions

What happens with the data at each layer?

Data is also described as Protocol Data Unit (PDU). But when the data moves along the layers a new name will be assigned at different layers for better differentiation.
PDUs can have the following names: Bits, Frame, Packet, Segment (when transport protocol TCP is used), Datagram (when transport protocol UDP is used) and Data.
The following table presents a short overview.

A PDU consist of a body with the actual data and a header that contains information about how to handle the PDU at each layer. When data is sent, PDUs are passed down from the highest layer (Application) to the lowest layer (Physical). At each layer the PDU gets processed and new information gets added to the header. This is called encapsulation.
When data is received the data flow is in the opposite direction from lowest layer to highest layer until the data reaches the user. The additional PDU Header Information that have been added are now processed backwards at each layer and removed afterwards. Almost like peeling an onion layer by layer. This process is called de-encapsulation.

Let's look at it with an imaginary scenario. We work at a company and want to send a letter and put it in an envelope. The letter itself is our data and the envelope is our header. Before the envelope reaches the postman (the network media), it has to be passed down through different departments (the different layers). At each department our envelope with our letter in it is put in another envelope with new information added by the department. When the letter reaches the postman, it is nested into multiple envelopes. Now the postman delivers our letter to another company with the same structure as ours and passes it first to the department at the lowest hierarchy. They open the envelope, read the message relevant to them. Take the other envelopes out and pass them to the next higher layer, where they redo the process until the letter reaches the intended recipient.

To answer this question we first have to understand what exactly the internet is. In short the internet is the interconnection of multiple networks into one big network that stretches around the globe.

How are those networks interconnected?

Different types of equipment are at work here. We can categorize them into end devices, intermediary devices and network media. End devices are at the source or destination of every data transmission. Our computer, notebook, smartphone, tablet or printer would count as them. Intermediary devices are able to connect different networks with each other and route data between those intermediary devices. Routers and switches are part of this category. What is left are the network media. They allow us to connect those intermediary devices with each other so we can establish a connection between them. Those are cables and wireless connections.

This infrastructure we can enjoy today didn't happen overnight. Over the years all those devices had to be physically connected over larger regions, between countries and even continents. We can even see a map of the cables that have been laid underwater at this site https://www.submarinecablemap.com/. For wireless transmissions antennas and satellite is used.

How can we access the internet?

We receive access through our Internet Service Providers (ISP). They either provide us with a preconfigured router or we can use our own and configure it accordingly. Some routers have an in-built modem and switch. The modem allows us to connect with our ISP and the switch is necessary, so we can establish at least a cable connection if the router or our end devices don't have wireless functionality. When everything is set up and all devices are connected, we were able to create our own network to gain internet access. Connected devices receive a unique IP address from the router. This allows the router to know which device is sending and receiving data later on.

Networks can be as small as a home network, but can also be as big as a company network with many hundreds or thousands of users and devices. Depending on the scenario there are many types of network devices with advanced functions that can be used to fulfill the desired needs.

How does data travel the internet?

At last we circle back to our initial question. When we think about network connections, we need to think in form of data. But not in big chunks of data. Rather smaller pieces of data, also described as packets, in which the larger files get divided by our end device before it gets sent.

When we browse the web, we make requests to receive data from a destination. When we visit a website like Google, Amazon or Netflix. We ask its server to sent us information, so it can be shown in the browser. Our requests are sent in form of packets as mentioned earlier.
Those packets will reach our router, because it is our gateway to access all the information provided by the internet. Each packet contains information about the sender and destination in form of IP addresses. Now our router has to find the next best path for the packets and sends them on their way out. On their journey those packets have to pass multiple routers. And at each stop they as well try to find the next best path for these packets, so they can reach their destination.
After arriving at the desired destination, the information inside those packets get evaluated and the requested resource gets sent back to the source of the request (our end device). This is only possible because the packets contain the information from where they are coming from. And as you can guess, the answer of the destination will be sent in form of packets as well.
Now our router receives those response packets and forwards them to the correct device waiting for them. The end device puts all those packets back together and presents us with the awaited web page, stream or the downloaded file.

We see that intermediary devices like routers play a crucial role in networks. They provide our devices with an unique IP address, so they can be distinguished from one another. They receive data from inside and outside the personal network, evaluate the packet information and forward them accordingly. There are many more devices with equally important different functionalities as well like firewall appliances that are responsible for the security of networks. But in this article we have been interested in the movement of data between networks therefore our focus was on the routers.