Network Security Fundamentals

Trust Boundaries on the Wire#

Most of the protocols in this course were designed for a smaller, more trusting internet. ARP believes any reply, DNS originally believed any answer, and BGP believes its neighbours. Network security is largely the work of compensating for that trust with layers of controls: separating systems, filtering what crosses between them, encrypting what travels, and watching for what gets through anyway.

Segmentation: Limiting the Blast Radius#

The most effective network defence is segmentation: placing systems in separate networks that connect only through controlled choke points. If the public web server and the payroll database share a flat network, compromising the web server gives an attacker a direct path to the database. If they sit in different segments behind a firewall that allows only the application's database port from the application servers, the attacker has to break through another control, and makes noise doing it.

A typical layout:

Related patterns:

• Micro-segmentation applies policy per workload, often in software (cloud security groups, Kubernetes NetworkPolicy, host firewalls), so even hosts in the same subnet cannot talk freely.
• Zero-trust networking removes network location as a source of trust altogether: every request is authenticated and authorised on its own merits. See the zero trust lesson.
• Egress filtering is the half people forget. Restricting outbound traffic from servers stops malware downloading its second stage and makes data exfiltration and command-and-control far harder.

Firewalls: Enforcing the Policy#

• Packet filters match on IP, port, and protocol. Fast, but they have no memory of connections.
• Stateful firewalls track connections, so return traffic for an allowed outbound session is permitted automatically and unsolicited inbound packets are dropped.
• Next-generation firewalls add application identification, user identity, TLS inspection, and threat feeds.
• Web application firewalls focus on HTTP-layer attacks such as injection and XSS.

The firewalls lesson goes deeper. Here is what a sensible default-deny host policy looks like in nftables, the current Linux firewall framework:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept      # replies to connections we started
    ct state invalid drop
    iif "lo" accept
    ip saddr 10.10.0.0/24 tcp dport 22 accept # SSH only from the management subnet
    tcp dport { 80, 443 } accept               # public web
    icmp type echo-request limit rate 5/second accept
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

The non-obvious lines: policy drop makes anything not explicitly allowed fail closed, the ct state established,related rule is what makes the firewall stateful, and restricting SSH by source subnet means a leaked key alone is not enough to log in from the internet. Load it with sudo nft -f rules.nft and inspect it with sudo nft list ruleset. On a production server, tighten the output chain too, following the egress point above.

Verify Segmentation, Don't Assume It#

A diagram is not a control. Test from inside each zone that the paths you expect to be blocked really are, on networks you are authorised to test:

# From an app-tier host: the database port should be open, SSH to the data tier should not
nmap -Pn -p 5432,22 10.30.0.0/28

# From a user laptop: nothing in the data tier should answer at all
nmap -Pn -p 1-65535 --max-retries 1 10.30.0.10

-Pn skips the ping check, since well-filtered hosts do not answer ping. filtered in the results means packets were silently dropped (a firewall is doing its job); closed means the host answered with a reset, which tells you the path is open to the host even though the port is not.

In the cloud, the equivalent audit is a script over your security groups. This one lists every rule open to the entire internet on anything other than the web ports:

import boto3

ALLOWED_PUBLIC_PORTS = {80, 443}          # the only ports meant to face the internet
OPEN_CIDRS = {"0.0.0.0/0", "::/0"}

def risky_rules(region="us-east-1"):
    ec2 = boto3.client("ec2", region_name=region)
    for page in ec2.get_paginator("describe_security_groups").paginate():
        for group in page["SecurityGroups"]:
            for perm in group["IpPermissions"]:
                sources = {r["CidrIp"] for r in perm.get("IpRanges", [])}
                sources |= {r["CidrIpv6"] for r in perm.get("Ipv6Ranges", [])}
                if not sources & OPEN_CIDRS:
                    continue
                proto = perm["IpProtocol"]           # "-1" means all protocols
                start, end = perm.get("FromPort"), perm.get("ToPort")
                if proto == "-1":
                    ports = "ALL"
                elif start == end and start in ALLOWED_PUBLIC_PORTS:
                    continue                          # 80/443 open to the world is intended
                else:
                    ports = f"{start}-{end}" if start != end else str(start)
                yield group["GroupId"], group["GroupName"], proto, ports

for gid, name, proto, ports in risky_rules():
    print(f"{gid}  {name:<24} {proto:<4} {ports:<12} open to the internet")

Typical findings are SSH (22), RDP (3389), or a database port left open "temporarily", and old rules allowing all protocols. Run it on a schedule and treat new findings as incidents. The same check belongs in the deployment pipeline, as covered in the network automation lesson.

Encryption in Transit#

Assume every network path can be observed or tampered with, including your own data centre. Use TLS for every protocol, including internal service-to-service calls, where mutual TLS (both sides present certificates) also authenticates the caller. Retire plaintext protocols: Telnet, FTP, plain HTTP, SNMPv1/v2c with community strings, and LDAP without TLS all hand credentials to anyone on the path.

Common LAN and Infrastructure Attacks, With Their Fixes#

The Ethernet, ARP and switching lesson explains why the switch-level attacks work.

Intrusion Detection and Network Monitoring#

An IDS watches traffic and raises alerts; an IPS sits inline and can block. Suricata and Snort use signatures, while Zeek turns traffic into rich logs of connections, DNS queries, TLS handshakes, and HTTP requests that you can search later. A simple Suricata rule looks like this:

alert tcp $HOME_NET any -> $EXTERNAL_NET 23 (msg:"Outbound Telnet from internal host"; flow:to_server; sid:1000001; rev:1;)

Signatures catch known patterns; anomaly detection flags departures from a baseline. Both produce false positives, so tuning matters. Detection signals worth alerting on:

• Internal hosts connecting to new external destinations on unusual ports, or at unusual volumes.
• A new host scanning many internal addresses or ports.
• DNS anomalies: very long or random-looking subdomains, high query rates to one domain, lookups of newly registered domains. The DNS security lesson covers these.
• Services listening on ports that are not in your inventory.
• Spikes in failed authentication against VPNs, SSH, or admin panels.

Send these to a central system and correlate them with host and identity logs, as described in detection and SIEM. Network data shows the movement between hosts; endpoint telemetry shows what happened on each one. You need both.

Defence in Depth, Applied#

No single control is enough. A layered posture means the failure of one does not become a breach:

1. Segment so a compromised host has few places to go.
2. Filter every boundary, both inbound and outbound, with default-deny rules that are reviewed regularly. Old "allow any" rules are how attackers cross otherwise well-designed networks.
3. Encrypt all traffic in transit, and authenticate service-to-service calls.
4. Harden switches and Wi-Fi against local attacks.
5. Monitor flows, DNS, and firewall logs against a baseline.
6. Rehearse response: know how to isolate a segment or a single host quickly without taking down the rest of the network.

The goal is not an impenetrable wall. It is making each step of an attacker's path both harder and noisier, so that an intrusion is detected and contained while it is still small.

Practice#

In a lab (a few VMs or containers on separate networks), build a web, app, and database tier with host firewalls implementing the table above. Use nmap from each tier to prove which paths are open, then deliberately add an over-broad rule and confirm that your scan or audit script catches it.