Programming and Scripting for Cybersecurity: Part 2 – Building a Secure Bash Lab

Published on
4 mins read
--- views

Introduction

Continuing our journey into security-focused scripting, Part 2 moves from theory to hands-on practice. You will select a Linux distribution, validate your lab setup, and build a short Bash script that bootstraps a working directory for future automation exercises. Each step reinforces why environment choices, permissions, and path handling matter when security teams scale their tooling.

Learning Objectives

  • Compare common security-oriented Linux distributions and justify a selection for lab work.
  • Verify a terminal session with pwd/ls to confirm directory awareness and shell readiness.
  • Implement a Bash script that creates structured workspaces, logs activity, and enforces restrictive permissions.
  • Explain the trade-offs between relative and absolute paths in administrative automation.

Scenario: Building Dharma’s Automation Lab

At Dharma, the automation squad is preparing a sandbox where analysts can prototype scripts before pushing them to production servers. Your assignment is to establish the baseline: choose the operating system image, document the initial filesystem view, and provide a reusable script that every teammate can run to replicate the directory structure. The screenshots below capture the selected distribution and the confirmation of the shell environment.

Selected Distribution

HW 2

The lab runs on Ubuntu 22.04 LTS (WSL2 in this instance). Ubuntu strikes a balance between stability, extensive package support, and compatibility with security tooling. Its LTS cadence promises regular security updates without disruptive changes, making it a reliable foundation for automation drills.

Terminal Verification – pwd and ls

HW 2

Capturing the prompt, along with pwd and ls, documents the working directory (/home/dharma) and confirms that the expected files (diagnostico.sh, among others) are accessible. This evidence is vital when teammates replicate the workflow or audit your setup.

Designing the diagnostico.sh Script

The onboarding kit includes a utility script that prepares a seguridad workspace, records basic activity, and enumerates the contents of the directory for quick verification. Below is the annotated version you will maintain in version control.

#!/usr/bin/env bash
set -euo pipefail

BASE_DIR="$HOME/seguridad"

# Create the working directory if it is missing.
mkdir -p "$BASE_DIR"

# Ensure the activity log exists and is empty for this run.
: > "$BASE_DIR/registro.log"

# Produce a current listing from inside the workspace.
cd "$BASE_DIR"
ls -la > listado.txt

# Append a timestamp entry so we know when the script was executed.
echo "Execution: $(date)" >> registro.log

echo "Done. Files generated at: $BASE_DIR"

Why These Choices Matter

  • Absolute base path ($HOME/seguridad). Anchoring the workspace under the operator’s home directory avoids surprises caused by different invocation points and keeps permissions manageable.
  • set -euo pipefail. The script fails fast on undefined variables or command errors, preventing partial state that could confuse future runs.
  • Idempotent directory and log creation. Using mkdir -p and the : truncation operator makes the script safe to run multiple times without stale data.
  • Listing capture. Saving ls -la output to listado.txt creates an artefact that auditors can review without rerunning the script.
  • Timestamp logging. registro.log doubles as a quick audit trail, demonstrating when the workspace was initialized or refreshed.
  • Permissions. After downloading or cloning the script, run chmod 700 diagnostico.sh. Restricting execution to the owner protects against tampering and accidental invocation by other users on shared hosts.

Execution Evidence

HW 3

The final screenshot captures the successful execution and the resulting files, satisfying the deliverable for the lab notebook.

Reflection: Paths and Portability

In this exercise, absolute paths offer predictability; every run targets $HOME/seguridad regardless of the caller’s current directory. Relative paths could be useful inside the workspace—for example, referencing ./listado.txt once the script has changed directories. Mixing both approaches thoughtfully keeps the script portable while ensuring critical operations always resolve correctly.

Next Steps

With the lab scaffolded, you are ready to explore richer automation tasks: integrating logging frameworks, parsing arguments, and validating system state before and after each action. These enhancements build directly on the structure established here, reinforcing disciplined scripting habits for cybersecurity operations.