Jeff McJunkin
Eric CapuanoPro tip for network & system admins... If you have a load balancer set up in front of your web-facing servers (like OWA, etc), please consider enabling the X-Forwarded-For header to make log analysis easier during the inevitable IR. This header captures the actual source IP of the request and passes it to the backend server, despite the traffic appearing to come from the load balancer's IP. #infosec #DFIR
J. R. DePriest 
:EA DATA. SF:@eric_capuano you sound like you speak from experience. This is a conversation we've had to have more than once, as well.
Whitney Champion πͺ@jrdepriest @eric_capuano π―π―π―π―π―
Nick Craver@eric_capuano worth noting the now-standardized Forwarded header if supported (supported on a lot of platforms now): https://datatracker.ietf.org/doc/html/rfc7239
RFC 7239: Forwarded HTTP Extension
This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.
β@eric_capuano Did they try to tell you that not setting X-Forwarded-For was more secure? That's always fun.
Chris Elgee@jrdepriest @eric_capuano If you try hard enough, you can make XFF a vulnerability (e.g., trust if forwarded from X internal system). Just... don't do that. You'll be fine. (-:
Matthew Gracie@eric_capuano You can also configure tools like Suricata to log this IP either instead of or in addition to the inner load balancer IP, which is very helpful.
πππ’ππ‘ πΈπ₯π₯ππ§As a long time IR guy, this is an evergreen reminder.
Year after year, engagement after engagement.
Fritz Adalis@eric_capuano
XFF on should be a default. Also note you need to terminate tls at the load balancer to add the header. (You can do a new sesson from the lb to server.)
XFF on should be a default. Also note you need to terminate tls at the load balancer to add the header. (You can do a new sesson from the lb to server.)
~# sudohuman@eric_capuano "jeeze we sure get a lot of malicious traffic from 10.10.0.2, think we should block it?"
Gary Pullis@eric_capuano Reminder that this has to be configured in 3 places: Load balancer, web server, log aggregation tool (SIEM).
And, the header is not always called X-Forwarded-For. Depends on the load balancer setup. Then, the web server needs to be configured to log the header, and you SIEM needs to understand how to ingest the header.
You want to log both IPs: (1) the X-Forwarded-For IP of the "real client", and (2), the IP that accessed the web server directly. The value of collecting the "direct IP" is that it will tell you if the client connected via your load balancer or if they bypassed the load balancer. If you skip the "direct IP" then your logs will have no IP address at all when someone bypasses your load balancer, and that's a real bummer.
But, yeah, holy cow, the sadness of not having real client IPs in your logs is intense.
Goupil@eric_capuano and log the header in the backend
Peesha Deel 
@eric_capuano Do you worry about spoofed IPs using this header? I use that header during pen tests to bypass some source validation checks.