Lab 04 — Linux Networking

Linux networking is one of the most important skill areas for:

Linux Administrators

Cloud Engineers

SOC Analysts

Security Engineers

Cloud Security Engineers

DevOps Engineers

Incident Responders

Penetration Testers

In the previous labs, you worked with:

Linux Administration
        ↓
Linux Hardening
        ↓
Linux IAM

Now you will understand how the Linux server communicates.

Your mission is to move from:

"The Network Is Not Working"

to:

Interface
   ↓
Address
   ↓
Subnet
   ↓
Route
   ↓
Gateway
   ↓
DNS
   ↓
Port
   ↓
Firewall
   ↓
Application

Mission Information

Lab: Linux Networking
Level: Beginner → Intermediate
Estimated Time: 120–180 minutes
Environment: Authorized Linux VM or disposable lab server
Primary Role: Linux / Network Administrator
Secondary Roles: SOC Analyst, Security Engineer, Cloud Engineer, DevSecOps Engineer

Mission Scenario

Your organization has deployed a Linux application server.

Users report intermittent connectivity problems, and the security team also wants confirmation that the server exposes only required network services.

You have been asked to perform a Linux network assessment.

You must determine:

Which Interfaces Exist?

Which IP Addresses Are Assigned?

Which Networks Are Connected?

Where Is the Default Gateway?

How Is DNS Configured?

Which Services Are Listening?

Which Connections Are Active?

Which Firewall Controls Exist?

Can Required Destinations Be Reached?

Is Anything Unexpected Exposed?

You will finish by producing a professional Linux networking assessment report.

Learning Objectives

By completing this lab, you should be able to:

Identify Linux network interfaces
Understand interface states
Review IPv4 and IPv6 addresses
Understand subnet and CIDR concepts
Review routing tables
Identify the default gateway
Understand ARP and neighbor discovery
Review DNS configuration
Test DNS resolution
Understand TCP and UDP
Identify listening ports
Identify established connections
Map ports to processes
Review host firewall configuration
Understand loopback and wildcard bindings
Test network connectivity systematically
Troubleshoot common Linux network problems
Investigate suspicious network activity
Document network-security findings

Lab Architecture

                     Internet / Network
                            |
                            |
                      +-----+-----+
                      |  Gateway  |
                      +-----+-----+
                            |
                     Local Network
                            |
                +-----------+-----------+
                |                       |
                v                       v
        +---------------+       +---------------+
        | Linux Server  |       | Other Systems |
        |               |       |               |
        | Interface     |       | DNS           |
        | IP Address    |       | Applications  |
        | Routes        |       | Services      |
        | DNS           |       +---------------+
        | Firewall      |
        | Services      |
        +---------------+

Linux Networking Mental Model

Always think in layers:

APPLICATION
     ↓
PORT
     ↓
TCP / UDP
     ↓
IP
     ↓
ROUTING
     ↓
NETWORK INTERFACE
     ↓
NETWORK

When something fails, identify:

Which Layer Failed?

instead of immediately restarting services.

Part 01 — Prepare the Lab

Create your workspace:

mkdir -p ~/linux-networking-lab

Enter it:

cd ~/linux-networking-lab

Create:

mkdir baseline evidence findings

Step 01 — Identify the System

Run:

hostname

Then:

cat /etc/os-release

Then:

uname -r

Record:

Hostname:

Distribution:

Kernel:

Date:

Step 02 — Capture Initial Network Baseline

Run:

ip -brief address

Save:

ip -brief address > baseline/interfaces.txt

Then:

ip route > baseline/routes.txt

And:

ss -lntu > baseline/listening-ports.txt

You now have a starting network baseline.

Part 02 — Understand Network Interfaces

Run:

ip link

You may see interfaces such as:

lo

eth0

ens33

ens160

enp0s3

Interface naming depends on the environment.

Step 03 — Review Interface State

Run:

ip -brief link

Look for states such as:

UP

DOWN

UNKNOWN

Important Concept

An interface can exist but still not provide usable network connectivity.

You need to validate:

Interface Exists
      ↓
Interface Enabled
      ↓
Address Assigned
      ↓
Route Available
      ↓
Network Reachable

Part 03 — Loopback Interface

Most Linux systems have:

lo

The loopback interface.

Common addresses include:

127.0.0.1

for IPv4 and:

::1

for IPv6.

Why Loopback Matters

Loopback allows:

Application
      ↓
Local Network Stack
      ↓
Another Local Application

without traffic leaving the host.

Security Significance

A service listening only on:

127.0.0.1

normally has much less remote exposure than one listening on:

0.0.0.0

provided no other forwarding or proxy mechanism exposes it.

Part 04 — Review IP Addresses

Run:

ip addr

Or use the concise version:

ip -brief addr

Record:

Interface:

IPv4 Address:

IPv4 Prefix:

IPv6 Address:

Interface State:

IPv4 Example

You might see:

192.168.10.25/24

This contains:

IP Address
192.168.10.25

Prefix
/24

Part 05 — Understand CIDR

CIDR expresses the network prefix.

Examples:

