My IT Journal

Secondary DNS Server

Thu, 09 Jul 2026 00:00:00 +0000

Objective

Configure a Secondary DNS server that automatically replicates DNS zones from the Primary DNS server using zone transfers (AXFR).

Environment

Virtualization: VirtualBox
OS: ( 1 Primary DNS Server VM + 1 Secondary DNS Server + 1 Web Server VM + 1 Client VM)

Network Topology

Prerequisites

This lab builds upon the following previous labs:

Private DNS Infrastructure with BIND9
Hosting Multiple Websites on One Server Using Nginx

The following components are assumed to already be configured:

HTTPS with Nginx using a Private Certificate Authority

Wed, 08 Jul 2026 00:00:00 +0000

HTTPS with Nginx using a Private Certificate Authority

Objective

Secure an existing Nginx website using HTTPS and a certificate signed by a private Certificate Authority.

Environment

Virtualization: VirtualBox
OS: ( 1 DNS Server VM + 1 Web Server VM + 1 Client VM)

Network Topology

Prerequisites

This lab builds upon the Private DNS Infrastructure with BIND9. The following components are assumed to already be configured:

BIND9 installed and running on the DNS server.
The company.lab DNS zone created and configured.
The zone file (/etc/bind/db.company.lab) already exists.
The client is configured to use the internal DNS server (192.168.10.10) via Netplan.
DNS resolution between the client and the DNS server has been verified.

Phase 1 - Verify DNS Resolution

Before enabling HTTPS, verify that DNS resolves the web server correctly.

Configuring Reverse DNS (PTR Records) with BIND9

Sat, 04 Jul 2026 00:00:00 +0000

Configuring Reverse DNS (PTR Records) with BIND9

Objective

Extend the existing private DNS infrastructure by configuring Reverse DNS (PTR records). This enables IP addresses to be resolved back to hostnames, complementing the forward lookup zone created in previous labs.

By the end of this lab, the DNS server will support both:

Forward lookups (hostname → IP address)
Reverse lookups (IP address → hostname)

Environment

Virtualization: VirtualBox
OS: ( 1 DNS Server VM + 1 Web Server VM + 1 Client VM)

Network Topology

Hosting Multiple Websites on One Server Using Nginx

Fri, 03 Jul 2026 00:00:00 +0000

Hosting Multiple Websites on One Server Using Nginx

Objective

Host multiple websites on a single web server by combining:

DNS (BIND9) Nginx Virtual Hosts (Server Blocks)

Environment

Virtualization: VirtualBox
OS: ( 1 DNS Server VM + 1 Web Server VM + 1 Client VM)

Network Topology

Prerequisites

This lab builds upon the Private DNS Infrastructure with BIND9 (3-VM Lab). The following components are assumed to already be configured:

BIND9 installed and running on the DNS server.
The company.lab DNS zone created and configured.
The zone file (/etc/bind/db.company.lab) already exists.
The client is configured to use the internal DNS server (192.168.10.10) via Netplan.
DNS resolution between the client and the DNS server has been verified.

In this lab, the existing DNS infrastructure is extended by adding additional DNS records and configuring Nginx virtual hosts to host multiple websites on a single web server.

Private DNS Infrastructure with BIND9

Thu, 02 Jul 2026 00:00:00 +0000

Private DNS Infrastructure with BIND9

Objective

Build a private DNS infrastructure using BIND9 where:

A DNS server resolves names in the company.lab domain.
A web server hosts a website.
A client uses the DNS server to locate and access the web server.

Environment

Virtualization: VirtualBox
OS: ( 1 DNS Server VM + 1 Web Server VM + 1 Client VM)

Network Topology

Phase 1 - Configure DNS Server

Step 1 - Install BIND9 and verify

sudo apt update
sudo apt install bind9 bind9-utils dnsutils
sudo systemctl status named/bind9
ss -tulnp | grep 192.168.10.10:53

Linux Firewall & DMX Networking Lab

Wed, 17 Jun 2026 00:00:00 +0000

Objective

The lab focuses on troubleshooting real-world network failures by systematically isolating issues at each layer of the network stack.

Network Topology

LAN (User Network)		DMZ (Service Network)
192.168.10.0/24			192.168.20.0/24
__________________		_____________________

