【问题标题】:Risk of exploits "backwards" into outbound tcp connections漏洞利用“向后”进入出站 tcp 连接的风险
【发布时间】:2010-10-15 18:46:49
【问题描述】:
我正在构建一个服务器应用程序,它将通过防火墙发起 TCP 连接来维持与其他应用程序的连接,该防火墙只对应用程序将连接到的相关 IP 端口的出站流量开放。
如果有人接管了我们连接的机器,从而能够通过我们建立的出站连接反向利用我们的应用程序,那么风险是什么?
连接上使用的协议不难弄清楚,但它基于周期性的心跳(间隔 30 秒)。如果错过了两次连续的心跳,发起者(我们)将终止连接并重新连接。
我们的应用程序的源代码或二进制文件将不可用于我们连接到的组织。
【问题讨论】:
标签:
security
tcp
firewall
network-protocols
exploit
【解决方案1】:
如果攻击者可以访问您正在连接的机器或网络,他们很容易嗅探到您服务器的网络流量。这可能允许他对您的协议进行逆向工程,然后尝试将恶意数据注入返回到您服务器的数据中,或者完全替换客户端应用程序。
由于听起来您无法信任客户端应用程序,因此发起连接的人并不重要,一旦建立连接,您就有了双向通信通道。在这种情况下,最好的办法是验证来自客户端的所有数据。
如果您可以信任客户端,但不能信任网络,那么为您的网络协议添加一些加密会有所帮助。
【解决方案2】:
如果您自己的应用服务器不监听任何传入数据,那么风险很小
【解决方案3】:
除了对你说你的协议外,他们不能对你做任何事情。风险恰恰是任何可以做的事情,从他们的一端到你的另一端,使用你的协议,都会被完成。
注意我并不是说他们必须向你讲一个格式良好的协议版本。如果您的系统使用 fgets() 将传入消息读入静态缓冲区,则“缓冲区溢出”是使用您的协议可以对您执行的操作的一部分。
【解决方案4】:
您的场景是一个相当普遍的场景,网络完全与互联网隔离的情况非常罕见。也就是说,请考虑以下因素:
- 第三方可以根据协议支持的内容发送信息。这几乎是一场失败的战斗,因为没有什么你可以真正依赖的东西可以完全阻止他们。见下文。
- 如果您想确保信息来自正确的第三方,那么您应该需要签名信息。一些更高级别的协议可以为您做到这一点。您在实现中会面临漏洞,但如果协议支持它,您自己的漏洞几乎不会减少。
- 如果要确保信息是私密的,则需要加密。一些更高级别的协议可以为您做到这一点。适用与上述相同的 cmets。
- 您会暴露于所使用的较低级别协议中的任何漏洞(隐式或显式)。自己动手做所有事情都是不可能和不切实际的,如果你这样做了,你很可能会引入漏洞。当然,请确保拥有最新的补丁。