Cybersecurity Fundamentals

The Linux operating system exposes much more of the underlying system than the closed alternatives. Process listings, network sockets, loaded modules, kernel events, traffic flows — it's all accessible with standard tools. That visibility is the foundation for this guide on learning cybersecurity. Even beyond the cybersecurity focus, the techniques here are universally helpful in understanding what's running on your machine, what it's communicating with, and how to understand these processes.

Why Cybersecurity Matters Now

Three shifts are making this more urgent than ever before:

• Autonomous agents — AI systems that execute commands, access files, and make decisions without direct supervision. An agent with internet access and a payment method is already making decisions you'd formerly make yourself.
• Quantum computing — Encryption that protects banking, messaging, and authentication could become breakable within the next year or two. The timeline isn't clear, but the certainty is.
• Everything connected — From thermostats to tractors, more devices exist outside traditional security perimeters than inside them.

The thread connecting these: systems are doing more, faster, with less human oversight. Understanding what's running on your devices isn't optional — it's the foundation of rational security.

Investigation

Investigation follows a specific order — from most volatile to most persistent. Memory evidence is gone on reboot. Log evidence persists but can rotate. Network state shows what's exposed. Traffic shows what's active. Vulnerability assessment looks at the software itself. Each phase builds on the last.

Live analysis captures what's running at this moment. Reboot the machine and this evidence is gone. This is where attackers establish persistent footholds, and where finding them is most difficult because they're mixed in with legitimate processes.

ps aux --sort=-%cpu

ps aux lists every running process. Sorting by CPU usage puts active processes first — anything consuming resources unexpectedly warrants investigation.

What to look for: processes running from unusual paths (/tmp, /dev/shm), processes with names that mimic system tools but run from unexpected locations, unexpected parent-child relationships, or suspiciously high resource usage for processes that should be idle.

# Listening sockets — what's waiting for connections
ss -tulpn

# Established connections — what's actively communicating
ss -tupn

ss (socket status) replaced the deprecated netstat. Key flags: -t TCP, -u UDP, -l listening, -p show process, -n don't resolve names (faster and avoids DNS traffic).

What to look for: listening ports you didn't explicitly open, established connections to unfamiliar IPs on non-standard ports, and services bound to 0.0.0.0 (all interfaces) that should only be on 127.0.0.1 (loopback only).

Persistence Mechanisms

These are the methods that let code survive a reboot. Attackers prioritize these because they provide reliable re-entry even if the initial access is detected.

# Cron jobs — your own
crontab -l

# Cron jobs — system-wide
cat /etc/crontab

# Systemd services
systemctl list-units --type=service --state=running

# Shell init files — compare against known-good backup
diff ~/.bashrc ~/.bashrc.bak

# Autostart entries
ls ~/.config/autostart/

find / -perm -4000 -type f 2>/dev/null | sort

SUID (Set User ID) binaries run with the file owner's privileges regardless of who executes them. /usr/bin/sudo is SUID root — that's what allows privilege escalation. An attacker who adds a SUID binary or modifies an existing one has a permanent escalation path.

# Find binaries newer than /etc/passwd (system install date)
find /usr/bin /usr/sbin /usr/local/bin -newer /etc/passwd -ls 2>/dev/null

The /etc/passwd timestamp serves as a reference point — it was last modified when the system was installed or when users were added. Any system binary newer than that should be traceable to a known package update.

Log Analysis

Logs tell you what happened across time. They reveal sequences, patterns, and timing that only become meaningful in retrospect. A single failed login is noise. Forty failures in sixty seconds suggests a brute-force campaign. The difference is only visible in logs.

# Count entries in the past 24 hours
journalctl --since "24 hours ago" --no-pager | wc -l

A healthy desktop generates 2,000-8,000 entries per day. Significantly higher volume suggests a service in an error loop, repeated crashes, or something generating unusual activity.

# Filter by severity: error, critical, alert, emergency
journalctl -p err --since "24 hours ago" --no-pager

The -p flag filters by syslog priority. On a healthy system, these should be sparse and recognizable.

# SSH connection attempts
grep "Failed password\|Invalid user\|Accepted\|Disconnected" /var/log/auth.log | tail -50

