# Your Computer Is Talking. Learn to Read the Signs.

A computer is rarely doing nothing.

Even when the screen looks quiet, processes are running.

Services are listening.

Users are authenticating.

Applications are opening files.

Network connections are being created.

Logs are recording events.

If you want to learn defensive cybersecurity, one of the most valuable things you can do is learn how to observe all of this.

Before asking:

> **"Has this system been hacked?"**

learn to ask:

> **"What is this system doing?"**

* * *

## Start With Processes

A process is a running instance of a program.

On Linux, one of the simplest ways to see running processes is:

```bash
ps aux
```

You will probably see far more output than expected.

That is good.

Do not try to memorize everything.

Instead, begin asking questions:

*   What user owns the process?
    
*   What command started it?
    
*   How much CPU or memory is it using?
    
*   Do I recognize it?
    
*   Is it expected on this machine?
    

For a more interactive view, many systems also provide:

```bash
top
```

Processes become much easier to understand when you observe them regularly rather than only when something is wrong.

* * *

## Look at Listening Services

Next, ask what your computer is waiting for.

On Linux:

```bash
ss -tulpn
```

Depending on your permissions and Linux distribution, the amount of process information displayed may vary.

You might see services listening on addresses such as:

```text
127.0.0.1:631
0.0.0.0:22
```

Now you have questions.

What service owns port 22?

SSH commonly uses TCP port 22.

Should SSH be running?

Should it be reachable from every interface?

Is that intentional?

This is how networking knowledge becomes security knowledge.

* * *

## Check Services

Linux systems commonly use `systemd` to manage services.

Try:

```bash
systemctl --type=service --state=running
```

You might see services for:

*   Networking
    
*   SSH
    
*   Logging
    
*   Scheduled tasks
    
*   Updates
    
*   Other system functions
    

Pick one and investigate it.

For example:

```bash
systemctl status ssh
```

Now you can connect a process to a service and eventually connect that service to network activity and logs.

That relationship matters.

* * *

## Look at Network Connections

Listening ports tell you what is waiting for connections.

Active connections tell you something else.

Try:

```bash
ss -tun
```

You may see connections to local or remote systems.

Again, do not immediately label unfamiliar activity as malicious.

Ask:

*   Which application created the connection?
    
*   Where is it going?
    
*   Is the destination expected?
    
*   How long has the connection existed?
    
*   Is the traffic related to something I just did?
    

Defensive analysis is built on questions like these.

* * *

## Who Is Logged In?

Try:

```bash
who
```

And:

```bash
last
```

These commands can help you inspect current or historical login information available on the system.

Now create an experiment.

SSH into your lab server.

Run:

```bash
who
```

Log out.

Then run:

```bash
last
```

You are no longer just reading cybersecurity theory.

You are observing evidence created by your own actions.

* * *

## Read the Logs

For systems using the `systemd` journal:

```bash
journalctl
```

There may be a lot of information.

That is normal.

You can narrow it down.

For example:

```bash
journalctl -u ssh
```

Or, depending on the distribution and service name:

```bash
journalctl -u sshd
```

Now perform an SSH login.

Check the logs again.

Try an incorrect password in a safe lab environment.

Then check again.

What changed?

This is the beginning of log analysis.

NIST's Cybersecurity Framework 2.0 places detection and analysis of possible cybersecurity attacks and compromises within the **Detect** function.

* * *

## Establish a Baseline

You will hear the word **baseline** frequently in security.

For beginners, think of a baseline as understanding what is normal well enough that deviations become noticeable.

Imagine a server that normally has:

```text
SSH
DNS client activity
Software update traffic
No public web service
```

One day you discover:

```text
New service listening on port 8080
Unknown process
Unexpected external connection
```

Does that prove compromise?

No.

Maybe you installed something and forgot.

Maybe another administrator made a legitimate change.

Maybe a package started a new service.

Or maybe it deserves investigation.

The difference is that you noticed it because you understood what the machine normally looked like.

* * *

## Do Not Turn "Different" Into "Malicious"

This is an important habit.

Security tools often highlight unusual behavior.

But unusual does not automatically mean harmful.

A new process could be:

*   A legitimate update
    
*   New software
    
*   Administrative activity
    
*   A scheduled job
    
*   A configuration change
    
*   Something malicious
    

Your job is to gather more information.

Security analysis is not:

```text
Different = Attack
```

It is:

```text
Observation
     ↓
Context
     ↓
Evidence
     ↓
Assessment
```

That difference matters.

* * *

## Build a Five-Minute Observation Routine

Open your Ubuntu home-lab VM.

Run:

```bash
who
```

Then:

```bash
ps aux
```

Then:

```bash
ss -tulpn
```

Then:

```bash
systemctl --type=service --state=running
```

Then:

```bash
journalctl -n 30
```

Do this periodically.

You will slowly stop seeing random terminal output.

You will begin seeing a system.

That shift is important.

* * *

## What Are You Actually Learning?

At first, these commands may feel disconnected.

But they start fitting together.

For example:

```text
User logs in through SSH
        ↓
ss shows the network connection
        ↓
sshd handles the session
        ↓
A process exists for the connection
        ↓
Logs record the authentication event
```

Now you are beginning to understand how one event appears across multiple parts of a system.

That is an important defensive-security skill.

When something suspicious happens, you rarely want to rely on only one source of evidence.

You want to correlate what you see.

* * *

## Ask Better Questions

When you find something unfamiliar, avoid jumping immediately to:

> **"Is this malware?"**

Instead, ask:

```text
What is it?

Who started it?

When did it start?

What is it communicating with?

Is it expected?

What logs mention it?

What changed before it appeared?
```

These questions move you from guessing toward investigation.

* * *

## Key Takeaway

Your computer constantly produces information about what it is doing.

**Processes** tell you what is running.

**Services** tell you what capabilities are active.

**Network connections** tell you who the system is communicating with.

**Login records** tell you who accessed it.

**Logs** tell you what happened.

Before learning how to detect something abnormal, learn what normal looks like.

That is one of the foundations of defensive security.

* * *

## Verified References

*   **NIST Cybersecurity Framework 2.0**  
    The CSF 2.0 **Detect** function focuses on finding and analyzing possible cybersecurity attacks and compromises.  
    https://www.nist.gov/cyberframework
    
*   **NIST Cybersecurity Framework 2.0 Core**  
    Provides the categories and subcategories associated with the CSF functions, including detection and monitoring activities.  
    https://www.nist.gov/cyberframework/getting-started/online-learning/components-framework
    
*   **NIST Log Management Guidance**  
    NIST provides guidance related to log management and the collection, analysis, and retention of computer security log data.  
    https://csrc.nist.gov/publications/detail/sp/800-92/final
    

* * *

*This article is intended for educational purposes. Commands and exercises should only be performed on systems you own or are explicitly authorized to administer.*