39 Outbound vs Inbound-Initiated Connections
This is a critical security concept, especially in healthcare networks. Let me explain.
39.1 The Core Principle
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ OUTBOUND-INITIATED: Internal device STARTS the connection → ALLOWED │
│ │
│ INBOUND-INITIATED: External device STARTS the connection → BLOCKED │
│ │
└─────────────────────────────────────────────────────────────────────────────┘This is the default security posture for most enterprise/hospital networks.
39.2 Visual Explanation
FIREWALL
│
HOSPITAL │ INTERNET
INTRANET │
│
│
┌──────────────┐ │ ┌──────────────┐
│ Workstation │ │ │ Google │
│ 10.6.34.100 │ │ │ Server │
│ │ │ │ │
│ START ────┼────────►│─────────┼──► OK ✓ │ OUTBOUND-INITIATED
│ connection │ │ │ │ Connection allowed
│ │◄────────┼─────────┼──── Reply │ (response comes back)
│ │ │ │ │
└──────────────┘ │ └──────────────┘
│
│
┌──────────────┐ │ ┌──────────────┐
│ PACS Server │ │ │ Attacker │
│ 10.6.23.50 │ │ │ Hacker │
│ │ │ │ │
│ X ◄─────┼─────────┼─────────┼──── START │ INBOUND-INITIATED
│ BLOCKED! │ ▲ │ │ connection │ Connection blocked!
│ │ │ │ │ │
│ │ │ │ │ │
└──────────────┘ │ │ └──────────────┘
│ │
│ │
Firewall blocks unsolicited
incoming connections39.3 How Stateful Firewalls Enable This
The firewall tracks who initiated the connection:
┌─────────────────────────────────────────────────────────────────────────────┐
│ STATEFUL FIREWALL CONNECTION TABLE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Connection 1 (Outbound-initiated by internal host): │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ Internal: 10.6.34.100:52431 → External: 142.250.80.46:443 │ │
│ │ State: ESTABLISHED │ │
│ │ Initiated by: INTERNAL ← Firewall remembers this! │ │
│ │ Verdict: ALLOW outgoing packets, ALLOW response packets │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Connection 2 (Inbound-initiated by external host): │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ External: 203.0.113.50:48721 → Internal: 10.6.23.50:443 │ │
│ │ State: NEW (no matching outbound connection) │ │
│ │ Initiated by: EXTERNAL │ │
│ │ Verdict: DROP ✗ (no rule allows this) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘39.4 Firewall Rules That Implement This
┌─────────────────────────────────────────────────────────────────────────────┐
│ TYPICAL HOSPITAL FIREWALL RULES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ # OUTBOUND: Allow internal hosts to initiate connections to internet │
│ ALLOW src=10.6.0.0/16 dst=ANY port=443 proto=TCP state=NEW,ESTABLISHED│
│ ALLOW src=10.6.0.0/16 dst=ANY port=80 proto=TCP state=NEW,ESTABLISHED│
│ │
│ # INBOUND: Only allow ESTABLISHED (responses to our requests) │
│ ALLOW src=ANY dst=10.6.0.0/16 state=ESTABLISHED,RELATED │
│ ▲ │
│ │ │
│ No "state=NEW" here! Only responses allowed. │
│ │
│ # Block everything else │
│ DENY src=ANY dst=ANY │
│ │
└─────────────────────────────────────────────────────────────────────────────┘39.5 Real-World Hospital Scenario
ALLOWED: Radiologist downloads AI model update
──────────────────────────────────────────────
Workstation Firewall Cloud Server
10.6.34.100 (AI vendor)
│ │ │
│ 1. SYN (NEW) ──────────►│───────────────────────────►│
│ "I want to connect" │ Outbound NEW = OK ✓ │
│ │ │
│◄─────────────────────────│◄─────────── 2. SYN-ACK ────│
│ │ Response = OK ✓ │
│ │ │
│ 3. ACK, Data ──────────►│───────────────────────────►│
│◄─────────────────────────│◄─────────── 4. Data ───────│
│ (download) │ │
BLOCKED: External attacker tries to access PACS
───────────────────────────────────────────────
PACS Server Firewall Attacker
10.6.23.50 203.0.113.99
│ │ │
│ │◄─────────── 1. SYN (NEW) ──│
│ │ Inbound NEW = BLOCK ✗ │
│ │ │
│ Never reaches │ Connection │
│ the server! │ dropped │
│ │ │39.6 NAT Also Plays a Role
Most hospital networks use NAT (Network Address Translation), which inherently supports this pattern:
┌─────────────────────────────────────────────────────────────────────────────┐
│ NAT GATEWAY │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ INTERNAL NETWORK NAT INTERNET │
│ (Private IPs) (Public IP) │
│ │
│ 10.6.34.100 ─────┐ │
│ 10.6.34.101 ─────┼──────► NAT Gateway ──────► 203.0.113.1 │
│ 10.6.34.102 ─────┘ (translates) (single public IP) │
│ │
│ The NAT maintains a translation table: │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Internal │ External (NAT'd) │ Remote │ │
│ ├─────────────────────┼──────────────────────┼─────────────────────┤ │
│ │ 10.6.34.100:52431 │ 203.0.113.1:40001 │ 142.250.80.46:443 │ │
│ │ 10.6.34.101:48210 │ 203.0.113.1:40002 │ 151.101.1.140:443 │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ Without an entry in this table, incoming packets have │
│ NOWHERE TO GO → automatically dropped! │
│ │
└─────────────────────────────────────────────────────────────────────────────┘39.7 When Inbound IS Allowed (Exceptions)
Sometimes you DO need to allow inbound connections. This requires explicit rules:
SCENARIO: Hospital hosts a patient portal accessible from internet
─────────────────────────────────────────────────────────────────
INTERNET
│
▼
┌─────────────────┐
│ External │
│ Firewall │
│ │
│ ALLOW inbound │◄── Explicit rule:
│ to DMZ:443 │ ALLOW src=ANY dst=DMZ port=443
└────────┬────────┘
│
▼
┌─────────────────┐
│ DMZ │
│ │
│ Web Portal │◄── Only this server exposed
│ (port 443) │
│ │
└────────┬────────┘
│
┌────────┴────────┐
│ Internal │
│ Firewall │
│ │
│ Very restricted │◄── DMZ can only access specific
│ rules │ backend services
└────────┬────────┘
│
▼
┌─────────────────┐
│ BACK ZONE │
│ (Databases) │◄── Never directly exposed
└─────────────────┘39.8 Summary Table
| Connection Type | Direction | Default Policy | Example |
|---|---|---|---|
| Outbound-initiated | Internal → External | ALLOW | Workstation browsing Google |
| Inbound-initiated | External → Internal | DENY (unless explicit rule) | Attacker scanning ports |
| Response traffic | External → Internal | ALLOW (stateful tracking) | Google responding to request |
| DMZ services | External → DMZ | ALLOW (specific ports only) | Patient accessing portal |
39.9 Why This Matters for Healthcare
┌─────────────────────────────────────────────────────────────────────────────┐
│ SECURITY BENEFITS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. ATTACK SURFACE REDUCTION │
│ - Attackers can't directly reach internal servers │
│ - Port scans from internet see nothing │
│ │
│ 2. DATA EXFILTRATION MONITORING │
│ - All outbound traffic passes through firewall │
│ - Can inspect/log what's leaving the network │
│ │
│ 3. COMPLIANCE (HIPAA, etc.) │
│ - PHI (Protected Health Information) stays protected │
│ - Audit trail of all connections │
│ │
│ 4. RANSOMWARE MITIGATION │
│ - External command & control servers can't initiate │
│ - (Though malware inside CAN connect out - need other controls) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