Request hitting varnish and getting served and not checking mod_security rule? - linux

I have a reverse proxy server on which mod_security is configured to be used as web application firewall and varnish is for cache. I have blocked a country but as request hit Varnish and getting served. The setup is like below
Request > Varnish[80] > Mod_security/HTTPD[8080]
On opening page on 8080, the rule is working , but on 80 the request is getting served by the Varnish.

You will need to put your geolocation rules into varnish for it to get use of varnish (alternatives are really bad for cache hitrates). Theres a VMOD for geo-location called https://github.com/varnish/libvmod-geoip

Related

How to setup a reverse proxy in IIS using host file?

I'm trying to setup a reverse proxy in IIS 10 using some fake urls.
In my host file I set up :
127.0.0.1 somedomain.com
Then I created a website in IIS 10 binding to this domain and a fake page :
When typing somedomain.com on chrome, the fake page shows properly. I assume the fake domain website works.
I have then another website with a reverse proy rewrite rule. I expect requests to the new website to be rewritten and show the first somedomain.com
When running my reverse proxy website I'm getting the error :
HTTP Error 400.605 - Bad Request
The request cannot be routed because it has reached the Max-Forwards limit. The server may be self-referencing itself in request routing topology.
Does anyone know what I'm doing wrong please ?
I tried changing the rule action type to "Redirect" and I can see that the redirection works correctly.

How to preserve referrer (Referer HTTP header) across subdomains?

I have a website running on www.example.com that makes GET requests to api.example.com to process a form. When I examine web server logs for api.example.com I see that requests from Safari get the full referer (e.g., www.example.com/page-where-request-originated). But requests from Chrome only get a partial referer (www.example.com).
I need the ability to track the full referring page when the request hits api.example.com. Reviewing the documentation for Referrer-Policy it seems my only option is to set it to unsafe-url. But that seems overkill because I only want the referrer to be sent for subdomains of example.com. Is that possible?
The only option I can find is strict-origin : Send the origin as referrer, but only when the request is no downgrade from https to http.
see: https://wiki.crashtest-security.com/enable-security-headers
Everything else will either omit the referrer completely or send the origin URL without any URL parameters.

How to handle http requests which are getting redirected as https using my nodejs-express app?

I am injecting some script tags in a website, with source such as http:localhost:3000/css/my-page-css.css . While its working on almost all sites, there's this particular website that is somehow sending all my http requests as https. How do I handle such a case?
I have configured an https server also on my nodejs app which listens to port 8443 and http listens to 3000. But, when I inject my script tags, they have src URLS which point to port 3000. So even if I have an https configured on my nodejs app, it won't work since it would be listening to a different port.
You are using HTTP Strict Transport Security (HSTS)
Using the securityheader.com website on your URL, or Chrome Developer tools we see the following HTTP Header is sent back by your site:
Strict-Transport-Security max-age=7889238
This HTTP Header will be configured in your webserver and is a way of your webserver telling the browser "For the next 7889238 seconds only use HTTPS on this domain. If someone tries to use HTTP (either by typing or by clicking on a link) then automatically switch HTTP to HTTPS before you send it on to the server."
This is a security feature as currently the default (if a scheme is not explicitly given) is HTTP. This allows website owners to switch the default and, even strong that that, prevents it being able to be switched back.
HSTS is set at a domain level and it is not possible to have it on for one port (e.g. 443) but not for another (e.g. 3000) - it's either on for that domain or off.
If you really want to use HTTP then you need to remove this header and remove the remembered value of this header from your browser. While chrome allows you to do this by typing chrome://net-internals/#hsts in the URL and using the delete option, the easiest way to do this is to change the max age from 7889238 to 0, and then load the website again. And then remove the header completely.
This can be especially annoying for sites like localhost where you proxy requests and inadvertently set it for that dummy host name. You should see if your node proxy server allows you to strip off that HTTP header. Some might say it would be better if browser makers ignored HSTS for localhost, however I think it would be better if developers just stopped fighting HTTPS and used that even for development environments using a self-signed certificate that is added to your local trust store. This was you can avoid problems like mixed content, and also use features that are HTTPS only (including Brotli, HTTP/2, Geo Location...etc.) while developing (though some browsers like Chrome still allow these on http://localhost).
Alternatively set up a local DNS alias for each of your dev sites and use that with or without HTTPS as appropriate for the site in question.

Apache error instead of varnish error

I configured varnish for my client .Now my client want to see apache error instead of varnish backend fetch failed in browser .Is there any option available varnish 4.
Alas, there is no option to do so.
You either pipe the requests to see everything from backend (bypassing Varnish), or you have default behaviour of 503 Backend fetch failed on errors from backend.
You can use VCL to serve the apache error page. By default Varnish, on error, will serve its preconfigured error page.
In vcl_backend_response detect if Apache is erroring, if that's the case, retunr(deliver) to serve the Apache error page.
If you share you VCL I can have a look at it.

HSTS: Should I force user to use HTTPS on load balance or web server?

My environment :
1.) 1 load balance server (nginx)
2.) 2 web servers (express.js running on node.js)
3.) 1 database server
Hello, I am trying to force my user to use https. I look through many tutorials on how to implement https in express.js.
However, as I look through many tutorials, I found 2 ways on how to redirect user http to https.
redirecting user to https on nginx config ( on load balance server )
redirecting user to https on express.js ( on web server )
My question is:
which is a better way to implement HSTS for my web app (on a load balance or on a web server)
Also please kindly give little information on the advantages and disadvantages of each of the options
Thank you very much :)
You can reduce traffic by enforcing https upstream on the load balancer, if you are only serving content that needs to be encrypted it might be best to restrict http traffic to the web servers from external sources.
Otherwise a http request will pass through the load balancer, be directed to web server 1 where it will respond with a 302 redirect to use the https url. This causes the user to have to make 2 request to get to your website.

Resources