Networking Fundamentals for Defenders Guide: Addressing, Routing and Traffic Basics

You cannot defend, monitor or investigate a network you do not understand, and many security mistakes start with a misread subnet, a forgotten NAT rule or a log that never recorded the right field. This guide explains the networking basics every defender needs: how IP addresses and subnets work, what routers and switches actually do, how NAT changes what your logs show, the difference between TCP and UDP, and how DNS and DHCP hand out names and addresses. It then turns to what defenders should log, from firewall records to NetFlow and IPFIX, and when you need full packets rather than flows. It is for analysts and engineers who need enough network depth to read an incident timeline with confidence; deeper topics have their own guides, linked where they fit.

Key takeaways

• Addresses tell you where, not who. An IP address identifies an interface at a point in time; DHCP leases, NAT and VPN pools mean you need lease, translation and session logs to tie it to a device or identity.
• CIDR is the language of every rule. A firewall rule, a cloud security group and an allow list are all prefixes; a /16 written where a /24 was meant opens 65,536 addresses instead of 256.
• Know the layer you are looking at. Switches forward frames by MAC address inside a VLAN, routers forward packets by IP prefix between networks, and only routed or filtered boundaries give you a natural control and logging point.
• Flows answer "who talked to whom", packets answer "what was said". Collect flow records and firewall logs everywhere, and keep packet capture for chokepoints and incident response.
• Time and translation make or break investigations. Synchronised clocks, recorded NAT translations and retained DHCP and DNS logs are cheap to keep and impossible to recreate after an incident.

IP addressing, subnets and CIDR

Every device that talks on an IP network has at least one address. IPv4, defined in RFC 791 in 1981, uses 32-bit addresses written as four decimal numbers (192.0.2.10). IPv6, now specified as Internet Standard 86 in RFC 8200, uses 128-bit addresses written in hexadecimal groups (2001:db8::10). Both split an address into a network part and a host part, and the split is written with a slash: the number after it is how many leading bits identify the network.

This notation is CIDR (Classless Inter-domain Routing, RFC 4632, BCP 122). It replaced the old Class A, B and C scheme so that blocks could be sized to need and routes could be aggregated. RFC 4632 gives the scale clearly: a /8 contains 16,777,216 addresses and a /24 contains 256.

Private, special and IPv6 ranges

• RFC 1918 private space: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. RFC 1918 says routes and packets for these ranges should not cross enterprise borders, that border routers should filter them in both directions, and that DNS records pointing at private addresses should stay inside the enterprise. Inbound internet traffic claiming an RFC 1918 source is spoofed or misrouted and should be dropped.
• Anti-spoofing: BCP 38 (RFC 2827) asks networks to accept packets from a downstream network only if the source falls inside that network's legitimate prefixes, and to log what is dropped. Apply the same logic at your own edge: outbound packets should carry only your own source prefixes.
• Shared and loopback space: 100.64.0.0/10 (carrier-grade NAT), 127.0.0.0/8 (loopback) and 169.254.0.0/16 (link-local, which also hosts cloud instance metadata services at 169.254.169.254) appear in logs and need specific handling.
• IPv6: hosts usually have several addresses at once: a link-local fe80::/10 address, one or more global addresses and often temporary privacy addresses that change. Unique local addresses (fc00::/7) play roughly the role RFC 1918 plays in IPv4. If your tools only parse IPv4, IPv6 traffic on a dual-stack network is invisible to them. See the IPv6 Security Guide.

Routing, switching and VLANs

• Switches (layer 2): forward Ethernet frames inside one broadcast domain using MAC addresses learned on each port. Traffic between two laptops on one VLAN never reaches the firewall.
• ARP: to send to a local IPv4 address, a host broadcasts an ARP request and caches the reply. RFC 826 defines no authentication for those replies, which is why ARP cache poisoning (MITRE ATT&CK T1557.002) remains possible on any flat segment without switch protections such as dynamic ARP inspection. IPv6 uses Neighbor Discovery instead, with similar trust problems.
• VLANs: an IEEE 802.1Q tag lets one physical switch carry several separate layer 2 networks. A VLAN is not a security control on its own: inter-VLAN traffic is only filtered if routed through a firewall or ACL.
• Routers (layer 3): forward packets between networks by looking up the destination in a routing table and choosing the most specific matching prefix. Each hop decrements the IPv4 Time to Live (the IPv6 Hop Limit), and a packet is discarded when it reaches zero, which is how traceroute maps a path.
• Default gateway: the router a host sends everything to when the destination is not local. A rogue gateway handed out by a malicious DHCP server (ATT&CK T1557.003, DHCP Spoofing) puts an attacker in the path of all of a host's traffic.
• Dynamic routing: inside organisations OSPF or similar protocols share routes; between organisations BGP does. Route leaks and hijacks are a separate subject: see the BGP and Routing Security Guide.

The practical lesson: security boundaries exist where traffic is routed through something that filters and logs. If a sensitive server shares a VLAN with user laptops, no amount of firewall policy sees that traffic. Designing those boundaries is covered in the Network Segmentation Guide.

