6

I have several processes running on a system that interact with each other by TCP (eg. with the asynchronous messaging protocol by twisted).

process1 <=====> broker <=====> process2

There is one server instance (broker) running on a linux host, that listens to a TCP socket localhost:port. There are also some other processes, running on the same host, which query the broker instance by using the socket via TCP (given by twisted). The broker has access to a hardware security module (HSM).

I'm currently thinking about the security aspects of this design. Would it be possible for an eavesdropper, who has direct physical access to the host, to listen to the TCP traffic between the clients and the broker on this host? Since sometimes sensitive data is being transferred, I want to secure the communication between the processes and broker on the host.

How can this be done? There is always the problem of storing a private secret. For the broker its no problem because it has access to HSM, but for the client-processes which interact with the broker. Its hard to hide a secret for an attacker which has physical access to the host. How can authentication/encryption between processes and broker be realised?

Hope you understand my problem and can help me!

EDIT: SSL/TLS wouldn't be a good approach, since it comes with high overhead and there also exists the problem of secure storage for private secret.

Ovomaltine
  • 63
  • 1
  • 4
  • What kind of access has your attacker? If he has the same or higher permissions than your applications he might also compromise your processes to grab the traffic from inside the applications directly. If he does not has this access he can also not sniff localhost traffic unless your tcpdump or similar allows anybody to sniff it (i.e. setuid). – Steffen Ullrich Dec 27 '16 at 15:40
  • Basically the attacker can gain any access he is able to when he gets direct physical access to the machine. So reverse engineering, sniffing of local traffic is possible. Therefore I'm looking for options to encrypt/authenticate this traffic. But here lies the already mentioned problem of storing the private key securely. – Ovomaltine Dec 28 '16 at 09:28
  • With this kind of access encryption does not help much since the attacker could probably grab the data before encryption. You cannot trust any software running on a potentially fully compromised system. – Steffen Ullrich Dec 28 '16 at 09:31
  • Ok you're right. But it would be at least an acceptable level of security if the attacker cannot sniff the local TCP traffic. Grabbing the data from the processes would be even more challenging for the attacker, since the allocation of python objects is not so easy foreseeable than just listing on the TCP communication on localhost. – Ovomaltine Dec 28 '16 at 09:35
  • The attacker could simply replace ssl.py so that your python process does not do any more encryption at all. Or that the data are written to a file before encryption or similar. Don't address problems in an ad-hoc way (i.e. doing something is better than nothing) but instead start hardening your system where it makes most sense. Of course you need to do a proper and thorough analysis first how your system can be attacked at all. – Steffen Ullrich Dec 28 '16 at 09:38

3 Answers3

4

If you want to restrict inter process communication on a machine, I'd suggest doing away with TCP and instead uses Unix domain socket. Unix domain socket can be used exactly the same way as TCP (it's a bidirectional socket), but it creates a socket file instead of listening on a TCP port. You can control permission on the socket file using standard filesystem permissions. Twisted supports Unix domain socket.

If you really have to use TCP, then you can use SSL without encryption. By default, the eNULL cipher and aNULL authentication is not permitted in OpenSSL, but you can explicitly request for it. I personally would not recommend this.

You may also have some luck defining iptable rule that restricts how processes can connect to some TCP port.

On the whole though, trying to defend against someone with unrestricted root/physical access to your machine is a futile effort, and encryption for inter process communication within the same machine is rather silly but it's fairly harmless.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
2

Listening on localhost traffic is possible on Windows and Linux as well.

In Linux tcpdump -i lo.

You should consider at least encoding with special algorithm your communication and also consider protecting the process of broker from being dumped, debugged or reverse-engineered.

Opaida
  • 323
  • 1
  • 3
  • As I stated in my question I know that I face those scenarios that make encryption/authentication of the data necessarry. But the question how this can be achieved, especially how to store the private secret securely (eg. in a HSM). But not every process has access to the HSM. – Ovomaltine Dec 28 '16 at 09:29
1

The communications between these processes can always be intercepted by an attacker with privileged access to the system.

With root access to the box, the attacker owns the system and can circumvent anything and everything you implement (for the most part). Encrypted traffic? The functions that process the encryption keys can be hooked or the process memory can be dumped. Anti-reverse engineering is a possibility, but it can always be circumvented by someone skilled enough. The more effective and secure way of doing this would be writing an LKM that enforces the security of your processes at the kernel level; this requires a great deal of experience in kernel programming and is extremely difficult to do correctly (dare I say impossible?!) -- someone will always find a loophole, though it's something to consider.

Also, non-root users can't create raw sockets, which are needed to sniff packets (meaning an attacker will need root access to your system in order to intercept communications between your processes).

Securing information on a system from an attacker who already owns it is not a trivial task. You can make it harder to access said information, but you can never fully secure it.

Hello
  • 163
  • 5