Domain 1 of 5 · Chapter 4 of 9

Ports and Protocols

TCP vs UDP and the three port ranges

A packet reaches the right host by IP address, but it reaches the right application on that host by port number, a 16-bit value in the Layer 4 (Transport) header that ranges from 0 to 65535. The transport protocol carrying that port comes in two flavors, and N10-009 objective 1.4 expects you to pick correctly between them.

TCP: reliable, connection-oriented

TCP (Transmission Control Protocol) guarantees delivery. It opens every conversation with a three-way handshake (a SYN, a SYN-ACK, then an ACK), numbers each byte so the receiver can reorder and detect gaps, acknowledges what arrives, retransmits what does not, and closes gracefully with FIN/ACK. That bookkeeping costs round-trips and header space, but it is non-negotiable for traffic that must arrive intact: web pages (HTTPS), email (SMTP, IMAP), and file transfer (FTP, SSH) all ride TCP. See RFC 9293, the current TCP specification[1] for the handshake and reliability mechanics.

UDP: fast, connectionless

UDP (User Datagram Protocol) does almost nothing for you: no handshake, no acknowledgements, no ordering, no retransmission. A datagram is sent and forgotten. That is exactly what you want when a late packet is worse than a lost one, such as real-time voice and video, or when a single tiny request-and-reply is cheaper than building a connection, such as a DNS lookup, a DHCP discover, or a TFTP block. The contract is defined in RFC 768[2]. If a UDP application needs any reliability, it has to implement that itself above the transport.

A few services intentionally use both: DNS answers ordinary queries over UDP 53 but switches to TCP 53 for zone transfers and any response too large for a single datagram, and SIP can run over UDP or TCP on 5060.

Well-known, registered, and ephemeral

IANA, the Internet Assigned Numbers Authority, splits the 0 to 65535 space into three bands, and recognizing which band a number falls in is a recurring exam clue:

Range Name Used for
0 to 1023 Well-known (system) Core services: HTTP 80, HTTPS 443, SSH 22, DNS 53
1024 to 49151 Registered (user) Vendor-reserved apps: RDP 3389, MySQL 3306, MS SQL 1433
49152 to 65535 Dynamic / private / ephemeral The random source port a client picks for its own outbound connection

This banding, described in RFC 6335[3], explains stateful firewalls: a client browsing the web sends from an ephemeral source port to destination TCP 443, and the server's reply comes back to that ephemeral port. A stateful firewall remembers the outbound flow and permits the return automatically, where a stateless ACL would need a manual rule for the whole ephemeral range.

Port number space: 0 to 65535Well-known0 - 1023HTTP 80, SSH 22Registered1024 - 49151RDP 3389, MySQL 3306Dynamic / ephemeral49152 - 65535client source portsServer listens (destination)fixed well-known / registered portClient connects (source)random ephemeral port
IANA splits ports 0 to 65535 into well-known (0-1023), registered (1024-49151), and dynamic/ephemeral (49152-65535); servers listen on fixed ports, clients dial out from ephemeral ones.

The TCP three-way handshake and connection state

Because so many exam questions and real outages turn on whether a connection can be established, it pays to know the TCP setup exactly. The leading rule: TCP opens with a three-way handshake before any data flows, and a firewall that blocks any of the three steps blocks the whole service even though the port looks open.

The client sends a SYN (synchronize) to the server's listening port with its initial sequence number. The server replies with a SYN-ACK, acknowledging the client's sequence and adding its own. The client returns an ACK, and the connection is established; data transfer begins. When finished, either side sends FIN, the peer acknowledges, and the socket closes. This sequence, specified in RFC 9293[1], is why a telnet host 443 or an nmap SYN scan is a fast reachability test: a returned SYN-ACK proves the port is open and the path is clear.

UDP has no equivalent. A UDP service simply receives datagrams on its port, so there is nothing to handshake and nothing to tear down. This is the practical reason DHCP, DNS, and TFTP chose UDP: a one-shot request and reply does not justify a three-packet setup. It is also why scanning UDP ports is unreliable, since an open UDP port often answers with silence rather than an acknowledgement.

Why this drives firewall behavior

A stateful firewall watches the handshake, records the flow in a connection table, and automatically permits the matching return traffic to the client's ephemeral port. A stateless ACL judges each packet alone, so it needs explicit rules for both directions. The handshake is therefore the seam where most 'the port is allowed but it still will not connect' problems live: an inbound SYN permitted but the outbound SYN-ACK dropped means the connection never reaches established.

