Getting Started

Explore The System

A guided first tour: who you are, what is running, and what is listening.

The first thing any attacker does after landing on a host, and the first thing any defender should do when they inherit one, is orient: who am I, what is running, and what can the outside world reach? These three questions map directly to the account, process, and network layers. Answering them fast, with tools that are on every Linux box, is a core skill. This page walks the tour on your lab VM so the commands become reflex.

Roll your lab back to the clean snapshot from Local Setup before you start, so what you see matches the output here.

Identity: Who Am I?

Every command you run inherits your identity: a UID, a primary group, and a set of supplementary groups. Privilege decisions flow from these, so knowing them is step one.

whoami
id
groups

Expected output:

ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),27(sudo),100(users),...
whoami is ubuntu

The id line is the one to read carefully. uid=1000 means you are a normal user, not root (which would be uid=0). The groups= list is where privilege often hides: membership in sudo means you can escalate to root, and membership in adm grants access to system logs. When auditing an account, the group list tells you what it can do without ever running a single privileged command. The interplay of users, groups, and UIDs is covered in depth in Users & Groups.

Processes And Services: What Is Running?

Each running process has an owner. A process running as root that gets compromised gives the attacker root, so the count of root-owned processes is a rough measure of attack surface. List processes with their user and command:

ps -eo user,pid,comm --sort=user | head -n 15

Expected output:

USER       PID COMMAND
message+   612 dbus-daemon
root         1 systemd
root       412 systemd-journald
root       501 sshd
root       688 cron
systemd+   440 systemd-resolved
ubuntu     901 bash
...

On a systemd host, most of those long-running processes are services. systemctl lets you see them as managed units, which is more useful than raw process lists because it tells you what is enabled to start at boot.

systemctl list-units --type=service --state=running

Expected output:

UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
cron.service             loaded active running Regular background program...
dbus.service             loaded active running D-Bus System Message Bus
ssh.service              loaded active running OpenBSD Secure Shell server
systemd-journald.service loaded active running Journal Service
systemd-resolved.service loaded active running Network Name Resolution
...

The lesson: everything running is something that can go wrong. A hardened host runs as few services as possible, each as an unprivileged user. Ask of every entry “does this need to run, and does it need to run as root?”

Network Exposure: What Is Listening?

A service only matters to a remote attacker if a port is listening and reachable. ss (the modern replacement for netstat) shows listening sockets. The flags are worth memorizing: -l listening, -t TCP, -u UDP, -n numeric ports, -p owning process.

sudo ss -tulnp

Expected output:

Netid State  Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*         users:(("sshd",pid=501,fd=3))
tcp   LISTEN 127.0.0.53:53       0.0.0.0:*         users:(("systemd-resolve",pid=440))
udp   UNCONN 127.0.0.53:53       0.0.0.0:*         users:(("systemd-resolve",pid=440))

Read the Local Address column closely. 0.0.0.0:22 means SSH accepts connections from any network interface, so it is exposed to anything that can route to the host. 127.0.0.53:53 is bound to loopback only, so the DNS resolver is reachable from this machine alone and not from the network. That distinction, world-facing versus loopback-only, is the single most important thing to know about any listening service.

Putting It Together

You now have a snapshot of the host across three layers: you are the unprivileged ubuntu user with sudo rights, a handful of services run (mostly as root via systemd), and only SSH is exposed to the network. That is a small, sane attack surface, which is exactly why a fresh Ubuntu install is a reasonable baseline. As you add software in later sections, repeat this tour and watch the surface grow. When you are ready to confirm the kernel and tooling underneath, continue to Verify The Environment.

Practical Guidance

  1. Run id first on any unfamiliar host; the group list tells you your real capabilities before you touch anything.
  2. Treat every root-owned process as a question, not a given: does it need root, and does it need to run at all?
  3. Prefer systemctl list-units over raw ps when you want to know what is enabled and managed rather than just present.
  4. On any host, run ss -tulnp and flag every socket bound to 0.0.0.0; those are your network-facing risks.
  5. Re-run this three-part tour after installing anything, so you notice new users, services, and ports as they appear.