search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.34k stars 9.98k forks source link

Add IP range support to AllowedHosts #41702

Open vocko opened 2 years ago

vocko commented 2 years ago

Is there an existing issue for this?

Is your feature request related to a problem? Please describe the problem.

Currently allowed hosts (host filtering middleware) only allows to set an exact ip address. It would be very useful if it can support an ip range (ie. 172.28.0.0/16). An example use case can be an automatic scaling scenario where the exact ip address of the newly spun up instance is not known.

Describe the solution you'd like

Would be helpful if we can define an ip range within the allowed hosts configuration settings.

For example: "AllowedHosts": "mydomain.com;172.28.0.0/16"

An implementation I would like to have can be found here https://gist.github.com/akotranza/8d6539ac378087ac703dde3ec6b74308

Additional context

No response

Tratcher commented 2 years ago

Allowed hosts is for host names specified in the Host header, it's not intended for IPs. Do your requests have IPs in the Host header? Why?

vocko commented 2 years ago

My scenario is a web app that runs behind load balancer that spins up instances as needed. The host url is terminated at load balancer and it is then redirecting the traffic to the instances. However, they only have ip addresses, no host names (there is no point having internal host names). I have solved the host filtering problem by forwarding the headers, up here everything works fine.

The problem is with health checks that the load balancer is doing. I have used the health checks middleware and it all works fine, except for the host filtering as it causes the health check to return 400. Health check is on ip address only as it is a call between the load balancer and the instance. I have fixed it by adding the appropriate ip addresses to the host name, however, maintaining a wider (and dynamic) list of ip addresses is not ideal.

Two solutions I can think of: 1) Allow ip ranges in the allowed hosts (as requested above). 2) Allow to bypass the allowed hosts for certain endpoints (ie. health checks).

If there is another solution I can use for the scenario above, I will be happy to learn about it.

Tratcher commented 2 years ago

What load balancer are you using? Can it also set the Host header for health checks?

vocko commented 2 years ago

AWS EC2 load balancer.

It is not possible, I have even checked with AWS support and this was the answer:

ALB only sends the private IP address of the target as a default value over Host header, it is by design unable to modify.

They've told me there is a feature request to make that possible, but there is no ETA atm for when it could be available.

adityamandaleeka commented 2 years ago

We should address this in 7. Not sure exactly which approach to take yet though.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

octomad commented 2 years ago

@vocko We have this same issue and got around it by just setting the AllowedHosts: "*" and leaving AllowedForwardedHosts to be more specific.

 "AllowedHosts": "*",
 "AllowedForwardedHosts": "www.example.com;example.com"

If you're behind a reverse-proxy, then the Host header is going to be rewritten anyway.

ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Simonl9l commented 3 weeks ago

Guess this never made .Net 8, or .Net 9?

As an additional aide and probably worth of another issue: Is does to seem possible to configure host filtering to return a Json payload, Just Http? For an API it would be helpful if hosts that don't pas the filter, recieved a json error response payload.

Ben3152 commented 3 weeks ago

I'm currently running into the same problem as vocko. The current options look to be either allowing the health check to consider a 400 a good response or turning off the filtering altogether. Neither of which is a great option if the goal is to enable host filtering.