ClientServer (listening port)1. SYN2. SYN-ACK3. ACKConnection ESTABLISHEDdata flows; FIN/ACK closes it later
TCP's three-way handshake (SYN, SYN-ACK, ACK) establishes a connection before data flows; UDP has no equivalent setup.

The N10-009 port reference and secure pairings

This is the table the exam draws most of its objective 1.4 questions from. Learn the port, the transport, and the secure replacement for each cleartext service. Numbers below come from the IANA Service Name and Transport Protocol Port Number Registry[4].

Protocol Port(s) Transport What it does
FTP 20 (data), 21 (control) TCP Cleartext file transfer
SSH / SFTP / SCP 22 TCP Encrypted shell and file transfer
Telnet 23 TCP Cleartext remote shell
SMTP 25 TCP Mail relay between servers
DNS 53 TCP and UDP Name resolution (UDP queries, TCP zone transfer)
DHCP 67 (server), 68 (client) UDP Dynamic IP assignment
TFTP 69 UDP Trivial file transfer, no auth
HTTP 80 TCP Cleartext web
POP3 110 TCP Mail download (whole message)
NTP 123 UDP Time synchronization
IMAP 143 TCP Server-side mailbox access
SNMP 161 (poll), 162 (trap) UDP Device monitoring and alerts
LDAP 389 TCP Directory lookups (cleartext)
HTTPS 443 TCP TLS-encrypted web
SMB 445 TCP Windows file/print sharing
Syslog 514 UDP Log shipping to a collector
SMTP submission 587 TCP Authenticated client mail send
LDAPS 636 TCP LDAP over TLS
IMAPS 993 TCP IMAP over TLS
POP3S 995 TCP POP3 over TLS
SQL Server 1433 TCP Microsoft SQL database
MySQL 3306 TCP MySQL/MariaDB database
RDP 3389 TCP Windows remote desktop
PostgreSQL 5432 TCP PostgreSQL database
SIP 5060 (plain), 5061 (TLS) TCP and UDP VoIP session signaling

The cleartext-to-secure swaps you must memorize

The exam repeatedly asks you to replace an exposed cleartext protocol with its encrypted equivalent. The canonical pairs:

  • Telnet 23 to SSH 22. SSH (Secure Shell, RFC 4251[5]) replaces Telnet for remote administration and also carries SFTP and SCP, so one open port (22) covers shell and file transfer.
  • HTTP 80 to HTTPS 443. HTTPS wraps HTTP in TLS; the secure traffic listens on a separate port so a firewall can distinguish it.
  • FTP 20/21 to SFTP (over SSH, 22) or FTPS. SFTP is not FTP; it is a subsystem of SSH and uses no FTP ports, where FTPS is FTP wrapped in TLS.
  • LDAP 389 to LDAPS 636, POP3 110 to 995, IMAP 143 to 993, SMTP 25/587 with STARTTLS. Each directory or mail protocol has a TLS form on its own port (or, for submission, an in-band STARTTLS upgrade).
  • SNMPv1/v2c to SNMPv3. SNMP stays on UDP 161/162, but version 3 adds authentication and encryption that the earlier community-string versions lack.
CleartextEncrypted replacementTelnet (TCP 23)SSH (TCP 22)HTTP (TCP 80)HTTPS (TCP 443)FTP (TCP 20/21)SFTP (TCP 22)LDAP (TCP 389)LDAPS (TCP 636)POP3 (TCP 110)POP3S (TCP 995)IMAP (TCP 143)IMAPS (TCP 993)
Each cleartext protocol maps to an encrypted replacement on its own port: Telnet to SSH, HTTP to HTTPS, FTP to SFTP, LDAP to LDAPS, POP3 to POP3S, IMAP to IMAPS.

Exam-pattern recognition

Objective 1.4 questions are mostly recall, but the distractors are engineered around three predictable confusions. Recognizing the shape of the stem tells you what is really being tested.

The cleartext-versus-secure swap

Stem cue: a service is 'exposing credentials in plaintext' or 'must be hardened'. The answer is almost always the encrypted twin on its own port: Telnet to SSH 22, HTTP to HTTPS 443, FTP to SFTP 22, LDAP to LDAPS 636. Watch the trap of picking the same protocol on a different random port; the exam wants the named secure protocol, not HTTP-on-8443.

The TCP-versus-UDP pick

Stem cue: 'which protocol provides reliable, ordered delivery' (TCP) versus 'lowest latency for real-time voice' (UDP). The classic trick is DNS: it is the one common service that uses both, UDP 53 for queries and TCP 53 for zone transfers, so 'UDP only' is a wrong-but-tempting answer when the scenario mentions a secondary server pulling a full zone.

