We switched from a legacy Apache server serving as a load balancer (among other things) to haproxy. Apache would preserve header capitalization from upstream servers while haproxy transforms every header into lowercase. Is there a way to modify this behavior?
(I am aware that headers are supposed to be case-insensitive, unfortunately we have a legacy application that only supports a specific case in a specific header. Also, wouldn't modifying headers result in wasted compute cycles?)
Thanks to #mjf answer I found a specific way to fix it without recompiling haproxy.
For 2.0, add no option http-use-htx to your haproxy.cfg, for 2.0 [1].
For 2.1 add a set of option h1-case-adjust-bogus-server + h1-case-adjust, for 2.1 [2].
Maybe this patch may help to solve your issue.
I would think that the OP is experiencing an haproxy bug.
The excuse in that patch and the implication of the setting about how it is the applications fault is, well, a fallacy, to avoid using a stronger term. If you have an client/server solution where your client is talking to your own dedicated server which is putting in headers in a specific casing/capitalization, then accepting them in a different capitalization in the application IS the security risk, not the other way round. While it is true that the RFC says that the headers are case insensitive, it doesn't imply at all that a proxy is free to change it. For that reason (i.e. that a dedicated client talking to its dedicated server should legitimately expect it to retain the casing and should consider a change suspicious) I strongly believe that it should be classified as a bug, not a "feature to support bogus apps"; it is a bogus reasoning for an haproxy bug. Haproxy should (at least by default) retain the casing of the headers.
Related
I am using HTTPRequest node to make requests using TLS. Is there a way to skip certificate validation (checking the certificate chain, the expiration date) with standard IIB settings? I know this is risky.
In order to do this kind of things, there is a lot of workaround, but they are not that easy and quite horrible. I would suggest you to use a JavaCompute Node, using unix curl/wget commands for example (if running on Unix), or any other solution that is working on Java.
But I can confirm, you cannot use the default IIB nodes (like HTTPRequest) for this purpose.
According to this, you have to handle the exception yourself because IBM will not provide you a flag since it is a major security risk.
I have a legacy product that I'm trying to support on an Apache server and the server only after a recent update began rejecting request headers which only used LF for newlines and it's a tall order to rebuild it because of how old the code base is. Is there a setting somewhere that can be used or a mod_rewrite command that can be leveraged to allow request headers which use LF instead of CRLF or that will re-write LF's as CRLF's in request headers?
Example header from app:
Host: www.ourhostname.com:80\n
Accept-language: en\n
user_agent: Our Old Application\n
\n
If I hex edit the file to change the \n to \r\n, it works, but hex editing a file for release as an update isn't desired and I'm trying to find something server-side to get Apache to stop choking on LF's by themselves. Thanks in advance for any help on this problem!
we had the same problem and found Apache's fixed vulnerability:
important: Apache HTTP Request Parsing Whitespace Defects CVE-2016-8743
https://httpd.apache.org/security/vulnerabilities_24.html
These defects are addressed with the release of Apache HTTP Server 2.4.25 and coordinated by a new directive;
HttpProtocolOptions Strict
which is the default behavior of 2.4.25 and later. By toggling from 'Strict' behavior to 'Unsafe' behavior, some of the restrictions may be relaxed to allow some invalid HTTP/1.1 clients to communicate with the server, but this will reintroduce the possibility of the problems described in this assessment. Note that relaxing the behavior to 'Unsafe' will still not permit raw CTLs other than HTAB (where permitted), but will allow other RFC requirements to not be enforced, such as exactly two SP characters in the request line.
So, HttpProtocolOptions Unsafe directive may be your solution. We decided not to use it.
You could put a reverse proxy of some kind in front of Apache and have that handle converting the request to something Apache-friendly for you. Perhaps Varnish Cache would work, which can also function as just a HTTP processor, or NGINX. Another option may be a little Node.js app to accept the squiffy input and convert it to something better for you while piping it to the back-end.
I have a question. Can I find out the version of Apache when full signature is disabled. Is it even possible? If it is, how? I think that is possible because blackhats hacking big, corporate servers while knowledge of the version of the victim services is essential. What do you think? Thanks.
Well for a start there are two (or even three) things to hide:
ServerHeader - which shows the version in the Server response field. This cannot be turned of in Apache config but can be reduced to just "Apache".
ServerSignature - which displays the server version in the footer of error pages.
X-Powered-By which is not used by Apache but used by back end servers and services it might send requests to (e.g. PHP, J2EE servers... etc.).
Now servers do show some information due to differences in how the operate or how they interpret spec. For example the order of response headers, capitalisation, how they respond to certain requests all give clues to what server software might be being used to answer http requests. However using this to fingerprint a specific version of that software is more tricky unless there was an obvious, observable change from the client side.
Other options include looking at server status-page - though you would hope any administrator clever enough to reduce the default server header would also restrict access to the server-status page. Or through another security hole (e.g. being able to upload load executable scripts or the like).
I would guess most hackers would more be aware of bugs and exploits in some versions of Apache or other web servers and try to see if any of those can be exploited rather than trying to guess the specific version first.
In fact, as an interesting aside, Apache themselves have long been of the opinion that hiding server header information is pointless "security through obscurity" (a point I, and many others, disagree with them on) even putting this in their documention:
Setting ServerTokens to less than minimal is not recommended because
it makes it more difficult to debug interoperational problems. Also
note that disabling the Server: header does nothing at all to make
your server more secure. The idea of "security through obscurity" is a
myth and leads to a false sense of safety.
And even allowing open access to their server-status page.
I am on Mac OSX Lion using Nginx 1.4.1. I am using nginx in conjunction with Tornado.
In the process of installing the Nginx upload module (v. 2.2.0) I encountered some compatibility issues. See this reference for more info. Apparently, there is no great fix for this as of yet. My specific error is rooted in: error: no member
named 'to_write' in 'ngx_http_request_body_t'
Is there a way to make the two of these reliably compatible without jumping through hoops?
Or, is there a suitable alternative to using this upload module that will work with Nginx 1.4.1?
If not, should I considering using Nginx 1.3.8? And if so, where can I download this version? I do not see it available for download on their website here.
Thank you for the help. Regards.
1) No, it doesn't seem like there is as the maintainer of nginx-file-upload has implied he doesn't want to maintain it any more.
2) I found this article which lists some alternatives. One of which is nginx-big-upload I've not tried it yet.
3) Well you could consider it but then you're tied in to a package that isn't maintained. What happens if there's a security vulnerability for 1.3.8? You can't upgrade without either patching or changing your file upload strategy. If you want to, you can find all of the older Nginx versions here
The situation is pretty frustrating at the moment but there are options, just none of them are tried and true. When dealing with production systems stability and security are key.
1) Yes, this module dose not support for nginx 1.4+.
2) The reason is that nginx support chunked of thansfer-encode, and improve its code design. that it remove the field to_write of ngx_http_request_body_t struct.
3) https://github.com/hongzhidao/nginx-upload-module. This is an alter module. It support the latest nginx, and the feature is equal.
Is there a way to configure Apache to slow down login after failed attempts?
It looks like it is not the default setting as already discussed here.
On the other side it seems to be possible also without adding it to own application logic, on plain Apache, see here, but I found nothing in documentation and discussion???
Thanks
Achim