NAT and what it does to your logs

Network Address Translation rewrites addresses as packets cross a device. Most organisations use port address translation (PAT, also called NAT overload) at the internet edge: thousands of internal RFC 1918 hosts share one or a few public IPv4 addresses, and the device tracks each connection by rewriting the source port.

• Source NAT: internal clients appear on the internet as the firewall's public address. Only the translation log can turn an abuse report about your public IP into an internal host.
• Destination NAT (port forwarding): a public address and port are mapped to an internal server. Every such mapping is internet exposure and belongs in your attack surface inventory.
• Carrier-grade NAT: mobile and some broadband users share public addresses, so blocking or trusting one public IP affects strangers.
• Load balancers: back-end servers often see the load balancer's address, so pass on and log the original client address (for example in X-Forwarded-For).

Logging rule: record pre-translation and post-translation addresses and ports with a timestamp for every session at NAT devices, and retain them at least as long as you retain the logs they will be correlated with. NAT is not a firewall: it hides addresses, but it does not apply a security policy unless a stateful filter is configured alongside it.

TCP, UDP and ports

The transport protocols carry application data between processes, identified by port numbers.

TCP's control bits as listed in RFC 9293 are CWR, ECE, URG, ACK, PSH, RST, SYN and FIN. Reading them is the quickest way to tell a completed connection from a rejected or half-open one in a flow record. Ports are allocated by IANA under RFC 6335 in three ranges: system ports 0 to 1023, user ports 1024 to 49151, and dynamic or private ports 49152 to 65535, which clients usually pick as their temporary source port. A port number is a convention, not a guarantee: anything can listen on 443.

Ports to recognise on sight include 22 (SSH), 53 (DNS), 67 and 68 (DHCP), 80 and 443 (HTTP and HTTPS), 123 (NTP), 389 and 636 (LDAP and LDAPS), 445 (SMB), 514 (syslog) and 3389 (RDP). The risk of each, and how to restrict them, is in the Network Ports and Protocols Security Guide.

DNS and DHCP basics

• DHCP: RFC 2131 defines a four-message exchange: the client broadcasts DHCPDISCOVER, servers reply with DHCPOFFER, the client broadcasts DHCPREQUEST naming the chosen server, and that server confirms with DHCPACK. Clients send to UDP port 67 and servers reply to port 68. The lease hands out the address, subnet mask, default gateway and DNS servers, so whoever answers first controls where the client sends traffic. DHCP snooping on access switches restricts server replies to trusted ports.
• DHCP logs are identity evidence: the lease log maps IP address to MAC address and hostname over time. Without it, an alert on 10.20.30.40 at 02:14 last Tuesday may be impossible to attribute.
• DNS: resolves names to addresses. Clients ask a recursive resolver (usually on UDP 53, falling back to TCP 53 for large responses), which queries authoritative servers. Common record types are A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (free text, used for SPF and domain verification) and PTR (reverse lookup).
• Why DNS logs matter: almost every connection begins with a lookup, so resolver query logs show intent before traffic flows, reveal newly seen domains, and expose DNS used as a covert channel (ATT&CK T1071.004). Encrypted DNS sent straight to public resolvers bypasses your logs, so set a policy.

DNS attacks, protective DNS and DNSSEC are covered in the DNS Security Guide.

What defenders log: firewall, flow and network service records

Network evidence comes from a small number of sources.

IPFIX, Internet Standard 77 (RFC 7011), defines a flow as a set of packets passing an observation point during a time interval that share common properties, exported by an exporter to a collector. NetFlow is the vendor protocol it grew from. When you configure flow export, record whether sampling is applied (for example 1 in 1,000 packets), because sampled data cannot prove a connection did not happen.

Firewall policy and logging practice is described in NIST SP 800-41 Rev. 1, and intrusion detection sensor types (network-based, wireless, network behaviour analysis and host-based) in NIST SP 800-94. Day-to-day firewall operation is covered in the Firewall Management Guide.

Packet versus flow visibility: choosing what to collect

• Flow first, everywhere: flows and firewall logs are small enough to keep for months and cover the whole estate. They detect scanning (T1046 Network Service Discovery), beaconing to the same destination at regular intervals, unusual internal connections that suggest lateral movement (T1021 Remote Services) and large outbound transfers (T1048).
• Packets at chokepoints: deploy full or rolling packet capture at the internet edge, data centre core and in front of crown-jewel systems.
• Metadata as the middle ground: sensors that parse protocols into connection, DNS, HTTP and TLS logs give much of the value of packets at a fraction of the storage.
• Encryption changes the balance: with TLS 1.3 most payload is unreadable without inspection, so metadata such as server name, certificate, timing and volume carries most of the signal. See the TLS Inspection Guide before deciding to decrypt.
• Small versus large organisations: a small organisation can get most of the value from firewall logs, DNS logs and cloud flow logs sent to one place. Large or regulated estates add dedicated flow collectors, packet brokers and network detection and response; see the NDR Guide and the Network Monitoring and Packet Capture Guide.

Building your network baseline step by step

