Jump Servers
A jump server (also called a bastion host) is a hardened device inside a protected network that provides the sole authorized path for administrative access to that network. The architecture is intentionally two-step: an external administrator cannot connect directly to an internal server. Instead, they connect first to the jump server, authenticate, and then make their onward connection to the target system from inside the jump server.
External admin → [internet] → Jump server (MFA, hardened, logged) → [internal network] → Target server
The jump server's access methods: administrators connect via SSH, RDP, or VPN tunnel to the jump server. From the jump server, they initiate SSH, RDP, or other administrative protocols to internal systems. The internal servers only accept administrative connections from the jump server's IP address — direct connections from any other source are blocked at the firewall.
The security value of this architecture: it concentrates the entire administrative attack surface into a single, heavily monitored, and hardened system. If all servers are locked to accept admin traffic only from the jump server, an attacker who compromises an administrator's workstation still cannot reach internal servers — they must first compromise the jump server, which requires MFA and generates logged alerts.
The security risk of this architecture: The same property that makes the jump server valuable — it is the single path to all protected systems — also makes it the most valuable single target for an attacker. A compromised jump server is a compromised network. Every internal system the jump server can reach is now reachable by the attacker. This is why jump servers must be:
- Hardened (minimal services, patched, no unnecessary software)
- Multi-factor authenticated (password alone is not sufficient)
- Continuously monitored (every session logged, every command recorded)
- Strictly access-controlled (only authorized administrators can reach it; only from specific source IPs if possible)
Proxy Servers
A proxy server sits in the middle of a conversation between two devices and makes requests on behalf of one of them. In the most common enterprise configuration, internal users communicate to the proxy server rather than directly to internet destinations. The proxy makes the request to the internet, receives the response, inspects it, and passes it back to the original user.
What a proxy can do:
- Caching: The first request to a particular resource is fetched from the internet. The response is cached in the proxy. All subsequent identical requests receive the cached response immediately — no internet round-trip needed. This reduces bandwidth consumption and speeds up responses for popular content.
- URL filtering: The proxy maintains a list of blocked or categorized URLs. Requests to blocked categories (gambling, malware distribution, social media) are refused before the request even leaves the organization. This enforces acceptable use policies and protects users from accidentally visiting malicious sites.
- Content scanning: The proxy inspects the responses it receives from the internet before forwarding them to internal users. If a download contains malware, an exploit kit, or other malicious content, the proxy blocks it at the boundary — the malicious content never reaches the internal user's device.
- Access control: Authentication at the proxy controls which users can access which internet resources. A guest network user might be allowed to reach only specific sites; an engineer might have broader access.
Explicit vs. Transparent Proxies
Proxies are configured in one of two ways from the user's perspective:
- Explicit proxy: The user's operating system or application is explicitly configured with the proxy's IP address and port. The user's browser knows to send all HTTP/HTTPS traffic to the proxy rather than directly to the destination. Applications that do not support proxy configuration may not work through an explicit proxy. The proxy can identify which application made each request.
- Transparent proxy: The proxy intercepts traffic automatically at the network level — the user's device has no proxy configuration and has no awareness that a proxy is in the path. Traffic is redirected to the proxy by the network infrastructure (router, switch, or firewall redirect). Because the user is unaware of the proxy, it is referred to as transparent. The security team can deploy a transparent proxy without requiring configuration changes on user devices.
Forward, Reverse, and Open Proxies
Forward proxy (internal proxy): Sits between internal users and the internet, controlling and inspecting outbound traffic. Internal users' requests go to the forward proxy; the proxy fetches the content from the internet; the response is scanned and returned. The internet-side resource sees the proxy's IP address — not the internal users' real IPs. Used for: URL filtering, content scanning, caching, and enforcing acceptable use policies.
Reverse proxy: Sits in front of internal servers, receiving inbound traffic from the internet and forwarding requests to internal servers on behalf of external users. The external user connects to the reverse proxy — they never see the internal server's real IP address or know how many backend servers exist. The reverse proxy provides: security (inspects inbound requests for attacks before forwarding), caching (caches responses so repeated requests are served from the proxy without hitting the backend), and SSL/TLS termination (decrypts inbound HTTPS at the proxy, forwards unencrypted traffic to backend servers — offloading TLS processing).
Open proxy: A publicly available proxy server operated by an unknown third party. Users route their traffic through the open proxy to bypass organizational security controls — the organization's firewall and content filters see only traffic to the open proxy, not to the actual destination. From a security perspective, open proxies are a significant threat:
- The operator of the open proxy can see all unencrypted traffic passing through it
- The proxy could inject malicious content into responses before delivering them to the user
- Open proxies are commonly used by attackers to exfiltrate data, bypass DLP controls, and access blocked content
- Most organizations block known open proxy IP ranges at the firewall
What Load Balancers Do
A load balancer sits in front of a group of servers and distributes incoming requests across them. From the user's perspective, there is a single server they are communicating with. In reality, the load balancer is splitting traffic across many backend servers — a web server farm, a database cluster, or an application tier — without the user's knowledge or involvement.
Load balancers address two fundamental problems:
- Capacity: A single server can only handle so many concurrent requests. With a load balancer, the capacity of the service scales with the number of backend servers — adding a server adds proportional capacity. This is how large web services handle millions of simultaneous users.
- Fault tolerance: If one backend server fails, the load balancer detects the failure (typically through health checks — it sends periodic test requests to each server and marks unresponsive ones as unavailable) and redistributes traffic to the remaining healthy servers. This convergence is typically very fast — milliseconds to seconds — and most users never notice that a server went offline.
Active/Active Load Balancing
In an active/active configuration, all backend servers connected to the load balancer are active simultaneously — all are receiving and handling traffic. The load balancer distributes requests across all of them according to a scheduling algorithm (round-robin, least connections, IP hash, etc.).
Active/active configurations can include several advanced features:
- TCP offloading: Instead of the load balancer establishing a separate TCP session with each backend server for each client connection, it maintains a persistent pool of open TCP connections to backend servers. Client connections are mapped to existing backend connections rather than requiring new TCP handshakes for each request. This reduces the processing overhead of connection establishment — particularly important for high-request-rate environments.
- SSL/TLS offloading: The load balancer terminates all TLS connections from clients — it performs the cryptographic handshake and decryption. Decrypted traffic is then forwarded to backend servers in plaintext (or with lighter-weight internal encryption). On the return path, the load balancer re-encrypts responses before sending them to clients. Purpose-built cryptographic hardware inside the load balancer performs these operations far more efficiently than general-purpose server CPUs, freeing backend servers from TLS processing overhead.
- Caching: The load balancer can cache frequently requested responses. For identical requests (the same static page, the same image), the cached response is returned directly from the load balancer without the request reaching any backend server. This dramatically reduces backend server load for popular content.
- Prioritization (QoS): Certain application types or specific protocols can be given priority in the load balancer's queue. Critical business applications receive processing priority over lower-priority traffic during periods of congestion.
- Content switching: The load balancer inspects the content of requests and routes them to specific backend servers based on that content. For example: requests for /api/ endpoints go to the API server pool; requests for /images/ go to the static content server pool; requests for /checkout/ go to the payment processing server pool. This allows different server tiers optimized for different workloads to be managed through a single load balancer.
Active/Passive Load Balancing
In an active/passive configuration, the backend servers are divided into two groups: active servers that are currently receiving traffic, and passive (standby) servers that are ready but not currently used.
The active/passive workflow:
- Under normal operation: only active servers receive traffic. Passive servers sit idle but are running and ready.
- On failure detection: the load balancer detects that an active server is unresponsive, marks it unavailable, and promotes one of the passive servers to active status.
- After promotion: the newly active server begins receiving traffic. The failed active server is excluded from the pool.
- After recovery: the failed server is repaired and returned to standby (passive) status, not immediately promoted back to active.
Active/active vs. active/passive trade-offs: Active/active makes full use of all available hardware — every server is producing work all the time. Active/passive wastes the passive servers' capacity (they're running but idle) in exchange for simpler failover management and a predictable headroom buffer. Active/passive is simpler to reason about — the active capacity is fixed and known — but it costs more per unit of active capacity because standby hardware is not contributing to throughput.
Sensors — Where the Data Comes From
Modern networks generate security-relevant data from every device they contain. The challenge is not lack of data — it is aggregating, normalizing, and correlating data from dozens or hundreds of sources into a coherent picture. This is what sensors and collectors provide.
Sensors gather data from specific points in the network. Some devices have built-in sensor capability — they generate logs, statistics, and events as part of their normal operation:
- Intrusion prevention systems: Log every alert, every blocked packet, every signature match. Rich data on what attack traffic is reaching the network boundary.
- Firewalls: Log every permitted and denied connection — source IP, destination IP, port, protocol, timestamp. Connection logs are the foundation of network traffic analysis.
- Authentication systems: Log every successful and failed authentication — username, source IP, timestamp, MFA result. Authentication logs are critical for detecting credential attacks (password spraying, brute force, credential stuffing).
- Web server access logs: Log every HTTP request to the web server — URL, user agent, response code, response size, timing. Essential for detecting web application attacks (SQLi, XSS, path traversal).
- Database transaction logs: Log queries executed against databases — which user, what query, what table, how many rows affected. Unusual query patterns (large data dumps, queries from unexpected accounts) appear here first.
- Email platform logs: Log sent and received messages, attachment scanning results, spam/phishing detections. Email is the primary attack vector for most organizations — email logs are essential threat intelligence.
In addition to built-in device logging, dedicated sensors — standalone appliances whose sole purpose is traffic monitoring — can be placed at network segment boundaries to capture traffic that passes between zones. These provide independent visibility not dependent on what individual devices choose to log.
Collectors — Centralizing the Data
A collector receives data from sensors and stores it in a central database. Without a collector, log data is siloed — each device keeps its own logs in its own format, and correlating events across devices requires manually querying each device separately. A collector aggregates everything into one place.
Collector implementations:
- Syslog servers: The most basic collector. Network devices send log messages to a syslog server using the syslog protocol (UDP/TCP port 514 or TLS syslog on 6514). The syslog server stores these in a searchable log database. Simple, universal, supported by virtually every network device.
- Proprietary management consoles: Many security vendors include a dedicated management console with their product — the IPS management console, the firewall management platform. These consoles collect data from their specific device type and provide reporting tailored to that device's capabilities. The limitation: they only collect from their own vendor's devices.
- SIEM (Security Information and Event Management): The most capable collector category. A SIEM collects from all device types — firewalls, IPS, authentication systems, endpoints, servers, cloud services — normalizes the data into a common format, and provides correlated analysis across all sources. A SIEM does not just store logs — it runs queries, generates alerts, correlates events across time and systems, and provides dashboards and reports that give security teams a unified view of the entire environment.
The SIEM Correlation Engine
The most powerful capability of a SIEM is its correlation engine. Rather than analyzing each event in isolation, the correlation engine compares events across time, across devices, and across users to identify patterns that indicate security incidents.
A single failed login is noise. Twenty failed logins in thirty seconds from the same IP address is a brute force attack. One failed login followed by a successful login followed by a large data download is a credential compromise. An IPS alert from a specific external IP, followed two hours later by a successful VPN connection from the same IP, followed by a database query returning 50,000 rows — these three events in isolation might each be individually explainable, but correlated together they describe a specific attack pattern.
The correlation engine sees all of these events because it receives data from the IPS, the VPN gateway, and the database simultaneously. No individual device has that cross-device visibility — only the SIEM, as the single collector receiving data from all of them, can make that connection.