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

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.
pwd
and ls
Terminal Verification – 
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.
diagnostico.sh
Script
Designing the 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 tolistado.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

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.