DEV Community: Ibrahim Kabbash

Azure Sentinel in a Nutshell: A Beginner’s Overview

Ibrahim Kabbash — Sat, 12 Apr 2025 11:44:05 +0000

Security teams rely on SIEM tools to monitor and respond to threats, but managing them can be complex. Azure Sentinel, Microsoft’s cloud-native SIEM, not only addresses these challenges but also offers additional capabilities. This article breaks down what Azure Sentinel is and its basic components, followed by a quick demonstration of SSH brute force detection and alert creation as an example.

Table of Contents
Prerequisites
Azure Sentinel: The Basics
- Components
- Log Analytics Workspace
Demo: SSH Brute Force Detection
- Installing Syslog from the Content Hub
- Collecting Logs from Azure VM
- Creating Alert
Conclusion

Prerequisites

Azure Portal account.

Azure Sentinel: The Basics

Azure Sentinel is Microsoft’s cloud-native Security Information and Event Management (SIEM) tool, with built-in Security Orchestration, Automation, and Response (SOAR) capabilities. At its core, it’s designed to collect, analyze, and respond to security threats across your organization.

It can pull logs from Azure Active Directory, Office 365, firewalls, Syslog, and many more, then analyze and act on them. For example, with Syslog, Azure Sentinel can detect repeated failed SSH login attempts, which often indicate a brute force attack. It can then automatically trigger a playbook to block the suspicious IP address or notify your security team for further action.

Azure Sentinel’s Content Hub simplifies setup by providing pre-built solutions, including data connectors, analytics rules, and playbooks, making it easy to integrate sources like Azure Active Directory, Office 365, firewalls, and Syslog. Let’s break down some of them.

Components

These are the core elements you’ll find in Azure Sentinel’s sidebar, each playing a key role:

Content Hub: A centralized repository of out-of-the-box solutions and packages (plugins) for extending Sentinel’s capabilities. It includes pre-built content like data connectors, analytics rules, workbooks, playbooks, and hunting queries.
Data Connectors: Ingest data from a wide range of sources, including Azure services, AWS, on-premise systems, and third-party tools.
Workbooks: Customizable dashboards that provide interactive visualizations of your data, helping you analyze trends, investigate incidents, and respond to security threats.
Analytics: Create and manage detection rules for real-time threat monitoring. Includes pre-built rule templates, active rules, and scheduled analytics to identify suspicious activities automatically.
Hunting: Proactively search for threats using built-in or custom queries. Leverage advanced query languages like KQL (Kusto Query Language) to uncover hidden risks in your data.
Notebooks: Automate and enrich investigations using Jupyter notebooks. These are ideal for advanced threat hunting, incident investigation, and building machine learning models to enhance security operations.
Incidents: Group and manage related alerts into incidents, providing a centralized view for tracking and resolving security issues.
Playbooks: Automate responses to threats using workflows built in Logic Apps (an Azure service). Playbooks can trigger actions like blocking IPs, sending notifications, or escalating incidents based on predefined conditions.
Watchlist: Create custom lists of key data (e.g., high-risk IPs, privileged users) to prioritize or filter alerts during threat detection and investigation.

Log Analytics Workspace

Before we go further with Azure Sentinel, we’ll need to talk about Log Analytics first. Log Analytics is the backbone of Azure Sentinel, as it stores and organizes all the log data collected from your connected sources. Azure Sentinel cannot be created without a Log Analytics workspace because it relies on this workspace to query, analyze, and visualize the data for threat detection and response.

In short, Log Analytics provides the foundation, while Azure Sentinel builds on it to deliver advanced security operations.

Reference

Demo: SSH Brute Force Detection

We’ll do a demo to set up Azure Sentinel for detecting SSH brute force attacks. This includes installing the Syslog content hub, using the SSH rule template to create an alert, and seeing how Azure Sentinel responds to suspicious activity in real time.

Before starting, ensure you’ve setup Azure Sentinel and a Log Analytics workspace—both are straightforward to set up in the Azure portal, so just go through the creation process. You’ll also need to create an Azure Linux VM to collect the Syslog data for the demo.

