Is IP whitelisting safe enough for a HTTP Basic protected service available on the internet?

Question

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?

Answer 1

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.

Answer 2

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.