Proxy Types — Full Comparison
| Type | Direction | Who Uses It | Primary Functions | Security Risk |
|---|---|---|---|---|
| Forward Proxy | Outbound (internal → internet) | Internal users; their traffic exits through it | URL filtering, content scanning, caching, user authentication, acceptable use enforcement | Low (organization-controlled); can be bypassed by users routing through open proxies |
| Reverse Proxy | Inbound (internet → internal servers) | External users; their requests arrive through it | Hides backend servers, inspects inbound requests, SSL termination, caching, load distribution | Low (organization-controlled); single point of failure for inbound traffic without redundancy |
| Open Proxy | Any (user-configured) | Anyone on the internet; used to bypass restrictions | Circumvents firewall and content filter; anonymizes user traffic; exfiltrates data | HIGH — operated by unknown third party; can inject content, capture credentials, exfiltrate data |
| NAT (simplest proxy) | Outbound (internal → internet) | All internal devices; transparent network-layer function | Translates private IPs to public IPs; hides internal addressing; stateful connection tracking | Very low; does not inspect application content; no URL filtering or content scanning |
Explicit vs. Transparent Proxy
| Attribute | Explicit Proxy | Transparent Proxy |
|---|---|---|
| User/device awareness | Device is configured with proxy IP and port; application knows it is using a proxy | Device has no proxy configuration; user is unaware a proxy exists |
| Configuration required | Each device or application must be configured (manually or via policy) | Network infrastructure (router/switch/firewall) redirects traffic automatically |
| Bypass risk | Applications that don't support proxy config bypass the explicit proxy entirely | All traffic is redirected — harder to bypass without routing around the network redirect |
| HTTPS handling | Straightforward — application sends CONNECT request to proxy for TLS tunneling | Requires SSL inspection (break-and-inspect) to process HTTPS — complex; requires certificate trust |
| Deployment complexity | Device configuration is the complexity — must be managed for all users | Network infrastructure configuration is the complexity — no device changes needed |
| Best for | Managed enterprise devices where configuration can be pushed via policy | Environments with unmanaged devices (guest Wi-Fi, BYOD) where device-level config is not possible |
Forward Proxy vs. Reverse Proxy — Traffic Flow
Forward proxy (outbound, protects users):
Internal user → [Forward Proxy] → Internet website
↑
URL filter, content scan, cache
Website sees: proxy's IP (not the internal user's IP)
User sees: filtered, scanned, possibly cached response
Reverse proxy (inbound, protects servers):
Internet user → [Reverse Proxy] → Internal web server
↑
Inspect requests, SSL termination, cache
Internet user sees: reverse proxy's IP (not the internal server's IP)
Internal server sees: decrypted requests from the proxy (not raw internet traffic)
Load Balancer — Active/Active vs. Active/Passive
| Attribute | Active/Active | Active/Passive |
|---|---|---|
| Server states | All servers receive traffic simultaneously | Some servers active (receiving traffic); others on standby (idle but ready) |
| Resource utilization | High — all servers productive | Lower — standby servers consume power but do no work until needed |
| Capacity | Full combined capacity of all servers | Only active servers contribute capacity; standby provides failover headroom |
| On server failure | Traffic redistributed among remaining active servers; capacity reduced proportionally | Standby server promoted to active; capacity maintained at same level |
| Failover speed | Very fast — no server state change required; just redistributes load | Fast — passive server must be promoted (seconds) |
| Complexity | More complex — all servers must handle any request (session state management) | Simpler — active servers handle all state; passive servers inherit state on promotion |
| Cost efficiency | Higher — all hardware is productive | Lower — standby hardware is idle most of the time |
| Best for | High-traffic applications where maximum throughput is required | Applications where simplicity and predictable failover behavior matter more than throughput |
Active/Active Load Balancer Feature Reference
| Feature | What It Does | Why It Matters |
|---|---|---|
| TCP Offloading | Maintains a persistent pool of open TCP connections to backend servers; maps client connections to existing backend connections | Eliminates per-request TCP handshake overhead; critical for high-request-rate environments |
| SSL/TLS Offloading | Load balancer performs all TLS encryption/decryption using dedicated crypto hardware; backends receive plaintext | Frees backend servers from expensive crypto processing; centralizes certificate management |
| Caching | Stores backend responses; subsequent identical requests served directly from cache without hitting backend | Reduces backend server load; improves response time for repeated requests |
| Prioritization (QoS) | Assigns processing priority to specific applications, protocols, or traffic types | Ensures critical business applications receive resources during congestion periods |
| Content Switching | Inspects request content (URL path, headers, cookies) and routes to specific backend pools based on content | Enables specialized server tiers for different workloads through a single entry point |
Sensor Data Sources — What Each Device Provides
| Sensor Source | Data Provided | What It Detects |
|---|---|---|
| IPS | Signature matches, blocked packets, anomaly alerts, threat source IPs | Network-level attacks, exploit attempts, scanning, known malware traffic |
| Firewall | Permitted/denied connections (src IP, dst IP, port, protocol, timestamp) | Unauthorized connection attempts, policy violations, traffic volume anomalies |
| Authentication system | Successful/failed logins, MFA results, account lockouts, source IP, timestamp | Brute force, password spraying, credential stuffing, impossible travel |
| Web server access log | HTTP requests (URL, user agent, response code, size, timing) | SQLi, XSS, path traversal, directory scanning, application abuse |
| Database transaction log | Queries executed, user account, tables accessed, row counts, timing | Unusual query patterns, bulk data extraction, unauthorized account activity |
| Email platform | Sent/received messages, attachment scan results, phishing/spam detection | Phishing campaigns, malware delivery, data exfiltration via email, BEC |
Collector Types — From Basic to SIEM
| Collector Type | What It Does | Limitation |
|---|---|---|
| Syslog server | Receives syslog messages from any device; stores in searchable log database | No correlation; each log entry treated individually; no cross-device analysis |
| Proprietary console | Vendor-specific management platform; collects from that vendor's devices with rich device-specific features | Only collects from that vendor's devices; cannot correlate across different device types |
| SIEM | Collects from all device types; normalizes to common format; runs correlation rules; provides unified dashboards, alerts, and investigation tools | Complex to deploy and tune; high licensing cost; generates alerts that require human review; correlation rules must be maintained |
Jump Server — Two-Step Access Architecture
Step 1: External admin → [internet] → Jump server
Authentication: password + MFA token
Connection: SSH or VPN to jump server IP
Firewall: only jump server IP exposed externally for admin protocols
Step 2: Jump server → [internal network] → Target server
Connection: SSH, RDP, or other admin protocol
Firewall: target servers accept admin protocols only from jump server IP
Logging: all commands recorded on jump server
Security principle: all internal servers locked to jump server as sole admin source
Attack surface: 1 hardened, MFA-protected, monitored system (not N servers × M admin ports)