Network Appliances Flashcards

A hardened device inside a protected network that is the sole authorized path for administrative access. Two-step architecture: (1) External admin connects to jump server via SSH/VPN with MFA; (2) From jump server, admin connects to internal target via SSH/RDP. Internal servers accept admin connections only from the jump server's IP — never directly from external sources. All sessions are logged and recorded. Security risk: compromise of the jump server gives an attacker access to all internal systems the jump server can reach — making it the highest-priority hardening target. MFA, continuous monitoring, and strict access control are non-negotiable.

A proxy that controls and inspects outbound traffic from internal users to the internet. Also called an internal proxy. Internal users send requests to the forward proxy; the proxy fetches content from the internet; responses are inspected and returned. The internet sees the proxy's IP, not internal users' real addresses. Functions: URL filtering (blocks unauthorized sites), content scanning (inspects downloads for malware), caching (stores popular responses to reduce bandwidth), access control (user authentication at the proxy). The forward proxy enforces the organization's acceptable use policy for internet access and protects users from malicious internet content.

A proxy that receives inbound traffic from the internet and forwards requests to internal servers. External users connect to the reverse proxy — never to the internal server directly. Security functions: inspects inbound requests for attacks (SQLi, XSS) before forwarding; drops malicious requests at the proxy; hides internal server IP addresses and infrastructure topology. Performance functions: SSL/TLS termination (decrypts HTTPS at proxy, reducing backend crypto load); caching (serves repeated requests from cache without hitting backend servers); load distribution (distributes requests across multiple backend servers). A WAF is typically deployed as a reverse proxy. Reverse proxy faces the internet; internal server faces the reverse proxy.

A publicly accessible proxy server operated by an unknown third party and not controlled by the organization. Users configure their devices to route traffic through the open proxy, bypassing the organization's forward proxy and its content filters, DLP controls, and URL filtering. Security risks: the open proxy operator can view all unencrypted traffic; can inject malicious content into responses; can capture credentials; can exfiltrate data. Open proxies are the wrong answer whenever security improvement is the goal — they route organizational traffic through uncontrolled, potentially hostile infrastructure. Most organizations block known open proxy IP ranges at the perimeter firewall and restrict HTTPS CONNECT tunnels to approved destinations only.

Explicit proxy: User's device is configured with the proxy's IP address and port. The application knows it is using a proxy and sends traffic directly to the proxy. Applications that don't support proxy configuration bypass it entirely. Configuration managed via Group Policy or MDM for managed devices. Transparent proxy: User's device has no proxy configuration and no knowledge a proxy exists. Network infrastructure (router/switch/firewall) silently redirects traffic to the proxy. Works for all traffic; cannot be bypassed by user browser configuration. Requires more complex network setup. Best for: environments with unmanaged or BYOD devices, or where device-level proxy configuration is impractical.

A load balancer configuration in which all backend servers simultaneously receive and handle traffic. The load balancer distributes requests across all active servers. All server capacity is used at all times — maximum throughput. On server failure: load redistributes to remaining active servers (capacity decreases proportionally). Advanced features: TCP offloading (persistent connection pools to backends); SSL offloading (TLS processing centralized at load balancer); caching (repeated requests served from cache); QoS prioritization (critical traffic gets higher priority); content switching (routes requests to specific server pools based on request content). Higher resource efficiency than active/passive; more complex session state management.

A load balancer configuration in which some servers are active (receiving traffic) while others are passive (on standby — running but idle). On active server failure: load balancer detects failure via health check, marks server unavailable, promotes one passive server to active. Service continues at the same capacity level as before the failure. Trade-off vs. active/active: passive servers are idle most of the time — lower resource efficiency, higher cost per unit of active capacity. Advantage: simpler failover management, predictable capacity (active capacity is fixed and known), guaranteed headroom for failure scenarios. Best for: applications where simplicity and predictable failover matter more than maximum throughput.

A load balancer feature where the load balancer performs all TLS encryption and decryption, freeing backend servers from cryptographic processing. Clients connect to the load balancer with HTTPS; the load balancer decrypts using purpose-built crypto hardware; backends receive plaintext HTTP. On the return path, the load balancer re-encrypts before sending to clients. Benefits: backends free from expensive TLS CPU overhead; certificate management centralized on the load balancer (not per-backend); simpler backend configuration. The trade-off: traffic between the load balancer and backends is unencrypted — the internal network segment must be treated as trusted. Also called SSL termination. Load balancers use dedicated hardware accelerators (ASICs) that perform crypto far more efficiently than general-purpose server CPUs.

A load balancer feature that inspects request content (URL path, HTTP headers, cookies, or other application-layer data) and routes requests to specific backend server pools based on that content. Examples: /api/* → API server pool; /stream/* → GPU-enabled media servers; /checkout/* → PCI-compliant payment servers; /static/* → CDN-backed content servers. This allows specialized server pools optimized for different workloads to be managed through a single load balancer front door — the user never knows which pool handled their request. Content switching maximizes efficiency: requests go to servers designed for that specific workload rather than all requests hitting generalist servers.

A platform that collects, normalizes, stores, and correlates security events from across the entire infrastructure. A SIEM receives logs from firewalls, IPS, authentication systems, web servers, databases, endpoints, and cloud services — normalizes them to a common format — and stores them in a searchable database. The correlation engine analyzes events across devices and time periods to identify patterns that no single device could detect: three individually ambiguous events from three different systems that together constitute an attack. A SIEM provides: dashboards (real-time visibility), alert queues (prioritized incidents for SOC review), investigation tools (event timeline reconstruction), and reports (compliance and trend analysis). The correlation engine is what distinguishes a SIEM from a simple log aggregator.