Skip to content
Lesson 2 of 8

How Networks Work

11 min read

Why a Security Professional Needs to Understand Networks

You cannot protect what you do not understand. The vast majority of attacks —from initial scanning to data exfiltration— travel across the network. Understanding how devices communicate lets you recognize what is normal traffic and what is suspicious, where to place defenses, and how attackers think when probing a target.

A network is, in essence, a set of devices that exchange data following common rules called protocols. When you open a web page, your browser and the remote server carry out a carefully choreographed conversation of protocols stacked on top of one another. Understanding that stack is the first step toward defense.

A protocol is nothing more than an agreed-upon language. Just as two people need to speak the same language to understand each other, two computers need to use the same protocol to exchange data. The remarkable thing about the Internet is that it works because millions of devices from different manufacturers, in different countries, honor exactly the same agreements: the open standards we will walk through in this lesson.

For defensive work, this knowledge translates into concrete questions: which of my organization's services are exposed to the Internet? What traffic is expected between these two machines? Why is this accounting workstation talking to a server on another continent at 3 a.m.? Without networking fundamentals, those questions cannot even be asked.

IP Addresses: Identity on the Network

Every device connected to a network has an IP address (Internet Protocol) that uniquely identifies it within that network. In IPv4, this address takes the form of four numbers separated by dots, such as 192.168.1.10, where each number ranges from 0 to 255. Because IPv4 addresses ran out, today it coexists with IPv6, which uses much longer addresses in hexadecimal format, such as 2001:db8::8a2e:370:7334.

There are public addresses, routable on the Internet, and private addresses that only work within local networks. The private ranges are defined by standard and are worth memorizing, because they show up constantly:

| Private range | Typical example | Where you will see it | |---|---|---| | 10.0.0.0 to 10.255.255.255 | 10.0.5.20 | Large corporate networks | | 172.16.0.0 to 172.31.255.255 | 172.16.1.5 | Mid-sized networks, cloud environments | | 192.168.0.0 to 192.168.255.255 | 192.168.1.10 | Homes and small offices |

The NAT (Network Address Translation) technique lets many private devices share a single public address. It is what your home or office router does: inward, each machine has its private IP; toward the Internet, they all go out through the same public IP. That is why, when a small business says "the IP changed and the system stopped working," they almost always mean the public IP assigned by the Internet provider.

You can see your own machine's network configuration with a command. On Windows:

ipconfig /all

On Linux or macOS:

ip addr        # Linux
ifconfig       # macOS and older Linux

Look for three pieces of data: your private IP address, the subnet mask (which defines the size of your local network), and the default gateway (the router all your traffic goes through). To verify connectivity with another machine you use ping, and to see the route packets take to a destination, tracert on Windows or traceroute on Linux:

ping 192.168.1.1
tracert example.com

For an attacker, discovering an organization's address range is one of the first steps of reconnaissance. For a defender, knowing your own range is the prerequisite for inventorying what is connected — a device nobody registered is a device nobody protects.

Ports and the TCP/IP Model

If the IP address identifies the device, ports identify the specific service within that device. A server can run many services at once: a website on port 443 (HTTPS), mail on 25 (SMTP), remote SSH access on 22. There are 65,535 ports, and the first 1,024 are known as "well-known" ports because they are reserved for standard services.

A useful analogy: the IP address is the building's street address, and the port is the apartment number. The mail carrier (the network) needs both to deliver the package to the right person. These are the ports you will encounter most often:

| Port | Service | What it is for | Security note | |---|---|---|---| | 22 | SSH | Encrypted remote administration | A constant target of brute-force attacks | | 25 | SMTP | Sending email | Abused for spam when misconfigured | | 53 | DNS | Name resolution | Should be monitored: abused for tunneling | | 80 | HTTP | Unencrypted web | Content travels readable; today it should redirect to HTTPS | | 443 | HTTPS | Encrypted web | The current standard for every website | | 3389 | RDP | Windows remote desktop | Should never be exposed directly to the Internet | | 445 | SMB | Windows file sharing | A historic vector for worms and ransomware |

The TCP/IP model organizes communication into layers, each with its own responsibility: the network access layer moves bits over the physical medium (cable, Wi-Fi); the Internet layer routes packets between networks using IP addresses; the transport layer delivers data to the correct process using ports; and the application layer contains the protocols programs use (HTTP, DNS, SMTP). When you send data, each layer adds its own "label" (encapsulation); when it arrives, each layer removes it in reverse order.

At the transport layer two key protocols coexist: TCP (Transmission Control Protocol), connection-oriented and reliable, which guarantees that data arrives complete and in order through a setup process called the three-way handshake (SYN, SYN-ACK, ACK); and UDP (User Datagram Protocol), faster but without guarantees, used by services such as streaming or DNS.

| Characteristic | TCP | UDP | |---|---|---| | Connection | Connection-oriented (handshake first) | Connectionless: send and done | | Reliability | Guarantees complete, in-order delivery | No delivery or ordering guarantees | | Speed | Higher overhead | Minimal overhead, faster | | Typical uses | Web, email, file transfer | Streaming, video calls, games, DNS |

Understanding ports and protocols is essential because a service exposed on an open port is a potential entry point. You can see which connections your own machine has open right now:

netstat -an

