Network Security in Depth

Beyond the basics

Access control lists, stateful firewalls, the demilitarized zone (DMZ), virtual private networks (VPNs), port security and 802.1X are explained in Network Security Basics; host firewalls on Linux in Linux Security. This page builds on them. The theme throughout is defense in depth: assume that one control will fail at some point, and make sure the next one limits the damage, detects it, or both.

Modern attacks rarely break through the firewall head-on. They arrive through a phishing email, a stolen password or a vulnerable internet-facing service, and then try to spread inside. Much of network security in depth is therefore about the inside: slowing that spread down and noticing it.

Segmentation and microsegmentation

In a flat network every device can reach every other device. That is convenient — and it means that once an attacker controls one laptop, every server is one connection away. Moving from the first compromised system to others is called lateral movement, and ransomware groups depend on it to reach file servers, backups and domain controllers.

Classic network segmentation splits the network into zones (users, servers, management, guests) with filtering between them. Microsegmentation takes this down to the level of individual workloads: each server or even each application gets its own policy, such as "the web servers may reach the database on port 5432, and nothing else may". It is usually enforced in software — host firewalls managed centrally, a hypervisor's distributed firewall, or cloud security groups (see Cloud Networking) — rather than with virtual LANs (VLANs), which would become unmanageable at that granularity.

IT and OT separation

Industrial environments — energy, water, manufacturing, transport — run operational technology (OT): control systems, programmable logic controllers and the screens operators use to run a physical process. In OT, availability and physical safety come first; systems may run for decades and often cannot be patched or restarted on short notice. That makes separation from the office (IT) network essential.

Conceptually, organizations do this by:

• Placing a separate, tightly filtered zone (an industrial DMZ) between IT and OT, so no connection goes straight through. Reference models such as the Purdue model and the zones and conduits of the IEC 62443 standards describe these layers.
• Letting data flow out of OT (for reports and monitoring) more easily than commands flow in; some sites use one-way devices (data diodes) for this.
• Routing remote access for vendors through a controlled jump server with multi-factor authentication and session logging, enabled only when needed.
• Monitoring OT traffic passively, because active scanning can disturb fragile control equipment.

The details depend heavily on the sector and its regulator; treat this as orientation, and follow your organization's OT security policy.

Intrusion detection and prevention

An intrusion detection system (IDS) inspects traffic and raises an alert when something looks like an attack. A network IDS receives a copy of the traffic from a switch's mirror port (Switched Port Analyzer, SPAN) or a network test access point (TAP), so it cannot slow down or block anything. An intrusion prevention system (IPS) sits inline, in the traffic path, so it can drop malicious packets or reset a connection before they reach their target. Next-generation firewalls usually include an IPS. Host-based versions (host-based intrusion detection and prevention systems, HIDS/HIPS) run on the server or endpoint itself. Well-known open-source engines are Snort and Suricata.

Signature and anomaly detection

• Signature-based detection compares traffic with patterns of known attacks. It is precise and easy to explain, but it cannot recognize an attack nobody has written a signature for yet, so signatures must be updated constantly.
• Anomaly-based (behavior-based) detection first learns what normal traffic looks like and then flags deviations — a workstation suddenly sending gigabytes at night. It can catch new attacks, but it produces more false positives, and "normal" must be learned on a network that is not already compromised.

Most products combine both. Either way, encrypted traffic limits what a network sensor can see, which is one reason endpoint detection (see Endpoint Security) has become just as important. Alerts from IDS and IPS sensors feed into central monitoring, described in Security Monitoring and the SOC.

Network access control

Network access control (NAC) decides whether a device may join the network and, if so, which part of it. It typically combines:

• Authentication of the user or device, usually with 802.1X on wired ports and Wi-Fi, ideally with device certificates (see PKI and Certificates).
• A posture check: is the operating system patched, is endpoint protection running, is the disk encrypted? An agent on the device reports this, or the NAC system queries the device management platform.
• A decision: full access, a restricted or quarantine VLAN with only the update servers reachable, or a guest network with internet access only.

Devices that cannot do 802.1X — printers, badge readers, cameras — are often admitted by MAC address (MAC Authentication Bypass). Because a MAC address is easy to copy, such devices should land in their own restricted segment, never on the user network.

Proxies, web filters and DNS filtering

Forward proxies and web filters

A forward proxy makes web requests on behalf of users. Because all web traffic passes through it, it can enforce policy: block categories of sites (malware, phishing, gambling), scan downloads, and log who visited what. To look inside HTTPS, the proxy performs TLS inspection: it decrypts and re-encrypts the traffic, using a company root certificate that is installed on managed devices. That gives visibility, but it also puts very sensitive data in one place, may break some applications, and has privacy implications under the General Data Protection Regulation (GDPR) (in Dutch: AVG). Most organizations exclude categories such as banking and healthcare, and document the decision.

A reverse proxy works the other way around: it sits in front of your own servers and receives requests from the internet. It can terminate TLS, balance load and host a web application firewall (see Web Application Security).

DNS filtering

Almost every connection starts with a DNS lookup (see DNS). A filtering resolver simply refuses to resolve domains that are known to host malware or phishing, or returns the address of a block page instead. It is cheap, covers every device that uses the resolver — including phones and devices that cannot run an agent — and stops many threats before a connection is even made. It is easily bypassed by a device that uses another resolver or encrypted DNS, so block outbound DNS to anything but your own resolvers, and manage browsers' encrypted-DNS settings (see encrypted DNS).

Email security gateways

Email is the most common delivery route for phishing and malware. An email security gateway (on premises or as a cloud service) filters spam, scans and detonates attachments in a sandbox, and rewrites links so they are checked when clicked. Three DNS-based standards help receivers spot forged senders:

