A SOC analyst investigates a series of SQL injection attempts targeting a public-facing web application. The WAF logs show the attacks originated from a single external IP and were successfully blocked. However, when the analyst queries the SIEM for the specific internal host that received the blocked payload, the logs only show traffic hitting the load balancer's VIP. No individual backend server logs contain the attack string. What architectural characteristic most likely explains this lack of host-level attribution?
Select an answer to reveal the explanation.
Short Explanation
Think of a load balancer as a receptionist who forwards calls without writing down who called. If it doesn't preserve the client IP or add a header, your backend logs just see the VIP, not the attacker. That breaks host-level attribution even though the WAF caught the payload.
Full Explanation
Layer 7 load balancers often terminate TLS and proxy application requests. If the device does not preserve the original client IP at the network layer or inject it into a header such as X-Forwarded-For, the backend server receives the request as coming from the load balancer. The server therefore logs the VIP or balancer address rather than the attacker, and the original attack metadata may never reach host telemetry. This makes correlation across WAF, LB, and endpoint logs unreliable. A SIEM filtering rule would not explain absent host logs if the payload had reached the agent, because collection normally precedes indexing and filtering. DNS round robin affects name resolution before the connection is made, not how an established HTTP request is distributed to a backend. A transparent bridge mode generally preserves Layer 3 source information, so it would aid rather than obscure attribution. Exam caveat: Confirm whether the load balancer terminates TLS and whether client IP headers are enabled. Operational check: Review the load balancer configuration and test a request to verify X-Forwarded-For appears in backend logs.