# Or via journalctl
journalctl -u ssh --since "24 hours ago" --no-pager

On internet-connected machines, you'll see automated scanners trying common usernames. The distinction: invalid user (username doesn't exist) means the attacker is prospecting; failed password (valid username, wrong password) means they already know an account name.

grep "sudo:" /var/log/auth.log | tail -30

Every sudo invocation is logged with full context: user, terminal, working directory, target user, and exact command. An entry like COMMAND=/bin/bash that you didn't initiate is a high-priority finding — lateral movement scripts frequently use sudo bash to obtain an interactive root shell.

Linux Audit Framework (auditd) logs file access and system calls at the kernel level — events that journald and syslog don't capture by default. Without it, there's no record of which processes read which files. Adding file watches for sensitive paths is straightforward:

# Watch the bash history file for reads
sudo auditctl -w /home/*/.bash_history -p r -k history_read

# Make it persistent
echo "-w /home/*/.bash_history -p r -k history_read" | \
  sudo tee -a /etc/audit/rules.d/local.rules

Attack Surface Mapping

Attack surface mapping answers: what's reachable on this machine, and what's running when someone connects? This is what an attacker on the network would build during reconnaissance — before touching a single file.

sudo nmap -sV -p- 127.0.0.1

Three flags cover the essentials:

• -sV — service version detection; identifies exact software and version
• -p- — scan all 65,535 ports, not just defaults
• sudo — required for SYN scan (faster, less likely to be logged)

# Find your LAN IP first
ip addr show | grep "inet " | grep -v 127.0.0.1

# Scan localhost — bypasses most firewalls
sudo nmap -sV -p- 127.0.0.1

# Scan your LAN IP — what the network can reach
sudo nmap -sV -p- 10.0.0.10

The difference between localhost and LAN IP scan results is your firewall's contribution. If they're identical, the firewall isn't filtering incoming traffic.

sudo nmap -sU --top-ports 20 127.0.0.1

UDP is slower but reveals DNS (port 53), NTP (port 123), SNMP (port 161), and mDNS (port 5353). These are commonly left open and frequently unpatched.

sudo ufw status verbose
sudo iptables -L -n -v

Before scanning, verify what's actually doing the filtering. Many systems run firewalls that aren't enabled, or have rules that don't accomplish what the user intended.

Traffic Capture

Traffic capture is where static analysis becomes dynamic. You're no longer asking what could communicate — you're watching what actually does. Sixty seconds during normal use contains DNS queries, keep-alives, update checks, and background beacons.

# List interfaces
ip link show

# Or ask tcpdump
sudo tcpdump -D

On WiFi, it's typically wlan0. On ethernet, eth0 or enp3s0. Capture on the interface with active traffic.

sudo tcpdump -i wlan0 -n -c 50

-n disables hostname resolution (critical — DNS lookups add latency and noise). -c 50 captures 50 packets then stops. Verify you're on the right interface before running a longer capture.

sudo tcpdump -i wlan0 -n port 53

DNS queries reveal every domain a process communicates with — readable hostnames rather than raw IPs. This is the most informative protocol to isolate first.

What to look for: unfamiliar domains, unusual patterns (random subdomains suggest DNS tunneling), high frequency to single domains (beaconing), and direct IP queries (malware bypassing DNS entirely).

sudo timeout 60 tcpdump -i wlan0 -n -w capture.pcap
echo "Captured $(du -h capture.pcap | cut -f1)"

-w writes to a pcap file for later analysis. timeout 60 captures exactly one minute, then stops.

# Requires tshark (part of Wireshark)
sudo apt install tshark

# Conversation summary — biggest talkers by bytes
tshark -r capture.pcap -q -z conv,ip | sort -k 3 -rn | head -20

The conversation summary immediately surfaces destinations receiving unexpected data volume — the anomaly you're looking for.

# Extract unique external IPs, exclude LAN
tcpdump -r capture.pcap -n | \
  awk '{print $5}' | \
  grep -v "^10\.\|^192\.168\.\|^127\." | \
  sed 's/\.[0-9]*$//' | sort | uniq -c | sort -rn | head -20