Each line shows a local address, a remote address, and a state (LISTENING means a service is waiting for connections on that port). Tools like Nmap (nmap -sV 192.168.1.10) let you scan which ports are open and which services run behind them —something both defenders do to audit and attackers do to map targets. Important: only scan machines you own or have explicit authorization for; scanning other people's networks without permission is illegal in most jurisdictions.

DNS: the Phone Book of the Internet

People remember names like example.com, but machines communicate by IP addresses. DNS (Domain Name System) is the system that translates domain names into IP addresses. When you type a URL, your machine queries a DNS server that responds with the corresponding IP, and only then is the real connection established.

The full process is a chain of queries: your machine first checks its local cache; if it does not have the answer, it asks the resolver (usually your Internet provider's, or a public one like 1.1.1.1 or 8.8.8.8); if the resolver does not have it either, it walks the hierarchy: the root servers point to whoever handles .com, the .com servers point to whoever handles example.com, and that domain's authoritative server finally hands over the IP. All of this happens in milliseconds, and answers are cached so the journey is not repeated.

You can run these queries yourself with nslookup:

nslookup example.com
nslookup example.com 1.1.1.1   # query using a specific DNS server

On Linux and macOS there is also dig, which shows more detail:

dig example.com
dig MX example.com   # query the domain's mail servers

DNS stores several record types, and recognizing them helps with both administration and investigation:

| Record | What it contains | Example use | |---|---|---| | A | The IPv4 address for a name | example.com → 93.184.216.34 | | AAAA | The IPv6 address for a name | The modern equivalent of the A record | | MX | The domain's mail servers | Where emails get delivered | | CNAME | An alias pointing to another name | www.example.com → example.com | | TXT | Arbitrary text | Domain verification, anti-spam policies (SPF) |

DNS is so central that it has become a frequent target. Attacks such as DNS spoofing or cache poisoning redirect victims to malicious servers without their noticing: the victim types their bank's correct name but ends up on a fake copy. DNS tunneling, in turn, abuses DNS queries to smuggle data out of a network covertly, taking advantage of the fact that almost no firewall blocks port 53. That is why monitoring DNS traffic is a valuable defensive practice: newly registered domains, unusually long queries, or abnormal volumes are often the first signs of an intrusion.

From the Network to Security

With these fundamentals, you can already see the network as a map of possible attack paths and control points. A firewall filters traffic based on IPs and ports; an intrusion detection system (IDS) analyzes suspicious patterns; network segmentation limits how far an attacker can move once inside.

Segmentation deserves special mention because it is one of the most cost-effective defenses: it means dividing the network into zones by function —servers, workstations, guest network, cameras and IoT devices— and controlling traffic between zones. If a salesperson's laptop gets infected, segmentation keeps the malware from reaching the billing server directly. You already know the household version of this: the Wi-Fi "guest" network, separated from your personal devices.

This mental map also explains the principle of reducing the attack surface: every open port, every exposed service, and every permissive firewall rule is one more path to defend. The quintessential defensive question is simple: "does this really need to be exposed?"

Exercise: Follow the Trail of a Web Visit

You can observe all this machinery with the tools you have already seen, without installing anything. Open a terminal and reconstruct, step by step, what happens when you visit a site:

  1. Resolve the name: nslookup example.com — write down the IP address the response returns.
  2. Check the path: tracert example.com (or traceroute on Linux/macOS) — count how many hops separate your machine from the server, and notice at which point the traffic leaves your local network (the first addresses will be private; the following ones, public).
  3. Open the site in your browser and immediately run netstat -an — look for a connection to that IP on port 443, in the ESTABLISHED state.
  4. Interpret the whole scene: your machine queried DNS (port 53, normally UDP), established a TCP connection with its handshake to the server's port 443, and is now exchanging encrypted data over HTTPS.

That journey —name, IP, route, port, connection— is exactly the same one a professional analyzes when investigating suspicious traffic; the only difference is the intent behind the question.

Common Mistakes

  • Exposing administration services to the Internet: RDP (3389) or admin panels reachable from anywhere are among the most exploited intrusion vectors. If remote access is needed, it should go through a VPN or, at minimum, require MFA.
  • Confusing public and private IPs: reporting the private IP (192.168.x.x) when a provider asks for "your IP" — that address only makes sense inside your local network.
  • Forgetting that what is not inventoried is not protected: printers, cameras, and IoT devices also have IPs and open ports, and they usually fall outside every security plan.
  • Assuming DNS "just works": using the default DNS with no filtering wastes a cheap defensive layer; filtering resolvers block known malicious domains before the connection is ever established.
  • Scanning without authorization: running Nmap against other people's networks "for practice" can be a crime. Practice on your own network or in labs designed for it.

Key Takeaways

  • The IP address identifies the device; the port identifies the service within the device. Together they define where each connection goes.
  • Private ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x) are not routable on the Internet; NAT lets them share a public IP.
  • TCP offers reliable delivery with a handshake; UDP offers speed without guarantees. Each has its place.
  • DNS translates names to IPs and is both an attack target (spoofing, tunneling) and a valuable source of defensive signals.
  • Commands to start exploring: ipconfig, ping, tracert, netstat -an, nslookup.
  • Every exposed service is attack surface: the key question is always "does this need to be reachable?"

In the following lessons we will apply this knowledge by studying concrete threats and how they take advantage of network services, as well as the cryptographic tools that protect information while it travels through these channels.