Idea Details

Ability to select port(s) where a service should be exposed

Last activity 06-13-2019 09:45 AM
Michiel Helder's profile image
10-22-2015 04:20 AM

I would like the ability to set which listen port(s) a service is available on in the Service Properties.

This would make it much easier to limit outbound services (creating an internal service to access an external service) to only be accessible from the internal network. As far as I know right now this can only be done by including an IP restriction or by comparing the listen port in the policy. But in both cases the service still exists on the external interface and generates an error response when it's called.

I would like to have a scenario where we set up a separate internal and external listen port (bind to specific interface) and can configure in the service properties on which port(s) the service path is made available so it doesn't exist at all on the external interface.


Comments

01-15-2019 05:33 AM

Hi Michiel, basically I agree with what you've said, my comments here are to help give some options to look at for those caught in the now, where the feature doesn't yet exist.  

01-15-2019 03:38 AM

Hi Mark,

 

As mentioned before, we are aware of the current options on how to solve this in the gateway. It's just that we have seen this fail with several customers. In many cases the gateway having separate external and internal interfaces makes people think that a policy can and will be deployed as an internal policy. They develop the policy with that in mind, but for some reason forget to include the required security within the policy. I have seen several times that internal policies were exposed externally without or with very limited authentication on them.

 

Having a listen port binding option in the service properties makes it part of the service configuration/deployment process and much more obvious and harder to miss when setting up a new service. I hope that makes sense.

 

As for the earlier question on error handling: I think it should be handled like any unresolved service.

 

Thanks,

Michiel

01-15-2019 01:06 AM

As mentioned often this requirement is done by having two API Gateway's installed, one internal one external.  The external one providing a more limited subset of services and proxying/passing them onto the internal gateway. 

 

Additionally, here are two workarounds that may work for your use case: 

 

1) Add global pre-service policy, which fires after service resolved, and check service + tcp access for matches/ failures.

https://communities.ca.com/message/242161409-re-prevent-internally-facing-policies-from-being-accessible-on-externally-f… 

 

2) The listen port can bypass resolution and be pointed to specific service, that service can then check the URI allow restricted set of services to proceed, and give error for others.  The proceeded services the forward the request to another port on the same API Gateway. 

https://communities.ca.com/message/242161409-re-prevent-internally-facing-policies-from-being-accessible-on-externally-f… 

 

Cheers - Mark

01-14-2019 06:45 PM

The feature to be able to bind specific services to a particular listener at deployment time (so also requires restman enhancements) would be useful for physical security. 

 

Preventing certain services from being exposed at all on public facing interfaces would be of interest to our banking customer.

01-10-2019 02:03 PM

What I've done is essentially set a check in the services on what port the request arrived on, so one port is listening to the internal facing load balancer and the other listens to the external facing load balancer, then the network firewall team ensures each of those is only reachable from the appropriate network segments.

12-20-2018 07:33 PM

Just to add the experience from another customer. 

 

They have several different interfaces and listening ports, each directed from different parts of the networks.

 

They would like to enable some access to "external" and restrict other accesses to "internal" - but this is not possible in the current design.  "Published service message input" is all services, or one can select one specific service. 

 

 

So what they would like is something like the expanded list for "Built-in services" where each service can be individually selected as enabled on that interface/port.  

 

An example of problematic service is /restman, where there is no way to easily exclude it from the "published services".

 

Workarounds are : 

1) Implement a pre-service global policy and check the target interface and raise an error.

 

2) Use two different API Gateway's one for internal and one for external, or one that proxies the request to the second gateway. 

 

 

Cheers - Mark

01-20-2017 05:28 PM

Intriguing, I think this setting would belong in the service properties not in the port settings...

also I think you would want to return a 404 instead of drop connection (as if you resolved into your catch-all instead of a non-existent port)

10-22-2015 05:22 PM

Yes, I am aware of this option. That's basically what I meant with comparing a listen port in the policy. But since it's such a common use case, at least for many of our customers, it would be really great if this could be a simple configuration option in the service properties.

10-22-2015 11:26 AM

As you're probably aware, you have the ability to bind specific listen ports (Policy Manager > Tasks > Manage Listen Ports) to a specific network, subnet or group of networks using the Interface tagging feature: https://wiki.ca.com/display/GATEWAY84/Manage+Interfaces

 

To avoid giving away that an internal service is exposed on the external listen port you could use a message-received global policy to check the port and simply drop the TCP connection using the Customize Error Response assertion.  No response is sent to the client in this case.

 

Not exactly what you're looking for, but you're not giving away the fact that there is a service at this endpoint which sounds like your primary concern.