Listen, Subscribe & Follow:
Eric Flores joins Greg Ferro and Ethan Banks for a discussion about the fundamentals of load balancers, aka “Application Delivery Controllers.” What is a load balancer (ADC)? What’s it good for? How does it work?
The back story of this show is that Eric & Ethan were planning this show many months ago. Then, Eric had a fantastic opportunity to go to work for F5 Networks, who make some of the most popular ADC’s in the industry today. Eric took the gig, and now he’s a New Product Introduction Engineer at F5. Eric settled into the new job, and then we started working on this podcast again.
This was not a sponsored show, but since Eric is working for F5 now, Greg decided to play the curmudgeonly old grump, just to make sure the show didn’t sound like too much like marketing. I mean, hey – Eric works for F5, and I (Ethan) am an F5 fanboy, having working on their kit since 2006. It would be easy to get a bit unbalanced.
All in all, we think we delivered on the goal, which was to introduce load balancer technology on the show. That said, we get into some details too, covering things like TCP proxies, hardware acceleration, SSL offload, and common deployment architectures, like one-armed vs. two-armed.
Links
Share this episode
<>
I was utterly charmed when Ethan pronounced “route” as “root”.
But also, Greg made the claim it’s not worthwhile to be able to log endpoint client IP at the server/application layer, and if a security person claims they need it, one should make it the security team’s responsibility. That last point reminds me of the toxic ITIL siloing of roles, and I would really strongly disagree.
With the rise of end-to-end encryption, strong IDS/IPS has shifted to the server side of things. And this is not new. For years I was at a hosting and development company that specialized in promotions and contests, some of which had rewards that strongly incentivized fraudulent behavior to get rewards. I was the lead on the server team, but we were not strongly siloed–in fact, there was incredibly interplay between the developers, the network team and the server guys, to a degree I’ve rarely seen elsewhere. In one promotion in 2010 that involved hundreds of thousands being donated to social-media-advocated charity that took “votes” from ordinary users, I found substantial indications of fraud based on origin IPs (this was after a layer of SSL termination at Akamai and then again at our LB). I started working on a tool to crunch the data and make a determination of likelihood of fraud based on server-side details that included origin IP (the most important), timing of requests, and aggregate requests from an IP that didn’t match standard behavior (like, no CSS requests, no images requests, etc), plus some things like user-agent, but it turned out bots were sophisticated enough in 2010 to randomize that. It was having that origin IP available that was absolute key to discovering fraud.
Later, we got the app devs involved to implement device fingerprinting via javascript, plus data from users’ PII (they had to log in to vote, and we could datamine their accounts to test if they were realistic users).
Having the endpoint IP strongly correlated to requests and accounts was vastly desirable from a security standpoint. We leveraged that into an entire “trust system” that we stuck into our promotion engine that gave us a competitive edge. Well, until another company acquired us in 2012 for our customer contracts, and then later shut us down.
Thanks, Allen. Reasonable points made on usefulness of endpoint IP. This show is over 2 years old, so to be fair I remember little of the points Greg and I made here along with Eric. My suspicion is that, like many positions we might take on one thing or another, it can indeed be argued both ways depending on your POV–which you have done admirably.