Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire

scipio

Published: 01 Jul 2026 › Updated: 01 Jul 2026 Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire

Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire

What will I learn

Defense-in-depth network design -- layered security from perimeter to endpoint;
Next-generation firewalls -- application-aware filtering, IPS, SSL inspection, and threat intelligence feeds;
IDS/IPS deployment -- Snort, Suricata, and where to place sensors for maximum visibility;
Network segmentation in practice -- VLANs, micro-segmentation, and zero trust network access;
TLS inspection -- decrypting HTTPS traffic for security monitoring and the privacy tradeoff;
DNS security -- DNS filtering, sinkholing, and DNS-over-HTTPS implications for defenders;
Network Access Control (NAC) -- 802.1X authentication and device posture checking;
Defense: building networks that detect, contain, and resist the attacks from this entire series.

Requirements

A working modern computer running macOS, Windows or Ubuntu;
Understanding of network attacks from episodes 29-40;
Familiarity with security architecture from Episode 53;
The ambition to learn ethical hacking and security research.

Difficulty

Intermediate

Curriculum (of the `Learn Ethical Hacking Series`):

Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire

Solutions to Episode 72 Exercises

Exercise 1: Tiered administration (abbreviated).

# Created accounts:
# Tier 0: t0-admin1, t0-admin2, t0-admin3 (Domain Admins)
# Tier 1: t1-srvadm1, t1-srvadm2, t1-srvadm3 (Server Admins)
# Tier 2: t2-helpdesk1, t2-helpdesk2, t2-helpdesk3 (Workstation Admins)

# GPO on Workstation OU:
# "Deny log on locally" = Domain Admins, Server Admins
# "Deny log on through RDP" = Domain Admins, Server Admins

# Test: attempted to log into WS01 as t0-admin1
# Result: "The sign-in method you're trying to use isn't allowed"
# Tiering enforced successfully.

The "sign-in method not allowed" message is exactly what successful tiered administration looks like -- Windows rejecting a Domain Admin credential at a Tier 2 workstation because the GPO explicitly denies that cross-tier logon. This is the single most impactful control you can deploy in Active Directory, and the test proves it works. Remember episode 33 where we stole cached credentials from a workstation where a DA had logged in? With tiering enforced, that DA account NEVER touches the workstation in the first place, so there are no cached credentials to steal, no tokens to harvest with mimikatz, no attack chain from workstation to Domain Controller. The inconvenience of maintaining three separate admin accounts per administrator is a tiny price compared to the catastrophic cost of a full domain compromise -- and if your sysadmins complain about it, remind them that the entire Kerberoasting attack path they studied in episode 33 begins with one Domain Admin logging into one workstation "just to check something real quick."

Exercise 2: Credential protections (abbreviated).

Credential Guard + mimikatz:
  mimikatz# sekurlsa::logonpasswords
  ERROR kuhl_m_sekurlsa_acquireLSA: Handle on memory (0x00000005)
  -> BLOCKED. Credential Guard isolates LSASS.

LAPS + lateral movement:
  Each workstation has a unique random 20-char local admin password.
  crackmapexec smb 192.168.1.0/24 -u administrator -p OldSharedPassword
  -> 0 successful authentications (passwords are all unique now)

Protected Users + NTLM relay:
  ntlmrelayx.py targeting t0-admin1 -> NTLM authentication refused.
  Protected Users forces Kerberos only, NTLM is disabled.

Three controls, three attack vectors killed. Credential Guard gave mimikatz an access denied error (0x00000005) because LSASS is now running inside a hardware-isolated VBS container that even SYSTEM-level processes cannot read. The mimikatz approach from episode 33 simply does not work anymore -- the credentials are there, but they are behind a hardware boundary that software alone cannot cross. LAPS eliminated the shared local admin password problem entirely: CrackMapExec sprayed the old shared password across the subnet and got zero hits because every workstation now has its own unique 20-character random password that rotates every 30 days. The lateral movement technique of "compromise one machine, use the local admin hash on every other machine" is dead. And Protected Users killed NTLM relay by forcing Kerberos-only authentication for the Tier 0 admin accounts -- ntlmrelayx cannot relay what does not exist. Each of these controls maps directly to a specific offensive technique from episode 33, and the exercise proves that the defense works. Having said that, these controls protect against KNOWN attack patterns. A determined attacker with a kernel zero-day or a novel bypass technique can still potentially compromise the domain -- defense in depth means layering controls so that bypassing one does not give the attacker everything.