CIDR	Common IPv4 Mask
`/8`	255.0.0.0
`/16`	255.255.0.0
`/24`	255.255.255.0
`/32`	Single IPv4 host route

Do not rely only on memorized tables.

Understand that the prefix determines:

Network Portion

Host Portion

Example

Given:

192.168.10.25/24

the network is typically:

192.168.10.0/24

and the host address is:

192.168.10.25

Part 06 — Public vs Private IPv4

Common private IPv4 ranges include:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

These ranges are commonly used inside:

Enterprise Networks

Home Networks

Cloud VPCs/VNets

Lab Environments

Security Perspective

Do not assume:

Private IP
=
Secure

Private networks can still contain:

Compromised Systems

Malicious Insiders

Misconfigured Services

Lateral Movement

Part 07 — Review Routes

Run:

ip route

You may see something conceptually similar to:

default via 192.168.10.1 dev eth0

192.168.10.0/24 dev eth0

Routing Model

Destination
     ↓
Routing Table
     ↓
Matching Route
     ↓
Gateway / Interface
     ↓
Packet Forwarded

Step 04 — Identify the Default Route

Look for:

default

Record:

Default Gateway:

Interface:

Why the Default Gateway Matters

If a destination is outside directly connected networks, Linux usually needs an appropriate route.

A common path is:

Linux Server
      ↓
Default Gateway
      ↓
Other Networks

Troubleshooting Question

If the server can communicate locally but not with remote networks, investigate:

Routing

Gateway

Upstream Firewall

Network ACL

NAT

Destination

Part 08 — Route Selection

Linux may have multiple routes.

The system generally selects the most appropriate route based on routing rules and prefix specificity.

Conceptually:

Destination
      ↓
Most Specific Applicable Route
      ↓
Selected Path

Step 05 — Ask Linux Which Route It Would Use

For an approved destination:

ip route get <approved-ip>

This can show information such as:

Selected Interface

Gateway

Source Address

Part 09 — Review Neighbor Information

On local Ethernet-style networks, systems need to map network-layer addresses to link-layer neighbors.

Run:

ip neigh

You may see:

IP Address

MAC Address

Interface

Neighbor State

IPv4 Concept

Traditionally:

IPv4
   ↓
ARP
   ↓
MAC Address

IPv6 Concept

IPv6 uses:

Neighbor Discovery

rather than ARP.

Security Perspective

Unexpected neighbor information may sometimes support investigations into:

Address Conflicts

Gateway Problems

Local Network Spoofing

Unexpected Devices

but evidence must be interpreted carefully.

Part 10 — Test the Local Network Stack

Test loopback:

ping -c 4 127.0.0.1

If IPv6 is available:

ping -c 4 ::1

This primarily validates the local IP stack.

Step 06 — Test Your Own Address

Identify your assigned address:

ip -brief addr

Then test the appropriate local address where useful.

Step 07 — Test the Gateway

If ICMP is permitted in your lab:

ping -c 4 <gateway-ip>

Important

A failed ping does not automatically mean:

Gateway Is Down

ICMP may be filtered.

Use multiple pieces of evidence.

Part 11 — Connectivity Testing Model

Use this sequence:

01 Loopback

02 Local Interface

03 Local Gateway

04 Remote IP

05 DNS Name

06 Required Port

07 Application

This helps isolate the failing layer.

Part 12 — DNS

DNS translates names into information such as IP addresses.

Conceptually:

application.example
        ↓
       DNS
        ↓
    IP Address

Step 08 — Review Resolver Configuration

Inspect:

cat /etc/resolv.conf

Depending on the distribution, this file may be managed dynamically.

You may see:

nameserver

search

options

Important

Do not assume manually editing /etc/resolv.conf is the correct persistent fix.

It may be managed by:

NetworkManager

systemd-resolved

DHCP

Cloud Networking

Part 13 — Test DNS

Depending on installed utilities, use:

getent hosts example.com

or tools such as:

dig

host

nslookup

if available.

DNS Troubleshooting Model

Can Reach IP?
      |
      +-- No → Network/Routing/Firewall
      |
      +-- Yes
            ↓
Can Resolve Name?
      |
      +-- No → DNS
      |
      +-- Yes
            ↓
Test Application

Part 14 — `/etc/hosts`

Inspect:

cat /etc/hosts

Local host mappings can influence name resolution.

Security Perspective

Unexpected host-file entries can sometimes:

Redirect Applications

Override Expected Resolution

Cause Troubleshooting Problems

Do not immediately classify every custom entry as malicious.

Determine its business purpose.

Part 15 — TCP and UDP

Linux applications commonly communicate using:

TCP

or:

UDP

TCP

TCP provides connection-oriented communication.

Conceptually:

Client
   ↓
Connection Establishment
   ↓
Data Exchange
   ↓
Connection Close

Common examples include:

SSH

HTTPS

Database Connections

UDP

UDP is connectionless at the transport layer.

Common uses can include:

DNS

Monitoring

Streaming

Infrastructure Protocols

depending on the application.

Security Lesson

Do not assume:

UDP
=
Unimportant

UDP services can also create significant attack surface.

Part 16 — Ports

Ports identify application endpoints.

Conceptually:

IP Address
   +
Port
   +
Protocol

Examples commonly include:

22/TCP  → SSH

53/UDP  → DNS

53/TCP  → DNS

80/TCP  → HTTP

443/TCP → HTTPS

But never identify a service solely from the port number.

Applications can listen on non-standard ports.

Part 17 — Identify Listening TCP Ports

Run:

ss -lnt

Interpret:

-l
Listening

-n
Numeric

-t
TCP

Step 09 — Review UDP Listeners

Run:

ss -lnu

Step 10 — Review Processes

With appropriate privilege:

sudo ss -lntup

This may help map:

Port
   ↓
Process
   ↓
Service

Network Security Question

For every listener ask:

What Process Owns It?

Which User Runs It?

Why Is It Required?

Which Interface Is It Bound To?

Who Can Reach It?

Part 18 — Understand Bind Addresses

Compare:

127.0.0.1:8080

with:

0.0.0.0:8080

Conceptually:

127.0.0.1
      ↓
Local IPv4 Access

0.0.0.0
      ↓
All Applicable IPv4 Interfaces

IPv6 wildcard bindings may appear as:

[::]

Actual reachability still depends on:

Routes

Firewall

Network Controls

Application Configuration

Finding Example

Finding:
Service Bound to Unnecessary Interfaces

Observation:
An application service listens on all
available interfaces despite only requiring
local communication.

Risk:
The service may become reachable from
networks that do not require access.

Recommendation:
Bind the service to the minimum required
interface and enforce appropriate firewall
restrictions.

Part 19 — Established Connections

Run:

ss -nt

Look for established TCP connections.

For process information:

sudo ss -ntp

where supported.

Connection Investigation

For each unexpected connection determine:

Local Address

Local Port

Remote Address

Remote Port

Process

User

Connection State

Part 20 — TCP Connection States

You may encounter states such as:

LISTEN

ESTAB

TIME-WAIT

SYN-SENT

SYN-RECV

These states help describe where a TCP connection is in its lifecycle.

Security Perspective

For example:

Many SYN-RECV Connections

may require investigation.

But do not immediately conclude:

Attack

Possible explanations include:

Traffic Spike

Network Problem

Application Behavior

Scanning

Denial-of-Service Activity

Context matters.

Part 21 — Map Process to Port

Suppose you find:

TCP 8080

listening unexpectedly.

Use:

sudo ss -lntp

Then identify the process.

You may also use appropriate process inspection tools.

Investigation Workflow

PORT
  ↓
PID
  ↓
PROCESS
  ↓
USER
  ↓
EXECUTABLE
  ↓
SERVICE
  ↓
CONFIGURATION
  ↓
BUSINESS REQUIREMENT

Part 22 — Review Network Services

List running services:

systemctl --type=service --state=running

Compare:

Running Services

against:

Listening Ports

Not every service listens on a network port.

Not every network process is necessarily managed exactly as you expect.

Correlate evidence.

Part 23 — SSH Network Review

If SSH is running, determine:

Which Port?

Which Address?

Which Process?

Which Interface?

Who Can Reach It?

Use:

sudo ss -lntp

and the relevant SSH configuration.

Security Model

Instead of:

SSH Open Everywhere

prefer:

Approved Administrators
        ↓
Approved Network
        ↓
Firewall
        ↓
SSH

where the environment permits.

Part 24 — Host Firewall

Linux host firewalls provide another network-security layer.

Common management technologies include:

firewalld

nftables

ufw

Your distribution may use one of these or another approved solution.

Critical Safety Rule

If connected remotely:

DO NOT
apply restrictive firewall rules
until required administrative access
has been explicitly allowed.

Otherwise you may lock yourself out.

Part 25 — Determine Firewall Technology

Check which tooling exists and is active.

For firewalld:

systemctl status firewalld

For UFW:

sudo ufw status

For nftables:

sudo nft list ruleset

Use the technology appropriate to your system.

Part 26 — Firewalld Review

If firewalld is active:

sudo firewall-cmd --get-active-zones

Then:

sudo firewall-cmd --list-all

Review:

Zone

Interfaces

Services

Ports

Sources

Firewalld Mental Model

Interface / Source
      ↓
Zone
      ↓
Policy
      ↓
Allowed Traffic

Part 27 — UFW Review

If UFW is used:

sudo ufw status verbose

Review:

Status

Default Policies

Allowed Services

Source Restrictions

Part 28 — nftables Review

If nftables is directly managed:

sudo nft list ruleset

Your objective is not to memorize every syntax detail.

Understand:

Table
   ↓
Chain
   ↓
Rule
   ↓
Traffic Decision

Part 29 — Firewall Design

Use:

DEFAULT RESTRICTION
       ↓
EXPLICIT BUSINESS REQUIREMENT
       ↓
ALLOW REQUIRED TRAFFIC

For example:

SSH
   ↓
Only Administration Network

HTTPS
   ↓
Approved Client Networks

Database
   ↓