Client VM			Server VM
192.168.10.101			192.168.20.10
	|				|
	|				|
	________ Firewall VM ___________
		(Router + Firewall)

Issue 1: No connectivity between networks

Failure to connect to the webserver

Troubleshooting Workflow

Step 1 - Verify the service exists

From Server:

DMZ Network Lab - Firewall, Routing, and nftables

Tue, 16 Jun 2026 00:00:00 +0000

Objective

The goal of this lab is to design and implement a basic DMZ (Demilitarized Zone) network using Linux virtual machines, understand routing between network segments, and apply nftables as a stateful firewall.

Network Topology

LAN (User Network)		DMZ (Service Network)
192.168.10.0/24			192.168.20.0/24
__________________		_____________________

Client VM			Server VM
192.168.10.101			192.168.20.10
	|				|
	|				|
	________ Firewall VM ___________
		(Router + Firewall)

VM & Routing Configuration

Client VM

sudo netplan try
sudo netplan apply

Firewall VM (Core Router)

Linux nftables Firewall Fundamentals Lab

Mon, 15 Jun 2026 00:00:00 +0000

Objective

Lab Environment

Client VM 1 - 192.168.10.101 Client VM 2 - 192.168.10.102 Server VM - 192.168.10.10

Server Setup

Step 1 - Run web server

python3 -m http.server 8080
ss -tln | grep :8080

Step 2 - Base firewall configuration

sudo nft add table inet filter
sudo nft add chain inet filter input \
'{ type filter hook input priority 0; policy drop; }'
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input ct state established,related accept

LUKS Full Disk Encryption Lab (Attack & Defense)

Fri, 12 Jun 2026 00:00:00 +0000

Objective

This lab demonstrates how Linux Full Disk Encryption (LUKS) works and what it protects against.

Part 1 - Attack Scenario (Unencrypted Disk)

Step 1 - Identify disk

lsblk

Step 2 - Create filesystem (no ecnryption)

sudo mkfs.ext4 /dev/sdc

Step 3 - Mount disk

sudo mkdir /mnt/test
sudo mount /dev/sdc /mnt/test

Step 4 - Add sensitive data

echo "Sensitive data" | sudo tee /mount/test/secret.txt

ATTACK SIMULATION

Step 1 - Direct mount attempt

sudo mkdir /mnt/attack; sudo mount /dev/sdc /mnt/attack
ls -l /mnt/attack
cat /mnt/attack/secret.txt

GRUB Security Lab: Boot-Time Privilege Escalation & Hardening

Thu, 11 Jun 2026 00:00:00 +0000

Attack Simulation: Gaining Root Access via GRUB

Objective

Demonstrate how physical access to a Linux system can be abused to gain root privileges by modifying GRUB boot parameters.

Prerequisites

OS: Linux Ubuntu
Access to GRUB menu during boot
No GRUB password protection enabled

Attack Steps

Reboot the system and access the GRUB menu.
Select the default Linux entry and press e to edit boot parameters.
Locate the line starting with: linux /boot/vmlinuz-…
Modify the line
Boot the modified entry using Ctrl + X

USB Automounting with systemd

Sat, 06 Jun 2026 00:00:00 +0000

Objective

Setting up automatic USB drive mounting on a Linux server using systemd mount and automount units

Environment

OS: Ubuntu
Tools: system, USB drive

Step 1 - Find Partition UUID

Prerequisite: Plugin USB drive

blkid /dev/sdb1

Note: UUID and filesystem type

Step 2 - Create the Mount Unit

sudo nano /etc/systemd/system/mnt-usb.mount

Step 3 - Create Automount Unit

sudo nano /etc/systemd/system/mnt-usb.automount

Step 4 - Enable and Start

sudo systemctl enable mnt-usb.automount
sudo systemctl start mnt-usb.automount

Step 5 - Verify and test

Check the automount is active:

Centralized rsyslog server

Thu, 04 Jun 2026 00:00:00 +0000

Objective

Build a centralized logging environment where:

SERVER receives logs from client1
SERVER receives logs from client2
Logs are stored in separate files:
- /var/log/client1.log
- /var/log/client2.log

Network Layout

Host	IP
server	192.168.10.10
client1	192.168.10.101
client2	192.168.10.102

Environment

OS: Ubuntu
Tools: rsyslog

Part 1 - Configure the rsyslog Server

Verify rsyslog

