Having previously worked as a system administrator at IBM for over 12 years, maintaining infrastructure used by a global team, Dave joined the Loadbalancer.org support team to further develop his skillset and gain experience of varied customer environments.
Well, do you? After all, everyone likes to have choices, don't they?
OK, so I probably should have read the manual first... But what kind of engineer does that?!
Getting on board with zero trust is the easy part. Actually applying these principles to your architecture is less black and white.
The first question we always ask our customers is: "are you looking for performance, reliability, maintainability — or all three?"
It is understandable that SysAdmins, DevOps, and most in the IT and Security Departments involved want to ensure all load balancers are fully patched and protected, given that our product plays an important role in their topology.
The X-Forwarded-For Header is a simple yet powerful solution to a very common problem. I'm not sure why, but for some reason it also seems to cause a lot of confusion.
The long and short of it is, there are updates to the Linux kernel and glibc packages which will 'fix' the issue
For several years, if an instance was launched in AWS and during the initial configuration an IAM role was not defined, the only option available was to stop/terminate the instance and launch another, however, this has now changed!
I am going to focus on how simple it is to mitigate it when using the SSL termination/offloading options available on a Loadbalancer.org appliance.
Due to the way that PuTTY uses a signed integer variable to store the number of characters to be erased and there was inadequate checking for overflow, there was the potential for an attacker to corrupt important data in certain circumstances.
We are pretty sure Microsoft have quietly fixed this bug and not told anyone... But the story is quite fun so lets leave it here for a lesson in corporate stupidity