• SPF (Sender Policy Framework): a DNS record listing which servers may send mail for a domain.
• DKIM (DomainKeys Identified Mail): the sending server signs each message; the public key is published in DNS, so receivers can check the signature.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): a DNS record that tells receivers what to do when a message passes neither SPF nor DKIM for the domain shown in the From address (alignment) — nothing, quarantine or reject — and where to send reports.

Together they make it much harder to send mail that claims to come from your domain. They do not stop look-alike domains, so user awareness (see Social Engineering and Phishing) remains necessary.

DDoS attacks and mitigation

A distributed denial of service (DDoS) attack tries to make a service unavailable by overwhelming it from many sources at once, often a botnet of compromised devices. Attacks come in three broad kinds: volumetric (filling the internet link), protocol (exhausting connection tables in firewalls and load balancers) and application-layer (many expensive requests to a website or API).

A large volumetric attack is bigger than any single organization's internet connection, so your own firewall cannot stop it: the link is full before traffic reaches it. Mitigation therefore happens upstream:

• Internet providers and scrubbing services divert traffic to large filtering centers during an attack and forward only the clean traffic.
• Content delivery networks and cloud providers spread public services over many locations, so the load is absorbed across the globe (see Regions and Availability Zones).
• Rate limiting, caching and autoscaling help against smaller application-layer attacks.

Arrange DDoS protection before you need it: who to call at the provider, how to switch on scrubbing, and which services matter most. Those steps belong in the incident response plan (see Incident Response) and the business continuity plan.

Honeypots

A honeypot is a decoy system with no legitimate business use, placed to attract attackers. Because no normal user has any reason to touch it, every connection to it is suspicious — which makes honeypot alerts unusually reliable. Variants include a honeynet (a set of decoys), honey files and honeytokens: fake credentials or records that raise an alert the moment someone uses them.

A honeypot must be isolated and monitored so that it can never be used as a stepping stone to real systems, and it should be approved and documented like any other security control.

Zero trust

The traditional perimeter model works like a castle: a strong wall (the firewall) and everyone inside is trusted. Remote work, cloud services and phishing have made that wall porous: users and data are outside it, and attackers get inside it. Zero trust is a security model that drops the idea of a trusted network. Its motto is never trust, always verify: every request to a resource is authenticated and authorized on its own merits, based on the identity of the user, the device and its health, and the context (location, time, behavior, sensitivity of the data), with least privilege and continuous monitoring. NIST Special Publication 800-207 describes the architecture: a policy engine decides, and a policy enforcement point in front of each resource carries the decision out.

ZTNA versus VPN

A classic remote-access VPN (see VPNs) puts the remote device on the network: once connected, it can usually reach far more than the user needs. Zero trust network access (ZTNA) instead connects a user to one specific application at a time, after checking identity (with multi-factor authentication) and device posture, and keeps the applications themselves invisible to anyone who has not passed that check. Many organizations run both during a gradual migration.

Spotting lateral movement

Segmentation slows an intruder down; monitoring should notice the attempt. One simple, useful signal: a single internal host that connects to many other internal hosts on ports used for administration and file sharing — 445 (Server Message Block, SMB: Windows file sharing) and 3389 (Remote Desktop Protocol). Ordinary laptops talk to a few servers, not to dozens of colleagues' laptops. The script below counts distinct internal targets per source in a small, fake flow log, and skips a documented vulnerability scanner that does this on purpose:

from collections import defaultdict

# Fake flow log: (source, destination, destination port)
flows = [
    ("10.10.1.21", "10.10.5.10", 445),   # laptop -> file server
    ("10.10.1.22", "10.10.5.10", 445),
    ("10.10.1.23", "10.10.5.11", 3389),  # admin -> one server via RDP
    ("10.10.9.5", "10.10.1.21", 445),    # vulnerability scanner
    ("10.10.9.5", "10.10.1.22", 445),
    ("10.10.9.5", "10.10.1.23", 445),
    ("10.10.9.5", "10.10.1.24", 445),
    ("10.10.9.5", "10.10.1.25", 445),
    ("10.10.1.24", "10.10.1.21", 445),   # a laptop talking to many laptops
    ("10.10.1.24", "10.10.1.22", 445),
    ("10.10.1.24", "10.10.1.23", 3389),
    ("10.10.1.24", "10.10.1.25", 445),
    ("10.10.1.24", "10.10.1.26", 445),
    ("10.10.1.24", "10.10.5.11", 3389),
    ("10.10.1.24", "10.10.5.10", 445),
]

WATCHED_PORTS = {445, 3389}      # SMB file sharing, Remote Desktop
THRESHOLD = 5                    # distinct internal targets
KNOWN_SCANNERS = {"10.10.9.5"}   # approved, documented sources

targets = defaultdict(set)
for src, dst, port in flows:
    if port in WATCHED_PORTS and dst.startswith("10."):
        targets[src].add(dst)

for src in sorted(targets):
    count = len(targets[src])
    if count < THRESHOLD:
        continue
    if src in KNOWN_SCANNERS:
        print(f"{src}: {count} targets (known scanner, ignored)")
    else:
        print(f"ALERT {src}: {count} internal hosts on 445/3389")

ALERT 10.10.1.24: 7 internal hosts on 445/3389
10.10.9.5: 5 targets (known scanner, ignored)

Using a set per source counts each target once, however many connections there are. Real detection runs on flow data (NetFlow, IPFIX) or firewall logs in a security information and event management (SIEM) system, with thresholds tuned to your network, and an alert like this one is the start of an investigation, not proof: the analyst checks what 10.10.1.24 is, who uses it, and whether the activity was expected. The allowlist matters too — an undocumented exception for "the scanner" is exactly where an attacker would like to hide.