Exercise 3: Detection cheat sheet (abbreviated).

Attack                   | Sysmon Event | Windows Event
Kerberoasting           | --           | 4769 (TGS req, RC4 enc)
PsExec lateral movement | 1 (proc)     | 7045 (new service)
PowerShell -enc         | 1 (proc)     | 4104 (script block log)
LSASS access (mimikatz) | 10 (access)  | 4656 (handle request)
Scheduled task persist  | 1 (proc)     | 4698 (task created)

This cheat sheet is the bridge between offensive and defensive security. Each row maps an attack technique we performed in earlier episodes to the specific event IDs that detect it. Kerberoasting has no Sysmon signature (it is a legitimate Kerberos operation) but generates Event 4769 with RC4 encryption type -- and the detection signal is volume, not any single event. One TGS request is normal. Fifty TGS requests in 10 seconds from a single workstation is Kerberoasting. PsExec creates a new service on the target machine (Event 7045) and Sysmon catches the process creation (Event 1) -- both are reliable detection points because PsExec's service-based execution is its fundamental mechanism. The PowerShell row is critical: Event 4104 logs the DEOBFUSCATED script block, meaning even a Base64-encoded -enc command gets logged as readable text. And Sysmon Event 10 on LSASS access is effectively a mimikatz alarm -- legitimate processes almost never open a handle to LSASS with the specific access rights that credential dumping requires. Building this mapping between attacks and detections is the foundation of effective security monitoring, and these event IDs will become very relevant when we start looking at centralized log collection and correlation at scale.

Episode 72 covered hardening Windows and Active Directory -- tiered administration, Credential Guard, LAPS, Protected Users, Group Policy hardening, PowerShell security, and audit policies. Episodes 71 and 72 together hardened the individual systems -- Linux servers and Windows domain infrastructure. But systems do not exist in isolation. They communicate over a network. And the network is where attackers move laterally, exfiltrate data, communicate with C2 servers, and pivot between segments.

Network security architecture is about designing networks where every attack we covered in this series is either prevented, detected, or contained. Not by a single device -- by layers of defense that each catch what the others miss. A hardened Linux server behind an open, flat, unsegmented network is still vulnerable to the lateral movement, C2 communication, and data exfiltration techniques we demonstrated in episodes 34, 62, and beyond. The host is secure. The network around it is not. Today we fix the network.

Defense-in-Depth Network Design

The fundamental principle is simple: never rely on a single security control. Every layer exists to catch what the layer above it missed, and every segment exists to contain what the perimeter allowed through.

Internet
    |
[Edge Firewall / NGFW]           <- blocks known bad, filters by application
    |
[DMZ]                            <- web servers, email, DNS (public-facing)
    |                               Isolated from internal network
[Internal Firewall]              <- separates DMZ from internal
    |
[IDS/IPS Sensor]                 <- monitors all traffic crossing the boundary
    |
+-- [User VLAN]                  <- workstations, limited server access
|   |
|   [NAC / 802.1X]              <- only authenticated devices connect
|
+-- [Server VLAN]                <- app servers, only accessible from user VLAN on specific ports
|
+-- [Database VLAN]              <- DB servers, only accessible from server VLAN on DB ports
|
+-- [Management VLAN]            <- jump boxes, monitoring, admin access only
|
+-- [IoT VLAN]                   <- isolated, no internet unless required
|
[Network TAP / SPAN]             <- copies traffic to security monitoring
    |
[SIEM / NSM]                     <- correlates all network events

Each boundary enforces: default deny, allow by exception.
Each segment has: its own firewall rules, IDS visibility, and logging.

This diagram is the architectural embodiment of what we discussed in episode 53 (security architecture) applied specifically to network design. Every connection between zones is an explicit policy decision -- not "everything is open by default, we'll block what we notice." The DMZ exists to isolate public-facing services (web servers, email gateways, external DNS) from the internal network, so that compromising a web server (episodes 12-28 covered plenty of ways to do that) does not give the attacker direct access to internal systems. The internal firewall between the DMZ and internal network is the second barrier -- even if the edge firewall is bypassed or misconfigured, the internal firewall enforces its own independent ruleset.

