Reverseproxy for WS using IIS - iis

I have been searching all day long, but I don't have a clue how to solve this problem. I know there are similar questions here, but none seems to word.
I have an IIS server running on https://hostname.xy I deliver html and JS content from there and I have already configured a reverseproxy for SPA.
Now I am running a tomcat-server on port 7000 on the same server. The tomcat server accepts ws://..../.. requests.
All I want to do is communicating with that server. Requests get blocked because of mixed content. So I tried adding ssl to my tomcat server which is blocked because of a self signed certificate.
Is it possible to configure a reverse proxy that redirects all wss traffic to ws on a specific port? Could you share the specific rule from the web configuration in the IIS?
I tried next too many other rules this one here:
<rule name="WS reverse proxy" stopProcessing="true">
<match url="wss://myhostname.de/*" />
<action type="Rewrite" url="ws://127.0.0.1:7000/chat" logRewrittenUrl="true" />
</rule>

Related

Hide or rewrite HTTP response Server Header from SSRS

I am using SSRS 2016 for my report. And every time I access a report, the response always contains the IIS server information. I want to hide or rewrite this sensitive information from the HTTP response Server header. Is there any way I can do it?
Reporting Services uses Http.sys directly from the server’s operating system to accept requests directed to URLs and ports configured for Reporting Services. This architectural change allows Reporting Services to exist without IIS and provides the same functionality. So, some suggestions to use URLRewrite extension and create an outbound rule in the internet does not help in this case.
Is there any way we can configure to hide/rewrite HTTP response Server header in Reporting Services Configuration Manager?
You could create an outbound rule to remove Server header like this
<outboundRules>
<rule name="rewrite">
<match serverVariable="RESPONSE_SERVER" pattern="(.*)" />
<action type="Rewrite" />
</rule>
</outboundRules>
Then you will see the value of Server header being removed.

IIS URL Rewrite behaves differently for HTTP vs HTTPS

I've been trying to use the URL Rewrite module to create a rule that looks for any set of two or more forward-slashes in the URL (past the first set) that will redirect the browser to a URL with all sets of multiple forward slashes replaced with just one. Example:
http://myhost.com/abc//def//ghi//jkl//iisstart.png
should redirect to
http://myhost.com/abc/def/ghi/jkl/iisstart.png
I already understand that IIS sees these two URLs as functionally equivalent, but for this public-facing site we want to avoid any chance that crawlers will index URLs with the multiple forward slashes; hence the redirection. So here's the rule I put together:
<rule name="Redirect URLs with Multiple Forward Slashes" enabled="true" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".*" />
<action type="Redirect" url="{URL}" appendQueryString="true" />
<conditions logicalGrouping="MatchAny">
<add input="{UNENCODED_URL}" pattern="//" />
</conditions>
</rule>
I tested this on my local box, and it produced the expected outcome (the redirection). I copied it into a web.config on a development server and tried it out, but it didn't work. I even took the path of making sure the URL Rewrite installation matched the version on the development server (it's 2.0, and upgrading would be a pain in our large production server farm so I'd like to avoid that). After that, I took into account that our development server, by design, only serves up HTTPS, while I'd been testing in HTTP on my local box. When I enabled HTTPS on my local box, the rewrite rule didn't work with an HTTPS URL but worked fine with an HTTP URL pointing to the same resource.
All the URL Rewrite documentation I've looked at makes reference to HTTP, and there are no references to HTTPS. What am I doing wrong here?
For the record - my local box is running Windows 10, and has IIS version 10. The dev server is running Server 2012, and has IIS version 7.5.

Redirect to FQDN in IIS Not Working

