It is advised that asp net core must use a strong web server such as web listener
or a proxy as an internet gateway. My question is: is the build in reverse proxy strong enough to be that role? If I use asp net core + kestrel in my internal service and all external communication goes through reverse proxy after load balancer, is it secure?
Short answer: no
It's just a proxy with some smart retry logic.
You want to put a WAF, or Azure API manager, in front of it if you want to publish all your internal services to the internet and use kestrel, or use web listener for all your services.
Yes.
"The reverse proxy is built on the same Windows HTTP Server API (http.sys) that WebListener uses which provides the DoS protection that is currently missing from Kestrel." - Vaclav Turecek (github)
Related
In OutOfProcess hosting model, there are 2 web servers i.e. one internal web server and one external web server. The internal web server is called Kestrel and the external web server can be IIS, Apache, or Nginx.
When Kestrel is the cross-platform web server for the ASP.NET Core application, and support request from all platforms, then what is the use of external web server?
The IIS or apache contains a lot of advanced feature. For example, advanced logging, GUI ,failed request trancing and other feature. It is very easy to configure and find the logs more easily.
The Kestrel need all settings by the codes and if you need special feature, you need to develop by yourself or changing the codes.
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
I am working with CoAP protocol on IoT but also I need a web service. I implemented the web service on Apache with HTTP protocol and a Proxy that converts CoAP-HTTP request and responses. But I don't want to use the Proxy to convert CoAP-HTTP. I want to implement directly CoAP web service. Do you have any idea about that. On Apache or different things. Just any idea?
As you wrote On Apache or different things, I will here talk about the second option :). To implement the CoAP server itself, I would recommend either
NodeJS with the CoAP package
Java implementation Californium, from Eclipse.org
More complete list available at http://coap.technology/impls.html#server-side, see Server-side
And then handle the communication with your Apache HTTP server via WebSockets and REST APIs.
coap.me is also great to run tests during development.
I have a number of WCF 4.0 rest services on an internal application server which are accessed from a DMZ'd public facing web server. Essentially I am looking for the simplest way to restrict access to the services to calls from the web server and select internal accounts. It seems like a simple task of which I can find no simple answer.
Info:
IIS6 for both the web server and the application server
.NET 4
Web Server is not a part of a trusted domain
REST Services are 100% code.
Client calls are passing credentials via System.Net.CredentialCache.DefaultCredentials ( not sure if this is the way to go )
For the network part, you can disallow all IP's except the one of the ones you trust in IIS.
If I have a WCF SOAP (C#) based web service running in my local IIS - and I make an ASP.net website, again running in my local IIS - will the javascript making HTTP request calls from my webpage be successful? Or do the same origin policy rules come into play here?
It depends on how your sites are configured in IIS. Check out this wikipedia article on same origin policy.
Let's say your WCF SOAP service is running on http://localhost/service/GetStuff.svc and your ASP.NET site is running on http://localhost/mysite/Default.aspx. According to the table in the same origin article, the call should succeed, since your server host is the same in both cases (localhost) and differ only on the directory being referenced.
But, if your WCF SOAP service is running on http://localhost:8080/service/GetStuff.svc and your ASP.NET site is running on http://localhost/mysite/Default.aspx (default port of 80), then the call will fail since the server host differs in the port being accessed.
The three things to consider are host, protocol (http or https) and port. According to the article, not all browsers enforce port.
I hope this helps. Good luck!
BTW, does your application work?