Risque d'exploits "en arrière" dans les connexions tcp sortantes

Question

Je construis une application serveur qui maintiendra les connexions à d'autres applications en initiant des connexions TCP via un pare-feu qui n'est ouvert que pour le trafic sortant vers les ports IP concernés que l'application se connecter à.

Quel est le risque que quelqu'un prenne en charge la ou les machine (s) que nous connectons pour pouvoir exploiter notre application vers l'arrière via la connexion sortante que nous avons établie.

Le protocole utilisé pour la connexion n'est pas difficile à déterminer, mais il est basé sur un rythme cardiaque périodique (intervalle de 30 secondes). Si deux battements de cœur successifs sont manqués, l'initiateur (us) terminera la connexion et reconnectera.

Le code source ou les binaires pour notre application ne seront pas disponibles pour l'organisation à laquelle nous nous connectons.

Answer 1

Si votre propre serveur d'application ne l'écoute pas pour les données entrantes, il y a très peu de risque

Answer 2

Ils ne peuvent rien faire pour vous parler autre que votre protocole à vous. Le risque est précisément que tout ce qui peut être fait, de la fin à la fin, en utilisant votre protocole, sera fait.

N.B. Je ne veux pas dire qu'ils doivent parler une bien formée version de votre protocole pour vous. Si votre système lit les messages entrants dans un tampon statique en utilisant fgets(), alors les dépassements de tampon font partie de ce que vous pouvez faire en utilisant votre protocole.

Answer 3

Il est facile pour un attaquant de flairer le trafic réseau vers votre serveur s'il a accès à la machine ou au réseau auquel vous vous connectez. Cela pourrait lui permettre de procéder à l'ingénierie inverse de votre protocole, puis d'essayer d'injecter des données malveillantes dans les données renvoyées à votre serveur ou de remplacer complètement l'application côté client. Comme il semble que vous ne pouvez pas faire confiance à l'application côté client, peu importe qui initie la connexion, une fois que c'est en place, vous avez un canal de communication bidirectionnel. La meilleure chose à faire dans ce cas est de valider toutes les données provenant du client.

Si vous pouvez faire confiance au client, mais pas au réseau, l'ajout d'un cryptage à votre protocole réseau vous aidera.

Answer 4

Votre scénario est assez commun, il est vraiment rare d'avoir un réseau complètement isolé de l'Internet. Cela dit, tenez compte des facteurs suivants:

• Les tiers peuvent envoyer des informations en fonction de ce que le protocole prend en charge. C'est à peu près une bataille perdue, car il n'y a rien sur quoi vous pouvez vraiment compter qui les bloquerait complètement. Voir ci-dessous.
• Si vous voulez vous assurer que l'information provient du bon tiers, alors vous devriez avoir besoin d'informations signées. Certains protocoles de niveau supérieur peuvent le faire pour vous. Vous êtes exposé à des vulnérabilités dans la mise en œuvre, mais si le protocole le prend en charge, il sera à peine vulnérable.
• Si vous voulez vous assurer que l'information est privée, vous avez besoin du cryptage. Certains protocoles de niveau supérieur peuvent le faire pour vous. Les mêmes commentaires que ci-dessus s'appliquent.
• Vous êtes exposé à toute vulnérabilité dans les protocoles de niveau inférieur utilisés (implicitement ou explicitement). Il est à la fois impossible et peu pratique de tout faire rouler, et si vous l'avez fait, vous risquez d'introduire des vulnérabilités. Bien sûr, assurez-vous d'avoir les derniers correctifs.