Layer7 API Management

Expand all | Collapse all

Prevent internally facing policies from being accessible on externally facing listeners.

  • 1.  Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 10, 2019 08:59 PM

    We're currently deploying a new CA API Management gateway environment to provide the security layer between ourselves and B2B partners.

     

    Our new API GW tier will front partner facing API policies to our partners connecting into our organisation but will also publish internally facing APIs for our internal systems connecting out to partners (for this use case, the GWs will be used for inspection of the responses coming back from partner APIs).

     

    With the way listeners work on the CA product, when we choose to publish business APIs to a listener, we can't be selective about which policies are published on that listener.  As all published APIs will reside on the listener, this means our partner facing as well as our internally facing API policies are exposed to partners.

     

    I've been given a few suggestion from CA support on methods to work around this, but just wondering if anyone in the community has also tackled this issue.



  • 2.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Broadcom Employee
    Posted Jan 13, 2019 08:31 PM

    I'm not if 2 layers of gateway (internal gateway and external gateway) could meet your need.

    If not, you may think of Restrict Access to IP Address Range Assertion - CA API Gateway - 9.4 - CA Technologies Documentation 



  • 3.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 02:18 AM
    the first thing you should do in a policy is know who you are dealing with. In case of an open (http) outgoing policy it is restrict the ip-adress with an internal range like Zhijun He said. So you are sure it is an internal user.
    Make it a Policy fragment so you can re-use it in other outgoing policies.
    Regards, Sebastian.


  • 4.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 05:53 PM

    Thanks for the suggestion.  We have 3 separate tiers of gateways.   B2C (internet accessible), B2B for partners connecting in and also when we connect out to partners and Internal.  All inbound traffic from B2C and B2B comes in through those tiers which are hosted in DMZs, then flows down to our internal GWs.  Outbound goes through our internal tier out to B2B then to partners.

     

    Unfortunately we don't have the option of using caller IPs and we are using straight pass through on our load balancers so mutual TLS termination happens on the GWs themselves.  But it seems so far that the consensus is to solve this with assertions.



  • 5.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 03:30 AM

    We're resolving this by:

    - using 2 layers: DMZ and LAN gateways

    - using split-brain DNS, so that same URL can be used either internally (e.g. points to internal facing gateway) and externally (e.g. points to DMZ gateway).

    - using same *public* SSL Certificate on DMZ and LAN Gateways. Alternatively we could have used internal PKI Certificate for LAN Gateway, with same DN.



  • 6.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 05:57 PM

    Using mutual TLS (using internally signed certs) when our Internal API GW tier sends messages out via the B2B tier may be just be the simple solution here. 

     

    We'd prefer if the internally facing policies on the B2B tier which our Internal GWs call were not published on the external interface of our B2B GW though, but it looks like that's unavoidable.



  • 7.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 07:36 AM

    You can go with the solution Sebastian provided and check on ip-range.

     

    Another option, since you are refering listeners, is to check on the used port(s). You can deny usage on the service if it not bounded to the required ports (drop, 404, ...)



  • 8.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Broadcom Employee
    Posted Jan 14, 2019 06:16 PM

    Just to cover this off from some extra information in the support case - there is Idea for allowing services to be selectively enabled on the different listenign ports - rather than by default being available on all ports : 

     

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

     

    And the other workaround was to implement a global pre-service policy, which is triggered after the policy is identified but before it starts, and to apply some filter logic there to restrict access to services there. 

     

    It seems you can restrict on localIP, which will work if you have different network address for external and internal, but it does not seem to have localPort, so there may be some limitations to this approach.

     

    But certainly the Idea enhancemnt request would be useful. 

     

    Cheers - Mark



  • 9.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Posted Jan 14, 2019 06:35 PM

    Thanks Mark,  couldn't we use this context variable for local port if we were going to restrict based on the port the requests came in on?

     

    Then we could follow the suggestion in the Ideas thread to...

     

    "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"



  • 10.  Re: Prevent internally facing policies from being accessible on externally facing listeners.

    Broadcom Employee
    Posted Jan 15, 2019 12:59 AM
      |   view attached

    Hi Jason 

     

    And to elaborate on one of the other workarounds that I touched on in the support case (which I've had time to expand here with an example).

     

    For requests forwarded to specific port, you can add a "Service Resolution" so that all requests on that Listen Port : 8082 here, directs the traffic to testProxy service - note that it does not matter what the URI value is, it is always forwarded onto the testProxy service. 

     

     

    Then in the testProxy service we can do a pattern match for those URI's that are acceptable on port :8082.

    If none are acceptable we return a template 401 response. 

    Otherwise we forward the request to another port, here localhost:8080 which resolves those services as normal. 

     

     

    So the above method gives us another way to allow only a small sample of services to be accessible via a specific port. 

     

    Cheers - Mark 

    PS: I agree the Idea/enhancement request to allow selection of which interface is usable would be a useful addition to the gateway.   The solution Mark He explained, with two API  Gateways is probably the more normal way I have seen this done.  

    Attachment(s)

    zip
    testProxy-sample.xml.zip   910 B 1 version