Security hole using kestrel behind IIS? - reverse-proxy

We are running reverse proxy with IIS and Kestrel. I'm planning on installing SSL certificate on the IIS server and use HTTPS, but I'm concerned that the Kestrel is someway accessible from the outside (hence accessible in clear text). I don't think it is, but couldn't find any documentation for it.

Related

iisClientCertificateMappingAuthentication and WCF

I have a working WCF Service, that does what it should do, hosted by an IIS.
Now in another environment, this service shall be used as ever, but IIS should additionally require a client certificate for allowing to access.
So I generated some certificates, used iisClientCertificateMappingAuthentication to configure them and map them to users. So I can control which users can access the website and I see to what user the certificates are mapped in the FailedReqLogFiles.
Then I added a sub directory, put the WCF application in there, converted to an application with an apppool and ther the pain began.
The WCF Service is determined to demand that 'Anonymous authentication' must be activated. When I activate anonymous authenticaiton, the service can be invoked, but from then on, it doesn't matter which certificate is used for authentication.
I googled tons of articles and tried lots of configurations, but didn't success so far. I must admit, I'm not very familiar with WCF, this always drove me crazy. I do simply not understand why an application deals with the way the Webserver handles security (it's smiliar to adding SSL, when WCF is not configured properly, IIS shows 404, that's also one thing i do not understand, why the WCF is interfering with the way IIS exposes content to the world...).
Hope there's someone who could give advice, thank you very much in advance.
Regards, Chris
You could try below setting in iis to resolve the issue:
1)Open iis manager, select your site.
2)select the SSL setting from the middle pane.
3)in SSL setting check require SSL, client certificate select accept radio button.
4)click on apply and restart iis.
You could refer the below link for how to set iisclientcertificate authentication with WCF:
WCF Service Using Client Certificates Requires Anonymous Access in IIS and Therefore Doesn't Actually Work?
How do I implement Client Certificate authentication the right way?
https://learn.microsoft.com/en-us/iis/configuration/system.webServer/security/authentication/iisClientCertificateMappingAuthentication/

Recommended identity / user for Kestrel + .NET Core (Windows)