Application Tier Only

Part 30 — Defense in Depth

A Linux server may be protected by:

Internet / Enterprise Network
           ↓
Network Firewall
           ↓
Cloud Security Group / NSG
           ↓
Linux Host Firewall
           ↓
Application Listener

Do not rely on only one layer.

Part 31 — Test a TCP Port

For an approved destination and port, tools such as:

nc -vz <approved-host> <approved-port>

may be available.

If nc is not installed, use another approved connectivity-testing utility appropriate to the application.

Important

A successful TCP connection tells you:

Network Path + Port
Are Reachable

It does not necessarily prove:

Application Is Healthy

Part 32 — Application Testing

For HTTP/HTTPS services, an authorized lab may use:

curl -I http://<approved-host>

or:

curl -I https://<approved-host>

This tests at a higher layer than simple port connectivity.

Troubleshooting Ladder

Ping / Reachability
      ↓
Port Connectivity
      ↓
Protocol
      ↓
Application Response

Part 33 — Trace Network Path

Where installed and permitted:

traceroute <approved-destination>

or equivalent tools may help understand the path.

Remember that network devices may intentionally suppress or filter diagnostic responses.

Part 34 — NetworkManager

Many enterprise Linux distributions use:

NetworkManager

Check:

systemctl status NetworkManager

If available:

nmcli device status

Step 11 — Review Connections

nmcli connection show

Understand the distinction between:

Network Device

and:

Network Connection Profile

Part 35 — Persistent Configuration

A critical Linux networking lesson is:

Runtime Change
      ≠
Persistent Change

A configuration that works now may disappear after:

Reboot

Interface Restart

NetworkManager Reload

Always understand how your distribution persists network configuration.

Part 36 — DHCP vs Static Addressing

Linux hosts may obtain network configuration through:

DHCP

or use:

Static Configuration

DHCP May Provide

IP Address

Subnet

Gateway

DNS

Lease Information

Static Configuration

May be appropriate when predictable addressing is required.

The correct model depends on infrastructure architecture.

Part 37 — IPv6

Do not ignore IPv6.

Review:

ip -6 addr

Then:

ip -6 route

Security Mistake

An organization may carefully restrict:

IPv4

while forgetting:

IPv6

This can create unexpected exposure.

IPv6 Review Questions

Is IPv6 Enabled?

Is It Required?

Which Addresses Exist?

Which Services Listen on IPv6?

Does the Firewall Cover IPv6?

Part 38 — Network Statistics

Run:

ss -s

This provides a summary of socket usage.

Depending on installed tooling, other system/network statistics may also be available.

Security Perspective

Baselines help you recognize:

Normal Connection Volume

Normal Listening Ports

Normal Destinations

so deviations become easier to investigate.

Part 39 — Network Baseline

Create a baseline containing:

Interfaces

IP Addresses

Routes

Gateway

DNS

Listening Ports

Expected Services

Firewall Rules

Expected External Destinations

Example

Linux Network Baseline

Interface:
ensX

Role:
Application Network

Expected Services:
SSH
HTTPS

Expected Outbound:
DNS
Package Repositories
Logging Platform

Unexpected Listeners:
None

Part 40 — Troubleshooting Scenario 01

Server Has No Network Connectivity

Use:

Interface
   ↓
Link State
   ↓
IP Address
   ↓
Subnet
   ↓
Route
   ↓
Gateway
   ↓
Firewall

Commands may include:

ip -brief link

ip -brief addr

ip route

ip neigh

Part 41 — Troubleshooting Scenario 02

Server Can Reach IPs but Not Names

Likely investigation path:

Network Works
      ↓
Routing Works
      ↓
DNS Fails

Check:

Resolver Configuration

DNS Server Reachability

Name Resolution

Local Hosts File

Part 42 — Troubleshooting Scenario 03

Service Works Locally but Not Remotely

Investigate:

Application Running?
      ↓
Listening?
      ↓
Correct Bind Address?
      ↓
Host Firewall?
      ↓
Network Firewall?
      ↓
Routing?
      ↓
Client Path?

A common cause is:

Service Bound Only
to Loopback

but many other causes are possible.

Part 43 — Troubleshooting Scenario 04

Server Can Reach Local Network but Not Internet

Investigate:

Default Route

Gateway

Upstream Routing

NAT

Firewall

DNS

Test IP connectivity separately from DNS.

Part 44 — Troubleshooting Scenario 05

Connection Refused

Conceptually:

Network Path Reaches Host
      ↓
Target Port Rejects Connection

Possible causes:

Service Not Running

Wrong Port

Application Not Listening

Local Policy

Part 45 — Troubleshooting Scenario 06

Connection Times Out

Possible causes include:

Routing Failure

Firewall Drop

Network ACL

Unreachable Host

Application Path Problem

Do not treat:

Timeout

and:

Connection Refused

as identical symptoms.

Part 46 — Troubleshooting Scenario 07

Wrong IP Address

Check:

ip addr

Then determine:

DHCP?

Static?

Wrong Profile?

Wrong Interface?

Cloud Configuration?

