0

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

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

如果它很重要,我将使用 Node.js 来构建这个代理服务器,以及net.connect()创建与远程服务器的 TCP 连接的标准方法。

4

1 回答 1

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)以确定资源是否要受到限制。

根据评论中的信息更新:

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

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

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

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

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

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

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

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

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

一些额外的常识:

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

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

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

  4. 小心你发回的诊断错误,或者如果你发回任何东西(想想攻击者使用你的代理服务通过查看你的代理的响应来探测/映射你的内部网络资源)。

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

亲切的问候,

于 2013-11-07T00:25:56.817 回答