I have two web servers running Apache 2.4 on CentOS 7 and I am trying to set up a reverse proxy server for my web server. As of now, the proxy server is using a Let's Encrypt certificate, and when I access the proxy server before making changes to any virtual host configurations, I access the domain I have set up on the proxy and see a green lock in the upper left hand corner (no problems). I am using Firefox by the way.
Now, when I configure a virtual host to redirect the request to my web server, I get a web page with missing content (yellow exclamation point on the browser lock). My web browser appears to be blocking the images for my own protection, apparently. The proxy server appears to be redirecting my original request, which is good, but I am not see all the content load on-screen. It's likes it's been filtered out (it is) because the browser is just saying it's insecure.
How can I solve it?
Here is my configuration for a virtual host:
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
#
ProxyRequests Off
ProxyPass / http://IP:80/
ProxyPassReverse / http://IP:80/
</virtualhost>
I reviewed this article too: http://awesometoast.com/cors/
You should read about CORS (Cross Origin Resource Sharing)
After proxy pass (in the vhost config), try adding this (make sure you have apache mod_headers installed)
Header add "Access-Control-Allow-Origin" "*"
This is not a secure configuration, but the reason your resources are not loading and the yellow exclamation sign is showing up is because you are trying to load resources from a different domain, thus the browser is showing the site as not secure. Allowing the specific domains with the resources in the headers will tell the browser that the server with the resources is allowed.
Here are some links to refer:
Apache proxy with cors headers
Server Apache
Related
I've configured proxy reverse with apache 2.4 on a server (ip for example 192.168.1.10) as follows:
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost Off
ProxyPass "/foo/" "http://172.20.0.3/"
ProxyPassReverse "/foo/" "http://172.20.0.3/"
mod_proxy_html is loaded.
Where 172.20.0.3 is a docker container, hosted by the server.
When I browse to 192.168.1.10/foo/ I see on the url bar 192.168.1.10/index.php (index.php is the page I actually would like to browse), but the resources required to load index.php are not found. So I get 404 page not found.
Setting / instead of /foo works, but I need to configure other proxy on the same server too.
This Q/A does not provide solution for my case: Apache ProxyPass not loading Resources
What I'm missing? Thank you
I would like to block any traffic that does not come for the websites hosted on my VPC.
My Server's IP address is 1.2.3.4 which hosts 3 websites.
Following requests should be allowed:
http:// example1.com or https:// www.example1.com
http:// example2.com/ or https:// www.example2.com
http:// example3.com/ or https:// www.example3.com
Following requests should be blocked (including server's IP address):
http: //1.2.3.4/ or https:// 1.2.3.4/
http:// anyotherdomain.com/ or https:// anyotherdomain.com/
List of allowed Host names could be read from a text file which I could update as and when required.
Is this feasible? If yes, what are the pros and cons. If not, thank you for the information.
Cheers
You can't do that in iptables as you would like to.
What you have aren't 3 real different hosts, but 3 virtual hosts: the main difference, as you already know, is that they share the same IP address.
As they share the same IP, kernel's netfilter just can't distinguish different requests from its layer: it's your web server application itself that "routes" the different requests to its proper website by looking at the "Host:" header inside the incoming HTTP packet and by determining which virtualhost should reply to it.
A good compromise (denying instead of dropping) for what you want to do would be to setup a configuration in your web server to make it catch and deny any connection that doesn't belong to your virtual hosts. Also there's no need to make a different list in this way, as your web server could dinamically determine if the requested host exists or not.
Here's an example, assuming you're running Apache, adding the catchall sentence to the top will make your server respond with a 403 message to any connection that won't be overridden by your examples.com websites:
<VirtualHost *:80>
ServerName catchall
<Location />
Order allow,deny
Deny from all
</Location>
</VirtualHost>
<VirtualHost *:80>
ServerName example1.com
DocumentRoot /var/www/example1
<Directory /var/www/example1>
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>
...
VirtualHost for example2.com (allowing all as above)
VirtualHost for example3.com (allowing all as above)
That's not the same as dropping right from the kernel of course, but it stops any further interation with your server aswell.
I have created a reverse proxy for my node server that runs on localhost, so that it can be served over HTTPS.
The forwarding works grate, however when the app tries to make requests I get:
Mixed Content: The page at 'https://foo.com/' was loaded over HTTPS,
but requested an insecure XMLHttpRequest endpoint
'http://localhost:8888/graphql?query=%7Bnotifications(userid)%7Bid%2C…
This request has been blocked; the content must be served over HTTPS.
Vhost config:
<VirtualHost *:443>
ServerName www.foo.com
ServerAlias foo.com
DocumentRoot /var/www/foo/
ErrorLog /var/www/foo/error.log
CustomLog /var/www/foo/requests.log combined
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateFile "/etc/letsencrypt/live/foo.com/cert.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/foo.com/privkey.pem"
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://localhost:8888/
ProxyPassReverse / http://localhost:8888/
</VirtualHost>
What is missing from my setup?
You are openning the page on https://foo.com/, but URLs within your page contain hardcoded localhost domain and port. While rendering the page, client browser will try to fetch 'http://localhost:8888/graphql effectively skipping apache (which is running on port 80, on server foo.com) and hitting directly your node app, which will 1) work only if you run the browser from the very same machine where you have your node app running, and 2) even then, you will get the above error since some page assets are loaded using http.
When you use relative URLs (for example URL that begins with /), browser will prepend the base URL, resulting in https://foo.com/graphql.
Absolute vs relative URLs
You need to add a SSL certificate to your node.js app. Enabling it on apache won't help since the apache is forwarding the requests to your node.js app on port 8888 (which communicates on plain http and not https). That's why you get the mixed content error. The initial request is on https on apache then forwarded to http to node.js
Steps to configure node.js app with a SSL certificate (you can use a self-signed certificate or a commercial one).
First you have to use ssl-root-cas available via npm. The configure it as follows:
'use strict';
var https = require('https')
, cas
;
// This will add the well-known CAs
// to `https.globalAgent.options.ca`
require('ssl-root-cas').inject();
cas = https.globalAgent.options.ca;
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '01-ssl-intermediary-a.pem')));
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '02-ssl-intermediary-b.pem')));
cas.push(fs.readFileSync(path.join(__dirname, 'ssl', '03-ssl-site.pem')));
Try and see if that works!
I have an environment where the JBOSS server sits on a linux machine and it's services accessed via Apache server running there.
I am not able access the JBOSS console as "http://:/console"
What changes apparently will I have to make in "httpd.conf" to access this url from outside.
The safer way of accessing your JBoss console is through an ssh tunnel.
Execute locally
ssh -L 7990:localhost:9990 username#your.jboss.server -N
and enjoy your remote server's console on your local machine on port 7990.
Opening console port on your web server is also a solution, but less secure one.
Try with:
<Location /console>
ProxyPass http://localhost:9990
ProxyPassReverseCookiePath / /console/
ProxyPassReverseCookieDomain localhost <YOUR PUBLIC IP ADDRESS>
</Location>
<Location /console/>
ProxyPassReverse /
</Location>
ProxyPreserveHost On
The thing with the ProxyPassand ProxyPassReverse directives is that it preserves the domain so you can handle cookies as is on JBoss side without any problems, and that sessions are tracked correctly.
The ProxyPassReverseCookiePath directive rewrites the path string in Set-Cookie headers. If the beginning of the cookie path matches internal-path, the cookie path will be replaced with public-path. And ProxyPassReverseCookieDomain rewrites the domain string in Set-Cookie headers.
See more:
apache httpd JBoss AS 7 admin console proxy
Apache Module mod_proxy
I have configured Sonar webserver to have all of the requests to go through Microsoft IIS server.
It was confirmed to work fine with requests via http protocol.
However, once the https was enabled, after successful login, Sonar webapp is trying to redirect to non-https url, causing it to timeout. If I then go and change the url to go to https, it shows as authenticated and continues to work as normal.
The same issue happens when you trying to logout - instead of redirecting to https page, it goes out to http.
What needs to be done to make Sonar post-login action to use the same protocol via which the login page was requested originally?
sonar.properties has:
sonar.web.host: 127.0.0.1
sonar.web.port: 9000
sonar.web.context: /sonar
IIS plugin has:
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:9000"/>
</VirtualHostGroup>
<ServerGroup Name="sonar_group">
<Server Name="sonar_server">
<Transport Hostname="127.0.0.1" Port="9000" Protocol="http"/>
</Server>
</ServerGroup>
<UriGroup Name="sonar_host_URIs">
<Uri Name="/sonar*"/>
</UriGroup>
<Route ServerGroup="sonar_group" UriGroup="sonar_host_URIs" VirtualHostGroup="default_host"/>
Thanks.
In the web UI (while logged in as an admin user), go to Settings -> General and make sure the URL listed under Server Base URL starts with "https". This can also be set in the server's sonar.properties file using sonar.core.serverBaseURL
This is a well-known issue with the Ruby stack, and requires tweaking the web-server config -- not that of Sonar. On Apache you'd have to do the following, Im sure the pointers in the ticket will also lead you to a solution for IIS:
RequestHeader set X_FORWARDED_PROTO "https"