Checking for X-Forwarded-For against an Address Data-Group
Hello, I've been back and forth over this simple block of code, extracted from our f5 rule. I'm trying to adjust to Cloudflare X-Forwarded-For header for handling source IP address comparison to an internal list of credible internal IP ranges. While I understand that the "X-Forwarded-For" header is not 100% reliable, having this value set will aid debugging in other respects. When I call this f5 irule with no headers, it is fine, it appears to use the client_addr normally against our whitelist address Data Groups (very simple list of allowed ranges). But when I call it with a header of X-Forwarded-For via Postman it does not respond at all to the client (fails hard). I thought all Tcl variables are Tcl String, but is there something I need to convert extra for headers? -value on the header did not help either. when HTTP_REQUEST { if {[HTTP::header exists "X-Forwarded-For"]}{ set ip [HTTP::header "X-Forwarded-For"] } else { set ip [IP::client_addr] } set externalHost 1 if {[class match $ip equals Internal_Hosts]}{ set externalHost 0 } if {($externalHost == 0)}{ HTTP::respond 200 content { externalHost=0 } } elseif {($externalHost == 1)}{ HTTP::respond 200 content { externalHost=1 } } else { HTTP::respond 200 content { externalHost=unknown } }
f5 irules add headers
Hello, I'm trying to replace Nginx with f5, and I have a few headers I need to set in f5, but I'm not sure how... in nginx the config file looks like this: proxy_set_header X-Forwarded-Host $host; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; Is there any way of replicating this in f5? I was hoping to do this through irule, as I alredy have an irule assigned to one VS that changes url and uri and passes it to corect node: when HTTP_REQUEST { if { not (([HTTP::path] starts_with "/api/") or ([HTTP::path] starts_with "/auth") )} { return } set apiType [lindex [split [HTTP::path] "/"] 2] if {([HTTP::path] starts_with "/auth") }{ set newSubdomain access.uat. HTTP::header replace "Host" [string map [list "api-uat." $newSubdomain ] [HTTP::host]] HTTP::path [string map [list "/api/$apiType" "/access"] [HTTP::path]] log local0. "New Path [HTTP::host][HTTP::path]" virtual keycloak_vs node 172.17.1.104 8080 } else { log local0. "api type $apiType" append newSubdomain $apiType .uat. log local0. "New Subdomain $newSubdomain" HTTP::header replace "Host" [string map [list "api-uat." $newSubdomain ] [HTTP::host]] HTTP::path [string map [list "/api/$apiType" "/api"] [HTTP::path]] log local0. "New Path [HTTP::host][HTTP::path]" } unset newSubdomain unset apiType } not sure what else to include to make it clear.... The basic process is: user goes to api-uat.example.com/api/access f5 changes this to access.uat.example.com/auth (user don't see this) This takes user to the page with links, one of the links is "log in", and when user chooses it should go to api-uat.example.com/api/access/.... however for some reason URL in the browser is changed to access.uat.example.com/auth/... which is not accessible externally... I'm guessing that the problem is with missing proxy headers like I have them in nginx (which doesn't get the same problem) Hope this is clear enough 🙂
F5 LTM appears to be overwriting the cache-control response headers
BIG-IP LTM v15.1.4 When accessing our website through the F5 (VIP), the cache-control response headers are not honoring the values returned by the member servers in the Pool. When accessing the webservers directly (not through the F5) the cache-control header values are correct. INCORRECT HEADERS = cache-control: private CORRECT HEADERS = cache-control: no-cache, no-store We do not have any iRules modifying this header, we are not using Web Application Proxy (WAP), Web Acceleration, etc.
Forwarding to Different Port Replaces the Host Header
We use F5 in front of an AWS ALB for firewall purposes. In our virtual server, we forward our https requests to port 85. When the request arrives at our web tier, the request has the host header of our external url with ":85" appended to it. We want the behaviour to be when the request is forwarded, even to a different port, the host header remains the same in order for OpenID to work correctly. Please let me know if there is a workaround for this, and thanks in advance.X-Frame-Options: SAMEORIGIN header Question
Alright DC Community! This came in thru twitter and thought I'd ask on behalf of Stefán Jökull Sigurðarson (@stebets)/DC Member, Stebet: Does anyone know how an X-Frame-Options: SAMEORIGIN header could start appearing after adding a separate Content-Security-Policy header in an app? I'm suspecting something within our @F5Networks LB? Anyone seen this? It only got added after I put in my CSP header on the app-side of things though. So I'm curious if it's some sort of automatic thing to do if a CSP header is detected? It was removed easily enough with an iRule though. @jasonrahm replied: If using CSP frame-ancestors self should invalidate need for x-frame-options, but if you are not explicitly setting it must be gathered in a policy check somewhere before the app response is released. Previous Q/As also discuss clickjacking and methods to mitigate. Any other suggestions? Let's give him some advice! And, as always, appreciate the help! ps
How can I preserve the original HTTP Host Header to the Backendservers?
Hi guys, I'm trying the following configuration to loadbalance a RH SSO Key cloack Cluster: clientIP -> https/443 -> (clientssl-Profile) F5-Virtual Server (serverssl-Profile) -> SNAT-IP -> tcp8443 -> Backendserver The Backendserver need to see the original client http Header, so I created a http Profile with the "Insert X-Forwarded-For"-Option enabled. Alternative I tried the following iRule: when HTTP_REQUEST { HTTP::header insert X-Forwarded-For [IP::client_addr] } Unfortunaly, both ways didn't work properly... How can I preserve the whole original HTTP Host Header trough the F5 to the Backendservers? Thank you!Missing SOAPAction
Hey, I have a problem I think is easy to solve but this is my 1st time researching F5 rules. I'm a developer by trade but trying to figure out an urgent issue. I have a problem with an obscure client of our SOAP services. Our WSDLs speficy am empty SoapAction but this client assume that without a SOAPAction, it won't even send the header. Our server get a mixture of REST and SOAP requests so I am looking for a rule that will check only SOAP requests for a SOAPAction header and if it doesn't exist, add it. Or, is this just as easy as doing something like this? HTTP::header replace SOAPAction "" This is a little scorched earth but we don't have any SOAPAction anywhere. I don't think this would negatively affect other types of requests even it were be added to everything?iRule header removal for cached item reponses
Does anyone know if iRules do not apply to cached responses? I like to strip out X-Powered-By headers from my responses, but I'm seeing that header on the client side of things; I haven't made any changes to my iRule (though it's a large one shared between multiple VSs) which leads me to believe that the HTTP_Request and HTTP_Response rules aren't being applied to cached responses.
Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox
But browser support is only half the solution, don’t forget to implement the server-side, too. Clickjacking, unlike more well-known (and understood) web application vulnerabilities, has been given scant amount of attention despite its risks and its usage. Earlier this year, for example, it was used as an attack on Twitter, but never really discussed as being a clickjacking attack. Maybe because aside from rewriting applications to prevent CSRF (adding nonces and validation of the same to every page) or adding framekillers there just haven’t been many other options to prevent the attack technique from being utilized against users. Too, it is one of the more convoluted attack methods out there so it would be silly to expect non-technical media to understand it let alone explain how it works to their readers. There is, however, a solution on the horizon. IE8 has introduced an opt-in measure that allows developers – or whomever might be in charge of network-side scripting implementations – to prevent clickjacking on vulnerable pages using a custom HTTP header to prevent them from being “framed” inappropriately: X-FRAME-OPTIONS. The behavior is described in the aforementioned article as: If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin. But that’s only IE8, right? Well, natively, yes. But a development version of NoScript has been released that supports the X-FRAME-OPTIONS header and will provide the same protections as are natively achieved in IE8. The problem is that this is only half the equation: the X-FRAME-OPTIONS header needs to exist before the browser can act on it and the preventive measure for clickjacking completed. As noted in the Register, “some critics have contended the protection will be ineffective because it will require millions of websites to update their pages with proprietary code.” That’s not entirely true as there is another option that will provide support for X-FRAME-OPTIONS without updating pages/applications/sites with proprietary code: network-side scripting. The “proprietary” nature of custom HTTP headers is also debatable, as support for Firefox was provided quickly via NoScript and if the technique is successful will likely be adopted by other browser creators. HOW-TO ADD X-FRAME-OPTIONS TO YOUR APPLICATION – WITH or WITHOUT CODE CHANGES Step 1: Add the custom HTTP header “X-FRAME-OPTIONS” with a value of “DENY” or “SAMEORIGIN” before returning a response to the client Really, that’s it. The browser takes care of the rest for you. OWASP has a great article on how to implement a ClickjackFilter for JavaEE and there are sure to be many more blogs and articles popping up describing how one can implement such functionality in their language-of-choice. Even without such direct “how-to” articles and code samples, it is merely a matter of adding a new custom HTTP header – examples of which ought to be easy enough to find. Similarly a solution can be implemented using network-side scripting that requires no modification to applications. In fact, this can be accomplished via iRules in just one line of code: when HTTP_RESPONSE { HTTP::header insert "X-FRAME-OPTIONS" “(DENY || SAMEORIGIN)”} I believe the mod_rewrite network-side script would be as simple, but as I am not an expert in mod_rewrite I will hope someone who is will leave an appropriate example as a comment or write up a blog/article and leave a pointer to it. A good reason to utilize the agility of network-side scripting solutions in this case is that it is not necessary to modify each application requiring protection, which takes time to implement, test, and deploy. An even better reason is that a single network-side script can protect all applications, regardless of language and deployment platform, without a lengthy development and deployment cycle. Regardless of how you add the header, it would be a wise idea to add it as a standard part of your secure-code deployment requirements (you do have those, don’t you?) because it doesn’t hurt anything for the custom HTTP header to exist and visitors using X-FRAME-OPTIONS enabled browsers/solutions will be a lot safer than without it. Stop brute force listing of HTTP OPTIONS with network-side scripting Jedi Mind Tricks: HTTP Request Smuggling I am in your HTTP headers, attacking your application Understanding network-side scripting 9 ways to use network-side scripting to architect faster, scalable, more secure applications
