普遍的看法是，位于受信任网络内的内部应用程序（例如 Exchange）在暴露于 Internet 时应该是反向代理。Microsoft 建议为此使用 UAG/TMG，因为它具有一些内置的安全功能。Mod_security 在 Apache 反向代理场景中起着类似的作用。但是，我看到很多安装都使用了反向代理，但没有使用这个额外的安全层。
在这种情况下，为什么还要费心使用反向代理？如果您不使用某些 L7 逻辑来缓解攻击，那么添加代理层与直接暴露应用程序相比有什么好处？
答案1
从防御攻击的角度来看，不过滤输入/输出数据当然没有任何价值。有人可能会说，没有深思熟虑的代理实际上会降低安全性，因为：
- 引入了更大的复杂性，而且通常更为复杂。
- 透明度较低，因为每个交易都需要多个日志和警报层进行关联。
- 通过附加子系统可以增加攻击面。
- 系统更加多样化也增加了人为错误的风险。
- 每个系统都会存在引入不确定性的错误，代理也不例外。
更不用说技术资源（机器、存储、备份/恢复等）的浪费。
另一方面，在安全方面可能还会有其他方面的进步：
- 负载平衡和故障转移的可能性。
- 访问层与服务层的分离更加灵活（即更容易维护、重组等）。
- 未来的选项是轻松引入过滤等等，而不会争用服务层的系统资源。
- 分离除简单攻击特征过滤之外的其他功能，例如重写逻辑或某些日志记录，从而使得配置更加容易并且更改期间的风险更小。
- 某些功能可能在代理平台上有更好的记录或了解，从而通过将它们移出后端来提供更大的整体稳定性和控制力或减少未知数。
我确信还有更多，这只是我脑海中想到的。
答案2
曾经有一段时间，Apache 的默认安装比 IIS 的默认安装有更少的已知安全漏洞；独自的是一项安全改进。
因此，它可能仅仅成为了部落的传说，因为它曾经是一种最佳做法。