The separation into User, Server, Database, Management, and IoT VLANs is not just organizational tidiness -- it is the direct defense against the lateral movement techniques from episode 34. In a flat network (where all devices share one subnet), an attacker who compromises a single workstation can scan and attack every other device on the network directly. In a segmented network, that same compromised workstation can only reach the Server VLAN on specific ports (443 for web apps, for example) and cannot reach the Database VLAN, the Management VLAN, or the IoT VLAN at all. The blast radius of a single compromise is contained to what that segment's firewall rules allow.

Next-Generation Firewalls

Traditional firewalls operate at layers 3 and 4 -- they see IP addresses and port numbers, and that is all they can filter on. The problem is obvious: HTTPS to a legitimate website and HTTPS to an attacker's C2 server both look identical at layer 4. Both are TCP port 443. A traditional firewall cannot tell the difference.

Traditional firewall: port-based filtering
  "Allow TCP 443 outbound" -- cannot distinguish between
  HTTPS to legitimate sites and HTTPS to C2 servers.

Next-Gen firewall (NGFW): application-aware
  Identifies the APPLICATION inside the traffic:
  "Allow HTTPS to microsoft.com, block HTTPS to pastebin.com"
  "Allow Slack, block file uploads in Slack"
  "Allow SSH to jump-box only, block SSH everywhere else"

NGFW features:
  - Application identification (Layer 7 visibility)
  - Integrated IPS (block exploits in-line)
  - TLS/SSL inspection (decrypt and inspect HTTPS)
  - URL filtering (block categories: malware, phishing, gambling)
  - Threat intelligence feeds (block known malicious IPs/domains)
  - User identity integration (rules per user, not just per IP)
  - Sandboxing (detonate suspicious files before delivery)

Vendors: Palo Alto, Fortinet, Check Point, Cisco Firepower
Open source: pfSense, OPNsense (NGFW-lite functionality)

The application identification capability is what separates a next-gen firewall from a traditional packet filter. A Palo Alto NGFW (to pick the market leader) can identify over 3,000 distinct applications regardless of the port they use. An attacker running a Cobalt Strike HTTPS Beacon on port 443 might bypass a traditional firewall, but an NGFW that performs deep packet inspection and application identification can flag that the traffic pattern does not match legitimate HTTPS browsing behavior -- the timing intervals, the request sizes, the URI patterns all differ from real web traffic.

The user identity integration is equally powerful. Instead of writing firewall rules based on IP addresses (which change as users move between workstations, use VPNs, or connect from different locations), you write rules based on Active Directory group membership: "Finance users can access the accounting application on port 443, Engineering users can access the code repository on port 22, nobody can access the management interfaces except IT Admins." This is the network-level complement to the tiered administration we deployed in episode 72 -- restricting access based on WHO you are, not WHERE you happen to be sitting.

IDS/IPS -- Suricata and Snort

A firewall decides whether to allow or block traffic. An IDS/IPS decides whether traffic that was ALLOWED is actually malicious. These are complementary functions, not redundant ones -- the firewall enforces policy, the IDS/IPS detects attacks within the allowed traffic.

# Suricata (modern, multi-threaded, recommended over Snort 2.x)
apt install suricata

# Configuration: /etc/suricata/suricata.yaml
# Key settings:
#   af-packet interface (mirror port or TAP)
#   rule sources: ET Open, Snort community rules
#   logging: eve.json (structured JSON output -> send to SIEM)

# Update rules
suricata-update

# Run in IDS mode (detect and alert, do not block)
suricata -c /etc/suricata/suricata.yaml -i eth0

# Run in IPS mode (inline, can block)
suricata -c /etc/suricata/suricata.yaml --af-packet -q 0

# Custom rule examples:
# Detect Cobalt Strike beacon (default named pipe)
alert tcp any any -> any any (msg:"Cobalt Strike Named Pipe";
    content:"|5c 00|p|00|i|00|p|00|e|00 5c 00|m|00|s|00|a|00|g|00|e|00|n|00|t|00|_|00|";
    sid:1000001; rev:1;)

# Detect Metasploit Meterpreter stager
alert tcp any any -> any 4444 (msg:"Meterpreter Default Port";
    flow:to_server,established;
    content:"|00 00 00|"; depth:3;
    sid:1000002; rev:1;)

