12 - Security Architecture

Security Architecture

Objectives: By the end of this topic, you will be able to…

• Identify weaknesses in network and system architecture
• Use basic tools to validate network exposures
• Apply secure design principles
• Propose well-founded structural improvements

---

Principles of secure architecture

Security architecture consists of applying design principles that protect systems and networks from their conception. Three principles govern access and privilege: least privilege ensures that each component, process, or user has only the permissions strictly needed; separation of privileges divides critical functions among different roles or components so that compromising one does not grant control over all; and minimal exposure reduces the attack surface by limiting exposed services, open ports, and publicly accessible code.

Three additional principles build resilience into the design: defense in depth layers multiple independent security controls so that if one fails, another stops the attacker; fail-safe defaults ensure that in the event of an error the system denies access rather than granting it; and continuous auditing maintains logs of security events and monitors for anomalous behavior so that intrusions are detected and investigated promptly.

---

Firewalls: fundamentals and operation

A firewall is a network security system that monitors and controls incoming and outgoing traffic based on predetermined security rules.

Types of firewalls

Type	Description	Example
Packet Filtering (Stateless)	Examines individual packets in isolation by IP, port, protocol	Basic nftables rules
Stateful Inspection	Tracks connection state, allows return traffic for established connections	nftables with ct state
Application Layer (L7)	Inspects packet content, understands HTTP/FTP/DNS	WAF, proxy firewalls
Next-Generation (NGFW)	Combines traditional firewall with IPS, DPI, SSL inspection	Palo Alto, FortiGate

Firewall architectures

A Bastion Host is a single hardened system that serves as the main external contact point, minimizing the exposed perimeter to one well-defended entry. A Screened Subnet (DMZ) uses multiple firewalls to create isolated network zones for public-facing services, separating them from the internal network. A Dual-Homed Host is a computer with two network interfaces that acts as a gateway between two zones, forwarding only explicitly permitted traffic between them.

Firewall rule design principles

Default Deny (recommended): block all traffic by default, explicitly allow only necessary traffic. More secure, requires careful planning, reduces attack surface.

Rule ordering: rules are processed sequentially top to bottom, first match wins.

1. Allow SSH from admin subnet to server
2. Deny SSH from all other sources
3. Allow HTTP/HTTPS from anywhere to web server
4. Allow DNS from internal network to DNS server
5. Deny all other traffic (default deny)

Linux firewall tools

nftables — modern Linux packet filtering framework; default backend on Debian/Kali since kernel 5.2. Organizes rules in tables → chains → rules and supports named sets, verdict maps, and rate meters in a single unified tool:

nft add rule inet filter input tcp dport 22 accept
nft list ruleset

iptables — the older, widely-documented utility nftables replaces. Still present on many systems; the iptables-nft shim translates iptables commands to nftables internally. ufw — user-friendly frontend for iptables (default on Ubuntu). firewalld — dynamic manager with zones and services (default on CentOS/RHEL); can use nftables as its backend.

---

Network zones (segmentation)

Zone	Description
Public zone	Accessible from the internet (public web servers)
DMZ	Intermediate between internal network and outside, hosts public-facing services
Internal zone (intranet)	Private network with restricted access for sensitive data
Management zone	Exclusive network for system administration with strict access controls

Each zone is separated by firewalls allowing differentiated policies.

---

Access control models

Model	Description
DAC	Owner decides who has access. Flexible but error-prone
MAC	Centrally defined policies based on security classifications
RBAC	Access defined by roles (e.g., “auditor” role has specific permissions)

---

Secure network design

A well-designed network starts at the perimeter with firewalls and continues inward with segmentation by function and sensitivity — critical services like databases and authentication servers are isolated in their own zones, while VPNs provide secure access for remote users. Access control lists (ACLs) restrict lateral movement between segments, and unnecessary services are disabled to reduce the attack surface. Redundancy and fault tolerance are built in from the start so that no single failure becomes a security event.

Operationally, the design must be maintained: IDS/IPS systems are deployed alongside firewalls to detect what the rules miss, firewall rule sets are audited regularly to remove stale or overly permissive entries, all systems receive timely patches, and logs are centralized so that anomalies across the network can be correlated and investigated from a single location.

---

Common architectural failures

Many breaches trace back to a small set of design failures that compound each other. Lack of segmentation places everything on a single flat network, so an attacker who compromises one host can reach all others with no friction. Unnecessary access — services or users with more permissions than their role requires — means that when one account is compromised, the damage radius is far larger than it needed to be. Exposed internal services such as databases or admin panels reachable from the internet hand attackers a direct path to the most sensitive parts of the system. Lack of monitoring lets these intrusions proceed undetected until the damage is severe. Poor default configurations — unchanged vendor passwords, unnecessary services left enabled — provide trivial initial footholds. Missing or misconfigured firewalls remove the fundamental traffic control layer entirely. And a single layer of defense means that defeating the perimeter firewall ends the contest, rather than being just the first obstacle in a series.

---

Hands-on lab

Requirements: 3 Kali Linux VMs — VM1: firewall/gateway (two NICs), VM2: web server, VM3: attacker

