assume-breach-labs - Self-contained, Docker-based labs for a first cour

项目说明

Assume Breach — Labs

> Part of the Assume-Breach series — fi security labs, two companion books, and a game. Browse them all at the series hub.

A self-contained, Docker-based lab series for a first course in **defensi
security**.

▶ Student front door: Every exercise runs in containers — no machine, no Windows image, and (with
one small exception) no dependence on external websites. The practical companion to the
*Assume Breach* book.

> Using an AI assistant? Make it a thinking partner, not an autopilot — and never run a command you
> can't explain. The series guide Learning with AI
> shows how, including how to repeat each lab until you don't need the assistant at all.

> Unit-agnostic by design. Modules are numbered by topic, not by any unit code. See
> SCHEDULE.md to map modules onto a specific teaching week / workshop schedule.

Quick start

You don't need to know Docker. Install Docker Desktop (see
modules/module-00-setup), then:

(On Windows: install Git for Windows once, then double-click start.bat.)

That "logs you in" to the lab console — the machines power on, and shell-based modules drop you
straight into a real Linux shell on the lab machine (your prompt becomes e.g. root).
Browser-based modules (05, 06, 09, 10) give a small lab> menu instead — open launches the
module's page, map shows the network, connect <host> hops onto a machine. No docker typing
either way. Follow the module's LAB-GUIDE.md. Type exit (or quit at the lab> prompt) to leave.

> First time at a Linux command line? Read LINUX-BASICS.md — the
> absolute minimum the shell-based modules assume (about twenty commands), on one page.

> Choosing a module: ./start.sh opens Module 07 by default. Pick another with
> LAB_MODULE=07 ./start.sh. Instructors can also use the Makefile directly (make m07,
> make status, make help).

Modules

| Module | Topic | Runs | Guide |
|--------|-------|------|-------|
| 00 | En setup (install Docker, smoke test) | docs | module-00-setup/README.md |
| 01 | Access control & isolation (users, groups, permissions, ACLs) | ready | module-01-access-control/LAB-GUIDE.md |
| 02 | Port scanning & enumeration (nmap) | ready | module-02-port-scanning/LAB-GUIDE.md |
| 03 | Password attacks (John the Ripper, fcrackzip) | ready | module-03-password-attacks/LAB-GUIDE.md |
| 04 | Cryptography (classic ciphers + real PGP/GnuPG) | ready | module-04-cryptography/LAB-GUIDE.md |
| 05 | Risk management (in-browser SLE/ALE calculator) | ready | module-05-risk/LAB-GUIDE.md |
| 06 | Packet capture & analysis (Wireshark-in-browser) | ready | module-06-packet-capture/LAB-GUIDE.md |
| 07 | Firewalls (real iptables/nftables) | ready | module-07-firewalls/LAB-GUIDE.md |
| 08 | Digital forensics (email headers + stylometry) | ready | module-08-forensics/LAB-GUIDE.md |
| 09 | Human factors (self-hosted quiz + broken-cert sites) | ready | module-09-human-factors/LAB-GUIDE.md |
| 10 | Web security (deliberately app: OWASP Juice Shop) | ready | module-10-web/LAB-GUIDE.md |
| 11 | VPN & tunnelling (WireGuard) | ready | module-11-.md |

Modules are independent, but some pair naturally: 06 (packet capture) ↔ 11 (VPN) — the problem
and its fix (11 encrypts the traffic 06 reads in the clear); 02 (scanning) ↔ 07 (firewalls) — the
attacker's and defender's views of the same event. Module 12 — The Long Game is the
Incident Zero print-and-play game capstone.

Going further / extension labs for ad students: GOING-FURTHER.md.

How it works

One docker-compose.yml. Every service in the whole series lives in a single compose file.

Each module is a Compose profile, so make m07 (i.e. docker compose --profile module-07 up
-d) starts *only* that module's containers. Nothing else runs.

Pull, don't build. The shared toolbox image is published to GHCR

(ghcr.io/michael-borck/assume-breach-base), so most modules start with a plain pull — no build
toolchain needed on student laptops. Custom per-module images that aren't yet on GHCR build
locally the first time.

Self-contained. External web tools in the original labs are replaced by services running

inside the compose network. The only remaining external links are two optional third-party
awareness quizzes in Module 09.

Building images locally instead of pulling

The published image is the default. To build the base image yourself (offline, or to customise
tools):

> Note for external/exFAT drives (macOS): this dri AppleDouble ._* sidecar files
> that break BuildKit's context transfer (failed to xattr … operation not permitted). If a
> local build fails that way, use the legacy builder: DOCKER_BUILDKIT=0 make build-base.

Security

These containers are deliberately and deliberately o — that is the
curriculum. Run them on a machine you control, not on anything reachable from a network you don't own.

SECURITY.md covers what is intentional (the weak hashes, the raised capabilities,
the broken certificates), what hardening is in place (localhost-only ports, network isolation for the
attacker machine, an authenticated module 06 GUI), and — stated plainly — what none of it fixes.

If you are running these for a class, set your own credentials for the module 06 browser GUI rather
than using the published defaults. Create a .env next to this file (it is git-ignored):

Data & portability

The shipped labs use no host bind mounts, so they run identically on macOS, Windows, and Linux —
including from an external/exFAT drive. Two approaches carry lab data:

Small data (hashes, wordlists, configs, small archives — under ~1 MB): **baked into the module

image**. Negligible size, pulls cleanly from GHCR, zero mount issues.

Large data (packet captures, disk/memory images, in later modules): a **named Docker

populated at runtime**, never a host bind mount. Named li Docker's own storage, so
they sidestep host file-sharing quirks on every OS.

> De on an external/exFAT dri)? Docker Desktop's file-sharing can't bind-mount
> such paths and BuildKit trips on macOS ._* sidecar files. This only affects *building here* — not
> students, who pull prebuilt images. Use DOCKER_BUILDKIT=0 for local builds if one fails.

Running where you can't install Docker

Most people run the labs locally (see above). For locked-down lab PCs, Chromebooks, or anywhere Docker
Desktop can't be installed, there are two online routes — in order of preference:

1. A managed Linux + Docker desktop (recommended). If your institution offers a Docker-capable
Linux a remote-desktop / , run the labs there exactly as you would locally —
download the ZIP and run ./start.sh. No personal accounts, IT-supported. Ask your unit coordinator
whether this is a.

2. GitHub Codespaces (personal fallback). Opens the repo in a cloud VS Code in your browser and
runs the same ./start.sh, nothing installed on your machine. Open the repo on GitHub →
Code ▸ Codespaces ▸ Create codespace, then run ./start.sh. Know the trade-offs:
- Needs a GitHub account (more free hours via GitHub Education).
- You work inside VS Code in the browser, not the clean console front door.
- The browser modules (5, 6, 9) open via a forwarded URL Codespaces provides, not localhost —
the console detects Codespaces and prints the right link.
- Module 9's broken-certificate sites only work locally — the Codespaces proxy presents its own
valid certificate, which masks the broken ones the exercise relies on. The quiz half works online.

Licence

MIT — see LICENSE. Teaching material is free to reuse and adapt.

项目信息

开发语言：Shell

Star 数：2

技术要点

该项目属于防护思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Self-contained, Docker-based labs for a first course in defensive information security. Unit-agnostic; immersive lab console hides Docker.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。