0

In the following scenario, I'm looking to see if I can provide adequate security as is or if there would be any tangible benefit to re-architecting things (like changing it so that the service in question would be in a DMZ, or something like that). Assume that the data I'm trying to protect is highly sensitive and it would be a major headline if it got exposed.

  • On a server that has access to the internal network (because we also need to access a database or other internal services), there will be a gRPC service that listens on a specific TCP port.
  • I know in advance that I only want a client from a single known, trusted IP to connect in, so we'll create a rule in the external firewall to allow incoming TCP connections from that single IP to the IP endpoint of the gRPC service.
  • For encryption and authentication, we'll also be doing TLS 1.2 mutual authentication on the gRPC service.

As far as what I've been able to think of, this should be more than acceptable because the only way to be able to connect in on that port would be to either legitimately have that IP (and it's a static IP where we trust the entity that the IP has been assigned to) or to spoof it, and a potential attacker would have to know that you would have to spoof that specific IP, which seems very unlikely without insider information (and even then, you'd only be able to send in packets trying to damage things and wouldn't get responses back because they'd route to the real IP, right?). Assuming that a malicious actor were to gain control of that IP, they'd still have to have the appropriate certificate to get through the TLS piece, know the type of protocol that they're trying to exploit, potentially need application-layer credentials, etc. I only see this as a likelihood if the actual client machine that I expect to connect in gets compromised; as far as I know, it has good physical/network security around it, so I think this should be very improbable.

Additionally, what about if I didn't firewall it at all? Would the security level still be acceptably high since you'd have to either have a legitimate certificate signed by the same CA as the server's certificate, or have an exploit up your sleeve in order to get past the TLS authentication? I'd firewall it either way since there really is just a single client I want connecting in, but I'm also curious about this.

Are there other issues that I'm not thinking about, or any other good reasons that should lead me to abandon this sort of setup as insecure? Thanks in advance.

Kdawg
  • 103
  • 2
  • 1
    "because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent. – Patrick Mevzek Apr 17 '19 at 23:45
  • Your setup is very similar to what is done in the domain name industry, read https://tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level. – Patrick Mevzek Apr 17 '19 at 23:47
  • If you start now from scratch you may as well use TLS 1.3 and nothing else. – Patrick Mevzek Apr 17 '19 at 23:47
  • @PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer). – Kdawg Apr 19 '19 at 18:20

1 Answers1

1

Your setup is very similar to what is done in the domain name industry, read RFC 5734 for example. There are 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.

You can not just base your authentication on IP addresses, even if using TCP, because BGP spoofing happens, which means someone may "grab" your IP address and be able to originate traffic from it and get replies. This may last only a few minutes, but already enough for some harm to be done. Hence, you need to authenticate at the TLS level too: TLS provide multiple services, among which confidentiality and authentication; where everyone concentrates more on confidentiality (also because it is the easy part to get right), in fact authentication is more important, without it you can send encrypted content but to an unknown party which can be seen as similar as sending in plain text.

Of course, and specially with DV-certificates, if BGP spoofing happens someone will be able to generate certificates also. This will be mitigated by CAs using DNSSEC-aware resolver and multi-vantage points to do the validation. Which means that problem will begin to happen only if you loose at the same time control of your IP address space and also your authoritative nameservers. The issue can also be mitigated if you do not rely on external public CAs, but if you manage it purely internally and hence trusting only certificates generated by your CA. Of course your CA needs to be heavily protected, and its keys should be offloaded in some cold storage, like HSMs.

If you do not filter at all on IP addresses, with some firewall rules, you risk DOS and DDOS: even if people will not break into your system just by doing that they may render it unavailable, and availability can be seen as part of security.

Also, for any new setup today where you control both ends and do not need any backward compatibility, you are well advised to start directly with TLS 1.3 as it has numerous advantages over TLS 1.2

Community
  • 1
Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43