Shield Hybrid Data Pipeline Product From Malicious Usage

What do you get from this blog?

This blog introduces the Hybrid Data Pipeline IP Whitelist feature that could be used to provide secure access to critical resources by means of defining a set of IP addresses that you trust. This blog will explain how the IP Whitelist feature works with the help of an example.

Feature Highlights:

• Take control of your system by defining Whitelisted IPs at different levels – System, Tenant and User.
• Safeguard critical resources by allowing access to legitimate IP addresses.
• Support for a set of IPs to be whitelisted on a 'per resource' basis for more granular control.
• Easy to use APIs.

How to configure IP Addresses?

The product supports a set of APIs that can be used to configure the IP addresses at System and/or Tenant and/or User level.  Administrators can choose to define the IP addresses at one or more levels depending on how the product is deployed and the use-cases that it is trying to address.

Administrators can choose one of the following APIs depending on the level at which they wish to apply an IP whitelist.

/api/admin/security/whitelist/system for System level
/api/admin/security/whitelist/tenants/{id} for Tenant level /api/mgmt/security/whitelist/user?user={userName} for User level  

Following is the list of resources that could be protected by defining IP whitelists on a 'per resource' basis:

Administrators API
Management API
Data Access (JDBC, ODBC and OData)
WebUI Access (applicable only at system level)

The selection of the resource(s) is part of the request payload
{
    "managementAPI": [],
    "adminAPI": [],
    "dataAccess": [],
    "webUI": []
}

Both IPv4 and IPv6 formats are supported.  A single address can be defined as well as a range of addresses can be defined.

Example of a single address per resource -
"adminAPI": [
    {
      "startAddress": "172.16.25.0"
    }
  ]

Example of a range of addresses per resource -
"adminAPI": [
    {
      "startAddress": "172.16.25.0",
      "endAddress": "172.16.25.100"
    }
  ]

As seen in the payload, each resource allows a list of IP addresses to be defined.
"adminAPI": [
    {
      "startAddress": "172.16.25.0"
    },
    {
     "startAddress": "172.160.35.0",
     "endAddress": "172.160.35.10"
    }
  ]

How IP WhiteList feature works?

The order of IP checks starts from system level, tenant level and user level as shown in the following diagram.



IP WhiteList feature is ON by default, it can be turned OFF using the API /api/admin/configurations/8 by a system administrator.  If there are no IPs defined at any of the levels, all the requests will be served.

Configuring at System Level:
If the IPs are configured at System level resources, the whitelist is effectively applicable to all the users accessing the system irrespective of the tenant they belong to. After passing through the system level checks, the next check will be made at a tenant level, if it exists.

Configuring at Tenant Level:
If the IPs are configured at Tenant level resources, the whitelist is effectively applicable to all the users who belong to that tenant. After passing through the tenant level checks, the next check will be made at a user level, if it exists.

It is possible for the system administrator to delegate the job of managing the IPs to a tenant administrator by granting the permission IPWhiteList(29). 

Configuring at User Level:
If the IPs are configured at User level resources, the whitelist is effectively applicable to the individual users who request access to the protected resources.

Defining at Multiple Levels:
If there is a whitelist defined at multiple levels, ensure that they are also defined at the preceding levels. For example, whitelists defined at the tenant level, also need to be defined at the preceding level - system. Similarly, whitelists defined at the user level, also need to be defined at the preceding tenant and system levels.

Example Use-Case:

In this example, we will restrict WebUI to be accessed only within the network where the Hybrid Data Pipeline is running.  We assume the range of IPs in the network is 172.21.60.20 to 172.21.60.30.

How to achieve this?
This example assumes that you don’t have any IPs configured yet at system level.
Apply a range of IP Addresses for the “webUI” resource at a system level using the following API:

POST /api/admin/security/whitelist/system by using basic authentication of system administrator.
{
    "managementAPI": [],
    "adminAPI": [],
    "dataAccess": [],
    "webUI": [
{
"startAddress": "172.21.60.20",
"endAddress": "172.21.60.30"
}
]
}

How to validate and test?
For a positive case, try giving a range that includes your machine’s IP address and hit the login URL https://<server>:<port>/hdpui from a web browser. You will see a login page.

For a negative case, try giving a range that excludes your machine’s IP address using a PUT method. Hit the login URL, now you will see an 'access denied' message.