Lab setup

The three VMs simulate two network segments separated by a firewall. VM1 sits between them with one interface in each segment. VM2 is a server on the internal segment. VM3 is an attacker on the external segment.

Internet (external)          Firewall/Gateway            Internal network
                          ┌──────────────────┐
  VM3 (attacker)          │       VM1        │                        VM2 (web server)
  10.10.0.10 ─────── eth0                      eth1 ───────────────── 10.20.0.10
  gw: 10.10.0.1           │    10.10.0.1     │                        gw: 10.20.0.1
                          │    10.20.0.1     │
                          └──────────────────┘

VirtualBox network configuration

Create two isolated internal networks — one per segment: net-external and net-internal. In VirtualBox, go to each VM’s Settings → Network:

VM	Adapter	Attached to	Name
VM1	Adapter 1	Internal Network	net-external
VM1	Adapter 2	Internal Network	net-internal
VM2	Adapter 1	Internal Network	net-internal
VM3	Adapter 1	Internal Network	net-external

Note for VMware: use custom VMnet adapters (VMnet2, VMnet3) set to host-only with DHCP disabled, one per segment.

IP configuration

On each VM, assign a static IP. Identify the interface names first with ip link, then edit /etc/network/interfaces or use nmcli:

VM1 — eth0 (external):

sudo ip addr add 10.10.0.1/24 dev eth0
sudo ip link set eth0 up

VM1 — eth1 (internal):

sudo ip addr add 10.20.0.1/24 dev eth1
sudo ip link set eth1 up

VM2 — web server:

sudo ip addr add 10.20.0.10/24 dev eth0
sudo ip link set eth0 up
sudo ip route add default via 10.20.0.1   # firewall as gateway

VM3 — attacker:

sudo ip addr add 10.10.0.10/24 dev eth0
sudo ip link set eth0 up
sudo ip route add default via 10.10.0.1  # firewall as gateway

Verify connectivity before starting

Before touching any firewall rules, confirm the base network works:

# From VM3: firewall external interface should respond
ping -c 2 10.10.0.1
 
# From VM2: firewall internal interface should respond
ping -c 2 10.20.0.1
 
# From VM3: VM2 should NOT be directly reachable (no routing yet)
ping -c 2 10.20.0.10

IP forwarding is disabled by default on Kali, so VM3 cannot reach VM2 until Part 2 enables it. Confirm that now — ping 10.20.0.10 from VM3 should time out. If it succeeds, check that VM1’s forwarding is off:

# On VM1 — should print 0
cat /proc/sys/net/ipv4/ip_forward

These IPs are used throughout the lab. Wherever you see <webserver_IP>, substitute 10.20.0.10; wherever you see <firewall_IP>, substitute 10.10.0.1 (from VM3’s perspective) or 10.20.0.1 (from VM2’s perspective).

Part 1: Network design and planning

Read the following description of a small company’s infrastructure and use it to produce a network diagram and a firewall rule plan.

---

Scenario: A fintech startup runs a customer-facing web application and an internal operations team. The infrastructure has four zones separated by a single firewall/gateway:

• Internet — untrusted external network. Customers access the web app from here. Attackers originate from here too.
• DMZ — hosts one web server running HTTP and HTTPS. It must be reachable from the internet on those ports only. It also needs to reach an internal database to serve dynamic content.
• Internal network — hosts employee workstations (192.168.10.0/24) and a database server (192.168.10.50). The database listens on port 5432. Only the web server should be able to query it — not workstations, not the internet.
• Management zone — a single hardened admin workstation (10.0.0.5) used for SSH access to the firewall and the web server. No other host should be able to SSH into anything.

Additional constraints:

• The firewall itself must not accept connections from the internet or the DMZ — only from the management zone.
• Workstations need outbound internet access (HTTP/HTTPS) but should not accept inbound connections from any zone.
• All inter-zone traffic not explicitly permitted is denied.

---

1. Draw the network diagram. Include: zones, hosts with IPs, the firewall/gateway, and labeled arrows showing which traffic flows are permitted and in which direction.

2. Identify the decisions the description leaves open — things it does not specify but that you have to resolve to write rules. Document each decision and justify your choice.

3. Design a firewall rule table with: Rule #, Source, Destination, Port/Protocol, Action, Justification. Apply default-deny at the end of each chain.

Part 2: Basic nftables setup

nftables organizes rules in a three-level hierarchy: tables hold the ruleset for a given address family; chains attach to a netfilter hook (input, forward, output) and define the default policy; rules are the individual match-and-verdict statements evaluated top to bottom.

The inet address family covers both IPv4 and IPv6 in a single table, which is the modern default.

1. Enable IP forwarding on VM1 so it can route between interfaces:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

2. Write the baseline ruleset to a file. nftables accepts a declarative configuration that can be loaded atomically — safer and more readable than issuing rules one at a time:

sudo tee /etc/nftables-lab.conf << 'EOF'
#!/usr/sbin/nft -f
 
flush ruleset
 