When using Kestrel with IIS you define an Application Pool and identity (user). The default identity is "ApplicationPoolIdentity" but can be one of the following or a custom user:
When the application runs, Kestrel runs under the Identity you defined in IIS:
However, when using Kestrel behind a proxy server such as nginx (or standalone) what is the recommended "identity" (user) to use and how does one go about using it with Kestrel?
When you host Kestrel behind a proxy on Windows it is recommended to host the ASP.NET Core app in a Windows Service. Nginx would be configured to reverse proxy the applications url (e.g. http://localhost:5000) and the ASP.NET application would run under whatever user the service is configured to run as.
If you are hosting on Linux then you are responsible for creating your own service using whatever technology the underlying operating system provides (e.g. systemd, upstart, etc.)
The 'recommended' identity to use depends on what resources the ASP.NET app needs to access. The LocalService account has the same privileges as a member of the Users group.
You seem to be confused here. What you're talking about is the Application Pool Identity (which is what the window is even labeled as). The App Pool is essentially the process that serves your website. Processes run under accounts, be it a system, service, network, or user account. What account the process runs under determines (obviously) it's permissions and access. By default, in IIS, App Pools run under ApplicationPoolIdentity, which is just a local service account, with relatively limited permissions.
None of this has anything to do with Kestrel. Kestrel is just a simple web server. IIS merely acts as a reverse proxy. It accepts requests, hands them off to Kestrel, gets the response from Kestrel, and then sends that response back to the client. IIS gives you your security and administration layer, while Kestrel just handles the grunt work of serving the requests.
As a result, IIS can be interchanged for pretty much any web server than can act as a reverse proxy, such as Nginx. This would work the same way. Again, you don't define anything with Kestrel. It's just grunting along serving the requests the reverse proxy forwards it. It doesn't know or care what that reverse proxy is, and it doesn't matter.
That said, in either scenario there is no such thing as a "recommended identity" to use. This is a security aspect you are responsible for making a decision on. IIS has a default service account and Nginx probably has one as well. (I haven't run Nginx on Windows, but on linux, it literally runs under nginx:nginx.) For some, that's fine. Others decide to use a dedicated network account or a custom local service account. Still others decide to run under an actual user account. There's various reasons for each option and there's no one "right" way to do it, only a "right" way for your app, your server, your network, and your organization. No one can make those decisions for you.

How to implement Https on web facing nginx and several microservices behind it

I'm just starting to develop a SPA, with java(dropwizard) REST backend. I'm kinda new to 'web' development, but I did internal web apps before, so security was not a big concern before.
Right now I'm using nginx as my public facing web server, and I just discovered whole slew of complications that arise as we're splitting actual servers: static web server serving my SPA's files, and java microservices behind it.
I'm used to apache talking to tomcat with mod_jk, but now I had to implement CORS in dev because my SPA is deployed on a lite-server serving at different port than the REST Api served by dropwizard.
Now I got to my minimum viable product and wanted to deploy it on prod,
but I have no idea how do I do it.
Do I still need the CORS header? Dropwizard will be run separately on a different port only available to local processes, then I configure nginx to route incoming request from, e.g. /api/ to that port. Does that counts as cross-origin?
I'd like to serve full https. Dropwizard can serve to https, but I don't want to update SSL cert on multiple microservices. I read about nginx ssl termination, will this enable me to use plain http in local and https on nginx?
Any other caveats to watch out on deploying with this architecture?
Thank you!
Yes, you can certainly do it!
You can terminate https with nginx, and still have the backend operate on either plain http or even https still. The proxy_pass directive does support both access schemes for the upstream content. You can also use the newer TCP stream proxying, if necessary.
There are not that many caveats, really. It usually just works.

IIS Reverse Proxy ARR with certificate authentication

I have a scenario where I want to consume a Webservice from a different server within our corporate network using JQuery. My origin application is an ASP.NET Website running on IIS 7.5, the Webservice is running on an SAP Netweaver Gateway, so no Chance to allow my IIS host there or to use JSONP.
The problem is that I run into the CORS issue, so I installed ARR on my IIS machine and tried to do a rewrite url and use my IIS to consume the remote Webservice. But the problem is, that the target Webservice requires Certificate authentication and it seems that this is not supported by ARR. Am I correct?
Any help is appreciated,
Oliver
I have had a similar issue, in my first try I had both my application and ARR running on the same box and this was causing the Application's Authentication module to start first before ARR and was messing up the things, I found success when I had both of them run on different boxes. Below link helped me
http://blogs.msdn.com/b/asiatech/archive/2014/01/28/configuring-arr-with-client-certificate.aspx

How to use Forms Auth when SSL is on a proxy in front of the IIS Farm (WCF)?

Here is my scenario:
I have a proxy that actually has the SSL Cert installed and this sits in front of a load balanced web farm. Each IIS server does not have SSL so I can't use transport security via wsHttp binding. I have not investigated basicHttp because we want to provide SOAP 1.2 going forward w/ this solution. In addition to this, my network team won't allow any use of certs to encrypt at the message level. (this alone would solve my dilemma i'm sure)
My security group has a requirement that we use Forms Authentication (membership provider).
The final solution must allow SSL via the front proxy, yet some type of WCF binding to keep complexity encapsulated in a config file.
I was working with a custom binding that allowed for username/password sent via clear text, but when I try to connect via https i get the usual "http expected" uri error.
How can I use SSL via the proxy to connect securely from client app to web service, but not have SSL installed on IIS and leverage the WCF stack + forms authentication?
I'm not new to WCF, but this very custom setup seems to have me unsure if the requirements allow for any type "easy" solution.
Thank you in advance!
EDIT: I did finally get this working and decided to write a short blog post with complete source code required to write the custom binding.
I think this is similar to a problem many have had when wanting to provide WCF services over SSL when the actual service in IIS is behind an SSL-offloading device. In which case, the following two pages should help you out:
http://blog.hackedbrain.com/archive/2006/09/26/5281.aspx
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/87a254c8-e9d1-4d4c-8f62-54eae497423f/
Basically you need to lie to WCF and say that the service is secure, even though the traffic will be conducted over HTTP (between the service and the proxy).