Sysadmin on My IT Journal

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:

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.