Skip to main content

Skillber v1.0 is here!

Learn more

Firewalls Deep Dive

Checking access...

A firewall is a network security device that monitors and controls incoming and outgoing traffic based on predetermined security rules. It is the most fundamental — and most frequently misconfigured — security control in any organisation.

The Evolution of Firewalls

    timeline
    title Firewall Evolution
    1988 : First generation: Packet Filter
         : Cisco PIX, Checkpoint
    1994 : Second generation: Stateful Inspection
         : Tracks connection state
    2000 : Third generation: Application Layer Proxy
         : Understands application protocols
    2007 : NGFW (Next-Gen Firewall)
         : App-ID, User-ID, IPS integrated
    2014 : Cloud Firewalls
         : AWS Security Groups, Azure NSGs
    2020 : FWaaS (Firewall as a Service)
         : Cloud-delivered, SASE architecture
  

Firewall Types

1. Packet Filter (Stateless)

Decisions based solely on packet headers: source/dest IP, port, protocol.

Terminal window
# Stateless packet filter via iptables
# Allows HTTP(S) inbound to web server
iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/0 -d 10.0.1.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 0.0.0.0/0 -d 10.0.1.10 -j ACCEPT
# Blocks all other inbound traffic
iptables -A INPUT -j DROP
# Limitations: Cannot track connection state
# An attacker can send a packet with SYN flag even if connection was never established
ProsCons
Very fast (simple lookups)Cannot detect fragmented packet attacks
Low resource usageVulnerable to IP spoofing
Simple to configureNo application awareness
Suitable for high-throughputCannot track session state

2. Stateful Firewall

Maintains a state table tracking the state of each connection. Only allows packets that match an established connection state.

Terminal window
# Stateful firewall rules (iptables with conntrack)
# Allow established/related traffic
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow new SSH connections from admin subnet only
iptables -A INPUT -p tcp --dport 22 -s 10.0.100.0/24 -m state --state NEW -j ACCEPT
# Allow new HTTP/HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
# Default: drop everything else
iptables -A INPUT -j DROP
ProsCons
Tracks connection state (SYN, SYN-ACK, ACK)Higher resource usage
Prevents many spoofing attacksCan be bypassed by tunnelling
More secure than statelessState table can fill up (DoS vector)
Widely used standard

Connection states tracked:

StateMeaning
NEWFirst packet of a new connection (SYN)
ESTABLISHEDPart of an established bidirectional connection
RELATEDNew connection related to an established one (e.g. FTP data channel)
INVALIDPacket not part of any known connection — should be dropped

3. Next-Generation Firewall (NGFW)

Integrates traditional firewall capabilities with additional features:

FeatureWhat It DoesWhy It Matters
App-IDIdentifies application regardless of portBlocks Skype tunnelling over port 80
User-IDMaps IP to user identityRules based on username, not IP
Content-IDInspects file types, contentBlocks executable files via email
IPSInline intrusion preventionBlocks SQLi, XSS, buffer overflow
SSL DecryptionDecrypts TLS for inspectionCatches malware in encrypted traffic
Threat IntelligenceReal-time threat feedsBlocks known malicious IPs immediately
NGFW Rule Example (Palo Alto style):
Rule Name: "Allow HR to Salesforce"
Source Zone: internal
Source User: HR-Users (group)
Source IP: 10.0.50.0/24
Destination Zone: internet
Destination IP: salesforce.com
Application: salesforce-base
Service: ssl (443)
Action: Allow
Log: Allowed traffic
Profile: vulnerability-protection, anti-malware, url-filtering

4. Web Application Firewall (WAF)

Specifically designed to protect web applications from Layer 7 attacks.

WAF Protects Against:
└─ SQL Injection (SQLi)
└─ Cross-Site Scripting (XSS)
└─ Cross-Site Request Forgery (CSRF)
└─ Remote File Inclusion (RFI)
└─ Local File Inclusion (LFI)
└─ Parameter tampering
└─ Brute force login attempts
└─ DDoS at application layer
Examples: AWS WAF, Cloudflare WAF, ModSecurity, F5 ASM, Imperva

ModSecurity rule example:

Terminal window
# Block SQL injection attempts
SecRule ARGS "@detectSQLi" \
"id:942100,\
phase:2,\
deny,\
status:403,\
msg:'SQL Injection Detected via libinjection',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
severity:'CRITICAL'"

5. Cloud Firewall / Security Groups

Virtual firewalls in cloud environments. Unlike physical firewalls, these are highly dynamic and API-driven.

AWS Security Group example:

{
"IpPermissions": [
{
"IpProtocol": "tcp",
"FromPort": 443,
"ToPort": 443,
"IpRanges": [{"CidrIp": "0.0.0.0/0", "Description": "HTTPS from internet"}]
},
{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"IpRanges": [{"CidrIp": "10.0.100.0/24", "Description": "SSH from admin subnet"}]
},
{
"IpProtocol": "-1",
"UserIdGroupPairs": [{"GroupId": "sg-12345"}],
"Description": "All traffic from web tier"
}
]
}

Key differences from physical firewalls:

Cloud Security GroupPhysical Firewall
Stateful (return traffic auto-allowed)Configuration-dependent
No explicit deny (whitelist only)Can explicitly deny
Cannot inspect contentFull inspection possible
API-managed, changes instantManual or orchestrated changes
Distributed enforcementCentral chokepoint

Firewall Rule Base Design