The single-symptom-to-port mapping

Stem cue: one application is broken while everything else works. Map the symptom to its port: mail won't send means SMTP 25/587, name resolution fails means DNS 53, clock drift breaking Kerberos means NTP 123, remote desktop refused means RDP 3389, network device monitoring stopped means SNMP 161/162. The wrong answers are usually adjacent ports in the same family (110 vs 143, 389 vs 636, 80 vs 443), so read the exact number.

Numbers that are easy to swap

The most-missed pairs are the ones one digit or one role apart: 67/68 (DHCP server vs client), 161/162 (SNMP poll vs trap), 20/21 (FTP data vs control), 5060/5061 (SIP plain vs TLS), and 993/995 (IMAPS vs POP3S). Anchor each by its role, not by rote, and the distractors stop working.

N10-009 well-known ports: service, port, transport, and what it does

Service / protocolPortTransportRole and secure pairing
FTP20 (data), 21 (control)TCPCleartext file transfer; replace with SFTP/FTPS
SSH / SFTP / SCP22TCPEncrypted remote shell and file transfer; replaces Telnet/FTP
Telnet23TCPCleartext remote shell; replace with SSH 22
SMTP25TCPServer-to-server mail relay; submission is 587
DNS53TCP and UDPName resolution; UDP for queries, TCP for zone transfers
DHCP67 (server), 68 (client)UDPDynamic IP assignment via DORA broadcast
TFTP69UDPTrivial, no-auth file transfer for boot/config images
HTTP80TCPCleartext web; replace with HTTPS 443
POP3 / IMAP110 / 143TCPMail retrieval; secure as POP3S 995 / IMAPS 993
NTP123UDPTime synchronization; drift breaks Kerberos and logs
SNMP161 (poll), 162 (trap)UDPDevice monitoring; use SNMPv3 for auth/encryption
LDAP / LDAPS389 / 636TCPDirectory lookups; LDAPS adds TLS
HTTPS443TCPTLS-encrypted web; secure replacement for HTTP
SMB445TCPWindows file/print sharing; never expose to the internet
Syslog514UDPCentralized log shipping to a collector
SMTP submission587TCPAuthenticated client mail send with STARTTLS
RDP3389TCPWindows remote desktop; tunnel or VPN, never open raw
SIP5060 / 5061TCP and UDPVoIP signaling; 5061 is SIP over TLS

Decision tree

Need guaranteed, ordered delivery?file, web, mail, loginYes: use TCPNo: use UDPEncrypted variant available?harden cleartext servicesUDP real-time / one-shotVoIP, DHCP 67/68, TFTP 69SNMP 161/162, NTP 123, syslog 514YesNoUse the secure portSSH 22, HTTPS 443SFTP 22, LDAPS 636IMAPS 993, POP3S 995Cleartext TCP portHTTP 80, FTP 20/21Telnet 23, SMTP 25avoid on untrusted linksService uses BOTH transports?the DNS / SIP exceptionSpecial caseDNS 53 UDP query, TCP zone transfer; SIP 5060 UDP/TCPnever answer 'UDP only' for DNS

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A port number plus a transport protocol identifies one service

A 16-bit port number (0 to 65535) sits in the Layer 4 header and tells the receiving host which application a packet belongs to, while the IP address in the Layer 3 header only gets the packet to the host. The full tuple of source IP, destination IP, source port, and destination port pins one conversation to one application, which is why a firewall rule, a packet capture, and an exam stem all key off the destination port. Knowing the well-known port for each service is the core of N10-009 objective 1.4.

1 question tests this
Choose TCP when delivery must be guaranteed

TCP is connection-oriented: it opens with a three-way handshake, numbers bytes so they can be reordered, acknowledges and retransmits losses, and closes with FIN, so anything that must arrive intact rides it. Web (HTTPS 443), email (SMTP 25, IMAP 143), file transfer (FTP 21, SSH/SFTP 22), and remote desktop (RDP 3389) are all TCP. Reach for UDP instead only when the overhead of that reliability would hurt more than an occasional lost packet.

Trap Assuming TCP is always the safer default; for real-time voice or video the retransmission and ordering add latency that degrades the call, where UDP's drop-and-continue behavior is actually correct.

Choose UDP for real-time or one-shot traffic

UDP is connectionless with no handshake, acknowledgements, or retransmission, which makes it lighter and lower-latency. It fits streaming voice and video, plus single request-and-reply services where building a connection is wasteful: DNS queries (53), DHCP (67/68), TFTP (69), SNMP (161/162), NTP (123), and syslog (514) are all UDP. Any reliability UDP needs must be added by the application itself.