Installing Syslog from the Content Hub

After setting up Azure Sentinel, go to Content Hub and search for Syslog.

Select it and click on Install. It should install the following:

2 data connectors (Syslog via AMA and Syslog via Legacy Agent).
1 workbook.
7 analytic rules (one of them is the SSH brute force).
9 hunting queries.

Collecting Logs from Azure VM

After installing the Syslog content solution, click on Data connectors in the sidebar. Select the Syslog via AMA and click on Open connector page then click on +Create data collection rule.

Name the rule anything you wish, I named mine vm-syslog. For resources, select the Azure VM you just created (or the one you want to collect Syslog data from). Set LOG_DEBUG minimum log level for both LOG_AUTH and LOG_AUTHPRIV then create. This will create a Data Collection Rule that forwards the specified Syslog data to your Log Analytics workspace, where Azure Sentinel can query and analyze it for threat detection.

Try SSHing into the Azure VM you created. Make sure to perform one successful login and one failed attempt with a non-existent user (test-user for example). You’ll soon see why as we move forward.

To confirm if the logs are collected, go to Azure Sentinel or Log Analytics Workspace and click on Logs in the sidebar. Open an empty query in KQL (Kusto Query Language) mode and run Syslog so you can see all the data in the Syslog table. If you don’t see anything yet, you may need to wait 5-15 minutes after the creation of the data collection rule.

Creating Alert

Rules are the heart of Azure Sentinel, they are used to detect security threats and generate alerts. Now that we’ve installed the Syslog content solution in Azure Sentinel, created a VM, and set up a data collection rule to gather the VM’s Syslog data, let’s proceed to create an alert. Navigate to Analytics in the Azure Sentinel sidebar.

Here, you’ll find Active rules, which are custom or built-in analytics rules currently running in Azure Sentinel, and Rule templates, which are pre-configured, out-of-the-box rule definitions provided by the content solution you’ve installed. These templates can be enabled or customized to create active rules. Click on Rule templates and you’ll find the SSH - Potential Brute Force rule template here, select it.

Each rule template comes with its own predefined rule query. You can also create your own custom query if you want to build a custom rule. Before we create the active rule, let’s test the query first. Open another empty query and copy the rule query from the SSH brute force rule template and execute it, just like we did with the Syslog query last time. We won’t see any results yet, right? That’s because we haven’t attempted 15 failed SSH logins. To test the query, let’s remove the lines let threshold = 15; and | where PerHourCount > threshold. This will give you the modified query to work with.

Syslog
| where ProcessName =~ "sshd"
| where SyslogMessage contains "Failed password for invalid user"
| parse kind=relaxed SyslogMessage with * "invalid user " user " from " ip " port" port " ssh2" *
// using distinct below as it has been seen that Syslog can duplicate entries depending on implementation
| distinct TimeGenerated, Computer, user, ip, port, SyslogMessage, _ResourceId
| summarize EventTimes = make_list(TimeGenerated), PerHourCount = count() by bin(TimeGenerated,4h), ip, Computer, user, _ResourceId
| mvexpand EventTimes
| extend EventTimes = tostring(EventTimes)
| summarize StartTime = min(EventTimes), EndTime = max(EventTimes), UserList = make_set(user), ComputerList = make_set(Computer), ResourceIdList = make_set(_ResourceId), sum(PerHourCount) by IPAddress = ip
// bringing through single computer and user if array only has 1, otherwise, referencing the column and hashing the ComputerList or UserList so we don't get accidental entity matches when reviewing alerts
| extend HostName = iff(array_length(ComputerList) == 1, tostring(ComputerList[0]), strcat("SeeComputerListField","_", tostring(hash(tostring(ComputerList)))))
| extend Account = iff(array_length(ComputerList) == 1, tostring(UserList[0]), strcat("SeeUserListField","_", tostring(hash(tostring(UserList)))))
| extend ResourceId = iff(array_length(ResourceIdList) == 1, tostring(ResourceIdList[0]), strcat("SeeResourceIdListField","_", tostring(hash(tostring(ResourceIdList)))))