Default Policies

PolicySecurityUsabilityStandard
Default-DenyMaximumMinimalBest practice
Default-AllowMinimalMaximumDiscouraged

Best practice: Default-deny with explicit allow rules for required traffic.

Rule Ordering

Firewalls process rules from top to bottom. First match wins.

Rule Base Layout (Palo Alto firewall):
Order 1-10: Antivirus / Threat Prevention (auto-generated)
Order 11: [INFRASTRUCTURE] Allow DNS (DNS servers → internet)
Order 12: [INFRASTRUCTURE] Allow NTP (all servers → time.cloudflare.com)
Order 13: [ADMIN] Allow RDP/SSH (admin jump box → all servers)
Order 14: [BUSINESS] Allow HTTPS (web servers → database servers :3306)
Order 15: [BUSINESS] Allow LDAP (app servers → AD domain controllers)
Order 16-25: Business application rules
Order 26: [DENY] Block known malicious IPs (threat intel feed)
Order 27: [DENY] Block high-risk countries (if no business there)
Order 28: [LOG] Log all remaining traffic
Order 29: [DENY] Default-deny — catch-all (LAST RULE)

Rule Design Principles

1. Be Specific — Use source/dest zones, IPs, ports, applications
❌ Allow any any any
✅ Allow internal_zone → dmz_zone tcp/443 (web servers)
2. Least Privilege — Only open what's needed
❌ Allow web_servers to database_servers any any
✅ Allow web_servers to database_servers tcp/3306 (specific DB port)
3. Group Similar Rules — Order by function
❌ Random order of infrastructure, business, admin rules
✅ infrastructure_rules → admin_rules → business_rules
4. Block by Default — Change unused rules to deny
❌ Rules exist for decommissioned apps
✅ Remove or disable unused rules
5. Log + Monitor — Log denies, review rule hits
❌ No logging on deny rules
✅ Log all denies, track rule hit count
6. Review Regularly — Quarterly rulebase audit
❌ No review process
✅ Annual full review, quarterly hit count analysis

Common Firewall Misconfigurations

MisconfigurationRiskDetection
Any/Any rulesNo traffic restrictionAudit rulebase for “any any any”
Shadow rulesHidden rule that overrides intended policy (e.g., earlier allow-any supersedes a later deny)Rulebase analysis tools
Orphan rulesRules for decommissioned systemsMatch rules to asset inventory
Overly permissive outboundData exfiltration possibleEgress filtering audit
Default passwordsAdmin access to firewall itselfPassword audit, credential scanning
No logging on denySilent blocking, can’t troubleshootEnable logging on all deny rules
Rules never reviewedRules accumulate, security driftsQuarterly review process

Real Case: Firewall Misconfiguration at the Office of Personnel Management (OPM)

The 2015 OPM breach (21.5M records, including security clearance data of US intelligence personnel) was enabled by firewall misconfigurations.

Attack Path:
1. Attacker gains initial access via compromised credentials
2. Firewall rules were overly permissive — allowed broad access between segments
3. Once inside, attacker moved laterally to the background investigation database
4. No firewall segmentation between the web tier and the database tier
5. Data exfiltrated over 12+ months before detection
Aftermath:
- Total cost: $500M+ in remediation, credit monitoring
- Director of OPM resigned
- Congressional hearings on federal IT security
- Firewall rules tightened across all federal agencies

Firewall Tuning and Best Practices

Rule Lifecycle Management:
Create:
- Define business justification
- Specify source/dest/app/protocol
- Set expiration/review date
- Assign owner
Test:
- Deploy in monitor-only mode first (log but don't block)
- Verify no legitimate traffic is affected
- Review logs for 7 days before enabling enforcement
Enable:
- Set to enforce
- Monitor initially for false positives
Review (Quarterly):
- Check rule hit count (remove zero-hit rules)
- Verify source/dest/ports still valid
- Check for shadow rules
- Update documentation
Decommission:
- Remove immediately when systems are decommissioned
- Never leave orphan rules

Firewall Performance Considerations

FactorImpactMitigation
Rule countMore rules → slower processingKeep under 1,000 rules per firewall
LoggingLogging every packet → performance hitSample logs, log only denies
SSL decryptionDecrypting all TLS → 2-5x performance hitSelective decryption per policy
IPS/App-IDDeep inspection → 30-50% throughput reductionProfile-based activation
State table sizeFull state table drops new connectionsMonitor table utilization

Key Takeaways

  • Firewalls are the most fundamental network security control but also the most frequently misconfigured — an Any/Any rule effectively disables the firewall
  • Packet filter → Stateful → NGFW → Cloud firewall → FWaaS — choose the type that matches your architecture and risk
  • Default-deny is the only acceptable default policy — default-allow means you have no security boundary
  • Cloud security groups are stateful and API-driven — fundamentally different from physical firewall management
  • The OPM breach (21.5M records stolen) was enabled by flat networks with no firewall between web and database tiers
  • WAFs protect against application-layer attacks (SQLi, XSS) that traditional firewalls cannot see
  • Rule hygiene matters — orphan rules, shadow rules, and any/any rules accumulate over time; quarterly audits are essential
  • Monitor rule hit counts — if a rule has zero hits in 90 days, it should be reviewed for removal
  • SSL decryption is critical but expensive — selectively decrypt based on risk (not all traffic)
  • A firewall is only as good as its configuration — the hardware is irrelevant if the rulebase is poorly designed