I left a Linux security guide half-finished for months — Copilot helped me wrap it up (and taught me something I didn't expect)

The project that sat there collecting dust

I'm a teacher at SENAI in Taguatinga, Brazil. I teach Systems Development and Fullstack. A few months ago I created the linux-security-guide — a practical Linux guide focused on security, born directly from my classroom.

The reason I started it was simple and honest: I was tired of 2-hour YouTube videos teaching things wrong, and course materials that just make students memorize commands. I had about 15 students fail job interviews because they couldn't answer "how do you secure a Linux server in practice?" — and that made me angry. So I put together everything I teach in class and use day-to-day so nobody would go through the same frustration I went through when I started.

The project grew well. Fundamentals, networking, hardening, practical labs. But at some point it stopped. It just sat there with a nice structure, half-finished modules, and labs that didn't show students what they should actually see in the terminal.

This challenge was the push I needed.

What I added with Copilot

Three fronts:

1. Lab 04 — Suspicious process detection

This lab didn't exist. I knew what I wanted: something practical, with real commands (ps, top, lsof, netstat, /proc), defensive focus, and expected output for each step. I gave Copilot the context and it put together a solid structure I wouldn't have written that quickly on my own. I still had to review every block — the technical content was correct, but some sections needed the adjustment of someone who's actually worked with this in a classroom.

2. Automated hardening script

Module 03 of the guide teaches secure SSH, auditd, suspicious crontab. But there was no script to automate all of that. Copilot generated a hardening.sh with dependency checking, automatic backup of files it modifies, logging everything to /var/log/hardening.log, and decent error handling. Good enough to show students as a production script example.

3. Expected output in existing labs

The three existing labs had the commands but didn't show what students should see after running them. That sounds like a detail, but it isn't — beginner students get stuck exactly because they don't know if what appeared in the terminal is right or wrong. I used Copilot to review each lab and add those output examples. Repetitive work I always kept putting off.

The moment I didn't expect

While working on the suspicious crontab module (03-hardening/crontab-suspeito.md), I was listing the basic commands to check scheduled tasks. Standard stuff.

Copilot suggested creating a lab where the student finds a cron job running a hidden script at /var/tmp/.cache/.systemd-fix.sh and has to trace where it came from.

I laughed out loud. Because that's exactly the kind of dirty trick an attacker would use in the real world. A name that looks legitimate, a hidden directory inside /var/tmp, a path that slips past a quick listing. I wouldn't have thought of that level of "dirty detail" on my own — at least not at that moment. It was smart because it helped me turn a boring "look at the crontab" lesson into a treasure hunt that students loved.

What I had to fix

Copilot is useful, but stubborn like a student who thinks they know everything.

In the SSH hardening lab (lab-03-ssh-hardening.md), it generated a correct command to disable password authentication — it put PasswordAuthentication no just fine. But it forgot to mention ChallengeResponseAuthentication. If a student followed only that, the server would still accept some older authentication methods. A guaranteed vulnerability.

I had to add three more configuration lines and an explicit warning in the text. Copilot helps, but it doesn't replace someone who's already been burned trying to fix a server at 3am.

What changed in the project

Before: organized structure, incomplete content, labs with no visual feedback for whoever runs them.

After: new lab on process detection, functional hardening script, and existing labs with expected output at each step.

The guide still isn't perfect. But now it's in a state where I can recommend it to a student without having to apologize for any unfinished part.

Repository

github.com/MMVonnSeek/linux-security-guide

Created and maintained by Professor Max — SENAI Taguatinga, Brazil.