Amazon web services AWS ELB使用X-Forwarded-For作为客户端IP记录到S3

Amazon web services AWS ELB使用X-Forwarded-For作为客户端IP记录到S3,amazon-web-services,amazon-s3,amazon-elb,x-forwarded-for,Amazon Web Services,Amazon S3,Amazon Elb,X Forwarded For,我们有一个DDoS层(Project Shield),它将公共请求转发到我们的AWS应用程序负载平衡器(ALB)。我们的ALB已启用访问日志记录(到S3存储桶)。除了设置bucket、设置权限和启用此功能之外,我还没有找到很多配置选项 ALB日志似乎将客户端IP存储为项目屏蔽(与X-Forwarded-For标头中列出的IP相比)。是否可以让ALB记录原始客户端ip(X-Forwarded-For中最左侧) 如果这是不可能的,也许有一个更好的解决方案,我忽略了 我的目标是让我们的防火墙设置解析这

我们有一个DDoS层(Project Shield),它将公共请求转发到我们的AWS应用程序负载平衡器(ALB)。我们的ALB已启用访问日志记录(到S3存储桶)。除了设置bucket、设置权限和启用此功能之外,我还没有找到很多配置选项

ALB日志似乎将客户端IP存储为项目屏蔽(与X-Forwarded-For标头中列出的IP相比)。是否可以让ALB记录原始客户端ip(X-Forwarded-For中最左侧)

如果这是不可能的,也许有一个更好的解决方案,我忽略了

我的目标是让我们的防火墙设置解析这些日志,根据规则清洗它们,并根据恶意流量/模式将IP列入黑名单


提前感谢。

您的提议似乎有一些问题。其中。。。Project Shield也是一个缓存,不是吗?因此,
X-Forwarded-For
值的意义有限——您应该只看到缓存未命中的请求,对于流行内容,这应该是少数请求。假设您有要阻止的地址,则防火墙规则无法阻止您发现的任何地址,因为防火墙会将Project Shield服务器的后端地址视为流量源,而不是原始客户端。此外,请注意原始客户端IP不是
X-Forwarded-For
中最左侧的地址。您可以假定为原始客户端IP的唯一值是
X-Forwarded-For
中最右边的不受信任地址。通常这也是最左边的方法,但这不是一种一致有效的方法,因为客户端可以轻易地欺骗最左边的值,或者除了链中最右边的受信任设备添加的值之外的任何值,该值始终是列表中最右边的不受信任地址。谢谢@Michael sqlbot-这两个方面你都是正确的。我想如果原始ip位于黑名单。然而,这些请求仍然会击中Shield,Shield仍会试图拉回未命中。谢谢你的全面回复-肖恩