Part 47 — Troubleshooting Scenario 08

Duplicate IP

Possible symptoms include:

Intermittent Connectivity

Unexpected Neighbor Changes

Connection Instability

Investigate:

Address Assignment

DHCP

Neighbor Table

Network Infrastructure

Part 48 — Troubleshooting Scenario 09

Application Cannot Reach Database

Use:

Application Host
      ↓
DNS
      ↓
Route
      ↓
Firewall
      ↓
Database Listener
      ↓
Application Authentication

Do not assume every database connection problem is:

Network

It may be:

Authentication

TLS

Application Configuration

Database Policy

Part 49 — Troubleshooting Scenario 10

SSH Cannot Connect

Review:

Client Network

DNS / IP

Route

Firewall

Port

sshd Listener

SSH Service

Authentication

Account Policy

This is a layered problem.

Part 50 — Network Security Investigation

Suppose your monitoring platform reports:

Linux Server
Connecting to
Unexpected External IP

Do not immediately block it without understanding the context.

Investigate:

Remote IP
   ↓
Connection
   ↓
Local Process
   ↓
PID
   ↓
User
   ↓
Executable
   ↓
Parent Process
   ↓
Business Requirement

Step 12 — Review Active Connections

Use:

sudo ss -ntp

Identify:

Remote Address

Local Process

PID

Step 13 — Investigate Process

For an authorized process:

ps -fp <PID>

Review:

User

Parent

Command

Start Information

Additional process inspection may be appropriate depending on the investigation.

Security Investigation Model

NETWORK
   ↓
PROCESS
   ↓
USER
   ↓
FILE
   ↓
PARENT
   ↓
TIMELINE
   ↓
BUSINESS CONTEXT

Part 51 — Unexpected Listening Port

Suppose you discover:

0.0.0.0:9000

and it is not in the approved baseline.

Investigate:

01 Identify Process

02 Identify User

03 Identify Executable

04 Identify Service

05 Review Start Method

06 Review Logs

07 Confirm Business Requirement

08 Determine Exposure

09 Assess Risk

10 Remediate if Authorized

Finding Example

Finding:
Unexpected Network Listener

Observation:
A service is listening on TCP port 9000
across available network interfaces but
is not present in the approved server
baseline.

Risk:
The service may create unnecessary
network attack surface or represent an
unauthorized application.

Recommendation:
Identify the process owner and business
requirement. Remove or restrict the
service if it is not authorized.

Part 52 — Unexpected Outbound Connection

Finding:
Unexpected Outbound Network Connection

Observation:
A server process established a connection
to an external destination that is not
part of the documented application flow.

Risk:
Unexpected outbound communication may
represent misconfiguration, unauthorized
software, or potentially malicious
activity.

Recommendation:
Correlate the connection with the process,
user, executable, logs, destination
reputation, and business requirements
before determining the appropriate
containment or remediation action.

Part 53 — Overly Broad Firewall Rule

Finding:
Overly Broad Network Access

Observation:
A network service is permitted from a
broader source range than required for
its business function.

Risk:
Unnecessary network reachability increases
the number of systems capable of
interacting with the service.

Recommendation:
Restrict access to approved source
networks or systems using least-privilege
firewall rules.

Part 54 — Administrative Service Exposure

Finding:
Administrative Service Broadly Exposed

Observation:
A remote administration service is
reachable from networks that do not
require administrative access.

Risk:
Broader administrative exposure increases
the opportunity for authentication attacks
and exploitation of the service.

Recommendation:
Restrict administrative access to
approved management networks and enforce
strong authentication and monitoring.

Part 55 — Missing Host Firewall

Finding:
Host-Level Network Filtering Not Enforced

Observation:
The Linux server does not have an active
host-level network-filtering policy,
despite the server role requiring
defense-in-depth controls.

Risk:
The server relies entirely on upstream
network controls and may become exposed
if those controls are changed or bypassed.

Recommendation:
Implement an approved host firewall policy
that permits required traffic and restricts
unnecessary access.

Part 56 — Network Logging

Network security requires visibility.

Relevant evidence can come from:

Application Logs

SSH Logs

Firewall Logs

System Journal

DNS Logs

Proxy Logs

Cloud Flow Logs

Network Security Devices

SIEM

Linux Perspective

Linux tells you:

Which Process

Which User

Which Socket

Network infrastructure may tell you:

Which Source

Which Destination

Which Flow

Combining both provides stronger evidence.

Part 57 — Cloud Networking Connection

Linux networking directly maps to cloud networking.

AWS

Linux Interface
      ↓
EC2 ENI
      ↓
Subnet
      ↓
Route Table
      ↓
Security Group
      ↓
NACL
      ↓
Gateway

Azure

Linux Interface
      ↓
Azure NIC
      ↓
Subnet
      ↓
Route
      ↓
NSG
      ↓
Azure Network

Google Cloud

Linux Interface
      ↓
Compute Interface
      ↓
VPC
      ↓
Subnet
      ↓
Route
      ↓
Firewall Policy

Critical Cloud Lesson

A Linux administrator may see:

Everything Looks Correct

inside the VM.

But the failure may exist in:

Cloud Route

Security Group

NSG

VPC Firewall

Network ACL

Load Balancer

NAT

Always understand both layers.

Part 58 — Container Networking Connection

Containers introduce another networking layer.

Physical / Cloud Network
        ↓
Linux Host
        ↓
Container Network
        ↓
Container
        ↓
Application

Linux networking knowledge helps you understand:

Container Interfaces

Bridges

NAT

Port Publishing

Namespaces

Part 59 — Kubernetes Networking Connection

Kubernetes expands this further:

External Client
      ↓
Load Balancer / Ingress
      ↓
Service
      ↓
Pod Network
      ↓
Container
      ↓
Linux Network Stack

This is why Linux networking is foundational for:

Kubernetes Security

Part 60 — SOC Connection

Linux network evidence helps investigate alerts such as:

Unexpected Outbound Connection

New Listening Port

SSH Connection

Suspicious DNS Request

Port Scan

Command-and-Control Indicator

Lateral Movement

SOC Workflow

ALERT
   ↓
IP / PORT
   ↓
LINUX HOST
   ↓
PROCESS
   ↓
USER
   ↓
TIMELINE
   ↓
DECISION

Part 61 — Incident Response Connection

During an incident, network information can help determine:

Which Systems Communicated?

Which Process Connected?

Which Accounts Were Involved?

Which Destinations Were Contacted?

Which Services Were Exposed?

Do not destroy evidence unnecessarily by immediately:

Restarting

Killing Processes

Clearing Connections

Reconfiguring Everything

before collecting required evidence.

Part 62 — Build a Network Inventory

Create:

Linux Network Inventory

Include:

Hostname:

Interfaces:

MAC Addresses:

IPv4 Addresses:

IPv6 Addresses:

Subnets:

Default Gateway:

DNS Servers:

Listening TCP Ports:

Listening UDP Ports:

Firewall Technology:

Expected Services:

Part 63 — Build a Service Exposure Matrix

Service	Protocol	Port	Bind Address	Required	Expected Sources
SSH	TCP	22	Review	Yes	Admin Network
HTTPS	TCP	443	Review	If applicable	Approved Clients
Unknown	TCP	Example	Review	Review	Review

Part 64 — Build a Connectivity Matrix

Source	Destination	Port	Expected	Result
Admin Host	Linux Server	SSH	Yes	Test
Linux Server	DNS	DNS	Yes	Test
Linux Server	Approved App	App Port	Yes	Test
Unapproved Source	Admin Service	SSH	No	Validate restriction

Only perform tests inside your authorized environment.

Part 65 — Create the Networking Report

Your report should contain:

1. Executive Summary

Describe:

Overall Network State

Major Connectivity Issues

Unexpected Exposure

Firewall Status

Highest-Risk Findings

2. System Information

Hostname

Distribution

Kernel

Server Role

3. Interface Inventory

Interface

State

MAC

IPv4

IPv6

4. Routing

Connected Routes

Default Gateway

Unexpected Routes

5. DNS

Resolver Configuration

Resolution Test

Observed Issues

6. Services

Listening Port

Protocol

Process

User

Bind Address

Business Requirement

7. Firewall

Technology

State

Allowed Traffic

Observed Gaps

8. Active Connections

Document relevant:

Local Endpoint

Remote Endpoint

Process

User

Expected?

9. Findings

For each:

Title

Observation

Risk

Evidence

Recommendation

Priority

Part 66 — Evidence Checklist

Capture appropriate evidence for:

Do not unnecessarily capture:

Credentials

Private Keys

Tokens

Sensitive Application Data

Part 67 — Practical Challenge

Without using a graphical interface, answer:

What Is My IP?

What Is My Prefix?

What Is My Gateway?

Which Interface Carries Default Traffic?

Which DNS Resolver Is Used?

Which TCP Ports Are Listening?

Which UDP Ports Are Listening?

Which Processes Own Them?

Which Connections Are Established?

Which Firewall Is Active?

Part 68 — Troubleshooting Challenge

Your Linux server:

Can Reach 8.8.8.8

but:

Cannot Resolve example.com

Which layer should you investigate first?

DNS

because basic IP connectivity already works.

Part 69 — Troubleshooting Challenge

Your application responds on:

127.0.0.1:8080

but remote clients cannot connect.

Investigate:

Bind Address

Host Firewall

Upstream Firewall

Routing

The service may be intentionally restricted to loopback.

Part 70 — Troubleshooting Challenge

A port is permitted by the firewall, but:

Connection Refused

What should you investigate?

Is the Application Running?

Is It Listening?

Is It Listening on the Correct Address?

Is the Correct Port Configured?

A firewall rule cannot create a listener.

Part 71 — Troubleshooting Challenge

The service is listening and the Linux firewall permits it, but clients still time out.

Move outward:

Linux Host
   ↓
Cloud / Network Firewall
   ↓
Route
   ↓
Load Balancer
   ↓
Client Network

Part 72 — Security Challenge

You discover:

Unknown Process
      ↓