Execute the query, and you should see the one failed SSH login attempt with the non-existent user that you made earlier. You did it though, right? Right?

Now, back to the rule template. Click on Create rule, and consider updating the description to avoid confusion when reviewing incidents later. In the Set rule logic section, change the threshold from 15 to 5 and set the query scheduling to run every 5 minutes. Leave everything else unchanged and create the active rule. Once created, you’ll find it under Active rules in Analytics.

Let’s test the alert now. Execute the command below (if you’re using Linux), it should do 6 failed attempts to the server. You may need to install sshpass package.

for i in {1..6}; do sshpass -p 'randomPassword' ssh -o StrictHostKeyChecking=no dummy-user@<ip-address>; done

After 5 minutes or more, go to Azure Sentinel and click on Incidents in the sidebar. You should see the incident created from the alert triggered by the brute force attempt we simulated. To confirm, you can run the query in Logs with the threshold set, and you should see matching results.

Conclusion

We covered what Azure Sentinel is, its components, and walked through a demo to detect SSH brute force attacks. By setting up Syslog, creating alerts, and simulating threats, we saw how Azure Sentinel efficiently monitors and creates incidents.

We didn’t get to cover playbooks, but they can be really handy for automated workflows. Playbooks are built on Logic Apps, a no-code/low-code Azure service, and they enable automated responses, like blocking IPs, sending alerts, and many other applications. Playbooks can even be used to forward incident data to Azure Event Hub, enabling integration between Azure Sentinel and Azure Event Hub. If you’re interested in sending Event Hub data to a log shipper like Fluentd, you can check out my article on integrating Azure Event Hub with Fluentd.

In summary, Azure Sentinel is a comprehensive solution for modern security teams, combining SIEM and SOAR functionalities to streamline threat management. It also offers advanced hunting, machine learning, and customizable workbooks for deeper insights.

Configuring Fluentd to Collect Data from Azure Event Hub

Ibrahim Kabbash — Sun, 30 Mar 2025 15:37:24 +0000

This guide covers setting up Fluentd to fetch data from Azure Event Hub using Kafka Fluentd plugin.

Prerequisites
Understanding Azure Event Hub
What is Fluentd?
Setting Up Fluentd for Azure Event Hub
- Creating Event Hub
- Fluentd Docker Compose Setup
- Using the Kafka Fluentd Plugin
- Testing and Verifying Data Collection
Conclusion

Prerequisites

Azure Portal account.
Docker.

Understanding Azure Event Hub

Azure Event Hub is a real-time data streaming service similar to Apache Kafka. It supports Kafka protocol, allowing Kafka applications to send and receive messages without modification. Like Kafka, it handles high-throughput event ingestion, partitioning, and consumer groups.

Event streaming platforms like Azure Event Hub and Kafka follow a publish-subscribe model. Producers send messages to a specific topic (or event hub), where they are stored in partitions. Consumers, which are subscribed to the topic, read messages from these partitions, processing them in real-time or batch mode. Each consumer group tracks its offset to ensure messages are processed efficiently without duplication.

TL;DR: Producers generate data to a specific topic, consumers are subscribed to the topic and receive the data.

The following table maps concepts between Kafka and Event Hubs.

Kafka Concept	Event Hubs Concept
Cluster	Namespace
Topic	An event hub
Partition	Partition
Consumer Group	Consumer Group
Offset	Offset

Note that you’ll need at least Standard tier because there is no Kafka consumer in the Basic tier.

What is Fluentd?

Fluentd is an open-source data collector used to unify logging by collecting, transforming, and routing log data across different systems. You can collect data from various sources like files, databases, protocols, etc.. and send them to other various destinations as well.

This Fluentd config sets up an HTTP input on port 9880 to receive data and saves it as JSON where the destination is a file. The tag-name is used to route logs, ensuring data flows from the source to the correct output.