1. Map address space: list every IPv4 and IPv6 prefix in use (sites, VLANs, VPN pools, cloud VPCs, partner links) with an owner and purpose in an IPAM or a maintained spreadsheet. This supports NIST CSF 2.0 ID.AM-03.
2. Synchronise time: point every network device, server and log collector at the same NTP sources and log in UTC. A few minutes of drift breaks correlation between firewall, DHCP and endpoint logs.
3. Turn on the core logs: firewall allow and deny logs with rule IDs and NAT fields, DNS resolver query logs, DHCP lease logs and VPN session logs, forwarded to a central platform (see the SIEM Guide).
4. Export flows: enable NetFlow or IPFIX on edge and core routers and flow logs in each cloud account. Document any sampling rate.
5. Test that it works: from a test host, make a known connection, a DNS lookup and a blocked connection, then find all three in your logs within the expected delay and confirm the NAT and DHCP records let you trace the test host by name.
6. Baseline normal: record top talkers and destinations per segment for two to four weeks before writing threshold alerts.
7. Tighten and review: add egress filtering, BCP 38 anti-spoofing and RFC 1918 border filters; change rules in a pilot segment first, keep the previous rule set exported so you can roll back in one step, and review rule hits after each change.

Detection and measurement

Detections built from these fundamentals: RFC 1918 or own-prefix sources arriving at the edge; DHCP offers from unexpected servers; a gateway address changing MAC; hosts touching many internal addresses or ports quickly (T1046, T1018 Remote System Discovery); hosts using non-corporate DNS servers; and servers initiating outbound connections they never should.

• Log coverage: percentage of routed boundaries, NAT devices and cloud accounts sending firewall and flow logs to the central platform (target 100 per cent).
• Attribution rate: share of internal IP addresses in alerts that can be resolved to a hostname and owner within 15 minutes using DHCP, IPAM and VPN logs.
• Address space coverage: prefixes seen in flow data that are not in the IPAM inventory (target zero unknown prefixes).
• Over-broad rules: count of firewall or security group rules with source 0.0.0.0/0 or ::/0 to non-web ports, or internal sources wider than /16.

Framework mapping

In CIS Controls v8.1, Control 12 (Network Infrastructure Management) and Control 13 (Network Monitoring and Defense) cover the same ground. In ISO/IEC 27001:2022 Annex A, the closest controls are 8.20 Networks security, 8.22 Segregation of networks and 8.16 Monitoring activities.

Common failure patterns

• Treating a VLAN as a firewall: separate VLANs routed by a core switch with no access control list give the appearance of segmentation with none of the control.
• Forgotten remote access paths: a VPN profile or port forward nobody remembers is still a route into the network. In the Colonial Pipeline ransomware attack, attackers used a legacy VPN profile that was no longer in use but had never been disabled, protected only by a password that had leaked. An inventory of every remote access path, with MFA on each, would have closed it.
• No NAT or DHCP history: an alert names an address that has since been reassigned, and the translation or lease logs were never kept.
• "Any" in the source column: rules opened to 0.0.0.0/0 for a quick test and never narrowed, or an internal /8 allowed to a database because nobody knew the real client subnet. See the Top 10 Network Security Misconfigurations.
• IPv4-only monitoring on dual-stack networks: operating systems prefer IPv6 when available, so filters, flow parsers and detections written for IPv4 silently miss traffic.
• Logging denies but not allows: deny logs show the noise of the internet; the allowed connection that exfiltrated data is the one you need, and it was not recorded.

Practitioner checklist

• Maintain an inventory of every IPv4 and IPv6 prefix, VPN pool and cloud range with an owner.
• Filter RFC 1918 and your own prefixes as inbound sources, and allow only your own prefixes as outbound sources (BCP 38).
• Route traffic between sensitive VLANs through a filtering, logging control point.
• Enable DHCP snooping and dynamic ARP inspection on user access switches.
• Log firewall allows and denies with rule ID and NAT translation fields, and retain them as long as related logs.
• Collect DNS resolver, DHCP lease and VPN session logs centrally with synchronised UTC timestamps.
• Export NetFlow or IPFIX from edge and core, and cloud flow logs from every account, recording sampling rates.
• Keep rolling packet capture at the internet edge and in front of critical systems.
• Review rules with any-source or over-broad prefixes every quarter.
• Run a test connection each quarter and prove you can trace it end to end to a named device.

Standards and references

• IETF: RFC 791 Internet Protocol
• IETF: RFC 8200 Internet Protocol, Version 6 (IPv6) Specification
• IETF: RFC 4632 Classless Inter-domain Routing (CIDR)
• IETF: RFC 1918 Address Allocation for Private Internets
• IETF: RFC 9293 Transmission Control Protocol (TCP)
• IETF: RFC 7011 IP Flow Information Export (IPFIX) Protocol
• IANA: Service Name and Transport Protocol Port Number Registry
• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy

Related NHI Mgmt Group resources: Network Security Guide · OSI and TCP/IP Models Guide · Network Ports and Protocols Security Guide · DNS Security Guide · NDR Guide