2.5 bad ways to implement a server load balancing architecture
I'm in a bit of mood after reading a Javaworld article on server load balancing that presents some fairly poor ideas on architectural implementations. It's not the concepts that are necessarily wrong; they will work. It's the architectures offered as a method of load balancing made me do a double-take and say "What?" I started reading this article because it was part 2 of a series on load balancing and this installment focused on application layer load balancing. You know, layer 7 load balancing. Something we at F5 just might know a thing or two about. But you never know where and from whom you'll learn something new, so I was eager to dive in and learn something. I learned something alright. I learned a couple of bad ways to implement a server load balancing architecture. TWO LOAD BALANCERS? The first indication I wasn't going to be pleased with these suggestions came with the description of a "popular" load-balancing architecture that included two load balancers: one for the transport layer (layer 4) and another for the application layer (layer 7). In contrast to low-level load balancing solutions, application-level server load balancing operates with application knowledge. One popular load-balancing architecture, shown in Figure 1, includes both an application-level load balancer and a transport-level load balancer. Even the most rudimentary, entry level load balancers on the market today - software and hardware, free and commercial - can handle both transport and application layer load balancing. There is absolutely no need to deploy two separate load balancers to handle two different layers in the stack. This is a poor architecture introducing unnecessary management and architectural complexity as well as additional points of failure into the network architecture. It's bad for performance because it introduces additional hops and points of inspection through which application messages must flow. To give the author credit he does recognize this and offers up a second option to counter the negative impact of the "additional network hops." One way to avoid additional network hops is to make use of the HTTP redirect directive. With the help of the redirect directive, the server reroutes a client to another location. Instead of returning the requested object, the server returns a redirect response such as 303. I found it interesting that the author cited an HTTP response code of 303, which is rarely returned in conjunction with redirects. More often a 302 is used. But it is valid, if not a bit odd. That's not the real problem with this one, anyway. The author claims "The HTTP redirect approach has two weaknesses." That's true, it has two weaknesses - and a few more as well. He correctly identifies that this approach does nothing for availability and exposes the infrastructure, which is a security risk. But he fails to mention that using HTTP redirects introduces additional latency because it requires additional requests that must be made by the client (increasing network traffic), and that it is further incapable of providing any other advanced functionality at the load balancing point because it essentially turns the architecture into a variation of a DSR (direct server return) configuration. THAT"S ONLY 2 BAD WAYS, WHERE'S THE .5? The half bad way comes from the fact that the solutions are presented as a Java based solution. They will work in the sense that they do what the author says they'll do, but they won't scale. Consider this: the reason you're implementing load balancing is to scale, because one server can't handle the load. A solution that involves putting a single server - with the same limitations on connections and session tables - in front of two servers with essentially the twice the capacity of the load balancer gains you nothing. The single server may be able to handle 1.5 times (if you're lucky) what the servers serving applications may be capable of due to the fact that the burden of processing application requests has been offloaded to the application servers, but you're still limited in the number of concurrent users and connections you can handle because it's limited by the platform on which you are deploying the solution. An application server acting as a cluster controller or load balancer simply doesn't scale as well as a purpose-built load balancing solution because it isn't optimized to be a load balancer and its resource management is limited to that of a typical application server. That's true whether you're using a software solution like Apache mod_proxy_balancer or hardware solution. So if you're implementing this type of a solution to scale an application, you aren't going to see the benefits you think you are, and in fact you may see a degradation of performance due to the introduction of additional hops, additional processing, and poorly designed network architectures. I'm all for load balancing, obviously, but I'm also all for doing it the right way. And these solutions are just not the right way to implement a load balancing solution unless you're trying to learn the concepts involved or are in a computer science class in college. If you're going to do something, do it right. And doing it right means taking into consideration the goals of the solution you're trying to implement. The goals of a load balancing solution are to provide availability and scale, neither of which the solutions presented in this article will truly achieve.
APM :: Portal Access Lists :: SNI & HTTP
I'm trying to create a Portal Access List with a few web resources, and one of the links does not work because it is an Apache server that is validating that the SNI and HTTP hostname match. The problem is, that when the user logs into APM and launches the web link, they are launching a request to the APM and not the backend server... therefore the SNI is for APM and does not match the HTTP hostname in the header (which is specified in the Portal Access link via Application URI). [ssl:error] [pid 11111] AH02032: Hostname xxx.yyy.com provided via SNI and hostname aaa.bbb.com provided via HTTP are different From what I've read, this cannot be disabled on the Apache server without removing SNI and recompiling... which is not an option for me. However this F5 use-case seems like it would be fairly common, so I'm not sure what I'm missing here. Anybody have any thoughts? Thanks-Apache origin and header conversion to iRules
I need to take this an Irule f5 can you help me with this please <IfModule mod_headers.c> Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure SetEnvIf Origin "^http(s)?://(.+\.)?tgr\.cl$" AccessControlAllowOrigin=$0 Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin Header set Access-Control-Allow-Credentials "true" </IfModule>Mitigating The Apache Struts ClassLoader Manipulation Vulnerabilities Using ASM
Background Recently the F5 security research team has witnessed a series of CVE’s created for the popular Apache Struts platform. From Wikipedia: Apache Struts was an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model–view–controller (MVC) architecture. It was originally created by Craig McClanahan and donated to the Apache Foundation in May, 2000. Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top-level Apache project in 2005. The initial CVE-2014-0094 disclosed a critical vulnerability that allows an attacker to manipulate ClassLoader by using the ‘class’ parameter, which is directly mapped to the getClass() method through the ParametersInterceptor module in the Struts framework. The Apache Struts security bulletin recommended upgrading to Struts 2.3.16.1 to mitigate the vulnerability. Alternatively, users were also able to mitigate this vulnerability using a configuration change on their current Struts installations. The mitigation included adding the following regular expression to the list of disallowed parameters in ParametersInterceptor: '^class\.*' After several weeks, the solution was found to be incomplete, and sparked four new CVE’s: CVE-2014-0112, CVE-2014-0113, CVE-2014-0114 and CVE-2014-0116. Note: During the initial release of this article, CVE-2014-0114 and CVE-2014-0116 were not yet publicly disclosed, and weren't mentioned in this article. The article has now been edited to include mitigation for these CVEs as well. CVE-2014-0112 mentions the ClassLoader vulnerability still existing in parameters, and the security advisory for it suggests a new regular expression to include in the ParametersInterceptor config: (.*\.
Apache Log4j2 (CVE-2021-44228) mitigation iApp
Problem this snippet solves: There is a CVE released related to Apache log4j, which could be a vulnerability on a server located behind the BIG-IP. F5 SIRT have helpfully created an iRule to mitigate this vulnerability, this is an iApp to simplify creation and management of the iRule. How to use this snippet: Install the iApp Template Download and unpack the archive Login to BIG-IP TMUI and navigate to iApps>Templates Hit Import button, select the template and hit Upload Create an iRule instance Navigate to iApps>Application Services>Applications Hit Create button, enter a relevant Name and select the log4j2_mitigation template Set the Debug Level ( Off, Attack or Debug ). Off = no logs, Attack = logs in the case of an attack detected, Debug = more detailed logs Hit Finished - iRule should be created Assign iRule to virtual server Navigate to LTM>Virtual Servers. Click on the Virtual Server, navigate to Resources tab Click Manage button under iRules section, add iRule. Note the Virtual Server must have an assigned http profile for this iRule, otherwise it will throw an error. Manage iRule If you have issues with the iRule or want to modify logs, navigate to iApps>Application Services>Applications and click on the deployed service. Navigate to the Reconfigure tab, make changes and hit Finished Tested this on version: 15.1
Need Help with Case Insensitive iRule for Apache Migration
Hi All, I have been helping on migrating our Apache environments into our F5 and everything has been working well, until we noticed that case insensitivity is not working. Here is the issue I am running into: If I go to www.website.com/test it works just fine. If I go to www.website.com/TEST, it does not work at all. I have the rewrite profile in place and the following iRule as well: when HTTP_REQUEST { set uri [string tolower [HTTP::uri]] if { not ( [HTTP::path] ends_with "/") && not ( [URI::basename [HTTP::uri]] contains "." ) } { # Append slash and keep querystring when it exists HTTP::uri [HTTP::path]/[expr { "[URI::query [HTTP::uri]]" eq {} ? {} : "?[URI::query [HTTP::uri]]" }] } if { [string tolower [HTTP::uri]] starts_with "/apps" } { pool ProxyPass_DEV_pool_2 } else { pool ProxyPass_DEV_pool_1 } } I figured line 2 "set uri [string tolower [HTTP::uri]]" would have fixed this but no dice. Any help would be greatly appreciated. Thanks!Apache to F5 Configuration
Hi everyone, We are having trouble with our F5 Configuration.Here is the scenario: We are using Mobile application (from playstore) to access the server. It uses standard VS with port 443 and performing SSL offloading. Configuration is based from the Apache Server which is currently on production and no error. Single server is used to access using Web and Mobile Application, only uses different ports.Here is the config: ProxyPass /fo connectiontimeout=60 timeout=600 ProxyPassReverse / timeout=600 ProxyPass /mob connectiontimeout=60 timeout=600 ProxyPassReverse /mob timeout=600 Looking at the firewall, no other port being used by the client when accessing using application. we captured some pcap, based on it, F5 can receive the traffic and can exchange SSL. However, we cannot see that F5 is sending the traffic to the server.It seems that there is configuration error with the virtual server. We tried changing the type to Performance L4 but SSL-offloading is removed. we also changed the protocol to All protocol, but still, SSL-offloading is removed. Is there a way to have All protocol type of VS but with SSL-offloading? If this can be done via irule. If not, does anyone experienced the same problem (using mobile application passing thru F5). Thank you all for the response.
health monitor IIS
Hello, I was wondering if someone can shed some light on a health monitor I am trying to setup. Ill give a brief overview of the setup. We have an application that gets proxied via apache ( apache are the nodes in the pool being monitored, acts as proxy nothing more) to IIS where the application actually lives. I am trying to setup a monitor so that it monitors say an index.html page on the IIS server something along the lines of Send string - http://Portal/dir/index.html receive string - IIS is up Tried to use this but nodes fail the health check when applying the monitor to the pool The service ports that its monitoring for are https Any help is greatly appreciated ThanksUploading Apache certificate chain
Trying to implement smart card auth for the big-ip configuration utility, but unable to upload the cert chain via the ui or cli. Receive the following error: Values (/parition/name) specified for Certificate Bundle Entity (/partition......) foreign key index (certificate_file_object_FK) do not point to an item that exists in the database. I've seen references to this error and a bug in 11.5, however this is 12.1.2 and also having the problem with 13.0 I've uploaded the bundle elsewhere and it's fine. Does anybody know if the bug is still outstanding or any work arounds? Appreciated.Migrate IIS ASM policy to Apache
Hello! If a you have a established IIS ASM policy, but your company moves to Apache Servers. At a high level, does anyone have any tips for merging the two policies. I have read this entire article here; https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-5-0/40.html And at a high level, it seems that the steps are: 1) Create a new policy with the same distinctions but add Apache signature set. (Keep differentiate HTTP/HTTPS URI's and Encoding options the same) 2) update all signatures on both ASM systems (if moving to a different ASM) 3) Use the policy diff feature and manually carry over the attributes. Thanks!
