Cybersecurity Learning Roadmap: From Linux and Networks to Evidence

A scanner reports an open port. You have found a service accepting connections from that test location. You have not yet established what the application does, whether its exposure is intended, or whether it has a vulnerability.

A useful beginner cybersecurity roadmap moves from Linux state to network observations and then to a finding whose claims match the evidence. Learn to connect those layers before expanding the number of tools you run.

The first project below examines a development service you start yourself on loopback. It is a small investigation exercise, not a penetration test or a complete preparation for a security role. Use only your own test environment or an explicitly authorized lab target.

Begin with a question small enough to answer

Use this question: “Does my local test service accept a connection and return the file I expect?” Record the target as 127.0.0.1, the protocol as TCP/HTTP, and the chosen port as 8081.

That scope matters technically. Loopback is local to the machine or network namespace where a command runs. A test from your laptop does not inspect a remote lab’s loopback listener. Run the server and client commands below in the same environment.

Keep a record with separate fields for observation, interpretation, and unknowns. For example, a returned marker is an observation. Attributing it to your intended file requires connecting the response to the server’s configured directory. Whether another network can reach the service remains unknown from a local request alone.

Build the Linux foundation around the target

Use Python 3.7 or later and curl, with two terminals. In terminal one:

mkdir security-service-demo
cd security-service-demo
mkdir site
printf 'owned-test-service\n' > site/index.html
python3 -m http.server 8081 --bind 127.0.0.1 --directory site

Choose another unused directory or port if necessary. Leave the server in the foreground. The Python server documentation describes these directory and bind options and warns against production use. This target is deliberately limited to a dedicated test directory and loopback.

Before introducing a scanner, identify the file, process, and listener. On Linux, use:

id
ps -eo user,pid,args
ss -ltn

Find the Python command you started and the 127.0.0.1:8081 listener. The process list can contain unrelated applications; inspect it locally rather than publishing the full output. These commands are inspection examples for a Linux environment with procps and iproute2, not universal commands for every terminal implementation.

id describes your current identity. The process listing helps determine the service identity. ss shows a socket observation; its manual documents the listening, TCP, and numeric-output options. You still need an application request to learn what the service returns.

If identifying the process or reading its file mode is difficult, pause here for Linux practice. The permissions walkthrough and LabEx Linux path provide starting points. More scan options will not fill a missing understanding of users or paths.

Make the application request first

In terminal two:

curl --noproxy '*' -i http://127.0.0.1:8081/index.html
curl --noproxy '*' -i http://127.0.0.1:8081/missing.txt

The first request should return the marker with a successful response. The second should return a not-found response because you did not create missing.txt. Look at terminal one for the corresponding request records.

Do not classify a 404 as a failed network connection. Receiving an HTTP response means a server answered at the application layer. Conversely, a TCP connection alone does not establish that the requested file exists.

Keep the request path, status, and observation time in your notes. If a record is absent, first check where this server writes its logs and whether you are inspecting the right process. Absence from one log is not proof that no connection occurred anywhere.

Add one port scan for a different observation

If Nmap is installed, run a TCP connect scan against only the owned loopback port:

nmap -sT -p 8081 127.0.0.1

The Nmap scan-technique reference explains that -sT uses the operating system’s connect call. This exercise does not require raw-packet scanning, operating-system fingerprinting, or scanning a range of hosts.

With the server running, expect the selected TCP port to appear open. Treat any displayed service name cautiously: a conventional name associated with a port number is not proof of the actual program. You already have stronger local context from the process command and HTTP response.

Stop your foreground server with Ctrl+C in terminal one, then repeat the same scan. With no other listener or filtering affecting the test, the port should appear closed. If it does not, inspect the local state before drawing a conclusion; another process may have taken the port.

Nmap’s port-state reference distinguishes closed from filtered and explains that states represent the scanner’s viewpoint. An open port is not a vulnerability finding. A closed port after you stop a service is not a security assessment of the machine.

Write the smallest supported finding

Use your own observed values rather than copying an expected result as if you measured it. A completed note should separate these parts:

Field	What belongs there
Scope	Owned loopback service, selected port, client location, time
Observation	Actual listener, request status, response marker, and optional scan state
Interpretation	How the observations relate to the configured test service
Limit	No remote-reachability, authentication, or vulnerability assessment was performed
Verification	The result after stopping or restarting that same service

This example may produce no security defect. That is acceptable. The skill being practiced is determining what the evidence supports, including when a dramatic conclusion is unwarranted.

When you do encounter an unexpected exposure in an authorized exercise, explain the condition that makes it relevant: intended audience, observed audience, and the configuration that differs. Then verify a correction from the relevant client position. “Close the port” is incomplete when legitimate clients still need the service.

Branch according to the evidence you need next

If the gap is understanding traffic, study protocols and packet analysis. Wireshark’s user guide introduction describes packet capture and inspection. Start with traffic from a controlled exercise, learn the request/response relationship, and distinguish what is visible from what encryption hides. A packet viewer cannot supply evidence that was never captured.

If the gap is understanding a host change, study users, file ownership, processes, service logs, and timestamps. Practice reconstructing a small, known change before attempting a complex incident timeline. A checksum comparison can establish that bytes differ; it does not identify who changed them or why.

If the gap is web behavior, add HTTP methods, status codes, sessions, and authentication in a dedicated training application. Learn its intended behavior before treating a surprising response as an exploit.

The LabEx cybersecurity path, checked on September 14, 2026, includes courses such as Nmap for Beginners, Wireshark for Beginners, and Host-Based Security & Auditing. Choose a course whose evidence type matches your gap. This route is not a promise of job or certification readiness, and collecting course completions does not replace explaining your observations.

Leave the target and the record in a known state

Stop the foreground test server if it is still running. From security-service-demo, remove only the file and empty directory you created:

rm site/index.html
rmdir site

Keep your investigation note separately. For the next exercise, change one controlled condition and write a prediction before running a tool. Then explain the difference between the prediction and the observation without claiming more than the test can establish.

References

• Python HTTP server — the local development target and its limitations.
• ss manual — Linux socket inspection.
• Nmap scan techniques — TCP connect scanning.
• Nmap port states — scope of open, closed, and filtered observations.
• Wireshark user guide — a next step for packet evidence.