限制IP地址应该在哪里处理？答案

【问题标题】：Where should restricting IP address be handled?限制IP地址应该在哪里处理？
【发布时间】：2009-05-08 16:26:08
【问题描述】：

我们在应用层前面运行反向代理，我想知道处理 IP 限制的“最佳实践”位置在哪里。

目前，我们使用应用程序安全性来限制通过 IP 地址对特定资源的访问，但是当我们转向在反向代理后面运行时，这会导致一些问题。在代理而不是应用程序上配置允许/拒绝规则非常容易，但是由于我们在代理后面运行多个应用程序，因此对配置进行修改有可能影响其他应用程序（不是很大的危险，但仍然存在） .

过滤器是在链的上游还是更靠近应用程序更好？

是否有任何陷阱，例如我们通过应用程序限制和添加反向代理遇到的所有请求“来自”代理，迫使我们使用标头来查找“真实”IP 地址。

【问题讨论】：

您的应用程序是如何托管的？自己的服务器？科洛？机架空间？在我上一家公司，我们使用 Rackspace，只是向他们发送了一个请求，要求他们在网络级别限制 IP。
目前，我们托管在同一地点。我们正在迁移到 Amazon 的 EC2 环境。我们不希望在网络级别进行 IP 限制，因为有时，只有某些资源需要通过 IP 地址进行限制。

【解决方案1】：

我们尽可能早地过滤并使其远离应用程序；这类事情可以通过网络运营更好地管理。原因是应用程序开发人员或维护人员在更改 IP 地址时并不总是参与其中，而网络操作人员通常是第一个知道的。此外，网络类型工具通常更擅长提供/限制软件级工具的访问。

【讨论】：

【解决方案2】：

我永远不会受到 IP 地址的限制。像这样的限制是安全层的工作，而不是 IP 地址所在的网络层的工作。我很少发现让应用程序限制网络实施的价值。

【讨论】：

【解决方案3】：

这取决于需要通过 IP 限制的资源类型。如果应用程序的某些部分需要通过 IP 进行限制，那么应用程序应该处理它。如果需要阻止整个应用程序，那么您应该更进一步。

一般规则是在不损害您现有的任何审计系统的情况下尽早进行限制（了解人们何时试图破坏您的安全系统几乎总是一个好主意）。

【讨论】：

【解决方案4】：

我尽可能早地通过 IP 地址进行限制 - 这消除了后续层或子网中的不必要流量。所以我的建议类似于 u07ch 的建议，尽早做。

【讨论】：