Ports split into well-known, registered, and ephemeral bands

IANA divides the 0 to 65535 space into three ranges: well-known ports 0 to 1023 for core system services (HTTP 80, SSH 22), registered ports 1024 to 49151 for vendor applications (RDP 3389, MySQL 3306), and dynamic or ephemeral ports 49152 to 65535 that a client picks at random for the source side of an outbound connection. A server listens on a fixed low port; the client dials out from an ephemeral one, and the server replies to that ephemeral port.

Trap Treating the ephemeral range as something the firewall must open inbound; a stateful firewall tracks the outbound flow and permits the return automatically, so no manual ephemeral-range rule is needed.

DNS uses both UDP 53 and TCP 53

DNS is the classic dual-transport service: it answers ordinary name queries over UDP 53 for speed, but switches to TCP 53 for zone transfers between servers and for any response too large to fit a single UDP datagram. On the exam, a scenario about a secondary server pulling a full zone is testing TCP 53, so 'UDP only' is the wrong-but-tempting answer.

Trap Answering 'DNS uses UDP only'; zone transfers and oversized responses use TCP 53, which a question about secondary-server replication is specifically probing.

Telnet 23 is cleartext; replace it with SSH 22

Telnet (TCP 23) carries the entire remote-administration session, credentials included, in plaintext, so it must be replaced with SSH (Secure Shell, TCP 22). SSH encrypts the session and also carries SFTP and SCP, so one open port (22) covers encrypted shell and file transfer. When a stem says a management protocol is 'exposing credentials', the answer is SSH 22.

Trap Picking the same insecure protocol on a non-standard port (Telnet on 2323); changing the port does not encrypt the traffic, and the exam wants the named secure protocol, SSH.

5 questions test this
HTTP 80 becomes HTTPS 443 with TLS

HTTP (TCP 80) serves web traffic in cleartext; HTTPS (TCP 443) wraps the same HTTP in TLS and listens on its own distinct port so a firewall or analyzer can tell secure from insecure web by port alone. Sending to 443 does not by itself encrypt anything unless TLS is actually negotiated, but the standard secure-web answer is always HTTPS 443.

3 questions test this
FTP uses 20 and 21; SFTP rides SSH on 22

FTP uses TCP 21 for the control channel and TCP 20 for the data channel, both cleartext. Its secure replacement SFTP is not FTP at all: it is a subsystem of SSH and runs over TCP 22 with no FTP ports, while FTPS is a different beast that wraps FTP in TLS. Confusing SFTP with FTPS, or expecting SFTP on port 21, is a common error.

Trap Assuming SFTP uses an FTP port like 21 or 22 as 'FTP over TLS'; SFTP is SSH File Transfer Protocol on TCP 22, whereas FTPS is the TLS-wrapped FTP variant.

6 questions test this
SMTP relays on 25; clients submit authenticated mail on 587

SMTP (TCP 25) moves mail between mail servers (server-to-server relay), while TCP 587 is the submission port a mail client uses to send authenticated outbound mail, typically upgrading to encryption with STARTTLS. Many providers block outbound 25 from clients to fight spam, so a user whose mail will not send is usually pointed at 587. Port 465 was historically SMTPS but the exam centers on 25 and 587.

Trap Assuming sending to 587 is automatically encrypted; submission still needs STARTTLS to negotiate TLS, otherwise the session stays in cleartext.

3 questions test this
POP3 110 and IMAP 143 secure to 995 and 993

POP3 (TCP 110) downloads mail and typically removes it from the server, while IMAP (TCP 143) keeps mail server-side and syncs folder state across devices. Their TLS-encrypted forms are POP3S on TCP 995 and IMAPS on TCP 993. The 993-versus-995 pair is a favorite distractor because the numbers are adjacent and the roles are easy to swap.

Trap Swapping the secure ports, calling IMAPS 995 and POP3S 993; IMAPS is 993 and POP3S is 995, anchored to their cleartext parents 143 and 110.

DHCP uses UDP 67 on the server and 68 on the client

DHCP assigns IP configuration dynamically over UDP, with the server on port 67 and the client on port 68. The handshake follows the DORA sequence (Discover, Offer, Request, Acknowledge), and the initial Discover is a broadcast because the client has no address yet. Reversing 67 and 68 is a classic trap, so anchor 67 to the server.

Trap Putting the DHCP server on 68 and the client on 67; the server listens on UDP 67 and the client on UDP 68, not the reverse.

4 questions test this
SNMP polls on UDP 161 and receives traps on UDP 162