<source [tag-name]>
  @type http
  port 9880
  bind 0.0.0.0
  body_size_limit 32m
  keepalive_timeout 10s
</source>

<match [tag-name]>
  @type file
  path /output/alert-logs
  append true
  format json
</match>

Fluentd can also parse logs, format them, and route them to more than just files—it can send data to databases, cloud storage, or even message queues, making it great for centralized logging.

We’ll take similar concept from the config above where the source will be a Kafka input plugin.

Setting Up Fluentd for Azure Event Hub

Creating Event Hub

Go to your Azure portal and search for Event Hubs then click on “Create event hubs namespace.”
Pick or create a resource group.
Pick a unique namespace name.
Choose the Standard pricing tier.
Keep everything else default and click on “Review + create.”
Go to the event hub namespace resource you created.
On the side bar, click on “Event Hubs” under entities and create an Event Hub with a name (I named mine test-hub).
Select the event hub you just created.
On the side bar, click on “Shared access policies” under settings and add a new policy named listen-policy with listen access.
After creation, copy one of the connection strings and keep it somewhere for later steps.

- Be sure you’ve created the shared access policy in the event hub itself, not the event hub namespace.

Fluentd Docker Compose Setup

You can use these files from my tutorials repo or create the following below:

Dockerfile for Fluentd, installing the Kafka plugin.

FROM fluent/fluentd:v1.17-debian-1
# Install Kafka plugin
USER root
RUN fluent-gem install fluent-plugin-kafka
USER fluent

Fluentd docker-compose.yaml file.

services:
  fluentd:
    container_name: fluentd
    hostname: fluentd
    build: .
    volumes:
    - ./fluentd.conf:/fluentd/etc/fluentd.conf:ro
    - ./logs:/var/log/fluentd

Create logs directory and change its ownership to Fluentd’s container UID.
```
mkdir logs && sudo chown 999:999 logs
```

Using the Kafka Fluentd Plugin

You can use the plugin to both consume and produce data, in our case, we’ll configure to consume data from Event Hub using Event Hub’s Shared Access Signatures (SAS) for delegated access to Event Hubs for Kafka resources.

Use the fluentd.conf below and update it with your Event Hub’s name, Event Hub namespace name, and connection string. The HUB_NAME in this article’s case is test-hub, the namespace name is test1Mx4.servicebus.windows.net, and replace the connection string accordingly.

<source>
  @type kafka
  brokers [EVENT_HUB_NAMESPACE].servicebus.windows.net:9093
  topics [HUB_NAME]
  username $ConnectionString
  password [EVENT_HUB_CONNECTION_STRING]
  ssl_ca_certs_from_system true
  format json
</source>

<match [HUB_NAME].**>
  @type file
  path /var/log/fluentd/
  append true
  <format>
      @type json
  </format>
</match>

It should look like this after updating the fluentd.conf file.

<source>
  @type kafka
  brokers test1Mx4.servicebus.windows.net:9093
  topics test-hub
  username $ConnectionString
  password Endpoint=sb://test1mx4.servicebus.windows.net/;SharedAccessKeyName=listen-policy;SharedAccessKey=<secret-key>=;EntityPath=test-hub
  ssl_ca_certs_from_system true
  format json
</source>

<match test-hub.**>
  @type file
  path /var/log/fluentd/
  append true
  <format>
      @type json
  </format>
</match>

Testing and Verifying Data Collection

After setting up the files, execute docker compose up --build and be sure that the container is running fine.

CONTAINER ID   IMAGE                            COMMAND                  CREATED              STATUS              PORTS                 NAMES
73654ee6e84b   fluentd-azure-eventhub-fluentd   "tini -- /bin/entryp…"   About a minute ago   Up About a minute   5140/tcp, 24224/tcp   fluentd

To test, open your Event Hub’s Data Explorer from the sidebar and click "Send Events." Choose a pre-canned dataset as an example, then click "Send" to produce it to the hub for Fluentd to consume.