Listening on 0.0.0.0:4444

Do not immediately classify it solely by the port number.

Investigate:

PID

Process

Executable

User

Parent

Start Time

Service

Logs

Network Connections

Business Requirement

Port numbers alone are not proof of malicious behavior.

Part 73 — Network Troubleshooting Method

Use this professional workflow:

01 Understand the Symptom

02 Determine Scope

03 Identify Source

04 Identify Destination

05 Identify Protocol and Port

06 Check Interface

07 Check Address

08 Check Route

09 Check DNS

10 Check Listener

11 Check Firewall

12 Check Application

13 Review Logs

14 Compare Baseline

15 Fix Minimum Necessary Layer

16 Validate

17 Document

Part 74 — Common Networking Mistakes

Avoid:

Restarting Network Services Immediately

Disabling Firewall to Troubleshoot

Assuming Ping Proves Everything

Assuming Ping Failure Means Host Down

Ignoring DNS

Ignoring IPv6

Ignoring Bind Addresses

Assuming Port Number Identifies Application

Making Temporary Changes Permanent Accidentally

Forgetting Cloud Network Controls

Opening 0.0.0.0/0 Without Requirement

Failing to Document Routes

Ignoring Outbound Connections

Part 75 — Security Design Principles

Apply:

Least Exposure

Network Segmentation

Defense in Depth

Explicit Business Requirements

Secure Administration

Logging

Monitoring

Controlled Egress

Baseline Comparison

Part 76 — Network Segmentation

Instead of:

Every Server
Can Reach
Every Server

prefer architectures such as:

User Tier
   ↓
Application Tier
   ↓
Database Tier

with controlled communication between layers.

Security Benefit

Segmentation can reduce:

Attack Surface

Lateral Movement

Blast Radius

Part 77 — Ingress vs Egress

Ingress

Traffic entering the server:

Client
   ↓
Linux Server

Egress

Traffic leaving the server:

Linux Server
   ↓
External Destination

Security teams should consider both.

Why Egress Matters

If malware executes on a server, unrestricted outbound access may allow:

Command and Control

Data Exfiltration

Malicious Downloads

Therefore outbound communication should also have business context.

Part 78 — Network Baseline Maturity

Level 1

Know IP Addresses

Know Gateway

Know Listening Ports

Level 2

Document Required Services

Apply Host Firewall

Monitor Connections

Centralize Logs

Level 3

Network Segmentation

Controlled Egress

Flow Monitoring

Automated Baselines

Configuration Management

Level 4

Continuous Network Detection

Automated Drift Detection

Zero Trust Access

Policy as Code

Part 79 — Career Connection

This lab directly supports:

Linux Administrator

Network Administrator

SOC Analyst

Security Engineer

Cloud Engineer

Cloud Security Engineer

DevOps Engineer

DevSecOps Engineer

Incident Responder

Penetration Tester

Interview Scenario 01

A Linux server can communicate with local systems but not remote networks. What do you check?

Routes

Default Gateway

Upstream Routing

Firewall

NAT

Interview Scenario 02

A server can reach an IP address but cannot reach the hostname. What is likely wrong?

Start with:

DNS Resolution

Interview Scenario 03

An application works locally but remote users cannot reach it. What do you investigate?

Bind Address

Listening Port

Host Firewall

Network Firewall

Route

Application Configuration

Interview Scenario 04

How do you identify which process owns a listening port?

A common approach is:

sudo ss -lntup

and then correlate the PID/process with system information.

Interview Scenario 05

Why should you review outbound connections?

Because unexpected outbound communication may indicate:

Misconfiguration

Unauthorized Software

Compromise

Data Exfiltration

Command-and-Control Activity

50 Linux Networking Interview Questions

What is a network interface?
What is the loopback interface?
What is 127.0.0.1?
What is an IP address?
What is CIDR?
What does /24 mean?
What are private IPv4 ranges?
What is a subnet?
What is a default gateway?
What does ip route show?
How does Linux select a route?
What does ip route get do?
What is ARP?
What is IPv6 Neighbor Discovery?
What does ip neigh show?
What is DNS?
What is /etc/resolv.conf?
Why should you not always edit /etc/resolv.conf directly?
What is /etc/hosts?
What is TCP?
What is UDP?
What is a network port?
What is a listening port?
What is an established connection?
What does ss do?
How do you identify listening TCP ports?
How do you identify UDP listeners?
How do you map a port to a process?
What does 0.0.0.0 mean for a listener?
What does 127.0.0.1 mean for a listener?
What is the difference between connection refused and timeout?
Why might ping fail even if a service is reachable?
What is a host firewall?
What is firewalld?
What is nftables?
What is UFW?
What is ingress traffic?
What is egress traffic?
Why should outbound traffic be monitored?
What is network segmentation?
Why is IPv6 security important?
What is NetworkManager?
What does nmcli manage?
What is the difference between DHCP and static addressing?
How would you troubleshoot DNS failure?
How would you troubleshoot SSH connectivity?
How would you investigate an unknown listening port?
How would you investigate an unexpected outbound connection?
How does Linux networking relate to cloud networking?
Why is a network baseline valuable for incident response?