SNMP monitors devices over UDP: the manager polls agents on port 161 (get/set requests), and agents push asynchronous alerts to the manager on port 162 (traps). Versions 1 and 2c authenticate only with a cleartext community string, so SNMPv3 is the secure choice because it adds authentication and encryption while staying on the same 161/162 ports.

Trap Believing SNMPv3 moves to a new port for security; v3 keeps UDP 161/162 and gains its protection from the protocol version, not a port change.

4 questions test this
NTP synchronizes clocks on UDP 123

NTP keeps device clocks in sync over UDP 123, and accurate time is load-bearing far beyond cosmetics: Kerberos authentication rejects tickets when clocks drift past about five minutes, log correlation across devices breaks, and certificate validity windows misfire. A stem about authentication failing org-wide or logs that will not line up is often really an NTP 123 problem.

LDAP queries on 389; LDAPS adds TLS on 636

LDAP reads and writes directory data (users, groups, computers) over TCP 389 in cleartext, and LDAPS wraps the same protocol in TLS on TCP 636. Directory binds carry credentials, so production directory traffic should use 636. The 389-to-636 pairing is the directory analogue of HTTP-to-HTTPS.

6 questions test this
SMB shares files on TCP 445 and must not face the internet

SMB provides Windows file and printer sharing over TCP 445 (modern, direct over TCP/IP; the legacy NetBIOS path used 137 to 139). SMB has a long history of wormable vulnerabilities, so port 445 should be blocked at the perimeter and confined to the internal LAN. A scenario about ransomware spreading laterally often hinges on open SMB 445.

Trap Exposing SMB 445 across a WAN or to the internet for remote file access; it belongs on the trusted LAN, and remote access should go through a VPN instead.

RDP is TCP 3389 and should never be open raw to the internet

Remote Desktop Protocol gives graphical Windows remote control over TCP 3389. Because it is a high-value target for brute force and exploitation, it should be reached through a VPN or a jump host rather than exposed directly. A stem describing a refused remote-desktop session points at 3389, and one describing a hardening fix points at tunneling it.

4 questions test this
SIP signals VoIP calls on 5060, with TLS on 5061

SIP sets up, modifies, and tears down VoIP calls on port 5060 (plaintext, over UDP or TCP), with SIP over TLS on 5061. SIP only handles the signaling; the actual media stream rides RTP on a separately negotiated UDP port range. A call that connects but has no audio is a media (RTP) problem, not a SIP 5060 signaling problem.

Trap Treating no-audio-on-an-otherwise-connected-call as a SIP 5060 failure; signaling succeeded, so the fault is in the RTP media path, not the SIP port.

5 questions test this
TFTP is UDP 69 with no authentication

TFTP (Trivial File Transfer Protocol) moves files over UDP 69 with no authentication and no encryption, which is why it is used only on trusted links for tasks like pushing firmware images, loading switch and router configs, or PXE network boot. Its full-featured, authenticated counterpart is FTP or SFTP; TFTP trades every feature for simplicity.

Syslog ships logs to a collector on UDP 514

Syslog centralizes event and log messages to a collector over UDP 514, the standard way devices feed a central log server or SIEM. Plain UDP syslog is fire-and-forget with no delivery guarantee, so high-assurance deployments may run it over TCP or TLS instead, but the exam default is UDP 514.

1 question tests this
Database services use 1433, 3306, and 5432

The common database ports N10-009 references are Microsoft SQL Server on TCP 1433, MySQL/MariaDB on TCP 3306, and PostgreSQL on TCP 5432, all in the registered range. These should be reachable only from application tiers, never exposed to the internet. They are easy to confuse with one another, so anchor each to its engine.

A port is a convention, not enforcement

Default ports are agreements, not guarantees: an administrator can run HTTPS on 8443 or SSH on 2222, and malware can listen on any free port. The exam tests the standard assignments, but real defense cannot trust a port alone, which is why deep packet inspection and application-aware firewalls look at content rather than just the port number.

Trap Assuming traffic on TCP 443 must be legitimate HTTPS; the port is only a label, and a stateful or next-gen firewall is needed to confirm what is actually riding it.

References

  1. RFC 9293 — Transmission Control Protocol (TCP) Whitepaper
  2. RFC 768 — User Datagram Protocol (UDP) Whitepaper
  3. RFC 6335 — IANA Procedures and Port Number Ranges (Service Name and Transport Protocol Port Number Registry) Whitepaper
  4. Service Name and Transport Protocol Port Number Registry
  5. RFC 4251 — The Secure Shell (SSH) Protocol Architecture Whitepaper