Quartz 4

12 - Security Architecture

7 min read

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

TypeDescriptionExample
Packet Filtering (Stateless)Examines individual packets in isolation by IP, port, protocolBasic iptables rules
Stateful InspectionTracks connection state, allows return traffic for established connectionsiptables with conntrack
Application Layer (L7)Inspects packet content, understands HTTP/FTP/DNSWAF, proxy firewalls
Next-Generation (NGFW)Combines traditional firewall with IPS, DPI, SSL inspectionPalo 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

iptables — most common Linux firewall utility:

iptables -A CHAIN -s SOURCE -d DESTINATION -p PROTOCOL --dport PORT -j ACTION

ufw — user-friendly frontend for iptables (default on Ubuntu). firewalld — dynamic manager with zones and services (default on CentOS/RHEL). nftables — modern replacement for iptables with better performance.

Network zones (segmentation)

ZoneDescription
Public zoneAccessible from the internet (public web servers)
DMZIntermediate between internal network and outside, hosts public-facing services
Internal zone (intranet)Private network with restricted access for sensitive data
Management zoneExclusive network for system administration with strict access controls

Each zone is separated by firewalls allowing differentiated policies.

Access control models

ModelDescription
DACOwner decides who has access. Flexible but error-prone
MACCentrally defined policies based on security classifications
RBACAccess 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 (firewall/gateway, web server, attacker)

Part 1: Firewall fundamentals and planning

  1. Analyze the provided network diagram and answer:
    • What traffic should be allowed from internet to internal servers?
    • What should be blocked between internal zones?
    • What ports need to be open?
    • What default policies should apply?
  2. Design a firewall rule table with: Rule #, Source, Destination, Port/Protocol, Action, Justification

Part 2: Firewall implementation and testing

  1. Configure firewall VM with iptables:
# Enable IP forwarding
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
 
# Default policies
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
 
# Allow loopback and established connections
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 
# Allow SSH from admin subnet
sudo iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
 
# Allow HTTP/HTTPS to web server
sudo iptables -A FORWARD -p tcp --dport 80 -d <webserver_IP> -j ACCEPT
sudo iptables -A FORWARD -p tcp --dport 443 -d <webserver_IP> -j ACCEPT
  1. Start web server on VM2:
sudo systemctl start apache2
  1. Test from attacker VM:
nc -zv <webserver_IP> 80
nmap -sT -p 1-1000 <webserver_IP>
curl http://<webserver_IP>

? Which ports were accessible before applying the firewall rules, and which were blocked afterward? Did any traffic that you expected to be blocked still get through?

Part 3: Advanced rules and attack simulation

  1. Implement rate limiting and scan protection:
# SSH brute force protection
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name SSH
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --name SSH -j DROP
 
# Anti-scan rules
sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
sudo iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
 
# Logging
sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPT-INPUT-DROP: "
  1. Launch attacks from VM3 and verify protection:
sudo nmap -sS -T4 <target_IP>
hydra -l root -P /usr/share/wordlists/rockyou.txt.gz ssh://<target_IP>

? Did the SSH rate-limiting rules stop the Hydra brute force? How many attempts were allowed before blocking kicked in? What log entries confirmed the block?

  1. Monitor in real-time:
sudo tail -f /var/log/kern.log | grep IPT
watch -n 1 'sudo iptables -L -v -n'

Submission

  • Initial firewall rule table with justifications
  • Command history from all three VMs
  • Screenshots of scans before/after firewall, blocked attacks, allowed traffic
  • Short report (2-3 pages): architecture, attacks attempted, firewall responses, recommendations

Key concepts

TermDefinition
FirewallSystem that monitors and controls network traffic based on rules
DMZIntermediate network zone that hosts isolated public-facing services
RBACAccess control based on roles assigned to users
DACAccess control where the owner decides who has access
iptablesLinux utility for configuring firewall rules
IPSIntrusion detection and prevention systems

Navigation: ← Previous | Home | Next →

Graph View

Backlinks