Lab Completion Checklist

Interfaces

Addressing

Understood CIDR
Identified subnet
Identified private/public addressing concepts
Reviewed address configuration

Routing

DNS

Reviewed resolver configuration
Tested name resolution
Reviewed /etc/hosts
Understood DNS troubleshooting

Transport

Services

Mapped ports to processes
Identified service owners
Reviewed bind addresses
Validated business requirements

Firewall

Identified firewall technology
Reviewed firewall status
Reviewed allowed services/ports
Understood least-exposure design
Preserved administrative access

Troubleshooting

Security

Reviewed unexpected listeners
Reviewed active connections
Reviewed administrative exposure
Reviewed outbound communication
Documented security findings

Documentation

Final Linux Networking Mental Model

When investigating Linux networking, think:

WHO
Which process/user?

WHAT
Which application/protocol?

WHERE
Which local and remote address?

PORT
Which service endpoint?

INTERFACE
Which network interface?

ROUTE
Which path?

DNS
Which name resolution?

FIREWALL
Which traffic is permitted?

LOGS
What evidence exists?

BASELINE
Is this expected?

Mission Accomplished

You have now worked through:

Linux Interfaces

IPv4

IPv6

CIDR

Routing

Gateways

Neighbors

DNS

TCP

UDP

Ports

Sockets

Processes

Services

Firewall Controls

Network Troubleshooting

Network Security Analysis

You have moved from:

Linux User

to thinking like:

Linux Network Administrator
+
Security Analyst

Most importantly, you now have a repeatable troubleshooting workflow:

INTERFACE
   ↓
IP ADDRESS
   ↓
SUBNET
   ↓
ROUTE
   ↓
GATEWAY
   ↓
DNS
   ↓
PORT
   ↓
FIREWALL
   ↓
APPLICATION

What’s Next?

➡️ Lab 05 — Linux Security

In the final Linux lab, you will combine the skills from:

Linux Administration

Linux Hardening

Linux IAM

Linux Networking

into a complete Linux security assessment.

You will work through:

System Baseline
      ↓
Identity Review
      ↓
Privilege Review
      ↓
Filesystem Security
      ↓
Process Investigation
      ↓
Service Security
      ↓
Network Exposure
      ↓
Logging and Auditing
      ↓
Persistence Review
      ↓
Security Controls
      ↓
Suspicious Activity Investigation
      ↓
Findings and Remediation

Your Linux lab journey continues:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking
        ↓
Lab 05 — Linux Security
        ↓
Runbook 01 — Linux Incident Investigation
        ↓
Runbook 02 — Linux Security Assessment
        ↓
Runbook 03 — Linux Server Hardening

Lab 04 — Linux Networking

Mission Information

Mission Scenario

Learning Objectives

Lab Architecture

Linux Networking Mental Model

Part 01 — Prepare the Lab

Step 01 — Identify the System

Step 02 — Capture Initial Network Baseline

Part 02 — Understand Network Interfaces

Step 03 — Review Interface State

Important Concept

Part 03 — Loopback Interface

Why Loopback Matters

Security Significance

Part 04 — Review IP Addresses

IPv4 Example

Part 05 — Understand CIDR

Example

Part 06 — Public vs Private IPv4

Security Perspective

Part 07 — Review Routes

Routing Model

Step 04 — Identify the Default Route

Why the Default Gateway Matters

Troubleshooting Question

Part 08 — Route Selection

Step 05 — Ask Linux Which Route It Would Use

Part 09 — Review Neighbor Information

IPv4 Concept

IPv6 Concept

Security Perspective

Part 10 — Test the Local Network Stack

Step 06 — Test Your Own Address

Step 07 — Test the Gateway

Important

Part 11 — Connectivity Testing Model

Part 12 — DNS

Step 08 — Review Resolver Configuration

Important

Part 13 — Test DNS

DNS Troubleshooting Model

Part 14 — /etc/hosts

Security Perspective

Part 15 — TCP and UDP

TCP

UDP

Security Lesson

Part 16 — Ports

Part 17 — Identify Listening TCP Ports

Step 09 — Review UDP Listeners

Step 10 — Review Processes

Network Security Question

Part 18 — Understand Bind Addresses

Finding Example

Part 19 — Established Connections

Connection Investigation

Part 20 — TCP Connection States

Security Perspective

Part 21 — Map Process to Port

Investigation Workflow

Part 22 — Review Network Services

Part 23 — SSH Network Review

Security Model

Part 24 — Host Firewall

Critical Safety Rule

Part 25 — Determine Firewall Technology

Part 26 — Firewalld Review

Firewalld Mental Model

Part 27 — UFW Review

Part 28 — nftables Review

Part 29 — Firewall Design

Part 30 — Defense in Depth

Part 31 — Test a TCP Port

Important

Part 32 — Application Testing

Troubleshooting Ladder

Part 33 — Trace Network Path

Part 34 — NetworkManager

Step 11 — Review Connections

Part 14 — `/etc/hosts`