Preface

This book is for students learning Linux and shell scripting as foundations for cybersecurity. Cybersecurity is the book’s central application: the chapters show how to inspect systems, reason about permissions, process logs, automate audits, and support authorized triage and incident-response workflows. Bash provides the practical language for exploring servers, files, processes, networks, and repeatable technical workflows.

The book assumes no prior Linux or programming experience. You work in a terminal from the first chapter, and across the book you build a host audit toolkit: a set of Bash scripts that inspect a Linux system, check its configuration against safe defaults, and write a report someone else can read and verify.

Why Linux and Bash

Most of the systems that cybersecurity protects run Linux or another Unix-like operating system: web servers, cloud instances, containers, network appliances, and embedded devices. To defend them, you need to know how Linux works, not only which commands to type. Accounts and groups decide who can do what. Permissions decide which files are exposed. Processes and services show what is running and what is listening. Logs record what happened. A defender who understands these parts knows what a healthy system looks like, and so can recognize one that has been misconfigured or compromised.

Linux is also where much of the security work itself happens. Security distributions such as Kali Linux and Security Onion are built on Linux, and network monitoring tools such as Zeek and Suricata run on it. Analysts, incident responders, and penetration testers spend much of their day at a Linux command line, often on a remote machine with no graphical interface at all.

Bash is the default shell on most Linux distributions, so it is the language you use to talk to all of these systems. The commands and scripts you learn here run on the machines you will be asked to inspect.

Scripting turns one-time commands into repeatable procedures. Checking file permissions by hand works on one server; a loop checks fifty. Repeatability matters in security for a second reason: a script records exactly what was checked and how, so another analyst can rerun it, review it, and trust the result. Logs, reports, and evidence hashes come out the same way every time.

Reading Bash matters as much as writing it. Installers, scheduled jobs, system startup, build pipelines, and a good deal of attacker tooling are shell scripts. When an incident responder finds an unfamiliar script in /tmp or an odd entry in a crontab, reading it correctly is the first step, and that depends on the details this book spends time on: quoting, expansion, redirection, and exit status.

Bash also has limits. Large programs, complex data structures, and heavy data analysis belong in a language such as Python, and the book points out when a task crosses that line. Bash’s strength is joining the tools already on the system, such as find, grep, awk, ssh, and systemctl, into a working procedure.

Linux and Bash in a Cybersecurity Curriculum

The book is written for a Linux and scripting course early in a cybersecurity program, before or alongside courses in networking, security operations, digital forensics, and penetration testing. Those courses assume students can move around a Linux system, read logs, and automate a check. This book teaches those skills directly instead of leaving students to pick them up along the way.

Security is the application throughout the book, not a final unit. Each chapter carries a security thread: hidden files and evidence-preserving copies with filesystem management, risky permissions and least privilege with access control, unquoted variables as injection risks with quoting, failed login attempts with text processing, and unusual processes with system monitoring. Chapters 19 and 20 then combine these patterns into audit and incident-response scripts.

The work is defensive and authorized. Chapter 1 sets the rule followed everywhere in the book: you inspect and automate only systems you own or have explicit permission to use, normally your own lab virtual machine.

The topics align with the Basic Scripting and Programming and the Operating Systems Concepts knowledge units of the National Centers of Academic Excellence in Cyber Defense (CAE-CD) program, so the book can support those units in a designated program.

For Instructors

The book has twenty chapters in five parts. Part I (Linux Command-Line Foundations) covers the terminal, the filesystem, access control, and streams. Part II (Bash Programming Foundations) turns command-line users into script authors. Part III (Streams, Logs, and Robust Automation) covers redirection, text processing, logs and evidence files, and defensive scripting. Part IV (Linux Operations and Remote Administration) covers processes, services, scheduling, remote access, and backups. Part V (Cybersecurity Automation) applies all of it to audit and incident response. Chapter Topics lists what each chapter covers.

Each chapter has a landing page, content sections sized for class meetings, and four assignments: Preview, Lab, Homework, and Project. The project steps grow the host audit toolkit chapter by chapter, and Appendix G organizes the capstone. A course with less time can use Parts I to III as a Linux and Bash foundation and then select from Parts IV and V.

The assignments assume each student works on their own Linux virtual machine, with full control of accounts, files, permissions, services, and remote access. Appendix H covers VM onboarding. This hands-on, systems-first model grows out of the earlier bashnet course materials, and it owes its design to the original assignments of Larry Dennis.

Examples target Bash on Linux. Where macOS differs, for example its older Bash 3.2 without associative arrays, the text says so, and Appendix C covers POSIX portability in detail.

Videos throughout this book are embedded via YouTube’s official player and remain the property of their original creators. No ownership or affiliation is claimed. Embedded videos may become unavailable if creators remove them or disable embedding. Rightsholders with concerns may contact support@thinkpress.org.