If you see 40 distinct destinations in 60 seconds of idle browsing, something is making background connections you haven't accounted for.

strings capture.pcap | grep -i "password\|passwd\|authorization\|cookie\|token" | head -20

This surfaces plaintext credentials in captured packets. Modern HTTPS returns nothing — encrypted. If this returns actual credentials, something is communicating without TLS.

Vulnerability Assessment

Version information visible to you is visible to any attacker scanning the network. Vulnerability assessment uses that same information to answer: do these versions have known, published CVEs?

sudo apt install lynis
sudo lynis audit system

Lynis audits system configuration against a hardening checklist: SSH settings, file permissions, PAM, kernel parameters. It produces a hardening index (0-100) and prioritized suggestions. Think of it as a configuration baseline rather than a CVE scanner.

sudo nmap -sV --script vulners 10.0.0.10

The vulners script queries the Vulners vulnerability database using version strings from -sV. It returns CVEs with CVSS scores. Note: Debian backports security fixes into older upstream versions — the version string may not match what the CVE database expects.

# Check actual installed version via dpkg
dpkg -l openssh-server
dpkg -l cups

dpkg shows the full Debian package version with patch suffix. Compare against the Debian Security Tracker (security-tracker.debian.org) — more accurate than querying NVD directly with upstream version numbers.

sudo apt install exploitdb
searchsploit openssh 9.2

Searchsploit queries a local Exploit-DB database. The distinction: a CVE documents that a vulnerability exists; an Exploit-DB entry means working exploit code is publicly available. The latter raises severity considerably.

Future Threats

The threat landscape isn't static. Three shifts are fundamentally changing what's possible — and what's at risk.

The AI Agent Problem

We are entering an era where software makes decisions, executes actions, and interacts with systems autonomously. An AI agent with internet access, a payment method, and the ability to run commands isn't science fiction — it's current technology.

• Speed — An agent can scan thousands of targets, test hundreds of credentials, and probe for vulnerabilities faster than any human. Manual security assumed a human attacker with human limitations.
• Scale — One agent can manage hundreds of machines, thousands of accounts, or millions of data points simultaneously. The attack surface that was once theoretical is now practical.
• Autonomy — A human attacker needs to make judgment calls. An agent follows objective functions — and can be told to keep trying until something works.

Traditional security assumes a distinct boundary between human operator and automated tool. AI agents blur that boundary — and sometimes cross it without clear authorization. Credential management becomes more critical. Permission boundaries need rethinking. Audit trails become essential.

The Quantum Threat

Quantum computers will break current encryption. This isn't a matter of if — it's a matter of when. The timeline is uncertain, but the mathematics are settled: RSA, DSA, and elliptic curve cryptography (ECC) become breakable once quantum computers reach sufficient scale.

Data captured today can be decrypted later. An attacker recording encrypted traffic now can decrypt it once quantum capabilities exist. This is already happening. Migration takes time — the systems you're using today will still be running when quantum computers arrive. Assume encrypted traffic captured today may be readable within a decade.

The Connected Everything

More devices with computational capacity and network access exist outside traditional security perimeters than inside them. Thermostats, watches, appliances, vehicles, agricultural equipment — all connected, most unpatched, many with trivially exploitable vulnerabilities.

The most practical defense for connected environments is network segmentation — treating untrusted devices as if they're already compromised. Most home routers support multiple SSIDs or VLANs. The principle is: assume a device will be compromised, and design your network so that compromise doesn't spread.

# Update everything
sudo apt update && sudo apt upgrade

# Enable and configure firewall
sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Restrict SSH to LAN only (adjust subnet as needed)
sudo ufw allow from 10.0.0.0/24 to any port 22

# Check credentials in history
history

# Disable password authentication
PasswordAuthentication no

# Disable root login
PermitRootLogin no

# Limit authentication attempts
MaxAuthTries 3

# Set login grace period
LoginGraceTime 30

# Disable empty passwords
PermitEmptyPasswords no

# Use strong key exchange
KexAlgorithms curve25519-sha256

sudo systemctl reload ssh
sudo sshd -T | grep -i "passwordauth\|permitroot"