Risk of exploits "backwards" into outbound tcp connections.

Question

I am building a server application that will maintain connections to other applications by initiating TCP connections out through a firewall that is only open for outbound traffic to the relevant IP's ports that the application will connect to.

What is the risk of someone having taken over the machine(s) we connect to being able to exploit our application backwards through the outbound connection that we have established.

The protocol used on the connection is not difficult to figure out but it's based on a periodic heartbeat (interval 30 seconds). If two successive heartbeats are missed, the initiater (us) will terminate the connection an reconnect.

The sourcecode or binaries for our application will not be available to the orginasation we connect to.

Answer 1

If your own application server does not listen for any incoming data then there is very little risk

Answer 2

They can't do anything to you other than speak your protocol to you. The risk is precisely that anything that can be done, from their end to your end, using your protocol, will be done.

N.B. I don't mean they have to speak a well-formed version of your protocol to you. If your system reads incoming messages into a static buffer using fgets(), then 'buffer overruns' are part of what can be done to you using your protocol.

Answer 3

It is straightforward for an attacker to sniff the network traffic to your server if they have access to the machine or network you are connecting to. This could allow him to reverse engineer your protocol, and then either try and inject malicious data into the data going back to your server, or replace the client side application altogether.

Since it sounds like you can't trust the client side application, it doesn't matter who is initiating the connection, once it's up, you have a two-way communication channel. The best thing to do in this case is to validate all the data coming from the client.

If you can trust the client, but not the network, then adding some encryption to your network protocol will help.

Answer 4

Your scenario is a fairly common one, its really rare to have a network completely isolated from the internet. That said, consider the following factors involved:

• Third parties can send info-in based on what the protocol supports. Its pretty much a lost battle, as there isn't anything you can really rely on that would block them completely. See below.
• If you want to ensure the information is coming from the right third party, then you should need signed information. Some higher level protocols can do this for you. You are exposed to vulnerabilities in the implementation, but if the protocol supports it rolling your own will hardly be less vulnerable.
• If you want to ensure the information is private, you need encryption. Some higher level protocols can do this for you. The same comments as above apply.
• You are exposed to any vulnerability in the lower level protocols used (implicitly or explicitly). Its both impossible and impractical to roll your own of everything, and if you did you are likely to introduce vulnerabilities. Of course, make sure to have the latest patches.