# Detect DNS tunneling (long subdomain labels)
alert dns any any -> any any (msg:"Possible DNS Tunneling";
    dns.query; content:"."; offset:40;
    sid:1000003; rev:1;)

The distinction between IDS mode and IPS mode is critical. In IDS mode, Suricata monitors a copy of the traffic (from a mirror port or network TAP) and generates alerts -- it sees everything but blocks nothing. In IPS mode, Suricata sits inline in the traffic path and can actively drop malicious packets before they reach their destination. IDS mode is safer to deploy (a misconfigured rule generates a false alert, not a production outage) but less effective (the attack succeeds while you are being notified about it). IPS mode stops attacks in real time but carries the risk that a false positive blocks legitimate traffic. Most organizations start with IDS mode, tune their rules to reduce false positives over a period of weeks, and then switch high-confidence rules to IPS mode while keeping lower-confidence rules in alert-only mode.

The three custom rules deserve explanation because they demonstrate how signature-based detection works. The Cobalt Strike rule looks for the specific byte pattern of the default named pipe that Cobalt Strike uses for inter-process communication (msagent_) -- this is the C2 framework we studied in episode 41 and built upon in episode 62. The Meterpreter rule detects connections to port 4444 (the Metasploit default) with a specific byte pattern at the beginning of the connection. And the DNS tunneling rule alerts on DNS queries where the subdomain portion is longer than 40 characters -- a strong indicator of data being encoded in DNS queries, which is the exfiltration technique we covered in episode 40 ;-)

Having said that, these are basic signatures. A skilled attacker (as we discussed in episode 63 on evasion) will change default ports, modify named pipes, and use short DNS labels with higher query volume instead of long labels. Signature-based detection catches the default configurations and the lazy attackers. Behavioral analysis and anomaly detection are needed for the rest -- which is where tools like Zeek and RITA come in later.

Network Segmentation Implementation

The defense-in-depth diagram showed the concept. Here is the implementation -- actual VLAN definitions with firewall rules between them:

VLAN design with firewall rules:

VLAN 10 -- Users (10.10.10.0/24)
  Allowed: -> VLAN 20 port 443 (web apps)
  Allowed: -> Internet (via proxy)
  Denied:  -> VLAN 30 (databases -- no direct access)
  Denied:  -> VLAN 40 (management -- admin only)

