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!
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
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.Retain source IP in UDP packet
Hi - I'm passing SNMP traps through an F5 VIP to our event collector. However being UDP the header info isnt retained and the node IP is showing as the SNAT address. Is there any way to retain the orgional IP? I'm thinking something like x-forwarded-for for TCP. Thanks!
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 🙂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! psMissing 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?
20 Lines or Less #19
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head. This week has been fantastic here in DCLand. I've been sequestered in a room with the awesome minds of the DevCentral team for most of the week brainstorming, collaborating, sharing, and thinking up generally cool new stuff! It's always a good time when the team gets together and there are almost always some hawesome things that come out of it, so keep an eye open for those. In the meantime there have been a load of cool iRules being written with a couple of prime choices for this week's 20LoL. One was even submitted directly via email, a 20LoL first, which is absolutely killer and I'd love to see more of it, so thanks Aidan, and don't be shy all you iRulers, get your ideas in! Many thanks and much credit to the always amazing hoolio and one of our awesome F5 engineers Aidan for the iRules in this edition. With that, I bring you this week's 20 Lines or Less: Log Every x Seconds There are thousands of reasons to log info in an iRule, but I think this one is built with the concept in mind of using the iRule of a type of advanced warning system. Logging info about things that could potentially cause problems later is great, unless you're flooding your log with that info and causing a problem NOW instead of later. So why not only log every x seconds if that condition is still valid? when RULE_INIT { # Initialize a variable to track the last time a log message was made set ::last_log_timestamp [clock seconds] # Shortest interval (in seconds) to log a message set ::min_log_interval 60 } when CLIENT_ACCEPTED { # Check if there are two or less active members in the default pool if {[active_members [LB::server pool]] < 3 and [expr {[clock seconds] - $::last_log_timestamp}] > $min_log_interval}{ log local0. "[virtual name], [LB::server pool]: [active_members [LB::server pool]] members available!" } } More on obfuscating your server and app type There have been many posts and examples of how to help mask what kind of app server and os you're running. Many of them are listed by hoolio in this post. This is one more great example of trying to mask an app type by getting rid of some key headers, including looping through to remove all the "x-" headers, which is a new take on this concept. Cool stuff. when HTTP_RESPONSE { # Remove server header HTTP::header remove "Server" # Remove Date header HTTP::header remove "Date" # Remove any header which starts with "X-" for {set i 0} {$i < [HTTP::header count]} {incr i} { # Check if the current header name starts with X- if {[string tolower [HTTP::header at $i]] starts_with "x-"}{ # Remove the header HTTP::header remove [HTTP::header at $i] } } } Simulating a WAN environment with iRules Sometimes there's a need to simulate a delay in traffic, as if sending info across a WAN environment. Trouble is, that's actually pretty tough to accomplish without proper WAN simulation gear. Well, here's an iRule that can do just that! It just barely squeaks in under the 20 lines requirement, if you remove the log lines, but I'm showing it here in its full format because I think the logs could be useful. Yet another awesome example of the power of iRules in just 20 Lines or Less. NOTE: This iRule is NOT designed for production use. It is very high load, and will GREATLY slow down traffic on your entire system if applied in a high traffic environment. That is, after all, kind of the point. It is intended for testing use and PoC type deployments in a safe, controlled dev/test environment where no production traffic will be harmed in the wild. Thanks ;) when CLIENT_ACCEPTED { log local0. "Client Packet accepted" TCP::collect } when CLIENT_DATA { log local0. "Generating Client Lag" set y1 [clock clicks -milliseconds] for { set x 0 } { $x < 175000 } { incr x } { #do nothing } set time1 [expr [clock clicks -milliseconds] - $y1] log local0. "Client for loop time is $time1 milliseconds" log local0. "Client packet released" TCP::release TCP::collect } when SERVER_CONNECTED { log local0. "Server Packet accepted" TCP::collect } when SERVER_DATA { log local0. "Generating Server Lag" set j1 [clock clicks -milliseconds] for { set z 0 } { $z < 175000 } { incr z } { #do nothing } set time1 [expr [clock clicks -milliseconds] - $j1] log local0. "Server for loop time is $time1 milliseconds" log local0. "Server packet released" TCP::release TCP::collect } There's your dose of iRules goodness in 20 Lines or Less for this week. Stay tuned for future editions and be sure to get your submissions in if you want to see your iRule featured. Thanks much for reading and as always, all feedback is welcome so don't be shy. #Colin
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.
