Most websites utilize https:// encryption to secure traffic to/from their webservers. This is a blessing and a curse...it's a blessing because the traffic is unreadable in its encrypted form. It's a curse because, well, the traffic is unreadable in its encrypted form. How will anyone know to block certain traffic (i.e. malware, etc) if its unreadable? The answer is...you can't. In order to inspect this encrypted traffic, you can implement a BIG-IP solution that decrypts the traffic and then sends it to a separate FireEye cluster of servers to inspect and take action on the traffic. In this Lightboard Lesson video, John explains the solution of using a BIG-IP and FireEye device to inspect traffic and keep your webservers safe. Enjoy!
Great integration, however I was working on this integration last year and I could never made it to work in layer 2 using the single Big IP solution (using route domains). F5 engineering informed me that the solution works in layer 3, that is using serveral vlans and subnets on the internal side, FireEye segment and external segment, but what if the customer does not want to change their IP addresses?
Another thing to take into account is a technology named proxy chaining requiered when the customer wants to maintain their explicit proxy, otherwise the proxy communication will not be decrypted and send to the upwards explicit proxy.
What we are looking for is a transparent layer 2 setup without having to change the network infrastructure.
As I said I tested the solution in our lab last year but never got it to work properly:
I think all of the guides I’ve seen seem to be geared towards using the F5 to inspect internal client traffic going out via a forward proxy scenario—is there any documentation on using the F5/FireEye to inspect ingress traffic from the internet while only having a single BIGIP?
