I1.3 Ports, Protocols, and Services
Analyze fictional network services using protocol, port, direction, connection state, owner, exposure, purpose, endpoint context, firewall evidence, and least-privilege decisions.
Lesson Progress
Ports, Protocols, and Services
High School Intermediate • I1: Networking for Defenders • Lesson 3 of 8
Readiness Check
Before You Start
0/4 ready
Professional Hook
The Same Port Can Support Approved Work, Unnecessary Exposure, or Suspicious Activity
Port 443 often supports HTTPS, but a defender still needs to know which application opened the connection, which domain and address were involved, whether the destination is approved, which account acted, whether the service is expected, and what the firewall and endpoint records show. Port context begins the review; it does not finish it.
Weak response
“It uses a common port, so it must be safe.”
Strong response
“Read the complete connection tuple, identify the service and owner, measure exposure, correlate evidence, and compare the activity with approved purpose.”
Objective 1
Explain how transport protocols, ports, applications, and services relate without treating them as identical.
Objective 2
Use source, destination, direction, protocol, port, state, owner, and purpose to review fictional network activity.
Objective 3
Distinguish expected, unnecessary, exposed, denied, and review-required services.
Objective 4
Correlate service inventory, firewall, endpoint, authentication, DNS, and change evidence before reaching a conclusion.
Objective 5
Recommend safe defensive actions based on least privilege, ownership, approved purpose, and evidence quality.
Why This Matters
Services Create Useful Capabilities and Potential Exposure
Every enabled service should have a reason, an owner, an approved audience, appropriate authentication, logging, protection, and a review process. Defenders reduce risk by understanding what each service does, who needs it, where it should be reachable, and what evidence confirms normal behavior.
Transport Comparison
TCP, UDP, and Network-Control Concepts
TCP
Connection-oriented communication with sequencing, acknowledgments, and reliability concepts.
Defensive use
Useful when reviewing connection state, repeated failures, resets, established sessions, and service availability.
Caution
A successful TCP connection does not prove that the application request was authorized or trustworthy.
UDP
Connectionless communication with lower overhead and no built-in delivery confirmation at the transport layer.
Defensive use
Common in services that favor speed, short requests, or application-managed reliability.
Caution
A lack of connection state does not mean the traffic is automatically suspicious.
ICMP concepts
Carries network control, status, and error information rather than normal application sessions.
Defensive use
Can help explain reachability, path, or error conditions when allowed and interpreted correctly.
Caution
One failed reachability test does not prove the destination is unavailable because controls may intentionally limit it.
Core Concept
A Connection Is More Than a Port Number
A useful defensive record includes a source address, source port, destination address, destination port, transport protocol, direction, state, time, device, user, process, zone, rule decision, service owner, and approved purpose. Missing context should reduce confidence rather than encourage a stronger claim.
Source
Where the connection began or was observed.
Destination
The system or service the traffic attempted to reach.
Protocol and ports
The transport behavior and logical service identifiers.
Context
User, process, owner, purpose, direction, state, zone, and time.
Key Vocabulary
Intermediate Service and Transport Terms
Transport protocol
A protocol that helps applications exchange data between endpoints. TCP and UDP are common examples.
Port
A numbered logical identifier used to direct network traffic to the correct application or service.
Service
A function made available by a system, application, or device, such as web access, name resolution, remote administration, or file sharing.
Source port
The port associated with the system that begins or participates in a connection. Client source ports are often temporary.
Destination port
The port associated with the service a connection is trying to reach.
Well-known port
A commonly recognized port number associated with a standard service concept.
Ephemeral port
A temporary client-side port selected for a connection rather than a permanently hosted service.
Listening service
A service waiting for incoming network requests on a specific interface, protocol, and port.
Connection state
The observed status of a connection, such as attempted, established, closed, reset, allowed, or denied.
Exposure
The degree to which a service is reachable from other devices, networks, zones, or the public internet.
Service inventory
A documented list of approved services, owners, systems, ports, protocols, purpose, exposure, and review dates.
Least functionality
The practice of enabling only the services and features required for an approved purpose.
Service Reference
Common Port and Service Concepts
Port numbers are clues, not complete conclusions. Defenders also need direction, owner, source, destination, process, encryption, identity, purpose, and change context.
Service
Web
Port concepts
80/TCP and 443/TCP concepts
Expected purpose
Browser and application access to approved web services.
Defender questions
Is HTTPS expected? Is the domain approved? Is the source group allowed? Is the certificate and application context normal?
Service
DNS
Port concepts
53/UDP and 53/TCP concepts
Expected purpose
Name-resolution requests and responses.
Defender questions
Which resolver was used? Was the domain expected? Did resolution succeed? Did a later connection occur?
Service
DHCP
Port concepts
67/UDP and 68/UDP concepts
Expected purpose
Automatic address configuration for approved devices.
Defender questions
Which scope assigned the address? Does the lease match the VLAN, subnet, device, and approved design?
Service
Secure remote administration
Port concepts
22/TCP or 3389/TCP concepts
Expected purpose
Authorized administration of approved systems through controlled pathways.
Defender questions
Who owns the service? Is remote administration required? Is access restricted, logged, protected, and time-bounded?
Service
Port concepts
25, 465, 587, 110, 143, 993, and 995 concepts
Expected purpose
Sending, receiving, and securely accessing email through approved services.
Defender questions
Which mail role is expected? Is encryption required? Is the destination an approved provider?
Service
File sharing
Port concepts
445/TCP and related concepts
Expected purpose
Authorized access to shared files or organizational resources.
Defender questions
Is the service needed between these zones? Are permissions and authentication appropriate? Is the exposure too broad?
Service Decisions
Classify the Service Before Recommending a Change
Approved and expected
The service has a documented owner, purpose, required users, protected pathway, and current review.
Approved but overexposed
The service is legitimate, but more devices, users, or zones can reach it than necessary.
Unnecessary
The service is enabled but no current approved purpose or owner can be confirmed.
Denied as designed
A control blocks traffic that is not approved across the boundary.
Review required
Evidence is incomplete, ownership is unclear, or the service behavior does not match the baseline.
Evidence Analysis
What Service Evidence Can and Cannot Prove
Evidence source
Service inventory
Can support
Approved owner, system, port, protocol, purpose, exposure, authentication requirement, and review date.
Limitation
May be outdated or incomplete unless validated against current technical evidence.
Evidence source
Firewall record
Can support
Source, destination, direction, protocol, port, zone, rule, action, and timestamp.
Limitation
Does not prove the complete application content, user intent, or service ownership.
Evidence source
Endpoint process record
Can support
Which local process, user, or application opened or received a network connection.
Limitation
Does not prove the remote service is approved or the entire network path succeeded.
Evidence source
Authentication record
Can support
Account, result, source context, time, and sometimes authentication method.
Limitation
A successful login does not prove every later action was appropriate.
Evidence source
DNS record
Can support
The name requested and the address returned during the time window.
Limitation
Does not prove that a service was reached or that its port was allowed.
Evidence source
Change record
Can support
Approved owner, reason, timing, affected service, test plan, and rollback plan.
Limitation
Does not prove the change was implemented exactly as approved.
Defensive Workflow
Review a Service in Six Steps
Name the service
Identify the application or function the traffic is expected to support.
Read the full tuple
Record source, destination, direction, protocol, source port, destination port, state, and time.
Check ownership and purpose
Compare the observed service with inventory, role, system owner, and approved business need.
Measure exposure
Determine which users, devices, zones, or networks can reach the service.
Correlate evidence
Connect firewall, endpoint, DNS, authentication, inventory, and change records.
Choose a safe action
Document, monitor, restrict, validate, or escalate through an authorized and reversible process.
Fake Dashboard
Fake Service Exposure Dashboard
Training dashboard for the fictional Northstar Research Network. It compares approved service inventory with current firewall and endpoint evidence.
Approved web services
12
All twelve have owners, HTTPS requirements, limited zones, and current review dates.
Unowned listening service
1
A fictional workstation is listening on TCP 8080 with no current owner in the inventory.
Overexposed file service
1
An approved file service is reachable from both staff and guest zones instead of staff only.
Fake SOC Alert
Unowned Service Listening After an Approved Software Test
Source: Fake Service Inventory Monitor • Time: 01:42 PM
Fake Log Panel
Fake Service and Connection Evidence Timeline
13:31:02 INVENTORY system='research-ws-14' approved_services='https-client,dns-client,file-client' 13:32:18 ENDPOINT process='training-preview.exe' user='lab-user-4' listen='0.0.0.0:8080/tcp' 13:32:25 FIREWALL source_zone='staff' destination='research-ws-14:8080' action='allow' rule='temporary-test' 13:33:09 FIREWALL source_zone='guest' destination='research-ws-14:8080' action='deny' rule='default-boundary' 13:35:42 CHANGE title='preview application test' approved='true' end_time='three_days_ago' 13:37:16 OWNER_LOOKUP service='8080/tcp' result='no_current_owner' 13:40:21 DEPENDENCY_CHECK active_clients='0' application_status='test_complete' 13:42:03 CORRELATION finding='expired temporary service remains enabled' confidence='high'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Service Conclusion Is Best Supported?
What is the strongest defensive conclusion and next action?
Common Mistakes
Mistakes That Weaken Service Analysis
Safe Practice Lab
Create a Fictional Service Inventory and Exposure Review
Fictional Environment
Harborview Digital Arts Network
The fictional network includes a web portal, DNS resolver, DHCP service, file server, remote-administration gateway, email service, and one temporary development service. Students receive a service inventory, network zones, firewall records, endpoint process evidence, and approved change records.
Required Analysis
- Identify every service, owner, system, protocol, and port.
- Record who or what should reach each service.
- Compare listening services with the approved inventory.
- Classify each service as expected, overexposed, unnecessary, denied as designed, or review required.
- Connect firewall, endpoint, DNS, authentication, and change evidence.
- Document evidence limits and uncertainty.
- Recommend authorized, reversible, and validated next actions.
Scenario Decision Lab
An Approved Service Is Reachable From the Guest Zone
A fictional file service is approved for staff use. Firewall evidence shows the staff zone and guest zone can both reach TCP 445, while the design document says guest access should be blocked.
Scenario Decision Lab
A User Connects to an Uncommon Destination Port
A fictional approved application connects outbound to TCP 8443 at a documented vendor domain. DNS, endpoint, inventory, and change records all match a scheduled update.
Defender Habits
Ports, Protocols, and Services Review Checklist
Check Your Understanding
I1.3 Mini Quiz: Ports, Protocols, and Services
Choose your answers first. Explanations appear only after submission.
1. What is the main purpose of a network port?
2. Which statement best compares TCP and UDP?
3. Why can port 443 not prove that traffic is trustworthy?
4. What is an ephemeral port?
5. What should happen when a service has no confirmed owner or purpose?
6. Which evidence best connects a local program to a network connection?
7. What is the strongest response to an approved service that is reachable from too many zones?
Portfolio Prompt
Portfolio Prompt
Create a fictional Service Inventory and Exposure Review for a small organization. Include at least eight services with owner, system, protocol, port, purpose, required users or zones, authentication requirement, logging source, current exposure, risk classification, and review date. Add one overexposed service, one expired temporary service, and one correctly denied connection. Write an evidence-based recommendation for each.
Key Takeaways
What You Should Remember
Navigation