2

We are discussing about making available through the internet one of our microservices deployed on a public cloud on Kubernetes. This ms offers some sensitive information to the clients.

This microservices will be protected by HTTP Basic security and be exposed with TLS.

In addition we intend to add IP whitelisting to limit the range of IPs that can access it, so only our corporate network computers will be allowed to access it.

Is IP whitelisting safe enough, is it hackeable in some way?

Any recommendation to improve this approach or directly avoid it?

codependent
  • 187
  • 9
  • Which public cloud? Is this a windows AD environment? What scale is your operation? – DarkMatter Jan 11 '19 at 18:19
  • Google Cloud. The ms exposes a REST API. Local corporate applications need to call that service using HTTP Basic to obtain startup information such as database credentials. Our env isn’t Windows AD – codependent Jan 11 '19 at 18:23
  • I'd recommend whitelisting in general, but if you're already using TLS, why not use client certificates too? – Polynomial Jan 11 '19 at 18:33
  • Your title says "API whitelisting" but your question says "IP whitelisting"; what exactly are you filtering on? Is the web service public on the Internet but some APIs only available from certain IPs, or is the whole service restricted to those IPs, or...? – CBHacking Jan 12 '19 at 01:20
  • Ups, I have corrected the title: it’s IP whitelisting, the whole REST API is protected by IP – codependent Jan 12 '19 at 01:27

2 Answers2

2

Just some clarifications/assumptions on my part based on your question. You would like to expose a micro-service API running on Kubernetes to the internet. The API in question is running on top of an HTTPS server which allows for TLS encrypted communication. What you want to know is if white listing is sufficient for protecting your API. Let me know if I missed any thing.

My initial answer is no, this is not secure. Or rather, it's not as secure as I think it should be. You have not made any mention of securing the API in anyway other than IP listing. Is this an open API that allows access to sensitive information? How else are you going to establish trust with your remote systems and users? Are you sure that your remote systems will always come from the same IPs? What happens if one of the IPs is compromised?

Going beyond my initial barrage of questions, I think we should look at a couple of key principles that I rely on when trying to design security solutions for companies.

First, I never trust the network unless I absolutely have to. Any chance I can implement a solution that performs verification, I do that. Whitelisted IPs do not pass this measure because an IP address is not a form of identity. IPv6 does have some capability to perform identity through an address, but it's not widely adopted and I don't think the standards are mature enough yet.

Second, identity is the biggest factor to your security. An attacker can come from anywhere, and in some industries the biggest risk for attack is actually from within your own company. Healthcare has the largest internal risk with a whipping 65% chance of being compromised from within. You mustknow who had access, when, and whether or not they should have access. You should know the machine they had access with and whether or not it's known. And if you can afford it, having the behavioral history of actions to check the traffic is a major benefit too. All of these identifiers are what will protect your API.

Third, once you have an identity management system in place, you need to ensure that you can properly authorize and audit user access.

Now, if you have all of these things built into your API already, then all the best to you. Overtime, you may find it beneficial to migrate from a white list to a blacklist which allows you to block the trouble makers. You can even automate this with the right types of scripts/automation and reduce the chance of blocking your clients. This will help to reduce your operational burden and reduce the potential impact to your clients, a win win.

Connor Peoples
  • 1,421
  • 5
  • 12
  • I appreciate your detailed answer. I’d like to clear up the context. As you correctly say, I have a ms that offers an API running on K8s exposed to internet. This ms is secured with HTTP Basic authentication, communicates with TLS and has a whitelist configuration so clients need to be in the allowed whitelisted network, and authenticate with their credentials. This is the scenario in which Id like to know if it’s secure enough, or could be improved in any way. – codependent Jan 12 '19 at 10:13
1

HTTP Basic Auth over HTTPS would be as secure as any login form via HTTPS. It’s OK to authenticate users in this way.

Of course now you should worry about every HTTPS detail: certificate pinning / protecting against reissue by an attacker, rejecting weak cipher suites, CSPs, iframes, etc...

Limiting the access to the ip range is more on the edge. You can’t trust the IP in the TCP packet: it is specified by users/hackers machine. Although in order to successfully complete TCP handshake you need to exchange messages, and if you’re faking your IP the messages are arriving at the computer with the fake IP. The attacker needs access to communication channels or to destination computer, or something clever. So...

If in doubt – don’t trust. Limiting IPs is not sufficient to guarantee security, but it definitely protects against some attacks. It’s also a pretty big inconvenience: you need to track the changes in the ip ranges of your client. Also your system would reject access in case of the internet/power outage on the client’s side and somebody trying to do something critically important from their smartphone. Or if client changes provider.

Andrew Morozko
  • 1,759
  • 7
  • 10