So basically the use-case is let’s suppose I have certain reverse proxy rules configured by my users dynamically in the caddy config. But I do not want them to be able to set upstream to some local service running on a port on my machine which is running caddy server as well.
There are few ways users can set upstream to local services.
Directly setting upstream address as localhost:9001 or 127.0.0.1:9002 etc. (Can be restricted using hard checking at time of config updation)
Some domain let’s say example.com which resolves to 127.0.0.1.
Some domain let’s say example.com redirects to example2.com which resolves to 127.0.0.1.
I can’t control this at other service level because some routes in config are required to proxy to these services as well.
Is there a hander level check that can be introduced to restrict this scenario. We’ll need to check IP after DNS resolution and redirects have been performed.
I assume you expose some API or interface which allows your users to add routes to your caddy config. Why not filter what they can add in your application logic?
It’s unclear what you’re asking. Please properly complete the help topic template, including your config, logs, and how you’re running Caddy. It matters.
@francislavoie I will try to add more details in a while.
@melink14 Hey, Looks like you understand my query here, actually I am going to add that filter. But still there is a use-case that after creating the rule using my API, user can edit the A record for the given domain and point it to 127.0.0.1. Now since DNS will be hosted somewhere out of my control and Caddy server will perform the resolution at the request time.
Only possible way I could think of is to write a caddy module and call it before every reverse proxy module call and “resolve to an IP address for a given domain name in reverse proxy handler” if applicable and then apply the conditional logic of rejection or acceptance.
I think the extra details will be useful since it’s hard to relate your problem to caddy specfically.
Have you actually been successful in the types of work arounds you’re describing?
For example, even if the A record points to 127.0.0.1 that shouldn’t change how caddy routes those requests since the HOST of the request will still be domain.com. As far as I know, caddy is not resolving DNS of requests in order to route…
I think if you had some example caddy configs which were vulnerable then it would help us see exactly what you need at which layer.
this.