Proxy Servers and Forward/Reverse Proxies

A proxy server is an intermediary device (hardware or software) that sits between clients and servers, forwarding requests and responses on behalf of clients. It acts as a gateway, allowing organizations to control, monitor, and secure traffic. Proxies can be deployed in two primary modes: forward proxy and reverse proxy.

A forward proxy is placed in front of client devices (e.g., user workstations) to manage outbound traffic to the internet. When a client requests a web resource, the request goes to the proxy, which then makes the request on behalf of the client. The target server sees the proxy's IP address, not the client's IP. This provides anonymity and allows the organization to enforce policies such as blocking certain websites, caching content, and logging all outbound requests.

How it works mechanically: 1. Client sends an HTTP GET request to the proxy (e.g., GET http://example.com). 2. Proxy checks its access control list (ACL) to see if the destination is allowed. 3. If allowed, the proxy checks its cache for a cached copy of the resource. 4. If not cached, the proxy establishes a new TCP connection to the target server, using its own IP address. 5. The proxy forwards the request to the server, receives the response, and caches it (if caching is enabled). 6. The proxy sends the response back to the client, potentially modifying headers (e.g., stripping the Via header or adding X-Forwarded-For).

Key variants: - Transparent proxy: Intercepts traffic without client configuration. The client is unaware of the proxy. Often used in captive portals or for content filtering. The proxy can still modify headers, but the client does not need to set proxy settings. - Anonymous proxy: Hides the client's IP but reveals itself as a proxy. The server sees the proxy's IP and knows a proxy is used. - High anonymity proxy (elite proxy): Hides both the client's IP and the fact that a proxy is being used. The server sees the proxy's IP but no proxy headers.

Standards and ports: - HTTP proxy: port 8080 (common), 3128 (Squid default). - SOCKS proxy: port 1080. SOCKS5 supports authentication and UDP. - RFC 2616 (HTTP/1.1) defines proxy behavior.

A reverse proxy is placed in front of internal servers (e.g., web servers, application servers) to manage inbound traffic from the internet. It receives client requests and forwards them to the appropriate backend server. Clients interact only with the reverse proxy, never directly with the backend servers. This provides load balancing, SSL termination, caching, and protection against attacks like DDoS.

How it works mechanically: 1. A client sends an HTTP request to https://www.example.com. 2. DNS resolves the domain to the reverse proxy's public IP. 3. The reverse proxy receives the request, terminates the TLS connection (if HTTPS), and inspects the request. 4. Based on rules (e.g., URL path, load balancing algorithm), the proxy selects a backend server (e.g., 10.0.1.10:80). 5. The proxy establishes a new TCP connection (often HTTP) to the backend server, forwarding the request. 6. The backend server processes the request and sends the response back to the proxy. 7. The proxy may cache the response, add headers (e.g., X-Forwarded-For), and then send the response to the client over the original TLS connection.

Key features: - Load balancing: Distributes requests across multiple servers using algorithms like round-robin, least connections, or IP hash. - SSL/TLS termination: Offloads encryption/decryption from backend servers, reducing their CPU load. - Web Application Firewall (WAF): Inspects traffic for malicious patterns (SQL injection, XSS) before forwarding. - Caching: Stores static content to reduce backend load.

Common tools: - Nginx: Popular reverse proxy and load balancer. Configuration example:

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

| Aspect | Forward Proxy | Reverse Proxy | |--------|---------------|---------------| | Purpose | Protects clients | Protects servers | | Direction | Outbound traffic | Inbound traffic | | Client awareness | Clients must be configured (or transparent) | Clients are unaware | | Server knowledge | Server sees proxy's IP | Server sees proxy's IP (internal) | | Typical use | Content filtering, anonymity, caching for users | Load balancing, SSL termination, WAF |

Attackers can use proxies to anonymize malicious traffic. For example, an attacker might chain multiple anonymous proxies (proxy chains) to hide their origin when launching attacks. Defenders must be able to detect proxy usage by analyzing headers like X-Forwarded-For or Via, or by using IP reputation databases.

Defenders deploy reverse proxies to mitigate attacks: - DDoS mitigation: The reverse proxy can absorb traffic and filter malicious packets before they reach backend servers. - Web application firewall: Integrated WAF blocks common web attacks. For example, ModSecurity running on Nginx can inspect requests for SQL injection patterns. - TLS inspection: Forward proxies can decrypt outbound HTTPS traffic (with appropriate certificates installed) to inspect for malware or data exfiltration. This is known as SSL/TLS interception or man-in-the-middle (MITM) proxy.

Real command/tool examples: - Squid (forward proxy): squid -z initializes cache directories. Configuration file /etc/squid/squid.conf. - cURL with proxy: curl -x http://proxy:8080 http://example.com. - Check proxy headers: curl -I http://example.com may show Via: 1.1 proxy.local.

Both forward and reverse proxies can cache content to improve performance. Forward proxies cache frequently accessed web pages for users, reducing bandwidth. Reverse proxies cache static assets (images, CSS) to offload backend servers. Cache control is managed via HTTP headers like Cache-Control, Expires, and ETag.

Forward proxies can require authentication (e.g., NTLM, Basic, Digest) before allowing outbound traffic. Reverse proxies can authenticate clients (e.g., via OAuth, client certificates) before granting access to backend applications.

Proxies generate logs that are invaluable for security analysis. Forward proxy logs show every outbound request, including URLs, timestamps, and user identities. Reverse proxy logs show inbound requests and backend responses. These logs can be fed into SIEM systems for anomaly detection.

For SY0-701, know:

Scenario 1: Insider Threat Detection via Forward Proxy

A SOC analyst notices unusual outbound traffic from a single workstation: connections to a file-sharing site at 3 AM. The forward proxy logs show the user's IP, the full URL, and the amount of data transferred (500 MB). The analyst queries the SIEM for the user's activity over the past week, finding multiple large uploads to the same site. The correct response is to escalate to the incident response team, who interview the user and discover they are exfiltrating customer data. The forward proxy logs provided the evidence. A common mistake is to ignore the alert because the site is not on the block list; instead, the analyst should recognize the anomalous volume and timing.

Scenario 2: Reverse Proxy Mitigating DDoS

An e-commerce site experiences a sudden surge in traffic during a flash sale. The reverse proxy (HAProxy) detects a high number of requests from a single IP range (likely a botnet). The proxy's rate limiting feature kicks in, dropping requests exceeding 100 per second per IP. Legitimate users are unaffected because the proxy continues to serve cached content and load balances across healthy servers. The engineer reviews HAProxy stats via its web interface and sees the blocked IPs in the 'denied' counter. The correct response is to adjust rate limits if needed and add the IP range to a permanent block list. A common mistake is to block all traffic from the range without verifying if it includes legitimate users (e.g., a corporate VPN).

Scenario 3: SSL Interception for Malware Analysis

An organization deploys a forward proxy with SSL interception to inspect all HTTPS traffic. A user's workstation tries to connect to a command-and-control (C2) server using HTTPS. The proxy decrypts the traffic and the integrated malware detection engine identifies a known malicious pattern (e.g., a specific HTTP user-agent string). The proxy blocks the connection and logs the event. The SOC team receives an alert and investigates the workstation, finding a trojan. The correct response is to quarantine the workstation and perform forensic analysis. A common mistake is to disable SSL interception due to performance concerns, leaving encrypted threats undetected.