Networking basics for security: IP addresses, ports and protocols from a defender's view

Almost every security conversation eventually becomes a networking conversation. Which ports are open? Can this database be reached from the internet? Why does the scanner say the server speaks an old protocol? If the network layer is a black box to you, those questions are hard to answer, and it is easy to accept a risky default because you cannot see it.

This part of the series covers the networking basics a developer needs to reason about exposure. It is not a networking course; it is the minimum vocabulary and the few commands that let you check your own systems. In part 1 we framed security as protecting confidentiality, integrity and availability. Here we look at the paths through which those properties are attacked.

Addresses: who is talking

IP addresses

An IP address identifies a network interface at the logical level, and it is what routers use to move packets between networks.

• IPv4 addresses are 32 bits, written as four numbers, such as 192.0.2.10.
• IPv6 addresses are 128 bits, written in hexadecimal groups, such as 2001:db8::10.

From a security perspective, three ranges matter most:

A frequent mistake is treating private addresses as safe. An attacker who compromises one machine in your network, or a misconfigured VPN, sees everything on the private range. Defence in depth means services still authenticate, even internally.

IPv6 deserves a specific warning: many hosts get a global IPv6 address automatically. A firewall configured only for IPv4 can leave a service fully reachable over IPv6. Always check both.

MAC addresses

A MAC address is the hardware address of a network interface, such as 00:1a:2b:3c:4d:5e. It is used only inside one local network segment; routers do not forward it. MAC addresses can be changed in software, so they are not a reliable form of identity. Allow-listing devices by MAC on a Wi-Fi network is a convenience, not a security control.

Ports: which service is answering

An IP address gets a packet to a host. A port number, from 0 to 65535, gets it to a specific program on that host. A server process "listens" on a port, and a client connects to that port.

Ports below 1024 are traditionally privileged and assigned to well-known services. The ones you will see in almost every scan report:

The rule of thumb: every open port is a door. Each one should have an owner, a reason to exist and an access rule. Databases, caches and admin panels belong on private networks or loopback.

TCP and UDP: how they talk

Most traffic uses one of two transport protocols.

TCP is connection-oriented. Client and server perform a three-way handshake (SYN, SYN-ACK, ACK) before any data flows, and TCP guarantees ordered, reliable delivery. HTTP, SSH and database protocols use TCP. Because of the handshake, the source address of an established TCP connection is hard to fake.

UDP is connectionless. Packets are sent without a handshake and may arrive out of order or not at all. DNS, video calls and many games use UDP. Because there is no handshake, the source address of a UDP packet can be spoofed easily. This is why UDP services such as open DNS resolvers are abused for reflection and amplification attacks: a small spoofed request makes the server send a large reply to the victim.

Protocols above the transport: plain text versus encrypted

Many older protocols send data, including passwords, as plain text: Telnet, FTP, HTTP, SMTP without TLS, and some database connections. Anyone on the network path can read them. The modern replacements wrap the same conversation in TLS or use a secure design from the start: SSH instead of Telnet, SFTP instead of FTP, HTTPS instead of HTTP.

When a report says a service "supports TLS 1.0" or "allows plain-text authentication", it is a confidentiality and integrity problem: someone in the middle could read or change the traffic.

Seeing your own exposure

You do not need special tools to start. On a Linux host, list every socket in the listening state with the owning process:

sudo ss -tulpn

Example output, trimmed:

Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=812))
tcp   LISTEN 127.0.0.1:5432      users:(("postgres",pid=1044))
tcp   LISTEN 0.0.0.0:6379        users:(("redis-server",pid=1210))
tcp   LISTEN [::]:443            users:(("nginx",pid=930))

How to read it:

• 127.0.0.1:5432 means PostgreSQL only accepts connections from the same host. Good.
• 0.0.0.0:6379 means Redis listens on every IPv4 interface. Unless a firewall blocks it, any machine that can reach this host can talk to Redis. This line deserves a ticket.
• [::]:443 means nginx listens on every IPv6 interface, which is expected for a web server.

Listening is only half of the picture; firewalls and cloud security groups decide what can actually reach the port. To check from the outside, run a scan against hosts you own, from a machine outside the network:

nmap -Pn -p 1-1024,3306,5432,6379,9200 203.0.113.25

Only scan systems you own or have written permission to test. Unauthorised scanning can break terms of service and, in many countries, the law.

A short checklist

• Every listening port has an owner and a documented reason.
• Databases, caches, queues and admin interfaces bind to loopback or private interfaces only.
• Firewall or security group rules exist for both IPv4 and IPv6.
• Plain-text protocols are replaced or wrapped in TLS.
• Internal services still require authentication; the private network is not a trust boundary.
• An external scan of your public addresses runs on a schedule, and new open ports raise an alert.

Key takeaways

• IP addresses route packets between networks; MAC addresses only matter inside one segment and can be spoofed.
• Ports identify services, and each open port is attack surface that needs an owner.
• TCP connections are hard to spoof once established; UDP traffic is easy to spoof and is abused for amplification.
• Plain-text protocols expose both credentials and data to anyone on the path.
• ss -tulpn on the host and an authorised external scan together show your real exposure.

The next part defines threats, vulnerabilities and risk, and how to decide which findings actually matter.

References

• RFC 1918, Address Allocation for Private Internets: https://www.rfc-editor.org/rfc/rfc1918
• RFC 9293, Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293
• IANA Service Name and Transport Protocol Port Number Registry: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
• Nmap reference guide: https://nmap.org/book/man.html