sudo systemctl status rsyslog

Enable UDP Syslog reception and restart the rsyslog service

sudo nano /etc/rsyslog.conf
sudo systemctl restart rsyslog

DNS Lab - Dnsmasq, Client resolver, Caching

Tue, 05 May 2026 00:00:00 +0000

🧪 DNS Lab

📌 Objective

Understand DNS from a systems perpective

⚙️ Environment

Virtualization: VirtualBox
OS: ( 1 DNS Server VM + 1 Client VM)

🛠️ Lab Network Topology

🧩 Phase 1 — Direct DNS (No Cache)

Client VM -> dnsmasq (192.168.10.10)

Used for:

Break #1 (Wrong DNS Server)
Break #2 (Wrong DNS Record)

🧩 Phase 2 — Direct DNS (No Cache)

Clint VM -> systemd-resolved (127.0.0.53) [CACHE] -> dnsmasq (192.168.10.10) [DNS SERVER]

Inter-Interface Packet Forwarding Failure Investigation

Fri, 01 May 2026 00:00:00 +0000

🧪 Inter-Interface Packet Forwarding Failure Investigation

📌 Objective

Diagnose why a client cannot reach the internet

⚙️ Environment

Virtualization: VirtualBox
OS: ( 1 DHCP Server VM + 1 Client VM)

🛠️ Lab Network Topology

Server (DHCP)

IP: 192.168.10.10
Interfaces:
- enp0s8 -> LAN
- enp0s3 -> NAT

Client VM

IP: 192.168.10.100
Interface: enp0s8
Gateway: 192.168.10.10

🚨 Incident Statement

Client cannot access the internet

🔍 PHASE 1 — Verify the Problem

Run on Client VM:

Process Management & Resource Control Lab

Fri, 24 Apr 2026 00:00:00 +0000

🧪 Process Management & Resource Control Lab

📌 Objective

Simulate and troubleshoot a real-world system slowdown caused by CPU saturation and memory exhaustion.

⚙️ Environment

Virtualization: VirtualBox
OS: Ubuntu Server

🛠️ Lab Setup

Step 1 - Create CPU Load Script

nano cpu_hog.sh
chmod +x cpu_hog.sh

Step 2 - Create Memory Load Script (Python)

nano mem_hog.py
chmod +x mem_hog.py

🚨 Incident Simulation

Step 1 - Check the System Load Baseline

uptime

DHCP Lab: Setup, Failure Scenarios & Debugging Workflow

Thu, 23 Apr 2026 00:00:00 +0000

🧪 DHCP Lab

📌 Objective

Understand how DHCP works in real network environment and how to debug common failure scenarios using a structured top-to-bottom approach.

⚙️ Environment

Virtualization: VirtualBox
OS: Ubuntu Server (1 DHCP Server VM & 2 Client VMs)
Network mode: Internal Network + NAT (enp0s3 ignored for DHCP lab)

🛠️ Network Setup

Interfaces

DHCP Server

enp0s8 -> 192.168.10.10/24 (Lab network)
enp0s3 -> NAT

Clients

enp0s8 -> DHCP assigned IPs
enp0s3 -> NAT (not used)

⚙️ Network Configuration (Netplan)

Both server and clients are configured using Netplan, which defines interface behavior before DHCP starts.

Basic Network Setup & Connectivity

Wed, 22 Apr 2026 00:00:00 +0000

🧪 Basic Network Setup & Connectivity Lab

📌 Objective

Understand how IP addressing, subnetting, and basic connectivity work in a controlled virtual environment.

⚙️ Environment

Virtualization: VirtualBox
OS: Ubuntu Server (2 VMs)
Network mode: Internal Network + NAT

VMs

VM	IP Address	Role
VM1	192.168.10.10/24	Client
VM2	192.168.10.20/24	Server

🛠️ Setup

Step 1 - Create Virtual Machines

Create two Linux virtual machines:

server_01
server_02

Recommended specs:

1 CPU
1-2 GB RAM
10+ GB disk

Step 2 - Configure Network

Both VMs must use the same Internal Network This ensures both machines are on the same isolated Layer 2 network.

Linux Networking

Mon, 20 Apr 2026 00:00:00 +0000

🧪 Linux Networking and Service Exposure Lab

📌 Objective