After the data gets sent to Event Hub, check your Fluentd logs directory as it should generate buffer files that store the produced data by consuming them from Event Hub.

Conclusion

In this guide, we set up Fluentd to fetch data from Azure Event Hub using the Kafka Fluentd plugin. We covered the basics of Azure Event Hub, configured Fluentd with Docker, and verified data collection by producing events and checking Fluentd’s log directory for buffered data.

With this setup, you can integrate Fluentd into your logging pipeline to collect, process, and route event data efficiently. For example, you can create a playbook in Azure Sentinel to export incident data to Event Hub and Fluentd will act as a log shipper for other destinations. You could also apply this approach to Azure Log Analytics, exporting data to Event Hub for Fluentd to forward to other destinations.

Customize Your Linux Desktop: A Beginner’s Ricing Guide

Ibrahim Kabbash — Mon, 24 Mar 2025 14:29:24 +0000

Ever wanted to customize your Linux desktop but felt lost in all the components and choices? You’re not alone—I’ve been there too. This guide is for beginners and anyone looking to rice their setup, covering most things you need to know, from window managers and bars to shells and more, no matter what distro you use.

Prerequisites
Note
Desktop Environments vs Window Managers
- Desktop Environments
- Window Managers
Ricing Components
- Bar
- File Manager
- Terminal
  - Shell
- Application Launcher
- Compositors
Conclusion

Prerequisites

Linux knowledge is preferable.

Note

Regarding the display servers (X11 and Wayland), not every component is compatible with Wayland. Some apps, window managers, and ricing tools may work differently or not at all compared to X11. Check compatibility before choosing your setup. I recommend looking them up and doing your research while ricing.

Desktop Environments vs Window Managers

Before diving in, you’ll need to decide whether to base your setup on a desktop environment or a window manager. Desktop environments come with a structured layout and built-in tools, making them easier to set up but more restrictive in customization. Window managers, on the other hand, give you full control over your system’s look and behavior, allowing you to customize everything from keybindings to window management—but they require more manual configuration.

Desktop Environments

When ricing a desktop environment, keep in mind that customization is often limited by its design, some require extensions or third-party tools, and updates may break custom themes or configurations.

Some of the popular desktop environments are:

GNOME: Minimalist and modern but not very customizable without extensions.
KDE: Customizable and feature-rich.
XFCE: Lightweight and fast.

Take your time looking into each one of them and pick the one best suited for you if you’re going for desktop environment.

Window Managers

When ricing a window manager, you have near-complete control, but setup requires manual configuration. Many Window Managers do not have built-in features like launchers, requiring extra tools and time to setup. Config complexity varies by window manager, but it pays off.

Some of the popular window managers are:

Qtile: Written in Python, highly configurable and easy to extend, but requires scripting knowledge.
AwesomeWM: Highly customizable, but its Lua-based configuration has a learning curve.
Hyprland: A modern Wayland compositor with smooth animations but but Wayland’s compatibility limitations can cause issues (as of writing this).

Ricing Components

Ricing involves customizing various components to however you want. Key components include bars for system info, file managers for navigation, terminals, and so on. We’ll be looking into each and their popular options.

Bar

The bar is a panel that displays system information, workspaces, open windows, etc..

For bar customization, you can use the one from your desktop environment, configure your window manager’s built-in bar (if available), or install a third-party option.

Some of the popular third-party options (compatibility varies between X11 and Wayland, so check support before choosing): Polybar, Waybar, Latte-dock, etc..

File Manager

The file manager is where you navigate, organize, and manage files and directories, using either a graphical interface or a terminal-based alternative. Popular options include Thunar, Dolphin, and Nautilus for GUI, or ranger for terminal-based management.

Terminal

The terminal is where you run commands, manage your system through, you know? Popular options include Alacritty, which is fast and minimal with GPU acceleration, Kitty, which also uses the GPU acceleration but offers extra features like tab management, and Terminator, which focuses on tiling multiple terminal panes in one window.

