Now that you understand what an IP address is, we need to answer the next question: once your computer finds another computer, how the hell does it know which program it wants to talk to? A server might be hosting a website, accepting SSH connections, running a database, receiving email, and doing a dozen other things at the same time. They can all live behind the same IP address. Ports are part of how the operating system keeps those conversations separated.
Think of the IP address as the address of an apartment building. Something like 192.168.1.50 gets you to the building, but that's not enough. You still need to know which apartment you're trying to reach. That's where the port number comes in. You might connect to 192.168.1.50 on port 22 for SSH or port 443 for HTTPS. Same machine. Same IP. Completely different services.
Ports are numbered from 0 through 65535. You'll commonly hear them divided into three groups. Ports 0–1023 are called well-known ports, 1024–49151 are registered ports, and 49152–65535 are generally dynamic or ephemeral ports. Don't waste your first week trying to memorize 65,536 numbers. You only need to start recognizing the ones you'll encounter constantly.
Some common ones are 22 for SSH, 25 for SMTP, 53 for DNS, 80 for HTTP, 443 for HTTPS, and 3389 for RDP. You'll also frequently encounter ports associated with databases, such as 3306 for MySQL and 5432 for PostgreSQL. These are conventions, not guarantees. SSH can run on port 5000. A web application can run on 8080. Seeing an open port gives you a clue about what might be there; it doesn't magically prove which software is running.
That brings us to protocols. A protocol is basically a set of rules that computers agree to use when communicating. HTTP defines how web clients and servers exchange web requests and responses. DNS defines mechanisms for resolving names. SSH provides a protocol for secure remote access. TCP and UDP provide different transport mechanisms used by many higher-level protocols.
You'll hear TCP constantly in security. TCP is connection-oriented. Before application data is exchanged, two systems normally establish a connection using what's called the three-way handshake. The client sends SYN. The server responds SYN-ACK. The client responds ACK. Think of it like, “Can we talk?” — “Yep, ready.” — “Cool, let's go.”
UDP works differently. There isn't an equivalent TCP-style connection handshake before sending data. A host can simply send a UDP datagram toward another host. That makes UDP useful for situations where low overhead or speed matters, but it also means scanning and troubleshooting UDP can behave differently from TCP. DNS commonly uses UDP for ordinary queries, although DNS can use TCP too.
Here's where this starts connecting directly to cybersecurity. When you're examining a machine you own or an authorized lab target, one of the first questions is often: what ports are listening? A listening port can indicate that some network-accessible service is waiting for connections. If port 22 is listening, maybe there's an SSH server. If 80 or 443 is listening, there's probably something web-related worth investigating.
On your own Linux machine, run:
ss -tuln
You're asking Linux to show you listening TCP and UDP sockets numerically. Depending on what's running, you might see something like:
That 0.0.0.0 part matters. It generally means the service is bound to all available IPv4 interfaces rather than only one specific address. Compare that with:
Remember 127.0.0.1 from Lesson 2? That's loopback. A service listening only there normally isn't directly reachable from another computer on your network. This is exactly why learning networking before learning scanners matters. You're already starting to understand what scanner results actually represent.
Now let's introduce Nmap, but we're keeping it inside your own machine or a lab you have permission to test. Start with:
nmap 127.0.0.1
Nmap will probe your local machine and report ports it discovers. You might see something like:
22/tcp open ssh
Read that from left to right. Port 22. Transport protocol TCP. State open. Nmap associates the port with ssh. Four pieces of information packed into one tiny line.
There's another distinction beginners need to understand: open, closed, and filtered aren't interchangeable. An open port generally means something is accepting connections there. A closed port indicates the host is reachable but nothing is listening on that port. Filtered generally means Nmap can't determine the port's state because something such as a firewall is interfering with the probes or responses.
This is where you need to kill a bad beginner habit early: an open port is not automatically a vulnerability. Port 22 being open doesn't mean you “found a hack.” An organization may intentionally expose SSH and have it properly patched, hardened, authenticated with keys, monitored, rate-limited, and restricted by network controls. Enumeration is about gathering evidence before drawing conclusions.
Build yourself a tiny local service so you can actually watch this happen. If Python is installed, go into a directory containing nothing sensitive and run:
python3 -m http.server 8000 --bind 127.0.0.1
You just started a simple HTTP server listening on port 8000 on your own loopback interface. Open another terminal and run:
ss -tln
You should now see something listening around 127.0.0.1:8000.
Now run:
nmap -p 8000 127.0.0.1
Nmap should detect that the port is open. Stop the Python server with Ctrl+C, run the scan again, and compare the result. That's a much better beginner exercise than copying twenty Nmap switches from some tutorial. You created a service, observed its socket, scanned it, killed it, and observed how the network state changed.
Now the pieces from the first three lessons should start connecting. DNS can help translate a hostname into an IP address. The IP identifies a host or network interface. Ports help identify network conversations and services. Protocols define how those systems communicate. A security tool like Nmap helps you observe pieces of that environment.
Eventually you'll look at an authorized lab machine and see something like 22/tcp open ssh, 80/tcp open http, and 3306/tcp open mysql. Your brain should immediately start forming questions instead of reaching for exploits. What SSH implementation is running? What's being served over HTTP? Is the database intentionally network-accessible? Are those services supposed to be exposed? What versions and configurations are present?
That's the beginning of enumeration, and enumeration is where a lot of real security work happens.
For now, get comfortable with ss, ping, and basic Nmap scans against your own systems or intentionally vulnerable labs. Understand what you're looking at before worrying about breaking anything.
Source: r/DaemoncoreAcademy · by /u/ChameleonCRM