The ports and protocols you have to know cold, and how to learn them once

Why this matters

This is the only part of Core 1 that is straight memorisation, and candidates either accept that early and get the marks, or resent it and lose them. There is no technique that removes the need to know that 3389 is remote desktop.

But the memorisation is smaller than it looks, and it is far easier when the list is organised by what the service does rather than alphabetically or numerically. Ports come in families: a plain protocol and its encrypted successor, a client port and a server port, a query port and a transfer port. Learning the families costs about a third of what learning the list costs.

The practical payoff outlives the exam. A port number is how a firewall rule, a scan result and a connection log all describe a service. A technician who reads 445 and thinks "file sharing" is reading the evidence; one who does not is guessing.

The lesson

Why the exam asks for port numbers: they are how a firewall rule describes a service

A firewall does not know what an application is. It sees an address, a protocol and a port, and its rules are written in exactly those terms. The same is true of a router's forwarding table, a scan result, a connection listing on a host, and most network logs.

So "which port must be open" is not trivia. It is the form that every practical question about network access takes:

• A user cannot reach an internal web application: which port should be permitted through the firewall?
• A remote desktop connection fails from outside the office: what forwarding rule does the router need?
• A scan shows an unexpected open port: what service is listening?

Each of those is unanswerable without the mapping, and each is answerable immediately with it. That is the whole argument for memorising the list.

The list worth memorising, grouped by what each service is actually for

Naming and addressing

• 53 DNS — name resolution, over UDP for queries and TCP for larger responses and zone transfers.
• 67 and 68 DHCP — server and client, over UDP.

Remote access and management

• 22 SSH — encrypted shell, and also the transport for SFTP and SCP.
• 23 Telnet — unencrypted shell. Present on the exam so you can identify it as the wrong answer.
• 3389 RDP — Microsoft's remote desktop protocol.
• 161 and 162 SNMP — management queries and traps.

Web

• 80 HTTP and 443 HTTPS.

Mail

• 25 SMTP for server-to-server transfer, 587 for authenticated submission, 465 for implicit TLS submission.
• 110 POP3 and 995 POP3 over TLS.
• 143 IMAP and 993 IMAP over TLS.

File transfer and sharing

• 20 and 21 FTP — data and control.
• 445 SMB — Windows file and printer sharing.
• 427 SLP and 548 AFP — Apple filing.
• 69 TFTP — trivial file transfer, over UDP, used by network devices for firmware and configuration.

Directory and authentication

• 389 LDAP and 636 LDAPS.

Databases and remote services

• 1433 SQL Server, 3306 MySQL.

That is the whole examinable set, and it is around two dozen numbers.

Secure and insecure pairs, and why the insecure one still exists

Several services appear twice: once as originally designed, once wrapped in TLS. The pairs are the easiest part of the list to learn because each pair is one fact plus a rule.

• HTTP 80 / HTTPS 443
• POP3 110 / 995
• IMAP 143 / 993
• LDAP 389 / LDAPS 636
• FTP 21 / and the secure alternatives, which are SFTP over SSH on 22 and FTPS using TLS
• Telnet 23 / SSH 22

The insecure versions persist for three reasons, and the exam expects you to recognise all three as explanations rather than justifications: legacy equipment that cannot be upgraded, internal traffic where somebody decided the risk was acceptable, and protocols where the plain port is still used for the initial connection before an upgrade to encryption.

When a scenario offers both, the encrypted one is the answer unless the scenario explicitly rules it out. When a scenario reports plain-text credentials on the network, the cause is one of the left-hand column.

Reading a connection attempt and naming the service from the port alone

The practical skill is turning a line of evidence into a sentence. A connection record has a source address and port, a destination address and port, and a protocol. The destination port names the service; the source port is ephemeral and carries no meaning.

Worked examples of the reasoning:

• 10.0.0.5:51234 -> 10.0.0.20:445 TCP — a workstation reaching a file share. Normal inside a network, alarming across an internet boundary.
• 10.0.0.5:49876 -> 8.8.8.8:53 UDP — a DNS query to an external resolver. Worth noticing if the organisation runs its own resolvers.
• 203.0.113.9:40000 -> 10.0.0.20:3389 TCP — an external host reaching remote desktop. This is the shape of a real-world incident.
• 10.0.0.5:52000 -> 10.0.0.1:161 UDP — an SNMP query to the gateway.

Reading in this direction — evidence to service — is what the exam is testing when it presents a log excerpt, and it is the same skill a technician uses when a firewall blocks something and nobody can say what.

Proving a port is open, closed or filtered from the machine in front of you

Knowing the number is half of it; the other half is testing. Three states, and they are distinguishable:

• Open — something is listening and accepted the connection.
• Closed — the host is reachable and actively refused. You get an answer.
• Filtered — nothing came back at all. A firewall dropped it silently.

The distinction matters because "refused" proves the host is up and the network path works, while "timed out" proves nothing about either. That is one of the most useful single facts in network troubleshooting and it returns in lesson 40.

Tools available on an ordinary machine:

• A telnet client or nc to a specific port: connects, refuses, or hangs.
• PowerShell's Test-NetConnection with a port, which reports success or failure and the route taken.
• The host's own listening port list, which answers "is this machine serving that port" rather than "can I reach it".
• A port scanner, on networks you are authorised to scan — and only there.

The order that saves time: check whether the service is listening locally before investigating the network, because a service that is not running produces exactly the same user-visible symptom as a blocked port.