None of the answers I've found to questions like this (notably this one) work for me, so here I go.
We are running IIS 8 on Windows Server 2012 R2. We have a wildcard certificate (*.mydomain.com) installed on the server. On the Default Web Site we have a single binding to accept incoming https requests on port 443. I have a second Web Site set with a single binding to accept incoming http requests on port 80.
On the latter Web Site I've created a URL Rewrite rule to redirect all incoming non-HTTP traffic to https://myserver.mydomain.com{REQUEST_URI}, and this works perfectly. If I browse to either http://myserver.mydomain.com/homepage or http://myserver/homepage, I am sucessfully redirected to the HTTPS version of the site with the full domain name included and thus it loads just fine.
If I browse to https://myserver.mydomain.com/homepage, the site also loads perfectly.
However, I am trying to create another URL Rewrite rule on the Default Web Site so that requests to https://myserver/homepage (Note: HTTPS but the full domain name is omitted) are redirected to the https://myserver.mydomain.com/homepage. The reason for this is that the SSL certificate is only matched if the full domain is included. As it stands, if I enter https://myserver/homepage I get a security warning (NET::ERR_CERT_COMMON_NAME_INVALID).
I've created the rule which I think should work, based on the answer I linked to above, but it doesn't work and I don't know why. My rule look like this:
<rewrite>
<rules>
<rule name="Redirect to FQDN" enabled="true" patternSyntax="ECMAScript" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^myserver$" />
<add input="{HTTPS}" pattern="^ON$" />
</conditions>
<action type="Rewrite" url="https://myserver.mydomain.com/{R:1}" />
</rule>
</rules>
</rewrite>
Even with this rule in place and enabled, when I browse to https://myserver/homepage I get the security message. What am I doing wrong with this rule?
Problem is that you have SSL only for *.mydomain.com. And when you accessing https://myserver it will return certificate error because your cert is not valid for this domain.
For better understanding about steps during SSL connection:
In your case, the problem is between step 2 and 3

Proxying Meteor WebSockets through IIS ARR

We have a need to proxy Meteor through an IIS proxy. An IIS site accepts bindings for a particular Meteor website and proxies the requests through to an alternate port.
Web sockets are not working and Meteor is reverting to XHR.
Web.Config file as follows:
<rule name="Meteor reverse proxy" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(.+)://" />
</conditions>
<action type="Rewrite" url="{C:1}://127.0.0.1:8008/{R:1}" />
</rule>
By accessing the website via 127.0.0.1:8008 on the server it works fine. Accessing the website through the IIS proxy fails.
I have noticed IIS ARR is changing the casing of the headers, removing a header (sec-websocket-extensions) and adding a handful of extras. This might not be related.
IIS Proxy:
Direct:
MS documentation recommends disabling WebSockets when in use alongside NodeJS. Updating this setting does not help.
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support#TOC301258519
Has anyone come across this issue?
Update
You'll notice the header above references ARR2.5, this version does not support web sockets. 3.0 is required to proxy sockets.
After testing the proxy via an alternative web socket hello world, ARR was proxying web sockets successfully. To solve the issue we disabled compression on web sockets within Meteor.
SERVER_WEBSOCKET_COMPRESSION environment variable to 0
https://forums.meteor.com/t/websocket-compression-introduced-in-meteor-1-2-doesnt-work-with-passenger-docker-nginx/12025

Forwarding NTLM credentials from IIS with ARR and URL Rewrite

Thanks in advance for your help.
In my environment, I configured IIS to act as a reverse proxy and forward requests to certain paths to an application server on another host. In order to do this, I used Application Request Routing (ARR) and URL Rewrite modules, I create my rule and everything's working fine.
IIS is responsible to authenticate clients using NTLM, so my question is: is it possible to pass the authentication credentials (at least the username) to my application server after authenticating the user?
I tried to do this adding a custom header to my requests, writing a rule like this:
<rule name="ForwardToApplicationServer">
<match url=".*" />
<serverVariables>
<set name="HTTP_AUTH_USER" value="{AUTH_USER}" />
</serverVariables>
<action type="Rewrite" url="http://myappserver/myapp/{R:0}" logRewrittenUrl="true" />
</rule>
But it doesn't work: when I read it on my application my header is alwasy empty. I also tried with and but none of these worked.
So, what am I doing wrong? Should I use another server variable? Am I missing something?
More in general: is it possible to do what i'd like to do?
Again, thanks in advance for your help, and please forgive me if I'm asking something obvious but I'm new to using IIS and I couldn't find anything that helped me.
http://weblogs.asp.net/owscott/an-intro-to-iis-url-rewrite-plus-redirecting-urls-to-www-web-pro-week-8-of-52
{REMOTE_USER}, {LOGON_USER} & {AUTH_USER} do not work with URL-REWRITE, ...
You can use www.isapirewrite.com which runs later in the stack and has a handle on the auth data.

Resources