Lion Cipher Lab

Exploit an exposed rsync daemon in your own lab, then restrict it

• Penetration Testing / Red Team
• Intermediate
• ~45 min
• Free · no account required

Why it matters

Almost everyone who has ever copied files between two machines has used rsync, and almost all of them have only ever used it the safe way — tunnelled inside SSH, where it inherits SSH's authentication and encryption and there is nothing to attack. What far fewer people know is that rsync has an entirely separate second personality: a standalone background service, the rsync DAEMON, that listens on its own TCP port (873 by default) and publishes named shares it calls 'modules'. That daemon was designed in an era of trusted networks, and for most of its life a module could be — and in countless…

What you'll learn

• distinguishing the two completely different ways rsync moves files — rsync over SSH (the safe, common mode) and the standalone rsync DAEMON on TCP 873 (the mode with anonymous 'modules') — and why only the second is the exposure this lab is about
• standing up a self-contained lab entirely on loopback: a deliberately weak rsync daemon on a high port, with its own config, run as your normal user, touching nothing but your own machine
• enumerating an rsync daemon the way an assessor would: listing its modules with `rsync rsync://host/`, listing a module's files, and recognising an anonymous (no auth-users) module on sight
• confirming the two halves of the finding — anonymous READ (pulling files the module exposes) and anonymous WRITE (uploading a file into a writable module) — and explaining accurately why a writable anonymous module is a foothold in the real world
• applying the real fix: `auth users` plus a `secrets file` locked to 0600, `read only = yes`, `hosts allow`, `use chroot = yes`, and an unprivileged `uid`/`gid` — and understanding why rsync itself refuses a world-readable secrets file
• measuring before and after with the identical probe: anonymous list/pull/write all succeed before the fix and are refused after it, while an authenticated client still works read-only
• judgment: why a tool that is safe in its everyday mode can be dangerous in a mode you forgot it had, and why the finding is always the human who enabled the anonymous daemon, never rsync itself

Steps in this lab

1. Two different rsyncs: the safe one everyone uses, and the one this lab is about
2. Build the self-contained lab: a throwaway directory and some bait files
3. Write a deliberately weak daemon config — and see what makes it weak
4. Start the weak daemon on loopback
5. Enumerate the daemon the way an assessor would
6. Confirm the READ finding: pull the files anonymously
7. Confirm the WRITE finding — and why it is the dangerous half
8. Write the fixed config — auth, read-only, chroot, host allow, low privilege
9. Measure the fix: the same anonymous probes are now refused
10. When this bites, when it does not, and how a pro avoids it entirely

Open the full interactive lab →