【问题标题】:Preventing connections bypassing firewalls when building a proxy在构建代理时防止连接绕过防火墙
【发布时间】:2013-11-18 11:34:54
【问题描述】:

我正在为特定应用程序构建各种代理服务器。客户端连接到此服务器并指定代理服务器应连接到的主机。从那里,代理服务器连接到最终服务器并来回中继数据。

在建立连接时,如何防止我的代理服务器的用户访问他们不应该访问的资源?例如,我不希望他们连接到 localhost 或我用于服务器管理的 VPN。我可以做一些黑名单,但我想知道是否有更好的解决方案只允许特定网络接口上的传出连接。可能是某种方式将 TCP 客户端绑定到特定接口,或者验证所选路由是否使用特定接口。

如果合适的话,我会使用 Node.js 来构建这个代理服务器,并使用标准的net.connect() 方法来创建到远程服务器的 TCP 连接。

【问题讨论】:

    标签: node.js networking tcp routing


    【解决方案1】:

    这个问题的答案完全取决于你正在构建什么样的“代理”,目前还不清楚,也许改写一下?

    如果您在谈论 SOCKS 或 HTTP 代理,恐怕这是不可能的,没有办法知道目标是否是 vpn 端点(至少从您的代理服务的角度来看)。您的代理应用程序可以过滤的唯一参考是在 socks 协商期间传递给您的服务器的 IP 地址或 DNS 名称,以及连接发起的源 IP 地址。但是,您可以使用防火墙,但这当然与代理无关。

    如果您正在构建某种防火墙/网络堆栈扩展/驱动程序、iptables/内核模块等,而您自己将在其中拆除并重新建立连接并执行严重的数据包摆弄,那么您当然拥有更大的控制权,并且能够检查几乎每一层连接。但是,在这种情况下,您的问题很难回答。

    您可以使用哪些软件/工具/语言,您在谈论什么平台?

    编辑:哎呀,错过了提到 Node.js 的段落,所以我假设您正在使用类似 socks 的协议将连接转发到最终目的地,并且您的代理应用程序无法查询更深的网络层。如果没有关于您的协议如何工作的更多详细信息,您所需要处理的可能只是来自已建立/将要建立的 tcp 连接的源 IP,以及在您的协议握手中协商的目标 IP/DNS。您也许可以使用它来让您的代理服务查询您的服务器或网络 vpn/路由配置(ppp.conf/ldap/yellow pages/database/what have you),以确定资源是否要受到限制。

    根据 cmets 中的信息更新:

    好的,我们可以将其分为 3 个部分:

    1. 为注册用户提供基于浏览器的广播客户端(我们可以认为这两个是同一个组件)的公共 Web 应用程序

    2. 这些用户可能希望或可能不希望他们的客户端与之交互的公共 Internet 上某处任意数量的不受监管的广播服务器,我们可能知道也可能不知道这些服务器的存在。

    3. 中间的代理服务接受来自网络客户端的连接,将流转发到这些服务器。

    我认为保护这些组件的最佳方法是让 webapp 具有权威性(它可以更好地扩展,更容易实现,更容易管理,并且它已经以某种形式存在)。默认情况下,代理应删除所有连接。只有当用户登录到 webapp/shoutcast 客户端时,它才会根据某种令牌或用户/密码组合通知代理它可以从哪些服务器连接以及将要连接到哪些服务器。

    当客户端连接到代理并提供其临时令牌(或其他标识方式)时,代理会在其内部哈希表中查找它以决定连接到哪里(或验证它是否允许在那里连接)。

    您可以让管理员预先批准现有的直播服务器列表供用户使用 web 应用程序进行选择,或者让用户将其添加到系统中,以便以后以编程方式或手动方式进行验证。

    至于防火墙,因为所有转发的连接都源自代理应用程序,所以删除源自代理并通过某些网络接口(admin、lan、vpn、tun、tap 等)的每个连接也应该很容易) 除了那些在互联网上发往外国地址的人。

    除了让您的 webapp 与代理通信之外,您甚至可以让它配置您(或亚马逊或其他任何人)的防火墙规则,以防止任何和所有恶意流量通过您的代理(或至少使执行和审核策略变得更加容易,因为因此,任何可能的连接都必须由有效且现有的用户拥有)并且还可以防止基本的拒绝服务攻击(webapp 可以比您的旧代理服务更容易和更便宜地托管在云中),因此默认情况下对所有内容进行防火墙并开放基于网络/用户活动的漏洞是一个可靠的游戏计划,无论是规模、复杂性、性能还是安全性。

    一些额外的常识:

    1. 协议强制(您只想让您的应用程序协议通过),终止任何不符合您的 rfc/协议的连接。这也有助于抵御易受攻击的服务的攻击,并防止其他协议随机通过。

    2. 建立被视为列入白名单的站点/服务(ip+端口对)的可配置(平面文件/数据库)列表。

    3. 建立可配置的黑名单(管理网络、本地主机等)

    4. 请注意您发回的诊断错误,或者您是否发回任何内容(想想攻击者使用您的代理服务通过查看您的代理的响应来探测/映射您的内部网络资源)。

    5. 考虑根本不实施此代理,除非您绝对必须这样做,如果静态配置的转发/路由就足够了,请改用它。中继(打开或关闭)因某种原因而被避开。

    亲切的问候,

    【讨论】:

    • 感谢您的意见 Yuka,这都是很好的建议。对于它的价值,我正在构建一个 SHOUTcast 源客户端代理,其中客户端是一个浏览器,通过 websockets 发送数据,代理服务器将这些数据转换为另一端真正的 SHOUTcast 服务器可用的东西。不幸的是,这一切都是必要的。我什至没有考虑错误消息和什么……这绝对是个好建议!
    • 好吧,布拉德,这让事情变得更清楚了。还有一个问题:广播服务器是否在您的控制之下(或网络客户端的同一组织结构的一部分),还是它们(客户端)来自各地,并连接到互联网上的随机广播服务器?例如。它们是否易于管理,基础设施的不同部分之间是否存在(或可能存在)逻辑链接,或者所有内容都被认为是自主的?
    • 他们来自四面八方,我无法控制他们。基本上,我为不同类型的客户端提供了一种访问他们想要的任何服务器的方法。它不会完全免费,因为用户必须注册才能使用我的服务,但这并不意味着我一定信任这些用户。这只是意味着向我发送请求将更加困难,因为我只允许每个用户一对夫妇。此外,我无法预测远程服务器的端口号或任何内容。这有点挑战,但我认为通过一些密切的监控和常识性保护,我可以应付。
    • 好的,我根据最近几个 cmets 提供的额外信息更新了答案。根据我收集到的信息,您应该能够将其固定下来并使其相当密闭(当然还有您愿意走多远,但这应该是相当微不足道的练习)。
    • 不客气,布拉德,希望对您有所帮助!祝你好运。
    猜你喜欢
    • 1970-01-01
    • 2011-06-04
    • 1970-01-01
    • 1970-01-01
    • 2016-06-01
    • 2011-08-09
    • 2021-06-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多