Shell

You can also customize your shell to improve functionality and appearance. Popular options include Bash (the default on most systems), Zsh, which supports plugins, and Fish, which has user-friendly syntax. You can change how your shell looks using customizable prompts like Starship, no matter which shell you’re using.

Application Launcher

The application launcher lets you find and run apps instantly without navigating menus. Popular options include Rofi and dmenu.

Compositors

A compositor is responsible for rendering and managing window effects, transparency, and animations. Although take note that it’s not ideal for gaming as it can cause frame drops.

One of the popular compositors is Picom, which is a lightweight X11 compositor with transparency, blur, and shadow effects.

Conclusion

Ricing your Linux setup is all about making it your own, both in looks and functionality. Whether you choose a desktop environment or a window manager, understanding the key components like bars, terminals, and shells will help you build a setup that suits your workflow. Take your time to experiment, research, and tweak configurations according to your need.

You can find inspiration for ricing by exploring community setups on forums and GitHub dotfiles, helping you discover new ideas and tools.

The screenshots below showcase my setup using Qtile as the window manager with a customized built-in bar, Alacritty as the terminal with Bash and Starship, and Rofi as the application launcher. Feel free to take inspiration from it, and you can find my dotfiles on GitHub.

Helm On Azure Container Registry: The Simple Way

Ibrahim Kabbash — Sat, 02 Dec 2023 12:44:20 +0000

This article walks through how to push and pull Helm charts on Azure Container Registry (ACR) locally. The same concept can also be used on a pipeline for automation.

Prerequisites
Note
Pushing To ACR
Pulling From ACR
Conclusion

Prerequisites

Azure Portal account
Helm installed
Azure Container Registry created

Note

The Helm chart version I’m using is version 3.10, there is an issue with Helm version 3.13 unable to push or pull charts to ACR even after logging into the registry successfully, throwing a status code 401 error.

Pushing To ACR

Navigate to your created ACR (mine is named blogacr21), on the sidebar, scroll down then click on Tokens (right under Repository permissions) and create a new token. Define the token name and scope map (_repositories_push for the current case). Click on your newly created token then generate for yourself a password.

Login to your ACR with your created token by using the following command (blogacr21 is my acr_name, PushingToken is my token_name). You’ll be asked to enter a password, paste the one that you generated.

helm registry login <acr_name>.azurecr.io/helm --username <token_name>
# Login Succeeded

In case you don’t have a Helm chart, create one and package it for it to be pushed.

helm create demo-chart
helm package demo-chart
# Successfully packaged chart and saved it to: /path/to/demo-chart-0.1.0.tgz

Push the chart using helm push command, it’ll be a successful push when it returns the hash digest, you should find the same digest if you checked on your repository.

helm push demo-chart-0.1.0.tgz oci://blogacr21.azurecr.io/helm
# Pushed: blogacr21.azurecr.io/helm/demo-chart:0.1.0
# Digest: sha256:d6aecffcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Pulling From ACR

Just like in the previous steps for pushing to the repository, you’ll need to create another token that has pulling permissions (or you could use the admin scope map but wouldn’t be a good security practice if it got compromised). ACR offers that you can create your custom scope map even targeting a specific repository only than having it on all repositories (just an extra best practice!) Go to Scope maps and create a new scope map. To have pulling permissions only, check just content/read and metadata/read permissions.

Create a new token and assign the scope map to the one that you just created for pulling the helm chart, then generate a new password and do registry login using the new token.

helm registry login <acr_name>.azurecr.io/helm --username <token_name>
# Login Succeeded

When a successful helm pull command is executed, you’ll find the packaged chart downloaded.

helm pull oci://blogacr21.azurecr.io/helm/demo-chart
# Pulled: blogacr21.azurecr.io/helm/demo-chart:0.1.0
# Digest: sha256:d6aecffcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

If you tried pulling another Helm chart (say helm/demo-chart2) using the same pulling token where it has scoped just on the demo-chart repository, it shouldn’t be authorized and you should receive a status code 401.