This lab simulates real-world Linux networking issues and teaches how to troubleshoot:

Service availability
Port listening
Firewall behavior (UFW)
Binding (’localhost’ vs external access)
Network-layer debugging

⚙️ Environment

OS: Ubuntu (VM + Bridged Adapter)
Service: Nginx
Tools: ss, curl, ufw, systemctl
Host machine for external testing (Powershell)

🟢 Stage 1

Verify service:

systemctl status nginx

Expected outcome: Active (running)

Check listening ports:

Log Analysis & System Debugging

Sun, 19 Apr 2026 00:00:00 +0000

🧪 Log Analysis & System Debugging Lab

📌 Objective

Read system logs like real incidents
Identify root causes
Debug common system failures

⚙️ Environment

OS: Ubuntu
Tools: journalctl, df, du, dmesg

🚨 Scenario 1: Service Crash Investigation

Step 1 - Break the service

sudo nano /etc/nginx/nginx.conf

Add invalid line:

invalid_directive;

Restart:

sudo systemctl restart nginx

Step 2 - Investigate

Check status:

systemctl status nginx

Check logs:

sudo journalctl -u nginx -n 50 --no-pager

Linux Permissions & Access Control

Sat, 18 Apr 2026 00:00:00 +0000

🧪 Linux Permission and Access Control Lab

📌 Objective

To test how Linux file permissions and access control mechanisms work in a multi-user environment.

⚙️ Environment

OS: Ubuntu
Tools: chmod, chown, ls, groups, sudo
Users: alice, bob, admin
Groups: devs, managers

🛠️ Setup

1. Create Users

sudo adduser alice
sudo adduser bob
sudo adduser admin

2. Create Groups

sudo groupadd devs
sudo groupadd managers

Assign users:

sudo usermod -aG devs alice
sudo usermod -aG managers bob
sudo usermod -aG devs admin
sudo usermod -aG managers admin

Cron Job Automation

Fri, 17 Apr 2026 00:00:00 +0000

🧪 Cron Job Automation Lab

📌 Objective

To build a scheduled automation script, observe its behavior, and learn how to debug failures.

⚙️ Part 1 - Script Setup

Create a working directory:

mkdir -p ~/cronlab
cd ~/cronlab

Create the script:

nano backup.sh

#!/bin/bash

DATE=$(date +"%Y-%m-%d_%H-%M-%S")
LOG_FILE="$HOME/cronlab/backup.log"
SOURCE="$HOME"
BACKUP_DIR="$HOME/cronlab/backups"

exec >> "$LOG_FILE" 2>&1

echo "--- RUN $DATE ---"

mkdir -p "$BACKUP_DIR"

rsync -a --exclude="cronlab" \
"$SOURCE/" "$BACKUP_DIR/home-backup-$DATE/"

echo "Backup finished"

Systemd Restart Behavior: Why Restart=on-failure Didn't Work

Tue, 14 Apr 2026 00:00:00 +0000

🧪 Systemd Service Restart Behavior Lab

📌 Objective

To test and understand how systemd handles automatic service restarts using the Restart=on-failure policy.

⚙️ Environment

OS: Ubuntu (systemd-based)
Tools: systemctl, journalctl, bash

🛠️ Setup

1. Create a test script

sudo nano /usr/local/bin/labtest.sh

#!/bin/bash
while true; do
	echo "lab service is alive: $(date)"
	sleep 10
done

Make it executable:

sudo chmod +x /usr/local/bin/labtest.sh

2. Create a system service

sudo nano /etc/systemd/system/labtest.service

[Unit]
Description=Lab test service
After=network.target

[Service]
ExecStart=/usr/local/bin/labtest.sh
Restart=on-failure
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Step 3 — Start the service

sudo systemctl daemon-reload
sudo systemctl enable labtest
sudo systemctl start labtest
systemctl status labtest

Grub2 Boot Recovery: Restoring a Server at 2AM

Thu, 09 Apr 2026 16:49:31 +0300

A step-by-step account of recovering a production server that dropped into the GRUB2 rescue shell at 2AM, resolved within SLA.

How I set up my IT journal

Thu, 09 Apr 2026 13:48:47 +0300

Why I started this blog

I am a beginner in IT and I want to document every problem I solve as I learn

What I plan to write about

Linux & Windows Troubleshooting
Network issues
Tools I discover