Linux · Lesson 10

UFW Firewall & Network Exposure

Review Linux host-firewall policy, default behavior, listening services, source networks, application profiles, and client connectivity so required services stay reachable while unnecessary exposure is reduced.

A firewall is most effective when its rules match the system's actual mission. Start with listening services and scenario requirements, then build the narrowest policy that preserves authorized access.

Lesson Snapshot

Core concepts6

Rule fields6

Inspection commands10

Main goalLeast-exposed required access

Learning objectives

Build firewall policy around required network paths

Explain how UFW fits into Linux firewall management and why firewall rules must support the scenario's required services.

Inspect firewall status, default policy, application profiles, and numbered rules before making changes.

Correlate UFW rules with listening ports, interfaces, services, and authorized network paths.

Distinguish required exposure, unnecessary exposure, misconfiguration, and unknown rules using evidence.

Apply narrow UFW changes that reduce attack surface without cutting off SSH or required applications.

Verify firewall behavior from both the local host and client perspective after every meaningful change.

Core idea

Firewall rules should describe the mission

If Morgan needs SSH and the internal application needs HTTPS, those paths should be allowed as narrowly as practical. Everything else should be justified by a required function, not by convenience.

Firewall risk

A secure policy can still break the system if applied in the wrong order

Prepare required allow rules before tightening defaults or enabling the firewall. Preserve a known-good management path until the new policy is verified.

Firewall fundamentals

Six concepts behind host-firewall policy

Host firewall

A host firewall controls traffic to and from one Linux system. It is one layer of defense and does not replace secure services, authentication, or network controls.

UFW

Uncomplicated Firewall is a frontend that simplifies common firewall management tasks on Ubuntu-family systems.

Default policy

Default incoming and outgoing behavior establishes what happens when no more specific rule matches.

Rule scope

A rule can be narrowed by protocol, port, source network, destination, interface, direction, or application profile.

Listening service

A firewall rule matters only in context. A permitted port with no listening service is different from a required service exposed to the wrong network.

Verification

Firewall changes are complete only when required clients can still connect and unnecessary traffic is actually blocked.

Rule anatomy

Every rule answers several questions

Action

ALLOW / DENY / REJECT

Defines whether matching traffic is permitted or blocked.

Direction

in / out

Specifies whether the rule applies to incoming or outgoing traffic.

Protocol

tcp / udp

Limits the rule to a transport protocol when applicable.

Port

22, 80, 443

Limits the rule to a service port or port range.

Source

192.0.2.0/24

Restricts traffic to a specific source host or network.

Destination

any / interface address

Restricts where traffic is headed on the local host.

Inspection first

Understand current exposure before changing policy

sudo ufw status verbose

Show whether UFW is active, default policies, logging state, and configured rules.

sudo ufw status numbered

Display rules with numbers so specific entries can be reviewed and removed carefully.

sudo ufw show raw

Show lower-level firewall rules generated by UFW for deeper troubleshooting.

sudo ufw app list

List application profiles that can be referenced in UFW rules.

sudo ufw app info OpenSSH

Show ports and protocols defined by the OpenSSH application profile when available.

ss -tulpn

Show listening TCP and UDP sockets so firewall rules can be compared with real services.

ip addr

Show interface addresses used to reason about which local networks and interfaces matter.

ip route

Show routing state and help identify reachable management or service networks.

systemctl status service-name

Confirm whether the service behind an allowed port is actually running and healthy.

sudo journalctl -k --since today | grep -i -E 'ufw|firewall'

Review kernel/firewall-related log evidence where UFW logging is enabled.

Service exposure map

Common network services need different decisions

SSH

22/tcp by default

Is remote administration required, and can the rule be narrowed to the authorized management network?

HTTP

80/tcp

Is a web service required, and should it be reachable from all networks or only a specific subnet?

HTTPS

443/tcp

Is secure web traffic required, and is TLS actually configured on the service?

DNS

53/tcp and 53/udp

Is the host acting as a DNS server, or is outbound DNS the only requirement?

Database

Varies by database

Should the database accept remote connections at all, and if so, from which application hosts?

Safe firewall workflow

Build policy in an order that protects availability

Inventory services

List listening sockets and identify which applications or services own them.

Map scenario requirements

Determine which services must be reachable, by whom, from where, and over which protocol.

Review existing policy

Inspect UFW status, defaults, numbered rules, application profiles, and logging state.

Prepare required allows

Create the narrowest rules that preserve SSH and required applications.

Remove unnecessary exposure

Delete or narrow only rules that are confirmed unnecessary or overly broad.

Verify from a client

Test required connectivity and confirm unnecessary traffic is blocked.

Controlled changes

Use the narrowest rule that preserves the mission