helm pull oci://blogacr21.azurecr.io/helm/demo-chart2
# Error: GET "https://blogacr21.azurecr.io/v2/helm/demo-chart2/tags/list": unexpected status code 401: unauthorized: authentication required, visit https://aka.ms/acr/authorization for more information.

Even if you tried pushing the same chart using the pulling token it shouldn’t be authorized as well because it lacks write permissions.

helm push demo-chart-0.2.0.tgz oci://blogacr21.azurecr.io/helm
# Error: server message: insufficient_scope: authorization failed

Conclusion

There can be other ways to use ACR and storing your Helm charts in them. However, using tokens can be the quickest way to set things up even on pipelines for automation, and if scope maps were used you can avoid having the risk of getting the entire repository compromised.

Configure mTLS with Nginx and EasyRSA

Ibrahim Kabbash — Sat, 18 Nov 2023 11:09:49 +0000

The goal of this article is to explain the concept of Mutual Transport Layer Security (mTLS) protocol, how it works, the role of each component and all with an example as a proof of concept.

Prerequisites
mTLS Anatomy
Demo
- Generate certificates and keys
- Setup Nginx
Testing
Conclusion

Prerequisites

Nginx knowledge
Secure Sockets Layer (SSL) / Transport Layer Security (TLS) and authentication knowledge
A virtual machine with Nginx and EasyRSA installed (preferably from the repo)
Linux knowledge

mTLS Anatomy

Before implementing the demo, let’s first have a good idea about mTLS and how does it compare to the usual SSL/TLS security protocols. SSL is primarily used to secure communication between a client (such as a web browser) and a server (such as a web server) which focuses on server authentication, where the client verifies the server's identity. Meanwhile mTLS on the other hand, is designed for mutual authentication. Both the client and the server are required to present their digital certificates to prove their identities, this ensures both parties can trust each other. The mTLS protocol can expand in case scenarios from VPNs to other case scenarios such as IoT for device authentication.

In mTLS, both the client and the server are verified and authenticated using digital certificates through a trusted Certificate Authority (CA). The following figure illustrates the request flow and how trust is established.

Demo

So we’re gonna need a server which has an Nginx running on and to generate a self-assigned certificate authority and using that certificate authority we’ll also need a client and server certificates and keys. All the certificates will be created using EasyRSA.

Generate certificates and keys

In your EasyRSA directory (where you installed it) create a public key infrastructure (PKI) in case you haven’t yet, if you did skip this step.

./easyrsa init-pki

After that, generate the CA certificate using the following command (if you want to add a pass phrase remove the nopass option)

./easyrsa build-ca nopass

You have created a self-assigned CA certificate, you can begin creating your own server and client certificates. We’ll create a server certificate for Nginx using the following command so it can host on SSL, then copy the server certificate and key to Nginx’s SSL directory

./easyrsa build-server-full server nopass
mkdir /etc/nginx/ssl
cp /path/to/easyrsa/pki/issued/server.crt /etc/nginx/ssl
cp /path/to/easyrsa/pki/private/server.key /etc/nginx/ssl

Server’s done, now you can create the client’s certificate and keys and they’ll be called client (or any other name you’d like). Be sure to copy them into your local machine for testing from the issued directory and private directory inside EasyRSA as well

./easyrsa build-client-full client nopass

Lastly generate a Certificate Revoke List (CRL), it’ll be explained further in the testing section why its needed

./easyrsa gen-crl

Setup Nginx

In order to use mTLS we’ll configure Nginx to require client authentication and ensure the client presents their own certificate that was made from our CA when they connect. Make sure to specify the location of your CA root certificate and the CRL below as they’re the crucial components for verification.

server {
        listen 80;
        server_name haha-example-server.com;
        location / {
                return 301 https://$host$request_uri;
        }
}