table inet filter {
 
    # Named set: hosts allowed to SSH into the firewall
    set admin_hosts {
        type ipv4_addr
        elements = { 10.20.0.10 }   # replace with your admin VM IP
    }
 
    chain input {
        type filter hook input priority 0; policy drop;
 
        iif lo accept                          # loopback always allowed
        ct state invalid drop                  # drop malformed packets
        ct state established,related accept    # allow return traffic
 
        ip saddr @admin_hosts tcp dport 22 accept   # SSH from admin only
        log prefix "NFT-INPUT-DROP: " limit rate 5/minute
    }
 
    chain forward {
        type filter hook forward priority 0; policy drop;
 
        ct state established,related accept
 
        # Allow HTTP and HTTPS to the web server only
        tcp dport { 80, 443 } ip daddr <webserver_IP> accept
        log prefix "NFT-FORWARD-DROP: " limit rate 5/minute
    }
 
    chain output {
        type filter hook output priority 0; policy accept;
    }
}
EOF

3. Load the ruleset and verify it:

sudo nft -f /etc/nftables-lab.conf
sudo nft list ruleset          # inspect the active rules
sudo nft list set inet filter admin_hosts   # verify the named set

Question

The ct state established,related accept rule appears above the SSH accept rule in the input chain. nftables evaluates rules top to bottom and stops at the first match. Swap those two rules in the config file, reload, and try to open a new SSH session from the admin host. What happens? Restore the original order afterward. What does this tell you about where connection-tracking rules must sit relative to service-specific rules?

Question

Without editing the config file, add a second IP to the admin set directly: sudo nft add element inet filter admin_hosts { <attacker_IP> }. Verify with nft list set inet filter admin_hosts, then try SSH from VM3 — does it work immediately? Now reload the file with sudo nft -f /etc/nftables-lab.conf. What happened to the element you added manually, and why?

4. Start the web server on VM2:

sudo systemctl start apache2

5. Test from VM3 (attacker) before and after loading the ruleset:

nmap -sT -p 1-1000 <webserver_IP>
curl http://<webserver_IP>
nc -zv <firewall_IP> 22       # should fail from attacker, succeed from admin

Question

Which ports were reachable before the ruleset was loaded? After loading, what changed? Try SSH into the firewall from VM3 — what happens, and why?

Question

The ruleset defines an input chain and a forward chain. What is the difference between traffic that hits each one? If you deleted the forward chain entirely and reloaded, could VM3 still reach the web server on VM2? Verify your answer by trying it.

Part 3: Rate limiting, anti-scan rules, and attack simulation

1. Extend the ruleset with brute-force and scan protections. Edit /etc/nftables-lab.conf and add the following rules inside the input chain, before the log-and-drop line:

        # Drop TCP packets with invalid flag combinations used by scanners
        tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 drop   # NULL scan
        tcp flags & (fin|syn) == (fin|syn) drop              # FIN+SYN scan
        tcp flags & (syn|rst) == (syn|rst) drop              # SYN+RST scan

        # Rate-limit new SSH connections: allow 3 per minute, drop the rest
        tcp dport 22 ct state new \
            limit rate over 3/minute burst 5 packets \
            log prefix "NFT-SSH-RATELIMIT: " drop

Reload atomically:

sudo nft -f /etc/nftables-lab.conf

Question

The config file starts with flush ruleset. Introduce a deliberate syntax error somewhere in the file and try reloading — does the flush take effect before nftables hits the error, leaving you with no rules at all? Fix the error, reload cleanly, then explain why atomic loading matters on a system that must stay protected during updates.

2. Launch attacks from VM3 and observe the firewall’s response:

# Stealth SYN scan and NULL scan
sudo nmap -sS -T4 <firewall_IP>
sudo nmap -sN -T4 <firewall_IP>
 
# SSH brute force
hydra -l root -P /usr/share/wordlists/rockyou.txt.gz ssh://<firewall_IP>

3. Monitor the firewall logs in real time on VM1:

sudo journalctl -kf | grep NFT
# or, if writing to syslog:
sudo tail -f /var/log/syslog | grep NFT

Also watch the rule hit counters update live:

watch -n 1 'sudo nft list ruleset'

Question

Did the rate-limit rule stop Hydra before it could try many passwords? How many attempts were logged before blocking kicked in? Did the NULL scan produce different results than the SYN scan — and why does nftables handle them differently?

4. At the end of the session, save the final ruleset:

sudo nft list ruleset > /etc/nftables-final.conf

Submission

• Initial firewall rule table with justifications (from Part 1)
• Final /etc/nftables-final.conf from all three VMs
• Screenshots: port scan results before/after ruleset, Hydra output, live log lines from journalctl
• Short report (2–3 pages): network architecture used, attacks attempted, how the firewall responded to each, and at least one rule you would add or change based on what you observed

---

Key concepts

Term	Definition
Firewall	System that monitors and controls network traffic based on rules
DMZ	Intermediate network zone that hosts isolated public-facing services
RBAC	Access control based on roles assigned to users
DAC	Access control where the owner decides who has access
nftables	Modern Linux framework for packet filtering, replacing iptables
IPS	Intrusion detection and prevention systems

---

Navigation: ← Previous | Home | Next →