Nimbostratus
NimbostratusHello,
Thank you for the response.
About the request logging, particularly " From the Pool Name list, select the pool that includes the node log server as a pool member." I take it that the pool that was created (splunk servers receiving the logs) would be the pool selected?
For the environment in question, a HTTP rule would not work well. All VIPS are defined for HTTPS and all pool members in all pools have HTTPS bound to them.
I will also test with x-forwarding enabled.
The requirement " analysts require end-to-end visibility in relation to network connection events in order to appropriately track potential threats, potentially malicious activity and assist in attack path validation during Cyber events & Cyber incident investigations. Due to the fact that a good majority of our Web-based traffic utilizes F5 VIPs to frontend infrastructure it makes it nearly impossible to determine the actual source of traffic when investigating Cyber events & Cyber incidents on victim infrastructure. The source IP that gets logged in the majority of all host logs is the IP of the VIP"
they are asking to see all traffic, end to end with no obfuscation whatsoever. The environment is such that the actual source addresses are from all over the world. IMHO I do not believe that the function of the F5's is to act as an agent to populate a SIEM. As the environment is using APM (replaced Microsoft Threat Management Gateways) there will be added overhead on the F5's as well.
Employee> About the request logging, particularly " From the Pool Name list, select the pool that includes the node log server as a pool member." I take it that the pool that was created (splunk servers receiving the logs) would be the pool selected?
Yes, that is correct.
> For the environment in question, a HTTP rule would not work well. All VIPS are defined for HTTPS and all pool members in all pools have HTTPS bound to them.
> I will also test with x-forwarding enabled.
If you have client-ssl profiles on the virtual servers, the TLS/SSL traffic is decrypted within the BigIP, and the HTTP events have access to the decrypted traffic, before re-encryption by the server-ssl profile.
And it is this visibility into the traffic that makes the BigIP the ideal data-collection point - the proviso is that data must be logged off-box using the High Speed Logging (HSL) functionality - the BigIP is not optimised for disk-I/O, so local logging at this level of detail will negatively impact performance.