server {
  listen 443 ssl;
  server_name haha-example-server.com;

    # server's certificate
  ssl_certificate     /etc/nginx/ssl/server.crt;
  ssl_certificate_key /etc/nginx/ssl/server.key;

    # specify path to CA
  ssl_client_certificate /path/to/easyrsa/pki/ca.crt;
    # specify path to CRL
  ssl_crl /path/to/easyrsa/pki/crl.pem;
  ssl_verify_client  on;

    # optional in case you wanted to troubleshoot
  access_log /var/log/nginx/mtls.access.log;
  error_log /var/log/nginx/mtls.error.log;

  location / {
    return 200 OK;
      }
}

The ssl_client_certificate used to verify client certificates presented during mTLS, while ssl_crl helps Nginx check if client certificates have been revoked by the CA before accepting them for mTLS. Finally, ssl_verify_client determines whether the server verifies client certificates during mTLS handshake or not. Can also be set to either off or optional.

Testing

We’ll be making an authenticated request with the curl command using the client’s certificate and private key. Make sure to add the host in your hosts file with the IP of the machine that you configured the web server with.

curl -Lks --cert /path/to/client.crt --key /path/to/client.key https://haha-example-server.com

The curl command’s options explained:

L redo the request on the new redirection
k explicitly allows "insecure" SSL connections
s silent mode to not show progress bar

If all is well, you should be getting an OK response hence the mTLS verification succeeded! Otherwise you’ll be getting the following response if the client is revoked, if the certificate is from a different CA, or if the certificate has been expired.

<html>
<head><title>400 The SSL certificate error</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The SSL certificate error</center>
<hr><center>nginx/1.24.0</center>
</body>
</html>

What if you don’t want that client to be able to authenticate anymore? Simply go back to your web server’s EasyRSA directory and execute the following.

md5sum /path/to/easyrsa/pki/crl.pem
./easyrsa revoke client
./easyrsa gen-crl
nginx -s reload
md5sum /path/to/easyrsa/pki/crl.pem

To explain the role of the CRL file further, if you ran the md5sum before revoking and after you’ll notice the hash value of the file is different, and that’s because it was changed. The CRL file contains a list of revoked certificates, allowing Nginx to check the revocation status of certificates during the request initiation. If you tried to use the curl command on the same certificate again it should give you a status code 400.

If you would like to create a certificate that’ll expire tomorrow using EasyRSA, open the vars file using your favorite text editor and uncomment the following line adding 1 so it’ll expire tomorrow.

set_var EASYRSA_CERT_EXPIRE 1

Conclusion

The mTLS can be implemented in many other ways and for many other use cases, it could be used as a license checker, an identity verification, or even to secure cross-service communication between microservices. You can test using an API instead of Curl command if you would like. Just be sure to manage your certificates properly and you’re good to go!

DEV Community: Ibrahim Kabbash

Azure Sentinel in a Nutshell: A Beginner’s Overview

Table of Contents

Prerequisites

Azure Sentinel: The Basics

Components

Log Analytics Workspace

Demo: SSH Brute Force Detection

Installing Syslog from the Content Hub

Collecting Logs from Azure VM

Creating Alert

Conclusion

Configuring Fluentd to Collect Data from Azure Event Hub

Table of Contents

Prerequisites

Understanding Azure Event Hub

What is Fluentd?

Setting Up Fluentd for Azure Event Hub

Creating Event Hub

Fluentd Docker Compose Setup

Using the Kafka Fluentd Plugin

Testing and Verifying Data Collection

Conclusion

Customize Your Linux Desktop: A Beginner’s Ricing Guide

Table of Contents

Prerequisites

Note

Desktop Environments vs Window Managers

Desktop Environments

Window Managers

Ricing Components

Bar

File Manager

Terminal

Shell

Application Launcher

Compositors

Conclusion

Helm On Azure Container Registry: The Simple Way

Table of Contents

Prerequisites

Note

Pushing To ACR

Pulling From ACR

Conclusion

Configure mTLS with Nginx and EasyRSA

Table of Contents

Prerequisites

mTLS Anatomy

Demo

Generate certificates and keys

Setup Nginx

Testing

Conclusion