Goal

Enable UFW

Example

sudo ufw enable

Caution

Do this only after required SSH and application access rules are prepared and understood.

Goal

Allow an application profile

Example

sudo ufw allow OpenSSH

Caution

Confirm the profile's ports and that the service is required.

Goal

Allow SSH from one training network

Example

sudo ufw allow from 192.0.2.0/24 to any port 22 proto tcp

Caution

Use only authorized source networks. 192.0.2.0/24 is documentation space for training examples.

Goal

Allow a required HTTPS service

Example

sudo ufw allow 443/tcp

Caution

Only useful if the HTTPS service is actually required and configured.

Goal

Delete a specific numbered rule

Example

sudo ufw delete RULE_NUMBER

Caution

Re-run status numbered immediately before deletion because rule numbers can change after edits.

Goal

Set incoming default deny

Example

sudo ufw default deny incoming

Caution

Ensure every required inbound service has an appropriate allow rule first.

Firewall logging

Use logs to explain behavior

Firewall logs are supporting evidence

Blocked or allowed traffic can help explain connection failures or suspicious activity, but absence of a log entry does not prove absence of traffic.

Logging level matters

Higher logging can create more noise and disk usage. Use the level appropriate to the environment.

Kernel logs may contain UFW entries

Depending on logging configuration, UFW messages can appear in the journal or traditional log files.

Correlate with service logs

Firewall evidence is stronger when compared with SSH, web, or application logs and client timestamps.

Verification

Test the policy from the network perspective

Firewall state

Re-run ufw status verbose and confirm the intended default policies and rules are active.

Listening services

Use ss -tulpn to confirm required services are still listening and unnecessary services are not unexpectedly exposed.

SSH

Test a new authorized SSH connection from the permitted source network before closing the known-good session.

Required applications

Test web, database, or custom application connectivity from the client perspective.

Blocked exposure

Confirm traffic that should no longer be permitted is actually blocked from the relevant network path.

Logs

Review firewall and service logs for unexpected denials or errors after the change.

Local success is not enough

A service can work on localhost while the firewall blocks every real client. Validate required traffic from the actual authorized network path.

High-risk shortcuts

Firewall actions that can create outages or erase evidence

ufw enable before preparing required rules

Can immediately cut off SSH or required applications.

ufw reset during investigation

Deletes the current rule set and can destroy useful evidence about prior firewall configuration.

Allowing any/any for convenience

Creates broad exposure that defeats the purpose of least-privilege firewall policy.

Blocking every unfamiliar port

Can break required applications or services whose purpose has not yet been identified.

Ignoring IPv6

A service may still be reachable over IPv6 even when only IPv4 behavior was considered.

Trusting only local tests

A service can work on localhost while remote clients are still blocked or overexposed.

Defensive lab

Reduce fictional Linux exposure without breaking required access

Read the fictional scenario: Morgan must SSH from the training subnet; an internal HTTPS application must be reachable from the same subnet; no other inbound services are required.

Run ss -tulpn, ip addr, ip route, ufw status verbose, ufw status numbered, and ufw app list without changing anything.

Map each listening port to its service and classify it as Required, Unnecessary, or Investigate.

Prepare narrow allow rules for SSH and HTTPS from the training network before enabling or tightening UFW.

Remove only confirmed unnecessary broad rules, preserving the original numbered-rule evidence first.

Verify UFW state, listening sockets, SSH access, HTTPS access, and expected blocked traffic.

Review firewall and application logs for unexpected denials and document the final network exposure.

Lesson checklist

Before moving on

I understand that UFW is a host-firewall frontend, not a replacement for secure services.

I inspect listening ports before changing firewall rules.

I compare every allowed port with a scenario-required service.

I review UFW default policies and numbered rules before edits.

I inspect application profiles before trusting their names.

I preserve required SSH access before enabling or tightening the firewall.

I narrow source networks when the scenario supports it.

I avoid reset or broad any/any rules during routine hardening.

I consider both IPv4 and IPv6 behavior.

I verify firewall changes from the client perspective.

Reflection

Check your reasoning

Question 1

Why should listening services be inventoried before enabling UFW?

Question 2

Why can an allowed port be harmless in one situation and risky in another?

Question 3

Why is a source-restricted SSH rule usually more precise than a broad allow rule?

Question 4

Why should UFW application profiles be inspected before use?

Question 5

How can a service still be unreachable even when UFW allows its port?

Question 6

What should you verify after changing the firewall around a required remote service?

Carry this forward

Firewall policy should mirror required network behavior. Know which services listen, who needs them, where clients come from, and what the firewall must allow or deny. Then verify the result from the client side.

Back to Linux CyberPatriot Hub

← Previous Lesson Next Lesson →