VLAN 20 -- Servers (10.10.20.0/24)
  Allowed: -> VLAN 30 port 5432, 3306 (database connections)
  Allowed: -> Internet for updates (specific URLs only)
  Denied:  -> VLAN 10 (servers don't initiate to workstations)
  Denied:  -> VLAN 40 (management -- admin only)

VLAN 30 -- Databases (10.10.30.0/24)
  Allowed: -> Nothing (databases are sinks, they receive, not initiate)
  Denied:  -> Everything outbound

VLAN 40 -- Management (10.10.40.0/24)
  Allowed: -> All VLANs on management ports (SSH, RDP, SNMP)
  Allowed: -> Internet for updates
  Only accessible FROM: pre-authorized admin IPs via VPN

Key principle: if VLAN 10 is compromised (workstation phished),
the attacker can reach the web app (VLAN 20) but NOT the database
(VLAN 30) or the management plane (VLAN 40). The blast radius
is contained.

Let me walk through the attack scenario that segmentation prevents. In episode 34 (pivoting and lateral movement), we demonstrated how an attacker on a compromised workstation scans the local network, discovers database servers, connects directly to them (because nothing prevents it in a flat network), and exfiltrates sensitive data. With the VLAN design above, that attack chain breaks at the first step: the compromised workstation in VLAN 10 cannot reach VLAN 30 at all. The firewall between VLANs explicitly denies that traffic. The attacker can reach the web application servers in VLAN 20 on port 443 only (because that is the legitimate access path for users), but even if they compromise the web app server, VLAN 20 can only reach VLAN 30 on database ports 5432 and 3306 -- and only from the server IP addresses, not from arbitrary connections.

The Database VLAN rule ("Allowed: Nothing outbound") is particularly important. Databases should be pure data sinks -- they receive queries and return results, but they never initiate outbound connections. If a database server is making outbound connections to the internet, something is very wrong (data exfiltration, a compromised database server downloading additional tools, or a reverse shell connecting to a C2 server). Blocking all outbound from the database VLAN makes exfiltration from a compromised database extremely difficult, because the attacker has no outbound channel to send the stolen data through.

The Management VLAN being accessible only from pre-authorized admin IPs via VPN is the network equivalent of tiered administration from episode 72. Only administrators can reach the management plane, and only from specific jump boxes that are themselves hardened and monitored. An attacker on a compromised workstation cannot SSH to a switch, cannot access the firewall management console, and cannot modify routing tables -- because the network infrastructure itself is in a VLAN that workstations cannot reach.

TLS Inspection

This is the most controversial network security control, and for good reason. It involves breaking the encryption that protects user privacy in order to inspect traffic for threats:

The problem: 90%+ of web traffic is HTTPS. An attacker's C2
traffic is also HTTPS. If you cannot inspect HTTPS, you cannot
see C2, data exfiltration, or malware downloads.

TLS inspection (SSL break-and-inspect):
  1. Firewall terminates the client's HTTPS connection
  2. Firewall decrypts the traffic
  3. Firewall inspects the plaintext for threats
  4. Firewall re-encrypts and forwards to the destination
  5. Client sees the firewall's certificate, not the destination's

Requirements:
  - Internal CA certificate deployed to all endpoints (via GPO)
  - NGFW with TLS inspection capability
  - Sufficient hardware (decryption is CPU-intensive)

Privacy considerations:
  - DO NOT inspect: banking, healthcare, personal email
  - Create exemption lists for sensitive categories
  - Document the inspection policy for legal/compliance
  - Some jurisdictions restrict employer inspection of traffic

Without TLS inspection:
  The attacker's Cobalt Strike HTTPS Beacon is invisible.
  Data exfiltration over HTTPS is undetectable.
  Malware downloaded over HTTPS bypasses the IDS.

  75%+ of malware uses HTTPS. If you are not inspecting, you
  are not seeing.

The privacy tradeoff here is real and cannot be handwaved away. TLS inspection means the organization's firewall can read every HTTPS request and response -- including personal browsing, webmail, banking sessions, and health portal visits. The exemption list (banking, healthcare, personal email) is not just a nice-to-have, it is a legal requirement in many jurisdictions. The EU's GDPR, for example, imposes strict limits on employer monitoring of employee communications, and inspecting personal email traffic without proper disclosure could violate privacy regulations we discussed in episode 55.

Having said that, the security argument is equally compelling. Without TLS inspection, 75% or more of your security monitoring is blind. The Cobalt Strike HTTPS Beacon we built in episode 62? Completely invisible to the IDS because the traffic is encrypted. The data exfiltration over HTTPS that we demonstrated? Undetectable. The malware download disguised as a legitimate HTTPS connection? It sails right through. The attacker does not even need to be sophisticated -- just using HTTPS (which is the default for everything in 2026) makes the traffic opaque to every network security tool that is not performing TLS inspection.

The practical approach is layered: inspect traffic on corporate-owned devices to corporate-managed applications (this is your network, your devices, your data), exempt categories that involve personal privacy (banking, health, personal webmail), and document the entire policy so that employees know what is being inspected and why. Certificate pinning in some applications (like mobile banking apps) will cause TLS inspection to fail -- those applications must be exempted rather than broken. The exemption list needs ongoing maintainance as new applications are deployed and new categories emerge.

DNS Security

DNS is the most undermonitored protocol in quit some networks, and it should not be. Every network connection starts with a DNS query. Every C2 callback resolves a domain name. Every data exfiltration channel (from episode 40's DNS tunneling to simple HTTPS to pastebin.com) begins with a DNS lookup that tells you exactly where the traffic is going.

# DNS is the first thing an attacker uses and the last thing
# defenders monitor. Fix that.

# 1. DNS filtering / sinkholing
# Block queries to known malicious domains
# Redirect to a sinkhole server that logs the query
# Tools: Pi-hole, Cisco Umbrella, Cloudflare Gateway

# 2. DNS logging (capture ALL queries)
# Every DNS query = an intent to connect. Log them all.
# Forward to SIEM for analysis.

# 3. Detect DNS tunneling
# Alert on: query length > 50 chars, TXT record queries to
# unusual domains, high query volume to single domain,
# high entropy in subdomain labels

# 4. DNS-over-HTTPS (DoH) -- the defender's dilemma
# DoH encrypts DNS queries inside HTTPS to port 443
# Benefit: protects user privacy from ISP snooping
# Problem: also hides attacker DNS from your security monitoring
# Solution: block DoH to external resolvers, force all DNS
# through your internal resolver (which you monitor)
# GPO: configure DNS to internal servers, block port 443 to
# known DoH providers (1.1.1.1, 8.8.8.8)

DNS sinkholing is elegant in its simplicity. When a compromised machine attempts to resolve a known malicious domain (a C2 server, a phishing page, a malware distribution site), the DNS resolver returns the IP address of your sinkhole server instead of the real answer. The malware connects to your sinkhole thinking it reached its C2 server, the sinkhole logs the connection attempt, and the SOC gets an alert that a specific machine just tried to call home to a known bad domain. The malware communication fails, the compromised machine is identified, and the attacker never knows their implant has been discovered. This is one of the most cost-effective network security controls available -- a Pi-hole running on a $50 Raspberry Pi can provide DNS filtering for an entire small network.

The DNS-over-HTTPS dilemma is one of those situations where a technology designed to protect privacy simultaneously undermines security monitoring. DoH encrypts DNS queries inside standard HTTPS connections, which means your DNS logging infrastructure sees nothing -- the queries bypass your internal resolver entirely and go directly to Cloudflare (1.1.1.1) or Google (8.8.8.8) over an encrypted channel that looks like normal web traffic. From a user privacy perspective, this is excellent: your ISP cannot see what domains you are resolving. From a network security perspective, this is terrible: neither can you. The solution for enterprise environments is to force all DNS resolution through your internal DNS server (which you control and monitor) and block outbound HTTPS to known DoH provider IPs. This preserves your DNS visibility while still allowing DoH between your internal resolver and its upstream forwarder if desired.

Network Access Control (802.1X)

Every attack in this series assumed one thing: the attacker could connect to the network. Whether it was plugging into a wall jack (episode 29) or joining the Wi-Fi (episode 30), network access was the unquestioned starting point. 802.1X questions that assumption:

802.1X authenticates DEVICES before granting network access:

1. Device connects to switch port (or WiFi)
2. Switch sends EAP challenge (device is in quarantine VLAN)
3. Device provides credentials (certificate, username/password)
4. RADIUS server validates credentials
5. If valid: switch assigns the appropriate VLAN
   If invalid: device stays in quarantine (internet only, no internal)

Benefits:
  - Rogue devices cannot access the network
  - Each device is identified and tracked
  - Dynamic VLAN assignment based on device/user identity
  - Guest devices get guest VLAN (isolated)

Why it matters:
  Episode 29 (network sniffing): the attacker plugged into a port.
  With 802.1X: the port stays dead until the device authenticates.
  Episode 30 (wireless attacks): the attacker joined the Wi-Fi.
  With 802.1X Enterprise: WPA2/3 Enterprise requires individual
  credentials, not a shared passphrase.

The dynamic VLAN assignment capability is what makes 802.1X powerful beyond simple access control. When a device authenticates, the RADIUS server does not just say "allow" or "deny" -- it tells the switch which VLAN to place the device in based on the device's identity and posture. A corporate laptop with up-to-date patches and antivirus gets placed in the User VLAN with full internal access. A personal phone gets placed in the Guest VLAN with internet access only. A device that fails posture checking (outdated OS, missing patches, no antivirus) gets placed in a remediation VLAN that only allows access to the patching server. This is Zero Trust at the network layer -- every device must prove its identity and health before it receives any network access at all.

The Wi-Fi angle is especially important. In episode 30, we broke WPA2-PSK (the shared passphrase model) by capturing a 4-way handshake and cracking the key offline. With WPA2/3 Enterprise (which uses 802.1X for authentication), there is no shared passphrase to crack. Each user authenticates individually with their own credentials (or ideally a device certificate), and the encryption keys are derived per-session, per-user. Capturing one user's handshake gives you nothing useful against another user's traffic. The entire class of wireless attacks that relied on a shared pre-shared key becomes irrelevant.

Network Monitoring and Visibility

Firewalls, IDS, and segmentation are all preventive and detective controls. But you also need full network visibility -- the ability to see every connection, every DNS query, every file transfer, and every protocol negotiation across your entire network. That is where Zeek and RITA come in:

# Zeek (formerly Bro) -- network security monitor
apt install zeek

# Zeek generates structured logs of ALL network activity:
# conn.log: every connection (src, dst, port, bytes, duration)
# dns.log: every DNS query and response
# http.log: every HTTP request (method, URI, user-agent, status)
# ssl.log: every TLS handshake (version, cipher, certificate)
# files.log: every file transferred over the network
# notice.log: detected anomalies

# These logs feed into your SIEM for correlation.
# Example detection: find C2 beaconing
# Query conn.log for connections to the same destination
# at regular intervals (e.g., every 60 seconds +/- jitter)

# RITA (Real Intelligence Threat Analytics)
# Analyzes Zeek logs specifically for C2 detection
# Identifies: beaconing, DNS tunneling, long connections
rita import --import-dir /opt/zeek/logs/current/ -d analysis
rita show-beacons -d analysis
# Shows hosts with periodic connection patterns (likely C2)

Zeek is fundamentally different from Suricata. Suricata uses signatures -- it looks for known patterns of known attacks. Zeek does not detect anything by itself. Instead, it creates a comprehensive, structured record of EVERYTHING that happens on the network. Every single connection, every query, every handshake. Every TCP connection, every DNS query, every HTTP request, every TLS certificate -- all logged in structured JSON format that can be shipped to a SIEM for analysis and correlation. Where Suricata says "I saw Cobalt Strike," Zeek says "here is every connection that happened in the last 24 hours, with source, destination, duration, bytes transferred, protocol, and timing -- YOU figure out which ones are suspicious."

RITA (Real Intelligence Threat Analytics) is the analysis layer on top of Zeek that specifically hunts for C2 communication patterns. Remember from episode 62 how C2 beacons work: the implant calls home at regular intervals (say, every 60 seconds with some random jitter), waiting for commands from the attacker. This beaconing pattern is very hard to spot in real time but becomes obvious in aggregate -- RITA analyzes hours or days of Zeek connection logs and identifies hosts that connect to the same external destination at suspiciously regular intervals. A browser visiting google.com generates irregular, bursty traffic patterns. A C2 beacon generates periodic, metronomic patterns. RITA assigns a "beacon score" to each destination based on how regular the timing is, how consistent the data sizes are, and how the pattern compares to normal browsing behavior. A beacon score above 0.7 or so is almost certainly a C2 implant.

The combination of Zeek for data collection and RITA for beaconing analysis catches the C2 traffic that Suricata's signatures missed -- the attacker who changed their Cobalt Strike default port, modified the named pipe, and customized the traffic profile to avoid signature detection. They can change the fingerprint, but they cannot change the fundamental beaconing behavior without breaking the C2 communication channel itself. This is behavioral detection versus signature detection, and it is significantly harder to evade.

Defense: The Complete Network Security Stack

Layer 1 -- Perimeter: NGFW with TLS inspection, IPS, URL filtering
Layer 2 -- Segmentation: VLANs with inter-VLAN firewall rules
Layer 3 -- Access Control: 802.1X on all switch ports and WiFi
Layer 4 -- Monitoring: Suricata IDS + Zeek NSM + DNS logging
Layer 5 -- Analysis: SIEM correlation + RITA beaconing detection
Layer 6 -- Response: automated blocking via SOAR integration

No single layer is sufficient. Each catches what the others miss.
The firewall blocks known-bad. The IDS detects known-attacks.
Zeek logs everything for forensics. RITA finds the unknown C2
that the firewall and IDS missed. 802.1X prevents unauthorized
devices. Segmentation contains whatever gets through.

This six-layer stack is the network implementation of the defense-in-depth principle from episode 53. Layer 1 (the NGFW) stops the obvious attacks -- known malicious IPs, known malware signatures, prohibited application categories. Layer 2 (segmentation) limits the blast radius when Layer 1 fails. Layer 3 (802.1X) prevents unauthorized devices from reaching any layer at all. Layer 4 (monitoring) sees what Layers 1-3 allowed through. Layer 5 (analysis) finds patterns in Layer 4's data that indicate compromise. And Layer 6 (response) closes the loop by automatically blocking newly discovered threats -- feeding RITA's beacon detections back into the NGFW's block lists, for example.

No single layer is sufficient, and that is the entire point. The attacker who bypasses the NGFW with a custom C2 protocol hits the IDS signatures. The attacker who evades the IDS signatures shows up in Zeek's connection logs. The attacker who hides in legitimate-looking HTTPS traffic gets caught by RITA's beaconing analysis. And the attacker who somehow evades ALL of these detection layers is still contained by segmentation -- they compromised one workstation in VLAN 10 but cannot reach the database in VLAN 30 or the domain controller in VLAN 40. The network architecture itself limits what the attacker can achieve, even in the worst case where every detection control fails. That is what "defense in depth" actually means -- not just "more tools," but layers that each address different failure modes.

All of these logs and alerts -- from the NGFW, from Suricata, from Zeek, from DNS logging, from 802.1X authentication events -- need to go somewhere centralized where they can be correlated, analyzed, and acted upon. That centralized visibility is what transforms raw data into actionable intelligence, and it is the natural next step from everything we have built in this episode.

The AI Slop Connection

AI-generated network configurations consistently create flat, unsegmented networks with permissive firewall rules. Ask an AI to configure a corporate network and you will get a single subnet with a single firewall rule that says "allow all outbound." Ask it to fix a connectivity issue and it will suggest disabling the firewall, opening all ports, or adding an "allow any any" rule -- because those suggestions "fix" the immediate problem by removing the security control that caused it.

AI suggests "allow all" rules to fix connectivity, opens management ports to the entire network, and recommends disabling TLS inspection because "it causes certificate errors." Every one of these suggestions undoes a specific control from this episode. The "allow all" rule eliminates segmentation. Opening management ports to the entire network bypasses the Management VLAN isolation. Disabling TLS inspection blinds your monitoring to 75%+ of traffic.

Network security requires architectural thinking -- understanding traffic flows, trust boundaries, and blast radius. An AI that recommends opening port 3306 to the entire network because "the web app cannot connect to the database" has no concept of segmentation. The correct fix is to allow port 3306 FROM the Server VLAN TO the Database VLAN only. The AI fix is to allow port 3306 FROM everywhere TO everywhere -- and now every compromised workstation can connect directly to the database server. The difference between a secure network and an insecure one is not the technology deployed (you can buy the most expensive NGFW on the market and still be compromised if it is misconfigured). The difference is the architecture -- the deliberate, thought-through design of trust boundaries, access rules, and monitoring coverage. A network designed by AI is a network designed to be exploited.

Exercises

Exercise 1: Deploy Suricata in IDS mode on your lab network. Write 3 custom detection rules: (a) detect Nmap SYN scans (flags: S; threshold: ...), (b) detect reverse shell connections to common ports (4444, 4443), (c) detect base64-encoded PowerShell in HTTP traffic. Test each rule by performing the corresponding attack and verify the alert fires. Save the rules and test results to ~/lab-notes/suricata-custom-rules.md.

Exercise 2: Design a segmented network architecture for a company with 200 employees, 50 servers, and 3 offices connected via VPN. Draw the network diagram showing: VLANs, firewall placement, IDS sensor placement, DMZ, management plane, and internet breakout. Specify firewall rules between each segment. Identify which attacks from this series each segment boundary prevents. Save to ~/lab-notes/segmented-network-design.md.

Exercise 3: Install Zeek and RITA in your lab. Generate normal traffic for 30 minutes (web browsing, DNS queries). Then run a C2 implant with a 60-second beacon interval for 30 minutes. Analyze with RITA: does show-beacons identify the C2 traffic? What is the beacon score? Document the detection and explain what network characteristics RITA uses to identify beaconing. Save to ~/lab-notes/zeek-rita-c2-detection.md.

Thanks for your time!

Hive account@scipio

Leave Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire to:

Written by scipio

Does it matter who's right, or who's left?

Best Posts From scipio

We have not curated any of scipio's posts yet. But you can encourage our curation team to review posts by visiting them regularly and by referring other readers. Because we give priority to frequently read content.

Learn Ethical Hacking (#73) - Network Security Architecture - Defending the Wire