Forum Discussion
James_Dyson_470
Nimbostratus
Nimbostratusmultiple rules / header info removing
Hi Guys,
I've got a build running production traffic that has just been pen tested and one of the complaints was the BigIP returning OS information in the header. (ver9.x)
I know (or think I know) that this can be stopeed using an iRule such as;
rule when HTTP_RESPONSE {
Remove all but the given headers.
HTTP::header sanitize “ETag” “Header01” “Header02”
but the problem is we are already using the following rules.
}
rule prod-https-redirect {
when HTTP_REQUEST {
HTTP::redirect "https://www.site.com/prod/"
}
}
rule prod-https-addition {
when HTTP_REQUEST {
if { [HTTP::uri] eq "/" } {
HTTP::redirect https://www.site.com/prod/
}
}
}
rule redirect-prod-addition {
when HTTP_REQUEST {
if { [HTTP::uri] eq "/" or [HTTP::uri] eq "" } {
HTTP::redirect https://www.site.com/prod/
}
}
SO basically we are running ssl on the f5, and redirects for the http and https, is there going to be an issue applying the header change rule, or is there a neater way of doing it?
Thanks for any advice in advance.
J
- You'll need to build your own HTTP redirect using TCP::respond rather than HTTP::respond.
This approach will suppress both the Connection: Keep-Alive header and the Server: BIG-IP header that are sent by default:when HTTP_REQUEST { set location "http://www.domain.com/uri" TCP::respond "HTTP/1.1 302 Found\r\nLocation: $location\r\nConnection: close\r\nContent-Length: 0\r\n\r\n" TCP::close }
Works like a charm!
/deb - ???
I've used this code and the resulting redirect response is a minimal but well-formed HTTP response without the offending headers:
HTTP/1.1 302 Found
Location: http://www.google.com
Connection: close
Content-Length: 0
tcpdump output, indicating appropriate CR/LF insertion:0x0000 4500 0085 d468 4000 ff06 484f ac19 c32d E....h@...HO...- 0x0010 c0a8 2ecb 1f90 074f a4f5 1b61 eea3 9967 .......O...a...g 0x0020 5018 111c 4aa1 0000 4854 5450 2f31 2e31 P...J...HTTP/1.1 0x0030 2033 3032 2046 6f75 6e64 0d0a 4c6f 6361 .302.Found..Loca 0x0040 7469 6f6e 3a20 6874 7470 3a2f 2f77 7777 tion:.http://www 0x0050 2e67 6f6f 676c 652e 636f 6d0d 0a43 6f6e .google.com..Con 0x0060 6e65 6374 696f 6e3a 2063 6c6f 7365 0d0a nection:.close.. 0x0070 436f 6e74 656e 742d 4c65 6e67 7468 3a20 Content-Length:. 0x0080 300d 0a0d 0a 0.... 
James_Dyson_470ok, so now I'm really confused.
according to this I can just use header remove,
Click here
but I'll hold my hands up and say I have no idea how it interacts with the existing rules. Could I not just add the iRule as above?
Wouldn't it just manipulate all outgoing headers?
Apologies for being slow here....help appreciated.- You're not slow. There are couple of things here that are not quite intuitive:
1)
HTTP_RESPONSE is specific to a SERVER response passing through the load balancer, and is not triggered for locally-generated responses. In this context, since there is no server response, no HTTP_RESPONSE event is triggered.
and even if the response event were triggered:
2) HTTP::header commands affect only headers passing THROUGH the load balancer, not locally-generated responses. (I'd imagine that it's a timing issue: We can't modify the response before it exists, but the response doesn't exist until LTM sends it, and we can't modify it after it's been sent...) In this context, the redirect response is locally generated, so we can't affect it with the header commands.
Hopefully that explains better.
You can apply the TCP::respond workaround to HTTP virtual servers, but I don't have a good one for HTTPS virtuals.
Good luck!
/deb